HaloO, brian d foy wrote:
So, then, back to the question. People don't care how it's implemented (and it would be great if we didn't have to explain it). What's the idiom for the comparison going to be?
My understanding is that values like NaN or Inf are exceptional. That means you can understand them as unthrown or in-band exceptions. Like undef they might contain interesting information about their origination. That being said I think these exceptional values should not be re-inserted into the regular flow of computation by simple comparison. In other words $x == NaN and the like should be undef. That means that these values behave viral in the sense that more and more of the values handled in a program become undef. The only operator that can be used to investigate these values should be ~~ and the given/when statement that uses it. This means we need a standard set of e.g. NaN cases. Does someone know what IEEE defines in that area? Here's a little code example illustrating my point: if $x ~~ NaN { given $x { when DIV_ZERO {...} when UNDERFLOW {...} when OVERFLOW {...} } } Also handling Inf is a difficult thing to do. In general Inf == Inf will hardly hold. The first thing I would expect is Inf to be properly typed. That is Inf[Num] is different from Inf[Complex] and for finite types any number outside the valid range could represent Inf. Regards TSa. -- You know, it would be sufficient to really understand the electron. --- Albert Einstein