![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
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");
}
}
Это мне надо было простенький тестик сварганить по работе, суммировать плавающие числа, а оно вон как боком выскочило.
nz
Date: 2023-01-14 23:22 (UTC)Зачем так сложно,
0.1 + 0.2 != 0.3же.Re: nz
Date: 2023-01-14 23:24 (UTC)C#
Date: 2023-01-15 00:40 (UTC)[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 }Re: C#
Date: 2023-01-15 01:09 (UTC)Re: C#
Date: 2023-01-15 16:01 (UTC)Re: C#
Date: 2023-01-15 19:15 (UTC)Although it is slower
Re: C#
Date: 2023-01-15 20:40 (UTC)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.
no subject
Date: 2023-01-15 21:11 (UTC)#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); }Результат:no subject
Date: 2023-01-16 05:50 (UTC)Hex interface is a good workaround.
But it may be hard to convince end users to use hex interface, right?
no subject
Date: 2023-01-14 23:30 (UTC)Тестик, в принципе, относится к этим специальным случаям. Тут можно воспользоваться простым подходом: использовать числа, кратные 1/2^n, где n < 24. Например, 0.25+0.375
no subject
Date: 2023-01-14 23:44 (UTC)Да, я ровно к тому и пришёл: использовать только рациональные числа со знаменателем - степенем двойки.
no subject
Date: 2023-01-14 23:56 (UTC)Тогда, наверное, надо float раздербанить на знак, экспоненту и мантиссу (целые) и сравнивать их, а не плавучку.
no subject
Date: 2023-01-15 00:52 (UTC)Проблема в том, что большинство десятичных дробей не могут быть точно отображены в двоичное представление. Получаются бесконечные дроби, к примеру:
десятичное 0.1 = двоичное 0.0001100110011(0011)
Бесконечную двоичную дробь приходится укорачивать. Возникает погрешность.
no subject
Date: 2023-01-15 01:19 (UTC)Не может быть, что копиляторы могут сделать мантиссу немного разную у плавучего литерала?
no subject
Date: 2023-01-15 01:29 (UTC)no subject
Date: 2023-01-15 02:05 (UTC)https://www.exploringbinary.com/double-rounding-errors-in-floating-point-conversions/
И ещё рядышком:
https://www.exploringbinary.com/incorrectly-rounded-conversions-in-visual-c-plus-plus/
no subject
Date: 2023-01-15 00:47 (UTC)Там про десятичную печать, но алгоритм можно применить и для сравнения.
no subject
Date: 2023-01-15 01:29 (UTC)Вечная тема. вообще говоря, вопрос равенства вещественных чисел и теоретически сложен. Проще считать, что это не эквациональная теория.
no subject
Date: 2023-01-15 01:30 (UTC)no subject
Date: 2023-01-15 01:39 (UTC)Ну ты прям физик.
Мы не такие. Я когда-то эмулятор FPP писал, так обнаружил, что могу вполне, на тех 80 битах, выдать точность выше, чем настоящий FPP гонит. Там же еще один запасной бит был, не в регистрах, а в процессе вычислений.
no subject
Date: 2023-01-15 02:07 (UTC)no subject
Date: 2023-01-15 02:22 (UTC)no subject
Date: 2023-01-15 03:21 (UTC)Если на питоне, то надо поискать, может тоже простое решение. Хотя, шестнадцатеричное можно и самому преобразовать, т.к. сложное уже отсутствует.
если на плюсах ...
Date: 2023-01-15 04:08 (UTC)то поневоле вспоминаешь древнюю формулу: "со свиным рылом в калашный ряд" :)
будто эти ваши плюсы, или там Питон - это не программы, написанные изначально на "лысом С"
no subject
Date: 2023-01-15 05:53 (UTC)no subject
Date: 2023-01-15 06:17 (UTC)no subject
Date: 2023-01-15 06:40 (UTC)no subject
Date: 2023-01-15 08:02 (UTC)no subject
Date: 2023-01-15 14:22 (UTC)А ещё лучше сразу в шестидесятиричной, как у древних египтян. Тогда на три тоже делить удобно будет.
no subject
Date: 2023-01-18 11:08 (UTC)no subject
Date: 2023-01-18 18:17 (UTC)