[Python-Dev] Numerical robustness, IEEE etc.

[Michael Hudson]

Nick Maclaren <nmm1 at cus.cam.ac.uk> writes:

> 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.

> Yes, it's better, but I would like to make it a LOT better.  I
> already have a more robust version of 2.4.2, but there are some
> problems, technical and political.  I should appreciate advice.

I would like to see Tim Peters' opinion on all this.

> 1) Should I start off by developing a testing version, to give people
> a chance to scream at me, or write a PEP?

"Yes"

Or did you want advice on which?  I think a PEP would make a lot of
sense.

> 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.

> 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.

> 3) I am rather puzzled by the source control mechanism.  Are commit
> privileges needed to start a project like this in the main tree?

Yes.  You can also use svk, I believe, but I don't really know
anything about that.

> 4) Is there a Python hacking document?  Specifically, if I want to
> add a new method to a built-in type, is there any guide on where to
> start?

Don't think so.  There's some stuff under http://www.python.org/dev/
but nothing that would cover this.

> 5) I am NOT offering to write a full floating-point emulator, though
> it would be easy enough and could provide repeatable, robust results.
> "Easy" does not mean "quick" :-(  Maybe when I retire.  Incidentally,
> experience from times of yore is that emulated floating-point would
> be fast enough that few, if any, Python users would notice.

Maybe you're right, but I personally doubt this last bit.



Speaking more generally, it would be nice if you gave more
explanations of why the changes you want to make are desirable -- and
for that matter, more details about what they actually are.

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.

Cheers,
mwh

-- 
  Python enjoys making tradeoffs that drive *someone* crazy <wink>.
                                       -- Tim Peters, comp.lang.python