Форум поддержки пользователей. LibreOffice, Apache OpenOffice, OpenOffice.org

Форум поддержки пользователей. LibreOffice, Apache OpenOffice, OpenOffice.org

28 Июнь 2017, 08:27 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
Новости: Часто задаваемые вопросы по LibreOffice и Apache OpenOffice.org
 
   Начало   Помощь Поиск Войти Регистрация    задать вопрос  
Страниц: 1 2 »   Вниз
  Печать  
Автор Тема: Неточность при вычислениях  (Прочитано 1428 раз)
0 Пользователей и 1 Гость смотрят эту тему.
chemyakyn
Пользователь
**
Offline Offline

Пол: Мужской
Расположение: Тюмень
Сообщений: 77



WWW
« Стартовое сообщение: 26 Декабрь 2016, 07:48 »

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


* shot161226_01.png (2.14 Кб, 233x86 - просмотрено 10 раз.)
Записан
Yakov
Администратор
*
Offline Offline

Сообщений: 2 204


WWW
« Ответ #1: 26 Декабрь 2016, 07:58 »

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

chemyakyn
Пользователь
**
Offline Offline

Пол: Мужской
Расположение: Тюмень
Сообщений: 77



WWW
« Ответ #2: 26 Декабрь 2016, 08:08 »

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

Сообщений: 564


« Ответ #3: 26 Декабрь 2016, 08:25 »

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


* ExcelТожеЧутьОшибается.jpg (36.89 Кб, 501x393 - просмотрено 15 раз.)
Записан

Руб. за сто, что Питоньяк
Любит водку и коньяк!
Потому что мне, без оных, -
Не понять его никак...
chemyakyn
Пользователь
**
Offline Offline

Пол: Мужской
Расположение: Тюмень
Сообщений: 77



WWW
« Ответ #4: 26 Декабрь 2016, 08:45 »

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


* shot161226_03.png (14.69 Кб, 368x320 - просмотрено 11 раз.)
Записан
economist
Ветеран
*****
Offline Offline

Сообщений: 564


« Ответ #5: 26 Декабрь 2016, 08:59 »

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

Руб. за сто, что Питоньяк
Любит водку и коньяк!
Потому что мне, без оных, -
Не понять его никак...
economist
Ветеран
*****
Offline Offline

Сообщений: 564


« Ответ #6: 26 Декабрь 2016, 09:19 »

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

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

Руб. за сто, что Питоньяк
Любит водку и коньяк!
Потому что мне, без оных, -
Не понять его никак...
chemyakyn
Пользователь
**
Offline Offline

Пол: Мужской
Расположение: Тюмень
Сообщений: 77



WWW
« Ответ #7: 26 Декабрь 2016, 09:23 »

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


* shot161226_04.png (54.65 Кб, 922x657 - просмотрено 10 раз.)
Записан
kompilainenn
Ветеран
*****
Offline Offline

Сообщений: 1 976



« Ответ #8: 26 Декабрь 2016, 09:44 »

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

Поддержать разработчиков LibreOffice можно тут, а наш форум вот тут
economist
Ветеран
*****
Offline Offline

Сообщений: 564


« Ответ #9: 26 Декабрь 2016, 10:30 »

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

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

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

 
Записан

Руб. за сто, что Питоньяк
Любит водку и коньяк!
Потому что мне, без оных, -
Не понять его никак...
mikekaganski
Старожил
****
Offline Offline

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 474


« Ответ #10: 26 Декабрь 2016, 10:47 »

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

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

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

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

С уважением,
Михаил Каганский
mikekaganski
Старожил
****
Offline Offline

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 474


« Ответ #11: 26 Декабрь 2016, 10:59 »

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

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

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

С уважением,
Михаил Каганский
Yakov
Администратор
*
Offline Offline

Сообщений: 2 204


WWW
« Ответ #12: 26 Декабрь 2016, 11:44 »

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

chemyakyn
Пользователь
**
Offline Offline

Пол: Мужской
Расположение: Тюмень
Сообщений: 77



WWW
« Ответ #13: 26 Декабрь 2016, 12:47 »

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

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

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

Yakov, спасибо за ссылку.
Записан
economist
Ветеран
*****
Offline Offline

Сообщений: 564


« Ответ #14: 26 Декабрь 2016, 12:59 »

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

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

Ведь есть же стандартный механизм локализации - почему бы его просто не включить в дистр эти сраные 20 функций, а не насиловать мозги бабушек-бухш и студенток изучением непонятных слов!
« Последнее редактирование: 26 Декабрь 2016, 13:02 от economist » Записан

Руб. за сто, что Питоньяк
Любит водку и коньяк!
Потому что мне, без оных, -
Не понять его никак...
Страниц: 1 2 »   Вверх
  Печать  
 
Перейти в:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!