PHP, тип Double - точность вычислений

[vinniepooh]

Привет!
Подскажите по типу Double в PHP. Есть проблема, что так как десятичные числа хранятся не как точные, то могут быть такие ошибки при использовании мат. функций (ниже). Вопрос в том, чья это проблема при разработке. Если программист пользуется типом Дабл, как он может гарантировать, что всё будет посчитано точно. Или это принципиальный компромисс в пользу скорости и использования памяти?

Вот цитата из руководства по MySQL:

"Note that as decimal numbers are normally not stored as exact numbers in computers, but as double-precision values, you may be fooled by the following result:
mysql> SELECT TRUNCATE(10.28*100,0);
-> 1027

The above happens because 10.28 is actually stored as something like 10.2799999999999999. "

То же самое и при вычислениях на PHP.
Возникает вопрос, зачем нужен тип Дабл, если возникают такие проблемы? Может ли он гарантировать хоть какую-то точность. Или что получается, то и получается (приближённо).

Альтернатива - BCMATH.

[Arigato]

А вам какая нужна точность? В любом случае всегда есть предел точности вычислений, а во время вывода просто надо округлять дробные числа до требуемого числа знаков. Ну и не пытаться пару вещественных чисел сравнивать оператором ==

[vinniepooh]

Точность - наверное, тут главное иметь гарантированное число правильных знаков. Ведь при желании можно его увеличить. А вот если мы не знаем, точно посчитало или нет - то это дальше не используешь. Посчитали, допустим, SIN(1.34) - а не знаем, сколько правильно. Или в этом примере.

+-1 - и уже всё поехало. Вообще нужна большая точность. Гляжу в сторону BCMath. Но с Даблом хотел бы разобраться, и не только в этом языке.

В общем, главное гарантия - что конкретно этот знак результата верный. Она есть?

[Alex11223]

И чего мало материала по этой теме?
http://floating-point-gui.de/basic/
http://php.net/manual/en/language.types.float.php
http://habrahabr.ru/post/112953/
https://rsdn.ru/article/alg/float.xml

[vinniepooh]

Спасибо за ссылки. Первую я видел, просто не успел прочесть. А вот руководство PHP меня первоначально насторожило - там так написано, как будто всё настолько плохо, что результатам вообще нельзя доверять. Собственно, поэтому и начал выяснять всё. В 3-й статье оптимистично, что "арифметика почти совершенна". Что же реально на практике, выясняю.

[Pavia]

Если программист пользуется типом Дабл, как он может гарантировать, что всё будет посчитано точно. Или это принципиальный компромисс в пользу скорости и использования памяти?

Это не компромисс, а необходимость.
- Чем больше числа тем медленнее они обрабатываются. Железячники нашли компромисс в виде 32 и 64 бит и объявили их стандартом. Они бы могли сделать числа больше, но тогда частота процессоров бы снизилась.
- Принципиально большие числа не решают проблему. Так как у математиков числа бесконечные к примеру корень(2), а в компьютере все числа ограниченны. Поэтому ошибки будут всегда. И большие числа не делают ошибки реже, они просто происходят на других входных данных.
- Использовать числа с переменной длиной тоже не выход. Так как алгоритм удвоения длины после каждой операции приводит к тому что через 32-35 операций вся память закончиться.

Вот и приходиться программистам думать как гарантировать точность. В принципе можно подобрать нужный алгоритм который гарантирует заданную точность.

В общем, главное гарантия - что конкретно этот знак результата верный. Она есть?

После каждой операции результат округляется усекается до 64 бит. Отсюда всегда будут ошибки. Так что тут либо смериться либо бороться.
А способ борьбы зависит от конкретной задачи. Это как соревнования щита и копья.

- Матрицы: оценка точности через число обусловленности; Смена алгоритма к примеру с Гаусса на SVD.
- Финансовые вычисления: делаются в СУБД с поддержкой целых чисел или с фиксированной точки.
- ЦОС: Разложение фильтра идёт на чётные степени.
- Геометрия: сравнение идёт с допуском.
- Статистика: суммирования ведут от малых чисел к большим.
- Математика: вычисление гипотенузы делают через деление.
и тд.

[vinniepooh]

Сейчас же ноутбуки и сервера довольно мощные и памяти много.
Реально вычислять на PHP с точностью 7-15 знаков промежуточные результаты, чтобы конечный результат был хорошим?
Вот возьмём сервер 4-8 GB RAM и 4-ядерный процессор. Сколько реально знаков там будет правильных у функций типа синуса и т.п.?

BCMath - хорошее расширение. 4-8 ГБ должно хватить реально, чтобы считать с приемлемой точностью.

Вот возьмём 3.787*4.39381234567 - сколько реально будет верных знаков здесь?
Также 3.787+4.39381234567, 3.787/4.39381234567 и SIN(3.787*4.39381234567).

[Arigato]

Зачем вам такая точность в знаках после точки? Это разве что для каких-то научных вычислений может пригодится.

[vinniepooh]

Может и не научные, но вычисления деревянных домов. Там если обвалится, будет не до смеха...

[Serge_Bliznykov]

Может и не научные, но вычисления деревянных домов.

тю на Вас.
берите размеры в миллиметрах. тогда два знака после запятой (одна сотая миллиметра) - эта точность, которую Вам не даст НИ ОДИН строительный измерительный прибор. Посмотрите, например, допуски при строительстве, линейный допуск 1-го класса точности (самый высокий), при длинах до 20 мм составляет 0.24 мм, при больших длинах допуск увеличивается, разумеется).
А в промежуточных вычислениях используйте 8-9 знаков после запятой, чтобы гарантировать отсутствие потери точности до 5-6 знаков.
Всё. Большая точность Вам не нужна.
Как избежать потерю точности - см. пост #6

p.s. никому не нужно точность в 15 знаков после запятой в указании длины конструкции. Откройте таблицу с размерами атома. Вы удивитесь, но размер атома аллюминия, например, имеет размер 0.000000118 мм (это 9 знаков после запятой), Вам нужна большая точность, чем размер атома?! Нанотехнологии в строительстве на марше?!