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, 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'm pretty sure it is. It certainly is on my machine at the moment: >>> float(3e300*3e300) == float(2e300*4e300) True Are you confusing INF with NAN, which is specified to be not equal to itself (and, IIRC, is the only thing specified to be not equal to itself, such that one way to test for NAN is x!=x). > For Python, I'd suggest throwing a Python exception on all errors > recognized by the FPU, except maybe underflow. If you're doing > such serious number-crunching that you really want to handle NANs, > you're probably not writing in Python anyway. Even if that were entirely true, there are cases where (for example) you're using Python to glue together numerical routines in C, but you need to do some preliminary calculations in Python (where there's no edit/compile/run cycle but there is slicing and array ops), but want the same floating point behavior. IEEE conformance is not an unreasonable thing to ask for, and "you should be using something else" isn't a good answer to "why not?". Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
