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 UTC4, 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 >> already know? > > Aren't we grumpy today!
My, what a clever response! Surely nobody will have noticed that it didn't answer my question.
>> [...] >> >> 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 answer the question I asked. Why do you keep telling me things I already know, instead of answering the questions I ask? It's almost as if you can't think of answers that don't completely undermine your point, so you try to deflect the questions by pretending I asked something else instead.
>> 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.
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 of 0^0 in six languages and posted about it in your threads? Hell, let's have a seventh:
phil@lamebot4000000000 ~ $ echo "#include <iostream> > #include <cmath> > int main() {std::cout << pow(0, 0) << \"\\n\";}" > zeropower.c++ phil@lamebot4000000000 ~ $ g++ zeropower.c++ phil@lamebot4000000000 ~ $ ./a.out 1
Huh. How about that.
> 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?

