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

Да: защото

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

Във вашия случай x и y са много малки, така че x*y ще бъде много по-малък - твърде малък, за да повлияе на резултатите от вашето изчисление. Така че що се отнася до вас,

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

Това означава, че можете да съхранявате числата с извадено 1 и вместо да умножавате, просто ги събирайте. Докато резултатите винаги са много по-малки от 1, те ще бъдат достатъчно близки до математически прецизните резултати, че няма да ви интересува разликата.

РЕДАКТИРАНЕ: Току-що забелязано: казвате, че повечето от тях са много близки до 1. Очевидно тази техника няма да работи за числа, които не са близки до 1 - т.е. x и y са големи. Но ако едното е голямо, а другото е малко, все още може да работи; вие се интересувате само от величината на продукта x*y. (И ако и двете числа не са близки до 1, можете просто да използвате обикновено Java double умножение...)

Може би бихте могли да използвате логаритми?

Логаритмите удобно намаляват умножението до събиране.

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

След това можете да използвате expm1, за да получите десетичната част от действителния резултат.

Не е ли точно такъв тип ситуация, за която е BigDecimal?

Редактирано за добавяне:

„Съгласно предпоследния параграф бих предпочел да избегна BigDecimal, ако е възможно от съображения за производителност.“ – здравия разум

„Преждевременната оптимизация е коренът на всяко зло“ – Кнут

Има просто решение, направено практически по поръчка за вашия проблем. Притеснявате се, че може да не е достатъчно бързо, така че искате да направите нещо сложно, което мислите, че ще бъде по-бързо. Цитатът на Кнут понякога се използва прекалено много, но това е точно ситуацията, срещу която той предупреждаваше. Напишете го по простия начин. Тествайте го. Профилирайте го. Вижте дали е твърде бавно. Ако е тогава започнете да мислите за начини да го направите по-бързо. Не добавяйте целия този допълнителен сложен, податлив на грешки код, докато не разберете, че е необходим.

В зависимост от това откъде идват числата и как ги използвате, може да искате да използвате рационални вместо плаващи числа. Не е правилният отговор за всички случаи, но когато е правилният отговор, наистина няма друг.

Ако рационалните числа не пасват, бих подкрепил отговора на логаритмите.

Редактирайте в отговор на вашата редакция:

Ако имате работа с числа, представляващи ниски нива на отговор, направете това, което правят учените:

• Представете ги като излишък/дефицит (нормализирайте частта 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)

ans =

      1.00004231009302

Обаче вижте какво ще се случи, ако просто направим простото адитивно приближение.

1 + (x+y+z+w)

ans =

            1.00004231

Загубихме битовете от нисък ред, които може да са били важни. Това е проблем само ако някои от разликите от 1 в продукта са поне sqrt(eps), където eps е точността, с която работите.

Опитайте това вместо това:

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

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

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

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

1+резултат

ans =

      1.00004231009302

Както можете да видите, това ни връща към резултата с двойна точност. Всъщност е малко по-точно, тъй като вътрешната стойност на резултата е 4.23100930230249e-05.

Ако наистина се нуждаете от точността, ще трябва да използвате нещо като BigDecimal, дори ако е по-бавно от Double.

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

Когато казвате "повечето от които са много близки до 1", колко точно?

Може би бихте могли да имате имплицитно отместване от 1 във всичките си числа и просто да работите с дробите.