Comparing floating point: == vs is

[Jonathan M Davis]

On Sunday 17 July 2011 14:19:12 Daniel Murphy wrote:
> "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
> news:mailman.1705.1310853321.14074.digitalmars-d-learn at puremagic.com...
> 
> > I suspect that the problem is a combination of issues with NaN and real.
> > If I
> > change the first three tests (which test init which is NaN) to is, then
> > they
> > pass, but the test for real.max fails regardless of whether is or == is
> > used.
> > The other tests seem to pass regardless of whether is or == is used. So,
> > I may
> > need to do something special for NaN, and I may have to do something to
> > deal
> > with the padding in real. I don't know.
> > 
> > - Jonathan M Davis
> 
> They all pass for me when using 'is' on win32, so assuming you're on linux
> or osx the padding issue is what you're running into.  The workaround is
> probably using isIdentical from std.math for floating point types instead of
> 'is' and only swapping the first 10 bytes in endianswap (for reals only,
> the other types should work).  The 'is' problem will be fixed, but swapping
> the full 12 or 16 bytes of real will always result in the wrong value.

I'm on Linux.

I need to do whatever will result in the correct value with == if that is at 
all possible. The question the is twofold:

1. How to make it so that swapping the endianness twice doesn't butcher NaNs.

2. How to properly swap reals if they have padding.

It sounds like the solution for reals is to only swap part of it. So, I assume 
that the first 10 bytes are a different ten bytes on each platform? If so, are 
they the ones on the left in little endian or the ones on the right (making 
big endian the other)? i.e. value[0 .. 10] or value[$ - 10 .. $]?

And that still leaves the question of NaN. Why would reversing the bytes twice 
make NaN's not equal with == anymore?

- Jonathan M Davis