Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #83398 > unrolled thread
| Started by | Devin Jeanpierre <jeanpierreda@gmail.com> |
|---|---|
| First post | 2015-01-08 19:02 -0800 |
| Last post | 2015-01-09 19:57 -0800 |
| Articles | 20 on this page of 24 — 8 participants |
Back to article view | Back to comp.lang.python
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Decimals and other numbers Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-01-08 19:02 -0800
Re: Decimals and other numbers Marko Rauhamaa <marko@pacujo.net> - 2015-01-09 09:28 +0200
Re: Decimals and other numbers Chris Angelico <rosuav@gmail.com> - 2015-01-09 18:37 +1100
Re: Decimals and other numbers Marko Rauhamaa <marko@pacujo.net> - 2015-01-09 11:31 +0200
Re: Decimals and other numbers Dave Angel <davea@davea.name> - 2015-01-09 02:49 -0500
Re: Decimals and other numbers Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-01-09 00:51 -0800
Re: Decimals and other numbers Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2015-01-09 11:07 +0200
[OT] x**y == y**x Peter Pearson <pkpearson@nowhere.invalid> - 2015-01-09 17:46 +0000
Re: [OT] x**y == y**x Marko Rauhamaa <marko@pacujo.net> - 2015-01-09 23:41 +0200
Re: [OT] x**y == y**x Peter Pearson <pkpearson@nowhere.invalid> - 2015-01-10 16:57 +0000
Re: Decimals and other numbers Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-09 19:49 +1100
Re: Decimals and other numbers Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-01-09 00:58 -0800
Re: Decimals and other numbers Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-09 21:20 +1100
Re: Decimals and other numbers Chris Angelico <rosuav@gmail.com> - 2015-01-09 21:39 +1100
Re: Decimals and other numbers Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-09 23:24 +1100
Re: Decimals and other numbers Chris Angelico <rosuav@gmail.com> - 2015-01-09 23:34 +1100
Re: Decimals and other numbers Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-01-09 17:25 -0800
Re: Decimals and other numbers Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-10 16:08 +1300
Re: Decimals and other numbers Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-01-09 01:11 -0800
Re: Decimals and other numbers Marko Rauhamaa <marko@pacujo.net> - 2015-01-09 11:34 +0200
Re: Decimals and other numbers Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-09 22:03 +1100
Re: Decimals and other numbers Marko Rauhamaa <marko@pacujo.net> - 2015-01-09 11:44 +0200
Re: Decimals and other numbers Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-10 16:05 +1300
Re: Decimals and other numbers Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-01-09 19:57 -0800
Page 1 of 2 [1] 2 Next page →
| From | Devin Jeanpierre <jeanpierreda@gmail.com> |
|---|---|
| Date | 2015-01-08 19:02 -0800 |
| Subject | Re: Decimals and other numbers |
| Message-ID | <mailman.17501.1420772593.18130.python-list@python.org> |
On Thu, Jan 8, 2015 at 6:43 PM, Dave Angel <davea@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. 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"). I expected 1, nan, or an exception, but more importantly, I expected it to be the same for floats and decimals. BTW, Ben, you linked to a file on your hard drive. You meant https://docs.python.org/2/library/decimal.html#decimal.InvalidOperation -- Devin
[toc] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2015-01-09 09:28 +0200 |
| Message-ID | <87a91s1kh4.fsf@elektro.pacujo.net> |
| In reply to | #83398 |
Devin Jeanpierre <jeanpierreda@gmail.com>:
> If 0**0 is defined, it must be 1.
You can "justify" any value a within [0, 1]. For example, choose
y(a, x) = log(a, x)
Then,
lim y(a, x) = 0
x -> 0+
and:
lim[x -> 0+] x**y(a, x) = a
For example,
>>> a = 0.5
>>> x = 1e-100
>>> y = math.log(a, x)
>>> y
0.0030102999566398118
>>> x**y
0.5
Marko
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-01-09 18:37 +1100 |
| Message-ID | <mailman.17509.1420789074.18130.python-list@python.org> |
| In reply to | #83407 |
On Fri, Jan 9, 2015 at 6:28 PM, Marko Rauhamaa <marko@pacujo.net> wrote: > Devin Jeanpierre <jeanpierreda@gmail.com>: > >> If 0**0 is defined, it must be 1. > > You can "justify" any value a within [0, 1]. For example, choose > > y(a, x) = log(a, x) > > Then, > > lim y(a, x) = 0 > x -> 0+ > > and: > > lim[x -> 0+] x**y(a, x) = a > > For example, > > >>> a = 0.5 > >>> x = 1e-100 > >>> y = math.log(a, x) > >>> y > 0.0030102999566398118 > >>> x**y > 0.5 I'm not a mathematical expert, so I don't quite 'get' this. How does this justify 0**0 being equal to 0.5? I know how to justify 0 and 1, and NaN (on the basis that both 0 and 1 can be justified). I don't follow how other values can be used. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2015-01-09 11:31 +0200 |
| Message-ID | <87oaq8e1wi.fsf@elektro.pacujo.net> |
| In reply to | #83409 |
Chris Angelico <rosuav@gmail.com>:
> I'm not a mathematical expert, so I don't quite 'get' this. How does
> this justify 0**0 being equal to 0.5?
Many operations like this are defined in terms of some very strong
argument of uniqueness. Ultimately, the key point is safety in
mathematical deductions. One minimal requirement would be:
lim f(x, y)
(x, y) -> (0, 0)
must be defined (See <URL: http://en.wikipedia.org/wiki/Limit_of_a_func
tion#Functions_of_more_than_one_variable>).
If you get sloppy, there is a real risk of terrible logical mistakes and
wrong results. I think having 0**0 return a value is as irresponsible as
having 0/0 return a value.
(The very same principle is used to define 0+0 and 0*0 as well.)
Marko
[toc] | [prev] | [next] | [standalone]
| From | Dave Angel <davea@davea.name> |
|---|---|
| Date | 2015-01-09 02:49 -0500 |
| Message-ID | <mailman.17510.1420789780.18130.python-list@python.org> |
| In reply to | #83407 |
On 01/09/2015 02:37 AM, Chris Angelico wrote: > On Fri, Jan 9, 2015 at 6:28 PM, Marko Rauhamaa <marko@pacujo.net> wrote: >> Devin Jeanpierre <jeanpierreda@gmail.com>: >> >>> If 0**0 is defined, it must be 1. >> >> You can "justify" any value a within [0, 1]. For example, choose >> >> y(a, x) = log(a, x) >> >> Then, >> >> lim y(a, x) = 0 >> x -> 0+ >> >> and: >> >> lim[x -> 0+] x**y(a, x) = a >> >> For example, >> >> >>> a = 0.5 >> >>> x = 1e-100 >> >>> y = math.log(a, x) >> >>> y >> 0.0030102999566398118 >> >>> x**y >> 0.5 > > I'm not a mathematical expert, so I don't quite 'get' this. How does > this justify 0**0 being equal to 0.5? > > I know how to justify 0 and 1, and NaN (on the basis that both 0 and 1 > can be justified). I don't follow how other values can be used. Roughly speaking, the idea is to have a relationship between x and y, such that even though they each get arbitrarily close to zero, the formula x**y is a constant 5. So he plugged in 1e-100. But if you plugged in 1e-500000000 and could handle the precision, the result x**y would still be 0.5 -- DaveA
[toc] | [prev] | [next] | [standalone]
| From | Devin Jeanpierre <jeanpierreda@gmail.com> |
|---|---|
| Date | 2015-01-09 00:51 -0800 |
| Message-ID | <mailman.17512.1420793559.18130.python-list@python.org> |
| In reply to | #83407 |
Marko, your argument is "this function x**y(a, x) must be continuous on [0, inf), and to be continuous at 0, 0**0 must be a". Since there are many possible values of a, this is not a "justification", this is a proof by contradiction that the premise was faulty: x**y(a, x) doesn't have to be continuous after all. 0**0 is 1, which makes some functions continuous and some functions not, and who cares? It's 1 because that's what is demanded by combinatorial definitions of exponentiation, and its origins in the domain of the natural numbers. Knuth says that thought of combinatorially on the naturals, x**y counts the number of mappings from a set of x values to a set of y values. Clearly there's only one mapping from the empty set to itself: the empty mapping. Number theory demands that performing multiplication among an empty bag of numbers gives you the result of 1 -- even if the empty bag is an empty bag of zeroes instead of an empty bag of fives. The result does not change. Either of those ideas about exponentiation can be thought of as descriptions of its behavior, or as definitions. They completely describe its behavior on the naturals, from which we derive its behavior on the reals. -- Devin On Thu, Jan 8, 2015 at 11:28 PM, Marko Rauhamaa <marko@pacujo.net> wrote: > Devin Jeanpierre <jeanpierreda@gmail.com>: > >> If 0**0 is defined, it must be 1. > > You can "justify" any value a within [0, 1]. For example, choose > > y(a, x) = log(a, x) > > Then, > > lim y(a, x) = 0 > x -> 0+ > > and: > > lim[x -> 0+] x**y(a, x) = a > > For example, > > >>> a = 0.5 > >>> x = 1e-100 > >>> y = math.log(a, x) > >>> y > 0.0030102999566398118 > >>> x**y > 0.5 > > > Marko > -- > https://mail.python.org/mailman/listinfo/python-list
[toc] | [prev] | [next] | [standalone]
| From | Jussi Piitulainen <jpiitula@ling.helsinki.fi> |
|---|---|
| Date | 2015-01-09 11:07 +0200 |
| Message-ID | <qotr3v49va0.fsf@ruuvi.it.helsinki.fi> |
| In reply to | #83413 |
Devin Jeanpierre writes: [...] > domain of the natural numbers. Knuth says that thought of > combinatorially on the naturals, x**y counts the number of mappings > from a set of x values to a set of y values. It's the other way around, of course: from a set of y values to a set of x values. Which reminds me of a question that once made me smile, even laugh, and still does: 2**3 is almost 3**2 but not quite - what gives? > Clearly there's only one mapping from the empty set to itself: the [...]
[toc] | [prev] | [next] | [standalone]
| From | Peter Pearson <pkpearson@nowhere.invalid> |
|---|---|
| Date | 2015-01-09 17:46 +0000 |
| Subject | [OT] x**y == y**x |
| Message-ID | <chaierFt612U1@mid.individual.net> |
| In reply to | #83416 |
On 09 Jan 2015 11:07:51 +0200, Jussi Piitulainen wrote: [snip] > Which reminds me of a question that once made me smile, even laugh, > and still does: 2**3 is almost 3**2 but not quite - what gives? If you've never looked at the set of reals (x,y) satisfying x**y == y**x, it's worth a visit. -- To email me, substitute nowhere->runbox, invalid->com.
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2015-01-09 23:41 +0200 |
| Subject | Re: [OT] x**y == y**x |
| Message-ID | <87wq4vfx8k.fsf@elektro.pacujo.net> |
| In reply to | #83460 |
Peter Pearson <pkpearson@nowhere.invalid>:
> If you've never looked at the set of reals (x,y) satisfying x**y ==
> y**x, it's worth a visit.
Thanks, it was. The graph's something like this:
| : *
| : *
| : *
| : *
6 + : * *
| : * **
| : * **
| : * **
| : * **
5 + : * **
| : * **
| : * **
| : * **
| : * **
4 + : * **
| : * **
| : * **
| : * **
| : * **
3 + : * **
| : * **
| : ***
| : ** *****
| : ** ***
2 + : ** *********
| : ** **
| : ** *******
| : ** ******
| : **
1 +.........**.................................................
| **:
| ** :
| ** :
| ** :
+*--------+---------+---------+---------+---------+---------+
1 2 3 4 5 6
where the line and the arc intersect at (e, e).
Where can I read more on the topic?
Marko
[toc] | [prev] | [next] | [standalone]
| From | Peter Pearson <pkpearson@nowhere.invalid> |
|---|---|
| Date | 2015-01-10 16:57 +0000 |
| Subject | Re: [OT] x**y == y**x |
| Message-ID | <chd3vaFip6hU1@mid.individual.net> |
| In reply to | #83468 |
On Fri, 09 Jan 2015 23:41:15 +0200, Marko Rauhamaa <marko@pacujo.net> wrote: > Peter Pearson <pkpearson@nowhere.invalid>: > >> If you've never looked at the set of reals (x,y) satisfying x**y == >> y**x, it's worth a visit. > > Thanks, it was. The graph's something like this: [snip] > > Where can I read more on the topic? Sorry, I don't know. One Phil Rust steered me to this problem in high school (c. 1964), and I never got much traction on it until Prof. Alfred Roch at EPFL pointed out (c. 1981) that it's revealing to think of horizontal lines intersecting the graph of ln(x)/x. If you like this sort of thing, here's another cute function that the same Phil Rust called to my attention: http://webpages.charter.net/curryfans/peter/XtoTheXtoTheX/ode_to_e.html -- To email me, substitute nowhere->runbox, invalid->com.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-01-09 19:49 +1100 |
| Message-ID | <54af9612$0$12995$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #83398 |
Devin Jeanpierre wrote:
> On Thu, Jan 8, 2015 at 6:43 PM, Dave Angel <davea@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
> 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...
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. But that's not terribly useful, and mathematicians with a
pragmatic bent (i.e. most of them) define 0**0 == 1 on the basis that it is
justifiable and useful, while 0**0 = 0 is justifiable but not useful and
leaving it as indeterminate is just a pain.
One argument comes from taking limits of x**y. If you set x to zero, and
take the limit as y approaches 1, you get:
lim of y -> 0 of 0**y = 0
But if you set y to 0, and take the limit as x approaches 0, you get:
lim of x -> 0 of x**0 = 1
There is a discontinuity in the graph of x**y, and no matter what value you
define 0**0 as, you cannot get rid of that discontinuity. Hence
indeterminate.
Here's another argument for keeping it indeterminate. Suppose we let 0**0 =
some value Q. Let's take the logarithm of Q.
log(Q) = log (0**0)
But log (a**b) = b*log(a), so:
log(Q) = 0*log(0)
What's log(0)? If we take the limit from above, we get log(x) -> -infinity.
If we take the limit from below, we get a complex infinity, so let's ignore
the limit from below and informally write:
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: naively it
sounds like it should be 0, but infinity is pretty big and if you add up
enough zeroes in the right way you can actually get something non-zero.
There's no one right answer. So if the log of Q is indeterminate, then so
must be Q.
But there are a host of good reasons for preferring 0**0 = 1. Donald Knuth
writes (using ^ for power):
Some textbooks leave the quantity 0^0 undefined, because the
functions 0^x and x^0 have different limiting values when x
decreases to 0. But this is a mistake. We must define x^0=1
for all x , if the binomial theorem is to be valid when x=0,
y=0, and/or x=-y. The theorem is too important to be arbitrarily
restricted! By contrast, the function 0^x is quite unimportant.
More discussion here:
http://mathforum.org/dr.math/faq/faq.0.to.0.power.html
> I expected 1, nan, or an exception, but more importantly, I expected
> it to be the same for floats and decimals.
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.
But in practice, I agree that 0**0 should give the same result regardless of
the type of zeroes used, and if the result is a number rather than a NAN or
an exception, it should be 1.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Devin Jeanpierre <jeanpierreda@gmail.com> |
|---|---|
| Date | 2015-01-09 00:58 -0800 |
| Message-ID | <mailman.17513.1420793970.18130.python-list@python.org> |
| In reply to | #83412 |
On Fri, Jan 9, 2015 at 12:49 AM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > Devin Jeanpierre wrote: > >> On Thu, Jan 8, 2015 at 6:43 PM, Dave Angel <davea@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 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. What you call making arithmetic "inconsistent", I call making the function inside the limit discontinuous at 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. :) > 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. -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. > : naively it > sounds like it should be 0, but infinity is pretty big and if you add up > enough zeroes in the right way you can actually get something non-zero. > There's no one right answer. So if the log of Q is indeterminate, then so > must be Q. > > But there are a host of good reasons for preferring 0**0 = 1. Donald Knuth > writes (using ^ for power): > > Some textbooks leave the quantity 0^0 undefined, because the > functions 0^x and x^0 have different limiting values when x > decreases to 0. But this is a mistake. We must define x^0=1 > for all x , if the binomial theorem is to be valid when x=0, > y=0, and/or x=-y. The theorem is too important to be arbitrarily > restricted! By contrast, the function 0^x is quite unimportant. > > More discussion here: > > http://mathforum.org/dr.math/faq/faq.0.to.0.power.html I've already been citing Knuth. :P >> I expected 1, nan, or an exception, but more importantly, I expected >> it to be the same for floats and decimals. > > 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. 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.) -- Devin
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-01-09 21:20 +1100 |
| Message-ID | <54afab5d$0$12976$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #83414 |
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@pearwood.info> wrote: >> Devin Jeanpierre wrote: >> >>> On Thu, Jan 8, 2015 at 6:43 PM, Dave Angel <davea@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
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-01-09 21:39 +1100 |
| Message-ID | <mailman.17516.1420799984.18130.python-list@python.org> |
| In reply to | #83422 |
On Fri, Jan 9, 2015 at 9:20 PM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > 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. 5 * 0 * 0 * 0 * 0 = 0 You can multiply 5 by 0 any number of times you like, and the answer will always be 0... unless you never multiply it by 0 at all, in which case it'll be 5. Multiplying 0 by any number, including 0, is 0... but *not* multiplying 0 by 0 doesn't have to give 0. 0**0 is the result of not multiplying any zeroes together, so it doesn't follow the rules of multiplying zeroes together. Look at it another way. 6**x modulo 10 will always be 6, right? 6, 36, 216... the rules for multiplying mean that the last digit will be consistent. (That's how we can know what the last digits of Graham's Number are, despite having no way to even comprehend its scale.) So what's 6**0? Is that going to end with 6, too, to be consistent? No, because we're not multiplying any sixes in, so the answer's simply 1. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-01-09 23:24 +1100 |
| Message-ID | <54afc884$0$12985$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #83423 |
I want to emphasis that I'm not really arguing that 0**0 should evaluate as 0. That's probably the least useful thing we can have out of the four possibilities: - return 1 - return NAN - raise an exception - return 0 But in the spirit of the Devil's Advocate, I mentioned that there was an argument to be made for having integer 0**0 return 0. Intuitively, we have: 0**5 = 0 0**4 = 0 0**3 = 0 0**2 = 0 0**1 = 0 0**0 = ? It's not hard to see that 0**n = 0 for every n except 0, so why make an exception for 0? I stress that there are *better* arguments for making that exception and having 0**0 defined as 1. My argument is merely that there is *an argument* for having 0**0 return 0. I could put it this way: If you start with nothing and raise it to the power of nothing, then there is nothing to exponentiate and you're left with nothing. More below. Chris Angelico wrote: > On Fri, Jan 9, 2015 at 9:20 PM, Steven D'Aprano > <steve+comp.lang.python@pearwood.info> wrote: >> 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. > > 5 * 0 * 0 * 0 * 0 = 0 Where did the 5 come from? You're effectively saying that 0**0 becomes 5*0**0, then cancelling the 0**0 because they're all zeroes and so don't matter, leaving 5. And that simply doesn't work. If it did work, there's nothing special about 5, we could use 18 instead: 0**0 = 5*0**0 => 5 but 0**0 = 18*0**0 => 18 therefore 5 = 18. Yay maths! :-) > You can multiply 5 by 0 any number of times you like, and the answer > will always be 0... unless you never multiply it by 0 at all, in which > case it'll be 5. Multiplying 0 by any number, including 0, is 0... but > *not* multiplying 0 by 0 doesn't have to give 0. 0**0 is the result of > not multiplying any zeroes together, so it doesn't follow the rules of > multiplying zeroes together. If you want to be vigorous, we're both talking nonsense. Exponentiation in terms of repeated multiplication only works for non-zero powers. Talking about "multiplication by itself zero times" raises the question "what the hell do you mean by multiplication by itself zero times?" There are ways to make this vigorous. The problem is, with 0**0, you get a different answer depending on how you make it vigorous. Hence 0**0 is indeterminate. > Look at it another way. 6**x modulo 10 will always be 6, right? 6, 36, > 216... the rules for multiplying mean that the last digit will be > consistent. (That's how we can know what the last digits of Graham's > Number are, despite having no way to even comprehend its scale.) Oh, after going through some of the discussions on Python-ideas, I'm pretty sure I comprehend its scale... > So > what's 6**0? Is that going to end with 6, too, to be consistent? No, > because we're not multiplying any sixes in, so the answer's simply 1. Why 1? Why not 3? Or 0? The answer is, it needs to be 1 to be consistent with the Index Laws such as a**(b-c) = a**b / a**c. That's a good answer, and it works great for a=6: 6**0 = 6**(2-2) = 6**2 / 6**2 = 36/36 = 1 (There's nothing special about 2, I could have used 0 = 97-97, or any other positive value.) But it doesn't work when the base is zero: 0**0 = 0**(2-2) = 0**2 / 0**2 = 0/0 = ???? Oops. There's that pesky indeterminate result again. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-01-09 23:34 +1100 |
| Message-ID | <mailman.17523.1420806865.18130.python-list@python.org> |
| In reply to | #83432 |
On Fri, Jan 9, 2015 at 11:24 PM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: >> 5 * 0 * 0 * 0 * 0 = 0 > > Where did the 5 come from? > > You're effectively saying that 0**0 becomes 5*0**0, then cancelling the 0**0 > because they're all zeroes and so don't matter, leaving 5. And that simply > doesn't work. If it did work, there's nothing special about 5, we could use > 18 instead: > > 0**0 = 5*0**0 => 5 > > but 0**0 = 18*0**0 => 18 > therefore 5 = 18. > > Yay maths! :-) To clarify, I'm following this sequence: 5 * 0**4 = 5 * 0 * 0 * 0 * 0 = 0 5 * 0**3 = 5 * 0 * 0 * 0 = 0 5 * 0**2 = 5 * 0 * 0 = 0 5 * 0**1 = 5 * 0 = 0 5 * 0**0 = 5 = ? Multiplication by zero is idempotent; any number of multiplications beyond the first won't change the result. But that doesn't mean that never multiplying by zero will have the same result. I think it's fairly obvious in this example that the pattern does NOT continue to the case where you're multiplying in no zeroes. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Devin Jeanpierre <jeanpierreda@gmail.com> |
|---|---|
| Date | 2015-01-09 17:25 -0800 |
| Message-ID | <mailman.17548.1420853187.18130.python-list@python.org> |
| In reply to | #83422 |
On Fri, Jan 9, 2015 at 2:20 AM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: -snip- > 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). You can, actually. It's just silly. (Similarly, you can declare that 0**0 is something other than 1 (or for that matter, doesn't equal anything at all), but it's silly.) > Can we agree that 0**1 is well-defined and get back to 0**0? Believe it or not I actually misread your whole thing and thought we were talking about 0**0. Otherwise I would've been much briefer... >>> 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 :-) I was alluding to the definition of the reals. > 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. Yes, all numbers can be represented as a converging limit. However, that does not mean that the way you compute the result of a function like x**y is by taking the limit as its arguments approach the input: that procedure works only for continuous functions. x**y is not continuous at 0, so this style of computation cannot give you an answer. > 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 This is a proof that f(x, y) = x**y is not continuous around 0, 0. It is not a proof that it is undefined at 0, 0, in fact, it says nothing about the value. > 0**0 = 0**(5-5) = 0**5 / 0**5 = 0/0 gives indeterminate Here is a nearly identical "proof" that 0**1 is "indeterminate": 0 = 0**1 = 0**(5 - 4) = 0**5 / 0**4 = 0/0 gives indeterminate. The fact that you can construct a nonsensical expression from an expression doesn't mean the original expression was nonsensical. In this case, your proof was invalid, because 0**(X-Y) is not equivalent to 0**X/0**Y. > 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: That isn't what "indeterminate" means. > 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. Sorry, I don't follow. n**0 as repeated multiplication makes perfect sense: we don't perform any multiplications, but if we did, we'd be multiplying 'n's. 0**m as repeated multiplication makes perfect sense: whatever we multiply, it's a bunch of 0s. Why doesn't 0**0 make sense? We don't perform any multiplications, but if we did, we'd be multiplying 0s. If we don't perform any multiplications, the things we didn't multiply don't matter. Whether they are fives, sevens, or zeroes, the answer is the same: 1. >>> 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. 0/0 is undefined, it isn't "indeterminate". Indeterminate forms are a way of expressing limits where you have performed a lossy substitution. That is: "the limit as x approaches a of 0/0" is an indeterminate form. >> 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. No, the point is that limits are irrelevant. As has been proven countlessly many times, x**y is not continuous around the origin. This has no bearing on whether it takes a value at the origin. > > [...] >>> 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. If you are performing no multiplications, you never multiplied 0 by any number at all, so what you get from 0*X is irrelevant. -- Devin
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2015-01-10 16:08 +1300 |
| Message-ID | <chbjd6F76b8U2@mid.individual.net> |
| In reply to | #83422 |
Steven D'Aprano wrote:
> I'm just sketching an informal proof. If you want to make it vigorous
^^^^^^^^
I think the usual term is "rigorous", unless the mathematician
is taking some kind of stimulant... :-)
--
Greg
[toc] | [prev] | [next] | [standalone]
| From | Devin Jeanpierre <jeanpierreda@gmail.com> |
|---|---|
| Date | 2015-01-09 01:11 -0800 |
| Message-ID | <mailman.17515.1420795186.18130.python-list@python.org> |
| In reply to | #83412 |
On Fri, Jan 9, 2015 at 12:58 AM, Devin Jeanpierre <jeanpierreda@gmail.com> wrote: >> 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. I should have responded in more detail here, sorry. If you aren't performing any multiplication, why does it matter what numbers you are "multiplying"? Doing no multiplications of five is the same as doing no multiplications of two is the same as doing no multiplications of... 0. You can define it to be 0 but only if you are multiplying an empty bag of zeroes, but it's hard to imagine what makes an empty bag of zeroes different from an empty bag of fives. It really surely is *not* the case. Obviously, this kind of ridiculousness comes naturally to Java and C++ programmers, with their statically typed collections. It's no surprise that's where the Decimal spec came from. ;) -- Devin
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2015-01-09 11:34 +0200 |
| Message-ID | <87k30we1rp.fsf@elektro.pacujo.net> |
| In reply to | #83412 |
Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
> mathematicians with a pragmatic bent
You shouldn't call engineers and scientists mathematicians ("with a
pragmatic bent"). Rigor is an absolute requirement for any mathematics.
Marko
[toc] | [prev] | [next] | [standalone]
Page 1 of 2 [1] 2 Next page →
Back to top | Article view | comp.lang.python
csiph-web