[
https://issues.apache.org/jira/browse/ARROW-14122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421849#comment-17421849
]
QP Hou commented on ARROW-14122:
--------------------------------
Awesome, looks like we have a consensus here :) +1 on making arrow interval
type unordered and introduce a totally ordered postgres interval type for
compatibility purpose.
> QP Hou, I think that the `PartialOrd` in Rust is not the same as partial
> order I referenced above. `PartialOrd` may return None when two types are not
> comparable, whereas the partial order above must always return true or false.
> However, even that is not what we want for compatibility with postgres.
I still think the ParitialOrd trait semantic matches the partial order
definition in the wiki page you linked, specially the non-strict partial order
definition. The only difference between non-strict partial order and total
order is missing of the `strongly connected` rule. Lack of strong connectivity
in plain English means an order cannot be defined for all pairs of elements
from the set, which is exactly the semantic we have for the current arrow
interval type. The antisymmetry rule starts with `if a<=b and b <=a`. The
preceding `if` means it is only applicable for a, b where an order can be
defined between them. The strong connectivity rule `a <= b or a >= b` is what
requires order to be defined for any two pairs of elements from the set.
However, I don't think this changes our conclusion :) As I mentioned in my
first comment and [~cpcloud] mentioned in his second comment, a correctly
defined partial order for the arrow interval type can be very confusing to our
end users. Partial order is useful for floating point number because it is only
NaN that cannot have order defined, so the set of unordered elements is very
sparse. While for arrow's interval type, the set of unordered elements is very
dense. This makes the partial order relation not very useful in practice. Most
of the time you will still need to convert it to timestamp or duration with a
reference point. So we might as well not define an order for it.
> Do we need a new JIRA/set of JIRAs to track the work of adding the extension
> type?
I think this is best tracked as a separate ticket and link to this one.
> [C++] interval comparison kernels
> ---------------------------------
>
> Key: ARROW-14122
> URL: https://issues.apache.org/jira/browse/ARROW-14122
> Project: Apache Arrow
> Issue Type: Sub-task
> Reporter: Phillip Cloud
> Priority: Major
> Labels: kernel
>
> Subtask for tracking interval comparison kernels
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
