On 2/27/07, Travis Oliphant <[EMAIL PROTECTED]> wrote:
Charles R Harris wrote: > > > On 2/27/07, *Travis Oliphant* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > PEP: <unassigned> > Title: Revising the buffer protocol > Version: $Revision: $ > Last-Modified: $Date: $ > Author: Travis Oliphant <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> > 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
_______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
