WAT: opCmp and opEquals woes

[Fool via Digitalmars-d]

On Saturday, 26 July 2014 at 13:25:06 UTC, Ola Fosheim Grøstad 
wrote:
> On Saturday, 26 July 2014 at 10:22:54 UTC, Fool wrote:
>> It needs to be defined what kind of relation opCmp is meant to 
>> model.
>>
>> If it's concept is a partial order, opEquals cannot be 
>> inferred.
>>
>> If it's concept is a strict weak ordering [1, 2], which is 
>> required for sorting, opEqual can be inferred.
>
> I don't think so.
>
> NaN < x is false
> NaN > x is false

...which means that < as it is usually defined on floating point 
numbers does not define a strict weak ordering.

This suggests that opCmp should not be required to model a 
(strict) weak ordering. On the other hand this means that sorting 
is not defined by opCmp.

The last fact is documented at 
http://dlang.org/phobos/std_algorithm.html#sort


> if you try to derive equality from that you would get:
>
> NaN == x is true

This is not a contradiction to what I wrote.


> For sorting you are obviously better off defining NaN as in a 
> manner that is consistent with the other values of the type. 
> E.g. preceding all other float values.

...which means that you are extending the partial order to a 
particular total order.