Я делал некоторые расчеты для планирования улучшенной реализации моего основного сита, когда заметил, что в листе Libre Office отображаются неправильные значения для чисел, значительно меньших 2 ^ 53, что является пределом для точных целочисленных вычислений в FoxPro и множество других языков, которые внутренне используют C double (aka IEEE 754 double).
Некоторые быстрые проверки показали неправильные результаты для чисел всего 2 ^ 50. Что еще хуже, сломанная часть программного обеспечения не давала никаких предупреждений о том, что она работает за пределами ее эксплуатационных пределов и что отображаемые значения были приблизительными (даже если правильные значения были введены вручную). Я думаю, они думали, что для POS, такого как Excel, должно быть достаточно для них (но они должны были называть его "Guesstimate" вместо "Calc" ).
Во всяком случае, можно ли превратить электронную таблицу в какой-то точный режим, который дает не менее точность double и/или заставить ее показывать какое-то предупреждение, когда некоторые расчет превышает его числовые возможности?
Или имеется ли какая-либо другая электронная таблица, подходящая для программистов в возрасте, когда даже телефоны и тостеры питаются от 64-битных чипов?
Предыстория: в этом конкретном случае потребность в точности возникает из-за того, что точность формул проверяется путем сравнения определенных столбцов результата со списками хорошо известных чисел (например, число простых чисел до 2 ^ k, доступно из OEIS) или с номерами, полученными из инструментального кода. Идея состоит в том, чтобы получить правильные формулы, проверив их на допустимые диапазоны - до где-то между 2 ^ 32 и 2 ^ 40 - и затем использовать эти формулы для изучения поведения для диапазонов до 2 ^ 64 (где невозможно получить полную картину, выполнив исчерпывающие тесты).
PS: я обнаружил, что проблема была подробно проанализирована в О числовой точности таблиц (pdf). Кажется, что gnumeric держится чуть лучше, чем остальные, но это скорее случай одноглазых среди слепых, чем на самом деле прохождение сборов; кроме того, он недоступен для Windows и, следовательно, для запуска виртуальной машины Linux на платформе, которую я разрабатываю и для...
UPDATE/РЕШЕНИЕ
До 2 ^ 49 проблем нет, поэтому можно нормально работать. Этого достаточно, чтобы получить точное представление о вещах. В итоговых таблицах большие числа и высокоточные результаты (вычисленные в другом месте) вводятся в виде предварительно форматированного текста (или, скорее, импортированного/вставленного), так что Calc не может обработать дисплей. Цифры по-прежнему можно ссылаться, применяя функцию VALUE(), а для многих встроенных вычислений внутренняя точность вполне достаточна - особенно для графического отображения.
На приведенном ниже рисунке показано, что я опубликовал в одном из комментариев, что внутренняя точность выше отображаемой. Как мы должны выяснить, каковы фактические значения, если программа не показывает их? Играйте с добавлением/вычитанием небольших значений, отслеживайте изменения, создавайте и проверяйте гипотезы относительно соотношения фактических значений, предполагаемого поведения округления и отображаемых значений? Ум по-настоящему боится.
Я предлагаю награду для любого из следующих действий:
-
практический способ восстановления Calc для разумного поведения в смысле WYSIWI (то, что вы видите, внутри, или, скорее, если оно внутри, то оно может отображаться), не уменьшая внутренней точности и не разрывая весь кровавый источник дерево и фиксация себя
-
указатель на таблицу с более высокой точностью, чем IEEE 754 double (предпочтительно произвольная точность, например GP/PARI, но как электронная таблица), который является общедоступным или условно-бесплатным; могут быть приемлемы веб-сайты/облачные вещи.
Причина для первого элемента двоякая: на первый взгляд это чертовски неприятно, когда точность электронных таблиц ниже, чем универсальная IEEE 754 doubleпотому что это означает, что опыт/знания относительно точности/точности/стабильности на этом базовом уровне не переносятся. С другой стороны, это еще больше неприятностей, если мы не можем верить, что отображаемые значения верны, даже если мы точно знаем, что фактические значения.
Причиной второго пункта является тот простой факт, что довольно сложно использовать script вещи в другой программе для вычисления вещей с высокой точностью или с помощью бинум или для редактирования/компиляции/запуска программ для этой цели, Помимо неудобного разделения на таблицу и кучу скриптов или исходных файлов было бы более естественным и удобным работать только внутри электронной таблицы, периода.
