wow 0^0 sure is inconsistent in Sage (was Re: [sage-newbie] Re: 0^0 undefined)
William Stein
>
> On Jan 29, 2008 12:18 PM, Georg <georg.gra...@gmail.com> wrote:
> >
> > Hi,
> > is there a way so that
> > 0^0
> > yields 1.
> > thanks in advance, Georg
It "works" if you using Sage's multiprecision reals, or Python floats or ints:
sage: 0.0^0.0
1.00000000000000
sage: float(0)^float(0)
1.0
sage: int(0)^int(0)
1
sage: RDF(0)^RDF(0)
nan
sage: CDF(0)^CDF(0)
0
sage: CC(0)^CC(0)
boom -- traceback
sage: 1^1
1
sage: 0^0
boom -- <type 'exceptions.ArithmeticError'>: 0^0 is undefined.
I'm surprised by this. I thought 0^0 would be undefined
everywhere, but instead it's undefined in 2 places, defined
in others, and Nan in one.
Paul Zimmerman -- what should we do?
>
>
> Well, 0^0 is an indeterminate form:
> http://en.wikipedia.org/wiki/Indeterminate_form#The_form_00
>
> So, do you mean something like this?
> sage: assume(x>0)
> sage: limit(x^x, x=0)
> 1
>
> Best,
> --
> Hector
>
>
> >
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
Stephen Forrest
I believe that for floats, a NaN response is required for IEEE 754
compliance, no?
For purposes of comparison, I can attest that Maple is inconsistent as
a consequence of deliberate design on this issue. For integers, 0^0
is 1; on the other hand, 0.0^0.0 is Float(undefined), that is
essentially NaN. My understanding is that 0^0=1 was the originally
desired outcome (for the usual reasons), but the NaN result was
retained for float input in order to retain IEEE 754 compliance.
regards,
Steve