[Python-Dev] Numerical robustness, IEEE etc.

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