Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / PowerBuilder [игнор отключен] [закрыт для гостей] / Бухгалтерское округление / 25 сообщений из 38, страница 1 из 2
30.03.2007, 09:45
    #34426488
PavelBuilder
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бухгалтерское округление
Напомню правило, а то многие путают его с правилом арифметического округления:
цифра перед пятеркой — если она четная, то округление вниз, иначе вверх. Это правило и называется правилом "Бухгалтерского" (или "Банковского") округления.

Собственно все это нужно для отчетности, если кто занимался подобным расскажите. Хотелось такую функцию на клиенте и/или на сервере (MS SQL 2000)

Меня этьо уже окончательно припаририло, Excel не умеет работать с числами больше 15 знаков, formula one то же имеет проблемы с округлением. Вобщем различное представление чисел в разных программах и механизмы реализации опереций с ними настолько разные, что посчитать что либо точно очень сложно. Клиенты получая отчеты нередко выгружают их в Excel чтобы сделать какие то выкладки и прочие рассчеты. Да и сами отчеты того же Билдера тоже надо считать правильно, а тут когда цифры захшкаливают за милиарды ... возникают странные вещи, например откуда не возьмись появляется 2 -ка в пятом знаке после запятой, ее удаляешь сохранешь, вроде пропадает. Собственно вопрос: есть ли в билдере или масдае, другие способы ркругления кроме арифметического. понятно что можно написать самому, но боюсь при больших выборках накладные расходы на вызов сильно снизят производительность.
...
Рейтинг: 0 / 0
30.03.2007, 13:00
    #34427241
PavelBuilder
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бухгалтерское округление
Теоретические правила просты:
1. промежуточные вычисления проводить с избыточной точностью (N+1)
2. промежуточные округления делать по бухгалтерскому правилу "ROUND HALF EVEN"
3. При любых операциях двух чисел оба должны быть округлены с точностью равной наименьшей точности чисел до самой операции (например если одно число с точностью до 2-ого знака, а другое до 4-ого, то последнее округляется до 2-ого)
4. итоговое число округляется по арифметическому правилу ... в пользу государства :)

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

Вобщем у меня сошлось ... теперь будем писать документ, согласно которому в организации будут производится округления.

Вот функция для MS SQL 2000 может кому пригодится:
Код: plaintext
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.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
IF OBJECT_ID('ROUND_HALF_EVEN') IS NOT NULL
    DROP FUNCTION ROUND_HALF_EVEN
GO

/*******************************************************************************
 *  PROCEDURE:
 *
 *  ARGUMENTS: @var  - число типа DECIMAL
 *             @pr   - точность (до какого знака после запятой)
 *
 *  RETURNS: округленное число 
 *
 *  LANGUAGE:   T-SQL
 *
 *  DESCRIPTION:  Функция округления по правилу "Бухгалтерского" (или "Банковского") округления.
 *  Правило: цифра перед пятеркой — если она четная, то округление вниз, иначе вверх.
 *  Так как числа достаточно случайны, то появление четных и нечетных цифр перед
 *  пятеркой равновероятно, алгоритм же арифметического округления нарушает "равновероятность",
 *  накапливается статистическая погрешность и
 *  " итог 'К выдаче' вновь окажется больше, чем 'Заработано' "
 *
 *******************************************************************************
 *  ИСТОРИЯ
 *******************************************************************************
 *  30/03/07  - pv    Создана
 *
 ******************************************************************************/
CREATE FUNCTION ROUND_HALF_EVEN (
  @var        DECIMAL( 20 , 8 ),
  @pr  SMALLINT
)
RETURNS DECIMAL( 20 , 8 )
AS
BEGIN
RETURN CASE WHEN CONVERT(INT,(ROUND(@var, @pr+ 1  , 1 ) - ROUND(@var, @pr, 1 ) ) * POWER( 10 , @pr+ 1 )) =  5 
            THEN ROUND(@var,@pr, 1 )+ CONVERT(INT,( ROUND(@var,@pr, 1 ) - ROUND(@var,@pr- 1 , 1 ) ) * POWER( 10 ,@pr) )% 2  * (  1 . 0 /POWER( 10 ,@pr))
            ELSE ROUND(@var, @pr)
       END
END
...
Рейтинг: 0 / 0
30.03.2007, 14:04
    #34427522
Локшин Марк
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бухгалтерское округление
PavelBuilderДа и сами отчеты того же Билдера тоже надо считать правильно, а тут когда цифры захшкаливают за милиарды ... возникают странные вещи, например откуда не возьмись появляется 2 -ка в пятом знаке после запятой, ее удаляешь сохранешь, вроде пропадает.
А тип переменной какой?
...
Рейтинг: 0 / 0
30.03.2007, 14:14
    #34427555
Локшин Марк
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бухгалтерское округление
PavelBuilderТак как числа достаточно случайны, то появление четных и нечетных цифр перед
пятеркой равновероятно, алгоритм же арифметического округления нарушает "равновероятность",
накапливается статистическая погрешность и
" итог 'К выдаче' вновь окажется больше, чем 'Заработано' "
Код: plaintext
1.
 0 . 5   0 . 6   0 . 7   0 . 8   0 . 9   1 . 0 .  1 . 1   1 . 2   1 . 3   1 . 4  =  1  ( 10  штук)
 1 . 5   1 . 6   1 . 7   1 . 8   1 . 9   2 . 0 .  2 . 1   2 . 2   2 . 3   2 . 4  =  2  ( 10  штук) и т.д.
И чего нарушается-то?
...
Рейтинг: 0 / 0
30.03.2007, 15:05
    #34427743
PavelBuilder
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бухгалтерское округление
Локшин Марк PavelBuilderДа и сами отчеты того же Билдера тоже надо считать правильно, а тут когда цифры захшкаливают за милиарды ... возникают странные вещи, например откуда не возьмись появляется 2 -ка в пятом знаке после запятой, ее удаляешь сохранешь, вроде пропадает.
А тип переменной какой?

DECIMAL (20, 8) на сервере, ну и datawindow естествено с точностью до 8- го знака
...
Рейтинг: 0 / 0
30.03.2007, 15:11
    #34427762
Anatoly Moskovsky
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бухгалтерское округление
Локшин МаркИ чего нарушается-то?
Имеется в виду вот что:
Неокругл Арифм. округл Бух. округл.0.5 1.0 0.01.5 2.0 2.02.5 3.0 2.03.5 4.0 4.04.5 5.0 4.05.5 6.0 6.06.5 7.0 6.07.5 8.0 8.08.5 9.0 8.09.5 10.0 10.0 50.0 55.0 50

Другими словами, сумма неокругленных значений должна равняться сумме округленных.
...
Рейтинг: 0 / 0
30.03.2007, 15:15
    #34427783
PavelBuilder
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бухгалтерское округление
Локшин Марк PavelBuilderТак как числа достаточно случайны, то появление четных и нечетных цифр перед
пятеркой равновероятно, алгоритм же арифметического округления нарушает "равновероятность",
накапливается статистическая погрешность и
" итог 'К выдаче' вновь окажется больше, чем 'Заработано' "
Код: plaintext
1.
 0 . 5   0 . 6   0 . 7   0 . 8   0 . 9   1 . 0 .  1 . 1   1 . 2   1 . 3   1 . 4  =  1  ( 10  штук)
 1 . 5   1 . 6   1 . 7   1 . 8   1 . 9   2 . 0 .  2 . 1   2 . 2   2 . 3   2 . 4  =  2  ( 10  штук) и т.д.
И чего нарушается-то?

Чтобы понять в чем суть, нужно решить задачу: если трое договарились делить всю прибыль поровну, то как разделить 10 копеек среди них, кому отдать копейку? В рамках предприятия это вытекает в то, кому отдать 10 рублей 50 копеек на милион строк. Согласись нехило?
Алгоритм арифметического округления работает так, что в случае пятерки в разряде заданной точности предыдущий разряд увеличивает и это "правило" всегдла увеличивает итог(!) все другие числа находятся в равномерном распределении, так еденички компенсируются девятками (там где за счет девяток набежала еденица, в еденичках она не случилась и излишний хвостик пропал) 2-ки уравновешиваются 8-ми, 3-ки - 7-ми и т.д, а вот 5-ка вызывает перекос.
Примечательно, что почти ни одно средство разработки не обладате совершенным алгоритмом округления. Вообще это очень сложная задача, чтобы понимать ее банально.
...
Рейтинг: 0 / 0
30.03.2007, 15:20
    #34427805
Anatoly Moskovsky
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бухгалтерское округление
Anatoly MoskovskyДругими словами, сумма неокругленных значений должна равняться сумме округленных.
Правда бух. округление не гарантирует это, а только приближается к этому при случайном равномерном распределении цифр в выборке.
Вот простейший пример когда неравномерная выборка приводит к разнице (причем в арифм. смпособе тоже):
Неокругл Арифм. округл Бух. округл. 0.5 1.0 00.5 1.0 0 1.0 2.0 0.0
...
Рейтинг: 0 / 0
30.03.2007, 15:56
    #34427962
PavelBuilder
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бухгалтерское округление
Анатолий, спасибо за пример :)

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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
 0 	 98584 
 1 	 32419 
 2 	 34667 
 3 	 32455 
 4 	 34076 
 5 	 35160 
 6 	 34364 
 7 	 30882 
 8 	 34307 
 9 	 32797 
...
Рейтинг: 0 / 0
30.03.2007, 16:07
    #34427994
Anatoly Moskovsky
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бухгалтерское округление
PavelBuilderНасколько в данном случае корректно говорить о равномерном распределении?

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
 0 	 98584 
 1 	 32419 
 2 	 34667 
 3 	 32455 
 4 	 34076 
 5 	 35160 
 6 	 34364 
 7 	 30882 
 8 	 34307 
 9 	 32797 

Я предполагаю, что высокая частота 0 связана с преобладанием круглых сумм. Их нужно исключить из подсчета, поскольку они не влияют на округление (я бы вообще оставил только частоту цифр перед 5).
Если же в этих цифрах уже учтено сказанное выше, то налицо неравномерность - сумма округл (бух) будет меньше суммы неокругленных (при 0 - округление вниз).
...
Рейтинг: 0 / 0
30.03.2007, 17:23
    #34428270
Локшин Марк
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бухгалтерское округление
PavelBuilderвсе другие числа находятся в равномерном распределении, так еденички компенсируются девятками (там где за счет девяток набежала еденица, в еденичках она не случилась и излишний хвостик пропал) 2-ки уравновешиваются 8-ми, 3-ки - 7-ми и т.д, а вот 5-ка вызывает перекос.
Все равно я не понимаю эту "магию" цифр. Вот например, у нас есть числа от 0 до 1 с точностью 5 знаков, соответственно от 0 до 0.4999 - это 0, и от 0.5 до 1 - это 1 (округляя по правилам арифметического округления). Т.е. ровно по 5000 вариантов для 0 и 1. Если полагать, что число случайно, то оно с вероятностью ровно 0.5 округлится в 0, а с 0.5 в 1. Где здесь "перекос"?
...
Рейтинг: 0 / 0
30.03.2007, 20:06
    #34428718
Локшин Марк
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бухгалтерское округление
А вот "бухгалтерское" округление какраз вносит перекос в сторону 0.
...
Рейтинг: 0 / 0
31.03.2007, 00:55
    #34428918
18-я весна
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бухгалтерское округление
Локшин Марк Где здесь "перекос"?
А Вы мой первый пример рассмотрите :)
Там все ясно видно.

А насчет верояностей - ошибочка у Вас :)
Вниз округляются не 5 из 10, а 4 из 9. Вверх округляются не 5 из 10, а 5 из 9.
Вот и посчитайте вероятность.
...
Рейтинг: 0 / 0
01.04.2007, 13:12
    #34429706
Локшин Марк
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бухгалтерское округление
Anatoly MoskovskyА насчет верояностей - ошибочка у Вас :)
Да, забыл еще один вариант. :) В моем случае действительно получается для арифметического округления 5000/10001 - 0 5001/10001 - 1.
Но для бухгалтерского округления получается-то еще хуже!
Вероятность для 0 - 6001/10001 для 1 - 4000/10001.
Может быть неправильно реализовано округление?
Чему должно быть равно:
Код: plaintext
select dbo.ROUND_HALF_EVEN ( 0 . 5999 , 0 )
сейчас результат
Код: plaintext
. 00000000 
...
Рейтинг: 0 / 0
02.04.2007, 09:58
    #34430459
PavelBuilder
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бухгалтерское округление
Локшин Марк
Код: plaintext
select dbo.ROUND_HALF_EVEN ( 0 . 5999 , 0 )
сейчас результат
Код: plaintext
. 00000000 


Все правильно, округление до целого, число перед пятёркой 0 - нечетное - округление вниз.

А замечание на самом деле то же к месту, например, взгляните на эти числа:
1.295 может быть "внутренне" представленно как 1.29499999 или 1.29999

Все это я к тому, что не свосем корректно для вычисления на компе использовать при округлении накидиывания "единицы", тут нужно скорее для кадого софта (сервес базы данных, клиентское приложение) найти такое число назовем его "epsilon" и оно будет наименьшим для "1+epsilon <> 1"

Собственно в тупом переносе на "комп" алгоритма округдения, не учитывается внутренне представление чисел, мы не знаем по каким принципаммпроисходит та или иная операция и точность этой операции. Вобщем я порыл инет на предмет этой области и выяснил что есть некий человек John Herbster, который придумал самый эффективнй алгорим подобного округления, еслии интересно, вот ссылка http://cc.codegear.com/Item.aspx?id=21909
только надо зарегистрироваться. Там код на паскале ... к слову сказать понять что там может не каждый. Использовать код конечно можно, но переписав на С и скомпилировать этот код в DLL чтоб потом подлинковать к масдаевскому ядру ... насколько это нехорошо я понимаю, но представить накладные расходы на подобный код реализованный другим способом ... совсем неприемлимо, поскольку нужно то такое округление как раз на огромных выборках.

По началу мы на работе выкрутились выводя сумму разделив дробную и целую часть, еще на уровне процедуры. Это дало некий простор для представления больших чисел, а пользователям на удивление это даже очень понравилось. Казалось бы что еще надо, но ... ошибка опять проявилась. Что б было понятно это отчеты "по оборотам" за большой период в сравнении с "остатками" и нужно это государству, а с ним так лучше не шутить. Вот и выяснил я попутно что ни одно из средств разработки на сегодняшний день не обладает должным инструментарием для подобных вычмислений, за исключением пожалуй perl`a
...
Рейтинг: 0 / 0
02.04.2007, 10:01
    #34430473
PavelBuilder
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бухгалтерское округление
вот кстати отличная статья и на русском, почти все что я писал там так и изложено
http://www.delphikingdom.com/asp/viewitem.asp?catalogid=1218
...
Рейтинг: 0 / 0
02.04.2007, 10:34
    #34430559
Локшин Марк
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бухгалтерское округление
PavelBuilderвот кстати отличная статья и на русском, почти все что я писал там так и изложено
Я там более подробную статью вчера нашел.
http://www.delphikingdom.com/asp/viewitem.asp?catalogID=1217
PavelBuilderВсе правильно, округление до целого, число перед пятёркой 0 - нечетное - округление вниз.
Тогда в моем примере арифметическое "равновероятнее" банковского.
...
Рейтинг: 0 / 0
02.04.2007, 10:48
    #34430588
PavelBuilder
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бухгалтерское округление
Да мне все равно, какое округление лучше :-) Дело в том, что при генерации некого отчета с денюжками в отчет нужно выводить и помежуточные и итоговые суммы, вот и выходит, что мне как раз нужно получить, чтобы сумма округленных значений совпала с суммой неокругленных, а то если клиент возьмет листочек и калькулятор у него не сойдется пару копеек, хотя на самом деле все верно. А мне надоело когда мне кидают на стол подобный отчет и называют меня нехорошими словами ... теперь ситауция на моей стороне, но руководству от это легче не стало :-)
...
Рейтинг: 0 / 0
02.04.2007, 11:03
    #34430630
Локшин Марк
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бухгалтерское округление
PavelBuilderА мне надоело когда мне кидают на стол подобный отчет и называют меня нехорошими словами ... теперь ситауция на моей стороне, но руководству от это легче не стало :-)
Но банковское округление в любом случае не гарантирует такого поведения. Для гарантированной "сходимости" нужно, например, тогда возможную разницу списывать с самого большого документа. Ну и в любом случае сразу округлять до минимальных единиц учета, хотя это не всегда спасает.
...
Рейтинг: 0 / 0
02.04.2007, 11:08
    #34430644
Anatoly Moskovsky
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бухгалтерское округление
Локшин МаркВ моем случае действительно получается для арифметического округления 5000/10001 - 0 5001/10001 - 1.
Но для бухгалтерского округления получается-то еще хуже!
Вероятность для 0 - 6001/10001 для 1 - 4000/10001.

Ошибка в попытке использования 4 разрядов после разряда округления, тогда как погрешность самих чисел равна 10%(+-5%) от значения разряда округления (т.е. имеет смысл только одна цифра после него).
А в этом случае получаем всего 4+5 вариантов арифметического округления и 5+5 вариантов бухгалтерского (округление нуля отбрасывается как не влияющее на результат).
...
Рейтинг: 0 / 0
02.04.2007, 12:00
    #34430807
Локшин Марк
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бухгалтерское округление
Anatoly Moskovskyтогда как погрешность самих чисел равна 10%(+-5%) от значения разряда округления
Почему? Числа могут быть точными хоть до 4 разряда, а мы хотим округлять до целых.
...
Рейтинг: 0 / 0
02.04.2007, 13:05
    #34431035
Anatoly Moskovsky
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бухгалтерское округление
Локшин МаркПочему?
Из метрологии.
...
Рейтинг: 0 / 0
02.04.2007, 13:34
    #34431151
Локшин Марк
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бухгалтерское округление
Anatoly Moskovsky Локшин МаркПочему?Из метрологии.
Не понял. Кто нам запрещает использовать 4 разряда при округлении, если все разряды точные? Где написано что при округлении до целых в этом случае 3 разряда нужно отбрасывать?
...
Рейтинг: 0 / 0
02.04.2007, 13:59
    #34431248
Anatoly Moskovsky
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бухгалтерское округление
Локшин Марк
Не понял. Кто нам запрещает использовать 4 разряда при округлении, если все разряды точные? Где написано что при округлении до целых в этом случае 3 разряда нужно отбрасывать?
В бухгалтерии все исходные суммы - целые (если рассматривать в копейках). Т.е. точность - 0 дробных разрядов.
Поэтому мнение о том, что после какой-либо операции над этими числами получится число с точностью 4 дробных разряда, ошибочно, поскольку погрешность превышает сумму всех этих разрядов, кроме первого после точки.

К вопросу "где написано": много где, вот хотя бы здесь .
При сложении и вычитании приближённых чисел в результате следует сохранять столько десятичных знаков, сколько их в приближённом данном с наименьшим числом десятичных знаков.

При умножении и делении в результате следует сохранять столько значащих цифр, сколько их имеет приближённое данное с наименьшим числом значащих цифр.

При возведении в квадрат или куб в результате следует сохранять столько значащих цифр, сколько их имеет возводимое в степень приближённое число ( последняя цифра квадрата и особенно куба при этом менее надежна, чем последняя цифра основания ).

При увеличении квадратного и кубического корней в результате следует брать столько значащих цифр, сколько их имеет приближённое значение подкоренного числа (последняя цифра квадратного и особенно кубического корня при этом более надёжна, чем последняя цифра подкоренного числа).

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

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

Если данные можно брать с произвольной точностью, то для получения результата с K цифрами данные следует брать с таким числом цифр, какое даёт согласно правилам 1-4 (К+1) цифру в результате.
...
Рейтинг: 0 / 0
02.04.2007, 14:44
    #34431418
Локшин Марк
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бухгалтерское округление
Anatoly MoskovskyВ бухгалтерии все исходные суммы - целые (если рассматривать в копейках). Т.е. точность - 0 дробных разрядов.
Суммы - возможно. Цены бывают и с 4 и с 5 знаками после запятой. Да и не только деньги так округлять можно.
Anatoly MoskovskyК вопросу "где написано": много где, вот хотя бы
Там написано про точность результатов операций. А в последнем пункте предполагается что с данными будут делаться определенные операции с заданной точностью.
Согласитесь, если у нас есть данные каких-то измерений равные 0.5999 с точностью до 4 знаков, то отбросить 3 знака и считать это 0 а не 1... Для меня как-то странно.
...
Рейтинг: 0 / 0
Форумы / PowerBuilder [игнор отключен] [закрыт для гостей] / Бухгалтерское округление / 25 сообщений из 38, страница 1 из 2
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]