MathGroup Archive 2009

[Date Index] [Thread Index] [Author Index]

Search the Archive

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