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

Michael Hudson mwh at python.net
Tue Jun 20 12:52:57 CEST 2006

This mail never appeared on python-dev as far as I can tell, so I'm
not snipping anything.

On 19 Jun 2006, at 16:29, Nick Maclaren wrote:

Michael Hudson <mwh at python.net> wrote:

As I have posted to comp.lang.python, I am not happy with Python's numerical robustness - because it basically propagates the 'features' of IEEE 754 and (worse) C99. That's not really now I would describe the situation today. It is certainly the case in 2.4.2, however you would describe it.

I guess you could say it reflects the features of C89. It certainly
doesn't do anything C99 specific.

But I wouldn't characterize anything Python does in the floating
point area as "designed", particularly. Portability makes that hard.

2) Because some people are dearly attached to the current behaviour, warts and all, and there is a genuine quandary of whether the 'right' behaviour is trap-and-diagnose, propagate-NaN or whatever-IEEE-754R- finally-specifies (let's ignore C99 and Java as beyond redemption),

Why? Maybe it's clear to you, but it's not totally clear to me, and it any case the discussion would be better informed for not being too dismissive. Why which?

Why are C99 and Java beyond redemption? I know some of the mistakes
Java makes here, but still, you could at least hint at which you are
thinking of.

There are several things that you might be puzzled over. And where can I start? Part of the problem is that I have spent a LOT of time in these areas in the past decades, and have been involved with many of the relevant standards, and I don't know what to assume.

Well, if you can't explain what your intentions are to me, as a
mathematics-degree holding core Python developer that has done at
least some work in this area, I posit that you aren't going to get
very far.

I'm not intimately familiar with the standards like 754 but I have
some idea what they contain, and I've read appendix F of C99, if that
helps you target your explanations.

there might well need to be options. These can obviously be done by a command-line option, an environment variable or a float method. There are reasons to disfavour the last, but all are possible. Which is the most Pythonesque approach?

I have heard Tim say that there are people who would dearly like to be able to choose. Environment variables and command line switches are not Pythonic. All right, but what is? Firstly, for something that needs to be program-global?

Why does it need to be program global? In my not-really-thought-out
plans for straightening out CPython's floating point story I had
envisioned code to be written something like this:

with fp_context(non_stop_context): a = 1e308*1e308 # a is now +inf b = a/a # b is now a quiet nan

with fp_context(all_traps_context): a = 1.0/3.0 # raises some Inexact exception

(and have a default context which raises for Overflow, DivideByZero
and InvalidOperation and ignores Underflow and Inexact).

This could be implemented by having a field in the threadstate of FPU
flags to check after each fp operation (or each set of fp operations,
possibly). I don't think I have the guts to try to implement
anything sensible using HW traps (which are thread-local as well,
aren't they?).

Does this look anything at all like what you had in mind?

Secondly, for things that don't need to be brings up my point of adding methods to a built-in class.

This isn't very hard, really, in fact float has class methods in 2.5...

I'm interested in making Python's floating point story better, and have worked on a few things for Python 2.5 -- such as pickling/marshalling of special values -- but I'm not really a numerical programmer and don't like to guess what they need. Ah. I must get a snapshot, then. That was one of the lesser things on my list.

It was fairly straightforward, and still caused portability problems...

I have spent a lot of the past few decades in the numerical programming arena, from many aspects.

Well, I hope I can help you bring some of that experience to Python.

Cheers, mwh

More information about the Python-Dev mailing list