[Python-Dev] Numerical robustness, IEEE etc.

Neal Norwitz nnorwitz at gmail.com
Mon Jun 19 05:29:07 CEST 2006


You should be aware of PEP 754 and address it.

http://www.python.org/dev/peps/pep-0754/

Also note that Python conforms to C89, not C99.  Any solution should
work on all Python platforms.  Some of those platforms are here:

http://www.python.org/dev/buildbot/all/

n
--
On 6/18/06, Brett Cannon <brett at python.org> wrote:
> [skipping answering the numeric-specific questions since I am no math expert
>  =) ]
>
>
> On 6/15/06, Nick Maclaren <nmm1 at cus.cam.ac.uk > 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.  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.
> >
> > 1) Should I start off by developing a testing version, to give people
> > a chance to scream at me, or write a PEP?  Because I am no Python
> > development expert, the former would help to educate me into its
> > conventions, technical and political.
>
>
> I would do both.  It is a lot easier to get something accepted when you have
> working code.  But a PEP to vent possible arguments against the change along
> with any backwards-compatibility issues will be needed for something as
> major as changing how math works.
>
> > 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),
> > 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?
> >
> > 3) I am rather puzzled by the source control mechanism.  Are commit
> > privileges needed to start a project like this in the main tree?
> > Note that I am thinking of starting a test subtree only.
>
>
> To work directly in Python's repository, yes, checkin privileges are needed.
>  In order to get these, though, you usually either need to have been
> involved in python-dev for a while and be known to the group or have someone
> everyone trusts to watch over you as you do your work in a branch.
>
> > 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?
>
>
> The C API docs are at http://docs.python.org/ and there are some docs at
> http://www.python.org/dev/ in terms of intro to how development for Python
> tends to take place.
>
> -Brett
>
>
> > 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.
> >
> >
> >
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com
>
>
>


More information about the Python-Dev mailing list