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/ordered_group): another step in the order
refactor -- ordered groups
#8060
Conversation
…nprover-community/mathlib into adomani_covariant_contravariant_file
…ty/mathlib into adomani_ordered_group
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.
In the first part you have lemmas which each of the four classes below. It would be good if you have the same pattern of lemmas for the four classes, following the same naming scheme (if possible while avoiding naming clashes):
[covariant_class α α (*) (≤)]
[covariant_class α α (*) (<)]
[covariant_class α α (function.swap (*)) (≤)]
[covariant_class α α (function.swap (*)) (<)]
There are currently quite some inconsistencies/omissions.
In some comments I ask about inconsistencies. To what extend is this because of trying to be (somewhat) backwards compatible?
by { rw [mul_inv_cancel_right, mul_comm a, mul_inv_cancel_right] at this, rw [this] } | ||
by { rw [← mul_le_mul_iff_left a, ← mul_le_mul_iff_right b], simp } | ||
|
||
alias neg_le_neg_iff ↔ le_of_neg_le_neg _ |
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.
Here and in other places, there are aliases only for additive operations. Is this just because the library doesn't use the multiplicative versions of these lemmas, but it does use the additive version?
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.
Yes, most of the times (probably all, I do not remember), I reformulated the statement from the additive version to multiplicative with to_additive
, and then I only introduced the alias for the additive version, since the multiplicative version was not in Lean before anyway.
lemma le_abs_self (a : α) : a ≤ abs a := le_max_left _ _ | ||
|
||
lemma neg_le_abs_self (a : α) : -a ≤ abs a := le_max_right _ _ | ||
|
||
lemma neg_abs_le_self (a : α) : -abs a ≤ a := |
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 there a reason that the shorter proof doesn't work anymore?
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.
Very superficially, neg_le
uses both left and right monotonicity. Here we are only assuming one-sided monotonicity and trading the other side for linear_order
. This should explain the le_total
bit. The calc
proof makes it look longer than it really is, but that is another matter! Does this clarify why the old proof does not work?
Thanks for the changes! bors d+ |
✌️ adomani can now approve this pull request. To approve and merge a pull request, simply reply with |
bors merge |
Floris, thank you so much for reviewing and for merging this! I think that the subsequent PRs will be shorter and more easily fractionable! |
Pull request successfully merged into master. Build succeeded: |
order
refactor -- ordered groupsorder
refactor -- ordered groups
This PR represents another wave of generalization of proofs, following from the
order
refactor. It is another step towards #7645.covariant + contravariant
typeclasses inalgebra/ordered_monoid
#7999, where the waves washes overordered_monoid
s.