Вот примитивнейшая прога



и вот её результаты


Если запускать не в IDE, результаты теже.
Откуда растёт эта потеря точности, ведь все числа с запасом влезают в разрядную сетку типа double 

Не влезают. 1.0011 как вы видите не влезает. Точное представление десятичного числа в двоичной форме не всегда влезает. Тут уже приводили пример, как например простая дробь 1/3  дает бесконечную дробь в десятичной форме 0.3(3). Аналогично при переходе из десятичной формы в двоичную.   

и сие справедливо для любых языков програмирования работающих с "реальными" простыми типами. так что не в Java дело  

danilsl, думаю, это происходит из-за приведения типов.
Как побороть для FOR не понял.

Вот так работает :)

Да, да, да сам пару дней назад столкнулся с подобной проблемой.
Единственный выход который мне посоветовали округлять 

Bulat
Можно так:


 
Вообще же, хотя это еще сильно зависит от бизнес-логики, лучше округлять конечный результат, а не промежуточные вычисления. 
Плюс стараться избегать операций с десятичными числами без реальной необходимости, хотя бы исходя из того, что, как тут уже говорилось, нормальная математика полагает, что 1/3+1/3+1/3 - это строго 1, а не нечто с периодами после запятой.

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

Например, не судите за качество - писал, что в голову с ходу пришло:

 

десятичное счисление - точно такая же математика, как и двоичное.
И у ЛЮБОЙ системы счисления есть "слабые места".
В этом плане десятичная ничуть не слабее двоичной/троичной/восьмиричной
Другое дело, что в памяти сохраняется как двоичное....

Но. Большинство чисел в бизнес-уровне хотят и должны корректно оперировать десятичными(!) числами.

Система, в разработке которой сейчас учавствую, все числовые значения из уровня бизнес-логики содержит в BigDecimal. Хотя он и громоздкий. 

chief39, 


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

Я просто посоветовал уходить от десятичных дробей там, где это возможно - думаю довольно безобидный совет при правильном применении.

Тот же BigDecimal не просто громоздкий, он еще очень медленный и порождает кучу объектов, т.е. казалось бы в тех областях, где больше всего желательны десятичные числа, сам BigDecimal вовсе не так уж желателен из-за вышеперечисленных недостатков.



Я бы сказал, что тут слабое место не в системе счисления, а в представлении чисел в компьютере.
Просто надо с этим смириться. 
 

Это да  Но в денежных(а такое почти в каждой системе) вычислениях лучше всё-таки не уходить :-/


Вот-вот! Ещё куда ни шло копаться вечерком спокойно и дебажить прогу, но совсем другое - когда система, работающая с деньгами, начинает их где-то(!) терять.
Причём найти это место, допустим, ещё не так страшно... А вот исправить неверные результаты сложных риалтайм расчётов на лету - это повешению подобно 


Я вот иногда думаю.... Почему люди считали по 10 пальцам а не по двум рукам? ))
Сколько проблем решилось бы...
И почему в джаве нет просто Decimal... 
 

2carper 
В своем случае-то я разобрался, да и в принципе ты советуешь почти тоже, но лично в моем случае я сначала умножал на 1000, а потом округлял переводя в тип int из double, а потом снова делил на 1000 и снова в double. А про BigDecimal не юзал, но мне сказали пару серьезных причин почему не стоит его применять, если нет существенной необходимости 

раз уж пошла такая пляска  
вот нашёл небольшое описание:
http://www.delphikingdom.com/asp/viewitem.asp?catalogID=374 

Это сообщение отредактировал(а) Metal_Heart - 24.5.2006, 08:42