КАТАСТРОФА С ОКРУГЛЕНИЕМ !!! :(

← →
cutter-pro (2002-08-22 14:19) [0]

Delphi округляет 1.5, 3.5, ... т.е. нечет перед запятой соот.
до 2, 4, ...
а 2.5, 4.5, ... т.е. чет перед запятой соот. до 2, 4, ...
В программе, над которой я сейчас работаю, просчет должен идти
согласно бухгалтерским расчетам, т.е.
1.5, 2.5, 3.5, 4.5, ... должны соот. округляться до 2, 3, 4, 5
Согласен, можно написать свою собственную процедуру, но, все же,
интересно услышать мнение остальных на этот счет!

← →
MBo (2002-08-22 14:24) [1]

1. Так и положено и документировано
2. Пиши

← →
McSimm (2002-08-22 14:33) [2]

Trunc(X + 0.5)

← →
Ekaterina (2002-08-22 14:36) [3]

SimpleRoundTo

← →
cutter-pro (2002-08-22 15:41) [4]

ОГРОМНОЕ СПАСИБО!!! ОСОБЕННО Екатерине!!! ;)

← →
DiamondShark (2002-08-23 14:04) [5]

Э, нет. Бухгалтерским называется именно первый метод, т.е. вот такой:

1.5 -> 2 3.5 -> 4 2.5 -> 2 4.5 -> 4

Почему? Обясняю.

Рассмотрим набор чисел

1.0 1.0 0 1.1 1.0 -0.1 1.2 1.0 -0.2 1.3 1.0 -0.3 1.4 1.0 -0.4 1.5 ??? ???? 1.6 2.0 +0.4 1.7 2.0 +0.3 1.8 2.0 +0.2 1.9 2.0 +0.1 2.0 2.0 0

Первый столбец -- точное число, второй -- округление, третий -- абсолютная ошибка. Легко заметить, что абсолютная ошибка зависит только от значности округления и не зависит от абсолютной величины числа.

А теперь представим, что нам надо считать сумму большого количества чисел, с распределением близким к равномерному, как обычно происходит на бухгалтерских счетАх.
Как видно, все погрешности (кроме 1.5 !) взаимно компенсируются (распределение равномерное). Если мы будем округлять Х.5 -> (X+1).0 или до (Х-1).0, то будет накапливаться систематическая ошибка.
Давайте прикинем, какого значения она может достичь.
Пусть N -- общее количество чисел.
Распределение близкое к равномерному, поэтому вероятность появления числа вида Х.5 -- 0.1
Абсолютная ошибка -- 0.5
Тогда мат. ожидание абсолютной ошибки суммирования N чисел N * 0.1 * 0.5 = N * 0.05

При суммировании к примеру 1000 значений с округлением до целого абсолютная погрешность может достигать 50.

Выход -- внести симметрию в вышеприведенную таблицу. Это и достигается округлением четных и нечетных чисел в разные стороны.

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

Вот пример: сумма чисел

точно | бухгалтерский | арифметический 1.5 2.0 2.0 3.5 4.0 4.0 2.5 2.0 3.0 4.5 4.0 5.0 ---- ----- ----- 12.0 12.0 14.0

Вопросы есть?

PS
кстати, в математическом сопроцессоре есть флажок, управляющий режимом округления (бухгалтерский или арифметический)

← →
Толик (2002-08-23 14:28) [6]

DiamondShark © (23.08.02 14:04) - 5 баллов!!!

← →
VICTOR_ (2002-08-23 15:42) [7]

>DiamondShark © (23.08.02 14:04)
Вопросы есть.
В первый раз слышу, чтобы в бухгалтерии округление зависело от четности или нечетности числа
:(((
Если это так, то
1)дай хоть одну ссылку на официальный документ
2)ссылку на пользователей, которые ведут такой учет
А то выходит, что несколько тысяч пользователей нашей программы
ведут ошибочно бухгалтерию

Всегда было
0,005 -> 0,01
0,015 -> 0,02
и т.д.
(если брать копейки)

← →
DiamondShark (2002-08-24 12:56) [8]

> VICTOR_ (23.08.02 15:42)
> >DiamondShark © (23.08.02 14:04)
> Вопросы есть.
> В первый раз слышу, чтобы в бухгалтерии округление зависело
> от четности или нечетности числа
> :(((

Все что мы знаем, мы когда-то услышали в первый раз ;)

> Если это так, то
> 1)дай хоть одну ссылку на официальный документ

Это конечно не официальный документ, но все же DiamondShark © (23.08.02 14:04) ;)
А если серьезно, то Национальный Стандарт бухгалтерского учета республики Молдова. Если очень надо, то могу найти (на память не помню) номер европейского стандарта, с которого его слизали.

А для своей страны вы сами должны стандарты знать.

> 2)ссылку на пользователей, которые ведут такой учет

http://delphi.mastak.ru/cgi-bin/anketa.pl?id=1025205444

> А то выходит, что несколько тысяч пользователей нашей программы
> ведут ошибочно бухгалтерию

Пользователи-то как-раз ни при чем ;)

> Всегда было
> 0,005 -> 0,01
> 0,015 -> 0,02
> и т.д.
> (если брать копейки)

И как результат -- систематическая ошибка.

0.005 + 0.015 = 0.020 -- точно
0.010 + 0.020 = 0.030 -- арифметический
0.010 + 0.010 = 0.020 -- бухгалтерский

Выберите варианты, наиболее точно, по-вашему, отражающие действительность.

Я же дал и обоснование и пример. Повторить что-ли?

← →
VICTOR_ (2002-08-27 11:08) [9]

>DiamondShark © (24.08.02 12:56)
Спасибо за детальное разъяснение.

>Выберите варианты, наиболее точно, по-вашему, отражающие >действительность.
Я выбираю вариант
0.010 + 0.020 = 0.030 -- арифметический
:)
+ округление цен до 5 знаков после запятой
+ округление сумм до 2 знаков после запятой

>А если серьезно, то Национальный Стандарт бухгалтерского учета >республики Молдова. Если очень надо, то могу найти (на память >не помню) номер европейского стандарта, с которого его слизали.
Надо почитать и свои стандатры, а вдруг я тоже отстал от жизни
:(((

КАТАСТРОФА С ОКРУГЛЕНИЕМ !!! :( Найти похожие ветки