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