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

[Travis Oliphant]

Charles R Harris wrote:
>
>
> On 2/27/07, *Travis Oliphant* <oliphant@ee.byu.edu 
> <mailto:oliphant@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.

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.

-Travis





>
> Chuck
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>