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
[Merged by Bors] - feat: port Algebra.BigOperators.Fin #1848
Conversation
theorem partialProd_right_inv {G : Type _} [Group G] (g : G) (f : Fin n → G) (i : Fin n) : | ||
((g • partialProd f) (Fin.castLt i (Nat.lt_succ_of_lt i.2)))⁻¹ * | ||
(g • partialProd f) i.succ = f i := by | ||
rcases i with ⟨i, hn⟩ |
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.
This theorem was a nightmare to prove. Lots of things that should be def-eq aren't recoginsed as such by rw
(e.g. n + 1
vs n.succ
). Moreover assoc_rw
would be really helpful.
Could somebody look at the proof and decide if there is anything that could be done to avoid non-terminal simp
and all the change
?
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.
Also the statement has changed. In Lean3 it was ↑i
instead of (Fin.castLt i (Nat.lt_succ_of_lt i.2))
. I changed that because Lean4 got the conversion wrong, could that be fixed too?
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 see, Lean 4 coerces via the path Fin n → ℕ → Fin (n + 1)
which results in different defeqs than castLt
. Although I can't actually find where the coercion comes from in mathlib 3...
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.
Nope, turns out that Lean 3 finds the same coercion (@coe_trans (fin n) ℕ (fin (n + 1)) nat.cast_coe (fin.fin_to_nat n)
). So I think it's best to keep the statement with a coercion.
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.
Thanks for writing the extensive porting note.
Let's merge this PR now. We can revisit this issue later.
Thanks 🎉 bors merge |
👎 Rejected by label |
bors r+ |
Co-authored-by: Floris van Doorn <fpvdoorn@gmail.com>
This PR/issue depends on:
|
Build failed:
|
bors r+ |
Co-authored-by: Floris van Doorn <fpvdoorn@gmail.com>
Pull request successfully merged into master. Build succeeded:
|
See Zulip question about
to_additive
.