Неточность при вычислениях

[chemyakyn]

Проблема во вложении. Повторить можно с лёгкостью.
Да, я знаю, как сделать так, чтобы пользователь этого не увидел.
Хочу получить комментарии от знающих людей, на сколько это бага или фича и с чем это связано.
Excel всегда показывает точно.

[Yakov]

Excel всегда показывает точно.

Вот как раз это сделано для совместимости с Excel. В Excel такое то же проявляется.
Это особенность работы с числами с плавающей запятой.

[chemyakyn]

Yakov, неправда.
1. Формат файла ODS. Какая такая совместимость с Excel?
2. Та же самая формула в Excel считает правильно. Т.е. на лицо явная несовместимость.

[economist]

Excel ведет себя еще интереснее (вложение)

[chemyakyn]

economist, хорошо, давайте перейдём к обсуждению Excel. У примерно 2000 пользователей в нашей организации, ещё год назад это выглядело бы так, как во вложении.

[economist]

Вы разрядность ячейки A3 увеличьте, посмотрим что получится. У меня MSO 2010/2013 под рукой нет, только 2007.

[economist]

То есть вопрос не в том как вычисляет Calc и Excel, а как показывает. В не-космических расчетах подобные погрешности смешны. 

Все числа в Excel - имеют тип Double, "плавающие" с двойной точностью (точность - плавает). Подобные огрехи - разумный компромисс между скоростью и красотой.

[chemyakyn]

economist, короче, я понял. Во всём Excel подлый виноват.
Это плохая идея, во всём кивать на Excel. Или надо сразу решить, что мы идём за "большим братом" и ничего своего не делаем, или выбирать свой путь и не кивать на него, на каждый вопрос.

[kompilainenn]

дело не в том, как Эксель или сякой Кальк. Дело в том, что машина оперирует двоичными числами, а потом переводит их в десятичную систему, отсюда эти неточности. Обе программы одинаковы в этом плане

[economist]

chemyakyn - из форумчан я люблю Excel, наверное, больше всех  Этот мой основной рабочий инструмент.
За 20 лет написано более 60 тыс. строк кода на VBA, включая большие приложения типа расчета ЗП на 1,5 тыс человек. В итоге сокращены десятки людей, сэкономлены десятки млн. руб. Excel - это эталон табличного процессора и действительно "максимально интегрированной" IDE широкого профиля.

И честно, искренне считаю что путь в массы - OpenOffice|LibreOffice получит только после того, как Calc станет похожим на Excel в главной части - в русскоязычных формулах и более широкой поддержке объектной модели VBA Excel. Она уже неплоха (в LO), примерно 50% кода совместимо. Но нужно больше.

Разделю мнение, что персональные компьютеры пришли в быт из бизнеса, а нем они обосновались благодаря Экселю. Вычилитель - есть "вычислитель".

[mikekaganski]

economist, короче, я понял. Во всём Excel подлый виноват.
Это плохая идея, во всём кивать на Excel. Или надо сразу решить, что мы идём за "большим братом" и ничего своего не делаем, или выбирать свой путь и не кивать на него, на каждый вопрос.

В этой ветке есть один господин, который всё хочет найти "проблему", "несовместимость", "виноватого"
На самом деле не совсем правда, что это "сделано для совместимости с Excel". Просто и Excel, и Calc используют аппаратные вычисления с плавающей точкой, как указал economist. У обеих программ есть альтернатива: переключиться на использование программных библиотек символьной алгебры или вычислений с неограниченной точностью. Но при этом быстродействие всех операций снизится в лучшем случае на два порядка. И это не просто неприемлемо, а неприемлемо вообще.
Другой вопрос, что Calc действительно делает следующий шаг с целью сохранения совместимости. Если оказывается, например, что алгоритм, выбранный Calc, даёт 1,00000000000001, а выбранный Excel - 0,99999999999999, то есть дальнейшая опрерация INT() для них даст разные результаты и приведёт к несовместимости, и об этом пользователи сообщают, то алгоритм пересматривается, чтобы давать погрешность в ту же сторону. Ведь при таких вычислениях имеет значение выбор порядка вычислений (даже таких "примитивных", как сложение/умножение/вычитание/деление), а значит, и методов оптимизации, и выбора библиотек...
Не существует переносимых методов с приемлемой производительностью, избавленных от таких погрешностей вичислений с плавающей точкой. Это на самом деле невероятно сложная проблема. Мне очень нравится цикл статей на эту тему у randomascii.

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

Ну, и что касается "при чём тут совместимость, если формат ODS" - если бы вдруг Calc сознательно решил давать разные результаты вычислений в зависимости от формата файла - это был бы вообще финиш.

[mikekaganski]

искренне считаю что путь в массы - OpenOffice|LibreOffice получит только после того, как Calc станет похожим на Excel в главной части - в русскоязычных формулах...

Вы, наверное, в курсе, что Calc имеет возможность локализовывать функции. Это зависит от решения команды локализации на определённый язык. Не далее как вчера, например, пришлось помогать пользователю из Польши, у которого из-за локализации не работала функция ABS() - её нужно было вводить в локализованном виде, либо включить английские имена функций в настройках формул Calc. Лично я, учитывая наличие такой настройки, не считаю, что локализация приведёт к проблемам - кроме дополнительной работы локализаторов, а это действительно проблема. (Может, Вы бы предложили им свою помощь в этом вопросе?)

Однако я не вижу, чтобы конкретно эта особенность в других локализациях как-то влияла на распространение "в массах". Это, скорее, разовый фактор удивления при переходе, не более.

[Yakov]

https://bz.apache.org/ooo/show_bug.cgi?id=117841  - отмечено как не баг

[chemyakyn]

mikekaganski, вот только не надо мне рассказывать за трудности вычислений с плавающей точкой. Я, знаете ли, с ЭВМ познакомился ещё когда PC в этой стране ещё не было, а Unix первый ставил ещё на СМ1420 - родная для него архитектура, между прочим.
В данном конкретном случае, это вопрос ответственности разработчиков и их способности принять конкретное решение. Мой вопрос как раз и состоял в этом - я нигде не нашёл комментариев, принималось ли какое-либо решение, или разработчики решили всё оставить как есть. Учитывая, что результат в MSO и LO всё-таки отличается, предположение об обеспечении совместимости отпадает.

На самом деле, по результатам этой ветки я выводы сделал и соответствующую запись в свою базу знаний внёс.

Что касается локализации функций. Лично я считаю, что это весьма бестолковое занятие. Единственная причина, зачем это может быть нужно, это для совместимости с MSO. Более чем сомнительная причина, с моей точки зрения.

Yakov, спасибо за ссылку.

[economist]

Русские функции в Calc - это совместимость прежде всего с головами пользователей Excel, коих в 1000 раз больше, чем пользователей Calc. Я одномоментно перевел 250 пользователей на Calc и ответственно заявляю - 90% недовольства - это функции "in english", а 10% - поведение при вставке. Так как насильный переезд был в эпоху "до риббона" (MSO 2003) - то других жалоб не было.    

Помощь  в локализации не окажу, так как не понимаю в чем она нужна. Ведь надо-то перевести всего лишь 20% самых часто используемых функций, существующих без изменений синтаксиса уже 10, а то и 30 лет (SUM, VLOOKUP, INDEX, INDIRECT, SUMIF итп)?  

Ведь есть же стандартный механизм локализации - почему бы его просто не включить в дистр эти сраные 20 функций, а не насиловать мозги бабушек-бухш и студенток изучением непонятных слов!