Search All of the Math Forum:

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

Notice: We are no longer accepting new posts, but the forums will continue to be readable.

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

 Messages: [ Previous | Next ]
 Dan Christensen Posts: 8,219 Registered: 7/9/08
Re: The ambiguity of 0^0 on N
Posted: Sep 19, 2013 4:30 PM

On Thursday, September 19, 2013 12:46:45 PM UTC-4, Rotwang wrote:
> 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
>
>

Aren't we grumpy today!

>
>
>
>

> >>> 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.

Then again, maybe not.

> 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?

[snip]

I chose

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

so that the pattern could be worked backwards (even extended into the negative integer exponents) by successively dividing by the base value. But the pattern could not be worked backwards for a base of 0 since you can't divide by 0. That left only 0^0 and 0^1 undefined in N. Introduce the Product of Powers Rule (PPR) and 0^1 must be 0 and 0^0 either 0 or 1.

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

Again, the burden of proof is on those wanting to assign an actual value to 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?

Sorry, it was, ummmm... an oddly stated question.

Perhaps you haven't done much programming, but, in the case of division by zero, programmers routinely test for potential zero denominators and code alternative ways to proceed in that event. In the same way, I would recommend testing for potential 0^0 situations -- just to be safe.

Dan

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