michal.x.strzelczyk@jpmorgan.com wrote:
IMO the pragmatic approach would be to settle with one fp format and implement (more or less trivial) transformation functions to support the platforms that don't implement it natively. Picking IEEE754 standard would seem fine unless somebody can point out gaps preventing this from being able to convey features other formats can.
I agree. Almost all platforms use the IEEE754 format for float and double. So these can, and probably should, be used for portable binary archives. If anyone needs to support some platform that uses some other format, then he will have to add code that converts to/from the IEEE754 formats. Several different formats are used for long double. I think it is reasonable not to support long double, at least not initially. I see three options for dealing with the endianness issue: 1. make all archives big-endian 2. make all archives little-endian 3. use the native format when saving, and put an endianness flag in the archive. 1 is inefficient when moving data between little-endian platforms 2 is inefficient when moving data between big-endian platforms So 3 should be most efficient. Is there an easy way of storing an endianness-flag in an archive? --Johan Råde