ValeryS
Если вы считаете что 1.5>1.0 это тоже самое что 1.25>1
тогда извините
А вот я сейчас спрошу, почему должно быть "то же самое", и ты не сможешь ответить.
Давай по порядку. Вот просто по-тупому.
Представим, что есть такой очень хреновый тип данных, для которого 1,125 уже неотличимо от 1, а всё, что больше, отличимо. Ну так, чтобы шагов поменьше было.
Первый код.
Первый оборот цикла: е=0,5, а=1,25, счётчик=1, а отличается от 1, продолжаем.
Второй оборот цикла: е=0,25, а=1,125, счётчик=2, а не отличается от 1, остановились.
Результат: е=0,25, 2 шага.
Второй код.
Первый оборот цикла: сравниваем 1,5 и 1, различается, считаем дальше, е=0,5, счётчик=1.
Второй оборот цикла: сравниваем 1,25 и 1, различаются, считаем дальше, е=0,25, счётчик=2.
Третий оборот цикла: сравниваем 1,125 и 1, не различаются, выходим из цикла.
Результат: е=0,25, 2 шага.
А теперь ткни пальцем, что тут неправильно. Единственная неточность - второй код делает три шага, а у меня выводится два. Похрен, мне надо было оценить порядок величины, проблема вообще не в этом.
Ага, не верь глазам своим (с) Козьма Прутков.
Ты тему-то читал? В Qt Creator и Builder второй код даёт то же самое при любых типах из перечисленных, что и при long double. И именно в этом, если ты не заметил, и состоит проблема. Онлайн-IDE выдаёт абсолютно аналогичные результаты и при float, и при double, и при long double для обоих кодов. Собственно в этом и проблема - в Qt Creator и Builder происходит хреновина. ПРОБЛЕМА НЕ В ЛОГИКЕ ВЫЧИСЛЕНИЯ ЭПСИЛОН. ПРОБЛЕМА В СТРАННОМ ПРЕОБРАЗОВАНИИ ТИПА, КОТОРОГО НЕ ДОЛЖНО БЫТЬ, НО ПРОИСХОДИТ.
Люди, вы чего? Уже второй чудесатый "ответ" в теме. Да с каким гонором-то. Жара что ли так действует?
