Make `x.toNat * 2 + b.toNat` the simp normal form of `(concat x
b).toNat`.
The choice for multiplication and addition was inspired by `Nat.bit_val`
from Mathlib.
Also, because we have considerably more lemmas about multiplication and
`_ + 1` than about shifts and `_ ||| 1`.
This is very helpful when dealing with bitvectors, where a case analysis
on the bitwidth leaves one with hypotheses of the form `x<2^(Nat.succ
w)`.
Design decisions I am unsure about:
- Is creating a helper `succ?` the correct way to match on the exponent
`e+1`?
- I'm not certain why the prior call to `Int.ofNat_pow` also checked
that the exponent was a ground natural. I removed this, since we now
explicitly handle cases where the exponent is a term of the form `e+1`.
---------
Co-authored-by: Scott Morrison <scott.morrison@gmail.com>
Co-authored-by: Joe Hendrix <joe@lean-fro.org>
Co-authored-by: Alex Keizer <alex@keizer.dev>
First (baby)-step to a `concat`-based `bitblast`: a characterization of
`concat` in terms of `getLsb`.
The proof might benefit slightly from a `toNat_concat` lemma, but I
wasn't sure what the normal form there should be, so I avoided it.
---------
Co-authored-by: Scott Morrison <scott@tqft.net>
Every usage of `carry` followed the pattern: `carry _ x.toNat y.toNat`,
so we've refactorod `carry` to take the `BitVec`s as arguments, and made
the `toNat` part of its definition.
This is a follow up to 'https://github.com/leanprover/std4/pull/645',
where the simp lemmas were requested:
https://github.com/leanprover/std4/pull/645#issuecomment-1944862251
---
Note that @semorrison asked to use `(Fin.last _)` to index. Now that we
use a `Nat` to index `msb` , the pattern `(Fin.last _)` would not have
the width be automatically inferred. Therefore, I've changed the
definitions to use `Nat` for indexing.
---------
Co-authored-by: Siddharth Bhat Mala <sb2743@cl.cam.ac.uk>
Co-authored-by: Scott Morrison <scott.morrison@gmail.com>
This PR is an effort to improve reasoning at the Nat level about
bitvectors and reduce of Fin and Nat.
It slightly tightens some proofs, but is generally aimed at reducing
inconsistencies between definitions at the Nat and Fin types in favor of
more consistently using Nat operations.
This ports leanprover/std4#664 to Lean core.
Here was the rational I provided in the discussion for
leanprover/std4#664:
It's mostly about consistency. If we use the same types and style in
definitions and proofs, there is less surprise when unfolding or
otherwise using definitions. We use some Nat based operations that
haven't been extended to Fin such as the bitwise operations, and I don't
want to pay the overhead of introducing a Fin version of every Bitvector
operation.
So this basically means Nat is preferred.
One argument potentially in favor of Fin is that we could reuse results
proven there, but that doesn't really seem to be the case so far.
A second argument is that we want to simplify expression to use more
canonical forms and we currently can pretty-print those operations
better using ofNat than ofFin. We could define the notations using ofFin
of course though, but that's additional operators that will show up in
expressions.
#3408 was somewhat large and didn't properly test the symm and label
attribute code after edits to the builtin versions.
This migrates the code for generating labeled attributes from Init back
to Lean so that the required definitions are in scope.
This also addresses a mistake in the symm elaborator that prevented symm
without location information from elaborating.
Both fixes have been tested on the Std test suite and successfully
passed.
Adds documentation to the `String.Iterator` API, mentored by
@eric-wieser and @david-christiansen
---------
Co-authored-by: David Thrane Christiansen <david@davidchristiansen.dk>
This is a quite substantial tactic.
It also includes the infamour `NatCast` typeclass (which I've equipped
with a module-doc). I wasn't at all sure where that should live, so it
is currently randomly in `Lean/Elan/Tactic/NatCast.lean`: presumably if
we're doing this it will go somewhere in `Init`.
---------
Co-authored-by: Leonardo de Moura <leomoura@amazon.com>
When updating Std, be careful that not every lemma has been upstreamed,
so we need to be careful to only delete things that have already been
declared.
