[Python-Dev] PyObject_RichCompareBool identity shortcut (original) (raw)
Alexander Belopolsky alexander.belopolsky at gmail.com
Thu Apr 28 20:09:21 CEST 2011
- Previous message: [Python-Dev] PyObject_RichCompareBool identity shortcut
- Next message: [Python-Dev] PyObject_RichCompareBool identity shortcut
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, Apr 28, 2011 at 1:25 PM, Steven D'Aprano <steve at pearwood.info> wrote: ..
But it's perfectly fine to do this:
sum(a) nan
This use case reminded me Kahan's
""" Were there no way to get rid of NaNs, they would be as useless as Indefinites on CRAYs; as soon as one were encountered, computation would be best stopped rather than continued for an indefinite time to an Indefinite conclusion. """ http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps
More often than not, you would want to sum non-NaN values instead.
..
(I grant that Alexander is an exception -- I understand that he does do a lot of numeric work, and does come across NANs, and still doesn't like them one bit.)
I like NaNs for high-performance calculations, but once you wrap floats individually in Python objects, performance is killed and you are better off using None instead of NaN.
Python lists don't support element-wise operations and therefore there is little gain from being able to write x + y in loops over list elements instead of ieee_add(x, y) or add_or_none(x, y) with proper definitions of these functions. On the other hand, eq gets invoked implicitly in cases where you don't access to the loop. Your only choice is to filter your data before invoking such operations.
- Previous message: [Python-Dev] PyObject_RichCompareBool identity shortcut
- Next message: [Python-Dev] PyObject_RichCompareBool identity shortcut
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]