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 <[EMAIL PROTECTED]> 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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
