Как справиться с умножением чисел, близких к 1

Ага: потому что

(1 + x) * (1 + y) = 1 + x + y + x*y

В вашем случае x и y очень малы, поэтому x*y будет намного меньше — слишком мало, чтобы повлиять на результаты ваших вычислений. Итак, что касается вас,

(1 + x) * (1 + y) = 1 + x + y

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

EDIT: только что заметил: вы говорите, что большинство из них очень близки к 1. Очевидно, что этот метод не будет работать для чисел, которые не близки к 1, то есть, если x и y большие. Но если один большой, а другой маленький, это все равно может работать; вас интересует только величина продукта x*y. (И если оба числа не близки к 1, вы можете просто использовать обычное умножение Java double...)

Может быть, вы могли бы использовать логарифмы?

Логарифмы удобно сводят умножение к сложению.

Кроме того, чтобы позаботиться о начальной потере точности, существует функция log1p (по крайней мере, она существует в C/C++), которая возвращает log(1+x) без потери точности. (например, log1p(1e-30) возвращает мне 1e-30)

Затем вы можете использовать expm1, чтобы получить десятичную часть фактического результата.

Разве не для таких ситуаций предназначен BigDecimal?

Отредактировано для добавления:

«В предпоследнем абзаце я бы предпочел избегать BigDecimals, если это возможно, по соображениям производительности». - здравомыслие

«Преждевременная оптимизация — корень всех зол» — Кнут

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

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

Если рациональные числа не подходят, я бы поддержал ответ логарифмов.

Изменить в ответ на ваше редактирование:

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

• Представьте их как избыток/дефицит (нормализуйте часть 1.0)
• Масштабируйте их. Подумайте о «частях на миллион» или о чем угодно.

Это позволит вам иметь дело с разумными числами для расчетов.

Стоит отметить, что вы тестируете пределы своего оборудования, а не Java. Java использует 64-битную плавающую точку в вашем процессоре.

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

Как указывает Дэвид, вы можете просто сложить смещения.

(1+x) * (1+y) = 1 + x + y + x*y

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

x = 1e-8 y = 2e-6 z = 3e-7 w = 4e-5

Что такое (1+x)(1+y)(1+z)*(1+w)? В двойной точности я получаю:

(1+x)(1+y)(1+z)*(1+w)

ответ =

      1.00004231009302

Однако посмотрите, что произойдет, если мы просто воспользуемся простой аддитивной аппроксимацией.

1 + (x+y+z+w)

ответ =

            1.00004231

Мы потеряли младшие биты, которые могли быть важны. Это проблема, только если некоторые из отличий от 1 в продукте составляют по крайней мере sqrt (eps), где eps — это точность, с которой вы работаете.

Попробуйте это вместо этого:

f = @(u,v) u + v + u*v;

результат = f(x,y);

результат = f(результат,z);

результат = f(результат,w);

1+результат

ответ =

      1.00004231009302

Как видите, это возвращает нас к результату двойной точности. На самом деле это немного точнее, так как внутреннее значение результата равно 4,23100930230249e-05.

Если вам действительно нужна точность, вам придется использовать что-то вроде BigDecimal, даже если оно медленнее, чем Double.

Если вам действительно не нужна точность, возможно, вы могли бы пойти с ответом Дэвида. Но даже если вы часто используете умножения, это может быть некоторая преждевременная оптимизация, поэтому BIgDecimal в любом случае может быть подходящим способом.

Когда вы говорите «большинство из которых очень близки к 1», сколько именно?

Возможно, вы могли бы иметь неявное смещение 1 во всех ваших числах и просто работать с дробями.