Проблемы точности Java BigDecimal

На самом деле ты хочешь

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

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

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

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

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

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

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

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

РЕДАКТИРОВАТЬ: На самом деле, просматривая 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);

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

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

отпечатки

0.1000000000000000055511151231257827021181583404541015625

Double.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