Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better inequalities with integer variables #23771

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

oscargus
Copy link
Contributor

References to other Issues or PRs

Inspired by #22066 (comment)

Brief description of what is fixed or changed

Inequalities where at least one side is integer are now simplified in a better way. E.g. x < pi is turned into x <= 3.

Other comments

Release Notes

  • core
    • Inequalities with integer variables are better simplified.

@sympy-bot
Copy link

Hi, I am the SymPy bot (v167). I'm here to help you write a release notes entry. Please read the guide on how to write release notes.

Your release notes are in good order.

Here is what the release notes will look like:

  • core
    • Inequalities with integer variables are better simplified. (#23771 by @oscargus)

This will be added to https://github.com/sympy/sympy/wiki/Release-Notes-for-1.11.

Click here to see the pull request description that was parsed.
<!-- Your title above should be a short description of what
was changed. Do not include the issue number in the title. -->

#### References to other Issues or PRs
<!-- If this pull request fixes an issue, write "Fixes #NNNN" in that exact
format, e.g. "Fixes #1234" (see
https://tinyurl.com/auto-closing for more information). Also, please
write a comment on that issue linking back to this pull request once it is
open. -->

Inspired by https://github.com/sympy/sympy/issues/22066#issuecomment-1166413191

#### Brief description of what is fixed or changed

Inequalities where at least one side is integer are now simplified in a better way. E.g. x < pi is turned into x <= 3.


#### Other comments


#### Release Notes

<!-- Write the release notes for this release below between the BEGIN and END
statements. The basic format is a bulleted list with the name of the subpackage
and the release note for this PR. For example:

* solvers
  * Added a new solver for logarithmic equations.

* functions
  * Fixed a bug with log of integers.

or if no release note(s) should be included use:

NO ENTRY

See https://github.com/sympy/sympy/wiki/Writing-Release-Notes for more
information on how to write release notes. The bot will check your release
notes automatically to see if they are formatted correctly. -->

<!-- BEGIN RELEASE NOTES -->
* core
   * Inequalities with integer variables are better simplified.
<!-- END RELEASE NOTES -->

@oscargus
Copy link
Contributor Author

This needs more thinking. Currently:

n = Symbol('n', integer=True)
(Eq(n, 2) | (n>= 3)).simplify()

gives

(Eq(n, 2) | Eq(n, 3) | (n>= 4))

Which breaks a test.

@smichr
Copy link
Member

smichr commented Jul 14, 2022

Could you do the following with Or having a mix of equalities and inequalities?

  1. create a Union of Intervals with Eq(x, i) -> Interval.open(i-1,i+1), Gt(x, i) -> Interval(i+1,oo), etc...
  2. convert result back to relational Union(Interval(2,3),Interval(5,oo)).as_relational(i) and do whatever canonicalization you wish knowing that contiguous ints are now combined

r = self.reversed._eval_simplify(**kwargs)
r = r.canonical
measure = kwargs['measure']
if measure(r) < kwargs['ratio'] * measure(self):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't the recursive _eval_simplify already do this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I do not include this, the last test here will fail:

# canonical operations are not the same as simplification,
# so if there is no simplification, canonicalization will
# be done unless the measure forbids it
assert simplify(r) == r.canonical
assert simplify(r, ratio=0) != r.canonical

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I agree that it is a bit of a mess to include it everywhere...

@@ -1130,6 +1130,34 @@ def _eval_fuzzy_relation(cls, lhs, rhs):
def strict(self):
return Gt(*self.args)

def _eval_simplify(self, **kwargs):
# standard simplify
eorg = e = super()._eval_simplify(**kwargs)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this really necessary? What is the superclass _eval_simplify in this case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went with the similar approach as in Equality. I'd expect Relational to be the superclass.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't notice that method existed. Any reason this logic shouldn't go there?

lhs_is_int = e.lhs.is_integer
rhs_is_int = e.rhs.is_integer
r = e
if lhs_is_int is True:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are all the cases here represented in the tests?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think so.

if lhs_is_int is True:
if rhs_is_int is True:
if e.lhs.is_number:
r = Ge(e.lhs - 1, e.rhs)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess it's subjective, but I wonder if it would be better to put use e.rhs <= e.lhs - 1 so that the number is on the right-hand side.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason is that this is a Ge to start with, so returns it like that. Then, there is a canonical call anyway further down.

@asmeurer
Copy link
Member

This seems to have let to a test failure

________________________________________________________________________________
__________ sympy/concrete/tests/test_sums_products.py:test_issue_2787 __________
Traceback (most recent call last):
  File "/home/runner/work/sympy/sympy/sympy/concrete/tests/test_sums_products.py", line 980, in test_issue_2787
    assert res == ans.subs(x, p/Abs(p - 1) <= 1)
AssertionError

@asmeurer
Copy link
Member

asmeurer commented Jul 16, 2022

I'm not a fan of the _eval_simplify method (see #19281 and #23609), but the changes here use it as well as they can. The simplifications themselves look fine, although I also wonder how well code like this would scale given other types of simplifications that we might want to do. A more general method will be needed for simplifying inequalities at some point.

@oscargus oscargus marked this pull request as draft July 19, 2022 14:02
@oscargus
Copy link
Contributor Author

A more general method will be needed for simplifying inequalities at some point.

Indeed. I see this primarily as "bounds tightening", which can be beneficial for a more general method as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants