On 2/27/07, Travis Oliphant <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. Chuck