opCmp, [partial/total/pre]orders, custom floating point types etc.

John Colvin via Digitalmars-d digitalmars-d at puremagic.com
Tue Jan 12 12:56:41 PST 2016


On Tuesday, 12 January 2016 at 20:04:26 UTC, Andrei Alexandrescu 
wrote:
> On 01/12/2016 03:01 PM, John Colvin wrote:
>> On Tuesday, 12 January 2016 at 19:28:36 UTC, Andrei 
>> Alexandrescu wrote:
>>> On 01/12/2016 02:13 PM, John Colvin wrote:
>>>> a<=b and b<=a must also be false.
>>>
>>> Would the advice "Only use < and == for partially-ordered 
>>> data" work?
>>> -- Andrei
>>
>> If by that you mean "Only use <= or >= on data that defines a 
>> total
>> ordering"* I guess it would work, but it has some pretty big 
>> downsides:
>>
>> 1) Annoying to use.
>> 2) You have to use the opCmp return 0 (which normally means 
>> a[<>]=b &&
>> b[<>]=a) to mean "not comparable".
>> 3) Not enforceable. Because of 2 you'll always get true if you 
>> use >= or
>> <= on any a pair that doesn't have a defined ordering.
>> 4) inefficient (have to do both < and == separately which can 
>> be a lot
>> more work than <=).
>>
>> *would be safer to say "types that define", but strictly 
>> speaking...
>
> I'd be in favor of giving people the option to disable the use 
> of <= and >= for specific data. It's a simple and logical 
> approach. -- Andrei

Having thought about this a bit more, it doesn't fix the problem:

It doesn't enable custom float types that are on par with 
builtins, doesn't enable transparent "missing-value" types and 
doesn't make tsbockmans checked integer types (or other custom 
types) work properly and transparently with builtin floats. The 
points 1, 2 and 4 from above still stand. Also - the big problem 
- it requires antisymmetry, which means no preorders.

One of the great things about D's opCmp and opEquals is that it 
separates `a==b` from `a<=b && b<=a`, which enables it to express 
types without antisymmetric ordering (see original post for 
examples), what you're describing would be a frustrating 
situation where you have to choose between breaking antisymmetry 
and breaking totality, but never both.

Please consider the second design I proposed? It's small, simple, 
has no impact on existing code and works in the right direction 
(library types can emulate / act as replacements for builtins) as 
opposed to the other way (library types are second class).


More information about the Digitalmars-d mailing list