migrated from Trac, where originally posted by lars_h on 15-Mar-2011 5:04pm
Floats in OM2, i.e., the objects encoded by the element, are specified as being of the IEEE 754 double precision variety, i.e., 64 bits wide. This makes sense, as those are probably the most widely supported floats today.
The most recent version IEEE 754-2008 does however define many more float formats. In particular, it defines floats with any bit-width a multiple of 32 from 128 and up, so it might be good for OM to support that too.
In the XML encoding, one would simply have to allow more than 16 hex digits in the value of the hex attribute of the OMF element; indeed, it is not clear to me from the OM2 schema that this isn't allowed already. I suspect the binary encoding might get into trouble however, as it seems the 8 bytes length of the data is implicit in the float token. It is not clear to me whether there is room in the binary encoding for another float token (would this be what the long bit is for?).
An alternative approach to encoding IEEE floats wider than 64 bits would be to define a symbol which, when applied to a bytearray, returns the corresponding IEEE 754 float. In that case, no change to the standard is needed.
Alas, I don't have access to the IEEE 754 standard as such, so I cannot speak with full confidence about what is in it.
migrated from Trac, where originally posted by lars_h on 15-Mar-2011 5:04pm
Floats in OM2, i.e., the objects encoded by the element, are specified as being of the IEEE 754 double precision variety, i.e., 64 bits wide. This makes sense, as those are probably the most widely supported floats today.
The most recent version IEEE 754-2008 does however define many more float formats. In particular, it defines floats with any bit-width a multiple of 32 from 128 and up, so it might be good for OM to support that too.
In the XML encoding, one would simply have to allow more than 16 hex digits in the value of the hex attribute of the OMF element; indeed, it is not clear to me from the OM2 schema that this isn't allowed already. I suspect the binary encoding might get into trouble however, as it seems the 8 bytes length of the data is implicit in the float token. It is not clear to me whether there is room in the binary encoding for another float token (would this be what the long bit is for?).
An alternative approach to encoding IEEE floats wider than 64 bits would be to define a symbol which, when applied to a bytearray, returns the corresponding IEEE 754 float. In that case, no change to the standard is needed.
Alas, I don't have access to the IEEE 754 standard as such, so I cannot speak with full confidence about what is in it.