On Wed, Jan 18, 2006 at 09:38:04AM +0800, 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'd like to point out that there's no reason in principle that a failure
undef c
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
At 9:50 AM +0800 1/18/06, Audrey Tang wrote:
However, I think one of P6's idea is that the user should not have
to care between 0 and 0.0's behaviours, so maybe it makes sense to
do the same thing (be it NaN or exception) both ways.
I'm not sure that IEEE 754/854 still applies if we want to merg
Audrey Tang wrote:
> That seems to follow from the standard (ruby, ocaml, mzscheme currently
> does that), but some may also argue for NaN bothways (ghc, js) or an
> exception bothways (perl5, python).
Er, wait, ghc also raises an exception for (div 0 0), because it
distinguishes integer (div) wit
Luke Palmer wrote:
> I believe we've been through this before. We go with a standard,
> probably IEEE, horridly mathematically unappealing though it may be.
> It will be easier to implement and it will be more predictable, both
> because most other language follow standards, too.
"The good thing
On 1/17/06, Audrey Tang <[EMAIL PROTECTED]> wrote:
> I personally like having 0/0 be NaN and 1/0 be Inf (as in JavaScript),
> but all of Python/Perl/Ruby/Scheme/OCaml throws exceptions for them...
I believe we've been through this before. We go with a standard,
probably IEEE, horridly mathematica
On 1/17/06, Audrey Tang <[EMAIL PROTECTED]> wrote:
> But putter on #perl6 reports "1" on his amd64. I'd be happy we spec it
> has to have to return 1 always for boxed Num types, even though it means
> additional cycles for boxed numeric types.
Isn't the point of boxing to provide a hardware-indep
Doug McNutt wrote:
>> - - Specify them to return some definite value.
> Only on a machine that doesn't do it in hardware or in some special perl
> function that's unlikely.
This question arises as different platform answer things differently for
the native calculation of eg. 1**Inf.
>
>> At this
Physicist here. One who believes -2**2 is negative.
At 23:26 +0800 1/17/06, Audrey Tang wrote:
>Several options:
>- - Use whatever the underlying "num" semantics available
That's likely to be in hardware. It might even be hard to detect without
looking at the NaN returned and that would be a was
Audrey Tang wrote:
> Assuming "num" uses the underlying floating point semantic (which may
> turn 0/0 into NaN without raising exception), what should the default
> "Num" do on these forms?
>
> 0/0
> 0*Inf
> Inf/Inf
> Inf-Inf
> 0**0
> Inf**0
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Assuming "num" uses the underlying floating point semantic (which may
turn 0/0 into NaN without raising exception), what should the default
"Num" do on these forms?
0/0
0*Inf
Inf/Inf
Inf-Inf
0**0
Inf**0
11 matches
Mail list logo
