At 09:38 +0800 1/18/06, Audrey Tang wrote: >Also, would you be happy with different treatments of Int/Int versus >Num/Num? > > 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 addition. 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 <--
