Оригиналът е на Nauseam Калкулаторът трябва да ви покаже резултата

Оригиналът е на Nauseam

Калкулаторът би трябвало да ви покаже резултата от прелюдия от вас математически израз, а това е доста, доста по-трудно, в сравнение с наподобява. Това, което ще ви опиша, е най-великата история за създаването на приложение-калкулатор. Разгледайте калкулатора в iOS. Забелязвате ли нещо? Той демонстрира неверен резултат. (10 100) + 1 – (10 100) е 1, а не 0. В Android резултатът е правилен. А историята за това по какъв начин се е случило сходно нещо е безусловно безумна.

Гугъл наема Ханс-Й. Бьом, който е добре прочут. Те са имали потребност от първокласен програмист, който да отстранява грешките при работата с паметта и паралелното програмиране. Той управлява напъните за дефиниране на семантиката на споделените променливи на C++. Но по-късно му разпореждат една както се оказва една невъзможна задача: да напише приложение-калкулатор.

Дори и за него това би трябвало да е било предизвикателство. Целта на приложението-калкулатор е да ви даде верните отговори. Числата с плаваща запетая са неточни – те не могат да показват стойности като 0,3 или 10 100. Това значи, че един калкулатор, основан на цифри с плаваща запетая, е като къща, издигната върху пясък.

Струва си да повторим: с цел да дава верни отговори на математическите изрази, калкулаторът би трябвало да показва цифри. А на процедура надалеч не всички цифри могат да бъдат показани във формат IEEE с плаваща запетая. Дори простите интервенции с цифри с плаваща запетая изискват деликатно обсъждане, с цел да се получи прецизен отговор.

Така да вземем за пример логаритъмът за сумиране на Кахан (Kahan summation algorithm) доста понижава числената неточност при събиране на поредност от цифри с плаваща запетая с последна акуратност спрямо стандартния (наивен) метод. Алгоритъмът работи, като поддържа обособена „ настояща отплата “ (running compensation) – променлива, която натрупва дребните неточности. Това решение в реалност води до повишение на точността на сумата с точността на компенсационната променлива.

Първото решение: огромните цифри

Някои проблеми могат да бъдат избегнати посредством потребление на огромни цифри. Повечето числови видове употребяват 2 или 4 байта. Но не и огромните цифри. Те са цели цифри без ограничавания. Те заемат толкоз памет, колкото им е нужна. Това взема решение казуса с образеца (10 100) + 1 – (10 100). Но огромните цифри са цели цифри. Какво да кажем за дробните цифри?

Дробите могат елементарно да се пресмятат. Просто би трябвало да се употребяват огромни цифри за числител и знаменател. Изпълнението на аритметичните интервенции за този вид данни е банално и постоянно дава точни отговори. По този въпрос мнозина биха оповестили победа. Но Бьом не е бил удовлетворен. Дори напълно не е бил удовлетворен.

Математиката е доста повече от дробни цифри. Какво ще кажете за π или √2? Калкулатор, основан на дроби с случайна акуратност, няма да може да пресметна обиколката на окръжност, тъй като π не може да се изрази като дроб. Ако вашият калкулатор не може да се оправи с математиката от 9-и клас, защо ви е необходим?

Алгебричната аритметика

Алгебричната аритметика би го доближила до крайната цел. Забравете за представянето на числата като числители и знаменатели. Можете да ги визиите като полиномно уравнение, на което те дават отговор. За √2 това би било x² – 2 = 0. (Освен това ще се сети, че се нуждае от позитивен корен.)

В тази обстановка математическите интервенции стават малко по-сложни за осъществяване:

за събиране би трябвало да се сътвори нов многочлен (полином), чийто корен е сумата от първичните многочлени за умножение се употребява комбинация от получените многочлени и резултантните многочлени.

Навярно се досещате, че и това напълно не е задоволително за Бьом. То работи единствено за алгебричните цифри. Но и това не дава π.

Конструктивните действителни цифри

Така че на Бьом не му остава нищо друго, с изключение на да се задълбочи в тематиката. Крайно време е да се заеме съществено с този калкулатор. Той стартира с задачите цифри (Bignum), мина към рационалните цифри, а по-късно и към алгебричните цифри. Какво следва? Конструктивните действителни цифри (строго видяно, преглеждаме градивни способи за сформиране на действителните числа).

Поради това Бьом стартира да учи „ рекурсивната действителна аритметика “ (RRA). Ако имате израз и знаете с каква акуратност би трябвало да бъде отговорът, RRA ще ви даде отговор с акуратност не по-ниска от заложената.

Конструктивните действителни цифри са цифри, които можете да изчислявате все по-точно и по-точно. Никога няма да можете да ми посочите всичките десетични дроби на цифрата π. Но в случай че ви помоля да назовете рационално число с акуратност до 0,01 от цифрата π, ще можете да ми назовете 3,14. Числото π е в границите на 0,01 от цифрата 3,14, тъй че това е верният отговор.

А в този момент да предположим, че ви помоля да пресметнете число с акуратност до 0,01 от 2π. Знаете по какъв начин да изчислите цифрите на цифрата π. (3,14159…) Тогава можете да вземете някои от тях и да ги умножите по 2. Но какъв брой числа би трябвало да вземете, с цел да получите отговор с акуратност до 0,01 за 2π?

Ако умножите цифрата по 2, грешката се удвоява. Помолих ви да пресметнете 2π с акуратност до 0,01, тъй че би трябвало да пресметнете π с акуратност до 0,005. Да кажем, че получавате 3,141, което в действителност е по-малко от 0,005 от π. Умножете това число по 2 и сте подготвени!

Как работи RRA (Recursive Ray Acoustics)

Всяко число в RRA е показано като функционалност, която приема рационално число и връща рационално число. Рационалното число, което тя приема, е изискваната погрешност. Гарантирано е, че рационалното число, което тя връща, е в границите на тази погрешност на действителното число, което в действителност тя показва.

Това значи, че RRA е елементарен за потребление. Посочвате какъв брой прецизен желаете да бъде отговорът и той рекурсивно дефинира каква акуратност е нужна при всички междинни калкулации. Той се оправя без проблем с изрази, съдържащи π или √2. Това е доста значимо за един калкулатор.

Нови проблеми

Мислите си: „ Сигурно Бьом би спрял дотук “. Просто би трябвало да се зададе „ точността на изхода “ на броя на цифрите, показвани от калкулатора, нали по този начин? Тогава всички цифри, показвани от калкулатора, ще бъдат правилни. По този метод в този момент калкулаторът постоянно ще извежда правилния отговор!

Но не би. Когато потребителите вкарат „ 1-1 “, отговорът е 0, тъй че би трябвало да се покаже „ 0 “. Но RRA ще ви каже единствено, че „ 1-1 е в границите на грешката при закръгляне от 0,0000000000000 “. Показването на 0,0000000000000 на екрана, когато отговорът е тъкмо 0, би било ужасяващ потребителски проблем.

Бьом се връща към чертожната дъска. В този миг той би трябвало да е бил много смутен. В съпоставяне с това, неговото „ ефикасно от позиция на пространството консервативно разчистване на паметта “ е било детска игра. Той не е могъл да се оправи самичък. Потърсил е помощта на изтъкнати сътрудници като Корки Картрайт и Върнън Лий, младши.

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

Запомнете: в случай че калкулаторът покаже 0 за e (-10000), то това би било погрешно. Това не е 0. Трябва да е 0.00000….. и можете да превъртате, до момента в който видите първата цифра. Но когато въведете sin(π), тя ТРЯБВА да бъде 0. sin(π) е равна навръх 0. RRA няма по какъв начин да ни покаже това!

Или можете просто да не давате отговора, както прави калкулаторът в iOS.

Следователно точният отговор не може да бъде получен благодарение на градивните действителни цифри. Но Бьом и сътрудниците му осъзнават, че това е изцяло допустимо. Не е належащо да работят с всички градивни действителни цифри. Необходимо е да работят единствено с тези цифри, които могат да бъдат изразени благодарение на интервенциите, налични в калкулатора.

Пробивът

Задачата бе да се дефинира дали две градивни действителни цифри са равни. Това е било невероятно да се реши. Те опростили задачата и се доближили до решение, като лимитирали методите, по които могат да се сформират числата:

Четирите съществени аритметични интервенции и квадратните корени тригонометричните функционалности sin, cos и tan и техните противоположни стойности Експоненциалните и (натуралните) логаритмични функционалности

Това е доста по-малък набор от цифри, в сравнение с всички градивни действителни цифри. Всъщност някой към този момент е изследвал тъкмо този проблем. Това са Дан Ричардсън и Джон Фич, които вземат решение задачата през 1994 година

Решението им е безусловно вярно. Авторите са създали полуалгоритъм, който първо свежда задачата до инспекция на еквивалентността на обикновените константи и по-късно я взема решение. Характерна специфичност на този логаритъм е, че той постоянно дава верен отговор при завършването си и обезпечено приключва, в случай че задачата не съдържа контрапример за хипотезата на Шануел.

Звучи съвършено. Но има един проблем. Алгоритъмът е прекомерно муден. 1 не е равно на 1 – e (e (e (-1000))). Но с цел да може логаритъмът на Ричардсън и Фич да открие това, ще са нужни повече стъпки, в сравнение с са атомите във Вселената. Калкулаторът на Android следва да работи. меко казано, по-бързо.

Те осъзнават, че не е краят на света, в случай че покажат „ 0.000000… “, когато отговорът е тъкмо 0, макар че това не е съвършеното потребителско преживяване. Те просто не могат да покажат „ 0 “ при положение, че отговорът е 0,0000001.

RRA ви дава цялостната мощ на градивните действителни цифри, само че минусът е, че приемането на точни отговори става невероятно. Рационалната аритметика ви дава точни отговори, само че не може да изрази π. Възможно ли е да се съчетаят мощните им страни?

Въпреки, че публикацията приключва малко ненадейно, мненията под нея са извънредно доста, като има голям брой образци и скрийншоти на това, какъв резултат се получава при въвеждането на задачата за изчисляването на (10 100) + 1 – (10 100).

Така да вземем за пример, един от потребителите споделя, че калкулаторът Hyper Calc Pro дава 0. Друг споделя, че SpeedCrunch дава 0, единствено че калкулаторът в Оценка за съвместимост Windows 10 и Windows 11 ненадейно дава верния отговор – 1.

Разбира се, всеки може самичък да ревизира, само че следват образци, че iPhone 15 дава 0, а Android 15 дава 1. От друга страна калкулаторът в Android 9 дава неправилната 0. Странно…