Старая шутка

[Racheengel]

Скажу более конкретно:
!(w>=0) - это НЕ проверка на Nan, а лишь желание положиться на определенное поведение компилятора (которому он совершенно не обязан следовать), причем абсолютно не переносимое. Чем это лучше того, что человек вообще не проверит входные данные?
Поэтому говно, однозначно.

[ViTech]

Ах как Вы взыскательны Однако практически бесконечные проверки Вас быстро вымотают и засорят код. Тогда броситесь в др крайность - ничего не проверять. И.т.д. В общем вариант с проверкой nan отнюдь не плох.

На мою взыскательность можно забить , но вычисления прежде всего должны быть корректными, с погрешностью допустимой для поставленной задачи, а не быстрыми и простыми в написании. Полагаясь, что функции в большом выражении могут возвращать NaN, и тогда всё выражение будет равно NaN, можно получить облом. В том же mingw 5.4.0 выражение "sin( sqrt( -3.14 ) )" вполне себе вычисляется и возвращает значение "-0.00159265", которое выглядит вполне нормальным и не NaN.

[Igors]

В том же mingw 5.4.0 выражение "sin( sqrt( -3.14 ) )" вполне себе вычисляется и возвращает значение "-0.00159265", которое выглядит вполне нормальным и не NaN.

Ну что же Вы аргументируете багами конкретного компилятора? Некорректно

Что касается альтернативы

Код

C++ (Qt)
errno = 0; 
float b = sqrt(a);
if (errno == EDOM) ...

Что-то мне совсем не хочется так делать в рабочем коде. Это надо "окружать", разбираться (а вдруг не EDOM а что-то другое?), да и парочка вызовов errno что-то потянет в число-дробилке. В общем, обычная "рекомендация для других", сам рекомендующий вряд ли будет ей следовать

Скажу более конкретно:
!(w>=0) - это НЕ проверка на Nan, а лишь желание положиться на определенное поведение компилятора (которому он совершенно не обязан следовать), причем абсолютно не переносимое. Чем это лучше того, что человек вообще не проверит входные данные?
Поэтому говно, однозначно.

"совершенно", "абсолютно" - никогда не верьте таким "превосходным степеням", это банальная попытка "взять на понт" - и ничего более Пользуюсь этим приемом со времен CodeWarrior, сколько компиляторов за это время сменил - не считал, ну может десяток. Пока проблем не было. Да и чего это я не должен верить справочнику

If the implementation supports IEEE floating-point arithmetic (IEC 60559),
    If the argument is less than -0, FE_INVALID is raised and NaN is returned.

Ах, возможно я буду работать на платформе где не поддерживается IEC 60559!! Ну если доживу до этого - тогда и буду разбираться  

[Old]

Что-то мне совсем не хочется так делать в рабочем коде.

Поэтому и нужно проверять аргументы функции до ее вызова, чтобы не поймать на выходе NaN.

[ViTech]

В том же mingw 5.4.0 выражение "sin( sqrt( -3.14 ) )" вполне себе вычисляется и возвращает значение "-0.00159265", которое выглядит вполне нормальным и не NaN.

Ну что же Вы аргументируете багами конкретного компилятора? Некорректно

Я поэтому и спрашивал, баг это или фича . Похоже на баг и дальнейшие расследования привели сюда: sqrt() no longer returns NaN for x less than -0, история изменений sqrt.def.h. Больше всего интересен Commit [6617eb] и мотивы, по которым поломали поведение по справочнику:

The R language has some hacks specifically for mingw-w64 that were caused by our handling of NaNs in sqrt(x). R uses a special valued NaN to mean 'Not Available' and expects it to be retained through various calculations. Our sqrt(x) doesn't do this, instead it normalises such a NaN (retaining sign).

Т.е. NaN'ы разные бывают . Кому-то нужен "special valued NaN", но sqrt обрезает до "обычного NaN", и чтобы что-то работало, нужно "some hacks specifically for ..." .

Заодно можно посмотреть как проверяют входные данные. Если предположить, что разработчики компилятора лучше знают внутреннюю кухню с float, NaN и прочим, то почему они пишут долго и муторно:

Код

C++ (Qt)
int x_class = fpclassify (x);
if (x_class == FP_NAN || signbit (x))
{ ... }

а не быстро и эффективно:

Код

C++ (Qt)
if (!(x>=0))
{ ... }