Подсчет суммы в таблице (неверно считает)

@FreeWay · Регистрация: 17.12.2007

Студворк — интернет-сервис помощи студентам

Всем привет, наткнулся на не понятную проблему.
У меня есть таблица (файл dbf), по определенному полю мне надо подбить сумму, делаю это таким кодом:

C++
1
2
3
4
5
6
7
8
9
10
11
12
   int n=2;
   String FieldName = DBGrid1->SelectedField->FieldName;
   float sum=0;
   Table1->First();
   while (!Table1->Eof)
   {
    sum=sum+Table1->FieldByName(FieldName)->AsFloat;
    Table1->Next();
   }
 
   LabelSum->Caption=FloatToStrF(sum,ffNumber,8,2)+" Грн";
   LabelCout->Caption=IntToStr(Table1->RecordCount)+" Строк";

работаю через BDE
проблема в том, что сумма хоть и редко, но бывает от одной до нескольких копеек не идет с реальной суммой. Если открыть дбф файл в экселе и подбить сумму, то он правильно суммирует.
Я так понимаю проблема в округлении, вернее в его отсутствии. Пробую такое округление -

C++
1
2
3
4
5
6
7
8
9
10
11
12
int n=2;
   String FieldName = DBGrid1->SelectedField->FieldName;
   float sum=0;
   Table1->First();
   while (!Table1->Eof)
   {
    sum=sum+Table1->FieldByName(FieldName)->AsFloat;
   [COLOR=red] sum=floor(sum*pow10(n)+0.5)*pow10(-n);[/COLOR]
    Table1->Next();
   }
LabelSum->Caption=FloatToStrF(sum,ffNumber,8,2)+" Ãðí.";
   LabelCout->Caption=IntToStr(Table1->RecordCount)+" ñòðîê";

но с ним несоответствие с реальной суммой выростает(
Подскажите как это правильно решить?

@Lord_Voodoo · 06.01.2009, 23:50

вот код математического округления:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
double MathRound(double num, int precision)
{
  AnsiString s, number = FloatToStr(num);
  bool sign = false;
  double k;
  int pos = number.Pos('.');
  int len = number.Length();
  if ((pos == 0) || ((len - pos) <= precision)) return num;
  AnsiString prom = number.SubString(1, 1);
  if (prom == '-') sign = true;
  s = number.SubString(pos+precision+1, 1);
  int i = StrToInt(s);
  if (i >= 5){
   if (sign)
     k = floor(num*Power(10, precision))/Power(10, precision);
   else
     k = ceil(num*Power(10, precision))/Power(10, precision);
  }else{
   if (!sign)
     k = floor(num*Power(10, precision))/Power(10, precision);
   else
     k = ceil(num*Power(10, precision))/Power(10, precision);
  }
  return k;
}

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

@FreeWay · 07.01.2009, 08:56 **[ТС]**

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

вот код математического округления:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
double MathRound(double num, int precision)
{
  AnsiString s, number = FloatToStr(num);
  bool sign = false;
  double k;
  int pos = number.Pos('.');
  int len = number.Length();
  if ((pos == 0) || ((len - pos) <= precision)) return num;
  AnsiString prom = number.SubString(1, 1);
  if (prom == '-') sign = true;
  s = number.SubString(pos+precision+1, 1);
  int i = StrToInt(s);
  if (i >= 5){
   if (sign)
     k = floor(num*Power(10, precision))/Power(10, precision);
   else
     k = ceil(num*Power(10, precision))/Power(10, precision);
  }else{
   if (!sign)
     k = floor(num*Power(10, precision))/Power(10, precision);
   else
     k = ceil(num*Power(10, precision))/Power(10, precision);
  }
  return k;
}

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

не прикольно, значит я не добьюсь точной суммы?

@FreeWay · 07.01.2009, 09:33 **[ТС]**

попробовал скулом:

C++
1
2
3
4
Query->Close();
Query->SQL->Clear();
Query->SQL->Text=("Select SUM (SUMA) AS Result FROM CARDw");
Query->Open();

посчитал правильно))) Значит у него какой то правильный округлитель встроенный)))

@Lord_Voodoo · 07.01.2009, 11:19

FreeWay, к сожалению, это обусловлено именно математическими причинами, хотя существует систем 6 бухгалтерских округлений... и вообще повысь точность расчетов, т.е. веди расчеты ну с 3-4 знаками после запятой и округление производи только уже при выводе на экран... а вот функция работает точно проверено на коммерческом софте с требовательностью к точности расчетов... покрути ее... и вообще у меня отдел бухгалтерии разрешает погрешность 5 копов...

так в билдере нет математического округления, только до верхенго или нижнего числа, а sql считает с математическим округлением... только будут ситуации, где тебе не получится проскочить мимо округлений отдельных сумм и округлением общей суммы...

@FreeWay · 07.01.2009, 13:01 **[ТС]**

мне напарник подсчитал сумму в визуал бейсике, у него есть встроенный тип currency, так у него сразу подсчитаолсь правильно.
Я вот думаю на си шарп переходить, там есть тип decimal специально для точных расчетов)

@Lord_Voodoo · 07.01.2009, 14:10

я не проверял, конечно, бейсик на работу с округлениями... но у меня с балансом вечная проблема, чтобы сумма общая совпадала с суммой получаемой из сумм по статьям, хотя между прочим исходные данные одинаковые, только пдв в 20% делает с расчетами чудеса... хотя попробуй, и если у тебя бейсик справится, то и я перейду туда, надоело сводить по 10 копеек каждый месяц

@FreeWay · 07.01.2009, 19:57 **[ТС]**

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

я не проверял, конечно, бейсик на работу с округлениями... но у меня с балансом вечная проблема, чтобы сумма общая совпадала с суммой получаемой из сумм по статьям, хотя между прочим исходные данные одинаковые, только пдв в 20% делает с расчетами чудеса... хотя попробуй, и если у тебя бейсик справится, то и я перейду туда, надоело сводить по 10 копеек каждый месяц

неееее на бейсик я не перейду, зачем идти назад). Я буду переходить на cи шарп

вот еще подсказали:

Я бы сделал int sum. А те числа float, которые ты читаешь из файла умножать на 100 и приплюсовывать к sum. Тогда в sum будет целое число копеек и никаких округлений. А чтобы получить результат, надо полученное число поместить в переменную float и поделить на 100.

@Lord_Voodoo · 08.01.2009, 00:10

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

Новые блоги и статьи Все статьи Все блоги /
Оттенки серого Argus19 18.03.2026 Оттенки серого Нашёл в интернете 3 прекрасных модуля: Модуль класса открытия диалога открытия/ сохранения файла на Win32 API; Модуль класса быстрого перекодирования цветного изображения в оттенки. . .	SDL3 для Desktop (MinGW): Рисуем цветные прямоугольники с помощью рисовальщика SDL3 на Си и C++ 8Observer8 17.03.2026 Содержание блога Финальные проекты на Си и на C++: finish-rectangles-sdl3-c. zip finish-rectangles-sdl3-cpp. zip	Символические и жёсткие ссылки в Linux. algri14 15.03.2026 Существует два типа ссылок — символические и жёсткие. Ссылка в Linux — это запись в каталоге, которая может указывать либо на inode «файла-ИСТОЧНИКА», тогда это будет «жёсткая ссылка» (hard link),. . .	[Owen Logic] Поддержание уровня воды в резервуаре количеством включённых насосов: моделирование и выбор регулятора ФедосеевПавел 14.03.2026 Поддержание уровня воды в резервуаре количеством включённых насосов: моделирование и выбор регулятора ВВЕДЕНИЕ Выполняя задание на управление насосной группой заполнения резервуара,. . .
делаю науч статью по влиянию грибов на сукцессию anaschu 13.03.2026 прикрепляю статью	SDL3 для Desktop (MinGW): Создаём пустое окно с нуля для 2D-графики на SDL3, Си и C++ 8Observer8 10.03.2026 Содержание блога Финальные проекты на Си и на C++: hello-sdl3-c. zip hello-sdl3-cpp. zip Результат:	Установка CMake и MinGW 13.1 для сборки С и C++ приложений из консоли и из Qt Creator в EXE 8Observer8 10.03.2026 Содержание блога MinGW - это коллекция инструментов для сборки приложений в EXE. CMake - это система сборки приложений. Здесь описаны базовые шаги для старта программирования с помощью CMake и. . .	Как дизайн сайта влияет на конверсию: 7 решений, которые реально повышают заявки Neotwalker 08.03.2026 Многие до сих пор воспринимают дизайн сайта как “красивую оболочку”. На практике всё иначе: дизайн напрямую влияет на то, оставит человек заявку или уйдёт через несколько секунд. Даже если у вас. . .

@Lord_Voodoo Почетный модератор 8785 / 2538 / 144 Регистрация: 07.03.2007 Сообщений: 11,873
	07.01.2009, 11:19
	FreeWay, к сожалению, это обусловлено именно математическими причинами, хотя существует систем 6 бухгалтерских округлений... и вообще повысь точность расчетов, т.е. веди расчеты ну с 3-4 знаками после запятой и округление производи только уже при выводе на экран... а вот функция работает точно проверено на коммерческом софте с требовательностью к точности расчетов... покрути ее... и вообще у меня отдел бухгалтерии разрешает погрешность 5 копов... так в билдере нет математического округления, только до верхенго или нижнего числа, а sql считает с математическим округлением... только будут ситуации, где тебе не получится проскочить мимо округлений отдельных сумм и округлением общей суммы... 0

@FreeWay 84 / 84 / 19 Регистрация: 17.12.2007 Сообщений: 574
	07.01.2009, 13:01 [ТС]
	мне напарник подсчитал сумму в визуал бейсике, у него есть встроенный тип currency, так у него сразу подсчитаолсь правильно. Я вот думаю на си шарп переходить, там есть тип decimal специально для точных расчетов) 0

@Lord_Voodoo Почетный модератор 8785 / 2538 / 144 Регистрация: 07.03.2007 Сообщений: 11,873
	07.01.2009, 14:10
	я не проверял, конечно, бейсик на работу с округлениями... но у меня с балансом вечная проблема, чтобы сумма общая совпадала с суммой получаемой из сумм по статьям, хотя между прочим исходные данные одинаковые, только пдв в 20% делает с расчетами чудеса... хотя попробуй, и если у тебя бейсик справится, то и я перейду туда, надоело сводить по 10 копеек каждый месяц 0

@Lord_Voodoo Почетный модератор 8785 / 2538 / 144 Регистрация: 07.03.2007 Сообщений: 11,873
	08.01.2009, 00:10
	я точность веду до трех знаков после запятой. а все равно перекосы есть... просто, будь простое решение, то не существовало бы кучи систем округлений... общзую сумму посчитать-то можно точно, но когда идет расписание, как она формировалась, тогда и начинается веселье... 0