Skip to content
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: bv_omega, a simple BitVec->Nat preprocessor + omega #3435

Merged
merged 3 commits into from
Feb 22, 2024
Merged

Conversation

kim-em
Copy link
Collaborator

@kim-em kim-em commented Feb 21, 2024

example (x y z : BitVec 8)
    (hx : x >>> 1 < 16) (hy : y < 16) (hz : z = x + 2 * y) : z ≤ 64 := by
  bv_omega

example (x : BitVec 8) (hx : (x + 1) <<< 1 = 4) : x = 1 ∨ x = 129 := by
  bv_omega

example (x y : BitVec 64) (_ : x < (y.truncate 32).zeroExtend 64) :
    ~~~x > (1#64 <<< 63) := by
  bv_omega

@github-actions github-actions bot temporarily deployed to lean-lang.org/lean4/doc February 21, 2024 12:37 Inactive
@github-actions github-actions bot added the toolchain-available A toolchain is available for this PR, at leanprover/lean4-pr-releases:pr-release-NNNN label Feb 21, 2024
@leanprover-community-mathlib4-bot
Copy link
Collaborator

Mathlib CI status (docs):

  • ❗ Std/Mathlib CI will not be attempted unless your PR branches off the nightly-with-mathlib branch. Try git rebase 959ad988611db082ae4a97e9b8c4390fab53352e --onto 8b8e001794e6a8b481d37f24fa77bb07797682a1. (2024-02-21 12:40:47)

@github-actions github-actions bot temporarily deployed to lean-lang.org/lean4/doc February 22, 2024 01:46 Inactive
@kim-em kim-em merged commit 469f519 into master Feb 22, 2024
9 checks passed
Currently the preprocessor is implemented as `try simp only [bv_toNat] at *`.
`bv_toNat` is a `@[simp]` attribute that you can (cautiously) add to more theorems.
-/
macro "bv_omega" : tactic => `(tactic| (try simp only [bv_toNat] at *) <;> omega)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of try, this could use { config := { failIfUnchanged := false }}. Is there any reason to prefer the latter over the former? It’s more verbose, but it seems less roundabout than failing first and then recovering. (Maybe it simply doesn’t matter.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
toolchain-available A toolchain is available for this PR, at leanprover/lean4-pr-releases:pr-release-NNNN
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants