Oh, thank you!
I had thought that the difference between x87 and SSE, and the different internal precisions, mattered only for intermediate register values during calculation - and that when a 32-bit float was "at rest", i.e. being stored in 32 bits, it would always have IEEE 754 representation (as described e.g. at https://en.wikipedia.org/wiki/Single-precision_floating-point_format#IEEE_75...)
Is this not right? Do I have the wrong mental model here?
The current behaviour does indeed seem a bit off (Poly/ML rev 62a56474f0, 64-bit Linux).
If I take, say, 1.0 and convert it to bytes big-endian, I think I expect to see
sign bit: 0 exponent (8 bits): 127 (exponent is 0, stored unsigned with an offset of 127) fraction (23 bits): 0 (as the 1 in 1.0 x 2^0 is implicit)
so 0111 1111 1000 0000 0000 0000 0000 0000 or 3F 80 00 00
and that's what PackReal32Big.toBytes 1.0 returns in MLton. In Poly/ML I'm getting this
PackReal32Big.toBytes 1.0;
val it = fromList[0wx1F, 0wxC0, 0wx0, 0wx0]: Word8Vector.vector
1F C0 00 00 is the same bit pattern as 3F 80 00 00, but shifted right by one bit, and no longer a normal IEEE 754 number I think. Is it possible there's an off-by-one error in the bit lookup, or is this all a symptom of my having the wrong idea about what's going on?
Thanks,
Chris
On Sat, 6 Feb 2021, at 16:24, David Matthews wrote:
I've added this to master. It seemed like a good idea although it was a bit more complicated than PackReal because Real32.real values are "boxed" in 32-bit Poly/ML but tagged in 64-bit.
I'm not exactly clear how useful PackRealN operations are for general data interchange. Currently they just store and load the bytes that make up the number but how those are interpreted will depend on the platform. For example it seems that the X87 format used on X86/32 is different from the SSE format used on X86/64.
David
On 02/02/2021 09:25, Chris Cannam wrote:
Hello! I find I could do with the PackReal32{Big,Little} structures, 32-bit floats being often more amenable to serialisation and used in some storage formats.
Would there be any appetite for adding these?
Thanks,
Chris _______________________________________________ polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml