0^0
Kwankyu Lee
The following scares me.
sage: 0^0
1
sage: F.<a>=GF(5)
sage: F(0)^0
Traceback (most recent call last):
...
ArithmeticError: 0^0 is undefined.
For any x, x^0 is 1 by definition. Isn't it in Sage? I am using Sage
4.1.2
Kwankyu
John H Palmieri
On Oct 22, 1:25 am, Kwankyu Lee <ekwan...@gmail.com> wrote:
> Hi,
>
> The following scares me.
>
> sage: 0^0
> 1
> sage: F.<a>=GF(5)
> sage: F(0)^0
> Traceback (most recent call last):
> ...
> ArithmeticError: 0^0 is undefined.
>
> For any x, x^0 is 1 by definition.
Anyway, 0^0 is undefined in mathematics, so it's good that it's
undefined in Sage.
William Stein
It's defined for Sage *integers*:
sage: 0^0
1
Among other reasons, this is for compatibility with Python and many,
many other programs:
sage: int(0)^int(0)
1
sage: maple('0^0')
1
sage: gap('0^0')
1
sage: gp('0^0')
1
William
Jason Grout
Even for discrete things like elements of GF(5)? I haven't thought
about what 0^0 is for things where the continuous limit doesn't make sense.
Jason
--
Jason Grout
Francois Maltey
> Even for discrete things like elements of GF(5)? I haven't thought
> about what 0^0 is for things where the continuous limit doesn't make sense.
>
product is the unit element.
The reason is the same for 0!=1. But x^(-n) is only defined if x has an
inverse.
In analysis 0^0 is undefined because it's a undefined limit:
un^vn = exp(un * log vn).
Try with un=1/n et vn=1/n and limit un^vn == 1
But for un=a/log n -> 0 and vn=1/n -> 0 un*log vn =-a and un^vn ->
e^(-a) != 1.
Martin Rubey
>>
>> I always thought that for any y, 0^y = 0.
>>
>> undefined in Sage.
>
> It's defined for Sage *integers*:
...
I think I've seen this discussion before. Categories!
Martin
Francis Clarke
particularly pages 407--408:
\bib{MR1163629}{article}{
author={Knuth, Donald E.},
title={Two notes on notation},
journal={Amer. Math. Monthly},
volume={99},
date={1992},
number={5},
pages={403--422},
}
Among the arguments given in favour of 0^0 = 1 are (1) that we might
like the binomial expansions to hold in general; (2) that there is
precisely one function from the empty set to itself.
Tim Lahey
I know of at least one case where 0^0 needs to be undefined in order to
get the right answer to a problem. In Mechanics of Solids, there are
singularity functions where,
<x-a>^n = 0 , x < a
= (x-a)^n , x >= a
if n > 0. n = 0 gives the Heaviside function, n = -1 is the Dirac delta
and n = -2 is the unit doublet which is the derivative of the delta
function.
There's also integration rules, but they're unimportant for this
discussion.
So, 0^0 amounts to defining that the Heaviside function = 1 at x = a.
I prefer
to think of it as undefined and define it strictly in terms of left
and right
limits.
Cheers,
Tim.
---
Tim Lahey
PhD Candidate, Systems Design Engineering
University of Waterloo
http://www.linkedin.com/in/timlahey
John H Palmieri
On Oct 22, 8:57 am, William Stein <wst...@gmail.com> wrote:
>
> > Anyway, 0^0 is undefined in mathematics, so it's good that it's
> > undefined in Sage.
>
> It's defined for Sage *integers*:
>
> sage: 0^0
> 1
sage: 0.000^0.000
1.00000000000000
Shouldn't this be undefined?
John
William Stein
Sage's behavior for 0.0^0.0 is determined by MPFR's, and MPFR follows
"the ISO C99 standard for the pow function" as explained here:
http://www.mpfr.org/mpfr-current/mpfr.html
In particular, see the rule that "pow(x, ±0) returns 1 for any x, even
a NaN." Indeed:
sage: RR('NaN')^0
1.00000000000000
William
-- William
John H Palmieri
real numbers) is that it doesn't exist, right? Or did I miss a memo
somewhere? What about these:
sage: CC(0)^CC(0)
NaN - NaN*I
sage: 0^CC(0)
NaN - NaN*I
sage: CC(0)^0
ArithmeticError: 0^0 is undefined.
sage: CC(Infinity)^0
1.00000000000000
sage: CC(Infinity)^CC(0)
NaN - NaN*I
This one seems like a real bug:
sage: CC('NaN')^0
1.00000000000000
sage: CC('NaN')^CC(0)
Exception RuntimeError: 'maximum recursion depth exceeded while
calling a Python object' in <type 'exceptions.RuntimeError'> ignored
John
Fredrik Johansson
What do you mean by "mathematical standard"? A perfectly valid view is
that 0^0 = 1 and that the function f(x,y) = x^y simply is
discontinuous.
> sage: CC(0)^CC(0)
> NaN - NaN*I
> sage: 0^CC(0)
> NaN - NaN*I
> sage: CC(0)^0
> ArithmeticError: 0^0 is undefined.
> sage: CC(Infinity)^0
> 1.00000000000000
> sage: CC(Infinity)^CC(0)
> NaN - NaN*I
The inconsistency is surely not good.
Fredrik
Tom Boothby
John H Palmieri
On Oct 22, 4:15 pm, Fredrik Johansson <fredrik.johans...@gmail.com>
wrote:
>
>
>
>
>
professors -- if they were doing something unusual or something about
which there was some controversy, they would mention it. For some
more evidence, for example, in the article cited by Francis Clarke,
Knuth notes on p. 407 that Cauchy said that 0^0 was undefined. There
were a few flawed attempts to explain that 0^0 = 1, after which, "The
debate stopped there [in 1834], apparently with the conclusion that
0^0 should be undefined." I interpret this as saying that, based on
the historical record, 0^0 is undefined. Knuth then proceeds to argue
that this is the wrong convention, but the whole reason he has to work
so hard is because 0^0 being undefined *is* the standard.
I can see that there are reasons for changing this, but I think it's a
little dangerous to do so. (For example, it will cause endless
trouble in calculus classes because students don't understand that
anything might be discontinuous, so if their calculator and computer
tell them that 0^0 = 1, they won't really understand why it's an
indeterminate form -- they'll just resentfully view it as another
random, arbitrary thing that mathematicians do and that they (the
students) have to memorize. In actuality, it's setting 0^0 to be 1
that's arbitrary, at least when you have real arguments, because of
the discontinuity of x^y.)
John
Dr. David Kirkby
For what it is worth,
Mathematica 7.0 for Sun Solaris SPARC (64-bit)
Copyright 1988-2009 Wolfram Research, Inc.
In[1]:= 0^0
0
Power::indet: Indeterminate expression 0 encountered.
Out[1]= Indeterminate
William Stein
Well like it or not, it is a fact that 0.0^0.0 = 1 *is* the official
ISO 99 standard. Note that ISO = "international standards
organization".
I'm not making an argument here for or against this. But there is no
arguing with it being an official standard as dictated by an
international standards organization for perhaps the worlds most
popular programming language (C/C++). I know nothing of why they
made that choice.
Here's an IEEE page spelling this out too:
http://www.opengroup.org/onlinepubs/009695399/functions/pow.html
William
William
John H Palmieri
> Well like it or not, it is a fact that 0.0^0.0 = 1 *is* the official
> ISO 99 standard. Note that ISO = "international standards
> organization".
>
> I'm not making an argument here for or against this. But there is no
> arguing with it being an official standard as dictated by an
> international standards organization for perhaps the worlds most
> popular programming language (C/C++).
automatically accept as standards something designated for use in a
programming language. I know that Sage is a programming environment,
but shouldn't it reflect mathematical truth, not computer programming
standards? If the ISO established a standard which was more
objectionable from a mathematical point of view, would we
automatically adapt it?
> I know nothing of why they made that choice.
"The following sections are informative. ... Rationale: None"
:p
Kwankyu Lee
algebraic programs often relied on this fact. If it was not the case,
then I would have been forced to use some 'if' constructs, or would
have mysterious bugs in the program.
Anyway, I am amazed that mathematicians do not agree on this matter
unanimously...
Kwankyu
William Stein
I just mentioned "0^0" to my wife (a Biologist), and she instantly
said "it doesn't exist".
William
John H Palmieri
>
> I just mentioned "0^0" to my wife (a Biologist), and she instantly
> said "it doesn't exist".
little silly so I probably won't do it, but it would be easy to do
with Catalyst.
In any case, the bug and the inconsistencies with the complex numbers
should probably be dealt with. (But not by me.)
John
Robert Bradshaw
>
> On Oct 22, 5:11 pm, William Stein <wst...@gmail.com> wrote:
>> Well like it or not, it is a fact that 0.0^0.0 = 1 *is* the official
>> ISO 99 standard. Note that ISO = "international standards
>> organization".
>>
>> I'm not making an argument here for or against this. But there is no
>> arguing with it being an official standard as dictated by an
>> international standards organization for perhaps the worlds most
>> popular programming language (C/C++).
>
> There is a question about whether we, as mathematicians, should
> automatically accept as standards something designated for use in a
> programming language. I know that Sage is a programming environment,
> but shouldn't it reflect mathematical truth, not computer programming
> standards?
I actually remember going through and fixing a whole bunch of rings
that didn't raise errors on 0^0--most of them were just an oversight.
(I think Tom Boothby was there too...) For Integers this was
explicitly changed back to be like Python and MPFR http://hg.sagemath.org/sage-main/diff/fa97eed25973/sage/rings/integer.pyx
. I'd rather have an error in most cases (especially for finite
fields) but consistency with the (Python) environment does have its
merits, if just to reduce confusion.
- Robert
Paul Zimmermann
> Date: Thu, 22 Oct 2009 14:14:41 -0700
>
> On Thu, Oct 22, 2009 at 2:02 PM, John H Palmieri <jhpalm...@gmail.com> wrote:
> >
> >
> >
> > On Oct 22, 8:57 am, William Stein <wst...@gmail.com> wrote:
> >> On Thu, Oct 22, 2009 at 8:11 AM, John H Palmieri <jhpalmier...@gmail.com> wrote:
> >>
> >> > Anyway, 0^0 is undefined in mathematics, so it's good that it's
> >> > undefined in Sage.
> >>
> >> It's defined for Sage *integers*:
> >>
> >> sage: 0^0
> >> 1
> >
> > What about:
> >
> > sage: 0.000^0.000
> > 1.00000000000000
> >
> > Shouldn't this be undefined?
> >
> > John
>
> Sage's behavior for 0.0^0.0 is determined by MPFR's, and MPFR follows
> "the ISO C99 standard for the pow function" as explained here:
>
> http://www.mpfr.org/mpfr-current/mpfr.html
>
> a NaN." Indeed:
>
> sage: RR('NaN')^0
> 1.00000000000000
>
> William
>
> -- William
indeed. Note that one gets the same results in C:
#include <stdio.h>
#include <math.h>
int
main ()
{
double x = 0.0;
double y = 0.0;
double z = pow (x, y);
printf ("%f^%f=%f\n", x, y, z);
}
patate% gcc e.c -o e -lm
patate% ./e
0.000000^0.000000=1.000000
Paul Zimmermann
PS: Maple is inconsistent here:
|\^/| Maple 10 (IBM INTEL LINUX)
._|\| |/|_. Copyright (c) Maplesoft, a division of Waterloo Maple Inc. 2005
\ MAPLE / All rights reserved. Maple is a trademark of
<____ ____> Waterloo Maple Inc.
| Type ? for help.
> 0^0;
1
> 0.0^0.0;
Float(undefined)
Peter Jeremy
>On Thu, Oct 22, 2009 at 4:52 PM, John H Palmieri <jhpalm...@gmail.com> wrote:
>> First, it's what I've always been taught, and I trust my teachers and
>> professors -- if they were doing something unusual or something about
>> which there was some controversy, they would mention it. For some
>> more evidence, for example, in the article cited by Francis Clarke,
>> Knuth notes on p. 407 that Cauchy said that 0^0 was undefined. There
>> were a few flawed attempts to explain that 0^0 = 1, after which, "The
>> debate stopped there [in 1834], apparently with the conclusion that
>> 0^0 should be undefined." I interpret this as saying that, based on
>> the historical record, 0^0 is undefined. Knuth then proceeds to argue
>> that this is the wrong convention, but the whole reason he has to work
>> so hard is because 0^0 being undefined *is* the standard.
By co-incidence, the latest Parabola[1] arrived yesterday and it
includes a discussion by Michael Deakin[2] on this (along with "is 1
prime" and "is 0 a natural number". He states that traditionally,
Euler, Pfaff and Mobius held that 0^0 == 1, whilst Cauchy, Libri and
two anonymous authors held that 0^0 is undefined, with the latter camp
"winning". Starting in 1970, Vaughan and Knuth joined the debate in
the former camp and the article concludes that 0^0 == 1 is now the
preferred convention. (The article includes the mathematical
arguments the various proponents used).
>Well like it or not, it is a fact that 0.0^0.0 = 1 *is* the official
>ISO 99 standard. Note that ISO = "international standards
>organization".
Likewise the ISO APL standard also defines 0*0 as 1 ('*' is the
power operator in APL). I'm not sure what the FORTRAN standard
says.
These standards all relate to the power operator in specific
programming languages and don't necessarily reflect mathematical
conventions as programming languages have limitations that pure
mathematics doesn't. A review of the relevant working group
debates might shed some light on their reasoning.
[1] "Parabola incorporating Function, a mathematics magazine for
secondary schools", ISSN 1446-9723
http://www.maths.unsw.edu.au/highschool/parabola.html
[2] Adjunct Senior Research Fellow in Mathematics & Statistics at
Monash University.
--
Peter Jeremy