Hi Chris,
Thanks for pointing this out. I've committed a fix that looks like it
works. It would be really helpful to have some tests for structures
such as these that could be included in the test suite. Actually,
generally more tests would be welcome; most of those that are there are
No problem, glad to be helpful - especially since I'm the one who asked for the
feature!
I also have the habit of viewing floating point as black magic, especially
because of historical issues such as x87 intermediate precision and weird
things like denormal numbers. So it's quite satisfying
Thank you for looking at this. You're quite right that the shifts were
wrong. I've pushed a fix for this that seems to have corrected it. I'm
not that familiar with the intricacies of floating point numbers so I'm
always glad when someone points out problems.
David
On 21/02/2021 13:50,
I took another little look at the behaviour here.
My basic assumption is that, for any Real32.real r,
Real32.== (PackReal32Big.fromBytes (PackReal32Big.toBytes r), r)
should hold. (and the same for Little obviously)
With the current repo code, it's possible to construct values for which this
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
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
