0^0 in sage-2.10.1 still undefined for Rationals...

2 views
Skip to first unread message

Georg

unread,
Feb 4, 2008, 10:23:10 AM2/4/08
to sage-support
Hi,
sage: Rational(0)^Rational(0)
---------------------------------------------------------------------------
<type 'exceptions.ArithmeticError'> Traceback (most recent call
last)

/home/georg/<ipython console> in <module>()

/home/georg/rational.pyx in sage.rings.rational.Rational.__pow__()

<type 'exceptions.ArithmeticError'>: 0^0 is undefined.

should not be, or?
Georg

William Stein

unread,
Feb 5, 2008, 10:23:51 AM2/5/08
to sage-s...@googlegroups.com

Thanks for pointing this out:

http://trac.sagemath.org/sage_trac/ticket/2057

Luis Finotti

unread,
Feb 5, 2008, 1:12:02 PM2/5/08
to sage-s...@googlegroups.com
Dear all,

I'm probably exposing my ignorance here, but should 0^0 be really
defined? I understand that it might be helpful sometimes in
Taylor/Laurent series, but couldn't it give some other problems?
E.g.,

sage: lim(x^(1/log(x)),x=0,dir='above')
_2 = e

If one actually defines a function and sage tries to compute, can't it
spill out 1 if it gets 0^0, when it might not be the case...

If I am completely missing the point here, please forgive the noise...


Best,

Luis

Georg

unread,
Feb 5, 2008, 5:54:21 PM2/5/08
to sage-support
Luis,
there are two threads about this topic in the sage-newbie group (with
the name "0^0 undefined" and "wow 0^0 shure is inconsistent in sage")
which i think should adress your doubts,
I'm not the expert here, but I have a practical application concerning
combinatorial sums where it's assumed for 0^0 to be 1, and I guess in
most applications it's like this, apart from the fact that in most
other Computer Algebra Systems it's defined this way.
If it would not be defined at all, I would have to do a workaround
like a conditional "if" or a "try" statement to handle this case.
So I think it's good to define it at all.
Maybe it would be a good idea to have the possibility as a user to
temporary redefine it, but this would also bear the risk of
inconsistency among all the different number types of sage (and
python).

> sage: lim(x^(1/log(x)),x=0,dir='above')
> _2 = e
>
> If one actually defines a function and sage tries to compute, can't it
> spill out 1 if it gets 0^0, when it might not be the case...

I'm not shure if I understand what your mean, I don't see a problem
here, keep in mind that the limit value of a function at a certain
point is completly independent of the function value of this function
at this point, there even does not have to exist a function value at
all at this certain point, these notions (limit value and function
value) at a certain point are completely independent, so the
implementation of the function lim must not depend on the function
value.
Georg
Reply all
Reply to author
Forward
0 new messages