Comparing floating point: == vs is

[Daniel Murphy]

"Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message 
news:mailman.1708.1310882400.14074.digitalmars-d-learn at puremagic.com...
> 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 .. $]?
>

They're just padding bytes, not included in the structure, so they always 
come afterwards.
eg.
union { real f; ubyte[10] b; }
should give you them in little or big endian.

> And that still leaves the question of NaN. Why would reversing the bytes 
> twice
> make NaN's not equal with == anymore?
>
NaNs would never be equal with ==.  Using 'is', it works as expected for me.
If you were reversing the full 12 bytes, then comparing, some of the data 
would have ended up in the padding bytes and could have got lost when moving 
to/from the stack or the floating point registers.  Don't forget that is 
will do a bitwise comparison including the padding bytes on linux, so 
isIdentical will likely give you the results you want.