За что математики не любят компьютерную арифметику

[vak]

#include <stdio.h>
int main ()
{
    if (-5.2 + 4.9 != -0.3) {
        printf("Oops!\n");
    }
    if (4.8 - 6.1 != -1.3) {
        printf("Oops!\n");
    }
    if (4.3 - 3.6 != 0.7) {
        printf("Oops!\n");
    }
}

Это мне надо было простенький тестик сварганить по работе, суммировать плавающие числа, а оно вон как боком выскочило.

Comments

nz

[nz]

Зачем так сложно, 0.1 + 0.2 != 0.3 же.

Re: nz

[vak]

Тоже верно. Упростил у себя.

[ichthuss]

Кто использует с плавающими типами сравнения "==" и "!=", кроме очень специальных случаев, тот сам себе злобный буратино.

Тестик, в принципе, относится к этим специальным случаям. Тут можно воспользоваться простым подходом: использовать числа, кратные 1/2^n, где n < 24. Например, 0.25+0.375

[vak]

Я хардвер проверяю. Результат должен точно совпадать с предсказанным.

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

[perdakot]

Я хардвер проверя

Тогда, наверное, надо float раздербанить на знак, экспоненту и мантиссу (целые) и сравнивать их, а не плавучку.

C#

[dennisgorelik]

In C# floating point calculations are not precise too:

[TestMethod]
public void FloatingPointCheck()
{
	Assert.AreEqual(0.2, 0.1 + 0.1); // Passes
	Assert.AreEqual(3.0, 1.0 + 2.0); // Passes
	Assert.AreEqual(0.3, 0.1 + 0.2); // Fails
}

[ircicq]

Есть полезная статья G. Steele, Jon L. White - How to print floating-point numbers accurately

Там про десятичную печать, но алгоритм можно применить и для сравнения.

[vak]

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

десятичное 0.1 = двоичное 0.0001100110011(0011)

Бесконечную двоичную дробь приходится укорачивать. Возникает погрешность.

Re: C#

[vak]

Calculations are OK. Decimal representations are imprecise.

[perdakot]

Это без разницы, сравнивать три поля по отдельности или всё слово целиком.

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

[juan_gandhi]

Вечная тема. вообще говоря, вопрос равенства вещественных чисел и теоретически сложен. Проще считать, что это не эквациональная теория.

[vak]

Компиляторы не могут нести отсебятину. Функция strtod(), превращающая строку в плавающее число, не ошибается, даже в самых младших битах мантиссы. Я тщательно проверял.

[vak]

Да у меня чистая практика: подал числа на вход хардвера, получил ответ на выходе. Некогда теоретизировать, трясти надо.

[juan_gandhi]

Ну ты прям физик.

Мы не такие. Я когда-то эмулятор FPP писал, так обнаружил, что могу вполне, на тех 80 битах, выдать точность выше, чем настоящий FPP гонит. Там же еще один запасной бит был, не в регистрах, а в процессе вычислений.

[archaicos]

Кажется, у мелкософта было... Вот:
https://www.exploringbinary.com/double-rounding-errors-in-floating-point-conversions/
И ещё рядышком:
https://www.exploringbinary.com/incorrectly-rounded-conversions-in-visual-c-plus-plus/

[archaicos]

Используй шестнадцатеричные вещественные константы типа 0x1p-1. Их уже давно завезли в С и C++.

[vak]

Шестнадцатеричные вещественные литералы это выход, да. Если бы дело было только в Си, я бы ничтоже сумняшеся. Однако числа ещё могут появляться из нашего доморощенного ассемблера. Мне пока стрёмно добавлять в него шестнадцатеричные ужасы. Но может придётся.

[archaicos]

Если он на плюсах, то стандартная библиотека конвертнёт, надо лишь распарсить.
Если на питоне, то надо поискать, может тоже простое решение. Хотя, шестнадцатеричное можно и самому преобразовать, т.к. сложное уже отсутствует.

если на плюсах ...

[h1uke]

или на Питоне лезть на этот уровень --
то поневоле вспоминаешь древнюю формулу: "со свиным рылом в калашный ряд" :)

будто эти ваши плюсы, или там Питон - это не программы, написанные изначально на "лысом С"

[sobriquet9]

Есть же DBL_EPSILON и std::numeric_limits::epsilon().

[vak]

Ну уж нет, в нашем вычислителе дважды два должно получаться ровно четыре, а не "сэм-восэм", как в анекдоте. 😀

[dijifi]

В начале моей карьеры видел я квадратный корень из четырех равный единице, но только для инструкции single precision. Глючный микрокод у железа. Так, вспомнилось.

[dijifi]

В начале моей карьеры видел я квадратный корень из четырех равный единице, но только для инструкции single precision. Глючный микрокод у железа. Так, вспомнилось.

[sobriquet9]

Так оно и получается. Даже с дробями всё точно, только в двоичной системе. Хотите, чтоб в десятичной было точно - переделайте вычислитель, чтоб он считал в десятичной системе. Такое вроде уже ж было, какие-то компьютеры внутри себя считали всё в BCD.

А ещё лучше сразу в шестидесятиричной, как у древних египтян. Тогда на три тоже делить удобно будет.

Re: C#

[dennisgorelik]

Is there a convenient way to use more precise representation?

Re: C#

[ircicq]

Type `decimal` in many programming languages including C#
Although it is slower

Re: C#

[dennisgorelik]

Oh.
vak meant "data representation in computer memory" (floating-point double vs decimal).
I thought he meant representation/conversion of data to decimal string.

In any case, the primary way to deal with imprecision is not increasing precision, but replacing number equality comparison with [epsilon] range comparison.

[vak]

Hex literals work fine. Not much human friendly though.

#include <stdio.h>
int main ()
{
    printf("%a\n", -0x5.2p0 + 0x4.9p0);
    printf("%a\n", 0x4.8p0 - 0x6.1p0);
    printf("%a\n", 0x4.3p0 - 0x3.6p0);
}

Результат:

-0x1.2p-1
-0x1.9p+0
0x1.ap-1

[dennisgorelik]

> Hex literals work fine.

Hex interface is a good workaround.
But it may be hard to convince end users to use hex interface, right?

[waqur]

Не зря в банковской сфере так популярен COBOL, у которого развитая система целочисленных типов фиксированной ширины в десятичном представлении. Банкиры ещё в 70-е были не в восторге от всех этих фокусов с округлением вещественных чисел с плавающей точкой.

[vak]

Ага, я тоже про Кобол вспомнил. Его арифметика одинаково точно работает (хоть и медленно) на любой компьютерной архитектуре.