Search All of the Math Forum:

Views expressed in these public forums are not endorsed by NCTM or The Math Forum.

Topic: The ambiguity of 0^0 on N
Replies: 106   Last Post: Sep 29, 2013 10:06 AM

 Messages: [ Previous | Next ]
 Rotwang Posts: 1,685 From: Swansea Registered: 7/26/06
Re: The ambiguity of 0^0 on N
Posted: Sep 19, 2013 12:46 PM

On 19/09/2013 16:33, Dan Christensen wrote:
> On Thursday, September 19, 2013 9:31:44 AM UTC-4, Rotwang wrote:
>> On 19/09/2013 06:23, Dan Christensen wrote:
>>> On Wednesday, September 18, 2013 7:11:53 PM UTC-4, Rotwang wrote:
>>>> On 18/09/2013 15:53, Dan Christensen wrote:
>>>>> [...]
>>>>
>>>>> Thus, if the Product of Powers Rule is to hold on N, 0^0 will be ambiguous -- being either 0 or 1. Unless one of these alternatives can be formally proven
>>>>
>>>> Obviously if you start of with a "definition" of ^ which leaves 0^0
>>>> undefined,

>>>
>>> Actually, I start with a definition which leaves out any explicit mention at all of exponents of 0 or 1. I define only exponents greater than 1. Starting with this definition, I prove that x^0 = 1 and x^1=x for x=/=0.

>>
>> But your definition leaves 0^0 undefined. So nothing can be proved about
>> it without an additional assumption.
>>

> Yes. That additional assumption is the extension of the Product of Power Rule to all of N. But even then, you are left with two possibilities: 0^0=1 or 0^0=0.

Yes, I know this already, in fact I said so in the next paragraph you
quoted below. Why do you keep telling people things they obviously

>>> I also proven that if you want to extend the Product of Powers Rule to all of N, then we must have 0^1=0 and either 0^0=0 or 0^0=1.
>>
>> Yes, I know. "If you want to extend the Product of Powers Rule to all of
>> N" is an additional assumption. But what I'd like to know is, what's so
>> special about the Product of Powers Rule? I mean, your "definition"
>> implies that x^0 = 1 for x != 0 - let's call this the Power of Zero
>> Rule. Why do you want to extend the Product of Powers Rule to all of N,
>> but not the Power of Zero rule?
>>

> You may be onto something here. If you don't want to make this extension -- the most conservative option, I suppose -- you also could not assign a value to 0^1.

Great. But why stop there? We could, for example, replace the definition
in your OP with, say, this:

(1) Ax in N: x^2=x*x

(2) Ax,y in N: x^(y + 2) = x^(y + 1)*x

AFAIK, that leaves not only 0^0 undefined, but it also leaves x^0
undefined for all x - it's even /more/ conservative! And that's good,
right? But you know what definition would be more conservative still?
Let ^ be any function. Better to play it safe, right? Just think of the
consequences that may arise from a calculation that results in a value
of something when it should result in something else. Software would be
so much more reliable if all functions would simply return NaN on every
input, because

...

No, I'm sorry. I can't even pretend to think that your argument makes
any sense.

>>> Until we are able to prove or disprove one of these alternatives, we should probably leave 0^0 undefined.
>>
>> Why? Note that I'm not asking you to repeat your argument that if one
>> defines ^ a certain way one finds that there are two different functions
>> why anyone should define ^ the way you do in your OP, rather than the
>> much simpler and more common way that it's usually defined, which has
>> the additional benefit that there is a unique function that satisfies
>> it, and that PPR can be derived from it, rather than just assumed.
>>

> It was much simpler to allow unrestricted comprehension for sets. But it eventually led to the now well-known contradictions (e.g Russell's Paradox).

OK. So I'll ask you once again: show me how the usual definition of 0^0

>>>> What negative consequences do you imagine
>>>> will follow from people defining exponentiation in the usual way?

>>>
>>> Whatever consequences may arise from a calculation that results in a value of 1 when it should be 0. The result could be catastrophic.

>>
>> But the consequences from a calculation that results in "undefined" when
>> it should be 1 could be similarly catastrophic.

>
> [snip]
>
> No more catastrophic than division by zero which is similarly undefined, and is treated by computers as an error condition.

I can't help but notice, Dan, that you once again failed to answer the
question I keep asking. Why do you imagine that the negative
consequences of 0^0 returning 1 when a programmer expects it to return
something else are more serious, or more likely, than the negative
consequences of 0^0 not returning 1 when a programmer expects it to do so?

Date Subject Author
9/18/13 Dan Christensen
9/18/13 Peter Percival
9/18/13 Dan Christensen
9/18/13 Peter Percival
9/18/13 Virgil
9/18/13 Dan Christensen
9/18/13 Rotwang
9/18/13 Rock Brentwood
9/18/13 Rotwang
9/19/13 Dan Christensen
9/19/13 Peter Percival
9/19/13 Dan Christensen
9/19/13 Peter Percival
9/19/13 Dan Christensen
9/19/13 fom
9/19/13 Dan Christensen
9/19/13 fom
9/19/13 Dan Christensen
9/20/13 fom
9/19/13 Virgil
9/19/13 Virgil
9/19/13 Rotwang
9/18/13 Virgil
9/18/13 fom
9/18/13 Rotwang
9/28/13 Shmuel (Seymour J.) Metz
9/29/13 Marshall
9/19/13 Dan Christensen
9/19/13 Dan Christensen
9/19/13 Peter Percival
9/19/13 Dan Christensen
9/19/13 Michael F. Stemper
9/19/13 Dan Christensen
9/19/13 Peter Percival
9/19/13 Dan Christensen
9/19/13 fom
9/19/13 Dan Christensen
9/19/13 fom
9/19/13 Dan Christensen
9/19/13 fom
9/19/13 Dan Christensen
9/20/13 fom
9/20/13 Dan Christensen
9/20/13 fom
9/19/13 fom
9/19/13 fom
9/19/13 Dan Christensen
9/19/13 fom
9/19/13 Peter Percival
9/19/13 Dan Christensen
9/19/13 fom
9/19/13 Rotwang
9/19/13 Dan Christensen
9/19/13 Helmut Richter
9/19/13 Dan Christensen
9/19/13 Peter Percival
9/19/13 Dan Christensen
9/19/13 Peter Percival
9/19/13 Dan Christensen
9/19/13 fom
9/19/13 fom
9/19/13 JT
9/19/13 JT
9/19/13 Michael F. Stemper
9/19/13 JT
9/19/13 JT
9/19/13 JT
9/19/13 Helmut Richter
9/28/13 Shmuel (Seymour J.) Metz
9/19/13 fom
9/19/13 Peter Percival
9/19/13 Dan Christensen
9/19/13 Peter Percival
9/19/13 Karl-Olav Nyberg
9/19/13 fom
9/19/13 fom
9/19/13 Rotwang
9/19/13 Dan Christensen
9/19/13 fom
9/25/13 Rotwang
9/26/13 Dan Christensen
9/27/13 Brian Q. Hutchings
9/19/13 fom
9/18/13 Rock Brentwood
9/19/13 Dan Christensen
9/19/13 Dan Christensen
9/19/13 Rotwang
9/19/13 Dan Christensen
9/19/13 fom
9/20/13 Dan Christensen
9/20/13 fom
9/20/13 Dan Christensen
9/20/13 Peter Percival
9/20/13 Peter Percival
9/20/13 Dan Christensen
9/20/13 Virgil
9/20/13 Peter Percival
9/20/13 fom
9/20/13 Michael F. Stemper
9/20/13 LudovicoVan
9/21/13 Michael F. Stemper
9/21/13 LudovicoVan
9/21/13 Richard Tobin
9/20/13 Peter Percival
9/20/13 Peter Percival
9/21/13 Dan Christensen
9/19/13 Karl-Olav Nyberg