On Thu, Apr 28, 2011 at 1:25 PM, Steven D'Aprano <st...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
