Що можна зробити з мовами програмування, щоб уникнути підводних каменів з плаваючою точкою?

Нерозуміння арифметики з плаваючою комою та її коротких приходів є головною причиною здивування та плутанини в програмуванні (врахуйте кількість запитань щодо переповнення стека, що стосуються "чисел не додається правильно"). Зважаючи на те, що багато програмістів ще не зрозуміли її наслідків, він має потенціал ввести багато тонких помилок (особливо у фінансовому програмному забезпеченні). Що можуть зробити мови програмування, щоб уникнути своїх підводних каменів для тих, хто не знайомий з поняттями, при цьому все ж пропонуючи його швидкість, коли точність не є критичною для тих, хто розуміє ці поняття?

Ви кажете "особливо для фінансового програмного забезпечення", яке виховує одного з моїх вихованців: гроші - це не поплавок, це int .

Звичайно, це схоже на поплавок. У ньому є десяткова крапка. Але це лише тому, що ви звикли до одиниць, які плутають проблему. Гроші завжди надходять у цілих кількостях. В Америці це центи. (У певних контекстах я думаю, що це можуть бути млини , але поки що це ігноруйте.)

Отже, коли ви кажете 1,23 долара, це дійсно 123 копійки. Завжди, завжди, завжди займайся математикою в цих умовах, і ти будеш добре. Для отримання додаткової інформації див:

• Мартіна Фаулера Кількість і Гроші моделі
• Його книги Шаблони архітектури прикладних програм та моделей підприємств
• Вікіпедія про округлення банкіра

Відповідаючи на питання безпосередньо, мови програмування повинні просто включати тип Гроші як розумний примітив.

оновлення

Гаразд, я повинен був сказати "завжди" двічі, а не три рази. Гроші справді завжди є int; ті, хто думає про інше, можете спробувати надіслати мені 0,3 копійки та показати результат у вашій банківській виписці. Але як зазначають коментатори, трапляються рідкісні винятки, коли потрібно робити математику з плаваючою комою на грошових числах. Наприклад, певні види цін або розрахунки відсотків. Вже тоді до них слід ставитися як до винятків. Гроші надходять і виходять як цілі кількості, тож чим ближче ваша система прислухається до цього, тим безпечніше буде.

Надання підтримки типу Decimal допомагає у багатьох випадках. Багато мов мають десятковий тип, але вони не використовуються.

Розуміння наближення, яке виникає при роботі з поданням дійсних чисел, є важливим. Використання як десяткових, так і типів з плаваючою комою 9 * (1/9) != 1є правильним твердженням. Коли константи оптимізатор може оптимізувати обчислення, щоб він був правильним.

Надання приблизного оператора допоможе. Однак такі порівняння є проблематичними. Зауважимо, що .9999 трлн доларів приблизно дорівнює 1 трлн дол. Не могли б ви внести різницю на мій банківський рахунок?

Нам сказали, що робити на першому курсі (другокурсник) лекції з інформатики, коли я вступив до університету (цей курс був обов'язковою умовою для більшості курсів наук)

Я пригадую лектора, який сказав: "Числа з плаваючою комою - це наближення. Використовуйте цілі типи грошей. Використовуйте FORTRAN або іншу мову з номерами BCD для точного обчислення". (а потім він вказав на наближення, використовуючи той класичний приклад 0,2, який неможливо точно представити у двійковій плаваючій точці). Це також виявилося того тижня в лабораторних вправах.

Ця ж лекція: "Якщо вам потрібно отримати більшу точність з плаваючою точкою, відсортуйте свої умови. Додайте невеликі числа разом, а не великі числа". Це застрягло в моїй свідомості.

Кілька років тому у мене була якась сферична геометрія, яка мала бути дуже точною і все-таки швидкою. 80-бітний подвійний на ПК не був його скороченням, тому я додав до програми деякі типи, які сортували умови перед виконанням комутативних операцій. Проблема вирішена.

Перш ніж скаржитися на якість гітари, навчіться грати.

Чотири роки тому у мене був колега, який працював у JPL. Він висловив невіру, що ми використовували FORTRAN для деяких речей. (Нам потрібні були супер точні числові симуляції, розраховані в автономному режимі.) "Ми замінили все це FORTRAN на C ++", - гордо сказав він. Я перестав цікавитись, чому вони пропустили планету.

Попередження: System з плаваючою комою не має точності для прямого тестування рівності.

double x = CalculateX();
if (x == 0.1)
{
    // ............
}

Я не вірю, що щось можна чи потрібно робити на мовному рівні.

За замовчуванням мови повинні використовувати довільну точність раціоналів для не цілих чисел.

Ті, кому потрібно оптимізувати, завжди можуть просити поплавці. Використання їх як замовчуванням має сенс у C та інших мовах програмування систем, але не в більшості популярних сьогодні мов.

Дві найбільші проблеми, пов’язані з числами з плаваючою комою:

• непослідовні одиниці, застосовані до обчислень (зауважте, це так само впливає на цілу арифметику)
• нерозуміння того, що числа FP - це наближення і як розумно поводитися з округленням.

Перший тип відмови можна усунути лише шляхом надання складеного типу, що включає значення та інформацію про одиниці. Наприклад, a lengthабо areaзначення, що включає одиницю (метри або квадратні метри або фути і квадратні фути відповідно). В іншому випадку ви повинні бути ретельними щодо того, щоб завжди працювати з одним типом одиниці вимірювання і перетворюватися на інший лише тоді, коли ми ділимося відповіддю з людиною.

Другий тип відмови - це концептуальний збій. Невдачі проявляються, коли люди вважають їх абсолютними числами. Це впливає на операції рівності, кумулятивні помилки округлення тощо. Наприклад, може бути правильним те, що для однієї системи два вимірювання еквівалентні в межах певного похибки. Тобто .999 і 1.001 приблизно збігаються з 1,0, коли вам не байдуже відмінності, менші за +/- .1. Однак, не всі системи такі поблажливі.

Якщо потрібен якийсь рівень мовного рівня, я б назвав це точністю рівності . У NUnit, JUnit і аналогічно побудованих тестових рамах ви можете контролювати точність, яку вважають правильною. Наприклад:

Assert.That(.999, Is.EqualTo(1.001).Within(10).Percent);
// -- or --
Assert.That(.999, Is.EqualTo(1.001).Within(.1));

Якщо, наприклад, C # або Java були змінені, щоб включити оператор точності, це може виглядати приблизно так:

if(.999 == 1.001 within .1) { /* do something */ }

Однак, якщо ви надаєте подібну функцію, вам також доведеться враховувати випадок, коли рівність хороша, якщо сторони +/- не однакові. Наприклад, + 1 / -10 вважає два числа еквівалентними, якби одне з них було в межах 1 більше, або на 10 менше, ніж перше число. Для вирішення цього випадку вам може знадобитися також додати rangeключове слово:

if(.999 == 1.001 within range(.001, -.1)) { /* do something */ }

Що можуть робити мови програмування? Не знаю, чи є одна відповідь на це питання, оскільки все, що компілятор / перекладач робить від імені програміста для полегшення його життя, зазвичай працює проти продуктивності, ясності та читабельності. Я думаю, що і спосіб C ++ (платити лише за те, що потрібно), і спосіб Perl (принцип найменшого здивування) є дійсними, але це залежить від програми.

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

Я переймаюся тим, що повинен знати програміст:

• Які типи з плаваючою комою доступні в системі та мовою
• Який тип потрібен
• Як висловити наміри того, який тип потрібен у коді
• Як правильно скористатися будь-яким автоматичним просуванням типу, щоб збалансувати чіткість та ефективність, зберігаючи правильність

Що можуть зробити мови програмування, щоб уникнути [плаваючої точки] підводних каменів ...?

Використовуйте розсудливі значення за замовчуванням, наприклад вбудовану підтримку децималів.

Groovy робить це досить непогано, хоча, доклавши трохи зусиль, ви все одно можете написати код, щоб ввести неточність з плаваючою комою.

Я погоджуюся, що на мовному рівні робити нічого. Програмісти повинні розуміти, що комп'ютери дискретні та обмежені, і що багато математичних понять, представлених у них, є лише наближеннями.

Неважливо, плаваюча точка. Треба розуміти, що половина бітових шаблонів використовується для від'ємних чисел і що 2 ^ 64 насправді досить мало, щоб уникнути типових проблем із цілою арифметикою.

Можливо зробити одне, що можна зробити - видалити порівняння рівності з типів з плаваючою точкою, крім прямого порівняння зі значеннями NAN.

Тестування рівності існувало б лише як функція виклику, яка приймала два значення та дельту, або для мов, таких як C #, які дозволяють типам мати методи EqualsTo, що приймає інше значення та дельту.

Мені здається дивним, що ніхто не вказав на раціональну кількість хитрощів родини Лісп.

Серйозно, відкрийте sbcl і зробіть це так: (+ 1 3)і ви отримаєте 4. Якщо *( 3 2)ви отримаєте 6. Тепер спробуйте, (/ 5 3)і ви отримаєте 5/3, або 5 третин.

Це може дещо допомогти в деяких ситуаціях, чи не так?

Одне, що я хотів би бачити, - це визнання того, що doubleйого floatслід розглядати як розширення конверсії, тоді як floatдо doubleзвуження (*). Це може здатися протиінтуїтивно зрозумілим, але врахуйте, що типи означають насправді:

• 0,1f означає "13,421,773,5 / 134,217,728, плюс-мінус 1 / 268,435,456 або близько того".
• 0,1 дійсно означає 3,602,879,701,896,397 / 36,028,797,018,963,968 плюс або мінус 1 / 72,057,594,037,927,936 або так "

Якщо один має a, doubleякий найкраще відображає кількість "десята частина" і перетворює його floatв результат, то це буде "13,421,773,5 / 134,217,728 плюс або мінус 1 / 268,435,456 або так", що є правильним описом значення.

На противагу цьому, якщо у людини є a, floatяка найкраще відображає кількість "десята частина" і перетворює її в double, результат буде "13,421,773,5 / 134,217,728, плюс або мінус 1 / 72,057,594,037,927,936 або так" - рівень мається на увазі точності що неправильно в коефіцієнті понад 53 мільйони.

Хоча стандарт IEEE-744 вимагає, щоб математика з плаваючою комою виконувалася так, як ніби кожне число з плаваючою комою представляє точну числову величину саме в центрі його діапазону, що не слід вважати, що значення з плаваючою комою насправді представляють саме такі точні числові величини. Швидше, вимога про те, щоб значення вважалися в центрі їх діапазонів, випливає з трьох фактів: (1) обчислення повинні виконуватися так, ніби операнди мають якісь конкретні точні значення; (2) послідовні та задокументовані припущення є кориснішими, ніж суперечливі або недокументовані; (3) якщо можна зробити послідовне припущення, жодне інше послідовне припущення не може бути кращим, ніж припущення, що величина являє собою центр його діапазону.

Між іншим, я пам’ятаю, якихось 25 років або близько тому хтось придумав пакет із числовими номерами для C, який використовував «типи діапазону», кожен з яких складався з пари 128-бітних плавців; всі обчислення будуть зроблені таким чином, щоб обчислити мінімальне та максимально можливе значення для кожного результату. Якщо хтось зробив великий тривалий ітеративний розрахунок і придумав значення [12.53401391134 12.53902812673], можна бути впевненим, що хоча багато цифр точності втрачено на помилки округлення, результат все одно може бути розумно виражений як 12,54 (і це не було " t дійсно 12,9 або 53,2). Я здивований, що я не бачив жодної підтримки таких типів на будь-яких основних мовах, тим більше, що вони здадуться добре підходити до математичних одиниць, які можуть працювати паралельно на кількох значеннях.

(*) На практиці часто корисно використовувати значення подвійної точності для проведення проміжних обчислень під час роботи з одноточними числами, тому необхідність використання набору тексту для всіх таких операцій може бути прикрою. Мови могли б допомогти, маючи тип "нечіткий подвійний", який би виконував обчислення як подвійні, і їх можна було вільно передавати на одиничні та з них; це було б особливо корисно, якби функції, які приймають параметри типу doubleта повернення, doubleмогли бути позначені таким чином, що вони автоматично генерують перевантаження, яка приймає та повертає "нечіткий подвійний" замість цього.

Якщо більше мов програмування зайняло сторінку з баз даних і дозволило розробникам визначати довжину та точність їх числових типів даних, вони могли істотно зменшити ймовірність помилок, пов'язаних з плаваючою комою. Якщо мова дозволила розробнику оголосити змінну як Float (2), що вказує на те, що їм потрібно число з плаваючою комою з двома десятковими цифрами точності, воно може виконувати математичні операції набагато безпечніше. Якщо це зробити, представляючи змінну внутрішньо цілим числом і діливши на 100, перш ніж виставляти значення, воно могло б підвищити швидкість, використовуючи швидші цілі арифметичні шляхи. Семантика Float (2) також дозволить розробникам уникати постійної потреби округляти дані перед виведенням їх, оскільки Float (2) по суті буде округляти дані до двох десяткових знаків.

Звичайно, вам потрібно дозволити розробнику запитати про максимальну точність значення з плаваючою комою, коли розробнику потрібно мати цю точність. І ви б запровадили проблеми, коли дещо різні вирази однієї математичної операції дають потенційно різні результати через проміжні операції округлення, коли розробники не мають достатньої точності у своїх змінних. Але, принаймні, у світі баз даних це здається не надто великою угодою. Більшість людей не роблять таких наукових розрахунків, які вимагають великої точності в проміжних результатах.

• мови мають підтримку типу Decimal; звичайно, це насправді не вирішує проблему, все ж у вас немає точного та кінцевого представлення, наприклад ⅓;
• деякі БД і рамки мають підтримку типу Money, це в основному зберігає кількість центів як ціле число;
• є кілька бібліотек для раціональної підтримки чисел; що вирішує задачу ⅓, але не вирішує задачу, наприклад, √2;

Зазначені вище застосовні в деяких випадках, але насправді не є загальним рішенням для поводження з плаваючими значеннями. Справжнє рішення - зрозуміти проблему і навчитися її вирішувати. Якщо ви використовуєте обчислення з плаваючою точкою, завжди слід перевірити, чи є ваші алгоритми чисельно стійкими . Існує величезна область математики / інформатики, яка стосується проблеми. Це називається числовий аналіз .

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

Функції, призначені для імпортування оцінок з плаваючою комою, повинні бути чітко позначені як такі та забезпечені параметрами, відповідними цій операції, наприклад:

Finance.importEstimate(float value, Finance roundingStep)

Єдиний реальний спосіб уникнути підводних каменів з плаваючою комою взагалі - це освіта - програмістам потрібно читати та розуміти щось на кшталт того, що повинен знати кожен програміст про арифметику з плаваючою комою .

Кілька речей, які можуть допомогти:

• Я другого, хто запитає, "чому точне тестування рівності для плаваючої точки навіть законне?"
• Натомість використовуйте isNear()функцію.
• Забезпечувати та заохочувати використання об'єктів акумулятора з плаваючою комою (які стабільніше додають послідовності значень з плаваючою комою, ніж просто додавати їх у звичайну змінну з плаваючою точкою).

Більшість програмістів будуть здивовані, що COBOL отримав таке право ... у першій версії COBOL не було плаваючої точки, лише десяткової, і традиція в COBOL тривала до сьогодні, що перше, про що ви думаєте, коли оголошуєте число, - це десятковий. .. плаваюча точка використовуватиметься лише в тому випадку, якщо вона вам справді потрібна. Коли C прийшов, чомусь не було примітивного десяткового типу, тож, на мою думку, саме тут почалися всі проблеми.