Почему BigDecimal.equals указан для индивидуального сравнения значения и масштаба?

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

Например, если вы храните измерения, сделанные двумя физическими датчиками, возможно, один из них в 10 раз точнее другого. Может быть важно представить этот факт.

Вопрос, который еще не рассматривался ни в одном из других ответов, заключается в том, что equals требуется, чтобы он соответствовал hashCode, и стоимость реализации hashCode, которая требовалась для получения того же значения для 123,0, что и для 123,00 (но все же разумная работа по различению разных значений) будет намного больше, чем у реализации hashCode, которая не требуется для этого. Согласно существующей семантике hashCode требует умножения на 31 и добавления для каждых 32 бит сохраненного значения. Если бы hashCode требовалось согласовывать значения с разной точностью, ему пришлось бы либо вычислять нормализованную форму любого значения (дорого), либо, как минимум, делать что-то вроде вычисления цифрового корня значения по основанию 999999999 и умножать это значение. , mod 999999999, в зависимости от точности. Внутренний цикл такого метода будет:

temp = (temp + (mag[i] & LONG_MASK) * scale_factor[i]) % 999999999;

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

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

Общее правило для equals состоит в том, что два равных значения должны быть заменены друг на друга. То есть, если выполнение вычисления с использованием одного значения дает некоторый результат, подстановка значения equals в то же вычисление должна дать результат, который equals является первым результатом. Это относится к объектам, которые являются значениями, например String, Integer, BigDecimal и т. Д.

Теперь рассмотрим BigDecimal значения 2,0 и 2,00. Мы знаем, что они численно равны, и что compareTo на них возвращает 0. Но equals возвращает false. Почему?

Вот пример, когда они не подлежат замене:

var a = new BigDecimal("2.0");
var b = new BigDecimal("2.00");
var three = new BigDecimal(3);

a.divide(three, RoundingMode.HALF_UP)
==> 0.7

b.divide(three, RoundingMode.HALF_UP)
==> 0.67

Результаты явно неравны, поэтому значение a не может быть заменено на b. Следовательно, a.equals(b) должно быть ложным.

По математике 10,0 равно 10,00. В физике 10,0 м и 10,00 м, возможно, разные (разная точность), когда мы говорим об объектах в ООП, я бы определенно сказал, что они не равны.

Также легко думать о неожиданной функциональности, если equals игнорирует масштаб (например: если a.equals (b), разве вы не ожидаете a.add (0.1) .equals (b.add (0.1)?).

Если числа округляются, это показывает точность расчета, другими словами:

• 10,0 может означать, что точное число находится в диапазоне от 9,95 до 10,05.
• 10,00 может означать, что точное число находится в диапазоне от 9,995 до 10,005.

Другими словами, это связано с арифметической точностью.

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

Может быть нет. Я предлагаю простое объяснение, что дизайнеры BigDecimal просто сделали неудачный выбор дизайна.

1. Хороший дизайн оптимизирует для обычного использования. В большинстве случаев (> 95%) люди хотят сравнить две величины на основе математического равенства. В меньшей части случаев, когда вы действительно заботитесь о том, чтобы два числа были равны как по масштабу, так и по значению, для этой цели мог бы существовать дополнительный метод.
2. Это противоречит ожиданиям людей и создает ловушку, в которую очень легко попасть. Хороший API подчиняется «принципу наименьшего удивления».
3. Это нарушает обычное соглашение Java, согласно которому Comparable согласуется с равенством.

Интересно, что класс BigDecimal в Scala (который реализован с использованием BigDecimal Java под капотом) сделал противоположный выбор:

BigDecimal("2.0") == BigDecimal("2.00")     // true

Метод compareTo знает, что завершающие нули не влияют на числовое значение, представленное BigDecimal, что является единственным аспектом, который заботит compareTo. Напротив, метод equals обычно не имеет возможности узнать, какие аспекты объекта кого-то волнуют, и поэтому должен возвращать только true, если два объекта эквивалентны всеми способами, которые могут быть интересны программисту. Если x.equals(y) истинно, для x.toString().equals(y.toString()) было бы довольно неожиданно получить ложь.

Другая проблема, которая, возможно, даже более важна, заключается в том, что BigDecimal по существу объединяет BigInteger и коэффициент масштабирования, так что, если два числа представляют одно и то же значение, но имеют разное количество конечных нулей, одно будет содержать bigInteger, значение которого является некоторой десятикратной степенью другой. Если равенство требует, чтобы мантисса и масштаб совпадали, тогда hashCode() для BigDecimal может использовать хэш-код BigInteger. Однако, если два значения можно считать «равными», даже если они содержат разные BigInteger значения, это значительно усложнит ситуацию. Тип BigDecimal, который использовал собственное резервное хранилище, а не BigInteger, мог бы быть реализован множеством способов, позволяющих быстро хешировать числа таким образом, чтобы значения, представляющие одно и то же число, сравнивались бы равными (в качестве простого примера, версия, которая упаковывала девять десятичных цифр в каждое long значение и всегда требовала, чтобы десятичная точка находилась между группами по девять, могла вычислять хэш-код таким образом, чтобы игнорировать конечные группы, значение которых было равно нулю), но BigDecimal, который инкапсулирует BigInteger может ' не делай этого.