Java BigDecimal проблемы с точностью

Question

Я знаю, что следующее поведение является старой проблемой, но все же я не понимаю.

System.out.println(0.1 + 0.1 + 0.1);  

Или даже если я использую BigDecimal

System.out.println(new BigDecimal(0.1).doubleValue() 
    + new BigDecimal(0.1).doubleValue() 
    + new BigDecimal(0.1).doubleValue()); 

Почему этот результат: 0.30000000000000004 вместо: 0.3?

Как я могу это решить?

Answer 1

То, что вы на самом деле хотите,

new BigDecimal("0.1") 
.add(new BigDecimal("0.1")) 
.add(new BigDecimal("0.1")); 

new BigDecimal(double) конструктор получает все неточности в double, так что к тому времени, вы сказали 0.1, вы уже ввели ошибку округления. Использование конструктора String позволяет избежать ошибки округления, связанной с переходом через double.

Answer 2

Попробуйте это:

BigDecimal sum = new BigDecimal(0.1).add(new BigDecimal(0.1)).add(new BigDecimal(0.1)); 

EDIT: На самом деле, глядя на Javadoc, это будет та же проблема, что и оригинал. Конструктор BigDecimal(double) сделает BigDecimal, соответствующий точному представлению с плавающей запятой 0,1, что не совсем равно 0,1.

Это, однако, дает точный результат, так как целые числа всегда могут быть выражены в точности с плавающей запятой представления:

BigDecimal one = new BigDecimal(1); 
BigDecimal oneTenth = one.divide(new BigDecimal(10)); 

BigDecimal sum = oneTenth.add(oneTenth).add(oneTenth); 

Answer 3

Это не проблема Java, а проблема компьютеров вообще. Основная проблема заключается в преобразовании из десятичного формата (человеческий формат) в двоичный формат (в компьютерном формате). Некоторые числа в десятичном формате не представляются в двоичном формате без бесконечных повторяющихся десятичных знаков.

Например, 0,3 десятичной цифры 0,01001100 ... двоичный. Но компьютер имеет ограниченные «слоты» (бит) для сохранения числа, поэтому он не может сохранить все бесконечное представление. Он сохраняет только 0,01001100110011001100 (например). Но это число в десятичной форме больше не 0,3, а 0.30000000000000004.

Answer 4

Первый never, никогда не используйте двойной конструктор BigDecimal. В некоторых ситуациях это может быть правильно, но в основном это не

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

Answer 5

Проблема заключается в том, что 0,1 представлен немного большим числом, например.

System.out.println(new BigDecimal(0.1)); 

печатает

0.1000000000000000055511151231257827021181583404541015625 

Двойник.toString() учитывает эту ошибку представления, поэтому вы ее не видите.

Аналогично 0,3 представлено немного ниже, чем на самом деле.

0.299999999999999988897769753748434595763683319091796875 

Если умножить представляемое значение 0,1 на 3 вы не получите представляемое значение 0,3, то вместо того, чтобы получить что-то немного выше

0.3000000000000000166533453693773481063544750213623046875 

Это не просто ошибка, но представления также ошибка округления, вызванная операциями. Это больше, чем Double.toString() будет исправлено, и вы увидите ошибку округления.

Мораль истории, если вы используете float или double, также округлите решение соответствующим образом.

double d = 0.1 + 0.1 + 0.1; 
System.out.println(d); 
double d2 = (long)(d * 1e6 + 0.5)/1e6; // round to 6 decimal places. 
System.out.println(d2); 

печатает

0.30000000000000004 
0.3