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

З.Ы. А замапить свой тип на decimal в Hibernate через custom type mapping не сильно сложно будет?

Здравствуйте, Trean, Вы писали:

T>Нужен сабж для финансовых расчетов, обычный BigDecimal никуда не годится.
Почему?

Здравствуйте, LeonidV, Вы писали:

LV>Здравствуйте, Trean, Вы писали:

T>>Нужен сабж для финансовых расчетов, обычный BigDecimal никуда не годится.
LV>Почему?

Исключительно потому, что после каждой операции создается новый объект, происходит создание и копирование массивов. Хотелось бы обойтись без таких постоянных релокаций для ограниченной последовательности операций. Кроме того округление хотелось бы делать в самом конце вычислений, а это значит что до округления будет расти точность и накладные расходы на ее представление (нужно обеспечить точность конечного результата не менее 8 знаков после запятой, есть такое требование). Как объект для хранения BigDecimal меня, вполне устраивает, черт с ним с хибернейтом, но вычисления хотелось бы делать inplace.

Здравствуйте, Trean, Вы писали:

T>Здравствуйте, LeonidV, Вы писали:

LV>>Здравствуйте, Trean, Вы писали:

T>>>Нужен сабж для финансовых расчетов, обычный BigDecimal никуда не годится.
LV>>Почему?

T>Исключительно потому, что после каждой операции создается новый объект, происходит создание и копирование массивов. Хотелось бы обойтись без таких постоянных релокаций для ограниченной последовательности операций. Кроме того округление хотелось бы делать в самом конце вычислений, а это значит что до округления будет расти точность и накладные расходы на ее представление (нужно обеспечить точность конечного результата не менее 8 знаков после запятой, есть такое требование). Как объект для хранения BigDecimal меня, вполне устраивает, черт с ним с хибернейтом, но вычисления хотелось бы делать inplace.

Ну, можно и не округлять до самого конца. А что значит не подходит? Вы уже нагрузочные тесты следали? Или это такая оптимизация с потолка?

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

Здравствуйте, Trean, Вы писали:

T>Исключительно потому, что после каждой операции создается новый объект, происходит создание и копирование массивов. Хотелось бы обойтись без таких постоянных релокаций для ограниченной последовательности операций. Кроме того округление хотелось бы делать в самом конце вычислений, а это значит что до округления будет расти точность и накладные расходы на ее представление (нужно обеспечить точность конечного результата не менее 8 знаков после запятой, есть такое требование). Как объект для хранения BigDecimal меня, вполне устраивает, черт с ним с хибернейтом, но вычисления хотелось бы делать inplace.
Вы реально тестировали на производительность? У меня делается достаточно сложная аналитика на BigDecimal'ах — GC без проблем справляется с тоннами BigDecimal'ов. Округление в BD, как раз, вполгне нормально работает.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Trean, Вы писали:

T>>Исключительно потому, что после каждой операции создается новый объект, происходит создание и копирование массивов. Хотелось бы обойтись без таких постоянных релокаций для ограниченной последовательности операций. Кроме того округление хотелось бы делать в самом конце вычислений, а это значит что до округления будет расти точность и накладные расходы на ее представление (нужно обеспечить точность конечного результата не менее 8 знаков после запятой, есть такое требование). Как объект для хранения BigDecimal меня, вполне устраивает, черт с ним с хибернейтом, но вычисления хотелось бы делать inplace.
C>Вы реально тестировали на производительность? У меня делается достаточно сложная аналитика на BigDecimal'ах — GC без проблем справляется с тоннами BigDecimal'ов. Округление в BD, как раз, вполгне нормально работает.

Для тестирования как раз и надо раздобыть альтернативную реализацию, чтобы понять стоит авчинка выделки или нет
Писал мортгейдж калькулятор, с тех пор осадочек остался, для вычисления эквивалентной ставки в результате пришлось использовать double пусть и с потерей точности, да и симуляция выплат по ссуде за 30 лет, тоже не мгновенно считалась.
"без проблем справляется" — это все относительно и субъективно: можно ведь и на многопроцессорной машине запускать с гигабайтами озу. Конечно, спихнуть на GC и CPU можно все, но мне не очень нравится, когда в критических местах делаются лишние вещи, если их можно не делать и за это ничего не будет
Что округление в BD хорошо и корректно работает я знаю, но чем выше точность, тем выше вспомогательные накладные расходы. Хочется скорости 50-70% от скорости С++, и если для обычной программы Java вполне может в среднем догнать и перегнать, то в "тяжелых" вычислениях приходится жертвовать ОО в пользу производительности. Попробуйте поработать с изображениями через setPixel и через ByteBuffer, разница будет в порядок.

Здравствуйте, Trean, Вы писали:

T>Для тестирования как раз и надо раздобыть альтернативную реализацию, чтобы понять стоит авчинка выделки или нет
Эээ... А зачем?

Если скорость существующей реализации удовлетворяет, то какой смысл что-то менять?

T>Писал мортгейдж калькулятор, с тех пор осадочек остался, для вычисления эквивалентной ставки в результате пришлось использовать double пусть и с потерей точности, да и симуляция выплат по ссуде за 30 лет, тоже не мгновенно считалась.
Странно, у меня точно такая же ситуация (считаю проценты пени) — все без проблем считается.

T>Что округление в BD хорошо и корректно работает я знаю, но чем выше точность, тем выше вспомогательные накладные расходы. Хочется скорости 50-70% от скорости С++, и если для обычной программы Java вполне может в среднем догнать и перегнать, то в "тяжелых" вычислениях приходится жертвовать ОО в пользу производительности. Попробуйте поработать с изображениями через setPixel и через ByteBuffer, разница будет в порядок.
Тут проблема на в ОО (на С++ в Blitz все тоже ООшное), а в иимутабельных объектах.

Trean wrote:

> Для тестирования как раз и надо раздобыть альтернативную реализацию,
> чтобы понять стоит авчинка выделки или нет
> Писал мортгейдж калькулятор, с тех пор осадочек остался, для вычисления
> эквивалентной ставки в результате пришлось использовать double пусть и с
> потерей точности, да и симуляция выплат по ссуде за 30 лет, тоже не
> мгновенно считалась.
Ссуда на 30 лет, по 12 месяцев, это всего 360 чисел. Ну пусть по 100 операций на число (а мне кажется реально не более
10) , получится 36000 арифметических действий, по 1000 тактов процессора (а реально не более 100) — на 1ГГц
процессоре... Это же миллисекунды! Может алгоритм кривой был? В бухгалтерии алгоритмы простые, это вам не ассиметричное
шифорвание.

Здравствуйте, Trean, Вы писали:

T>>>Нужен сабж для финансовых расчетов, обычный BigDecimal никуда не годится.
LV>>Почему?

T>Исключительно потому, что после каждой операции создается новый объект, происходит создание и копирование массивов. Хотелось бы обойтись без таких постоянных релокаций для ограниченной последовательности операций. Кроме того округление хотелось бы делать в самом конце вычислений, а это значит что до округления будет расти точность и накладные расходы на ее представление (нужно обеспечить точность конечного результата не менее 8 знаков после запятой, есть такое требование).

Вот для избежания округления в середине расчета сделал обретку над BigDecimal и добавил в нее поняти Fraction (дробь), в которой формирую дробь при операциях деления. В конце итор формируется из BigDecimal и Fraction с необходимой точностью округления. Но, боюсь, тебя это не устроит, бо как в худшем случае помимо оного BigDecimal приходится на каждую операцию создавать еще два объекта (Fraction и саму обертку).

Здравствуйте, Trean, Вы писали:

T>Кроме того округление хотелось бы делать в самом конце вычислений, а это значит что до округления будет расти точность и накладные расходы на ее представление (нужно обеспечить точность конечного результата не менее 8 знаков после запятой, есть такое требование).

Кстати, о точности. Уж не помню всех подробностей, но видел пост мужика, который в 90-х на каком-то из Smalltalk-ов писал софтину для австралийского банка. При вычислениях использовались натуральные дроби, и к концу дня числитель и знаменатель приобретали совершенно неприличные размеры (они были представлены аналогом BigInteger) жутко всё тормозя. Тогда паралельно добавили вриант с округлением после каждой операции. Этот вариант не накапливал тормоза и конечные результаты в конце дня отличались от эталонных (исходного варианта без потери точности) на сущие копейки. Помнится факт того, что "точность" может не стоить "выделки" довольно сильно поразил меня.

Andrei N.Sobchuck wrote:

> T>Кроме того округление хотелось бы делать в самом конце вычислений, а
> это значит что до округления будет расти точность и накладные расходы на
> ее представление (нужно обеспечить точность конечного результата не
> менее 8 знаков после запятой, есть такое требование).
>
> Кстати, о точности. Уж не помню всех подробностей, но видел пост мужика,
> который в 90-х на каком-то из Smalltalk-ов писал софтину для
> австралийского банка. При вычислениях использовались натуральные дроби,
> и к концу дня числитель и знаменатель приобретали совершенно неприличные
> размеры (они были представлены аналогом BigInteger) жутко всё тормозя.
> Тогда паралельно добавили вриант с округлением после каждой операции.
> Этот вариант не накапливал тормоза и конечные результаты в конце дня
> отличались от эталонных (исходного варианта без потери точности) на
> сущие копейки. Помнится факт того, что "точность" может не стоить
> "выделки" довольно сильно поразил меня.
Не скажу за всю одессу, но обычно считают целочисленно, в копейках. В редких случаях в 1/100 копеек. Строго
оговариваются правила округления (вверх/вниз/к ближайшему целому). Желательно поточнее узнать, откуда взялось требование
считать до 8-ми знаков, поди насочиняли. Так что long обычно хватает.

Здравствуйте, ., Вы писали:

.>Не скажу за всю одессу, но обычно считают целочисленно, в копейках. В редких случаях в 1/100 копеек. Строго
.>оговариваются правила округления (вверх/вниз/к ближайшему целому). Желательно поточнее узнать, откуда взялось требование
.>считать до 8-ми знаков, поди насочиняли. Так что long обычно хватает.
8 знаков часто бывает нужно. Например, у меня считается пени за день, что-то около 0.15% — соответственно на суммах в доллары цифры получаются в четвертом-пятом знаке после запятой. Ну и еще оставить запас на всякие возведения в квадрат и т.п.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Кстати, о точности. Уж не помню всех подробностей, но видел пост мужика, который в 90-х на каком-то из Smalltalk-ов писал софтину для австралийского банка. При вычислениях использовались натуральные дроби, и к концу дня числитель и знаменатель приобретали совершенно неприличные размеры (они были представлены аналогом BigInteger) жутко всё тормозя.
А что мешало переодически его нормализовывать?

Просто у double есть патологические проблемы с представлением дробей типа 1/3.

Cyberax wrote:

> .>Не скажу за всю одессу, но обычно считают целочисленно, в копейках. В
> редких случаях в 1/100 копеек. Строго
> .>оговариваются правила округления (вверх/вниз/к ближайшему целому).
> Желательно поточнее узнать, откуда взялось требование
> .>считать до 8-ми знаков, поди насочиняли. Так что long обычно хватает.
> 8 знаков часто бывает нужно. Например, у меня считается пени за день,
> что-то около 0.15% — соответственно на суммах в доллары цифры получаются
> в четвертом-пятом знаке после запятой. Ну и еще оставить запас на всякие
> возведения в квадрат и т.п.
Понятно... А почему обязательно за каждый день считать? Почему за период нельзя? Т.е. как чувак пришел оплатить, за всё
время и посчитать, а не на каждый день, пол копейки всё равно никто не платит.

Здравствуйте, ., Вы писали:

.>Понятно... А почему обязательно за каждый день считать? Почему за период нельзя? Т.е. как чувак пришел оплатить, за всё
.>время и посчитать, а не на каждый день, пол копейки всё равно никто не платит.
За день — так как оно так принято

Платежи осуществляются пачками и на тысячах чуваков получается уже ощутимая сумма.

Cyberax wrote:

> .>Понятно... А почему обязательно за каждый день считать? Почему за
> период нельзя? Т.е. как чувак пришел оплатить, за всё
> .>время и посчитать, а не на каждый день, пол копейки всё равно никто не
> платит.
> За день — так как оно так принято

> Платежи осуществляются пачками и на тысячах чуваков получается уже
> ощутимая сумма.
Не понял. 10000 людей платят по 3 десятых копейки??
Не может быть, такие счета не выставляет.

Здравствуйте, ., Вы писали:

>> Платежи осуществляются пачками и на тысячах чуваков получается уже
>> ощутимая сумма.
.>Не понял. 10000 людей платят по 3 десятых копейки??
.>Не может быть, такие счета не выставляет.
Агенство выставляет счета на зарплату для 1000 человек (причем за несколько месяцев), если предприятие не платит счет вовремя, то за каждый день просрочки идет пени. Причем пени считается отдельно по каждому человеку, а потом суммируется — так как деньги на всех людей переводятся одним куском. Причем еще возможны ситуации, когда предприятие проплачивает только ЧАСТЬ счетов, так что пени идет на остальные счета.

Cyberax wrote:

> Агенство выставляет счета на зарплату для 1000 человек (причем за
> несколько месяцев), если предприятие не платит счет вовремя, то за
> каждый день просрочки идет пени. Причем пени считается отдельно по
> каждому человеку, а потом суммируется — так как деньги на всех людей
> переводятся одним куском. Причем еще возможны ситуации, когда
> предприятие проплачивает только ЧАСТЬ счетов, так что пени идет на
> остальные счета.
А почему нельзя вначале сложить, а потом за период пени посчитать? Или законодательство такое?
Хотя какая разница... алгебраически то же самое должно получаться, имхо.

Здравствуйте, ., Вы писали:

.>А почему нельзя вначале сложить, а потом за период пени посчитать? Или законодательство такое?
.> Хотя какая разница... алгебраически то же самое должно получаться, имхо.
Проблема в том, что для разных людей может быть разное пени. Конечно, можно было бы группировать по дням.

Cyberax wrote:

> .>А почему нельзя вначале сложить, а потом за период пени посчитать? Или
> законодательство такое?
> .> Хотя какая разница... алгебраически то же самое должно получаться, имхо.
> Проблема в том, что для разных людей может быть разное пени. Конечно,
> можно было бы группировать по дням.
Ясно. Действительно, технически проще посчитать в BigInteger.