-
Notifications
You must be signed in to change notification settings - Fork 0
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: add BitVec.toFin_append #36
base: master
Are you sure you want to change the base?
Conversation
@[simp] theorem toFin_append {x : BitVec m} {y : BitVec n} : | ||
(x ++ y).toFin = @Fin.mk (2^(m+n)) (x.toNat <<< n ||| y.toNat) (toNat_append_lt x y) := by | ||
ext |
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.
I think it's more general to have h
be a proof, I have had situations where lean fails to unify correctly with the proposition when we fix the proof to be a a particular proof, even if we have proof irrelevance.
I added a proof template for: @[simp] theorem toInt_append {x : BitVec n} {y : BitVec m} :
(x ++ y).toInt = if n == 0 then y.toInt else x.toInt * (2 ^ m) + y.toNat := by but got a bit stuck in the actual proof. On the other hand, I find the toInt statement actually pretty neat. |
This adds
BitVec.[toInt|toFIn]_append
.An alternative way to state
toFin_append
is:which avoids the toNat_append proof in the match. @bollu reported this is preferable for robustness, but we would appreciate feedback from lean experts.