Decimals and other numbers
Steven D'Aprano
steve+comp.lang.python at pearwood.info
Fri Jan 9 11:20:10 CET 2015
I think we're in violent agreement here, nevertheless I think you're right
for the wrong reasons. See below...
Devin Jeanpierre wrote:
> On Fri, Jan 9, 2015 at 12:49 AM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>> Devin Jeanpierre wrote:
>>
>>> On Thu, Jan 8, 2015 at 6:43 PM, Dave Angel <davea at davea.name> wrote:
>>>> What you don't say is which behavior you actually expected. Since 0**0
>>>> is undefined mathematically, I'd expect either an exception or a NAN
>>>> result.
>>>
>>> It can be undefined, if you choose for it to be. You can also choose
>>> to not define 0**1, of course.
>>
>> No you can't -- that would make arithmetic inconsistent. 0**1 is
>> perfectly well defined as 0 however you look at it:
>>
>> lim of x -> 0 of x**1 = 0
>> lim of y -> 1 of 0**y = 0
I should have used "x" for the variable in both expressions:
lim of x -> 0 of x**1 = 0
lim of x -> 1 of 0**x = 0
> This is a misunderstanding of limits. Limits are allowed to differ
> from the actual evaluated result when you substitute the limit point:
> that's what it means to be discontinuous.
That's true, if the function is discontinuous. But it's irrelevant here.
Neither x**1 nor 0**x are discontinuous, they're both continuous, and both
have the same limit for x->0 in the first place and x->1 in the second.
However you do it, 0**1 must be 0.
> What you call making arithmetic "inconsistent", I call making the
> function inside the limit discontinuous at 0.
I don't understand what you're trying to say here. You can't just
arbitrarily declare that 0**1 equals something other than 0 (or for that
matter, doesn't equal anything at all).
0**1 = (5-5)**1 = 5-5 = 0
If you want to say that 0**1 != 0, then you likewise have to say that
5-5 != 0, otherwise arithmetic is inconsistent.
Can we agree that 0**1 is well-defined and get back to 0**0?
>>> If 0**0 is defined, it must be 1. I
>>> Googled around to find a mathematician to back me up, here:
>>> http://arxiv.org/abs/math/9205211 (page 6, "ripples").
>>
>> Not quite. I agree that, *generally speaking* having 0**0 equal 1 is the
>> right answer, or at least *a* right answer, but not always. It depends on
>> how you get to 0**0...
>
> You don't "get to" a number. Those are limits. Limits and arithmetic
> are different.
>
> (Well, sort of. :)
Yes, sort of :-)
Of course you can "get to" numbers. We start with counting, that's a way
to "get to" the natural numbers, by applying the "successor" function
repeatedly until we reach the one we want. Or you can "get to" pi by
generating an infinite sequence of closer and closer approximations. Or an
infinite series. Or an infinite product. Or an infinite continued fraction.
All of these "ways to get to pi" converge on the same result.
If 0**0 has a value, we can give that number a name. Let's call it Q. There
are different ways to evaluate Q:
lim x -> 0 of sin(x)/x gives 1
lim x -> 0 of x**0 gives 1
lim x -> 0 of 0**x gives 0
0**0 = 0**(5-5) = 0**5 / 0**5 = 0/0 gives indeterminate
So we have a problem. Since all these "ways to get to Q" fail to converge,
the obvious answer is to declare that Q doesn't exist and that 0**0 is
indeterminate, and that is what many mathematicians do:
http://mathworld.wolfram.com/Indeterminate.html
However, this begs the question of what we mean by 0**0.
In the case of m**n, with both m and n positive integers, there is an
intuitively obvious definition for exponentiation: repeated multiplication.
But there's no obvious meaning for exponentiation when both m and n are
zero, hence we (meaning, mathematicians) have to define what it means. So
long as that definition doesn't lead to contradiction, we can make any
choice we like.
Hence some mathematicians decide that things like the Binomial Theorem are
far more important than 0**x, and so they define 0**0 as 1. They can
justify that definition, of course, it's not just arbitrary, but the
important thing is that mathematicians working in other fields can and do
sometimes use a slightly different definition, one where 0**0 is
indeterminate.
http://www.askamathematician.com/2010/12/q-what-does-00-zero-raised-to-the-zeroth-power-equal-why-do-mathematicians-and-high-school-teachers-disagree/
>> Since you can get difference results depending on the method you use to
>> calculate it, the "technically correct" result is that 0**0 is
>> indeterminate.
>
> No, only limits are indeterminate. Calculations not involving limits
> cannot be indeterminate.
Do tell me what 0/0 equals, if it is not indeterminate.
> -snip-
>> log(Q) = 0*-inf
>>
>> What is zero times infinity? In the real number system, that is
>> indeterminate, again because it depends on how you calculate it
>
> In the real number system, infinity does not exist. It only exists in
> limits or extended number systems.
Yes, you are technically correct, the best kind of correct.
I'm just sketching an informal proof. If you want to make it vigorous by
using limits, be my guest. It doesn't change the conclusion.
[...]
>> Arguably, *integer* 0**0 could be zero, on the basis that you can't take
>> limits of integer-valued quantities, and zero times itself zero times
>> surely has to be zero.
>
> No. No no no. On natural numbers no other thing makes sense than 1.
On the basis that m**n means m multiplied by itself n times:
5**4 = 5*5*5*5 = 625
that gives us:
0**0 = zero multiplied by itself zero times.
You can multiply 0 by any number you like, and the answer will always be 0,
not 1. Even if that other number is 0, the answer is still 0.
> All of the definitions of exponentiation for natural numbers require
> it, except for those derived from analytical notions of
> exponentiation. (Integers just give you ratios of natural
> exponentials, so again no.)
As I started this post, we are in agreement that for a programming language,
having float and decimal 0**0 give different results is rather strange, and
like you I would prefer the answer given to be 1. As far as I am
concerned, "Knuth says so" is enough justification :-)
--
Steven
More information about the Python-list
mailing list