Использует ли Java BigDecimal аппаратную архитектуру, как long double в C++?
Насколько я понимаю, long double в C++ фактически использует аппаратную архитектуру (по крайней мере, для некоторых архитектур). BigDecimal в Java делает это для достаточно маленьких входов?
3 ответа
BigDecimal в Java делает это для достаточно маленьких входов?
Нет и не смог. Числа с плавающей точкой с потерями, в то время как каждый BigDecimal имеет связанную точность и может представлять ровно любое число ниже этой точности. Не существует "достаточно маленького ввода", которое можно было бы с пользой представить как число с плавающей запятой, потому что даже если у вас есть BigDecimal значение, которое может быть точно представлено в нотации с плавающей запятой, вам будет сложно выполнить любые операции над этим значением и сохранить указанную точность.
Другими словами, цель BigDecimal это предложить точность, жертвуя скоростью. Это идет вразрез с плавающей точкой, которая жертвует точностью в пользу скорости.
Похоже, вы спрашиваете, предлагает ли Java способ работы с long double чисел с плавающей точкой, и нет. Мы можем сделать вывод из того факта, что не предусмотрено, что авторы JDK никогда не считали необходимым добавлять язык.
Самым важным отличием BigDecimal от типичной аппаратной поддержки long double является основание с плавающей запятой.
Значение BigDecimal - это целое число, умноженное на степень десять. Аппаратное обеспечение с плавающей запятой обычно основано на двоичной переменной с плавающей запятой IEEE, и каждое значение представляет собой целое число, умноженное на степень два.
Некоторые вычисления, чьи входные данные точно представимы в long double, имеют результаты, которые приводят к большей ошибке округления в long double, чем в BigDecimal с заданным масштабом. Например, 1 и 10 могут быть представлены точно в обоих форматах. Результат деления 1 на 10 может быть представлен точно в BigDecimal с масштабом не менее 1, но не в любом формате radix 2.
Есть, конечно, много рациональных соображений, которые нельзя точно представить ни в одном формате. Рассмотрим 1/3. Даже там BigDecimal будет получать большую или меньшую ошибку округления, в зависимости от масштаба. Ответ вряд ли будет одинаковым в длинных двойных и BigDecimal.
Выполнение тестов для каждого расчета, чтобы определить, получат ли два формата одинаковый ответ, приведет к снижению производительности при использовании аппаратного обеспечения.
Нет. BigDecimal не использует аппаратную архитектуру. Смотрите, например, конструктор BigDecimal из исходного кода Java.
BigDecimal(BigInteger intVal, long val, int scale, int prec) {
this.scale = scale;
this.precision = prec;
this.intCompact = val;
this.intVal = intVal;
}