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

[Charles R Harris]

On 2/27/07, Travis Oliphant <oliphant at ee.byu.edu> wrote:
>
> Charles R Harris wrote:
> >
> >
> > On 2/27/07, *Travis Oliphant* <oliphant at ee.byu.edu
> > <mailto:oliphant at ee.byu.edu>> wrote:
> >
> >     PEP: <unassigned>
> >     Title: Revising the buffer protocol
> >     Version: $Revision: $
> >     Last-Modified: $Date:  $
> >     Author: Travis Oliphant <oliphant at ee.byu.edu
> >     <mailto:oliphant at ee.byu.edu>>
> >     Status: Draft
> >     Type: Standards Track
> >     Created: 28-Aug-2006
> >     Python-Version: 3000
> >
> >
> > <snip>
> >
> >
> >     Additions to the struct string-syntax
> >
> >        The struct string-syntax is missing some characters to fully
> >        implement data-format descriptions already available elsewhere
> (in
> >        ctypes and NumPy for example).  Here are the proposed additions:
> >
> >        Character         Description
> >        ==================================
> >        '1'               bit (number before states how many bits)
> >        '?'               platform _Bool type
> >        'g'               long double
> >        'F'               complex float
> >        'D'               complex double
> >        'G'               complex long double
> >        'c'               ucs-1 (latin-1) encoding
> >        'u'               ucs-2
> >        'w'               ucs-4
> >        'O'               pointer to Python Object
> >        'T{}'             structure (detailed layout inside {})
> >        '(k1,k2,...,kn)'  multi-dimensional array of whatever follows
> >        ':name:'          optional name of the preceeding element
> >        '&'               specific pointer (prefix before another
> charater)
> >        'X{}'             pointer to a function (optional function
> >                                                  signature inside {})
> >
> >
> > I think it might be good to have something for the quad and half
> > precision floats that will be coming along in the next IEEE754
> > specification. Quad precision isn't used that much, but when you need
> > it, it is useful. Half precision (16 bits) is used in some GPU's and I
> > have seen it used for such things as recording side looking radar
> > returns.
>
> 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?

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20070227/48da295a/attachment.html>