Nick Maclaren <[EMAIL PROTECTED]> 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 _______________________________________________ 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
