Принудительно установить секунды равными нулю

Я был членом комитета IEEE-754, я попытаюсь немного разъяснить некоторые вещи.

Во-первых, числа с плавающей запятой не являются действительными числами, а арифметика с плавающей запятой не удовлетворяют аксиомам реальной арифметики. Трихотомия - это не единственное свойство реальной арифметики, которое не выполняется для поплавков и даже самое важное. Например:

• Дополнение не является ассоциативным.
• Закон распределения не выполняется.
• Имеются числа с плавающей запятой без инверсий.

Я мог бы продолжить. Невозможно указать арифметический тип фиксированного размера, который удовлетворяет всем свойствам реальной арифметики, которые мы знаем и любим. Комитет 754 должен решить склонить или сломать некоторые из них. Это руководство основано на некоторых довольно простых принципах:

1. Когда мы можем, мы сопоставляем поведение реальной арифметики.
2. Когда мы не можем, мы пытаемся сделать нарушения как можно предсказуемо и легко диагностировать.

Что касается вашего комментария, «это не означает, что правильный ответ ложный», это неправильно. Предикат (y < x) спрашивает, меньше ли y, чем x. Если y является NaN, то это не меньше любого значения с плавающей запятой x, поэтому ответ обязательно является ложным.

Я упомянул, что трихотомия не выполняется для значений с плавающей запятой. Однако есть аналогичное свойство, которое выполняется. Пункт 5.11, параграф 2 стандарта 754-2008:

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

Что касается написания дополнительного кода для обработки NaNs, обычно возможно (хотя и не всегда легко) структурировать ваш код в таком формате, что NaNs проваливаются должным образом, но это не всегда так. Когда это не так, может потребоваться некоторый дополнительный код, но это небольшая цена, чтобы заплатить за удобство, которое привело к алгебраическому закрытию для арифметики с плавающей запятой.

---

Приложение: Многие комментаторы утверждали, что было бы более полезно сохранить рефлексивность равенства и трихотомии на том основании, что принятие NaN! = NaN, похоже, не сохраняет какой-либо знакомой аксиомы. Я признаюсь, что имею некоторое сочувствие к этой точке зрения, поэтому я решил вернуться к этому ответу и предоставить немного больше контекста.

Мое понимание от разговоров с Каханом заключается в том, что NaN! = NaN возникла из двух прагматических соображений :

• То, что x == y должно быть эквивалентно x - y == 0, когда это возможно (не являясь теоремой реальной арифметики, это делает аппаратную реализацию сравнения более эффективной с точки зрения пространства, что имеет первостепенное значение при время, когда стандарт был разработан - обратите внимание, однако, что это нарушается при x = y = бесконечность, поэтому это не является большой причиной для себя, оно может быть разумно согнуто до (x - y == 0) or (x and y are both NaN)).
• Что еще более важно, предикат isnan( ) не существовал в то время, когда NaN был формализован в арифметике 8087; необходимо было предоставить программистам удобное и эффективное средство обнаружения значений NaN, которые не зависят от языков программирования, предоставляющих нечто вроде isnan( ), которое может занять много лет. Я процитирую собственное письмо Кахана по этому вопросу:

Если бы не было способа избавиться от NaN, они были бы столь же бесполезны, как и Indefinites на CRAY; как только кто-то столкнулся, расчет лучше всего прекратить, а не продолжиться на неопределенное время до окончательного вывода. Вот почему некоторые операции над NaN должны доставлять результаты, отличные от NaN. Какие операции? ... Исключениями являются предикаты C «x == x» и «x! = X», которые соответственно равны 1 и 0 для каждого бесконечного или конечного числа x, но наоборот, если x не является числом (NaN); они обеспечивают единственное простое исключающее различие между NaN и числами на языках, которым не хватает слова для NaN и предиката IsNaN (x).

Обратите внимание, что это также логика, которая исключает возвращение чего-либо как «Not-A-Boolean». Возможно, этот прагматизм был неуместным, и стандарт должен был потребовать isnan( ), но это сделало бы NaN почти невозможным использовать эффективно и удобно в течение нескольких лет, пока мир ждал принятия языка программирования. Я не уверен, что это был бы разумный компромисс.

Чтобы быть тупым: результат NaN == NaN теперь не изменится. Лучше научиться жить с ним, чем жаловаться в Интернете. Если вы хотите утверждать, что отношение порядка, подходящее для контейнеров, должно существовать также , я бы рекомендовал, чтобы ваш любимый язык программирования реализовал предикат totalOrder, стандартизованный в IEEE-754 (2008). Тот факт, что он еще не говорит о справедливости озабоченности Кахана, которая мотивировала нынешнее положение дел.