
Re: The ambiguity of 0^0 on N
Posted:
Sep 19, 2013 4:30 PM


On Thursday, September 19, 2013 12:46:45 PM UTC4, Rotwang wrote: > On 19/09/2013 16:33, Dan Christensen wrote: > > > On Thursday, September 19, 2013 9:31:44 AM UTC4, Rotwang wrote: > > >> On 19/09/2013 06:23, Dan Christensen wrote: > > >>> On Wednesday, September 18, 2013 7:11:53 PM UTC4, 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 > > already know? >
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 > > leads to a contradiction (spoiler: it doesn't.) >
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.
This doesn't answer your question directly, but IIUC it should address your concern.
Dan Download my DC Proof 2.0 software at http://www.dcproof.com

