At 09:38 +0800 1/18/06, Audrey Tang wrote:
>Also, would you be happy with different treatments of Int/Int versus
> 0/0 # fail "illegal division by zero"
> 0.0/0.0 # NaN
I plead guilty. I was not aware that perl6 was going to allow types to be
defined like int and float.
While learning perl 5 I was frustrated by that lack at first but I came to like
it after a while because the treatment of strings that happen to be numbers is
$serial = "0000000048";
behaves like a numeric 48 if I add to it but I don't have to perform an sprintf
to get the zeros back if my goal is to repeat the value read from some HTML
page or cookie. As a Gegenbeispeil try entering that or even a date in M$Excel.
It will be immediately converted to a floating point seconds after the epoch
and there is no way to recover the input text. I hate it.
So. . .
If perl6 will allow me to define a variable as type int64, int32, or things
like that then division by zero should be an exception as should overflow on
If "the perl way" is the goal then users who don't want to go to C should be
treated to $numerics that allows for strings, scientific notation, and the like
while doing the right thing. For that, converting 0/0 to a floating point
division with a NaN result is quite proper.
The important thing is that ($aa + $bb)/$aa should return 1.0 when $bb is a NaN
underflow or if $aa is a NaN Inf. Those may not be the best examples but you
get the idea. Some intermediate results can return NaN's in a way that
inclusion in a later calculation can produce a correct result in spite of the
NaN. Numeric values often come from an external source. Unnecessary and
confusing validation of that kind of input should not be required just to keep
a program running. Just let the final answer show as a NaN and keep the
programming clear and short.
--> There are 10 kinds of people: those who understand binary, and those who