On Thu, Aug 4, 2016 at 1:21 PM, Chris Kaynor <ckaynor@zindagigames.com> wrote:
If lower happens to be greater than upper, that's clearly a mistake. Its
better to get an exception immediately, rather than run through a
million calculations and only then discover that you've ended up with a
million NANs.

It's okay if you get a few NANs, that simply indicates
that one of your x values was a NAN, or a calculation produced a NAN.
But if *every* calculation produces a NAN, well, that's a sign of
breakage. Hence, better to raise straight away.

sure -- but one reason NaN exists is so that errors can get propagated through the hardware without bringing everything to a halt -- this is really key in vectorized operations. And it's really useful. So I"d rather not have an exception there, if you are doing something like:

[ clamp(x, y, z) for z in the_max_values]

might be better to check for NaN somewhere else than have that whole operation fail.

I think it would also require more special case checking in the code....

I personally don't have much opinion on NAN behaviour in general - I don't think I've ever actually used them in any of my code, and the few cases they show up, it is due to a bug or corrupted data that I want caught early.

exactly -- usually a bug or corrupted data -- if NaN is passed in as a limit, it's probably a error of some sort, you really don't want it silently passing your input value through.

And you have inf and -inf if you do want "no limit"



Christopher Barker, Ph.D.

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception