Wider OMF formats

[kohlhase]

see OpenMath/OM3#137

[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.

[JamesHDavenport]

In terms of OMF, I agree with this. But it should be done. In fact, I’d be inclined to insert a note that it will be done. The reason OMF is building is partly for efficiency and partly to ensure accuracy for IEEE double. Now that IEEE supports more, OM should. There’s still a CD representation of software bigfloats, of course. James From: Michael Kohlhase [mailto:notifications@github.com] Sent: 05 October 2017 11:46 To: OpenMath/OMSTD <OMSTD@noreply.github.com> Cc: James Davenport <J.H.Davenport@bath.ac.uk>; Mention <mention@noreply.github.com> Subject: Re: [OpenMath/OMSTD] Wider OMF formats (#32) cc: @davidcarlisle<https://github.com/davidcarlisle> @JamesHDavenport<https://github.com/jameshdavenport> @pdfion<https://github.com/pdfion> @lars-hellstrom<https://github.com/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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#32 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AGvamfOjc9fR2mWIcz905Um2crwBEoQCks5spLNRgaJpZM4PqryE>.

[lars-hellstrom]

Despite being the originator, I don't agree. Quoting myself from the original ticket:

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)

Float construction symbols are far more flexible — besides supporting different bitwidths, they can also provide features such as:

• Densely packed complex floats (real and imaginary part concatenated in the same OMB).
• Densely packed vectors of floats (elements concatenated in the same OMB).
• Densely packed matrices of floats (ditto).

Moreover note that changing the OMF elements to support other float widths would be an OM3 change. And lots of phrasebook writers would hate it, because languages currently don't come with built-in support for floats wider than 64 bits.

Doing it via constructor symbols folds any problems into the generic "unhandled symbol" error case, which everybody already have to deal with anyway.