-
Notifications
You must be signed in to change notification settings - Fork 447
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
chore: change simp default to decide := false #2722
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
the
WIP
This is work in progress, and only a PR for the sake of CI or sharing. No review yet.
label
Oct 20, 2023
awaiting-review |
github-actions
bot
added
awaiting-review
Waiting for someone to review the PR
toolchain-available
A toolchain is available for this PR, at leanprover/lean4-pr-releases:pr-release-NNNN
and removed
WIP
This is work in progress, and only a PR for the sake of CI or sharing. No review yet.
labels
Oct 20, 2023
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/mathlib4
that referenced
this pull request
Oct 20, 2023
leanprover-community-mathlib4-bot
added
the
breaks-mathlib
This is not necessarily a blocker for merging: but there needs to be a plan
label
Oct 20, 2023
|
This was referenced Oct 21, 2023
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/mathlib4
that referenced
this pull request
Oct 22, 2023
collares
pushed a commit
to leanprover-community/mathlib4
that referenced
this pull request
Oct 22, 2023
3 tasks
So close! Mathlib builds, just some tests failing. :-) Please ping me when Mathlib builds! |
leanprover-community-mathlib4-bot
added
builds-mathlib
CI has verified that Mathlib builds against this PR
and removed
breaks-mathlib
This is not necessarily a blocker for merging: but there needs to be a plan
labels
Oct 23, 2023
kim-em
reviewed
Oct 23, 2023
kim-em
reviewed
Oct 23, 2023
kim-em
reviewed
Oct 23, 2023
collares
force-pushed
the
simp-decide
branch
2 times, most recently
from
October 23, 2023 08:12
a5ce211
to
47a2cb0
Compare
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/mathlib4
that referenced
this pull request
Oct 23, 2023
leodemoura
added
the
needs-update-stage0
stage 0 should be updated after merging this PR
label
Oct 23, 2023
Could you please add a line to |
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/mathlib4
that referenced
this pull request
Oct 26, 2023
leanprover-community-mathlib4-bot
added
breaks-mathlib
This is not necessarily a blocker for merging: but there needs to be a plan
and removed
builds-mathlib
CI has verified that Mathlib builds against this PR
labels
Oct 26, 2023
leanprover-community-mathlib4-bot
added
the
builds-mathlib
CI has verified that Mathlib builds against this PR
label
Oct 31, 2023
Fix for below warning in GitHub Actions. ``` Web Assembly The following actions uses node12 which is deprecated and will be forced to run on node16: mymindstorm/setup-emsdk@v11. For more info: https://github.blog/changelog/2023-06-13-github-actions-all-actions-will-run-on-node16-instead-of-node12-by-default/ ```
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/mathlib4
that referenced
this pull request
Nov 1, 2023
leanprover-community-mathlib4-bot
added
breaks-mathlib
This is not necessarily a blocker for merging: but there needs to be a plan
builds-mathlib
CI has verified that Mathlib builds against this PR
and removed
builds-mathlib
CI has verified that Mathlib builds against this PR
breaks-mathlib
This is not necessarily a blocker for merging: but there needs to be a plan
labels
Nov 3, 2023
leodemoura
added a commit
that referenced
this pull request
Nov 3, 2023
`simp` was previously swallowing runtime exceptions and masking an issue with this example. `runT` is defined by well-founded recursion, but reducing the ground term `runT x` takes a long time when `decide := true`. Remark PR #2722 changes the `decide` default value to `false`. When `decide := true`, we should probably have better diagnostics / error messages for this kind of situation.
leanprover-community-mathlib4-bot
added
breaks-mathlib
This is not necessarily a blocker for merging: but there needs to be a plan
builds-mathlib
CI has verified that Mathlib builds against this PR
and removed
builds-mathlib
CI has verified that Mathlib builds against this PR
breaks-mathlib
This is not necessarily a blocker for merging: but there needs to be a plan
labels
Nov 4, 2023
mathlib-bors bot
pushed a commit
to leanprover-community/mathlib4
that referenced
this pull request
Nov 17, 2023
# PR contents This is the supremum of - #8284 - #8056 - #8023 - #8332 - #8226 (already approved) - #7834 (already approved) along with some minor fixes from failures on nightly-testing as Mathlib `master` is merged into it. Note that some PRs for changes that are already compatible with the current toolchain and will be necessary have already been split out: #8380. I am hopeful that in future we will be able to progressively merge adaptation PRs into a `bump/v4.X.0` branch, so we never end up with a "big merge" like this. However one of these adaptation PRs (#8056) predates my new scheme for combined CI, and it wasn't possible to keep that PR viable in the meantime. # Lean PRs involved in this bump In particular this includes adjustments for the Lean PRs * leanprover/lean4#2778 * leanprover/lean4#2790 * leanprover/lean4#2783 * leanprover/lean4#2825 * leanprover/lean4#2722 ## leanprover/lean4#2778 We can get rid of all the ``` local macro_rules | `($x ^ $y) => `(HPow.hPow $x $y) -- Porting note: See issue lean4#2220 ``` macros across Mathlib (and in any projects that want to write natural number powers of reals). ## leanprover/lean4#2722 Changes the default behaviour of `simp` to `(config := {decide := false})`. This makes `simp` (and consequentially `norm_num`) less powerful, but also more consistent, and less likely to blow up in long failures. This requires a variety of changes: changing some previously by `simp` or `norm_num` to `decide` or `rfl`, or adding `(config := {decide := true})`. ## leanprover/lean4#2783 This changed the behaviour of `simp` so that `simp [f]` will only unfold "fully applied" occurrences of `f`. The old behaviour can be recovered with `simp (config := { unfoldPartialApp := true })`. We may in future add a syntax for this, e.g. `simp [!f]`; please provide feedback! In the meantime, we have made the following changes: * switching to using explicit lemmas that have the intended level of application * `(config := { unfoldPartialApp := true })` in some places, to recover the old behaviour * Using `@[eqns]` to manually adjust the equation lemmas for a particular definition, recovering the old behaviour just for that definition. See #8371, where we do this for `Function.comp` and `Function.flip`. This change in Lean may require further changes down the line (e.g. adding the `!f` syntax, and/or upstreaming the special treatment for `Function.comp` and `Function.flip`, and/or removing this special treatment). Please keep an open and skeptical mind about these changes! Co-authored-by: leanprover-community-mathlib4-bot <[email protected]> Co-authored-by: Scott Morrison <[email protected]> Co-authored-by: Eric Wieser <[email protected]> Co-authored-by: Mauricio Collares <[email protected]>
mathlib-bors bot
pushed a commit
to leanprover-community/mathlib4
that referenced
this pull request
Nov 17, 2023
# PR contents This is the supremum of - #8284 - #8056 - #8023 - #8332 - #8226 (already approved) - #7834 (already approved) along with some minor fixes from failures on nightly-testing as Mathlib `master` is merged into it. Note that some PRs for changes that are already compatible with the current toolchain and will be necessary have already been split out: #8380. I am hopeful that in future we will be able to progressively merge adaptation PRs into a `bump/v4.X.0` branch, so we never end up with a "big merge" like this. However one of these adaptation PRs (#8056) predates my new scheme for combined CI, and it wasn't possible to keep that PR viable in the meantime. # Lean PRs involved in this bump In particular this includes adjustments for the Lean PRs * leanprover/lean4#2778 * leanprover/lean4#2790 * leanprover/lean4#2783 * leanprover/lean4#2825 * leanprover/lean4#2722 ## leanprover/lean4#2778 We can get rid of all the ``` local macro_rules | `($x ^ $y) => `(HPow.hPow $x $y) -- Porting note: See issue lean4#2220 ``` macros across Mathlib (and in any projects that want to write natural number powers of reals). ## leanprover/lean4#2722 Changes the default behaviour of `simp` to `(config := {decide := false})`. This makes `simp` (and consequentially `norm_num`) less powerful, but also more consistent, and less likely to blow up in long failures. This requires a variety of changes: changing some previously by `simp` or `norm_num` to `decide` or `rfl`, or adding `(config := {decide := true})`. ## leanprover/lean4#2783 This changed the behaviour of `simp` so that `simp [f]` will only unfold "fully applied" occurrences of `f`. The old behaviour can be recovered with `simp (config := { unfoldPartialApp := true })`. We may in future add a syntax for this, e.g. `simp [!f]`; please provide feedback! In the meantime, we have made the following changes: * switching to using explicit lemmas that have the intended level of application * `(config := { unfoldPartialApp := true })` in some places, to recover the old behaviour * Using `@[eqns]` to manually adjust the equation lemmas for a particular definition, recovering the old behaviour just for that definition. See #8371, where we do this for `Function.comp` and `Function.flip`. This change in Lean may require further changes down the line (e.g. adding the `!f` syntax, and/or upstreaming the special treatment for `Function.comp` and `Function.flip`, and/or removing this special treatment). Please keep an open and skeptical mind about these changes! Co-authored-by: leanprover-community-mathlib4-bot <[email protected]> Co-authored-by: Scott Morrison <[email protected]> Co-authored-by: Eric Wieser <[email protected]> Co-authored-by: Mauricio Collares <[email protected]>
alexkeizer
pushed a commit
to leanprover-community/mathlib4
that referenced
this pull request
Nov 17, 2023
# PR contents This is the supremum of - #8284 - #8056 - #8023 - #8332 - #8226 (already approved) - #7834 (already approved) along with some minor fixes from failures on nightly-testing as Mathlib `master` is merged into it. Note that some PRs for changes that are already compatible with the current toolchain and will be necessary have already been split out: #8380. I am hopeful that in future we will be able to progressively merge adaptation PRs into a `bump/v4.X.0` branch, so we never end up with a "big merge" like this. However one of these adaptation PRs (#8056) predates my new scheme for combined CI, and it wasn't possible to keep that PR viable in the meantime. # Lean PRs involved in this bump In particular this includes adjustments for the Lean PRs * leanprover/lean4#2778 * leanprover/lean4#2790 * leanprover/lean4#2783 * leanprover/lean4#2825 * leanprover/lean4#2722 ## leanprover/lean4#2778 We can get rid of all the ``` local macro_rules | `($x ^ $y) => `(HPow.hPow $x $y) -- Porting note: See issue lean4#2220 ``` macros across Mathlib (and in any projects that want to write natural number powers of reals). ## leanprover/lean4#2722 Changes the default behaviour of `simp` to `(config := {decide := false})`. This makes `simp` (and consequentially `norm_num`) less powerful, but also more consistent, and less likely to blow up in long failures. This requires a variety of changes: changing some previously by `simp` or `norm_num` to `decide` or `rfl`, or adding `(config := {decide := true})`. ## leanprover/lean4#2783 This changed the behaviour of `simp` so that `simp [f]` will only unfold "fully applied" occurrences of `f`. The old behaviour can be recovered with `simp (config := { unfoldPartialApp := true })`. We may in future add a syntax for this, e.g. `simp [!f]`; please provide feedback! In the meantime, we have made the following changes: * switching to using explicit lemmas that have the intended level of application * `(config := { unfoldPartialApp := true })` in some places, to recover the old behaviour * Using `@[eqns]` to manually adjust the equation lemmas for a particular definition, recovering the old behaviour just for that definition. See #8371, where we do this for `Function.comp` and `Function.flip`. This change in Lean may require further changes down the line (e.g. adding the `!f` syntax, and/or upstreaming the special treatment for `Function.comp` and `Function.flip`, and/or removing this special treatment). Please keep an open and skeptical mind about these changes! Co-authored-by: leanprover-community-mathlib4-bot <[email protected]> Co-authored-by: Scott Morrison <[email protected]> Co-authored-by: Eric Wieser <[email protected]> Co-authored-by: Mauricio Collares <[email protected]>
arthur-adjedj
pushed a commit
to arthur-adjedj/lean4
that referenced
this pull request
Nov 20, 2023
arthur-adjedj
pushed a commit
to arthur-adjedj/lean4
that referenced
this pull request
Nov 20, 2023
`simp` was previously swallowing runtime exceptions and masking an issue with this example. `runT` is defined by well-founded recursion, but reducing the ground term `runT x` takes a long time when `decide := true`. Remark PR leanprover#2722 changes the `decide` default value to `false`. When `decide := true`, we should probably have better diagnostics / error messages for this kind of situation.
alexkeizer
pushed a commit
to leanprover-community/mathlib4
that referenced
this pull request
Nov 21, 2023
This is the supremum of - #8284 - #8056 - #8023 - #8332 - #8226 (already approved) - #7834 (already approved) along with some minor fixes from failures on nightly-testing as Mathlib `master` is merged into it. Note that some PRs for changes that are already compatible with the current toolchain and will be necessary have already been split out: #8380. I am hopeful that in future we will be able to progressively merge adaptation PRs into a `bump/v4.X.0` branch, so we never end up with a "big merge" like this. However one of these adaptation PRs (#8056) predates my new scheme for combined CI, and it wasn't possible to keep that PR viable in the meantime. In particular this includes adjustments for the Lean PRs * leanprover/lean4#2778 * leanprover/lean4#2790 * leanprover/lean4#2783 * leanprover/lean4#2825 * leanprover/lean4#2722 We can get rid of all the ``` local macro_rules | `($x ^ $y) => `(HPow.hPow $x $y) -- Porting note: See issue lean4#2220 ``` macros across Mathlib (and in any projects that want to write natural number powers of reals). Changes the default behaviour of `simp` to `(config := {decide := false})`. This makes `simp` (and consequentially `norm_num`) less powerful, but also more consistent, and less likely to blow up in long failures. This requires a variety of changes: changing some previously by `simp` or `norm_num` to `decide` or `rfl`, or adding `(config := {decide := true})`. This changed the behaviour of `simp` so that `simp [f]` will only unfold "fully applied" occurrences of `f`. The old behaviour can be recovered with `simp (config := { unfoldPartialApp := true })`. We may in future add a syntax for this, e.g. `simp [!f]`; please provide feedback! In the meantime, we have made the following changes: * switching to using explicit lemmas that have the intended level of application * `(config := { unfoldPartialApp := true })` in some places, to recover the old behaviour * Using `@[eqns]` to manually adjust the equation lemmas for a particular definition, recovering the old behaviour just for that definition. See #8371, where we do this for `Function.comp` and `Function.flip`. This change in Lean may require further changes down the line (e.g. adding the `!f` syntax, and/or upstreaming the special treatment for `Function.comp` and `Function.flip`, and/or removing this special treatment). Please keep an open and skeptical mind about these changes! Co-authored-by: leanprover-community-mathlib4-bot <[email protected]> Co-authored-by: Scott Morrison <[email protected]> Co-authored-by: Eric Wieser <[email protected]> Co-authored-by: Mauricio Collares <[email protected]>
grunweg
pushed a commit
to leanprover-community/mathlib4
that referenced
this pull request
Dec 15, 2023
# PR contents This is the supremum of - #8284 - #8056 - #8023 - #8332 - #8226 (already approved) - #7834 (already approved) along with some minor fixes from failures on nightly-testing as Mathlib `master` is merged into it. Note that some PRs for changes that are already compatible with the current toolchain and will be necessary have already been split out: #8380. I am hopeful that in future we will be able to progressively merge adaptation PRs into a `bump/v4.X.0` branch, so we never end up with a "big merge" like this. However one of these adaptation PRs (#8056) predates my new scheme for combined CI, and it wasn't possible to keep that PR viable in the meantime. # Lean PRs involved in this bump In particular this includes adjustments for the Lean PRs * leanprover/lean4#2778 * leanprover/lean4#2790 * leanprover/lean4#2783 * leanprover/lean4#2825 * leanprover/lean4#2722 ## leanprover/lean4#2778 We can get rid of all the ``` local macro_rules | `($x ^ $y) => `(HPow.hPow $x $y) -- Porting note: See issue lean4#2220 ``` macros across Mathlib (and in any projects that want to write natural number powers of reals). ## leanprover/lean4#2722 Changes the default behaviour of `simp` to `(config := {decide := false})`. This makes `simp` (and consequentially `norm_num`) less powerful, but also more consistent, and less likely to blow up in long failures. This requires a variety of changes: changing some previously by `simp` or `norm_num` to `decide` or `rfl`, or adding `(config := {decide := true})`. ## leanprover/lean4#2783 This changed the behaviour of `simp` so that `simp [f]` will only unfold "fully applied" occurrences of `f`. The old behaviour can be recovered with `simp (config := { unfoldPartialApp := true })`. We may in future add a syntax for this, e.g. `simp [!f]`; please provide feedback! In the meantime, we have made the following changes: * switching to using explicit lemmas that have the intended level of application * `(config := { unfoldPartialApp := true })` in some places, to recover the old behaviour * Using `@[eqns]` to manually adjust the equation lemmas for a particular definition, recovering the old behaviour just for that definition. See #8371, where we do this for `Function.comp` and `Function.flip`. This change in Lean may require further changes down the line (e.g. adding the `!f` syntax, and/or upstreaming the special treatment for `Function.comp` and `Function.flip`, and/or removing this special treatment). Please keep an open and skeptical mind about these changes! Co-authored-by: leanprover-community-mathlib4-bot <[email protected]> Co-authored-by: Scott Morrison <[email protected]> Co-authored-by: Eric Wieser <[email protected]> Co-authored-by: Mauricio Collares <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
awaiting-review
Waiting for someone to review the PR
builds-mathlib
CI has verified that Mathlib builds against this PR
needs-update-stage0
stage 0 should be updated after merging this PR
toolchain-available
A toolchain is available for this PR, at leanprover/lean4-pr-releases:pr-release-NNNN
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
External Contribution Guidelines.
This is a follow-up to #1888, which changed
dsimp
defaults but intended to changesimp
as well, and has been tried before in #2068, #2166 and #2192. I understand this was probably discussed in a dev meeting a long time ago (judging from the labels in #2068) and Scott Morrison states on Zulip that "in principle there is agreement to merge such a change". Quoting Heather Macbeth in #2068,One example which happened recently to Bhavik Mehta is quoted below.
simp
takes a long time to close the following goal because it tries and fails to use various decidability instances in Mathlib.The simp_arith changes are only needed because I couldn't figure out how to pass
config := {decide := true}
tolean4/src/Lean/Compiler/LCNF/PassManager.lean
Line 49 in 583e023