Как корректно обработать деление на 0, логарифм нуля, и т.п.

[zzzseregazzz]

Заметил, что в таких ситуациях (при работе с типом double) не генерируется никаких исключений.
Когда деления часто встречаются в программе, контроль каждого деления сильно загромождает код. 
QString::number применительно к результату таких операций выдает непонятные надписи вроде "inf".
Как правильно обработать такие ошибки?
Есть ли настройки компиляторов (в Windows и Linux) для того, чтобы в таких ситуациях бросались исключения?
Стоит ли написать и везде использовать класс-обёртку к базовым типам?

[Igors]

Это называется nan (not a number). Имеет свойство быстро размножаться т.к. любая опреация с ним производит только nan. Решение - проверять все аргументы, напр на ноль не делить.  Желание сачкануть (генреация исключений) в данном случае неуместно, т.к. проверка всяких граничных условий есть часть работы.

[zzzseregazzz]

Если деление в каждой 2-й строке, то что тогда делать?
Проверить аргументы недостаточно, т.к. 0 может получиться в процессе вычислений.

[Igors]

Если деление в каждой 2-й строке, то что тогда делать?

То что все делают - проверять и подсекать значения до нужного/валидного диапазона.

Проверить аргументы недостаточно, т.к. 0 может получиться в процессе вычислений.

Значит надо сохранить напр образовавшийся делитель во временной переменной и ее провеоить.

Если вылазит nan, значит входные данные некорректны - значит надо или автоматом делать их корректными или давать пользователю отлуп с указанием что не так. А выскакивать исключением здесь неграмотно

[Авварон]

А ведь на форуме выкладывали библиотечку, преобразующую SIG* в исключения:)

[zzzseregazzz]

То что все делают - проверять и подсекать значения до нужного/валидного диапазона.

Например как результат деления на 0 вернуть 1e+100 ? А почему не 3e+200? Нельзя некоректные данные сделать корректными.

[zzzseregazzz]

Значит надо сохранить напр образовавшийся делитель во временной переменной и ее провеоить.

Если проверять каждое деление может существенно упасть производительность.
Не говоря уже о читаемости кода.

[Igors]

Если проверять каждое деление может существенно упасть производительность.
Не говоря уже о читаемости кода.

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

Напр в исходном массиве треугольников могут быть такие что их площадь слишком мала или нулевая. Да, придется их сначала отфильтровать и удалить из контейнера, иначе быстро получу nan'ы. А выбросив исключение - что дальше? С этими данными не работаем, а почему - хз. Часто только этим профессиональный софт отличается от любительского.

[zzzseregazzz]

Простой пример. Надо отобразить отношение сигнал/шум в логарифмическом масштабе.
 
Что делать, если
- нет ни сигнала ни шума - log(0/0)
- сигнал есть, шум нулевой - log(1/0)
- сигнала нет, шум есть - log(0)

В первых двух случаях получаем сразу 2 неопределённости, но при этом все ситуации вполне корректны.

Как представить результат в виде строки?

[Igors]

Не знаю причем здесь строка. Ввести порог шума и сигнала - достаточно малые числа. типа 1.0e-8, это должно быть известно по задаче. Ну или просто if'ами. В любом случае exception здесь неуместны, т.к. ситуация штатная, корректная (по крайней мере с точки зрения пользователя), и обработке подлежит

[zzzseregazzz]

Т.е. из 0 делаем 1.0e-8. При этом считаем в несколько этапов - вместо

Код

C++ (Qt)
double sn=log(s/n);

пишем

Код

C++ (Qt)
double n_=((n<=0)?1e-8:n);
double sn_=s/n_;
double sn__=((sn_<=0)?1e-8:sn_);
double sn=log(sn__);

Боюсь, что это не пройдет code review из-за большого объёма и плохой читаемости, даже без учета логики (а если написать через if, то тем более).

Пусть пришел сигнал 1e-8, а шум нулевой.
Вместо 0 подставляем 1e-8. т.е. получается, что сигнал равен шуму - а это совсем неправильно.

[m_ax]

Да прибавьте в числителе и знаменателе (к шуму и сигналу) малую величину epsilon (cut-off)

Код

C++ (Qt)
static const double epsilon = 0.000001;
 
double sn = log((s + epsilon)/(n + epsilon));
 

[Igors]

Код

C++ (Qt)
double sn=log(s/n);

пишем

Код

C++ (Qt)
double n_=((n<=0)?1e-8:n);
double sn_=s/n_;
double sn__=((sn_<=0)?1e-8:sn_);
double sn=log(sn__);

Боюсь, что это не пройдет code review из-за большого объёма и плохой читаемости,

Точно не пройдет, но никто не мешает записать это нормально, напр

Код

C++ (Qt)
double signal = GetSignal();
double noise = GetNoise();
if (Max(signal. noise) < fudge_Factor) 
 result = 0; 
else {
 double ratio = Clamp(signal, signal_Min, signal_Max) / Clamp(noise. noise_Min, noise_Max);
 result = log(ratio);
} 

[zzzseregazzz]

Ну вот добрались уже до 8 строчек вместо одной.
К тому же следует учесть, что все функции теоретически могут бросить исключение, и должны быть обернуты в try{}catch{}.

[Igors]

Ну вот добрались уже до 8 строчек вместо одной.

Не надо стремиться написать так

Код:

double sn_=s/n_;

Так пишут женщины - и то не все 

К тому же следует учесть, что все функции теоретически могут бросить исключение, и должны быть обернуты в try{}catch{}.

Ни разу не видел чтобы напр sqrt, log. acos и.т.п. вызывали исключение. Дал некорректный аргумент - получил nan, вот и вся любовь. А если мы хотим идти своим путем, то проще бросить так

Код

C++ (Qt)
if (sn != sn) throw;