Почему бы и нет, тоже нормальная формулировка. Для int конечно тождественно

А вообще вещь известнейшая. Но стоит ее чуть-чуть замаскировать... В общем, если уж о говне заговорили, как старый солдатский фокус с лопатой  

Небось - авось, неужели так трудно дать простой грамотный ответ? Напр

Если хотя бы один из аргументов nan, то любое арифметическое сравнение возвращает false, хотя это и противоречит законам логики

C++ (Qt)
float w = sqrt(-1);
if (w >= 0) ..  // false 
if (w <= 0) ..  // false 
if (w == w) ..  // false, nan не равен самому себе 

Возвращаясь к исходному вопросу

C++ (Qt)
if (!(w >= 0)) // если w отрицательно ИЛИ невалидно

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

C++ (Qt)
if ((w < 0) || IsNan(w)) ..

Но то надо было заводить ф-цию, вероятно хедер. Ну и вообще "короче == круче", не так ли? 

Да нет уж, если логика алгоритма действительно допускает появление и сравнение nan-операндов, то это надо делать до условий, типа:

if (isNaN(w))
// bail out
else
if (w < 0)...

Так и чище, и понятней.

Если w свалилось в nan, то исходный код сработает (сравнение вернет false) и w будет присвоено 0. А в этом случае нет

Я тоже люблю вот так резвенько все решать Типа "nan не должен появляться вообще!". Некоторые так и делают
Так совсем плохо, теперь следов ошибки никаких, и почему не работает - хз. Да и рабочий метод нагрузили парочкой сомнительных fuzzy. А руками тоже неинтересно, напр

C++ (Qt)
float len = vec.length();
if (len > epsilon) 
 vec /= len;
 

Как, вместо 1 вызова 3 строки   И чему установить злополучный epsilon? Ах "исходя из требований задачи" (обычное вранье)

Ага, ага, а куда рыпнуться если "вскипело" (bail out)? Размазывать мульен exception? В общем, проверка на nan - совершенно легальный и полезный прием. Ну, как и все, хорош в меру

А почему акцент на NAN сделан? Будет w например равно INFINITY: оно для дальнейших вычислений сильно будет отличаться, если бы w было равно NAN? А по условию из первого поста не обнулится.

Абсолютно согласен  .
Правда ошибки такого рода не вполне очевидны, например, математические выражения типа


при всех проверках на валидность входящих параметров, вполне может дать NaN, всего лишь из-за того, что cos( a ) * sin( b ) / sin( c ) = 1.0000000000000001.
Но программисты должны помнить и об этом, что вещественные числа в информатике, совсем не то, что в математике.
Приходится писать, что-то типа такого).

C++ (Qt)
d = cos( a ) * sin( b ) / sin( c );
// проверка валидности
assert( ( abs( d ) - 1 ) < eps );
// приближенное вычисление
result = ( abs( d ) <= 1 - eps )
    ? acos( d )
    : ( value > 0 )
        ? 0
        : pi;
 

Здесь eps - очень сильно важна). Значение (для acos) для double с отклонением в 1e-12 можно посчитать несущественным, а вот 1.01 или 2.0 и т.д. означает явную алгоритмическую несогласованность входящих данных.

И важным является написать программу таким образом, чтобы nan не просочился. Последствия могут слишком дорого стоить).

Ах какими мудрыми (и назидательными) мы становимся когда ответ известен   Давайте лучше поумничаем "до того"

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

C++ (Qt)
float a;
...
float b = (a >= 0) ? sqrt(a)  : 0;
 

Разумеется второй вариант аккуратнее и чуть быстрее. Но есть ли еще какая-то разница?