You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Julian Hyde (JIRA)" <ji...@apache.org> on 2018/10/08 19:22:02 UTC
[jira] [Created] (CALCITE-2615) When simplifying OR, RexSimplify
incorrectly applies predicates deduced for operands to the same operands
Julian Hyde created CALCITE-2615:
------------------------------------
Summary: When simplifying OR, RexSimplify incorrectly applies predicates deduced for operands to the same operands
Key: CALCITE-2615
URL: https://issues.apache.org/jira/browse/CALCITE-2615
Project: Calcite
Issue Type: Task
Reporter: Julian Hyde
Assignee: Julian Hyde
When simplifying NOT AND, RexSimplify incorrectly applies predicates deduced for operands to the same operands.
Here is the test case (add it to RexProgramTest):
{code}
@Test public void testSimplifyNotAnd() {
final RexNode e = not(
and(
gt(and(vBool(1), literal(true)),
or(literal(true), literal(true), literal(false))),
gt(isNotNull(vBool(0)), eq(literal(false), vBool(1))),
or(ne(literal(true), literal(false)),
ge(vInt(0), literal((Integer) null)))));
final String expected = "TODO";
checkSimplify(e, expected);
}
{code}
When you run it, verify will find a combination of assignments such that the simplified expression returns a different result than the original.
The test case is not minimal; sorry.
The bug is in [RexSimplify.simplifyAndTerms|https://github.com/apache/calcite/blob/6b3844c0634792263a5073b8ea93565fb3415f41/core/src/main/java/org/apache/calcite/rex/RexSimplify.java#L412]. Put a breakpoint at that line to see the problem. It passes through the operands once, building a list of predicates. Then it passes through the operands again, simplifying each operand. Thus operand1 is simplified using a list of predicates that includes the predicate 'not operand1'. Clearly wrong. [~kgyrtkirk], I warned that this was possible in our discussions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)