Mathematics in Python are not correct
wxPyt...@gmail.com
>>> -123**0
-1
The result is not correct, because every number (positive or negative)
raised to the power of 0 is ALWAYS 1 (a positive number 1 that is).
The problem is that Python parses -123**0 as -(123**0), not as
(-123)**0.
I suggest making the Python parser omit the negative sign if a
negative number is raised to the power of 0. That way the result will
always be a positive 1, which is the mathematically correct result.
This is a rare case when the parser is fooled, but it must be fixed in
order to produce the correct mathematical result.
Michael Torrie
> Have a look at this:
>
>>>> -123**0
> -1
>
>
> The result is not correct, because every number (positive or negative)
> raised to the power of 0 is ALWAYS 1 (a positive number 1 that is).
No python is correct. you're expression parses this way, when converted
to a lisp-ish prefix expression:
(- (123 ** 0 ))
All calculators work this way, so I don't know why you are expecting
anything otherwise.
>
> The problem is that Python parses -123**0 as -(123**0), not as
> (-123)**0.
>
> I suggest making the Python parser omit the negative sign if a
> negative number is raised to the power of 0. That way the result will
> always be a positive 1, which is the mathematically correct result.
>
> This is a rare case when the parser is fooled, but it must be fixed in
> order to produce the correct mathematical result.
Michael Torrie
(negate (pow 123 0))
Using parenthesis to indicate precedence order of ops:
-(123 ^ 0)
The "-" you are using is not part of the number. It's a unary operator
that negates something. In normal order of operations, it has a much
lower priority than power.
Your post really took me back to my grade school days! I remember first
looking with consternation at my scientific calculator when it insisted
that -2^0 is -1.
The order of python operations can be found here:
http://docs.python.org/ref/summary.html
Hope this helps
Luis Zarrabeitia
> The problem is that Python parses -123**0 as -(123**0), not as
> (-123)**0.
Actually, I've always written it as (-123)**0. At least where I'm from,
exponentiation takes precedence even over unary "-". (to get a power of -123,
you must write $(-123)^0$ [latex])
Though not an authoritative source, wikipedia also uses the (-x)^y notation:
http://en.wikipedia.org/wiki/Exponentiation#Powers_of_minus_one
Btw, there seems to be a math problem in python with exponentiation...
>>> 0**0
1
That 0^0 should be a nan or exception, I guess, but not 1.
[just found out while trying the poster's example]
--
Luis Zarrabeitia (aka Kyrie)
Fac. de Matemática y Computación, UH.
http://profesores.matcom.uh.cu/~kyrie
Ben Finney
> The problem is that Python parses -123**0 as -(123**0), not as
> (-123)**0.
As explicitly defined in the language reference, the "negative"
operator has lower binding precedence than the "power" operator
<URL:http://www.python.org/doc/ref/summary.html>.
> I suggest making the Python parser omit the negative sign if a
> negative number is raised to the power of 0.
It does, if you actually have a negative number that you're raising to
power 0.
>>> (-123)**0
1
> This is a rare case when the parser is fooled
The parser is operating according to the documented language
specification. It can't account for the user being fooled by external
sources.
--
\ "You know what I hate? Indian givers... no, I take that back." |
`\ -- Emo Philips |
_o__) |
Ben Finney
Nicolas Dandrimont
> Have a look at this:
>
> >>> -123**0
> -1
>
>
> The result is not correct, because every number (positive or negative)
> raised to the power of 0 is ALWAYS 1 (a positive number 1 that is).
>
> The problem is that Python parses -123**0 as -(123**0), not as
> (-123)**0.
>
And why is this a problem ? It is the "standard" operator precedence
that -123^0 is -(123^0), isn't it ?
> I suggest making the Python parser omit the negative sign if a
> negative number is raised to the power of 0. That way the result will
> always be a positive 1, which is the mathematically correct result.
>
That's what it does :
>>> -123**0
-1
>>> (-123)**0
1
> This is a rare case when the parser is fooled, but it must be fixed in
> order to produce the correct mathematical result.
Again, the mathematical result is correct. -123^0 is -(123^0), not
(-123)^0.
Regards,
--
Nicolas Dandrimont
casti...@gmail.com
wrote:
> * wxPytho...@gmail.com <wxPytho...@gmail.com> [2008-05-08 15:54:42 -0700]:
> 1KDownload
Signs include power.
>>> -2**0
-1
>>> (-2)**0
1
>>> -(2**0)
-1
+x, -x Positive, negative
~x Bitwise not
** Exponentiation
from Help;
However:
>>> 2+3**1
5
>>> 2+3**2
11
So, the order of precedence table has not listed the identical order
of operations with the implementation.
I have hit parentheses in rolling too.
In terms of money, processor-based operations may not be equals.
Clock cycles cost fractions of time. But, I don't see x= -x in realty.
Christian Heimes
>>>> 0**0
> 1
>
> That 0^0 should be a nan or exception, I guess, but not 1.
No, that's correct for floats. Read the wikipedia article or the C99
standard for more information.
Christian
Terry Reedy
"Luis Zarrabeitia" <ky...@uh.cu> wrote in message
news:200805081914...@uh.cu...
| Btw, there seems to be a math problem in python with exponentiation...
| 1
| That 0^0 should be a nan or exception, I guess, but not 1.
a**b is 1 multiplied by a, b times. 1 multiplied by 0 no times is 1.
But there are unenlighted people who agree with you ;-)
Wikipedia has a discussion of this.
tjr
Erik Max Francis
Others have pointed out why this is not a parse error, as it's parsed as
-(123**0), not (-123)**0, which is apparently what you meant.
Note, however, that even normal mathematical conventions follow this
same rule. If you were to write
2
-x
as part of a mathematical equation, this means (translated to Python)
-(x**2), not (-x)**2.
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis
I sleep and dream that life is / All beauty
-- Lamya
Dan Bishop
> On Thursday 08 May 2008 06:54:42 pm wxPytho...@gmail.com wrote:
>
> > The problem is that Python parses -123**0 as -(123**0), not as
> > (-123)**0.
>
> Actually, I've always written it as (-123)**0. At least where I'm from,
> exponentiation takes precedence even over unary "-". (to get a power of -123,
> you must write $(-123)^0$ [latex])
FWIW, my TI-89 evaluates it as -1.
> Though not an authoritative source, wikipedia also uses the (-x)^y notation:http://en.wikipedia.org/wiki/Exponentiation#Powers_of_minus_one
>
> Btw, there seems to be a math problem in python with exponentiation...
>
> >>> 0**0
>
> 1
>
> That 0^0 should be a nan or exception, I guess, but not 1.
>
> [just found out while trying the poster's example]
Technically correct, but 0**0 == 1 is actually pretty useful. For one
thing, it lets you create a Vandermonde matrix without making 0 a
special case.
Luis Zarrabeitia
Quoting Christian Heimes <li...@cheimes.de>:
> Luis Zarrabeitia schrieb:
> >>>> 0**0
> > 1
> >
> > That 0^0 should be a nan or exception, I guess, but not 1.
>
> No, that's correct for floats. Read the wikipedia article or the C99
> standard for more information.
Weird, I can't find neither... (which wikipedia article? Couldn't find one about
C99.)
Don't take me wrong, I believe you... but I would really want to see the logic
behind that. I pretty much like the NaNs and Infs (and don't really understand
why python raises float division errors instead of them), but to have errors
pass with absolute silence seems dangerous even if it is useful sometimes
(Vandermonde example). I think I'd rather have python returning NaNs and
violating C99 on the 0**0=1, than to have 0**0=1 and not return NaNs.
--
Luis Zarrabeitia
Facultad de Matemática y Computación, UH
http://profesores.matcom.uh.cu/~kyrie
--
"Al mundo nuevo corresponde la Universidad nueva"
UNIVERSIDAD DE LA HABANA
280 aniversario
Ian Kelly
> Weird, I can't find neither... (which wikipedia article? Couldn't find one about
> C99.)
Try http://en.wikipedia.org/wiki/Exponentiation#Zero_to_the_zero_power
Mensanator
So it IS correct.
Luis Zarrabeitia
> On Thu, May 8, 2008 at 10:15 PM, Luis Zarrabeitia <ky...@uh.cu> wrote:
> > Weird, I can't find neither... (which wikipedia article? Couldn't find one
> about
> > C99.)
>
> Try http://en.wikipedia.org/wiki/Exponentiation#Zero_to_the_zero_power
Thanks!
Interesting reasoning... both ways ("undefined" for real exponents, 1 for
combinatory/set-theory). It would be way too confusing to have 0**0=1 and 0**0.0
undefined, so I guess is best to follow convention.
[now, I would really like to see 0/0=nan...]
Arnaud Delobelle
If we want Binomial expansion to work sanely, we need 0^0 = 1, e.g:
(x+0)^2 = 1*x^2*0^0 + 2*x*0 + 1*x^0*0^2
= x^2
Therefore 0^0 = 1
Also, x^y (for x, y natural numbers) can be defined as the number of
functions from Y to X where |X|=x and |Y|=y. As there is exactly one
function from the empty set to the empty set, 0^0 = 1.
The arguments for making 0^0 = 0 are weak, it is a bit more convincing
to want it to be undefined (as (0,0) is a point of discontinuity of
(x,y) -> x^y).
--
Arnaud
Lou Pecora
Michael Torrie <tor...@gmail.com> wrote:
> wxPyt...@gmail.com wrote:
> > Have a look at this:
> >
> >>>> -123**0
> > -1
> >
> >
> > The result is not correct, because every number (positive or negative)
> > raised to the power of 0 is ALWAYS 1 (a positive number 1 that is).
>
> No python is correct. you're expression parses this way, when converted
> to a lisp-ish prefix expression:
>
> (- (123 ** 0 ))
Yeah, it's just the standard parser. For other situations Python does
fine. E.g.
In [1]: x=-1
In [2]: x**0
Out[2]: 1
--
-- Lou Pecora
Lou Pecora
"Terry Reedy" <tjr...@udel.edu> wrote:
I like that argument better. But...
I've also heard the very similar a**b is a multiplied by a b-1 times.
That gives 0**0=0*(1/0). Uh, Oh! If you want consistency with the
treatment of exponents that might cause problems. Tough situation when
you have a "discontinuity" at 0 for x^x.
--
-- Lou Pecora
Terry Reedy
"Lou Pecora" <pec...@anvil.nrl.navy.mil> wrote in message
news:pecora-DFE713....@ra.nrl.navy.mil...
| In article <mailman.825.12102935...@python.org>,
| "Terry Reedy" <tjr...@udel.edu> wrote:
|
| > "Luis Zarrabeitia" <ky...@uh.cu> wrote in message
| > news:200805081914...@uh.cu...
| > | Btw, there seems to be a math problem in python with
exponentiation...
| > | >>> 0**0
| > | 1
| > | That 0^0 should be a nan or exception, I guess, but not 1.
| >
| > a**b is 1 multiplied by a, b times. 1 multiplied by 0 no times is 1.
| > But there are unenlighted people who agree with you ;-)
| > Wikipedia has a discussion of this.
| >
| > tjr
|
| I like that argument better. But...
|
| I've also heard the very similar a**b is a multiplied by a b-1 times.
Me too, in school, but *that* definition is incomplete: it excludes b=0 and
hence a**0 for all a. It was the best people could do before 0 was known.
But 0 was introduced to Europe just over 800 years ago ;-)
In general, sequence reduction work better if the base case is given
separately rather that defined as the first member of the sequence (which
excludes empty sequences!).
ab = [a]*b # b a count
a**b = reduce(int.__mul__, ab, 1) # better
a**b = reduce(int.__mul__, ab[1:], a) # crashes for b=0
Consider the equivalent pair of definitions for a*b:
a*b = 0 incremented by a, b times = reduce(int.__add__, ab, 0)
a*b = a incremented by a, b-1 times = reduce(int.__add__, ab[1:] a)
Since we have 0, the second, which excludes (crashes on) a*0 ,
is incomplete.
Terry Jan Reedy
Lou Pecora
"Terry Reedy" <tjr...@udel.edu> wrote:
> "Lou Pecora" <pec...@anvil.nrl.navy.mil> wrote in message
> news:pecora-DFE713....@ra.nrl.navy.mil...
> | In article <mailman.825.12102935...@python.org>,
> | "Terry Reedy" <tjr...@udel.edu> wrote:
> |
> | > "Luis Zarrabeitia" <ky...@uh.cu> wrote in message
> | > news:200805081914...@uh.cu...
> | > | Btw, there seems to be a math problem in python with
> exponentiation...
> | > | >>> 0**0
> | > | 1
> | > | That 0^0 should be a nan or exception, I guess, but not 1.
> | >
> | > a**b is 1 multiplied by a, b times. 1 multiplied by 0 no times is 1.
> | > But there are unenlighted people who agree with you ;-)
> | > Wikipedia has a discussion of this.
> | >
> | > tjr
> |
> | I like that argument better. But...
> |
> | I've also heard the very similar a**b is a multiplied by a b-1 times.
>
> Me too, in school, but *that* definition is incomplete: it excludes b=0 and
> hence a**0 for all a. It was the best people could do before 0 was known.
> But 0 was introduced to Europe just over 800 years ago ;-)
[cut some interesting examples]
Yes, I was also thinking about the b=0 case and then the case when b<0.
If you solve the b<0 case, you solve the b=0 case for a !=0. Define
a**b= a multiplied by 1/a |b-1| times when b<0. Then for b=0 we get
a*(1/a)=1.
Of course, I can avoid all this mathematical dancing around by using
some of the other simpler definitions like the original one. :-)
--
-- Lou Pecora
wxPyt...@gmail.com
mathematical clash of a sort. :) You guys really blew me away wih
your mathematical knowledge. And also the 0**0 is a thing I've never
thought about trying, until now that is. If the mathematical rule is
that EVERYTHING raised to the power of 0 is 1, then we should accept
that, even in the case of 0**0. This is just the way it is.
I have two another interesting things to discuss about, for which I'll
open new posts on this group. Look for "Python doesn't recognize quote
types" and "Python, are you ill?".
Terry Reedy
<wxPyt...@gmail.com> wrote in message
news:f6743b81-9324-46dd...@d77g2000hsb.googlegroups.com...
|I am stunned that this simple misunderstanding of mine ended in a
| mathematical clash of a sort. :) You guys really blew me away wih
| your mathematical knowledge. And also the 0**0 is a thing I've never
| thought about trying, until now that is.
Anyone who defines a function should think about 'edge' and 'corner' cases.
Recursive definitions often help, since such cases are typically the base
cases.
When learning a (computer) function, I often test such cases since they are
a common place to mess up.
tjr
Paddy
> I have two another interesting things to discuss about, for which I'll
> open new posts on this group. Look for "Python doesn't recognize quote
> types" and "Python, are you ill?".
Hi,
You might try making your titles a little more descriptive to help
people filter/search on them.
- Paddy.
Max M
> I have two another interesting things to discuss about, for which I'll
> open new posts on this group. Look for "Python doesn't recognize quote
> types" and "Python, are you ill?".
You have a tendency to form your questions as complaints about Python
being broken.
You will probably get better responses if you just state that there are
things you do not understand, and ask why it works that way.
--
hilsen/regards Max M, Denmark
http://www.mxm.dk/
IT's Mad Science
Grant Edwards
> wxPyt...@gmail.com skrev:
>
>> I have two another interesting things to discuss about, for
>> which I'll open new posts on this group. Look for "Python
>> doesn't recognize quote types" and "Python, are you ill?".
>
> You have a tendency to form your questions as complaints about
> Python being broken.
>
> You will probably get better responses if you just state that
> there are things you do not understand, and ask why it works
> that way.
The OP has already been banned from the wxWidgets IRC and the
wxPython mailing list. His MO is to post a never ending stream
of whining, flame-bait, and demands that wxWidgets, wxPython,
(or whatever) be changed to suit his tastes regardless of the
justification for the current design and the amount of breakage
it would cause. wxPythoner (AKA "Chester) also seemed fond of
constantly giving wrong/misleading answers when other
inexperienced users asked technical questions.
He especially liked to post messages with subjects like "To
Rogin Dunn" and "To wxPython Developers" mailing list
instructing them to change various things in wxWidgets,
wxPython, and Python. He consistently ignored pointers to
documentation and explanations of why things were done the way
they were.
On top of all that, his fowl language and insulting attitude
finally got him banned:
http://article.gmane.org/gmane.comp.python.wxpython/58645
http://article.gmane.org/gmane.comp.python.wxpython/58695
So it's best to probably just ignore him...
--
Grant Edwards grante Yow! LBJ, LBJ, how many
at JOKES did you tell today??!
visi.com
Tim Roberts
>
>I am stunned that this simple misunderstanding of mine ended in a
>mathematical clash of a sort. :) You guys really blew me away wih
>your mathematical knowledge. And also the 0**0 is a thing I've never
>thought about trying, until now that is. If the mathematical rule is
>that EVERYTHING raised to the power of 0 is 1, then we should accept
>that, even in the case of 0**0. This is just the way it is.
Sure, but it's ALSO the mathematical rule that 0 raised to any power is 0.
Thus, there are multiple solutions to this problem, meaning that there is
NO solution to the problem.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Terry Reedy
"Tim Roberts" <ti...@probo.com> wrote in message
news:hkse24lhna7fp26tc...@4ax.com...
| wxPyt...@gmail.com wrote:
| >
| >I am stunned that this simple misunderstanding of mine ended in a
| >mathematical clash of a sort. :) You guys really blew me away wih
| >your mathematical knowledge. And also the 0**0 is a thing I've never
| >thought about trying, until now that is. If the mathematical rule is
| >that EVERYTHING raised to the power of 0 is 1, then we should accept
| >that, even in the case of 0**0. This is just the way it is.
|
| Sure, but it's ALSO the mathematical rule that 0 raised to any power is
0.
That may be some people's (partial) rule but not everyone's.
There is only agreement on 0 to a positive power.
| Thus, there are multiple solutions to this problem, meaning that there is
| NO solution to the problem.
Only for some people.
a**b := reduce(mul, [a]*b, 1) for all counts a and b is a simple, uniform,
and useful rule.
Do you have in mind any situations in which it is advantageous to have 0**0
undefined?
tjr
Mark Dickinson
> Do you have in mind any situations in which it is advantageous to have 0**0
> undefined?
(Playing devil's advocate here.) If you regard x**y as exp(y*log(x))
then it's not at all clear that 0.**0. should be considered
well-defined. And since Python likes integer and floating-point
operations to match numerically (as far as possible), 0**0 then
also comes into question.
The big problem here is that the power operation is really trying
to combine two subtly different functionalities (integer powers
and real powers), with quite distinct use-cases, into a single
function. Which leads to problems: witness the mess that's
C99's pow specification: why does it make sense for (-2.0)**2.0 to
return 4.0, while (-2.0)**1.999999999 returns NaN? And why
should (-2.0)**infinity be well-defined?
It looks like that same mess is going to make it into IEEE 754r.
There were suggestions on the 754r mailing list to separate
the pow functionality out into two separate functions: pown
for integer powers and powr for real powers. pown(0.0, 0) would
be 1, while powr(x, y) would be defined strictly as exp(y*log(x))
and so powr(0.,0.) would raise the invalid signal.
I have to admit that almost all my uses of ** are with
integer exponents, and I'd be very upset if anyone took
0**0 == 1 away...
Incidentally, the decimal module is slightly schizophrenic about
this: Decimal(0)**Decimal(0) raises an exception, but
Decimal('Inf')**Decimal(0) returns Decimal(1). Which doesn't
make a lot of sense, since every reason for making 0**0
undefined seems to apply equally well to infinity**0...
Mark
Terry Reedy
"Mark Dickinson" <dick...@gmail.com> wrote in message
news:6b64d8f4-3f61-4295...@m73g2000hsh.googlegroups.com...
On May 11, 9:36 pm, "Terry Reedy" <tjre...@udel.edu> wrote:
|> Do you have in mind any situations in which it is advantageous to have
0**0
|> undefined?
| (Playing devil's advocate here.) If you regard x**y as exp(y*log(x))
Which, of course, I was not, but for the sake of discussion....
| then it's not at all clear that 0.**0. should be considered well-defined.
Then it seems equally dubious that 0.**y, y>0, should be well-defined.
It seems to me that lim as x goes to 0. exp(y*log(x)) is equally well
defined whether y is 0 or not, even though there is a discontinuity in the
limit.
.
...
| The big problem here is that the power operation is really trying
| to combine two subtly different functionalities (integer powers
| and real powers), with quite distinct use-cases, into a single
| function. Which leads to problems: witness the mess that's
| C99's pow specification: why does it make sense for (-2.0)**2.0 to
| return 4.0, while (-2.0)**1.999999999 returns NaN?
2.5 raises an exception. In 3.0,
>>> (-2)**1.99999999
(3.9999999722741113-1.2566370355167477e-07j)
| Incidentally, the decimal module is slightly schizophrenic about this:
That module follows the IBM-led standard, no matter how crazy.
Terry Jan Reedy
Mark Dickinson
> Then it seems equally dubious that 0.**y, y>0, should be well-defined.
> It seems to me that lim as x goes to 0. exp(y*log(x)) is equally well
> defined whether y is 0 or not, even though there is a discontinuity in the
> limit.
Well, there's a difference: the limit of exp(y*log(x)) as (x, y) ->
(0, a) exists for all finite nonzero a. The limit as (x, y) ->
(0, 0) doesn't.
> 2.5 raises an exception. In 3.0,>>> (-2)**1.99999999
>
> (3.9999999722741113-1.2566370355167477e-07j)
Interesting---I hadn't realised that 3.0 had changed this.
I can't quite decide whether I like this behaviour much. It
seems to be the only case where a computation involving only
floats can produce a complex number.
>
> | Incidentally, the decimal module is slightly schizophrenic about this:
>
> That module follows the IBM-led standard, no matter how crazy.
Yeah---I know. :-). The current decimal __pow__ code is mostly
my fault, at least in 2.5.2/2.6/3.0 onwards. For what it's
worth, the author of the Decimal standard has indicated that
the behaviour of 0**0 might change after IEEE 754r finally
sees the light of day.
Mark
Arnaud Delobelle
> On May 12, 2:09 am, "Terry Reedy" <tjre...@udel.edu> wrote:
>
> > Then it seems equally dubious that 0.**y, y>0, should be well-defined.
> > It seems to me that lim as x goes to 0. exp(y*log(x)) is equally well
> > defined whether y is 0 or not, even though there is a discontinuity in the
> > limit.
>
> Well, there's a difference: the limit of exp(y*log(x)) as (x, y) ->
> (0, a) exists for all finite nonzero a. The limit as (x, y) ->
> (0, 0) doesn't.
But exp(y*log(x)) -> 1 as (x, y) -> (0, 0) along any analytic curve
which is not the x=0 axis (I think at least - it seems easy to prove
that given f and g analytic over R, f(x)*ln g(x) -> 0 as x -> 0 if
f(0)=g(0)=0 and g(x)>0 in the neighbourhood of 0). This should cover
most practical uses?
--
Arnaud
Lou Pecora
<f6743b81-9324-46dd...@d77g2000hsb.googlegroups.com>,
wxPyt...@gmail.com wrote:
> I am stunned that this simple misunderstanding of mine ended in a
> mathematical clash of a sort. :) You guys really blew me away wih
> your mathematical knowledge. And also the 0**0 is a thing I've never
> thought about trying, until now that is. If the mathematical rule is
> that EVERYTHING raised to the power of 0 is 1, then we should accept
> that, even in the case of 0**0. This is just the way it is.
Well, it's really not that simple. You've seen that 0**0 can lead to
problems in various areas of mathematics (check the Wikipedia article on
analysis/calculus application vs. combinatorics and discrete math). You
have to be aware of those dangers, what the language (Python here), and
what your application requires. Consistency in mathematics is vital.
If you are using 0**0=1, then your code should be consistent with that
usage.
--
-- Lou Pecora
Lou Pecora
"Terry Reedy" <tjr...@udel.edu> wrote:
> "Mark Dickinson" <dick...@gmail.com> wrote in message
> news:6b64d8f4-3f61-4295...@m73g2000hsh.googlegroups.com...
> On May 11, 9:36 pm, "Terry Reedy" <tjre...@udel.edu> wrote:
> |> Do you have in mind any situations in which it is advantageous to have
> 0**0
> |> undefined?
>
> | (Playing devil's advocate here.) If you regard x**y as exp(y*log(x))
>
> Which, of course, I was not, but for the sake of discussion....
>
> | then it's not at all clear that 0.**0. should be considered well-defined.
>
> Then it seems equally dubious that 0.**y, y>0, should be well-defined.
> It seems to me that lim as x goes to 0. exp(y*log(x)) is equally well
> defined whether y is 0 or not, even though there is a discontinuity in the
> limit.
Huh? That "discontinuity" is the problem. Actually, the problem is
that the function f(x,y)=x**y=exp(y*ln(x)) will be double valued at x=0
and y=0. It's value will depend on the direction in which the limit
approaches (x,y)=(0,0). You cannot have a function that has two values
at one domain point without adding branch cuts (see complex functions
like ln(z), z is complex). That's not well defined -- in your sense.
You are choosing a branch cut and you must make sure the rest of your
math and code are consistent with that. You should also tell any users
of your code about that decision.
--
-- Lou Pecora
Mark Dickinson
> But exp(y*log(x)) -> 1 as (x, y) -> (0, 0) along any analytic curve
> which is not the x=0 axis (I think at least - it seems easy to prove
> that given f and g analytic over R, f(x)*ln g(x) -> 0 as x -> 0 if
> f(0)=g(0)=0 and g(x)>0 in the neighbourhood of 0).
Agreed. And this makes an excellent argument that if you're going to
choose a number for 0.0**0.0 then it's got to be 1. But I still don't
find it completely convincing as an argument that 0.0**0.0 should be
defined at all.
> This should cover most practical uses?
Maybe. But if you're evaluating x**y in a situation where x and y
represent physical quantities, or otherwise have some degree of error,
then you probably want to be warned if x and y both turn out to be
zero.
I seem to be digging myself into a hole here. I'm personally
firmly in the "0**0 should be 1" camp, and always have been---
there are just too many practical benefits to defining 0**0==1
to ignore, and in the case where you're interested in integer
exponents anything else is just plain wrong. The lack of
continuity of the power function at (0,0) seems a small
price to pay.
Mark
Arnaud Delobelle
> In article <mailman.962.12105725...@python.org>,
> "Terry Reedy" <tjr...@udel.edu> wrote:
>
>> "Mark Dickinson" <dick...@gmail.com> wrote in message
>> news:6b64d8f4-3f61-4295...@m73g2000hsh.googlegroups.com...
>> On May 11, 9:36 pm, "Terry Reedy" <tjre...@udel.edu> wrote:
>> |> Do you have in mind any situations in which it is advantageous to have
>> 0**0
>> |> undefined?
>>
>> | (Playing devil's advocate here.) If you regard x**y as exp(y*log(x))
>>
>> Which, of course, I was not, but for the sake of discussion....
>>
>> | then it's not at all clear that 0.**0. should be considered well-defined.
>>
>> Then it seems equally dubious that 0.**y, y>0, should be well-defined.
>> It seems to me that lim as x goes to 0. exp(y*log(x)) is equally well
>> defined whether y is 0 or not, even though there is a discontinuity in the
>> limit.
>
> Huh? That "discontinuity" is the problem. Actually, the problem is
> that the function f(x,y)=x**y=exp(y*ln(x)) will be double valued at x=0
> and y=0.
Actually f(x, y) can take any positive value, depending on how x and y
tend to 0. Say for example
x = exp(-k/y), k being a positive constant.
Then as y -> 0+, so does x and y*ln(x) = y * (-k/y) = -k
Therefore f(x, y) = exp(-k) and as y -> 0,
x -> 0
f(x, y) -> exp(-k)
> It's value will depend on the direction in which the limit
> approaches (x,y)=(0,0). You cannot have a function that has two
> values at one domain point without adding branch cuts (see complex
> functions like ln(z), z is complex).
This is unrelated, z -> ln(z) is a holomorphic function, locally
defined everywhere but at 0, therefore it can be defined on any simply
connected subset of the complex numbers not containing 0.
OTOH, f(x,y) as you defined it above is a real analytic function.
AFAIK, it doesn't have the above property.
--
Arnaud
Arnaud Delobelle
> On May 12, 11:15 am, Arnaud Delobelle <arno...@googlemail.com> wrote:
>
>> But exp(y*log(x)) -> 1 as (x, y) -> (0, 0) along any analytic curve
>> which is not the x=0 axis (I think at least - it seems easy to prove
>> that given f and g analytic over R, f(x)*ln g(x) -> 0 as x -> 0 if
>> f(0)=g(0)=0 and g(x)>0 in the neighbourhood of 0).
>
> Agreed. And this makes an excellent argument that if you're going to
> choose a number for 0.0**0.0 then it's got to be 1. But I still don't
> find it completely convincing as an argument that 0.0**0.0 should be
> defined at all.
>
>> This should cover most practical uses?
>
> Maybe. But if you're evaluating x**y in a situation where x and y
> represent physical quantities, or otherwise have some degree of error,
> then you probably want to be warned if x and y both turn out to be
> zero.
Yes. I'm not much of a physicist so I don't feel confident about this
at all, but when you work out x**y, if x is a measured quantity with
dimensions, then raising it to a power only makes sense if y is
dimensionless and an integer, or maybe a rational with a small
denominator (i.e. it makes sense to cube root a volume, but not a
velocity).
--
Arnaud