[Python-Dev] Numerical robustness, IEEE etc.

[Michael Hudson]

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