[Numpy-discussion] Draft PEP for the new buffer interface to be in Python 3000
Tue Feb 27 23:11:26 CST 2007
Charles R Harris wrote:
> On 2/27/07, *Travis Oliphant* <firstname.lastname@example.org
> <mailto:email@example.com>> wrote:
> 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
> > 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
> > 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:'
> That would probably do nicely. There are potential ambiguities but
> nothing worth worrying about. Is there a way to assign names to such a
> type? I suppose that it is just another string constant so one could
> write something like
> float32 = '>1t:sign: 8t:exp: 23t:mantissa:'
> and use that. Can those bit fields be of arbitrary length?
> Now for something completely different ;) In some things, like the
> socket module, it is possible to ask for a filelike interface which
> buffers the input and has the usual read, readline, etc function
> interface, but fromfile doesn't work with it. This isn't a biggie and
> I suppose fromfile is looking for a 'real' file, but I wonder if this
> would be a difficult thing to implement? I could look at the code but
> I thought I would ask you first.
The problem here is that fromfile is using the raw stdio fscanf commands
which require an actual file id. It is not using the Python-level
fread. It's pretty low-level. On the other-hand there is the
fromstring approach which works with any stream. I suspect a function
that uses one or the other could be implemented.
The relevant functions are XXXX_scan and XXX_fromstr in arraytypes.c.src
These are used for each data-type. Notice that PyArray_FromFile
actually requires a FILE *fp pointer. You might be able to use
PyArray_FromString which allows a char * to read data from.
> Numpy-discussion mailing list
More information about the Numpy-discussion