-
Notifications
You must be signed in to change notification settings - Fork 331
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
feat(Tactic): erw
tries rw
first and warns if that succeeds
#17638
base: master
Are you sure you want to change the base?
Conversation
PR summary af3c28c713
|
File | Base Count | Head Count | Change |
---|---|---|---|
Mathlib.Tactic.Common | 244 | 246 | +2 (+0.82%) |
Mathlib.CategoryTheory.Shift.Basic | 445 | 447 | +2 (+0.45%) |
Mathlib.CategoryTheory.Limits.Shapes.Reflexive | 556 | 558 | +2 (+0.36%) |
Mathlib.Topology.Order.ScottTopology | 671 | 673 | +2 (+0.30%) |
Import changes for all files
Files | Import difference |
---|---|
There are 4319 files with changed transitive imports taking up over 182543 characters: this is too many to display! | |
You can run scripts/import_trans_difference.sh all locally to see the whole output. |
Declarations diff
No declarations were harmed in the making of this PR! 🐙
You can run this locally as follows
## summary with just the declaration names:
./scripts/declarations_diff.sh <optional_commit>
## more verbose report:
./scripts/declarations_diff.sh long <optional_commit>
The doc-module for script/declarations_diff.sh
contains some details about this script.
Thanks for this PR! I'm (perhaps needlessly so) worries about the performance effects of this change. Can you benchmark this/is the speedcenter up and working already? |
Unfortunately the speedcenter was still down yesterday, and I don't see any movement in the zulip thread. I agree that this will make Mathlib a bit slower, but the extra cost of doing a |
927ac49
to
b297481
Compare
b297481
to
18e2fdb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two nits about outdated comments - otherwise the erw -> rw
replacements look good to me. The macro looks plausible to me, but I'm not an expert on them - that's a low-confidence approval of that part.
Nicely spotted, thanks! |
Lets split this into separate PRs for changing proofs and for the macro. |
I would prefer a solution where we only run the extra check in CI, like we do for |
1c9b47b
to
edc1e5c
Compare
See #17703 for only the changed proofs. |
I'm curious about the overall balance of this PR, thus let me bench it. |
!bench |
Go through Mathlib and replace `erw` calls where `rw` would also succeed. This PR is split off from #17638, containing all the changes that the linter suggested. Co-authored-by: Anne Baanen <[email protected]>
This PR/issue depends on: |
Here are the benchmark results for commit edc1e5c. Benchmark Metric Change
================================================================================
- ~Mathlib.Algebra.Module.LocalizedModule instructions 8.2%
- ~Mathlib.CategoryTheory.Adjunction.Lifting.Right instructions 46.6%
- ~Mathlib.Geometry.RingedSpace.PresheafedSpace.Gluing instructions 15.4%
- ~Mathlib.RepresentationTheory.GroupCohomology.Resolution instructions 8.1% |
The previous PR was performance-neutral - so the benchmark should mostly represent the effect of this PR. Overall, there is a slowdown of 200*10⁹ instruction (about 0.1-0.2% of all of mathlib). |
I'll hold off on merging this PR then, running it manually every so often until the number of |
This PR adds a macro rule to the `erw` tactic that first tries `rw` at reducible transparency, and displays a "Try this:" if that succeeded. This should help us get rid of uselessly slow `erw`s. This is a relatively simple implementation that does not verify if `erw` and `rw` would have resulted in the same exact rewrite. So it is possible that `erw` and `rw` both succeed but rewrite different occurrences, and there would be a suggestion to replace `erw` with `rw` in that case. I think the complication of running both at the same time and checking the goal state afterwards doesn't weigh up to accepting that this happens and adding an explanation to the warning generated by `erw`. I import the `erw` extension in `Tactic.Common`: it might be nice to migrate this up even earlier in the import hierarchy but `Mathlib.Tactic.TryThis` is a somewhat heavy import to put in `Mathlib.Tactic.Core`.
edc1e5c
to
6f76810
Compare
6f76810
to
af3c28c
Compare
Automatically found by the `erw` linter from #17638.
The `erw` linter of #17638 spotted two `erw`s that can be turned into `rw` for free.
This PR adds a macro rule to the
erw
tactic that first triesrw
at reducible transparency, and displays a "Try this:" if that succeeded. This should help us get rid of uselessly slowerw
s.This is a relatively simple implementation that does not verify if
erw
andrw
would have resulted in the same exact rewrite. So it is possible thaterw
andrw
both succeed but rewrite different occurrences, and there would be a suggestion to replaceerw
withrw
in that case. I think the complication of running both at the same time and checking the goal state afterwards doesn't weigh up to accepting that this happens and adding an explanation to the warning generated byerw
.I import the
erw
extension inTactic.Common
: it might be nice to migrate this up even earlier in the import hierarchy butMathlib.Tactic.TryThis
is a somewhat heavy import to put inMathlib.Tactic.Core
.Zulip thread: https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/Fixing.20the.20.60erw.60.20hell.20around.20concrete.20categories
erw
withrw
where possible #17703