This was not a great simp lemma, and hurts simp confluence. Better to
just use it locally where it is useful.
Similarly `List.head_eq_iff_head?_eq_some`.
This PR also pulls in some mathlib theorems on testBit and Nat and establishes facts about 2^w that are needed here and which are generally useful for bitvector reasoning.
The following theorem is not generalized to arbitrary x instead of 2, as this would require a condition to be added for x > 1 which would have to be passed to simp each time this theorem should fire.
chore: derive from testBit_two_pow
chore: convert first to prop and then decide
chore: move intMax down as well
chore: add simp set
Add simp-set into this PR
chore: fix simp extension
Move file to src/Lean to fix build
Add prelude
update date
Add university of cambridge as copyright holder
improve naming
use whitespace uniformly
use decide (n = m)
Drop the 'Nat.' namespace
Update src/Init/Data/BitVec/Lemmas.lean
Co-authored-by: Siddharth <siddu.druid@gmail.com>
Update src/Init/Data/BitVec/Lemmas.lean
Co-authored-by: Siddharth <siddu.druid@gmail.com>
Fix build
add some theorems
Revert "add some theorems"
This reverts commit fb97bc2007e371854b40badb3d6014da034c1f5e.
WIP
Shorten proof
Update src/Init/Data/Nat/Lemmas.lean
finish proofs
Update src/Init/Data/BitVec/Lemmas.lean
Co-authored-by: Kim Morrison <scott@tqft.net>
Update src/Init/Data/Nat/Lemmas.lean
Co-authored-by: Kim Morrison <scott@tqft.net>
chore: move BoolToPropSimps
`simp only` will not apply this simproc anymore. Users must now write
`simp only [reduceCtorEq]`. See RFC #5046 for motivation.
This PR also renames simproc to `reduceCtorEq`.
close#5046
@semorrison A few `simp only ...` tactics will probably break in
Mathlib. Fix: include `reduceCtorEq`.
We use `no_index` to work around special-handling of `OfNat.ofNat` in
`DiscrTree`, which has been reported as an issue in
https://github.com/leanprover/lean4/issues/2867 and is currently in the
process of being fixed in https://github.com/leanprover/lean4/pull/3684.
As the potential fix seems non-trivial and might need some time to
arrive in-tree, we meanwhile add the `no_index` keyword to the
problematic subterm.
---------
Co-authored-by: Eric Wieser <wieser.eric@gmail.com>
We swap the arguments for `Membership.mem` so that when proceeded by a
`SetLike` coercion, as is often the case in Mathlib, the resulting
expression is recognized as eta expanded and reduce for many
computations. The most beneficial outcome is that the discrimination
tree keys for instances and simp lemmas concerning subsets become more
robust resulting in more efficient searches.
Closes `RFC` #4932
---------
Co-authored-by: Kim Morrison <kim@tqft.net>
Co-authored-by: Henrik Böving <hargonix@gmail.com>
This is part of #3983.
After #4154 introduced equational lemmas for non-recursive functions and
#5055
unififed the lemmas for structural and wf recursive funcitons, this now
disables the special handling of recursive functions in
`findMatchToSplit?`, so that the equational lemmas should be the same no
matter how the function was defined.
The new option `eqns.deepRecursiveSplit` can be disabled to get the old
behavior.
### Breaking change
This can break existing code, as there now can be extra equational
lemmas:
* Explicit uses of `f.eq_2` might have to be adjusted if the numbering
changed.
* Uses of `rw [f]` or `simp [f]` may no longer apply if they previously
matched (and introduced a `match` statement), when the equational
lemmas got more fine-grained.
In this case either case analysis on the parameters before rewriting
helps, or setting the option `opt.deepRecursiveSplit false` while
defining the function
Updates the user widget manual to account for more recent changes. One
issue is that the samples no longer work on https://live.lean-lang.org/
because it uses an outdated version of the `@leanprover/infoview` NPM
package. They work on https://lean.math.hhu.de/ and in recent versions
of the VSCode extension.
This is part of #3983.
Fine-grained equational lemmas are useful even for non-recursive
functions, so this adds them.
The new option `eqns.nonrecursive` can be set to `false` to have the old
behavior.
### Breaking channge
This is a breaking change: Previously, `rw [Option.map]` would rewrite
`Option.map f o` to `match o with … `. Now this rewrite will fail
because the equational lemmas require constructors here (like they do
for, say, `List.map`).
Remedies:
* Split on `o` before rewriting.
* Use `rw [Option.map.eq_def]`, which rewrites any (saturated)
application of `Option.map`
* Use `set_option eqns.nonrecursive false` when *defining* the function
in question.
### Interaction with simp
The `simp` tactic so far had a special provision for non-recursive
functions so that `simp [f]` will try to use the equational lemmas, but
will also unfold `f` else, so less breakage here (but maybe performance
improvements with functions with many cases when applied to a
constructor, as the simplifier will no longer unfold to a large
`match`-statement and then collapse it right away).
For projection functions and functions marked `[reducible]`, `simp [f]`
won’t use the equational theorems, and will only use its internal
unfolding machinery.
### Implementation notes
It uses the same `mkEqnTypes` function as for recursive functions, so we
are close to a consistency here. There is still the wrinkle that for
recursive functions we don't split matches without an interesting
recursive call inside. Unifying that is future work.
