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

Top level constraint evaluation #547

Open
niklasdewally opened this issue Dec 7, 2024 · 4 comments
Open

Top level constraint evaluation #547

niklasdewally opened this issue Dec 7, 2024 · 4 comments
Labels
area::conjure-oxide/rule-engine Related to the rule engine and the expression rewriting logic. kind::feature New feature or request

Comments

@niklasdewally
Copy link
Collaborator

Now that constraints are a vector at the top level (#435), top level constraints are no longer being simplified as ands.

For example, savilerow/divide-mod-novar evaluates to:

true,
true,
true,
true,
true,
true,
true,
true,

We expect this to become

true

At the very least, we would want to do a total evaluation pass on this so that trivially true/false models can be identified.

In the future, we will be able to solve trivially true or false models without ever involving the solver.

@niklasdewally niklasdewally changed the title Top level boolean simplification Top level constraint evaluation Dec 7, 2024
@niklasdewally niklasdewally added area::conjure-oxide/rule-engine Related to the rule engine and the expression rewriting logic. kind::feature New feature or request labels Dec 7, 2024
@ozgurakgun
Copy link
Contributor

In fact, and @YehorBoiar might hate me for this, but this is quite a good argument for saving a single Expr in the model...

Or maybe an Option<Expr> to make sure we aren't making up adhoc empty expressions.

@niklasdewally
Copy link
Collaborator Author

In fact, and @YehorBoiar might hate me for this, but this is quite a good argument for saving a single Expr in the model...

Or maybe an Option<Expr> to make sure we aren't making up adhoc empty expressions.

As a reminder, what motivated us to make it a vector in the first place?

@YehorBoiar
Copy link
Contributor

YehorBoiar commented Dec 10, 2024

@niklasdewally Issue #421 was the motivation behind it

@ozgurakgun I don't really mind. Felix did mention that it could be not a good idea, and I was ready to be having to rewrite that whole thing once again :)
However, I'm having a break from conjure-oxide untill the new year, so I wouldn't be able to contribute to that right now.

@niklasdewally
Copy link
Collaborator Author

niklasdewally commented Dec 10, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area::conjure-oxide/rule-engine Related to the rule engine and the expression rewriting logic. kind::feature New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants