Wider OMF formats

[jbs1]

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.

[jbs1]

migrated from Trac, where originally posted by lars_h on 15-May-2014 12:39pm

My current suggestion, based on input from David Carlisle on the OM3 mailing list, is that rather than extending OMF to support more float formats, language should be added to the standard to clarify that the OMF element is primarily provided as a convenience (lightweight to implement, since 64-bit floats are very widely supported), and that other kinds of float should primarily be encoded as the application of an appropriate float construction symbol to the raw data (which may be encoded as an OMB element), e.g.

<OMA>
   <OMS cd="IEEEfloat" name="construct"/> <!-- symbol made up for sake of example -->
   <OMB>ASNFZ4mrze8BI0VniavN7w==</OMB> <!-- 128 bits of data, float value probably nonsense -->
</OMA>

This means this ticket could be changed from OM3 standard to OM2 standard (or something).

[kohlhase]

moved to OpenMath/OMSTD#32

[kohlhase]

cc: @davidcarlisle @JamesHDavenport @pdfion @lars-hellstrom

I think that having more float representations is a very good goal, but this requires a generalization that is outside the scope of Revision 2.