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