3 ms·
So... if I do: x = a/b + c/d + e/(f*g/h) I need to check: if(b == 0 || d == 0 || f == 0 || g == 0) rather then: if(isFinite(x)) Or whatever func
by mreome 8y ago
So... if I do:
x = a/b + c/d + e/(f*g/h)
I need to check:
if(b == 0 || d == 0 || f == 0 || g == 0)
rather then:
if(isFinite(x))
Or whatever function/equality check is appropriate, or a try/catch if it throws an exception.
I have to say that using a single check on the result seems significantly less prone to bugs then having to check all the values that could produce an invalid result.
- cryptonector 8y agoWithout NaN you don't get to see that the computation "went wrong". But that's not necessarily a problem, and only if it is must you check whether those inputs are zero. Still, I agree that a NaN value(s) is(are) preferable for this reason.
- mreome 8y agoOf course, there will be cases where you need to check some of the initial values regardless, but often you just care if the result is valid. From a defensive programming stand-point, if you don't expect any of those values to be zero, you just check for NaN at the end rather then carefully reviewing your calculations for which values you have to check. I would REALLY hate having to write a geometry library without NaN values. Both because of error checking, and the fact that NAN/INF is often the 'correct' answer when it's the result of a calculation.
- zokier 8y agoThe problem being that constructing isFinite(..) for machine integer types is basically impossible.