Почему при достаточно малых значениях вещественного числа кол-во итераций при нахождении машинного эпсилон резко убывает?

Question

[barbedman]

В общем, есть такой участок кода:
cout<< "Wtite a num:";cin>>fNum;
fNum=pow(fNum,-5);
fMachineEps=fNum2=fNum;
do
{
fMachineEps/=2;
fNum=fNum2+fMachineEps;
++itersAmount;
}while(fNum>fNum2);
На входе мы получаем число 10(float) и возводим его в некоторую отрицательную степень, а затем находим для него машинный эпсилон, т.е., если я правильно понимаю, минимальное число, которое будет восприниматься машиной не как ноль, ну и считается кол-во итераций, которое остается стабильным(25) до 10^(-38). Дальше идет убывание по 3-4 итерации с каждой степенью. Почему это происходит? Я предполагаю, что дело в том, что При достижении таких значений я приближаюсь к минимально возможным значения типа данных float, поэтому требуется меньше вычислений.

Answer 1

[RedHairOnMyHead]

float максимально держит до +/-38 степени число.

Тут таблица размерностей типов.

Answer 2

[Mercury13]

Машинный эпсилон — это минимальное число, что 1 + ε ≠ 1. Так что, в принципе, ты вычислил его правильно, хоть код и студенческий. Но есть один нюанс.

Дело в том, что float и double бывают нормализованные и денормализованные. Что это такое?
Любое число в двоичной системе счисления начинается с единицы. Поэтому головная единица подразумевается и не хранится — т.н. «нормализованное число». НО: когда порядок 00…00, считается, что в голове НОЛЬ, а относительная погрешность сменяется абсолютной — это денормализованное число.

0 1010…00 00000001 = +0,1101₂×2⁻¹²⁷ — нормализованное число
0 1010…00 00000000 = +0,0101₂×2⁻¹²⁷ — денормализованное
0 0000…00 00000000 = +0,0000₂×2⁻¹²⁷. Ноль — тоже денормализованное число.

10⁻³⁸ — минимальное нормализованное число. 10⁻⁴⁵ — минимальное денормализованное, с мантиссой 0,00…001. Помнишь, я говорил, что в денормализованных числах относительная погрешность сменяется абсолютной в эти самые 10⁻⁴⁵ — потому чем меньше число, тем больше «типа-эпсилон».

10-байтовый extended, он же long double, насколько мне известно, не нормализован, т.е. головная единица там хранится явно. Но такая точность редко нужна, появляется перерасход памяти (2 или 6 байтов, в зависимости от процессора и его настроек), да и не слишком оптимизируют сопроцессоры под такие числа.