Почему значение типа плавающей точки уменьшается?

Question

[versidue]

0.1 в двоичном представлении имеет следующий вид:
0.10000000000000000555111512312578

double value = 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1;

std::cout << std::setprecision(32);
std::cout << value << "\n\n";

Почему результат 0.99999999999999988897769753748435?
Ведь число явно должно быть больше 1, а не меньше.

Comments

[Евгений Шатунов]

versidue , а ты с IEEE-754 знаком?

[versidue]

Евгений Шатунов, сильно не углублялся, лишь поверхностно

[versidue]

Евгений Шатунов, так почему происходит? При их сложении неточные части тоже должны складываться и попадать в значащую часть, разве нет?

[Евгений Шатунов]

versidue, на результат каждой операции влияет некоторая накопительная ошибка. Методики округления малых величин могут приводить как к незначительному увеличению значения, так и к незначительному уменьшению.
Ты не можешь просто взять и утверждать что раз 0.1 представляется каким-то одним образом, то и результат сложения числа десять раз должен быть больше 1.0.

Результат твоих 9 сложений будет где-то близко к 1.0 в пределах отклонения, не дальше чем на std::numeric_limits<double>::epsilon() [?]. Именно так и обеспечивается точность операций по IEEE-754.
Т.е. результат может оказаться незначительно больше 1.0, а может оказаться незначительно меньше.
И именно это демонстрируется в твоем вопросе, т.к. эпсилон для типа double находится за 15м знаком после запятой.

[versidue]

Евгений Шатунов, видимо придется глубже копаться в этом ieee-754

[res2001]

Евгений Шатунов, versidue,

Результат твоих 10 сложений будет где-то близко к 1.0 в пределах отклонения, не дальше чем

Думаю, что не дальше чем epsilon*10, т.к. каждое сложение будет добавлять свою ошибку.
Но учитывая, что ошибка может быть как в плюс, так и в минус, то суммарная ошибка стремится к нулю, но, конечно, нулем никогда не будет (разве что сильно повезет).

[Евгений Шатунов]

res2001,

В какую сторону и на сколько будет погрешность, думаю, это можно посчитать, но для этого надо копнуть глубже.

Оставлю комментарий по этому поводу.
Там не будет отклонение до epsilon*10 потому что каждая следующая операция выполняется на результате предыдущей, а ее результат округляется согласно правилам в IEEE-754 чтобы вписаться в допустимый набор бит.
Всего IEEE-754 определяет 4 вида округления. Какой конкретный вид будет использован в результате операции, стандарт отдает на реализацию процессорам. Чаще всего применяется подход, при котором вид округления зависит от состояния хвоста результата. Если в хвосте биты в одном порядке, одним способом, если биты в другом порядке - то другим. Распределение вариантов равномерное. Таким образом достигается стремление результата к точному значению на большом количестве операций.
Поэтому из 9 сложений половина отклонит результат в большую сторону, а вторая половина - в меньшую. Сам же результат так и останется в пределах одного эпсилон от идеального значения.

Этот самый std::numeric_limits<T>::epsilon() и означает допустимый предел отклонения результата от идеального.

[res2001]

Евгений Шатунов,

Поэтому из 9 сложений половина отклонит результат в большую сторону, а вторая половина - в меньшую. Сам же результат так и останется в пределах одного эпсилон от идеального значения.

Если операнды представлены точными числами, то вы правы - погрешность будет в пределах epsilon.
Но операнды из примера автора уже содержат в себе погрешность (в каждом по epsilon). Вот и получится 10*epsilon для 10 сложений (это для нашего конкретного примера) - просто идеально сложили 10 операндов содержащих погрешность.
А теперь к этим 10*epsilon добавьте еще погрешность результата (предположим, что погрешности промежуточных результатов компенсировались и осталась только погрешность последнего вычисления). Будет 11*epsilon в худшем случае.

Помнится как-то была у меня задача, очень похожая на пример автора, где в цикле надо было что-то посчитать. Один из множителей в формуле был коэффициент, зависящий от индекса цикла, т.е. примерно так: f = i * const, где i - целый индекс цикла, const - константное число с плавающей точкой. Дальше f использовалась как множитель в формуле.
Сначала в целях некоторой оптимизации я считал f так: f += const - сложение чисел с плавающей точкой работает быстрее, чем умножение.
В итоге формула давала достаточно существенную погрешность, с которой нельзя было мирится.
Когда я заменил вычисление f через умножение, то существенная погрешность исчезла.
Просто много сложений в конечном счете накапливают погрешность и через какое-то количество итераций погрешность начинает выходить за рамки допустимого. А при умножении погрешность минимальная и не копится.
В моем примере расчет велся во float, поэтому существенная погрешность проявлялась достаточно быстро.

[Евгений Шатунов]

res2001, да, я видимо где-то все-таки запутался в понимании всего этого. Я тоже хорошо помню такое поведение, как ты в примере описываешь.

Answer 1

[res2001]

Числа с плавающей точкой по определению приближенные. Каждая операция над подобными числами вносит свою погрешность в результат. Так что не стоит удивляться. В какую сторону и на сколько будет погрешность, думаю, это можно посчитать, но для этого надо копнуть глубже.
Для проверки можете просто вывести результат 2 сложений, потом трех, ... А так же проверьте результат умножения.
Тут много интересного можно для себя открыть.
Так же небезъинтересно сравнить результат одних и тех же вычислений над double и float.
Даже и не надейтесь в плавающей точке получить какой-то точный результат. Если нужна точность, то надо использовать фиксированную точку.

Answer 2

[maaGames]

Видимо, потому что 0,1 это не 0,1 и числа с плавающей точкой ничего не должны. Не говоря о том, что это выражение могло быть при компиляции сосчитано непонятно какими числами либо могло быть заменено на умножение, либо было заменено на умножение ещё при вычислении результата в момент компиляции...