On: Take care, it's Floating Point Arithmetic

[lmm]

It's not commutative: -0 + 0 = -0, but 0 + -0 = 0.

[homeomorphic → lmm]

But doesn't IEEE-754 consider -0 and 0 equal? From https://en.wikipedia.org/wiki/IEEE_floating_point#Total-orde... :

"The normal comparison operations however treat NaNs as unordered and compare −0 and +0 as equal."

[ajross → homeomorphic]

Right. -0 == 0. The existence of a "-0" is a property of the underlying representation. The mathematical properties don't know about the sign bit, per se.

[ColinWright → lmm]

Ah, that's news to me - can you provide a reference? I'm trying to look it up but my Google-fu is failing to find a specific link. Thanks.

[notaddicted → ColinWright]

That's not the behaviour I'm seeing on my machine. (http://codepad.org/rlLuB5VF) ... but, if you subtract zero from zero the sign depends on the order: http://codepad.org/g9LzZWPd .

[VMG → ColinWright]

This paper is referenced in a newsgroup discussion: http://dl.acm.org/citation.cfm?id=156301.156303

http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.funct...

[ColinWright → VMG]

So quoting from the discussion:

    Oh, of course: for non-NaNs, correctly implemented IEEE
    arithmetic is "exactly rounded". So addition of non-NaNs
    must be commutative for any given rounding rule, ...

[pascal_cuoq → lmm]

(-0.) + (+0.) and (+0.) + (-0.) both evaluate to +0., as any compiler should readily confirm.

[stephencanon → pascal_cuoq]

N.B.: Except in round-to-minus-infinity, in which case they evaluate to -0.

[T-hawk → pascal_cuoq]

Is the compiler calculating that at compile time based on the lexical tokens, or at runtime with native CPU floating point instructions? That absolutely matters.