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.
sure.
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" -CHB -- Christopher Barker, Ph.D. Oceanographer 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 Chris.Barker@noaa.gov