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 
well done.

$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 
don't <--

Reply via email to