[Date Index]
[Thread Index]
[Author Index]
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
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**
| |