Проблема во вложении. Повторить можно с лёгкостью.
Да, я знаю, как сделать так, чтобы пользователь этого не увидел.
Хочу получить комментарии от знающих людей, на сколько это бага или фича и с чем это связано.
Excel всегда показывает точно.
Цитата: chemyakyn от 26 декабря 2016, 05:48Excel всегда показывает точно.
Вот как раз это сделано для совместимости с Excel. В Excel такое то же проявляется.
Это особенность работы с числами с плавающей запятой.
Yakov, неправда.
1. Формат файла ODS. Какая такая совместимость с Excel?
2. Та же самая формула в Excel считает правильно. Т.е. на лицо явная несовместимость.
Excel ведет себя еще интереснее (вложение)
economist, хорошо, давайте перейдём к обсуждению Excel. У примерно 2000 пользователей в нашей организации, ещё год назад это выглядело бы так, как во вложении.
Вы разрядность ячейки A3 увеличьте, посмотрим что получится. У меня MSO 2010/2013 под рукой нет, только 2007.
То есть вопрос не в том как вычисляет Calc и Excel, а как показывает. В не-космических расчетах подобные погрешности смешны.
Все числа в Excel - имеют тип Double, "плавающие" с двойной точностью (точность - плавает). Подобные огрехи - разумный компромисс между скоростью и красотой.
economist, короче, я понял. Во всём Excel подлый виноват.
Это плохая идея, во всём кивать на Excel. Или надо сразу решить, что мы идём за "большим братом" и ничего своего не делаем, или выбирать свой путь и не кивать на него, на каждый вопрос.
дело не в том, как Эксель или сякой Кальк. Дело в том, что машина оперирует двоичными числами, а потом переводит их в десятичную систему, отсюда эти неточности. Обе программы одинаковы в этом плане
chemyakyn - из форумчан я люблю Excel, наверное, больше всех :D Этот мой основной рабочий инструмент.
За 20 лет написано более 60 тыс. строк кода на VBA, включая большие приложения типа расчета ЗП на 1,5 тыс человек. В итоге сокращены десятки людей, сэкономлены десятки млн. руб. Excel - это эталон табличного процессора и действительно "максимально интегрированной" IDE широкого профиля.
И честно, искренне считаю что путь в массы - OpenOffice|LibreOffice получит только после того, как Calc станет похожим на Excel в главной части - в русскоязычных формулах и более широкой поддержке объектной модели VBA Excel. Она уже неплоха (в LO), примерно 50% кода совместимо. Но нужно больше.
Разделю мнение, что персональные компьютеры пришли в быт из бизнеса, а нем они обосновались благодаря Экселю. Вычилитель - есть "вычислитель".
Цитата: chemyakyn от 26 декабря 2016, 09:23
economist, короче, я понял. Во всём Excel подлый виноват.
Это плохая идея, во всём кивать на Excel. Или надо сразу решить, что мы идём за "большим братом" и ничего своего не делаем, или выбирать свой путь и не кивать на него, на каждый вопрос.
В этой ветке есть один господин, который всё хочет найти "проблему", "несовместимость", "виноватого" :)
На самом деле не совсем правда, что это "сделано для совместимости с Excel". Просто и Excel, и Calc используют аппаратные вычисления с плавающей точкой, как указал
economist. У обеих программ есть альтернатива: переключиться на использование программных библиотек символьной алгебры или вычислений с неограниченной точностью. Но при этом быстродействие всех операций снизится в лучшем случае на два порядка. И это не просто неприемлемо, а неприемлемо вообще.
Другой вопрос, что Calc действительно делает следующий шаг с целью сохранения совместимости. Если оказывается, например, что алгоритм, выбранный Calc, даёт 1,00000000000001, а выбранный Excel - 0,99999999999999, то есть дальнейшая опрерация INT() для них даст разные результаты и приведёт к несовместимости, и об этом пользователи сообщают, то алгоритм пересматривается, чтобы давать погрешность в ту же сторону. Ведь при таких вычислениях имеет значение выбор порядка вычислений (даже таких "примитивных", как сложение/умножение/вычитание/деление), а значит, и методов оптимизации, и выбора библиотек...
Не существует переносимых методов с приемлемой производительностью, избавленных от таких погрешностей вичислений с плавающей точкой. Это на самом деле невероятно сложная проблема. Мне очень нравится цикл статей на эту тему у randomascii (https://randomascii.wordpress.com/category/floating-point/).
А выбирать "свой путь" и "не кивать" нельзя. Потому что одна из самых главных задач у офисных программ - давать пользователю возможность открывать документы, полученные от корреспондента, и создавать документы для передачи корреспондентам.
Ну, и что касается "при чём тут совместимость, если формат ODS" - если бы вдруг Calc сознательно решил давать разные результаты вычислений в зависимости от формата файла - это был бы вообще финиш.
Цитата: economist от 26 декабря 2016, 10:30
искренне считаю что путь в массы - OpenOffice|LibreOffice получит только после того, как Calc станет похожим на Excel в главной части - в русскоязычных формулах...
Вы, наверное, в курсе, что Calc имеет возможность локализовывать функции. Это зависит от решения команды локализации на определённый язык. Не далее как вчера, например, пришлось помогать пользователю из Польши, у которого из-за локализации не работала функция ABS() - её нужно было вводить в локализованном виде, либо включить английские имена функций в настройках формул Calc. Лично я, учитывая наличие такой настройки, не считаю, что локализация приведёт к проблемам - кроме дополнительной работы локализаторов, а это действительно проблема. (Может, Вы бы предложили им свою помощь в этом вопросе?)
Однако я не вижу, чтобы конкретно эта особенность в других локализациях как-то влияла на распространение "в массах". Это, скорее, разовый фактор удивления при переходе, не более.
https://bz.apache.org/ooo/show_bug.cgi?id=117841 - отмечено как не баг
mikekaganski, вот только не надо мне рассказывать за трудности вычислений с плавающей точкой. Я, знаете ли, с ЭВМ познакомился ещё когда PC в этой стране ещё не было, а Unix первый ставил ещё на СМ1420 - родная для него архитектура, между прочим.
В данном конкретном случае, это вопрос ответственности разработчиков и их способности принять конкретное решение. Мой вопрос как раз и состоял в этом - я нигде не нашёл комментариев, принималось ли какое-либо решение, или разработчики решили всё оставить как есть. Учитывая, что результат в MSO и LO всё-таки отличается, предположение об обеспечении совместимости отпадает.
На самом деле, по результатам этой ветки я выводы сделал и соответствующую запись в свою базу знаний внёс.
Что касается локализации функций. Лично я считаю, что это весьма бестолковое занятие. Единственная причина, зачем это может быть нужно, это для совместимости с MSO. Более чем сомнительная причина, с моей точки зрения.
Yakov, спасибо за ссылку.
Русские функции в Calc - это совместимость прежде всего с головами пользователей Excel, коих в 1000 раз больше, чем пользователей Calc. Я одномоментно перевел 250 пользователей на Calc и ответственно заявляю - 90% недовольства - это функции "in english", а 10% - поведение при вставке. Так как насильный переезд был в эпоху "до риббона" (MSO 2003) - то других жалоб не было.
Помощь в локализации не окажу, так как не понимаю в чем она нужна. Ведь надо-то перевести всего лишь 20% самых часто используемых функций, существующих без изменений синтаксиса уже 10, а то и 30 лет (SUM, VLOOKUP, INDEX, INDIRECT, SUMIF итп)?
Ведь есть же стандартный механизм локализации - почему бы его просто не включить в дистр эти сраные 20 функций, а не насиловать мозги бабушек-бухш и студенток изучением непонятных слов!
economist, если бы локализация функций была такой большой проблемой, меня бы уже давно задолбали вопросами. Однако же, все молчат в тряпочку, хотя их далеко не 250.
Цитата: chemyakyn от 26 декабря 2016, 10:47Yakov, спасибо за ссылку.
Есть ещё баги на тему вычисления с плавающей запятой, но сразу не нашлись...
Цитата: Yakov от 26 декабря 2016, 13:35
Есть ещё баги на тему вычисления с плавающей запятой, но сразу не нашлись...
Ну, например, вот (https://bugs.documentfoundation.org/show_bug.cgi?id=63242).
И вот (https://bugs.documentfoundation.org/show_bug.cgi?id=50299).
Цитата: chemyakyn от 26 декабря 2016, 12:47
mikekaganski, вот только не надо мне рассказывать за трудности вычислений с плавающей точкой. Я, знаете ли, с ЭВМ познакомился ещё когда PC в этой стране ещё не было, а Unix первый ставил ещё на СМ1420 - родная для него архитектура, между прочим.
Каковы бы ни были (декларируемые) заслуги кого бы то ни было в любых областях, если человек своими высказываниями проявляет незнание обсуждаемого вопроса, "знакомство" с компьютером и опыт установки ОС не могут служить аргументом.
chemyakyn - интересно, а какие трудности возникают у ваших Calc пользователей?
"Не как в Excel" - я слышу очень редко, 3-5 обращений в год.
mikekaganski, Вы сейчас о чьих заслугах? О Ваших? Потому что я о своих заслугах вообще не говорил: речь шла только об опыте.
И да, я не знаю всех особенностей Calc. Собственно, именно поэтому и создал эту тему. Не смотря на нервную реакцию некоторых "гуру", некоторое понимание вопроса у меня появилось.
beconomist, трудности? На самом деле, с моей точки зрения, особых трудностей именно с Calc нет. А то, что пользователи сравнивают его с более привычным им Excel, это совершенно нормально.
Вообще, надо понимать, что внедрение LibreOffice, в нашем случае, это лишь один шаг на большом пути. Конечной целью является полный переход на отечественную аппаратную платформу. Скорее всего, этой платформой будет Эльбрус, но я не исключаю и другие варианты, например, тот же Байкал, имеющий более распространённую архитектуру. В нашем случае, офисный пакет просто является основным инструментом, с которым работают все сотрудники, без исключения. Следовательно, замена офисного пакета является необходимым, для дальнейшего перехода, сначала на отечественное ПО, а затем и на отечественное железо.
Что касается трудностей.
Как я уже говорил, именно с Calc непреодолимых трудностей немного. Есть некоторое количество неприятностей. Например, нет возможности скопировать стиль страницы, что приводит к необходимости создавать его заново, если разные страницы должны быть отформатированы по разному. Непреодолимых проблем, по сути, наблюдается только две: не работает VBA и OLAP. Кроме того, некоторые ИС написаны как дополнение к MS Office и в принципе не могут работать без него. Это пока основные причины, по которым оставляем MS Office на рабочих местах. Бывает и всякая экзотика. Например, ГАС Управление выгружает данные якобы в формате Excel, а на деле в совершенно феерическом формате, который фактически является HTML кодированным base64. Excel его открывает как MHTML, хотя и ругается.
Больше всего проблем наблюдается с Writer, т.к. при переходе на него с MS Word, в 995‰ наблюдаются проблемы с форматированием. При чём, я уверен, что эти проблемы являются следствием намеренного противодействия Microsoft. Мой многолетний опыт доказывает, что такие вещи очень в духе Microsoft.
Также, большой проблемой является внедрение Impress. Проблема даже не в том, что у него плохая совместимость с PowerPoint, и даже не в привычках пользователей. Проблема в том, что Impress явно недоделанный. Я редко сталкиваюсь с презентациями, но, например, задача переделать мастер-слайды в шаблоне оказалась совершенно нетривиальной, потому что оно просто не работает так, как ожидается. При этом, наблюдаются какие-то совершенно загадочные глюки, когда я хочу добавить или удалить мастер-слайд. Времени детально разбираться не было - как-то переделал, сдал и ладно. Разбираться потом буду.
Что касается Draw, то, похоже, до недавнего времени кроме меня им вообще никто у нас не пользовался. Однако, судя по тому, что в системе документооборота всё-таки появились документы в этом формате, вопросы по работе с ним не за горами. А вопросы есть. Самый простой вопрос: как напечатать на страницу A4 рисунок, сделанный в формате A3? Ответ: средствами Draw - никак. Можно напечатать через экспорт в PDF, но в этом случае наблюдаются довольно загадочные исчезновения элементов чертежа.
Цитата: chemyakyn от 29 декабря 2016, 08:36Самый простой вопрос: как напечатать на страницу A4 рисунок, сделанный в формате A3?
просто в целях повышения образованности: зачем рисовать в формате А3, если потом печать будет на формате А4? И да, конечно будут пропадать элементы при масштабировании, толщина линий тоже подвергается изменению
kompilainenn, хотя бы потому, что принтеров формата A3 гораздо меньше, чем формата A4. Обычно, начальству печатается большой формат, а чтобы почеркаться - маленький.
Да и вообще, масса случаев, когда распечатывать приходится с масштабированием. В LibreOffice масштабирование при печати есть, но оно не работает. Я не говорю про масштабирование в Calc - это другое, и оно работает. Слава Богу, именно в Calc масштабирование чаще всего и нужно.
Цитата: chemyakyn от 29 декабря 2016, 10:15В LibreOffice масштабирование при печати есть, но оно не работает.
если не трудно, напишите по шагам, как вы печатаете из А3 на страницу А4.
Как насчет выбрать опцию "Подогнать по размеру страницы"? - она не работает?
chemyakyn - извините, но я не верю в 99,5% проблем при открытии DOC во Writer.
В нашем архиве около 50 тыс. DOC/DOCX-файлов, из них половина - внешнего происхождения (8 банков, 4 администрации, 3 ФНС, куча рекламщиков, иностранцев, тысячи контрагентов) - с которыми с 2008-го года работали исключительно через OpenOffice, а позже - и через LibreOffice Writer.
Так вот, за всё это время проблемы возникли всего 4(четыре) раза (0,00008), в основном с "красивыми анкетками" якобы для ручного заполнения (окошки-флажки, тени и прочая мишура) и двух-колоночным безграмотно сделанным набором - смесью таблиц и врезок. Проблемы были решены вьюером от MS.
Если у кого-то проблемы возникают чаще чем с каждым сотым документом - то это признак диверсии, саботажа или "дезы". Ну не может быть столько проблем, ей-Богу!
Цитата: chemyakyn от 29 декабря 2016, 08:36Что касается Draw, то, похоже, до недавнего времени кроме меня им вообще никто у нас не пользовался. Однако, судя по тому, что в системе документооборота всё-таки появились документы в этом формате, вопросы по работе с ним не за горами. А вопросы есть. Самый простой вопрос: как напечатать на страницу A4 рисунок, сделанный в формате A3? Ответ: средствами Draw - никак. Можно напечатать через экспорт в PDF, но в этом случае наблюдаются довольно загадочные исчезновения элементов чертежа.
Таки да :(
Для примера открыл в
LibreOffice 5.1.6 Draw рисунок в
SVG, в котором текст не оконтурен и в результате вместо текста я увидел пустое место. Тогда я попробовал в LibreOffice Draw открыть такой же рисунок, но где текст уже превращён в контур, и о чудо всё было на своих местах. Попробовал экспортировать в PDF, так LibreOffice чуть не завис, правда рисунок в SVG был действительно огромный.
После этого решил проверить как поведёт себя
Apache OpenOffice 4.1.3 Draw в той же ситуации. В результате OpenOffice Draw нормально открыл рисунок где текст не окунтурен и все было на своих местах. Экспорт в PDF прошёл почти мгновенно без каких-либо зависаний.
Исходя из вышеизложенного, если действительно приходится часто сталкиваться с большими векторными рисунками, я рекомендую:
1) попробовать использовать Apache OpenOffice 4.1.3 Draw;
2) попробовать открыть рисунок А3 в Inkscape (https://ru.wikipedia.org/wiki/Inkscape), где произвести необходимые манипуляции (там нет ничего сложного). Например, нажать на кнопку
Выделить все объекты во всех видимых и неразблокированных слоях (Ctrl+Alt+A), после чего нажать на замочек (для пропорционального изменения ширины и высоты), и уменьшить рисунок до необходимых размеров. Уменьшить можно либо мышкой, либо введя искомое число в окошке в верхней части панели. Впрочем, можно и вовсе попробовать сразу из Inkscape распечатать рисунок формата А3, но лично я никогда из Inkscape ничего не отправлял на печать, тем более листы формата А3.
Постскриптум: по-моему данная тема уже уходит от первонального названия
Неточность при вычислениях ;)