Здравствуйте, vadimcher, Вы писали:
V>Сколько будет (int)( (0.1+0.7)*10 )?
Да моли что буедт!
7 скорее всего, а если очень повезёт, то 8
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, <Аноним>, Вы писали:
А>7 будет. А>т/к компилятор как правило получает значения вещественных чисел приблизительно в диапазоне А>например 6.0 * 8.0 А>будет как 47.999999993. когда мы выделяем целую часть получается понятно что
А вот тут-то мы вас и поправим!
Оба числа, 6.0 и 8.0 представимы во float, поэтому ошибки представления не возникает. Далее, результат умножения не вылез из мантиссы, поэтому ошибки нормализации снова не возникает. Так что получаем чистые 48.0, округляемые вниз до 48
Что же касается 0.1, 0.7, 0.8 — они непредставимы ни в одном из плавающих типов (float, double, long double).
И компилятор, и процессор вольны привнести туда ряд ошибок, причём как вниз, так и вверх.
Здравствуйте, vadimcher, Вы писали:
V>Этюд-не этюд, но по крайней мере полезное упражнение.
V>Сколько будет (int)( (0.1+0.7)*10 )?
Неужели 0 ?
Re[2]: 0.8*10=?
От:
Аноним
Дата:
16.07.07 05:07
Оценка:
7 будет.
т/к компилятор как правило получает значения вещественных чисел приблизительно в диапазоне
например 6.0 * 8.0
будет как 47.999999993. когда мы выделяем целую часть получается понятно что
Здравствуйте, <Аноним>, Вы писали:
А>7 будет. А>т/к компилятор как правило получает значения вещественных чисел приблизительно в диапазоне
Скорее имелось ввиду совсем не время компиляции А>например 6.0 * 8.0 А>будет как 47.999999993. когда мы выделяем целую часть получается понятно что
6.0*8.0 будет 48.0
Спасибо автору за то, что заставил перечитать правило преобразования типов...
Здравствуйте, Кодт, Вы писали:
К>Что же касается 0.1, 0.7, 0.8 — они непредставимы ни в одном из плавающих типов (float, double, long double). К>И компилятор, и процессор вольны привнести туда ряд ошибок, причём как вниз, так и вверх.
посему, по хорошему, нужно запретить преобразование float'ов в int с помощью cast'ов и использовать floor, ceil и round (возможно свои).
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, vadimcher, Вы писали:
V>>Сколько будет (int)( (0.1+0.7)*10 )?
E>Да моли что буедт! E>7 скорее всего, а если очень повезёт, то 8
Как ни странно, это абсолютно правильный ответ.
Более того, что более неточный тип используется для 0.1 и для 0.7, тем скорее мы получим точный ответ 8. Я так думаю.
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, <Аноним>, Вы писали:
А>>7 будет. А>>т/к компилятор как правило получает значения вещественных чисел приблизительно в диапазоне А>>например 6.0 * 8.0 А>>будет как 47.999999993. когда мы выделяем целую часть получается понятно что
К>А вот тут-то мы вас и поправим! К>Оба числа, 6.0 и 8.0 представимы во float, поэтому ошибки представления не возникает. Далее, результат умножения не вылез из мантиссы, поэтому ошибки нормализации снова не возникает. Так что получаем чистые 48.0, округляемые вниз до 48
К>Что же касается 0.1, 0.7, 0.8 — они непредставимы ни в одном из плавающих типов (float, double, long double). К>И компилятор, и процессор вольны привнести туда ряд ошибок, причём как вниз, так и вверх.
А вот интересный вопрос, насколько это зависит от компилятора/процессора?
Здравствуйте, vadimcher, Вы писали:
V>Более того, что более неточный тип используется для 0.1 и для 0.7, тем скорее мы получим точный ответ 8. Я так думаю.
А вот тут надо смотреть на период двоичной дроби 1/5 и на разрядность мантиссы. И на то, что там окажется в младшем разряде.
В общем, это лотерея.
Перекуём баги на фичи!
