[
https://issues.apache.org/jira/browse/DRILL-5094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716927#comment-15716927
]
Chunhui Shi commented on DRILL-5094:
------------------------------------
Yes. We don't need to optimize so hard here. The reason it is this way because
I actually started from reading Long.compare and other stuff (Comparator,
TimSort) in JDK first. Then I considered directly implementing compare method
here will reduce one function call and I could do the comparison and evaluation
in the order I prefer(>, <, ==)... So here it is the fix.
I agree that considering complete picture, the gain is not that much in
percentage perspective. But if we keep the fix this way, we also lose nothing.
Do you agree? :-) Thanks for the review so I got the chance to extract the
thoughts swiftly came to my mind when I coded this fix!
> Assure Comparator to be transitive
> ----------------------------------
>
> Key: DRILL-5094
> URL: https://issues.apache.org/jira/browse/DRILL-5094
> Project: Apache Drill
> Issue Type: Bug
> Reporter: Chunhui Shi
> Assignee: Chunhui Shi
> Priority: Critical
> Labels: ready-to-commit
>
> In AssignmentCreator.java, one Comparator could break transitive attribute
> required for a Comparator implementation and the result is not correct.
> E.g. for:
> long IntPlusOne = 0x80000000L;
> [0]=2 * IntPlusOne + 5, [1] = 2* IntPlusOne + 8, [2] = 4 * IntPlusOne + 4,
> the compare results will be like:
> compare([0],[1]) = -3,
> compare([1],[2]) = 4,
> compare([0],[2]) = 1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
