Re: Re: 0^0 = 1?

• To: mathgroup at smc.vnet.net
• Subject: [mg95857] Re: [mg95796] Re: 0^0 = 1?
• From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
• Date: Wed, 28 Jan 2009 06:44:04 -0500 (EST)
• References: <gl7211\$c8r\$1@smc.vnet.net> <gl9mua\$ajr\$1@smc.vnet.net> <200901271201.HAA23416@smc.vnet.net>

```On 27 Jan 2009, at 13:01, Dave Seaman wrote:

> There have been many discussions of this point in sci.math over the
> years.  The emerging consensus among mathematicians (not necessarily
> my
> own opinion) seems to be that it makes sense to observe that very
> distinction,
> namely, that 0^0 = 1 when the exponent is an integer, but that the
> expression should be left undefined when the exponent is real or
> complex.
>
> There is also considerable precedent in various programming
> languages for
> doing this.  In fact, the value of 0^0 (or 0**0 or pow(0,0), or
> whatever
> the notation may be) is often defined to be 1 of the appropriate
> base type,
> provided the exponent is an integer, and undefined otherwise.

Since you must know perfectly well that Mathematica does not
distinguish between the integer 0 and the complex number 0 your entire
argument is spurious in the context of the Mathematica language. You
can't seriously expect that Mathematica should be completely rewritten
to accommodate you on this.
>
>>>
>
>> One place I think it would it would cause problems is in
>> Mathematica Limit
>> and Series code. Things that do not evaluate to Indeterminate are
>> often
>> taken as "correct" limiting values. This is one reason that having
>> values
>> at discontinuities e.g. on branch cuts requires careful treatment,
>> special
>> code, is a source of bugs, etc. While I have not tried the
>> experiment, I
>> would venture to guess that making 0^0 evaluate to 1 would bring
>> substantial new troubles to that part of the code base. As I alluded
>> above, this sort of change incurs a development cost that can be
>> rather
>> steep, and for no gain I can discern.
>
> Mathematically, the definition of a limit makes no mention of
> whether the
> expression is defined at the point in question.  It's unfortunate that
> Mathematica code conflates two concepts that have nothing to do with
> each
> other.

But of course they do have something to do with each other and that
something is the concept of continuity of a function. If Mathematica
follows the conventions that functions are defined only where they are
continuous than it is reasonable, when computing a limit, to fist
check if the function has a value at the point where the limit is
being computer. If so, that value can be returned. This would give a
substantial benefit in terms of performance, which is of primary
importance for computer programs.

>
>
> There are several benefits that I can see for defining 0^0 = 1.
>
> 1) The binomial theorem says
>
> 	(a+b)^n = Sum[Binomial[n,k] a^k b^(n-k),{k,0,n}]
>
>   but in order for this to work for the case a=0 or b=0, we need 0^0
> = 1.
>
> 2) The derivative of x^n is D[x^n,x] = n x^(n-1), but in order for
>   this to work for the case n=1, we need 0^0 = 1.
>
> 3) The MacLaurin series for f[x] is given by
>
> 	Sum[D[f,{x,k}][0]/k! x^k,{k,0,Infinity}]
>
>   but for this to work for x = 0 we need 0^0 = 1.  The Exp[0]
>   argument that I mentioned previously is a special case.
>
> In each of these cases, the exponent is the integer 0.  The base may
> be
> real or complex.

All these are benefits only in respect of mathematical elegance. I
cant see any benefit in any of the above in respect of computing
performance - which is what counts in programs such as Mathematica.

Andrzej Kozlowski

```

• References:
• Prev by Date: Re: Re: Mathematica and LyX - Graphics and equations
• Next by Date: Re: Has anyone tried to use MathLink to receive real-time market
• Previous by thread: Re: 0^0 = 1?
• Next by thread: export to ps, transparency issue