Точные вычисления на java?

Question

[Artyom]

Возник вопрос с вычислительной математикой. Делаю некоторые задания, где необходимо рассчитывать корни уравнений с точностью до 6 знака после запятой. Делаю все по алгоритмам. В связи с этим возник вопрос, годятся ли встроенные типы для вычислений такого типа(всего 6 знаков после запятой). Пробовал использовать BigDecimal, результат тот же, ответы верны только до 3-4 знака. Делаю по типовым примерам.
В связи с этим, ошибка может находится в вычислениях(т.к. готовые формулы для вычислений уже есть в типовом примере и результат их вычислений отличается от результатов в книжке). В связи с этим, вопрос, как считать на джаве? А если считается все правильно и расчеты правильные, то почему ответ верен только частично? Дело в округлении промежуточных расчетов до 6 знака? Тогда без округления тоже должен быть правильный ответ ведь?
Метод не такой сложный.
Решал два примера, везде ответ верен не до конца.
Конкретно интересует "Решение систем нелинейных уравнений методом наискорейшего спуска"

rs1 = 2*(Math.cos(1.5 + x1)*(Math.sin(x1 + 1.5) + 2.9 - x2) + x1 + Math.cos(x2-2));	
rs2 = -2 * (Math.cos(x2 - 2) * Math.sin(x2 - 2) - x2 + Math.sin(x1 + 1.5) + 2.9 + x1*Math.sin(x1 + 1.5));

Пример вычисления значения первой и второй производных.
Просто каждый раз пересчитываем их, подставляя предыдущие значения иксов, пока разность между ними и текущими не будет меньше 0.000001, но ответ верен только до 3 ~знака после запятой

Answer 1

[SilentFl]

Попробуйте изменить порядок вычислений.
Пример первый, особенность представления дробных чисел в памяти: 1/10+1/10 в float'ах != 2/10 (потому что 1/10 представляется в памяти как 0.09999(9)) - это можно обойти приведением к общему знаменателю (1+1)/10.
Пример второй, особенность вычислений процессора: сумма ряда 1/10+1/100+1/1000 будет менее точной, чем сумма 1/1000+1/100+1/10. такая разница связана с тем, что два операнда должны быть приведены к одному порядку мантиссы, и в большинстве процессоров этому подвергается второй операнд, с отбрасыванием "невлезающих" разрядов, и, соответственно, снижением точности вычислений.

Answer 2

[Dmitry]

www.apfloat.org/apfloat_java

Comments

[Artyom]

т.е. даже точность в 6 знаков нельзя обеспечить стандартными типами?
Просто, это уравнение из типового примера, мой же вариант содержит двухэтажные дроби, которые выглядят слишком монструозно при использовании BigDecimal, плюс Math допускает значения только double, есть ли смысл вообще в таком случае? Лично у меня, никакой разницы не было заметно.

Answer 3

[MilkyWay]

BigDecimal нельзя так просто умножать операндом "*"

Comments

[Artyom]

Тут double вариант, в BigDecimal такой же ответ выходит. Может быть, в методичке ошибка, но результат все равно неверный)