Комментарии 18
Вы храните деньги в double? Зачем?
+22
У нас система, взаимодействующая с другими системами, некоторые из которых даже передают числа в строках, а отдельные экземпляры и хранят их там же (что ж поделаешь с чужими системами?). И когда тестировщик видит в одной системе 2974815.78, а в другой 2974815.75, то начинаются вопросы о том, какую же сумму будет корректно указывать в договоре.
-5
Вот именно. Fixed-point 56.7 использовать надо. Ну а если денег до 16,777,215.99 рублей — то 24.7.
+7
Думаете, лучше хранить в Integer (а кому-то и в Long) в формате <сумма>*100? — Т.е. при выводе и пр. делить на 100, чтобы получить копейки.
-3
В BigDecimal же.
+11
Просто удивительно, сколько раз люди попадают на эту проблему.
Хотя мне кажется уже на каждом углу говорят об этом.
Хотя мне кажется уже на каждом углу говорят об этом.
+4
НЛО прилетело и опубликовало эту надпись здесь
Простите, а можете скинуть ссылки на эти «углы», чтобы ищущие по теме смогли сразу раскрутить клубок, особенно учитывая ограниченность данного материала Явой?
0
Это не ограниченность явой, это ограниченность модели представления данных с плавающей точкой, описанной в IEEE 754, которая применяется сейчас практически в любом ЯП.
float money problem: About 30,600,000 results (0.38 seconds)
float money problem: About 30,600,000 results (0.38 seconds)
+1
В точных операциях (в том числе и фанансовых) нельзя использовать типы с плавающими точками из-за их ограниченной точности. Даже строка лучше в этой ситуации. В идеале — длинная арифметика. BigDecimal, как я понимаю (java я не знаю) — это оно и есть.
+5
В том языке, который Вы предпочитаете, какой тип лучше подходит для хранения денег?
0
Не сталкивался я на практике с расчётными финансовыми задачами.
В Objective-C для отображения цен использую NSDecimalNumber потому как его для этих целей использует iOS SDK.
Но это таки тип с плавающей точкой, пусть и способен хранить до 38 значимых цифр, и ничего большего чем просто хранение цены с ним делать всё равно не стоит.
Если бы мне пришлось делать какие-то расчётные операции — я бы поискал реализацию длинной арифметики на C и использовал бы её. Из минусов — большое потребление памяти и низкое быстродействие, в сравнении со стандартными типами. Из плюсов — максимальное хранимое значение упирается только в объём доступной оперативной памяти.
В Objective-C для отображения цен использую NSDecimalNumber потому как его для этих целей использует iOS SDK.
Но это таки тип с плавающей точкой, пусть и способен хранить до 38 значимых цифр, и ничего большего чем просто хранение цены с ним делать всё равно не стоит.
Если бы мне пришлось делать какие-то расчётные операции — я бы поискал реализацию длинной арифметики на C и использовал бы её. Из минусов — большое потребление памяти и низкое быстродействие, в сравнении со стандартными типами. Из плюсов — максимальное хранимое значение упирается только в объём доступной оперативной памяти.
0
BigDecimal bg = new BigDecimal(«2974815.78»);
bg.setScale(2);
System.out.println(bg);
Пара вопросов:
— зачем вам bg.setScale (особой нужды быть не должно...)?
— вы в курсе, что BigDecimal immutable-объект и ваш код — источник проблем?
0
Если у нас Java, то никто не мешает сделать класс с полями хранения рублей и копеек отдельными полями long и int, тот же Currency назвать.
А про игры с плавающей точкой уже действительно много написано, на том же хабре куча статей почему это происходит и т.п.
А про игры с плавающей точкой уже действительно много написано, на том же хабре куча статей почему это происходит и т.п.
+5
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Потеря точности из Double во Float или «Куда пропадали копейки?»