Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2002.04.22;
Скачать: CL | DM;

Вниз

Потеря 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 вся ветка

Текущий архив: 2002.04.22;
Скачать: CL | DM;

Наверх




Память: 0.48 MB
Время: 0.013 c
1-69810
VictorT
2002-04-09 17:47
2002.04.22
Консольное приложение


1-69860
BorisMor
2002-04-08 17:46
2002.04.22
Передача пути.


1-69897
ymin
2002-04-09 13:56
2002.04.22
Есть ли Help в минимальной установке Delphi 6?


1-69795
User_OKA
2002-04-10 14:48
2002.04.22
Help!!! Защита!!!


3-69713
oss
2002-03-29 12:03
2002.04.22
ADO login в mssql как ?