[Python-Dev] Numerical robustness, IEEE etc.

[Jim Jewett]

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