Support n-ary monotonic functions in discover_new_orderings

[gokselk]

Which issue does this PR close?

Closes #.

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

[berkaysynnada]

I'm sorry for the delayed response @gokselk. I had to deal with some urgent maintenance issues. The refactor looks promising overall, but I noticed some issues in the tests that indicate potential bugs.

In your first test, the table is ordered as [a+b, a, b], and you add the equality c = a + b. This results in new orderings of [a+b] and [a, b]. I believe this is incorrect—you can find a simple counter-example if this isn’t immediately clear. The initial orderings should remain unchanged (or potentially be updated to [c, a, b] but this is not our concern).

The correct test case should be as follows: start with an initial ordering of [c, a, b], then add the equality c = a + b. The final orderings should then be [c] and [a, b]. I tested this scenario with your implementation, and it works as expected (it does not work without your refactor). However, the current test should not pass, as the implementation seems to perform unintended simplifications. You need to identify and address this bug.

Once that’s fixed, it would be beneficial to add more scenarios. Consider using ScalarFunctionExpr's as PhysicalExpr to represent different mathematical functions.

[berkaysynnada]

You also need to resolve the conflicts coming from upstream to your branch.

[gokselk]

In your first test, the table is ordered as [a+b, a, b], and you add the equality c = a + b. This results in new orderings of [a+b] and [a, b]. I believe this is incorrect—you can find a simple counter-example if this isn’t immediately clear. The initial orderings should remain unchanged (or potentially be updated to [c, a, b] but this is not our concern).

The correct test case should be as follows: start with an initial ordering of [c, a, b], then add the equality c = a + b. The final orderings should then be [c] and [a, b]. I tested this scenario with your implementation, and it works as expected (it does not work without your refactor). However, the current test should not pass, as the implementation seems to perform unintended simplifications. You need to identify and address this bug.

Thanks for catching this. I agree the original test case was incorrect. I'm debugging the unintended simplification behavior with the ordering [a+b, a, b]. Will update once I identify and fix the issue.

For now, I've updated the test to use the correct case: [c, a, b] -> [c] and [a, b].

[gokselk]

@berkaysynnada I've pushed a potential fix that avoids unintended simplification by skipping cases where the original ordering starts with the equivalent expression.

However, I'm not entirely confident about this approach and would appreciate your review on whether this is the right way to handle these cases.