Calc Считает с ошибками Как решить ЭТО?

[BotExtraSens]

Доброго Времени Суток!
Уважаемые профи помогите решить проблему

У меня Libre Calc Версия: 5.3.2.2 (x64)
Который выполняет Заполнение Списка с Ошибками

Создал  список Данных в столбце:  числа по нарастающей  1  1,1  1,2 и так  до 6 (с шагом 0,1)
Ячейки не форматировал по умолчанию все числовые значения
в итоге в  столбце  некоторые отображаемые целые числа при двоеном клике отображаются как дробные например: 6,00000000000001  

Ниже прикрепил файл

Заранее Всем Спасибо!

[rami]

Каким способом вы создали такой список?

[BotExtraSens]

Каким способом вы создали такой список?

1)  Создал новый Документ
2)  Ввел первое число в столбце 1,0
3)  Ввел второе число  в столбце 1,1
4)  Выделил первые две ячейки  в столбце с числами 1,0 и 1,1
5)  Протянул выделение в низ по столбцу пока не получил число 6  (6,00000000000001 )
     получается шаг 0,1

[rami]

Да, кажется, это баг. На LibreOffice 6.3.4.2 тоже так, но если использовать "Заполнить ряды", то заполняет правильно.

[BotExtraSens]

Да, кажется, это баг. На LibreOffice 6.3.4.2 тоже так, но если использовать "Заполнить ряды", то заполняет правильно.

Пересмотрел несколько уроков по заполнению списков сделал как написанно и тут нате баг ))
Выявил это случайно когда в результате подсчетов пытался отфильтровать целые числа из общей массы , естественно не все ожидаемые отобразились )))

Как остальные Ютуб-Урока Делы так успешно автозаполняют или Преподают ?? )
LibreCaLc вроде в гоструктурах по импорто замещению, мож так  и общитались с пенсионным фондом (отфильтровалось не все)

Спасибо вам огромное , вроде помогло а то весь день пытался подсчитать предидущим способом с автозаполнением

[mikekaganski]

Ну, не то чтобы баг ... просто результат неточности машинных операций с десятичными числами.

Число 1 хранится в двоичном представлении без искажений. А вот 1,1 уже представлено неточно (~1.1000000000000001, т.е. ошибка примерно на единицу в 17-м значащем десятичном разряде, или на ~1*10^-16). При растягивании двух этих выделенных чисел Calc должен вычислить их разность, которая оказывается ~0.10000000000000009 (можно поэкспериментировать тут). Calc делает дополнительные проверки и округляет результат до 16 десятичных знаков после запятой - т.е. до 0.1000000000000001. При этом в интерфейсе представлены только 15 знаков, поэтому эта единица не видна. А в результате последовательных инкрементов (со своими погрешностями!) в конце концов эта 1*10^-16 вылезает, когда суммарно превышает 1*10^-15 (в принципе могло бы оказаться на 10 ячейке - но здесь играет роль погрешность инкрементов).

При ручном задании инкремента в диалоге заполнения рядов величина 0,1 тоже хранится с погрешностью - ~0,10000000000000001. Но тут абсолютная величина погрешности на порядок меньше (поскольку сама величина на порядок меньше, чем 1,1, от которой плясали изначально), и не вылезает в результат.

Обратите внимание, что при работе с десятичными числами в компьютерных системах необходимо учитывать возможность неточных вычислений - это не баг, а ограничение аппаратной части двоичных компьютеров при работе с числами с ограниченной точностью (обычно IEEE 754 double).

Но здесь можно поправить на самом деле, если ограничить округление не до 16, а до 15 знаков - следуя ограничению, заданному в UI (ведь и процедура производится из UI). Нужен баг, я сделаю фикс и предложу эксперту нашему.

[Yakov]

В Apache OpenOffice 4.1.3 это то же проявляется.

[mikekaganski]

tdf#129606

[BotExtraSens]

Обратите внимание, что при работе с десятичными числами в компьютерных системах необходимо учитывать возможность неточных вычислений - это не баг, а ограничение аппаратной части двоичных компьютеров при работе с числами с ограниченной точностью (обычно IEEE 754 double).

Просто первый раз с таким столкнулся до этого пробовал некоторые языки програмирования связанные с кодом вычислений но
с таким первый раз столкнулся из любопытсва выяснял в чем подвох методом тыка,  весь день потратил .
отсюда мое удивление )

Но здесь можно поправить на самом деле, если ограничить округление не до 16, а до 15 знаков - следуя ограничению, заданному в UI (ведь и процедура производится из UI).

Этот вариант тоже пробовал :
Отформатировал вывод до двух нулей после запятой  , но возникла другая проблема
при создание условия поиска целых чисел  ( Стандартный фильтр > Содержит > ,00 )
авто фильтр не выдовал результатов в отличие от первого варианта, который выводил по понятным теперь причинам хотябы часть результата))

Нужен баг, я сделаю фикс и предложу эксперту нашему.

В первом посте файл приложен в нем есть баг , Заранее спасибо!

[BotExtraSens]

В Apache OpenOffice 4.1.3 это то же проявляется.

Ясно

tdf#129606

Оперативно!

[mikekaganski]

при создание условия поиска целых чисел  ( Стандартный фильтр > Содержит > ,00 )
авто фильтр не выдовал результатов в отличие от первого варианта, который выводил по понятным теперь причинам хотябы часть результата))

Непонятно: что выводил первый вариант, чего не выводил второй? (и да, то, о чём Вы говорите - это просто форматирование; я писал не об обходных путях, а о том, что надо в коде поменять).

[Yakov]

Excel2007 так же ошибается, но уже на другой ячейке

[mikekaganski]

Действительно, и в 2016 так же. Ну, тогда если не примется патч - не так обидно :-)

[BotExtraSens]

Непонятно: что выводил первый вариант, чего не выводил второй? (и да, то, о чём Вы говорите - это просто форматирование; я писал не об обходных путях, а о том, что надо в коде поменять).

Что должно выводить писал в первом посте даной теме но не суть

Углубляться в коды пока нет возможностей по времени
потому пользовался базовыми функциями: сложение, умножение, деление в определенном диапазоне ячеек
для кого то ани обходной вариант ))

Затем отфильтровать целые числа ( которые без дробной части )

Excel2007 так же ошибается, но уже на другой ячейке

Неожидано )

[nik_ko]

Доброго Времени Суток!
проверил варианты

Интересно что это?! Баг?