.лядь...

тем, что выражение вида
x = x+1
когда x - целочисленного типа, обязано либо поменять значение x, либо вызвать ошибку времени выполнения.

А для типа double изменение исходного значения x таким выражением не гарантировано.

Если вам не нравится 1, напишите вместо него 1000000, с тем же результатом - изменение значения double не гарантируется.
Double близко расположены друг к другу вблизи нуля, с увеличением расстояния по краям.
С учетом максимально выразимых в double значений, вам не поможет ни миллиард, ни триллион. Добавляйте сразу гугол.

Это невинный ребенок 5 лет способен понять.
А если это не понятно в 12, то вся будущая жизнь программиста будет прожита зря.

лучше бы вы свой настоящий вопрос сформулировали, чем загадками разговаривать.
Если вопрос в том, а как же складывать double-значения?

То ответ на него не требует двух страниц:
используйте сложение по Кахану (компенсационное суммирование, William Kahan)

Есть альтернативный алгоритм - сложение на счетной линейке (абаке).
Он старше, в среднем обеспечивает чуть меньшую точность, но в отсутствии знакопеременности,
и в случае, когда каждое из слагаемых мало отличается по величине, обеспечивает приемлемую и скорость и точность.

ясно.
то есть, вопроса у вас нет.
Тоже хорошо.

Да вы поэт.
Но вам не хватает точности цитирования.
Говорилось вам следующее: в общем случае, при использование одного и того же вычислительного процесса,
на одних и тех же входных данных, нет гарантий, для типа double будет получено одно и то же двоичное представление значения.

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

Так, простое суммирование ряда значений double, суммирование по Кахану и суммирование "на абаке" не просто дадут три разных значения,
но и для каждого из алгоритмов результат окажется зависимым от последовательности подачи на вход вход сумматора значений из складываемого набора, при том, что сам набор, как мультимножество значений, остается неизменным.

С учетом того, что, что вы не всегда знаете последовательности исходных данных и особенности используемых алгоритмов,
песня состоит в предложении считать сочетание понятий "значение типа double" и "детерминированная функция" - оксюмороном.

А уж смешит это вас или печалит - это вопрос о том, как совсем малый культур-мультур в области вычислений получить.

Вам, кстати, как любителю статистических вычислений, должен быть известен такой термин - робастность .
Для алгоритмов, предназначенных для использования в комбинации со значениями типа double - это самостоятельный
технический термин, являющийся характеристикой алгоритма .

Он и пишется и звучит не так, как пишется и звучит "встроенная функция".

Вы бы распечатали это, лучше покрупнее.
Да и разглядывали вдумчиво перед сном.

образование вьюноши начинается совершенно с другого конца.
понятие "одно и то же значение" для типа double - плохо определено .

Имеет значение не только манера сравнения, но и манера выполнения операций.
Ни сложение, ни умножение для double не ассоциативны. a*(b*c) не обязано быть равным (a*b)*c, вне зависимости от того,
что представляет собой * - сложение или умножение.

Да, конкретно для корня вычисление стандартизировано вообще в исходном стандарте IEEE-754 1985г, в отличие от синусов, например, и прочих "библиотечных функций".
И, конкретно корень, конкретно из 2, на двух процессорах одной модели одного и того же производителя, почти наверно
даст в точности то же самое двоичное представление.
Но это не повод для того, чтобы оценивать равенство значений двух переменных по равенству хранящихся в них двоичных представлений.

поищите, при случае, в гугле "мифы о вычислениях с плавающей точкой".
Вот вам миф номер два:
"Арифметические операции детерминированы. Поэтому, если я вычисляю z = x + y в двух местах программы так,
что нигде не изменяю значения x и y между этими вычислениями z, то результат, записанный в z должен быть одним и тем же".

между "вычислимо" и "имеет смысл" - пропасть размером во вселенную.
Результаты вычислений выражений на значениях типа double могут не иметь арифметического смысла,
ввиду катастрофической потери точности при вычислениях. Например, при вычитании или делении.
Это, надеюсь, вам известно.

Из-за этой, в частности, особенности прямые сравнения, вне специфического контекста, не имеют смысла.
Если вам известно, что в x сидит 10, а в y - 5, то без дополнительной информации нельзя ответить на вопрос - должны ли эти значения быть признаны за несомненно равные или безусловно различные.

Кстати, а когда придет ваша очередь ответить на вопрос - что же именно вы хотели сказать, или о чем спросить, в своем стартовом посте?

В "инженерных расчётах", ради которых и придумывались double, не принято
сравнивать результаты без учета относительной ошибки, накопленной в процессе счета.

А если процесс оказался таким, что в мантиссе итога не осталось ни одной точной значащей цифры предполагаемого результата,
то на руках у вас просто мусор, который не с чем сравнивать.
Поэтому вас обманывают, когда говорят, что вы всегда можете округлить и потом сравнить.
Может оказаться так, что округлять не к чему.

Про рациональные числа - надеюсь, вы понимаете, что вообще представимы в компьютере лишь некоторые рациональные числа,
даже если речь не идет о фиксированных представлениях.
1/3, например, не представима ни в какой конечной двоичной форме.

последняя попытка.
Попробуйте помедитировать над требованиями к равенству:



И с учетом того, что результат, вообще говоря, может оказаться "платформозависимым".

Утверждения такого сорта красиво смотрятся, когда дополнены фразами вида:
"технически мне это гарантирует то-то и сё-то", со ссылкой на конкретные обещалки, несоблюдение которых означает готовность обещателя принять претензию по этому поводу.

Это исторически не было так в железе со значениями вблизи нуля, и обычно, этого не гарантировали и библиотеки.
А те, что гарантировали, имели тенденцию выдавать неприемлемые результаты по другому поводу.

Даже если вам известны чьи-то твердые гарантии на эту тему, выданные к текущему моменту для актуального железа или среды,
осторожнее не закладываться на это.

Впрочем, up to you...

Этим и хорош double - не нравится +0, возьмите -0, не любите -inf, может NaN вам больше понравится?
А уж как хорош веер настроек внутреннего округления при сохранении значения выражения в переменную...

Особенно приятно, что ими прикладной программист почти никогда не рулит, а, в частности,
Classic VB-программист - никогда не рулит - ест то, что дают.

Поэтому, если вам оказалось угодно что-то типа - а не переписать ли мне это на языке имярек, то
отдельно приятна невоспроизводимость результата вычисления после переписывания.

А какое же это счастье, когда выходит новая версия хардварного вычислителя...
Вот еще вчера (0.3 * 3) + 0.1 не был равен 1#, а сегодня-то - аж истома по телу растекается.

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