Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Потеря 1-4 коп. при суммировании чисел из базы даных [D3, dBase, FoxPro, Paradox]

Viktor Erko © (2002-03-30 10:27:00)
Проблема возникла при суммировании 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-04-01 11:55:00) [1]
бен ладен

sniknik (2002-04-01 09:04:00) [2]
вот так будет правильно Floattostrf(10428.32,ffFixed,7,2) (догадайся почему). и нечего на BORLAND валить если у сам .....

Viktor Erko (2002-03-31 19:07:00) [3]
Cпасибо Всем !!!

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

Anatoly Podgoretsky (2002-03-30 18:32:00) [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 и как я понимаю ограничено.

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

VAleksey (2002-03-30 17:04:00) [6]
Нет ну а че ты хотел ?
По моему это вообще проблема для dBase. Лично я стал использовать парадокс и вообще округлением не занимался и все всегда стало сходится

Anatoly Podgoretsky (2002-03-30 12:38:00) [7]
Float не предназначен для выполнения точных вычислений.

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »