Ordering methods are inconsistent for Double and Float

[NthPortal]

For:

• Float.NaN
• Double.NaN
• -0.0f and 0.0f
• -0.0d and 0.0d

the following inconsistencies exist:

• Ordering.lt can return false when Ordering.compare returns a negative number
• Ordering.lteq can return false when Ordering.compare returns a negative number or 0
• Ordering.equiv can return false when Ordering.compare returns 0
• Ordering.equiv can return true when Ordering.compare returns a non-zero value
• Ordering.gteq can return false when Ordering.compare returns a positive number or 0
• Ordering.gt can return false when Ordering.compare returns a positive number

The reason for the inconsistency is that the convenience methods are overridden to use the primitive operators (<, <=, ==, >=, and > respectively), which always return false for operations where at one of the operands is NaN. However compare is implemented by java.lang.{Float, Double}.compare, for which NaN is ordered as larger than all other values. Also, the primitive operators treat -0.0 and 0.0 as equal, while java.lang.{Float, Double}.compare do not.

Ordering.min is inconsistent with compare as well; however, I'm not sure it is consistent with the other methods either. Ordering.max seems to be consistent with compare by chance.

It is possible that this behavior is intended, though counter-intuitive, but if so, it should probably be documented.

---

One result of these inconsistencies is that TraversableOnce.min and .max are non-deterministic (and wrong):

scala> import java.lang.Double.NaN
import java.lang.Double.NaN

scala> Seq(5.0, 3.0, NaN, 4.0)
res0: Seq[Double] = List(5.0, 3.0, NaN, 4.0)

scala> res0.min
res1: Double = 4.0

scala> res0.max
res2: Double = 4.0

Those methods could be fixed by using Ordering.min and .max internally, instead of .lteq and .gteq; however, they shouldn't need to.

[NthPortal]

I've discovered that the problem is worse than I originally thought, so I've updated the issue description accordingly.

[NthPortal]

As I see it, there are three options here:

1. Leave the behaviour as is, and document it.
2. Remove the overrides for the other methods.
3. Change the definitions of the other methods to agree with compare (while still having slightly less overhead than calling compare).

I am in favour of option 2, but I'm happy to make and PR changes based on any of them.

[NthPortal]

Extended testing leaves me convinced that option 3 is extremely difficult, if not impossible, to do correctly. I'm happy for someone to prove me wrong though.

[NthPortal]

I've dug up the original source of this problem, which seems to be #5104, and this commit. While the commit does make Ordering.min and Ordering.max consistent with math.min and math.max, it makes the Ordering itself internally inconsistent (in multiple ways). I opine that internal consistency is vastly more important, and the lack of it much more confusing when stumbled across.

[NthPortal]

See also scala/scala#76

[NthPortal]

I've discovered more problems caused by these inconsistencies regarding min and max on collections, and updated the description accordingly

[NthPortal]

for reference, most of the discussion happened at scala/scala#6323 and scala/scala#6410

(I'm mostly leaving this comment because I keep forgetting where they took place myself)

[NthPortal]

good catch there Seth - this is a nightmarishly bad first issue 😄

[sjrd]

IMO a new issue should be created and all messages since #10511 (comment) should be transferred to the new issue. It makes no sense to me to reopen this issue and refix it. The current issue was fixed in 2.13.0-M5 already.

[eed3si9n]

I opened #11844, so I'm closing this issue here.