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

simp usually reduces Fin n literals, but not n itself #5630

Closed
nomeata opened this issue Oct 7, 2024 · 4 comments · Fixed by #5632
Closed

simp usually reduces Fin n literals, but not n itself #5630

nomeata opened this issue Oct 7, 2024 · 4 comments · Fixed by #5632
Labels
bug Something isn't working

Comments

@nomeata
Copy link
Collaborator

nomeata commented Oct 7, 2024

Very conveniently, simp knows about Fin n literals, and reduces them mod n:

example (n : Fin 25) (P : Fin 25Prop): P (26) := by
  simp
  guard_target = P 1

It does not do that for n itself, though:

/-- error: simp made no progress -/
#guard_msgs in
example (n : Fin 25) (P : Fin 25Prop): P (25) := by
  simp

I expect this to simplify to P 0.

Note that it also doesn't change 0 to n:

/-- error: simp made no progress -/
#guard_msgs in
example (n : Fin 25) (P : Fin 25Prop): P 0 := by
  simp

It would be desirable if simp would consistently reduce all Fin n literals (with concrete n) modulo n.

This came up in the equational_theories project.

Versions

"4.12.0-nightly-2024-10-03"

Impact

Add 👍 to issues you consider important. If others are impacted by this issue, please ask them to add 👍 to it.

@nomeata nomeata added the bug Something isn't working label Oct 7, 2024
@nomeata nomeata changed the title simp reduces Fin n literals, but not n simp usually reduces Fin n literals, but not n itself Oct 7, 2024
nomeata added a commit that referenced this issue Oct 7, 2024
previously, it would not reduce `25 : Fin 25` to  `0 : Fin 25`.

fixes #5630
github-merge-queue bot pushed a commit that referenced this issue Oct 15, 2024
previously, it would not reduce `25 : Fin 25` to  `0 : Fin 25`.

fixes #5630
@b-mehta
Copy link
Contributor

b-mehta commented Dec 10, 2024

Out of curiosity, would a similar fix to this one be appropriate for https://leanprover.zulipchat.com/#narrow/channel/270676-lean4/topic/simproc.20for.20Fin as well? Or are the fixes there the correct way to proceed

@nomeata
Copy link
Collaborator Author

nomeata commented Dec 10, 2024

I'm not an expert on the API design here. I'd say that whenever a simp rule works it should be used over a simproc. I'm not sure about the conclusion of that thread - did someone find a simp lemma that works?

@b-mehta
Copy link
Contributor

b-mehta commented Dec 10, 2024

I'd say that whenever a simp rule works it should be used over a simproc.

I think this answers my question!

I'm not sure about the conclusion of that thread - did someone find a simp lemma that works?

It is somewhat implicit in that thread, but the addition which works is

import Mathlib.Data.Fin.Basic

@[simp]
theorem coe_ofNat_of_lt (m n : ℕ) [NeZero m] (h : n < m) :
    ((no_index (OfNat.ofNat n) : Fin m) : ℕ) = OfNat.ofNat n := by
  rwa [Fin.coe_ofNat_eq_mod, Nat.mod_eq_of_lt]

example : ((3 : Fin 4) : Nat) = 3 := by
  simp

@nomeata
Copy link
Collaborator Author

nomeata commented Dec 10, 2024

If the discrimnation tree behaviour is ok here (I assume it will be tried on every Fin-to-Nat coercion), then yes, looks plausible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants