At 11:52 +0200 10/8/07, TSa wrote:
>HaloO,
>
>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
>
>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.
>From this engineer/physicist's point of view the most valuable part of the NaN
>concept is that NaNs can be passed to formulas and functions in a way that
>avoids error checking altogether.
$B = Inf ( as the result of a previous calculation)
$result = $A / (1.0 + 1.0 /$B);
need not return an error because one of its arguments is an error. The result,
to the expected precision of floating numerics, is exactly $A. Such formulas,
usually much more complicated, do crop up regularly and it's a pain to have to
pre-check for out-of-range values in a tight loop. It's best not to trap that
kind of error but to let the calculation proceed to a result which might, or
might not, be out of range.
Vectors and complex numbers, which can be thought of as 2-D vectors with
different rules, don't really exhibit the NaN concept. A component can be a NaN
but nobody has defined what a whole vector as a NaN means. Asking whether one
complex number is bigger than another results in an answer that depends on the
user's intentions and is probably not something that should be frozen into a
compiler. Let the programmer do an OR on each of the components as desired. He
might really want to compare lengths of the vectors.
Remember that there are some 2**22 possible NaNs in the bit pattern of a 32 bit
float. Only a few are defined by the IEEE. It's possible to use others as
results of a specialized subroutine. "The series didn't converge" for instance.
= Inf - Inf; # should not return zero! Those two Inf's are not equal except in
some special circumstances that will not be known. They might be calculated
from the same series that didn't converge but that's a problem for the likes of
Maple or Mathematica. Nobody should expect perl to worry about that kind of
thing. Inf == Inf returning true would make this curious if $A = Inf and $B =
Inf.
$Y = (A$ == B$) ? 0 : A$ - B$;
Wikipedia for IEEE 754
<http://en.wikipedia.org/wiki/IEEE_floating-point_standard> is accurate. Actual
IEEE standards have to be purchased and they are not cheap. Even as a member I
don't get to see them for free and if I sound upset, I intend to. GNU forever.
<http://en.wikipedia.org/wiki/NaN> Discusses "signaling" and "quiet" NaN's. It
might be possible for perl6 to trap errors for the signaling variety and not
for the quiet ones but that's not a complete answer.
For a Practical Extraction and Reporting Language perl6 should probably adopt
Wikipedia as an authority and, as far as possible, avoid making new definitions.
--
--> Halloween == Oct 31 == Dec 25 == Christmas <--
