[Python-Dev] PEP 3188: Implementation Questions

[David Cournapeau]

On Fri, Feb 26, 2010 at 1:51 PM, Meador Inge <meadori at gmail.com> wrote:
> Hi All,
>
> Recently some discussion began in the issue 3132 thread
> (http://bugs.python.org/issue3132) regarding
> implementation of the new struct string syntax for PEP 3118.  Mark Dickinson
> suggested that I bring the discussion on over to Python Dev.  Below is a
> summary
> of the questions\comments from the thread.
>
> Unpacking a long-double
> ===================
>
> 1. Should this return a Decimal object or a ctypes 'long double'?
> 2. Using ctypes 'long double' is easier to implement, but precision is
>     lost when needing to do arithmetic, since the value for cytpes 'long
> double'
>     is converted to a Python float.
> 3. Using Decimal keeps the desired precision, but the implementation would
>     be non-trivial and architecture specific (unless we just picked a
>     fixed number of bytes regardless of the architecture).
> 4. What representation should be used for standard size and alignment?
>     IEEE 754 extended double precision?

I think supporting even basic arithmetic correctly for long double
would be a tremendous amount of work in python. First, as you know,
there are many different formats which depend not only on the CPU but
also on the OS and the compiler, but there are quite a few issues
which are specific to long double (like converting to an integer which
cannot fit in any C integer type on most implementations).

Also, IEEE 754  does not define any alignment as far as I know, that's
up to the CPU implementer I believe. In Numpy, long double usually
maps to either 12 bytes (np.float96) or 16 bytes (np.float128).

I would expect the long double to be mostly useful for data exchange -
if you want to do arithmetic on long double, then the user of the
buffer protocol would have to implement it by himself (like NumPy does
ATM). So the important thing is to have enough information to use the
long double: alignment and size are not enough.

cheers,

David