Кажется, что стандарт IEEE 754 определяет 16,777,214 32-битных значений с плавающей запятой как NaNs, или 0,4% от всех возможных значений.
Интересно, в чем заключается обоснование для резервирования столь многих полезных значений, в то время как по существу нужны только 2: один для сигнализации и один для спокойного NaN.
Извините, если этот вопрос тривиален, я не нашел никаких объяснений в Интернете.
Стандарт IEEE-754 определяет NaN как число со всеми единицами в экспоненте и ненулевое значение. Бит наивысшего порядка в значении указывает, является ли NaN сигнальным или тихим. Остальные биты значащей формы образуют то, что называется полезной нагрузкой для NaN.
Всякий раз, когда один из операндов операции является NaN, результатом является NaN, а полезная нагрузка результата равна полезной нагрузке одного из операндов NaN. Сохранение полезной нагрузки имеет важное значение для эффективности в научных вычислениях, а хотя бы одна компания предложила использовать полезные ресурсы NaN для патентованных используется.
В более основных терминах NaN не несет никакой полезной числовой информации, и все 32 бита должны быть зарезервированы в любом случае, поэтому неиспользуемые биты в значении будут в противном случае потрачены впустую, если не было полезной нагрузки, определенной в стандарте.
Также имеется полезная нагрузка для 64-битных чисел с плавающей запятой, с ~ 10 ^ 15 возможными значениями. К сожалению, реализации расходятся в том, как переносить полезную нагрузку между 32 и 64-битными числами с плавающей запятой и обратно, т.е. Сохраняете ли вы наиболее значимые или наименее значимые биты. Поскольку обработка полезной нагрузки зависит от машины, вам нужен другой код для работы с полезными нагрузками на разных машинах.
Я бы не стал слишком беспокоиться о том, какая полезная нагрузка NaN распространяется после двоичной операции. NaN являются исключительными значениями, которые происходят с низкой вероятностью, и вероятность получения 2 из них маловероятна.
Согласно этой серии заметок Уильяма Кахана, одного из разработчиков формата IEEE-754, использование нескольких NaN предназначалось для того, чтобы аппаратное обеспечение могло заполнить информацию о том, что в первую очередь вызвало NaN, с тем чтобы вычисления, которые в итоге заканчивались в результате NaN может завершиться и затем позволить программисту написать код для анализа того, что пошло не так:
Спецификация IEEE 754 для NaN наделяет его полем битов, в которое программное обеспечение может записывать, скажем, как и/или где появился NaN. Эта информация была бы чрезвычайно полезна для последующей "ретроспективной диагностики" неисправных вычислений, но в настоящее время не существует программного обеспечения для ее использования. Обычно это поле копируется из операнда NaN в результирующий NaN каждой арифметической операции или заполняется двоичным кодом 1000... 000, когда новый NaN был создан с помощью необработанной операции INVALID. Из-за отсутствия программного обеспечения, чтобы использовать его, этот обычай атрофировался.
Таким образом, кажется, что это было преднамеренным и не определено, так что разные системы могут обрабатывать вещи по-разному Оглядываясь назад, кажется, что этого никогда не случалось, но это кажется разумной идеей!