On Feb 14, 11:09 pm, John Nagle <[EMAIL PROTECTED]> wrote: > You also need to think about how conditionals interact with > quiet NANs. Properly, comparisons like ">" have three possibilities:
True. There was a recent change to Decimal to make comparisons (other than !=, ==) with NaNs do the "right thing": that is, raise a Python exception, unless the Invalid flag is not trapped, in which case they return False (and also raise the Invalid flag). I imagine something similar would make sense for floats. > True, False, and "raise". Many implementations don't do that well, > which means that you lose trichotomy. "==" has issues; properly, > "+INF" is not equal to itself. I don't understand: why would +INF not be equal to itself? Having INF == INF be True seems like something that makes sense both mathematically and computationally. > If you support quiet NANs, you need the predicates like "isnan". They're on their way! math.isnan and math.isinf will be in Python 2.6. > C++ exception using Microsoft's compilers. But that's not portable. > x86 has exact exceptions, but most other superscalar machines > (PowerPC, Alpha, if anybody cares) do not. Interesting. What do you mean by 'exact exception'? > For Python, I'd suggest throwing a Python exception on all errors > recognized by the FPU, except maybe underflow. Yes: I think this should be the default behaviour, at least. It was agreed quite a while ago amongst the Python demigods that the IEEE overflow, invalid and divide-by-zero signals should ideally raise Python exceptions, while underflow and inexact should be ignored. The problem is that that's not what Python does at the moment, and some people rely on being able to get NaNs and infinities the old ways. > If you're doing > such serious number-crunching that you really want to handle NANs, > you're probably not writing in Python anyway. If you're worried about speed, then I agree you probably shouldn't be writing in Python. But I can imagine there are use-cases for nonstop arithmetic with nans and infs where speed isn't the topmost concern. Mark -- http://mail.python.org/mailman/listinfo/python-list
