[Python-Dev] Numerical robustness, IEEE etc. (original) (raw)

Jim Jewett jimjjewett at gmail.com
Fri Jun 23 20:21:18 CEST 2006

Nick Maclaren wrote:

The standard floating-point model is that it maps functions defined on the reals (sometimes complex) to approximations defined on floating- point.

OK.

The conventional interpretation was that any operation that was not mathematically continuous in an open region including its argument values (in the relevant domain) was an error, and that all such errors should be flagged. That is what I am talking about.

Not a bad goal, but not worth sweating over, since it isn't sufficient. It still allows functions whose continuity does not extend to the next possible floating point approximation, or functions whose value, while continuous, changes "too much" in that region.

Unfortunately, that doesn't help, because it is not where the issues are. What I don't know is how much you know about numerical models, IEEE 754 in particular, and C99. You weren't active on the SC22WG14

For some uses, it is more important to be consistent with established practice than to be as correct as possible. If the issues are still problems, and can't be solved in languages like java, then ... the people who want "correct" behavior will be a tiny minority, and it makes sense to have them use a 3rd-party extension.

For example, consider conversion between float and long - which class should control the semantics?

The current python approach with binary fp is to inherit from C (consistency with established practice). The current python approach for Decimal (or custom classes) is to refuse to guess in the first place; people need to make an explicit conversion. How is this a problem?

they are unspecified - IDEALLY, things like floating-point traps would be handled thread-locally ... but things like TLB miss traps, device interrupts and machine-check interrupts need to be CPU-global. Unfortunately, modern architectures use a single mechanism for all of them

That sounds like a serious problem for some combination of threading and trying to use hardware floating point at maximum efficiency. It does not sound like a problem for software implementations, like python's Decimal package. It might limit the gains that a portable C re-implementation could get, but if you need the absolute fastest and you need threads -- maybe that is again the domain of a 3rd-party extension.

-jJ

More information about the Python-Dev mailing list