Почему NaN - NaN == 0.0 с компилятором Intel C ++?

Question

Почему NaN - NaN == 0.0 с компилятором Intel C ++?

302

Хорошо известно, что NaN распространяются в арифметике, но я не смог найти никаких демонстраций, поэтому написал небольшой тест:

#include <limits>
#include <cstdio>

int main(int argc, char* argv[]) {
    float qNaN = std::numeric_limits<float>::quiet_NaN();

    float neg = -qNaN;

    float sub1 = 6.0f - qNaN;
    float sub2 = qNaN - 6.0f;
    float sub3 = qNaN - qNaN;

    float add1 = 6.0f + qNaN;
    float add2 = qNaN + qNaN;

    float div1 = 6.0f / qNaN;
    float div2 = qNaN / 6.0f;
    float div3 = qNaN / qNaN;

    float mul1 = 6.0f * qNaN;
    float mul2 = qNaN * qNaN;

    printf(
        "neg: %f\nsub: %f %f %f\nadd: %f %f\ndiv: %f %f %f\nmul: %f %f\n",
        neg, sub1,sub2,sub3, add1,add2, div1,div2,div3, mul1,mul2
    );

    return 0;
}

Пример (работает в прямом эфире здесь) дает в основном то, что я ожидаю (отрицательный немного странный, но это имеет смысл)

neg: -nan
sub: nan nan nan
add: nan nan
div: nan nan nan
mul: nan nan

MSVC 2015 создает нечто подобное. Однако Intel С++ 15 производит:

neg: -nan(ind)
sub: nan nan 0.000000
add: nan nan
div: nan nan nan
mul: nan nan

В частности, qNaN - qNaN == 0.0.

Это... не может быть правильным, не так ли? Что об этом говорят соответствующие стандарты (ISO C, ISO С++, IEEE 754) и почему существует разница в поведении между компиляторами?

imallett 25 авг. 2015, в 06:22

Источник

18

Javascript и Python (numpy) не имеют такого поведения. Nan-NaN - это NaN . Perl и Scala также ведут себя одинаково.
Paul 25 авг. 2015, в 05:18
33

Может быть, вы включили небезопасные математические оптимизации (эквивалент -ffast-math на gcc)?
Matteo Italia 25 авг. 2015, в 05:21
2

@nm Я не сказал, стандарты C / C ++. Я сказал «стандарт», имея в виду IEEE 754 и соответствующие реализации в C и C ++. Я признаю, что это было неясно, однако.
imallett 25 авг. 2015, в 05:23
5

@nm: не правда. Приложение F, которое является необязательным, но нормативным, когда оно поддерживается, и которое необходимо для определения поведения с плавающей запятой вообще , по существу включает IEEE 754 в C.
R.. 25 авг. 2015, в 05:25
0

@nm Как я уже писал, неясно . Я редактировал это только сейчас. Я думаю, но не уверен, что 754 здесь является стандартом, поэтому я сделал его еще более общим.
imallett 25 авг. 2015, в 05:25
5

Если вы хотите спросить о стандарте IEEE 754, укажите это где-нибудь в вопросе.
n.m. 25 авг. 2015, в 05:27
3

@nm: Они много говорят о NaN, на самом деле, повсеместно, если только стандарт не сильно отличается от проекта. Ctrl-F окончательный вариант C11 для NaN, и вы получите 374 попадания.
user2357112 25 авг. 2015, в 05:27
0

software.intel.com/sites/default/files/article/326703/...
Arun 25 авг. 2015, в 05:34
0

@ user2357112 Вы правы, извините, у меня не работает память,
n.m. 25 авг. 2015, в 05:43
67

Я был уверен, что этот вопрос был о JavaScript из заголовка.
MikeTheLiar 25 авг. 2015, в 12:51
0

GCC 5.1.0 в Ubuntu делает то же, что и в первом примере вывода. Я не использовал никаких переключателей, которые изменяют модель с плавающей запятой, поэтому все, что с этим связано, должно быть по умолчанию. Я использовал только -O3, который не связывается с моделью с плавающей запятой.
adam10603 25 авг. 2015, в 15:43
0

Почему -nan странный?
ChiefTwoPencils 25 авг. 2015, в 18:46
1

@ChiefTwoPencils Я думаю, что OP просто означает «странный» в общем смысле «это своего рода неинтуитивный» смысл, то есть «что означает для NaN быть отрицательным в первую очередь», а не в смысле «неожиданный и, возможно, неожиданный». не правильно." Я предполагаю, что OP до этого теста не осознавал, что -nan был определен спецификацией с плавающей точкой.
Kyle Strand 25 авг. 2015, в 18:52
1

@imallett Я сделал то, что, как я надеюсь, вы согласитесь, представляет собой минимальное изменение вашего вопроса, чтобы прояснить стандартную сторону вопроса (поскольку ответ с наивысшей оценкой полезен, но не совсем то, что вы, похоже, ищете) ,
Kyle Strand 25 авг. 2015, в 18:56
1

@KyleStrand Пожалуйста, не заменяйте собственное суждение ОП при определении вопроса. Он говорит, что интересуется «поведением как на C, так и на C ++», и вы отредактировали это, чтобы сделать его стандартным вопросом. ФП мог бы задать вопрос по программированию, является ли это концептуальным вопросом о стандартах. Размещая на Stack Overflow, практическом сайте вопросов и ответов, он делает этот вопрос практичным. Как на самом деле ведут себя компиляторы - вопрос практического программирования, и поэтому здесь мы поговорим подробнее.
Paul 26 авг. 2015, в 21:54
0

@Paul Er ... Вопросы C / C ++ на этом сайте довольно часто касаются стандартов C / C ++, и даже если они не имеют явного отношения к стандартам, на них часто отвечают со ссылкой на стандарт (ы). На самом деле, я был отвергнут, когда попытался спросить о практическом поведении, не подпадающем под действие стандарта . Но, что более важно, вопрос (перед редактированием!) Сказал: «Что стандарт говорит об этом». Таким образом, я не "сделал это стандартным вопросом"; это был (вполне очевидно) уже стандартный вопрос. Я просто уточнил, какие стандарты актуальны.
Kyle Strand 26 авг. 2015, в 21:59
0

@Paul Если вы хотите утверждать, что я затуманил вопросы или изменил цель вопроса, добавив IEEE, когда пользователь только спросил о стандартах C / C ++, это может быть разумной позицией. Но говорить, что вопрос был не о стандартах до моего редактирования, просто не соответствует действительности.
Kyle Strand 26 авг. 2015, в 22:01
3

Действительно, я спрашивал о стандартах. @ ouah's - мой любимый ответ на данный момент, так как он единственный, который на самом деле обращается к ним.
imallett 26 авг. 2015, в 22:12
0

@imallett Я полагаю, что вы можете дать Петру второй золотой значок, если примете ответ Оах: stackoverflow.com/help/badges/62/populist
Kyle Strand 26 авг. 2015, в 22:16
0

@KyleStrand Меня больше всего раздражало, что поведенческое любопытство исчезало. Предоставив некоторое понимание, которое было хорошо получено ранее, новые читатели жалуются, что я не ответил на вопрос. Конечно, и рабочий стандарт де-факто (фактический компилятор, который обычно используется большинством разработчиков) и документ стандартов важны в том, что код может быть безопасным какое-то время, когда оба соглашаются, и есть прецедент, что будущая разработка должна держать их в согласии.
Paul 26 авг. 2015, в 22:46
0

@KyleStrand На ваш предыдущий вопрос стыдно, что никто не ответил, но было бы много работы, чтобы ответить на него из ничего, так как для этого требуется набор тестов, несколько версий и т. Д. Однако это можно сделать с набор тестов и несколько док-контейнеров.
Paul 26 авг. 2015, в 22:46
1

@Paul Ах, я не предсказал негативного влияния на существующие ответы, так как в своем уме я сохранил первоначальное намерение вопроса. Это имеет больше смысла. Я не думаю, что с моей стороны было бы неразумно истолковывать круглые скобки как просто разъяснение поставленного вопроса о «стандарте», но вы правы, что мое редактирование убирает все упоминания о «поведении». Я думаю, что если он вообще будет присутствовать, он не должен быть в скобках. Я сделал еще одно редактирование.
Kyle Strand 26 авг. 2015, в 22:52
0

ОП, текущая версия приемлема?
Kyle Strand 26 авг. 2015, в 22:52
0

@Paul Я менее раздражен тем, что никто не ответил на мой вопрос, чем я, что было сопротивление идее, что ответ может быть ценным в первую очередь.
Kyle Strand 26 авг. 2015, в 22:54
2

@KyleStrand Да; текущая версия приемлема. Мой оригинальный вопрос был о стандартах. Поскольку причина оказалась в основном в компиляторах, я думаю, что лучше сделать ответы на оба вопроса.
imallett 27 авг. 2015, в 01:24
0

Вы можете добавить немного volatile здесь.
curiousguy 27 авг. 2015, в 04:55
0

Что странно в отрицательном NaN, так это то, что neg < 0 false : melpon.org/wandbox/permlink/o8JwN6RwOmOme9wY
Joseph 29 авг. 2015, в 00:42

Показать ещё 25 комментариев

Теги:

c++

floating-point

c

ieee-754

icc

3 ответа

Ещё вопросы

Javascript и Python (numpy) не имеют такого поведения. Nan-NaN - это NaN . Perl и Scala также ведут себя одинаково.
Может быть, вы включили небезопасные математические оптимизации (эквивалент -ffast-math на gcc)?
@nm Я не сказал, стандарты C / C ++. Я сказал «стандарт», имея в виду IEEE 754 и соответствующие реализации в C и C ++. Я признаю, что это было неясно, однако.
@nm: не правда. Приложение F, которое является необязательным, но нормативным, когда оно поддерживается, и которое необходимо для определения поведения с плавающей запятой вообще , по существу включает IEEE 754 в C.
@nm Как я уже писал, неясно . Я редактировал это только сейчас. Я думаю, но не уверен, что 754 здесь является стандартом, поэтому я сделал его еще более общим.
Если вы хотите спросить о стандарте IEEE 754, укажите это где-нибудь в вопросе.
@nm: Они много говорят о NaN, на самом деле, повсеместно, если только стандарт не сильно отличается от проекта. Ctrl-F окончательный вариант C11 для NaN, и вы получите 374 попадания.
@ user2357112 Вы правы, извините, у меня не работает память,
Я был уверен, что этот вопрос был о JavaScript из заголовка.
GCC 5.1.0 в Ubuntu делает то же, что и в первом примере вывода. Я не использовал никаких переключателей, которые изменяют модель с плавающей запятой, поэтому все, что с этим связано, должно быть по умолчанию. Я использовал только -O3, который не связывается с моделью с плавающей запятой.
@ChiefTwoPencils Я думаю, что OP просто означает «странный» в общем смысле «это своего рода неинтуитивный» смысл, то есть «что означает для NaN быть отрицательным в первую очередь», а не в смысле «неожиданный и, возможно, неожиданный». не правильно." Я предполагаю, что OP до этого теста не осознавал, что -nan был определен спецификацией с плавающей точкой.
@imallett Я сделал то, что, как я надеюсь, вы согласитесь, представляет собой минимальное изменение вашего вопроса, чтобы прояснить стандартную сторону вопроса (поскольку ответ с наивысшей оценкой полезен, но не совсем то, что вы, похоже, ищете) ,
@KyleStrand Пожалуйста, не заменяйте собственное суждение ОП при определении вопроса. Он говорит, что интересуется «поведением как на C, так и на C ++», и вы отредактировали это, чтобы сделать его стандартным вопросом. ФП мог бы задать вопрос по программированию, является ли это концептуальным вопросом о стандартах. Размещая на Stack Overflow, практическом сайте вопросов и ответов, он делает этот вопрос практичным. Как на самом деле ведут себя компиляторы - вопрос практического программирования, и поэтому здесь мы поговорим подробнее.
@Paul Er ... Вопросы C / C ++ на этом сайте довольно часто касаются стандартов C / C ++, и даже если они не имеют явного отношения к стандартам, на них часто отвечают со ссылкой на стандарт (ы). На самом деле, я был отвергнут, когда попытался спросить о практическом поведении, не подпадающем под действие стандарта . Но, что более важно, вопрос (перед редактированием!) Сказал: «Что стандарт говорит об этом». Таким образом, я не "сделал это стандартным вопросом"; это был (вполне очевидно) уже стандартный вопрос. Я просто уточнил, какие стандарты актуальны.
@Paul Если вы хотите утверждать, что я затуманил вопросы или изменил цель вопроса, добавив IEEE, когда пользователь только спросил о стандартах C / C ++, это может быть разумной позицией. Но говорить, что вопрос был не о стандартах до моего редактирования, просто не соответствует действительности.
Действительно, я спрашивал о стандартах. @ ouah's - мой любимый ответ на данный момент, так как он единственный, который на самом деле обращается к ним.
@imallett Я полагаю, что вы можете дать Петру второй золотой значок, если примете ответ Оах: stackoverflow.com/help/badges/62/populist
@KyleStrand Меня больше всего раздражало, что поведенческое любопытство исчезало. Предоставив некоторое понимание, которое было хорошо получено ранее, новые читатели жалуются, что я не ответил на вопрос. Конечно, и рабочий стандарт де-факто (фактический компилятор, который обычно используется большинством разработчиков) и документ стандартов важны в том, что код может быть безопасным какое-то время, когда оба соглашаются, и есть прецедент, что будущая разработка должна держать их в согласии.
@KyleStrand На ваш предыдущий вопрос стыдно, что никто не ответил, но было бы много работы, чтобы ответить на него из ничего, так как для этого требуется набор тестов, несколько версий и т. Д. Однако это можно сделать с набор тестов и несколько док-контейнеров.
@Paul Ах, я не предсказал негативного влияния на существующие ответы, так как в своем уме я сохранил первоначальное намерение вопроса. Это имеет больше смысла. Я не думаю, что с моей стороны было бы неразумно истолковывать круглые скобки как просто разъяснение поставленного вопроса о «стандарте», но вы правы, что мое редактирование убирает все упоминания о «поведении». Я думаю, что если он вообще будет присутствовать, он не должен быть в скобках. Я сделал еще одно редактирование.
@Paul Я менее раздражен тем, что никто не ответил на мой вопрос, чем я, что было сопротивление идее, что ответ может быть ценным в первую очередь.
@KyleStrand Да; текущая версия приемлема. Мой оригинальный вопрос был о стандартах. Поскольку причина оказалась в основном в компиляторах, я думаю, что лучше сделать ответы на оба вопроса.
Вы можете добавить немного volatile здесь.
Что странно в отрицательном NaN, так это то, что neg < 0 false : melpon.org/wandbox/permlink/o8JwN6RwOmOme9wY

Petr Abdulin · Answer 1 · 2015-08-25T07-12-00.000Z

294

Обработка с плавающей запятой по умолчанию в компиляторе Intel С++ составляет /fp:fast, которая обрабатывает NaN unsafely (что также приводит к тому, что NaN == NaN является true). Попробуйте указать /fp:strict или /fp:precise и посмотрите, поможет ли это.

Petr Abdulin 25 авг. 2015, в 07:12

15

Я просто пробовал это сам. Действительно, указание точного или строгого исправляет проблему.
imallett 25 авг. 2015, в 05:30
65

Я хотел бы одобрить решение Intel по умолчанию использовать /fp:fast : если вы хотите что-то безопасное , вам, вероятно, лучше избегать появления NaN, и обычно не используйте == с числами с плавающей запятой. Полагаясь на странную семантику, которую IEEE754 назначает NaN, возникают проблемы.
leftaroundabout 25 авг. 2015, в 14:24
10

@leftaroundabout: Что вы находите странным в NaN, кроме ужасного решения IMHO, что NaN! = NaN вернет истину?
supercat 25 авг. 2015, в 16:41
21

NaN имеют важное применение - они могут обнаруживать исключительные ситуации, не требуя тестов после каждого расчета. Не каждый разработчик с плавающей точкой нуждается в них, но не отклоняет их.
Bruce Dawson 25 авг. 2015, в 17:03
0

@leftaroundabout Выбор быстрой и безопасной совместим с обработкой ошибки FDIV : что-то редко встречается среднестатистическим пользователям, поэтому выбирайте наиболее быстрое решение.
chux 25 авг. 2015, в 18:17
6

@supercat Из любопытства согласны ли вы с тем, что NaN==NaN возвращает false ?
Kyle Strand 25 авг. 2015, в 18:52
6

@KyleStrand: Нет, но если NaN! = NaN вернул true, код может по крайней мере использовать инвертированную логику с! = Для защиты от некоторых проблемных случаев. Что было действительно необходимо (и по какой-то причудливой причине до сих пор не доступно) - это стандартизированное эффективное средство для выполнения полностью упорядоченного реляционного сравнения. Хотя бывают случаи, когда неупорядоченный NaN может быть полезен, бывают и другие случаи, например, при попытке отсортировать список чисел, когда он наносит ущерб всему. Если бы я разрабатывал язык, у меня было бы несколько типов float и double, которые были бы взаимно конвертируемыми ...
supercat 25 авг. 2015, в 19:06
2

... но использовал другую семантику сравнения NaN (операции будут разрешены только между значениями с одинаковой семантикой, за исключением того, что не-NaN-константы будут свободно преобразованы в любую другую форму); Я бы хотел, чтобы тип «общего назначения» использовал операторы полного ранжирования.
supercat 25 авг. 2015, в 19:09
0

@supercat Ха. Мне это нравится.
Kyle Strand 25 авг. 2015, в 19:17
4

@supercat NaN, неупорядоченные, важны в научных вычислениях для сохранения правильной семантики неопределенных форм. Я предполагаю, что этот вариант использования является более распространенным / более важным, чем эффективность сортировки списков, содержащих NaN.
user168715 26 авг. 2015, в 04:15
0

@leftaroundabout: Ваша позиция такова: если я хочу что-то «безопасное», мне лучше не использовать какие-либо функции, которые помогают мне писать код, который был бы быстрым и безопасным, потому что вы думаете, что они странные?
tmyklebu 26 авг. 2015, в 04:40
0

@supercat Если бы вы сортировали список чисел, содержащих NaN, вы бы поместили его в положительную или отрицательную бесконечность? (И разве не достаточно просто предварительно обработать список, чтобы удалить все NaN?)
Pharap 26 авг. 2015, в 08:47
0

@tmyklebu: нет, вам лучше использовать другие функции, которые помогут вам написать код, который будет быстрым и безопасным. В частности, все, что может быть гарантировано системой типов, предпочтительнее проверок во время выполнения (будь то через NaN или без). Шаблоны C ++ дают вам много возможностей, а системы типа Хиндли-Милнера, такие как OCaml или Haskell, еще лучше.
leftaroundabout 26 авг. 2015, в 08:53
0

@ user168715: Обе формы необходимы в разное время, но (1) даже в научных вычислениях я ожидаю, что наличие оператора, который рассматривает NaN как не равный чему-либо (включая другие NaN), будет примерно таким же важным, как и тот, который его рассматривает как не равный чему-либо, поэтому я не понимаю оснований для того, чтобы NaN возвращал false для всего, кроме неравенства, и (2) IEEE должен очень сильно исходить из принципа get-go, согласно которому реализации должны обеспечивать как полностью упорядоченные средства сравнения и "научный", а также то, что он обеспечивает функции для вычисления ...
supercat 26 авг. 2015, в 13:17
1

... тригональные функции в единицах окружностей или квадрантах. Несмотря на то, что есть некоторые цели, для которых радианы являются естественной единицей, есть также много случаев, когда вычисления заканчиваются коэффициентом пи, который можно было бы опустить, если бы в качестве единиц использовались круги. Учитывая, что для многих реализаций синуса и косинуса необходимо в любом случае преобразовать в дробную степень круга, требование умножения клиентского кода на pi и код библиотеки для умножения на 1 / pi не является рецептом для высокой точности.
supercat 26 авг. 2015, в 13:19
4

@ user168715: Кстати, я также думаю, что должно было быть четыре нулевых значения: ноль ( все, что плюс или минус ноль, приводит к самому себе), положительное и отрицательное бесконечно малое (результат уменьшения при умножении или делении) и беззнаковое бесконечно малое (результат вычитания дает нулевой результат). Деление на бесконечно малое со знаком должно дать +/- inf, а деление на бесконечно малое или без знака должно дать NaN. Такое расположение сделало бы все операции должным образом симметричными между положительными и отрицательными числами.
supercat 26 авг. 2015, в 13:22
5

@leftaroundabout: Вы когда-нибудь писали цифровой код? Необычные системы не спасут вас. То, как обрабатываются NaN, было тщательно спроектировано, так что вы все равно можете проверять наличие ошибок, но вам не нужно загрязнять свой код явными, редко используемыми условиями везде.
tmyklebu 26 авг. 2015, в 14:05
2

@supercat: IEEE 754-2008 (или как бы вы его ни подчеркивали) действительно рекомендует, чтобы реализации обеспечивали как общий порядок, так и обычные сравнения с плавающей точкой. К сожалению, они не могут диктовать синтаксис комитетам C и C ++. Я считаю, что он также рекомендует sinpi cospi и друзей для вашей второй жалобы. Я согласен, хотя; Жаль, что этого не было в начале.
tmyklebu 26 авг. 2015, в 14:08
0

sinpi т. д. в дополнение к традиционным версиям в радианах (но не заменяя их) - хорошая идея, но она не связана с вопросом о том, как следует обрабатывать NaN.
user168715 26 авг. 2015, в 14:28
0

@tmyklebu: Я работаю над MHD- кодами и поэтому точно знаю, что NaN не очень «спасают вас». Конечно, когда они всплывают, вы, как правило, можете быть уверены, что все пошло не так, но не каждая ошибка вообще проявляется как NaN. Но даже без них часто будут очевидные и эффективно проверяемые намеки на то, что что- то не так (например, отрицательная плотность). - Но ни один из этих советов не очень полезен для отладки, потому что ошибка обычно может быть где угодно в очень большом разделе кода. Для этого...
leftaroundabout 26 авг. 2015, в 14:44
0

... что-то вроде отладки, вам нужно будет включить неэффективные локальные проверки - что вы действительно можете в любом случае сделать для быстрой проверки перед каждым производственным циклом, требующим обработки! Но даже лучше, если большинство ошибок исправлено компилятором, и именно в этом помогают системы сильных типов. Конечно, они также не находят каждую ошибку, но они могут найти множество ошибок. По общему признанию я еще не работал с такими кодами в C ++ 11, OCaml из Haskell, чтобы подтвердить это; но я приписываю отсутствие таких кодов главным образом академической инерции.
leftaroundabout 26 авг. 2015, в 14:44
3

@leftaroundabout Я согласен с tmyklebu, что вывод типа здесь бесполезен. (Почти) никто не пишет NaN во время компиляции: они возникают из-за недостаточного / переполнения в течение многих итераций сложных вычислений, и прогнозировать их редко проще, чем запускать саму программу. Рассмотрим, например, моделирование задачи трех тел: если какие-либо два из трех тел окажутся слишком близко друг к другу, возникнут NaN (из-за переполнения силы, пропорциональной $ 1 / r ^ 2 $), но, конечно, три проблема - это классический пример хаотической системы, которую нельзя проанализировать во время компиляции.
user168715 26 авг. 2015, в 14:46
1

@ user168715: ну, в этом конкретном примере система типов не помогла бы, потому что это на самом деле не ошибка в программе, а скорее в установке проблемы (почему такие близкие, вызывающие переполнение окрестности возможны в первую очередь?)
leftaroundabout 26 авг. 2015, в 14:54
2

@leftaroundabout Правильно, но, к сожалению, именно так NaN возникают на практике. Можно представить код, который выполняет большое количество временных шагов численного интегрирования для задачи трех тел (для эффективности) и периодически проверяет наличие NaN и других проблем и, если обнаруживается, перематывает время (как деформация времени Джефферсона) и перезапускает те итерации со специальной (более дорогой) обработкой, которая обрабатывает столкновения тела.
user168715 26 авг. 2015, в 14:57
1

@ user168715: верно, но для этого вам не требуется гарантированная «прогрессия яда» NaN. Проверка на невероятно высокие кинетические энергии приведет к тому же результату.
leftaroundabout 26 авг. 2015, в 15:10
1

@tmyklebu: Я знаю, что IEEE начал рекомендовать такие вещи в 2008 году, но кто-нибудь действовал по этому поводу? Нарушение отношения равенства по умолчанию вместо того, чтобы иметь функцию для проверки того, являются ли две переменные «научно» равными, делает практически невозможным для языка поддержку семантики IEEE, а также указывает, что оператор == будет определять отношение эквивалентности для комбинаций операндов, где он компилирует [если бы я разрабатывал язык, я бы включил типы «ieee32» и «ieee64», которые имеют метод .ieee_eq() но запрещают оператор == и имеют == тестовую эквивалентность].
supercat 26 авг. 2015, в 15:46
1

@leftaroundabout: у меня никогда не было числового болвана, который ловила бы система причудливых типов. (Но я также никогда не работал над чем-то связанным с физикой. Я занимаюсь оптимизацией, и у нас нет единиц измерения.) Распространение NaN позволяет вам написать ясную логику для общего случая и убедительно обнаружить, что что-то пошло не так. Проверка на «невероятно высокие кинетические энергии» может обычно работать в физическом моделировании, но, вероятно, можно спроектировать вход, для которого он не работает.
tmyklebu 26 авг. 2015, в 16:57
0

@supercat: Некоторые модные математические библиотеки, такие как trigpi имеют функции trigpi . Вы находитесь в глубоком греховном состоянии, если вам нужно < для чисел с плавающей запятой и действовать как < для чисел с плавающей запятой, и действовать как общий порядок.
tmyklebu 26 авг. 2015, в 17:01
0

@tmyklebu: Есть много случаев, когда алгоритмы с плавающей запятой могут извлечь выгоду из запоминания. Если f(x) стоит дорого, и его вывод зависит только от x , то сохранение списка значений x и результатов вызова f(x) часто может быть полезной оптимизацией, но единственные известные мне способы, которые требуют средство проверки, эквивалентны ли два значения с плавающей запятой, и единственный известный мне способ сделать это эффективно, требует средств хеширования или ранжирования значений с плавающей запятой. Запоминание неясно, или есть способы сделать это эффективно без вышеупомянутых функций?
supercat 26 авг. 2015, в 17:28
0

Памятка не является неясной, но она также не требует полного заказа. Преобразуйте double помощью memcpy или аналогичного ему целочисленного типа одинакового размера, такого как int64_t , и используйте этот int64_t в качестве ключа. (Или array<char, sizeof(double) если вы один из тех людей.)
tmyklebu 26 авг. 2015, в 18:39
0

В качестве примечания, у компилятора Intel C ++ есть (в настоящее время не рекомендуется в пользу / fp и по умолчанию off off) / Op опция, которую в документации описывается следующим образом: «Обеспечивает соответствие стандартам ANSI C и IEEE 754 для арифметики с плавающей точкой». и «Задание параметра / Op оказывает следующие эффекты на компиляцию программы: [...] арифметические сравнения с плавающей точкой соответствуют спецификации IEEE 754, за исключением поведения NaN». Документация не содержит подробностей в оптимизации / несоответствии параметра / fp.
ouah 26 авг. 2015, в 21:42
1

@tmyklebu: Существуют способы получения полного порядка от double в C, но взломы, включающие memcpy или даже union могут в итоге вызвать дополнительные обходы регистров-> памяти. Кроме того, я не думаю, что полезность IEEE-754 должна была ограничиваться языками, которые поддерживают такую хакерскую работу на уровне битов.
supercat 26 авг. 2015, в 22:45
0

Можем ли мы все просто согласиться с тем, что числа с плавающей точкой доказывают существование Бога отрицанием, поскольку они явно являются работой дьявола? :-)
Bob Jarvis 28 авг. 2015, в 11:05
1

@supercat: Вы смотрели на Rust? Он определяет 4 черты (интерфейсы) для сравнения: PartialEq , PartialOrd , Eq и Ord , последние два - это PartialEq , у PartialOrd провайдеров мельниц == != , < , <= , > И >= однако с плавающей точкой ( f32 и f64 ) не реализуют Eq и Ord но только PartialEq и PartialOrd : doc.rust-lang.org/std/cmp/trait.PartialOrd.html
Matthieu M. 28 авг. 2015, в 15:07
0

@MatthieuM .: Я очень кратко посмотрел на Rust; Мне нравится концептуальное различие между «let» и «let mut», но я ничего не знаю об этом. Как используются частичные упорядочения, и что можно сделать, если нужно общее упорядочение по реалам (с отображением NaN как высоким, так и низким)?
supercat 28 авг. 2015, в 16:09
0

@supercat: вы можете использовать частичные упорядочения, вызывая методы черты: fn partial_cmp(&self, &other) -> Option<Ordering> возвращает ни упорядочения, ни упорядочения; для плавающих точек сравнение с NaN не приводит к упорядочению. Если вы хотите определить общий порядок, вы создаете новый тип: struct MyF32(f32); а затем вы можете реализовать интерфейс для вашего типа и решить, как продолжить сравнение. Основным преимуществом является то, что он заставляет людей явно выбирать поведение, которое имеет для них смысл.
Matthieu M. 28 авг. 2015, в 17:34
0

@MatthieuM .: Я не хотел спрашивать, каким образом можно спрашивать объекты о частичном упорядочении, а скорее как его можно было бы с пользой использовать. Существуют ли какие-либо полезные универсальные алгоритмы, которые требуют какого-либо порядка, который не требует полного порядка?
supercat 28 авг. 2015, в 18:35
0

@supercat: Если честно? Я понятия не имею!
Matthieu M. 28 авг. 2015, в 19:27
0

Говоря о fp: fast по умолчанию от Intel, он примерно соответствует gcc -ffast-math -fno-cx-limited-range, тогда как fp: fast = 2 включает -complex-limited-range и другие. Я принадлежу к меньшинству, которое предпочло бы, чтобы в этих опциях не учитывалось резкое снижение значения и игнорирование скобок в стиле k & r. У меня также есть оговорки относительно того, как взаимная математика обрабатывается в соответствии с этими вариантами. Тем не менее, я использую их большую часть времени.
tim18 11 июнь 2016, в 19:39

Показать ещё 37 комментариев

ouah · Answer 2 · 2015-08-26T09-43-00.000Z

Это., не может быть прав, не так ли? Мой вопрос: что говорят об этом соответствующие стандарты (ISO C, ISO С++, IEEE 754)?

Петр Абдулин уже ответил, почему компилятор дает ответ 0.0.

Вот что говорит IEEE-754: 2008:

(6.2 Операции с NaN) "[...] Для операции с тихими входами NaN, отличными от максимальных и минимальных операций, если результат с плавающей запятой должен быть доставлен, результат должен быть тихим NaN, который должен быть один из входных NaNs."

Таким образом, единственным допустимым результатом для вычитания двух тихих операндов NaN является тихое NaN; любой другой результат недействителен.

В стандарте C говорится:

(C11, F.9.2 Преобразования выражения p1) "[...]

x - x → 0. 0" Выражения x - x и 0. 0 не эквивалентны, если x является NaN или бесконечное "

(где здесь NaN обозначает тихое NaN согласно F.2.1p1 "Эта спецификация не определяет поведение сигнальных NaNs. Обычно он использует термин NaN для обозначения тихих NaN" )

zwol · Answer 3 · 2015-08-29T15-59-00.000Z

Поскольку я вижу ответ, оспаривающий соответствие стандартов компилятору Intel, и никто другой не упомянул об этом, я укажу, что и GCC, и Clang имеют режим, в котором они делают что-то очень похожее. Их поведение по умолчанию IEEE-совместимо -

$ g++ -O2 test.cc && ./a.out 
neg: -nan
sub: nan nan nan
add: nan nan
div: nan nan nan
mul: nan nan

$ clang++ -O2 test.cc && ./a.out 
neg: -nan
sub: -nan nan nan
add: nan nan
div: nan nan nan
mul: nan nan

- но если вы попросите скорость за счет правильности, вы получите то, что вы просите -

$ g++ -O2 -ffast-math test.cc && ./a.out 
neg: -nan
sub: nan nan 0.000000
add: nan nan
div: nan nan 1.000000
mul: nan nan

$ clang++ -O2 -ffast-math test.cc && ./a.out 
neg: -nan
sub: -nan nan 0.000000
add: nan nan
div: nan nan nan
mul: nan nan

Я считаю, что вполне справедливо критиковать выбор ICC по умолчанию, но я бы не стал читать все войны Unix в этом решении.

Обратите внимание, что с -ffast-math gcc больше не соответствует ISO 9899: 2011 в отношении арифметики с плавающей запятой.
@FUZxxl Да, дело в том, что оба компилятора имеют несовместимый режим с плавающей запятой, просто icc использует этот режим по умолчанию, а gcc - нет.
Просто чтобы бросить топливо в огонь, мне очень нравится выбор Intel по умолчанию включить быструю математику. Весь смысл использования поплавков - получить высокую пропускную способность.