[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:
> >
> >
> >     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:'


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.

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