Zulip Chat Archive

Stream: mathlib4

Topic: Data.Int.Order.Basic


Scott Morrison (Dec 13 2022 at 22:25):

mathlib4#938, which is on the critical path, is down to one annoying error, which I wouldn't mind some help with.

Scott Morrison (Dec 13 2022 at 22:27):

We get to a point where the goal is ¬↑(k + 2) < (2 : ℤ), and the translated proof is by decide, but this doesn't work, with expected type must not contain free or meta variables. Trying instead by revert k; decide gives failed to synthesize Decidable (∀ (k : ℕ), ↑(k + 2) < 2 → 0 ≤ ↑(k + 2) → ¬↑(k + 2) < 2).

Scott Morrison (Dec 13 2022 at 22:27):

Happy to have either a fix/explanation of how to get decide working there, or any arbitrary workaround.

Gabriel Ebner (Dec 13 2022 at 22:32):

Yeah that error is a bit patronizing. I wonder if we should just add a decide! tactic.

Eric Wieser (Dec 13 2022 at 22:41):

Presumably this worked before because int.lt was defined inductively in a way that made it always true?

Mario Carneiro (Dec 13 2022 at 22:49):

it's still defined like that

Mario Carneiro (Dec 13 2022 at 22:49):

decide just doesn't want to try reducing an open term to ofTrue

Mario Carneiro (Dec 13 2022 at 22:50):

FYI we already have a decide! tactic

Mario Carneiro (Dec 13 2022 at 22:50):

it reverts everything before calling decide

Mario Carneiro (Dec 13 2022 at 22:51):

I think we should just remove the error message, and instead only use that check to enable the fast path

Scott Morrison (Dec 13 2022 at 23:02):

The more immediate question here is that decide! is not working either, and this is what I would like help with.

Kevin Buzzard (Dec 13 2022 at 23:07):

theorem emod_two_eq_zero_or_one (n : ) : n % 2 = 0  n % 2 = 1 :=
  have h : n % 2 < 2 := abs_of_nonneg (show 0  (2 : ) by decide)  Int.emod_lt _ (by decide)
  have h₁ : 0  n % 2 := Int.emod_nonneg _ (by decide)
  match n % 2, h, h₁ with
  | (0 : ), _ ,_ => Or.inl rfl
  | (1 : ), _ ,_ => Or.inr rfl
  | (k + 2 : ), h₁, _ => absurd h $ False.elim $ h₁.not_le $ by
    rw [Nat.cast_add]
    exact (le_add_iff_nonneg_left 2).2 (NonNeg.mk k)
  | -[a+1], _, h₁ => by cases h₁

is a proof if you want to keep the port moving while you worry about decidability.

Scott Morrison (Dec 13 2022 at 23:18):

I made an issue for this, linked to it, and will merge the PR now.

https://github.com/leanprover-community/mathlib4/issues/994

Kevin Buzzard (Dec 13 2022 at 23:27):

/- The `simpNF` linter reports:
SOME SIMP LEMMAS ARE NOT IN SIMP-NORMAL FORM.
see note [simp-normal form] for tips how to debug this.
https://leanprover-community.github.io/mathlib_docs/notes.html#simp-normal%20form -/
#check @natAbs_dvd_iff_dvd /- Left-hand side simplifies from
  natAbs a ∣ natAbs b
to
  (match a with
  | ofNat m => m
  | -[m+1] => Nat.succ m) ∣
  match b with
  | ofNat m => m
  | -[m+1] => Nat.succ m
using
  simp only [Int.natAbs]
Try to change the left-hand side to the simplified term!
 -/

Kevin Buzzard (Dec 13 2022 at 23:28):

natAbs a gets "simplified" to that mess??

Yaël Dillies (Dec 13 2022 at 23:28):

Did someone tag Int.natAbs with simp?

Scott Morrison (Dec 13 2022 at 23:29):

Yes, it seems @Ruben Van de Velde did 3 days ago.

Yaël Dillies (Dec 13 2022 at 23:30):

In Lean 3, it meant constructor applications would get simplified. Did that change in Lean 4?

Scott Morrison (Dec 13 2022 at 23:32):

Yes.

Scott Morrison (Dec 13 2022 at 23:32):

This (PR) is fixed now.

Kevin Buzzard (Dec 13 2022 at 23:34):

Well that's my new lean 4 fact of the day

Ruben Van de Velde (Dec 14 2022 at 05:15):

Scott Morrison said:

Yes, it seems Ruben Van de Velde did 3 days ago.

I blame mathport, I only changed it from nat_abs :)

Kevin Buzzard (Dec 14 2022 at 08:09):

Yeah it's the change in behaviour which spiked us.


Last updated: Dec 20 2023 at 11:08 UTC