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)