Proposed standard python module: ieee754

[Warnes, Gregory R]

> -----Original Message-----
> From: martin at v.loewis.de [mailto:martin at v.loewis.de]
> 
> "Warnes, Gregory R" <gregory_r_warnes at groton.pfizer.com> writes:
> 
> > Not at all.  As it stands now, most common platforms have 
> IEEE 754 compliant
> > hardware, unfortunately, the C library routines are 
> inconsistent in how and
> > whether they deal with these special values.   
> 
> It's worse than that: The hardware is usually *not* (strictly) IEEE 754
> compliant,

True, but it is close enough for the numerical software I use on a regular
basis (R, Octave, Mathematica, Matlab...)

> and even if it is, it is inconsistent across platforms in
> being so. 

Again, its more a case of the C libraries being inconsistent.

> IEEE supports different rounding modes and exception modes
> (this is probably wrong terminology), 

good enough, ;^)

> so whether computations give INF
> or an exception is vendor-defined (either is IEEE 754 compliant).

Well, only  vendor defined in the limited sense that the vendor supplied
C-library provides the defaults and the calls to change them.  But, python
already has the 'fpectrl' module which allows the python programmer to
(partially) set the exception handling aspects of the FPU.   

For this module, I'm interested in being able to deal with the special
values when I do get them...   Perhaps later we'll create a comprehensive
solution.

-Greg

> 
> Regards,
> Martin
> -- 
> http://mail.python.org/mailman/listinfo/python-list
> 


LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately.