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 _______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
