Autoit разучился считать?

Ниже указан код, если его включить на тест и нажимать enter, то где-то к 5.76 число внезапно становится 5.7600000000001 и далее ошибка накапливается (число становится 5,25000...02).
Подскажите с чем это связано?

http://kuzelenkov.narod.ru/mati/book/inform/inform5.html

C2H5OH сказал(а):

http://kuzelenkov.narod.ru/mati/book/inform/inform5.html

Нажмите, чтобы раскрыть...

Изучил статью, перечитал, однако ответ в ней так и не нашел

babanty
с чем это связано?
Раздели 1 на 3, у тебя будет 3 в периоде. Есть дробные числа, которые нельзя представить в виде законченного числа, от этого на краю числа появляется округление. У Autoit по заявлению разработчиков есть функция борющаяся с этой проблемой, но видимо это грань где нельзя отбросить погрешность, ведь она может оказаться правильной.
Либо округляй до удобной тебе величины, либо если тебе нужна великая точность, то эта погрешность достаточно мала, для точности числа
Кстати, тема поднималась ни единожды.

AZJIO сказал(а):

babanty
с чем это связано?
Раздели 1 на 3, у тебя будет 3 в периоде. Есть дробные числа, которые нельзя представить в виде законченного числа, от этого на краю числа появляется округление. У Autoit по заявлению разработчиков есть функция борющаяся с этой проблемой, но видимо это грань где нельзя отбросить погрешность, ведь она может оказаться правильной.
Либо округляй до удобной тебе величины, либо если тебе нужна великая точность, то эта погрешность достаточно мала, для точности числа
Кстати, тема поднималась ни единожды.

Нажмите, чтобы раскрыть...

Единственный выход оказался округлять. Так ведь тут ситуация не такая как при 1/3 = 0,333..., тут вычитается из числа 6 одна сотая 24 раза, и на моменте "5.77-0.01" у него получается 5.76000000000001, то есть запустите этот код ниже и будет та же самая ошибка.


Если это связано с тем как записываются числа, то почему же это не работает в этих примерах:


Или в этом:

babanty
В десятичной системе тебе кажется очевидным числа 0,01, в двоичной системе очевидное выглядит как 0,(3) (тройка в периоде) и поэтому операция с таким числом несёт в себе неточность на краю, так как отсекается к примеру 9-ка на конце и если округлить было бы из 19 в 20, но отсекая становится 10.У тебя число на конце диапазона фальшивит. Ты вычисляешь в цикле 30 раз, естественно эта фальшь начинает влиять на крайний регистр числа. Ещё раз: то что тебе кажется очевидным в десятичной системе, не очевидно в двоичной системе. А лучший вариант, просто переведи число в двоичную систему и складывай их, каждый раз переводя результат в десятичную систему. И поймёшь в какой момент появляется погрешность.
Мне просто лень это делать, может в интернете есть статья, поищи. Но это не от языка зависит, а от формы представления числа и разрядности. Какую бы то не выбрал разрядность у тебя просто после пятидесяти нолей появится единичка, или после тысячи нолей. Твоя задача после вычисления откинуть две последние числа в 00 и вычислять с той же разрядностью.
Например 7 в двоичной системе 111, это как для десятичиной 999, или число 1024 выглядит как 10000000000, соответственно 1000 будет выглядеть не таким округлённым (1111101000) в десятичной системе.

Для представления чисел с плавающей запятой используются 64 бита, из них под мантиссу отводится 52.
Для выполнения операции с числом порядка 2+2, отнимаемая Вами 0,01, имеющая ненормализованное представление
1010001111010111000010100011110101110000101000111101 с порядком 2-6,
будет сдвинута до порядка 2+2 и её мантисса будет иметь вид
0000000001010001111010111000010100011110101110000101
что фактически является числом 0,00999999999999979
и отличается от 0,01 на 0,00000000000000021.
Поэтому, отнимая в цикле 0,01, Вы накапливаете погрешность и в итоге получаете ощутимую разницу,
а однократно отняв 5.77-0.01 или 6-(0.01*24)), вы не отловите накопление разницы.

:D