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
