Передбачається точність функцій з плаваючою комою


9

Переглядаючи реалізацію іншого програміста функції для обчислення нормального CDF розподілу , я запропонував або замінити всю реалізацію на вбудовані функції Python, або використовувати SciPy, загальну наукову бібліотеку.

Інший програміст зазначив, що ні в жодних документах, math.erfc()ні scipy.stats.norm.cdf()в їх документації не передбачено жодних гарантій точності. Тому я повинен бути більш обережним щодо заміни алгоритму наближення (який був узятий із шанованого джерела та який мав задокументовані межі помилок ).

Якщо чесно, думка сумніватися у точності та точності вбудованої або бібліотечної функції ніколи не спадала мені на думку. Зрештою, я закликав такі функції, як sin()і sqrt()роками, без особливих роздумів - навіщо слід math.erf()чи scipy.stats.norm.cdf()бути інакшим?

Але зараз я стурбований. Мої запитання:

  1. Загалом, якщо в документації не зазначається особлива згадка, чи мається на увазі, що ці види функцій є абсолютно точними до останнього десяткового знаку, в межах точності, пропонованої плаваючою точкою подвійної точності IEEE?
  2. Це правда для Python's math.erf()або SciPy scipy.stats.norm.cdf()зокрема? Як ти можеш це сказати?
  3. Ця довідкова сторінкаsin() говорить ...

    Ці функції можуть втратити точність, коли їх аргумент є близьким до кратного pi або далекий від 0,0.

    Чому такі застереження повинні існувати, коли функція синуса періодична і симетрична? Здається, що абонент кладе на себе тягар, щоб канонізувати вхід для отримання оптимальної точності.

    З іншого боку, документація Mozilla Math.sin()нічого не говорить про точність або точність. Чи означає це, що вона є абсолютно точною, або це "загальновідомі відомості", які Math.sin()були б точними лише за певних обставин у JavaScript, як і скрізь?


1
FYI щодо питання 1: Зазвичай гарантії на точність подаються з точки зору ULP (одиниці останнього місця), що стосується двійкових цифр поплавця.

Відповіді:


10

Якщо в документації не зазначається особлива згадка, чи мається на увазі, що ці види функцій повністю точні до останнього десяткового знаку, в межах точності, що пропонується IEEE з плаваючою точкою подвійної точності?

Я б не зробив цього припущення.

Там, де я працюю, ми маємо справу з даними телеметрії, і загальновідомо, що дві різні математичні бібліотеки можуть давати два різні результати, навіть якщо обидві відповідають стандартам IEEE з плаваючою точкою. Це має наслідки, коли ви намагаєтесь повторити обчислення та порівняти два результати для рівності.

Здається, що абонент кладе на себе тягар, щоб канонізувати вхід для отримання оптимальної точності.

Це справедлива оцінка. Прийнятним є те, що в документації зазначено, щоб не було сюрпризів.

З іншого боку, документація Mozilla ...

Я пропоную спробувати кілька обчислень у кожній бібліотеці чи мові програмування (особливо поблизу межових областей, таких як sin()поблизу кратного pi), і порівняти їх. Це має дати точне уявлення про те, якої поведінки ви можете очікувати від кожного.


2
Тест - хороша ідея. Існує незліченна кількість разів, коли документація говорить одне, але функції поводяться по-іншому. І ОП хочуть покластися на неявні припущення, які навіть не задокументовані.
Сіюань Рен
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.