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

Added transformations for quantification over special integer sets #1431

Merged
merged 5 commits into from
Mar 4, 2022

Conversation

Kukovec
Copy link
Collaborator

@Kukovec Kukovec commented Mar 2, 2022

  • Tests added for any new code
  • Ran make fmt-fix (or had formatting run automatically on all files edited)
  • Documentation added for any new functionality
  • Entry added to UNRELEASED.md for any new functionality

First part of #1407, without the plumbing.

@codecov-commenter
Copy link

codecov-commenter commented Mar 2, 2022

Codecov Report

Merging #1431 (325b56e) into unstable (b908195) will increase coverage by 0.03%.
The diff coverage is 93.75%.

Impacted file tree graph

@@             Coverage Diff              @@
##           unstable    #1431      +/-   ##
============================================
+ Coverage     74.57%   74.61%   +0.03%     
============================================
  Files           358      359       +1     
  Lines         11357    11373      +16     
  Branches        559      542      -17     
============================================
+ Hits           8470     8486      +16     
  Misses         2887     2887              
Impacted Files Coverage Δ
...alache/tla/pp/IntegerQuantificationOptimizer.scala 93.75% <93.75%> (ø)
...he/io/annotations/parser/CommentPreprocessor.scala 93.97% <0.00%> (+1.20%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b908195...325b56e. Read the comment docs.

Copy link
Collaborator

@bugarela bugarela left a comment

Choose a reason for hiding this comment

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

LGTM, I just left some opinion/questions for the testing part.

Copy link
Contributor

@shonfeder shonfeder left a comment

Choose a reason for hiding this comment

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

A few small comments and suggestions, one one more substantive (but totally optional) suggestion about the organization of the logic in the transformation.

Comment on lines 11 to 12
* This transformation rewrites expressions of the form `(\A | \E) x \in S: P`, where S is one of `Int`, `Nat`, `a..b`,
* into `(\A | \E) x: Q` (unbounded quantification).
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this communicate that the rewriting generally moves the bounds from variable binding in the quantifier into constraints in the expression that is quantified over? iiuc, this is part of the key idea, not simply that that it produces unbounded quantification.

Comment on lines 89 to 103
test("Translation of Nat") {
val natSet = tla.natSet().as(SetT1(IntT1()))

forSetWithPredicates(Gen.const(natSet), postPredE, postPredA)
}

test("Translation of Int") {
val intSet = tla.intSet().as(SetT1(IntT1()))

forSetWithPredicates(Gen.const(intSet), postPredE, postPredA)
}

test("Translation of a..b") {
forSetWithPredicates(rangeGen, postPredE, postPredA)
}
Copy link
Contributor

Choose a reason for hiding this comment

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

What are the properties being tested for here? It's not clear to me from the names of the test. I can see that you are testing certain transformations, but it would help with readability of the tests IMO to include in the name what properties of the transformations are being checked for.

Copy link
Contributor

Choose a reason for hiding this comment

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

In my experience, the point of property based tests it to end up with something that looks like: "forall x: T. P(x)where theTis determined by generators of expressions of the appropriate type, andPis the test of what should hold of every instance ofx`. I am not really able to figure out whether that is happening in these tests in some way. Maybe after the fix discussed with Gabriela that will be clearer for me. I'll check back after those changes are int!

Copy link
Collaborator Author

@Kukovec Kukovec Mar 2, 2022

Choose a reason for hiding this comment

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

If you want the above formulation, P(ex) := transform((\E | \A) x \in S: p(ex)) = (\E | \A) x: q(ex),

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Basically, does the transformation have the expected shape for Q

Copy link
Collaborator

@thpani thpani left a comment

Choose a reason for hiding this comment

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

I like the implementation, only a few comments there.
The tests, I found rather difficult to follow. I think this can be resolved with some restructuring and renaming, see my comments inline.

*/

@Singleton
class IntegerQuantificationOptimizer(tracker: TransformationTracker) extends TlaExTransformation {
Copy link
Collaborator

Choose a reason for hiding this comment

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

General question, do we have a naming scheme for these? I see both Optimizers and Simplifiers in the codebase, is there any difference?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Not really. IMO a simplifier translates an expression into another expression that is equivalent under certain conditions and structurally simpler. An optimizer may produce a more complex expression, which nevertheless improves performance.

Copy link
Collaborator

@konnov konnov left a comment

Choose a reason for hiding this comment

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

Just a few comments, as there are good reviews already. I agree with Thomas that these transformations are not about optimizations. Maybe they are simplifications.

*/

@Singleton
class IntegerQuantificationOptimizer(tracker: TransformationTracker) extends TlaExTransformation {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Not really. IMO a simplifier translates an expression into another expression that is equivalent under certain conditions and structurally simpler. An optimizer may produce a more complex expression, which nevertheless improves performance.

Copy link
Contributor

@shonfeder shonfeder left a comment

Choose a reason for hiding this comment

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

LGTM!

Thank you for taking the time to add this feature in incrementally! :)

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

Successfully merging this pull request may close these issues.

6 participants