Потеря 1-4 коп. при суммировании чисел из базы даных

← →
Viktor Erko (2002-03-30 10:27) [0]

Проблема возникла при суммировании 6000 чисел типа 9999999,99. которые
находятся в базе dbf. В переменных isuma и GSUMA сума оказывалась на 1-4
копейки меньше или больше от суммы полученой другими методами.
Подскажите причину не правильного суммирования.
Var
isuma, GSUMA, tmpsuma:currency;
.......
GSUMA:=0.00;
isuma:=0.00;

........
tmpsuma:=Datamodule2.Work.FieldByName("APEN").Ascurrency;
isuma:=isuma+tmpsuma;
.....

GSUMA:=GSUMA+isuma;
....
outstring:=Floattostrf(GSUMA,ffFixed,6,2);

← →
Anatoly Podgoretsky (2002-03-30 12:38) [1]

Float не предназначен для выполнения точных вычислений.

← →
VAleksey (2002-03-30 17:04) [2]

Нет ну а че ты хотел ?
По моему это вообще проблема для dBase. Лично я стал использовать парадокс и вообще округлением не занимался и все всегда стало сходится

← →
sniknik (2002-03-30 18:14) [3]

Это не проблема отдельной базы а округлений вообще. есть разные типs округлений, метематическое (знакомо с детства со школьной парты) а есть бухгалтерское (забавное и трудное для понимания :) 1С-ники с ним знакомы.
Но одно из бухгалтерских требований вполне законно (логично по крайней мере), суммируются те суммы которые в отчете на бумаге. Если суммируемые значения сами являются вычисляемыми значениями то должны быть округлены до знака при печати.
Не слишком мутно?
Проще. Перед операцией делай Trunc(tmpsuma*100)/100, чтобы откинуть знаки за "кадром". Например что будет если сложить 200 раз число 5,21008? И не думай что такого не может (типа тип currency и т.д), попробуй может получится. Хотя чтобы полностью избавится от таких нестыковок мне в свое время пришлось сумму в стринге хранить.

← →
Anatoly Podgoretsky (2002-03-30 18:32) [4]

VAleksey (30.03.02 17:04)
Это не проблема dBase IV и ниже они нормально работают так как используют BCD, а проблема Борланда

sniknik © (30.03.02 18:14)
Trunc(tmpsuma*100)/100 это поможет только в огранченном количестве случаев, так проблема лежит в области представления чисел с плавающей запятой, не все числа возможно представить точно, яркий представитель число 0.02
Казалось бы выход в Integer, но Борланд преобразовывает большие числв в Double при считывании из поля.

BCD пока поддержан в Д6 и как я понимаю ограничено.

← →
Viktor Erko (2002-03-31 19:07) [5]

Cпасибо Всем !!!

Причиной потери копеек была не верная работа функции Floattostrf(GSUMA,ffFixed,6,2) число 10428.32 переводилось в символьный формат в виде 10428.30 ( BORLAND !!!??). После замены на функцию STR(gsuma:6:2,outstring) все проблемы с округлением исчезли надеюсть полностью.

← →
sniknik (2002-04-01 09:04) [6]

вот так будет правильно Floattostrf(10428.32,ffFixed,7,2) (догадайся почему). и нечего на BORLAND валить если у сам .....

← →
Anatoly Podgoretsky (2002-04-01 11:55) [7]

бен ладен

Потеря 1-4 коп. при суммировании чисел из базы даных Найти похожие ветки