| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java: Общие вопросы > Округление double |
| Автор: firedrago 26.9.2005, 01:07 | ||
| Всем привет, посоветуйте как точнее всего реализовать округление double до сотых или тысячных.... я делал это так, но работает оно как-то не точно.....хотя по идее должно.... при раскладе Nbr.formatDouble(1.0049, 2) получается 1.00 а мне надо 1.01
|
| Автор: Ch0bits 26.9.2005, 02:09 |
| Потому что [0.000; 0.005] = 0.00 и (0.005; 0.01] = 0.01 1.0049 так и получается 1.00, по моему так и должно быть. |
| Автор: Macross 26.9.2005, 08:51 |
| Если мне память не изменяет, то по правилам математики 1.0049 округляеться именно до 1.00. Округление идет по следующему знаку за нужным, в данном случае по третьему, а 4 округляеться до 0. |
| Автор: firedrago 26.9.2005, 11:02 |
| да округление математически правильное, но если для бугалтерии, то спустя какое-то время будет потеря денег... |
| Автор: 3,14 26.9.2005, 11:59 | ||
firedrago, тогда отсылай в процедуру не number, а
|
| Автор: Ch0bits 26.9.2005, 12:12 | ||
Поэтому там считают с большей точностью и только в отчётах округляют до копеек. |
| Автор: Guest 26.9.2005, 13:53 | ||
Могу посоветовать следующее, как сделать проще не знаю
|
| Автор: firedrago 26.9.2005, 14:30 |
| всем спасибо, я думаю для начала подойдет. если еще какие-то идеи возникнут, буду благодарен. |
| Автор: carper 3.10.2005, 16:19 | ||||
firedrago
Не знаю, полезно ли, но рекомендую почитать статьи об округлении в финансовых расчетах. Там куча правил, очень мало, что имеющих с обычным округлением. Вот, более-менее стандартные типы (признанные математиками), разумеется, это только то немногое, что я вспомнил из того, чего не знаю 1.35 = 1.4 1.35 = 1.3 1.39 = 1.3 (не округление, а просто "отбрасывание" "лишних" цифр) 1.35 = 1.4 но 1.45 = 1.4 (округление в нечетную сторону) Встречал и варинат 1.351= 1.3, но 1.356 = 1.4 Тут все дело в том, что в финансах в обычную математику вмешивается целая куча параметров, таких как, например, необходимость использования бесконечных дробей (типа партия из 3 товаров за 10 рублей в принципе не может быть реализована строго по 10/3 руб. за штуку). Необходимость расчета с максимальной точностью вплоть до заданного отчетного периода, после которого сумма округляется и далее цикл повторяется, потом идет перерасчет с налоговой на сальдо и сумма снова корректируется. Целые статьи пишутся о том, как максимально сгладить эффект сальдо при финансовых расчетах. Это я к чему, а к тому, что тут JAVA не причем, вы имеете дело с типичным бизнес-правилом и для него надо самому писать JAVA метод, реализующий бизнес-функцию. Это желательно делать даже для стандартного округления, т.к. в дальнейшем при необходимости изменения бизнес-правила надо будет только изменить одну функцию. Например, для простейшего варианта округления (внимание! работает неверно для большого кол-ва знаков после запятой, >7, кажется, что можно решить введением BigDecimal) можно написать что-то вроде (разумеется, неоптимизированный вариант, я его только сейчас изобрел
|
| Автор: Guest 4.10.2005, 19:52 | ||
| В азбуке Refactoring: Improving the Design of Existing Code by Martin Fowler, Фаулер пишет:
[Fowler, AP] это видимо отсыл к M.Fowler Analysis Patterns: Reusable Object Models. Reading, Mass.: Addison-Wesley, 1997. A book of domain model patterns. http://www.google.ru/search?q=quantity%20pattern |
| Автор: firedrago 4.10.2005, 23:13 | ||
| я тут еще нашел интересную библиотеку на яве http://www.doc.ic.ac.uk/~oce/numerics/download.htm с исходниками, там много всего есть, правда еще времени не было с ней разобраться.... и в отношении округленяй вот что в ней...
|
| Автор: hatsumeika 7.10.2005, 20:46 | ||
| очень не рекомендую использовать для хранения денег или значений, используемых для вычисления денег double. Ибо:
лучше использовать BigDecimal. при этом нужно использовать конструктор BigDecimal(String), а не BigDecimal(double). Т.е. нужно писать BigDecimal("0.1"), а не BigDecimal(0.1) |