[
https://issues.apache.org/jira/browse/CALCITE-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17265132#comment-17265132
]
Julian Hyde commented on CALCITE-4467:
--------------------------------------
No one has yet convinced me that these should be Calcite's default semantics.
And if these are not the current, default, semantics, then you are proposing to
add a new mode. That requires a significant amount of testing.
bq. are there other simplifications that come to your mind
If NaN does not equal itself, then the law of the excluded middle kicks in. You
can no longer assume that 'x = x or x <>' is true. Which is exactly what makes
NULL so troublesome.
I could come up with examples, that you could then refute, but the onus should
be on you to show why simplifying in the presence of NaN is not as hard as
simplifying in the presence of NULL. Which, as we know, is hard.
> Incorrect simplification for 'NaN' value
> ----------------------------------------
>
> Key: CALCITE-4467
> URL: https://issues.apache.org/jira/browse/CALCITE-4467
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Jesus Camacho Rodriguez
> Assignee: Jesus Camacho Rodriguez
> Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{RexSimplify}} simplifies {{x = x}} to {{null or x is not null}} (similarly
> <= and >=), and {{x != x}} to {{null and x is null}} (similarly < and >).
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rex/RexSimplify.java#L363
> This may not be applicable in some cases. For instance, if the type of x is
> floating-point, x could be 'NaN'. While some RDBMS consider 'NaN' = 'NaN'
> (e.g., Postgres), some others consider 'NaN' != 'NaN' following the IEEE 754
> standard. For the latest, the rewriting above will result in incorrect
> results.
> I think we should simply ignore this simplification for floating-point type.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
