[
https://issues.apache.org/jira/browse/CALCITE-3956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17092449#comment-17092449
]
Liya Fan commented on CALCITE-3956:
-----------------------------------
[~julianhyde] Thanks a lot for your quick response.
IMO, partial order is a mathematical specification, and it is orthogonal to the
implementation details.
That is to say, we can also implement a partial order with Comparable, and it
is the return values of the {{compareTo}} method that determines if it is a
partial order or a total order.
According to the mathematical definition, a partial order is defined as one
that satisfies all the following conditions:
1. Reflexivity: a<=a for all a in S.
2. Antisymmetry: a<=b and b<=a implies a=b.
3. Transitivity: a<=b and b<=c implies a<=c.
(Please refer to https://mathworld.wolfram.com/PartialOrder.html)
With the current implementation, it is easy to create instances that violates
the above conditions, due to the problems described above (e.g. we can create
VolcanoCost objects so that a <= b and b <=a, but a != b). The root cause is
that the logic in different comparison methods is contradictive, so the
problems still exist.
> Unify comparison logic for RelOptCost
> -------------------------------------
>
> Key: CALCITE-3956
> URL: https://issues.apache.org/jira/browse/CALCITE-3956
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Liya Fan
> Assignee: Liya Fan
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, comparisons between RelOptCost objects are based on 3 methods:
> 1. {{boolean isLe(RelOptCost cost)}}
> 2. {{boolean isLt(RelOptCost cost)}}
> 3. {{boolean equals(RelOptCost cost)}}
> The 3 methods used in combination determine the relation between RelOptCost
> objects.
> There are some problems with this implementation:
> 1. Some logic is duplicate in the above methods, making it difficult to
> maintain.
> 2. To determine the relation between RelOptCost objects, we often need to
> call more than one comparison methods, leading to performance overhead.
> 3. Since the logic is spread in multiple methods, it is easy to end up with
> contradictive comparison logic, which will suprise the users. For example,
> the following assertion should hold according to common sense:
> {{if a >=b, then we have a > b or a == b}}
> However, with the current implementation of {{VolcanoCost}}, we can easily
> create instances that violate the above assertion.
> To solve the problems, we want to make {{RelOptCost}} extends the
> {{Comparable<RelOptCost>}}, so the comparison logic is unified in the
> {{compareTo}} method, which solves the above problems.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
