[Numpy-discussion] Draft PEP for the new buffer interface to be in Python 3000

Travis Oliphant oliphant@ee.byu....
Tue Feb 27 22:38:55 CST 2007


Charles R Harris wrote:
>
>
>     The problem is that we aren't really specifying floating-point
>     standards, we are specifying float, double and long double as whatever
>     the compiler understands.
>
>     There are some platforms which don't follow the IEEE 754 standard.
>     This format specification will not be able to describe
>     platform-independent floating-point descriptions.
>
>     It would be nice to have such a description, but that is not what
>     struct-style syntax does.  Perhaps we could add it in the
>     specification,
>     but I'm not sure if the added complexity is worth holding it up over.
>
>
> True enough, and it may not make that much sense until it is in the c 
> standard. But it might be nice to reserve something for the future and 
> maybe give some thought of how to deal with new data types as they 
> come along. I can't think of any really flexible methods that don't 
> require some sort of verbose table that goes along with the data, and 
> the single letter codes are starting to get out of hand. Hmmm. It 
> would actually be nice to redo things so that there was a prefix, say 
> z for complex, f for float, then something for precision. The 
> designation wouldn't be much use without some arithmetic to go with it 
> and it doesn't make sense to write code for things that don't exist. I 
> wonder how much of the arithmetic can be abstracted from the data type?

I suspect we may have to do this separately in the NumPy world.   
Perhaps we could get such a specification into Python itself, but I'm 
not hopeful.  Notice, though that we could use the struct syntax to 
specify a floating-point structure using  the bit-field and naming.

In other words an IEEE 754 32-bit float would be represented in 
struct-style syntax as

'>1t:sign: 8t:exp: 23t:mantissa:'



-Travis





More information about the Numpy-discussion mailing list