Округленческое

[spamsink]

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



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

Comments

[vak]

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

[spamsink]

Даже с дефолтным округлением там бездна, звёзд полна. Некоторые явления я совсем не могу объяснить.

[archaicos.livejournal.com]

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

[spamsink]

1. Я специально сказал, что промежуточные результаты нужно сохранять (с наперед заданной той или иной точностью, например, с помощью volatile).
2. Ошибки в компиляторе - особь статья.
3. Я специально сказал, что на что нужно делить, чтобы избежать проблем с денормализованными числами.

[vak]

Получается в 14.9% случаев результат меньше единицы, и никогда больше. Это при стандартном округлении к ближайшему. Типа такого:

49: result 3fefffffffffffff
103: result 3fefffffffffffff
107: result 3fefffffffffffff
161: result 3fefffffffffffff
187: result 3fefffffffffffff
197: result 3fefffffffffffff
237: result 3fefffffffffffff
239: result 3fefffffffffffff
249: result 3fefffffffffffff
253: result 3fefffffffffffff
347: result 3fefffffffffffff
389: result 3fefffffffffffff

[spamsink]

Теперь попробуй сохранять результат деления в long double.

[vak]

Тогда результат всегда точным получается.

[spamsink]

Прошу прощения, я имел в виду, и умножения тоже. Тогда у меня получается практически 50%/50%, с малой долей точных результатов. Это в точности то, что процессор выполняет внутри; спрашивается, почему промежуточные округления так смещают статистику вниз?

[vak]

Да вроде нет, тоже 14.9%.
Вот исходник: https://code.google.com/p/vak-opensource/source/browse/trunk/languages/c-language/rounding.c

[spamsink]

Вместо one просто 1.0.

[vak]

Непонятно, откуда такая разница.

[spamsink]

Вот и я о том.

[vak]

Что-то компилятор там мудрит.