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

[Andkorol]

Сообщение от vinniepooh

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

Деревянный дом обвалится из-за неточности в 7-м знаке после запятой?
В таких вещах желательно всё-же понимать разумный баланс между точностью вычислений размеров – и возможностями современного строительного оборудования + человеческий фактор.
Ибо можно хоть убиться, вычисляя с офигенной точностью длину стены в 10.39381234567м – но по факту в лучшем случае запилят 10.4м, и все дела.
Потому, что это – обычная практичность и здравый смысл.
Я уж и не говорю о требованиях всяких СНиП и прочих технических и разрешительных документов – где все эти вещи строго регламентированы, и всякая лишняя заумь просто запрещена.

Сообщение от vinniepooh

mysql> SELECT TRUNCATE(10.28*100,0);
-> 1027

PHP код:

Server version: 5.6.19 MySQL Community Server (GPL)

mysql> SELECT TRUNCATE(10.28*100,0);
+-----------------------+
| TRUNCATE(10.28*100,0) |
+-----------------------+
|                  1028 |
+-----------------------+
1 row in set (0.01 sec) 


С точностью вроде всё ОК.

[vinniepooh]

Может быть, новые версии MySQL уже лучше считают. Это было в руководстве к 4.0.17. Однако важен сам факт наличия такой проблемы. Вот из той же статьи по плав. точке - там пишут, что якобы уже совершенно всё.
А в доках по PHP - примеры всё-таки есть.

А если, к примеру, запилят до 10.42 - и накопленные ошибки либо полученные при округлении дадут нам неверно толщину стены? Я не говорю, что именно толщина такая должна быть. Пусть это будет какое-то промежуточное значение - синус или что-то ещё. Вес и т.п.

Перестраховаться, конечно, лучше - хотя нормам надо соответствовать. Просто примеры 8-6.4 из http://php.net/manual/en/language.types.float.php не дают покоя. 1028 посчитало, а еще что-то может и не посчитать. Кто же будет виноват? )

[vinniepooh]

Отыскал на странице относительную точность 1.11е-16. Это точность представления? Т.е., реальное число в компьютере принимает вид типа Дабл с ошибкой такой. Так?

А что касается мат. операций - они тоже все вызывают погрешности? Или только те, которые вынуждают округлять (есть список?)?

Возьмём того же рода пример: 1.123+1.1234567890123.

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

Если для одной операции будет 1.11е-16 погрешность результата, то общую можно оценить как число операций * 1.11е-16. Вроде бы логично.

А вот для неэлементарных мат. операций - на странице PHP.NET не видно, какая же погрешность. Это можно поискать, но, может, кто-то знает?

Собственно, это и есть главный вопрос. После вычислений получим тип Дабл - и какая же погрешность будет у результата (в процессе могут быть и округления, и сами операции что-то давать могут ).

[Arigato]

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

[ADSoft]

может немного не в тему.... но мне кажется автор путает понятие типа в MySQL и в PHP приводя пример именно в запросе к БД... (а это разные вещи).

В PHP принято называть - Числа с плавающей точкой (Float) . http://www.php.su/learnphp/datatypes/?float тут расписано что и как. Так что по сути тут два раза погрешность срабатывает - и в БД и в самом PHP.

Действительно, как сказано выше - для большинства стандартных вещей хватает такой точности. Если не хватает используйте спец модули и типы PHP, используйте соотв тип и в MySQL. Иначе - нечего заморачиваться с потерей цифры где то там в 14 разряде

[vinniepooh]

Всем удачного дня.

"В частности это означает, что никто не даст вам гарантию на определенное число знаков после точки".
В документации говорится про макс. ошибку в виде 1.11е-16. Что же это значит тогда? Гарантия нужна.

Вот вернёт программа результат в виде числа типа Double var_dump($x) $x=3.747. Как его предъявишь заказчику - это насколько точно посчитано? Сколько верных знаков и т.п.

[vinniepooh]

А в промежуточных вычислениях используйте 8-9 знаков после запятой, чтобы гарантировать отсутствие потери точности до 5-6 знаков.
Всё. Большая точность Вам не нужна.

Благодарен за помощь.

Вопрос: как это лучше реализовать с типом Дабл?
(BCMath кажется более защищённым от этих проблем)
Вот объявили $x=1.234 к примеру. Значит ли это, что внутреннее представление числа будет в худшем случае с погрешностью 1.11е-16? Как я понял, некоторые числа точно представимы, а некоторые типа 0.7 нет (как указано в доках).

А что касается подсчёта: $y=f($x);

PHP код:

function f($x)
{
$y=$x*1.58+7.77*sin($x)-3.14*sqrt($x);
return $y;
}; 


мне погрешность операций придётся самому считать?
Как доказать, что именно с 8-9 знаками надо считать, чтобы не было "потери точности до 5-6 знаков.". А если формулы сложные будут?

Просто я основательно разбираюсь, так что вопросы вполне логичные.

[vinniepooh]

3. Если числа будут из базы - то накопление доп. ошибки из-за FLOAT MySQL уж никак не впечатляет

[vinniepooh]

4. PHP.SU

вещественное число довольно большой точности (ее должно хватить для подавляющего большинства математических вычислений).

При каких условиях? Какой сложности функции возможны для вычисления с гарантированной точностью в N знаков?

ошибки при использовании типа Дабл от мат. операций тоже накапливаются? как их учесть?

[vinniepooh]

Доброго дня!