On Jun 23, 6:49 pm, Lie Ryan <lie.1...@gmail.com> wrote: > Mark Dickinson wrote: > > On Jun 23, 3:52 am, Steven D'Aprano > > <ste...@remove.this.cybersource.com.au> wrote: > >> On Mon, 22 Jun 2009 13:43:19 -0500, David C. Ullrich wrote: > >>> In my universe the standard definition of "log" is different froim what > >>> log means in a calculus class > >> Now I'm curious what the difference is. > > > It's just the usual argument about whether 'log' means > > log base 10 or log base e (natural log). At least in the > > US, most[*] calculus texts (and also most calculators), > > for reasons best known to themselves, use 'ln' to mean > > natural log and 'log' to mean log base 10. But most > > mathematicians use 'log' to mean natural log: pick up a > > random pure mathematics research paper that has the word > > 'log' in it, and unless it's otherwise qualified, it's > > safe to assume that it means log base e. (Except in the > > context of algorithmic complexity, where it might well > > mean log base 2 instead...) > > I usually use log without explicit base only when the base isn't > relevant in the context (i.e. when whatever sane base you put in it > wouldn't really affect the operations). In algorithmic complexity, a > logarithm's base doesn't affect the growth shape and, like constant > multiplier, is considered irrelevant to the complexity. > > > Python also suffers a bit from this confusion: the > > Decimal class defines methods 'ln' and 'log10', while > > the math module and cmath modules define 'log' and > > 'log10'. > > In fact, in the Decimal class there is no log to an arbitrary base. > > > (But the Decimal module has other problems, > > like claiming that 0**0 is undefined while > > infinity**0 is 1.) > > Well, in math inf**0 is undefined. Since python is programming language, > and in language standards it is well accepted that undefined behavior > means implementations can do anything they like including returning 0, > 1, 42, or even spitting errors, that doesn't make python non-conforming > implementation. > > A more serious argument: in IEEE 745 float, inf**0 is 1. Mathematic > operation in python is mostly a wrapper for the underlying C library's > sense of math. > > > > > [*] A notable exception is Michael Spivak's 'Calculus', which also > > happens to be the book I learnt calculus from many years ago.
Well, AFAIK Python defines CPython as the standard. So whatever CPython does is the defined behaviour. Regarding inf ** 0, why does IEEE745 define it as 1, when there is a perfectly fine NaN value? -- http://mail.python.org/mailman/listinfo/python-list