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 25, 2013 5:47 PM

On 19/09/2013 21:30, Dan Christensen wrote:
> On Thursday, September 19, 2013 12:46:45 PM UTC-4, Rotwang wrote:
>> [...]
>>
>> 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!

My, what a clever response! Surely nobody will have noticed that it

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

Yes, I know. In fact I've said so multiple times. But That doesn't
you try to deflect the questions by pretending I asked something else

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

Proof of what? That defining 0^0 = 1 doesn't lead to a contradiction?
Sure, it's not hard to show that if, for example, ZFC is consistent,
then so is ZFC together with an additional constant symbol ^ and axioms
stating that that ^ is a function with domain the natural numbers which
satisfies the usual definition of exponentiation.

But since you're so keen to apply the burden of proof to others, I
wonder whether you'd be willing to apply it to yourself? In particular,
your OP says that exponentiation can be defined as a binary function on
the set of natural number N such that:

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

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

If this definition is to be used in your argument, then the burden of
proof is on you to show that it doesn't lead to a contradiction, right?
So go ahead and prove it.

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

What part don't you understand? Maybe I can help you out with some of
the longer words?

> Perhaps you haven't done much programming,

Haha, very funny. Perhaps you failed to notice that I checked the value
have a seventh:

phil@lamebot-4000000000 ~ \$ echo "#include <iostream>
> #include <cmath>
> int main() {std::cout << pow(0, 0) << \"\\n\";}" > zeropower.c++

phil@lamebot-4000000000 ~ \$ g++ zeropower.c++
phil@lamebot-4000000000 ~ \$ ./a.out
1

> but, in the case of division by zero, programmers routinely test for potential zero denominators and code alternative ways to proceed in that event.

Yes, I know.

> In the same way, I would recommend testing for potential 0^0 situations -- just to be safe.

But, see, this doesn't answer the question I asked. The question you
chose to answer is "how can the negative consequences of 0^0 returning
something other than the usual value be avoided?". But that's
irrelevant, because you presumably agree - or would do if you ever
answered inconvenient questions - that the alleged negative consequences
of 0^0 returning the usual value can be avoided just as easily. But the
question I asked was, "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?". It's a
different question. Would you care to answer it?

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