[Python-ideas] Yet another sum function (fractions.sum)

[Mark Dickinson]

On Thu, Aug 22, 2013 at 7:18 AM, Steven D'Aprano <steve at pearwood.info>wrote:

> As far as whether some hypothetical sqrt method should return a complex
> number or raise an exception, I'd like to point out that as of Python 3.x,
> math.sqrt is now the odd-man-out:
>

If you restrict your attention to square root operations, then yes.  But
math.sqrt is behaving just like math.log, math.acos, math.asin, math.atanh,
etc. in raising an exception when it could have been returning a complex
number.  In that sense, I'd say that it's rather the ** operation that's
the odd man out, in that there are very few other ways to get complex
numbers with no obvious explicit request for complex numbers (either in the
form of a cmath import or use of imaginary literals, or use of the
'complex' constructor, etc.).  I've never been particularly comfortable
with this aspect of PEP 3141.

While I'm ranting: the other part of PEP 3141 that was wrong IMO is the
decision to return ints from math.floor and math.ceil (e.g., for floats and
Decimal instance).  On floats, floor and ceil are simple, fundamental and
inexpensive operations.  But the conversion to int adds unnecessary
overhead to those simple operations.

iwasawa:~ mdickinson$ /opt/local/bin/python2.7 -m timeit -s "x = 1e300;
import math" "y = math.floor(x)"
10000000 loops, best of 3: 0.107 usec per loop
iwasawa:~ mdickinson$ /opt/local/bin/python3.3 -m timeit -s "x = 1e300;
import math" "y = math.floor(x)"
1000000 loops, best of 3: 0.574 usec per loop

</rant>

-- 
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130822/50578727/attachment.html>