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

[Merged by Bors] - chore: more squeeze_simps arising from linter #11259

Closed
wants to merge 2 commits into from

Conversation

adomani
Copy link
Collaborator

@adomani adomani commented Mar 9, 2024

The squeezing continues! All found by the linter at #11246.


Open in Gitpod

@adomani adomani added the awaiting-review The author would like community review of the PR label Mar 9, 2024
@urkud
Copy link
Member

urkud commented Mar 10, 2024

Thanks! 🎉
bors merge

@github-actions github-actions bot added ready-to-merge This PR has been sent to bors. and removed awaiting-review The author would like community review of the PR labels Mar 10, 2024
mathlib-bors bot pushed a commit that referenced this pull request Mar 10, 2024
The squeezing continues!  All found by the linter at #11246.
@mathlib-bors
Copy link

mathlib-bors bot commented Mar 10, 2024

Pull request successfully merged into master.

Build succeeded:

@mathlib-bors mathlib-bors bot changed the title chore: more squeeze_simps arising from linter [Merged by Bors] - chore: more squeeze_simps arising from linter Mar 10, 2024
@mathlib-bors mathlib-bors bot closed this Mar 10, 2024
@mathlib-bors mathlib-bors bot deleted the adomani/squeeze_simps branch March 10, 2024 17:43
kbuzzard pushed a commit that referenced this pull request Mar 12, 2024
The squeezing continues!  All found by the linter at #11246.
Copy link
Collaborator

@YaelDillies YaelDillies left a comment

Choose a reason for hiding this comment

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

Would you mind opening a PR addressing my comments?

Comment on lines +117 to 118
· simp only [zpow_negSucc, conj_pow, mul_inv_rev, inv_inv]
rw [mul_assoc]
Copy link
Collaborator

Choose a reason for hiding this comment

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

Make the proof more robust by not squeezing the simp:

Suggested change
· simp only [zpow_negSucc, conj_pow, mul_inv_rev, inv_inv]
rw [mul_assoc]
· simp [zpow_negSucc, conj_pow, mul_assoc]

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Done.

Comment on lines +181 to 182
· simp only [foldr_cons, ih, cons_bind, append_assoc]
rw [← permutationsAux2_append]
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
· simp only [foldr_cons, ih, cons_bind, append_assoc]
rw [← permutationsAux2_append]
· simp [ih, ← permutationsAux2_append]

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This says

tactic 'simp' failed, nested error:
maximum recursion depth has been reached (use `set_option maxRecDepth <num>` to increase limit)

Comment on lines -313 to -314
· simp at h
simp [*]
Copy link
Collaborator

Choose a reason for hiding this comment

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

Sure that's a golf, but please reassure me that your linter does not flag this as a non-terminal simp!

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I am still working on the internal mechanics of the linter. The first simp was indeed flagged, but a newer version of the linter will hopefully be aware of the tactic immediately following a simp and will use this information to decide whether a simp is considered terminal or not. So,

  • I will not revert this change,
  • I agree with you that this should not have been flagged,
  • I do think that the current version is more robust than what it was before, though!

😄

@@ -1157,7 +1159,7 @@ theorem liftRel_flatten {R : α → β → Prop} {c1 : Computation (WSeq α)} {c
match s, t, h with
| _, _, ⟨c1, c2, rfl, rfl, h⟩ => by
-- Porting note: `exists_and_left` should be excluded.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
-- Porting note: `exists_and_left` should be excluded.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Removed the note.

Comment on lines +1334 to +1339
destruct_eq_think <| by
unfold toList
simp only [toList'_cons, Computation.destruct_think, Sum.inr.injEq]
rw [toList'_map]
simp only [List.reverse_cons, List.reverse_nil, List.nil_append, List.singleton_append]
rfl
Copy link
Collaborator

Choose a reason for hiding this comment

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

This looks like a symptom of the simp bug that was fixed by letting simp not resynthesize everything anymore. Hence I'm pretty sure something like this will work:

Suggested change
destruct_eq_think <| by
unfold toList
simp only [toList'_cons, Computation.destruct_think, Sum.inr.injEq]
rw [toList'_map]
simp only [List.reverse_cons, List.reverse_nil, List.nil_append, List.singleton_append]
rfl
destruct_eq_think <| by unfold toList; simp [toList'_map]; rfl

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Literally what you suggest gives

type mismatch
  HEq.rfl
has type
  HEq ?m.129498 ?m.129498 : Prop
but is expected to have type
  Computation.destruct (toList (cons a s)) = Sum.inr (List.cons a <$> toList s) : Prop

I could not find a better proof...

Comment on lines -1359 to +1367
simp [head]; cases Seq.head s <;> rfl
simp only [head, Option.map_eq_map, destruct_ofSeq, Computation.map_pure, Option.map_map]
cases Seq.head s <;> rfl
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm honestly not sure this kind of changes is an improvement

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I reverted this change.

Comment on lines +39 to +42
| _, _, _, _, _, σh, ⟨rfl⟩, ⟨rfl⟩, h => ⟨by
simp only [Nat.cast_id, σh, Rat.ofScientific_false_def, Nat.cast_mul, Nat.cast_pow,
Nat.cast_ofNat, h, Nat.mul_eq]
norm_cast⟩
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is a false positive. norm_cast is a simp-like tactic, hence the simp is not terminal. Please revert.

Copy link
Collaborator Author

@adomani adomani left a comment

Choose a reason for hiding this comment

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

@YaelDillies I addressed the comments that I could in #11455.

Comment on lines +181 to 182
· simp only [foldr_cons, ih, cons_bind, append_assoc]
rw [← permutationsAux2_append]
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This says

tactic 'simp' failed, nested error:
maximum recursion depth has been reached (use `set_option maxRecDepth <num>` to increase limit)

Comment on lines -313 to -314
· simp at h
simp [*]
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I am still working on the internal mechanics of the linter. The first simp was indeed flagged, but a newer version of the linter will hopefully be aware of the tactic immediately following a simp and will use this information to decide whether a simp is considered terminal or not. So,

  • I will not revert this change,
  • I agree with you that this should not have been flagged,
  • I do think that the current version is more robust than what it was before, though!

😄

@@ -1157,7 +1159,7 @@ theorem liftRel_flatten {R : α → β → Prop} {c1 : Computation (WSeq α)} {c
match s, t, h with
| _, _, ⟨c1, c2, rfl, rfl, h⟩ => by
-- Porting note: `exists_and_left` should be excluded.
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Removed the note.

Comment on lines +1334 to +1339
destruct_eq_think <| by
unfold toList
simp only [toList'_cons, Computation.destruct_think, Sum.inr.injEq]
rw [toList'_map]
simp only [List.reverse_cons, List.reverse_nil, List.nil_append, List.singleton_append]
rfl
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Literally what you suggest gives

type mismatch
  HEq.rfl
has type
  HEq ?m.129498 ?m.129498 : Prop
but is expected to have type
  Computation.destruct (toList (cons a s)) = Sum.inr (List.cons a <$> toList s) : Prop

I could not find a better proof...

Comment on lines -1359 to +1367
simp [head]; cases Seq.head s <;> rfl
simp only [head, Option.map_eq_map, destruct_ofSeq, Computation.map_pure, Option.map_map]
cases Seq.head s <;> rfl
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I reverted this change.

Comment on lines +117 to 118
· simp only [zpow_negSucc, conj_pow, mul_inv_rev, inv_inv]
rw [mul_assoc]
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Done.

dagurtomas pushed a commit that referenced this pull request Mar 22, 2024
The squeezing continues!  All found by the linter at #11246.
utensil pushed a commit that referenced this pull request Mar 26, 2024
The squeezing continues!  All found by the linter at #11246.
Louddy pushed a commit that referenced this pull request Apr 15, 2024
The squeezing continues!  All found by the linter at #11246.
uniwuni pushed a commit that referenced this pull request Apr 19, 2024
The squeezing continues!  All found by the linter at #11246.
callesonne pushed a commit that referenced this pull request Apr 22, 2024
The squeezing continues!  All found by the linter at #11246.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready-to-merge This PR has been sent to bors.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants