Floating Point

← →
Begin (2005-10-25 16:51) [0]

Детский такой вопрос... :)
Проект много и плотно работает с дробными числами. Пользую Round, RoundTo, пару своих функций.

Однако. Расхождения в каком ни будь знаке после точки все равно иногда появляются. Дикое количество RoundTo по тексту тоже слегка напрягает.

Посему озадачился вопросом - можно ли как ни будь указать Delphi, что в проекте ВСЕ float-операции должно вести с точностью до второго, к примеру, знака после точки ?

Пытался искать в Compiler Directives... Не нашел... :)

← →
clickmaker © (2005-10-25 16:55) [1]

> Посему озадачился вопросом - можно ли как ни будь указать
> Delphi, что в проекте ВСЕ float-операции должно вести с
> точностью до второго, к примеру, знака после точки ?

достаточно выводить результаты с точностью до 2 знака. Расхождения-то вряд ли будут раньше...

← →
Begin (2005-10-25 16:58) [2]

clickmaker
> достаточно выводить результаты с точностью до 2 знака. Расхождения-
> то вряд ли будут раньше

Не... На 15-м шаге операции 0.2 копейки не отловленного вовремя расхождения превращаются в 3 целых копейки, что очень не гуд... :)

← →
umbra © (2005-10-25 17:10) [3]

не лучше ли пользоваться целыми числами?

← →
clickmaker © (2005-10-25 17:11) [4]

> 0.2 копейки не отловленного вовремя расхождения

это если в рублях, то 0.002 руб. Да неужто такая погрешность у типа double? не верицца

← →
Begin (2005-10-25 17:48) [5]

> umbra © (25.10.05 17:10) [3]
> не лучше ли пользоваться целыми числами?

Не получится... Копейки надо... :)

> clickmaker © (25.10.05 17:11) [4]
>
> > 0.2 копейки не отловленного вовремя расхождения
>
> это если в рублях, то 0.002 руб. Да неужто такая погрешность
> у типа double? не верицца

Не Double, а Currency. И не погрешность, а точность. :)
Но не в ней дело. К примеру: сумма комиссии вычисляется с использованием 4-х различных коэффициэнтов. Каждый из них, будучи типа Extended, при делении одного на другой, вычисляется до не-считал-какого знака после запятой. Но сильно больше 2-х.

Потом, после применения оных коэффициентов к переменным с деньгами, добрый Currency сохраняет значения до 4-го знака. Приходится везде пользовать RoundTo.

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

Да, к стати. А по существу вопроса есть чего сказать ? :)

← →
clickmaker © (2005-10-25 17:52) [6]

> приходится втыкать RoundTo, иначе вероятность возникновения
> расхождений в 1-2 копейки выростает оч. сильно.

а тебе не кажецца, что расхождение возникает именно из-за "втыкания" RoundTo?
не лучше ли посчитать все как есть (кстати, а зачем тебе Currency? тот же Extended подойдет), а потом округлить, когда тебя надо показать результат

← →
TUser © (2005-10-25 17:59) [7]

Я сейчас буду переходить плавно на использование целых чисел вместо fp. Если вычислений много, то это сильно ускоряет, и много где именно так все и реализовано - исходные данные переводятся в integer с заданной точностью, дальше используются + - * div mod shr shl power и целочисленное извлечение корня. ничего больше. Результат вычислений переводится в float, если это требуется.

← →
Defunct © (2005-10-25 19:36) [8]

TUser © (25.10.05 17:59) [7]

хм.. даже на вычислениях обдирают...
самый верный способ imho - [6], надо не "обрезание" числам делать, а наоборот мантиссу расширять, и округлять лишь только перед выводом на экран.

> Если вычислений много, то это сильно ускоряет

SSE2 тоже ускоряет неслабо, без потерь точности...

← →
umbra © (2005-10-25 19:45) [9]

> Не получится... Копейки надо...

Всегда можно в конце разделить на 100

← →
umbra © (2005-10-25 19:56) [10]

2 Begin (25.10.05 17:48) [5]

Просто я читал такую же дискуссию в перловском листе рассылки (точнее, дискуссия была о сложностях при сравнении чисел с плавающей точкой) и тамошние киты настоятельно рекомендовали все денежные расчеты проводить в целых числах. Оно и понятно - как указал TUser © - никаких проблем с точностью и выигрыш в скорости.

← →
AlexWlad © (2005-10-25 20:01) [11]

> Begin (25.10.05 17:48) [5]
>
> Но не в ней дело. К примеру: сумма комиссии вычисляется
> с использованием 4-х различных коэффициэнтов. Каждый из
> них, будучи типа Extended, при делении одного на другой,
> вычисляется до не-считал-какого знака после запятой. Но
> сильно больше 2-х.

Плохо, когда сначала делятся маленькие числа, а потом идет умножение. Лучше первое делимое сразу умножить, а потом делить на оставшиеся.

← →
Anatoly Podgoretsky © (2005-10-25 20:08) [12]

umbra © (25.10.05 19:56) [10]
Ой ли, а делить то как будешь, с точность до копейки, а потом умножать.
Не все так прекрасно с целыми. А вот поддержки подлинных чисел с фиксированой запятой так и нет. А ведь у них была технология от Ashton Tate, потеряли наверно.

← →
umbra © (2005-10-25 20:14) [13]

> а делить то как будешь, с точность до копейки, а потом умножать

Немного не понял. Что делить, и что умножать? Можно целые брать с количеством знаков, соттветстсвующим одной десятитысячной копейки. И при этом они будут целыми. Делить - это я имел в виду, когда пользователю показывать.

Ну например есть стоимость партии и количество, надо вычислить цену штуки. Цена будет в копейках .ххххх, если сохранить результат деления до копейки, то будут большие финансовые потери.

> Не получится... Копейки надо... :)

Считать можно и целыми (вместо 0.02 - 2, а рубль - 100). Если результат нужно выводить дробью, при выводе раздели число на 100. Вот и все :)

P.S. Delphi не очень хорошо считает числа с плавающей точкой - порок компилятора :)

← →
end (2005-10-25 23:16) [17]

Лучше жевать, чем задавать вопросы. Лучше делом заниматься, чем больтать ерундой.
Как лохов, товарищ всех развел.

> хм.. даже на вычислениях обдирают...

Обдирают на том, что критично. Если основная задача программы - дать результат вычислений, то будет оптимизировать вычисления. Чтобы не за 25 лет, а через 48 часов.

Не, ну я в данной сфере не имею никакого опыта:(
Но по чтению, опыт есть! И он гласит, что бухгалтерия и математика - есть вещи не совместные!. Имхо.

Floating Point Найти похожие ветки