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 already know?
>>> 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 >> that satisfy that definition; everybody already knows that. I'm asking >> 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 leads to a contradiction (spoiler: it doesn't.)
>>>> 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?