[
https://issues.apache.org/jira/browse/CALCITE-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-2615:
---------------------------------
Description:
When simplifying NOT-AND-OR, RexSimplify incorrectly applies predicates deduced
for operands to the same operands.
Here is the test case (add it to RexProgramTest):
{code:java}
@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. Maybe it reproduces with NOT-OR.
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.
was:
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.
> When simplifying NOT-AND-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
> Priority: Major
>
> When simplifying NOT-AND-OR, RexSimplify incorrectly applies predicates
> deduced for operands to the same operands.
> Here is the test case (add it to RexProgramTest):
> {code:java}
> @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. Maybe it reproduces with NOT-OR.
> 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)
