-
Notifications
You must be signed in to change notification settings - Fork 297
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] - refactor(algebra): merge init_.algebra into algebra #2707
Conversation
E.g., we can delete |
I think that having more files in So I'm really not happy about the idea of relaxing restrictions about low dependencies of |
We could rename |
@@ -1,45 +1,222 @@ | |||
/- | |||
Copyright (c) 2017 Johannes Hölzl. All rights reserved. | |||
Copyright (c) 2014 Robert Lewis. All rights reserved. |
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 copyright date does not seem to be accurate.
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 most mathlib files contain the date of the first revision. The name and date here is from the init.algebra.field
file. If we want to change this to (c) 2014-2020
or something then that should be applied to a lot more theorems than this.
instance division_ring.to_group_with_zero {K : Type*} [division_ring K] : | ||
group_with_zero K := | ||
instance division_ring.to_group_with_zero : | ||
group_with_zero α := |
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 thought we're moving towards calling fields K
instead of α
?
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.
Is a group with zero a field? One thing I don't like about the new convention is that I am never sure what letter to use for these exotic structures. Anyway we can follow this up with some more cleanup in this vein.
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.
No, but a division ring is a kind of field. A Schiefkörper, to be precise. So obviously it should get a K
letter.
@@ -278,7 +278,7 @@ lemma f_squared : ∀ v : V n, (f n) (f n v) = (n : ℝ) • v := | |||
begin | |||
induction n with n IH; intro, | |||
{ simpa only [nat.cast_zero, zero_smul] }, | |||
{ cases v, simp [f_succ_apply, IH, add_smul], abel } | |||
{ cases v, simp [f_succ_apply, IH, add_smul, add_assoc], abel } |
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.
Is add_assoc
no longer simp?
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.
It was never supposed to be. It was officially removed as a simp lemma at the same time as mul_assoc
, but due to a bug in the core version of to_additive
it was getting marked as a simp lemma anyway.
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.
Oh, I didn't notice. I only remember the add_comm
/mul_comm
story, where clearly neither should be simp lemmas. Is there a good reason *_assoc
should not be simp?
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'm not totally clear on the reasons for removing these in the first place, but I think that consistency is good. Quite clearly even add_comm
is okay for simp because it has explicit support for AC rewriting. Maybe these lemmas should be added to a simp set like simp with ac
?
@@ -1,119 +1,294 @@ | |||
/- | |||
Copyright (c) 2017 Mario Carneiro. All rights reserved. | |||
Copyright (c) 2016 Jeremy Avigad. All rights reserved. |
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 copyright date also changes in the wrong direction.
Thanks a megaton of 🐙 🎉 🍰 🎆 bors merge |
This is a big refactor PR. It depends on #2697, which brings in the algebra hierarchy without any change to the file structure. This PR merges `init_.algebra.group` into `algebra.group` and so on for the rest of the algebraic hierarchy. Co-authored-by: Mario Carneiro <di.gama@gmail.com> Co-authored-by: Bryan Gin-ge Chen <bryangingechen@gmail.com>
Pull request successfully merged into master. Build succeeded: |
…nity#2707) This is a big refactor PR. It depends on leanprover-community#2697, which brings in the algebra hierarchy without any change to the file structure. This PR merges `init_.algebra.group` into `algebra.group` and so on for the rest of the algebraic hierarchy. Co-authored-by: Mario Carneiro <di.gama@gmail.com> Co-authored-by: Bryan Gin-ge Chen <bryangingechen@gmail.com>
Reorder the `WithOne` material. `Algebra.Group.WithOne.Defs` was hiding a `Ring` import! I credit Johan and Mario for leanprover-community/mathlib#2707.
Reorder the `WithOne` material. * `Algebra.Group.WithOne.Defs` was hiding a `Ring` import! I credit Johan and Mario for leanprover-community/mathlib#2707. * `WithBot` is not needed to define `WithOne.unone`. It's simpler to redefine it by hand. In the future, we might want to have an `Option` version (but not sure how much that's worth, since it would basically be `Option.get` again).
Reorder the `WithOne` material. * `Algebra.Group.WithOne.Defs` was hiding a `Ring` import! I credit Johan and Mario for leanprover-community/mathlib#2707. * `WithBot` is not needed to define `WithOne.unone`. It's simpler to redefine it by hand. In the future, we might want to have an `Option` version (but not sure how much that's worth, since it would basically be `Option.get` again).
This is a big refactor PR. It depends on #2697, which brings in the algebra hierarchy without any change to the file structure. This PR merges
init_.algebra.group
intoalgebra.group
and so on for the rest of the algebraic hierarchy.