Старая шутка

[Igors]

Или теперь загадку надо переформулировать так: "При каком типе w приведённый фрагмент не является говнокодом?" .

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

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

[Авварон]

Небось опять вещественная арифметика, +/-inf, +/-0, nan. Скука.

[Igors]

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

Если хотя бы один из аргументов 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)) ..

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

[ViTech]

Код:

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

С "отрицательно" понятно, а "невалидно" - из каких соображений следует? Если установлено, что w типа float.

[Racheengel]

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

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

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

[Old]

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

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

[Igors]

С "отрицательно" понятно, а "невалидно" - из каких соображений следует? Если установлено, что w типа float.

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

Код:

if (w < 0)  // false если w = nan

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

Я тоже люблю вот так резвенько все решать Типа "nan не должен появляться вообще!". Некоторые так и делают

void QVector3D::normalize()

Normalizes the currect vector in place. Nothing happens if this vector is a null vector or the length of the vector is very close to 1.

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

Код

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

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

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

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

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

[Old]

Так совсем плохо, теперь следов ошибки никаких, и почему не работает - хз.

Ну конечно, присвоить переменной вместо NaN ноль, это замечательно. И сразу понятно почему не работает.

Ага, ага, а куда рыпнуться если "вскипело" (bail out)? Размазывать мульен exception?

Ну как вариант - исключения. В любом случе нужно завершить приложение и отправить его на доработку.

В общем, проверка на nan - совершенно легальный и полезный прием. Ну, как и все, хорош в меру

Конечно, как и деление на 0.

[ViTech]

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

[Igors]

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

Не обнулится (для INF), но знак будет проверен корректно. Отличаться будет: любая арифметика с nan производит nan (размножается очень быстро), а INF легко пресечь обычными средствами, напр

Код

C++ (Qt)
if (!(w >= 0))
 w = 0;
else
 w = MIN(w, 1.0e+20);  // не nan, можно клампить 

[ssoft]

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

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

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

Код:

acos( cos( a ) * sin( b ) / sin( c ) );

при всех проверках на валидность входящих параметров, вполне может дать 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;
 

[Igors]

Приходится писать, что-то типа такого).

Код

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;
 

Если nan уже просочился, то все проверки вернут false. Да и assert и eps здесь ни к чему. Аккуратнее напр так

Код

C++ (Qt)
float d = cos(a) * sin(b) / sin(c);
float d2 = qBound(-1.0f, d, 1.0f);
if (fabs(d - d2) > 0)
 d = (value > 0) ? 0 : pi;
else
 d = acos(d2);
 

Но можно и так

Код

C++ (Qt)
float d = acos(cos(a) * sin(b) / sin(c));
if (IsNan(d))
 d = (value > 0) ? 0 : pi;
 

Хотя эти варианты не тождественны - и не только по скорости

[ssoft]

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

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

[ViTech]

Не обнулится (для INF), но знак будет проверен корректно. Отличаться будет: любая арифметика с nan производит nan (размножается очень быстро), а INF легко пресечь обычными средствами, напр

Код

C++ (Qt)
if (!(w >= 0))
 w = 0;
else
 w = MIN(w, 1.0e+20);

Т.е. надо проверять и отсекать не только NAN, но и +-INF, +-0 или ещё что в этом роде. Поэтому я про валидность и спрашивал. Проверка из первого сообщения достаточна для необходимой степени валидности значения float для дальнейших вычислений? Такие корявые проверки каждый раз писать надо? Почему не вынести в функцию с понятным названием и назначением?

[Igors]

И важным является написать программу таким образом, чтобы 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;
 

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