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

[Merged by Bors] - feat: Mixins for monotonicity of scalar multiplication #8869

Closed
wants to merge 9 commits into from

Conversation

YaelDillies
Copy link
Collaborator

@YaelDillies YaelDillies commented Dec 7, 2023

This PR introduces eight typeclasses for monotonicity of left/right scalar multiplication by nonnegative elements:

  • PosSMulMono: If a ≥ 0, then b₁ ≤ b₂ implies a • b₁ ≤ a • b₂.
  • PosSMulStrictMono: If a > 0, then b₁ < b₂ implies a • b₁ < a • b₂.
  • PosSMulReflectLT: If a ≥ 0, then a • b₁ < a • b₂ implies b₁ < b₂.
  • PosSMulReflectLE: If a > 0, then a • b₁ ≤ a • b₂ implies b₁ ≤ b₂.
  • SMulPosMono: If b ≥ 0, then a₁ ≤ a₂ implies a₁ • b ≤ a₂ • b.
  • SMulPosStrictMono: If b > 0, then a₁ < a₂ implies a₁ • b < a₂ • b.
  • SMulPosReflectLT: If b ≥ 0, then a₁ • b < a₂ • b implies a₁ < a₂.
  • SMulPosReflectLE: If b > 0, then a₁ • b ≤ a₂ • b implies a₁ ≤ a₂.

The design is heavily inspired to the corresponding one for multiplication (see Algebra.Order.Ring.Lemmas). Note however the following differences:

  • The new typeclasses are custom typeclasses instead of abbreviations for the correct CovariantClass/ContravariantClass invokations. This has the following benefits:
    • They get displayed as classes in the docs. In particular, one can see their list of instances, instead of their instances being invariably dumped to the CovariantClass/ContravariantClass list.
    • They don't pollute other typeclass searches. Having many abbreviations of the same typeclass for different purposes always felt like a performance issue to me (more instances with the same key, for no added benefit), and indeed a previous version of this PR hit timeouts due to the higher number of CovariantClass/ContravariantClass instances.
    • SMulPosReflectLT/SMulPosReflectLE did not fit in the framework since they relate on two different types. So I would have had to generalise CovariantClass/ContravariantClass to three types and two relations.
    • Very minor, but the constructors let you work with a : α, h : 0 ≤ a instead of a : {a : α // 0 ≤ a}. This actually makes some instances surprisingly cleaner to prove.
    • The CovariantClass/ContravariantClass framework was only used to automate very simple logic anyway. It was easily copied over.
  • We replace undocumented lemmas stating the equivalence of the four typeclasses mentioning nonnegativity with their positivity version by motivated constructors.
  • We abandon series of lemmas of dubious utility. Those were already marked as such in Algebra.Order.Ring.Lemmas (by myself).
  • Some lemmas about commutativity of multiplication don't make sense for scalar multiplication.

This PR links the new typeclasses to OrderedSMul and makes all old lemmas in Algebra.Order.SMul one-liners in terms of the new lemmas (except when they have the same name, in which case the lemma is simply moved) but doesn't delete the old ones to reduce churn. What remains to be done afterwards is thus:

  • finish the transition by deleting the duplicate lemmas from Algebra.Order.SMul
  • rearrange the non-duplicate lemmas into new files
  • generalise (most of) the lemmas from Algebra.Order.Module to Algebra.Order.Module.Defs
  • rethink OrderedSMul

Open in Gitpod

This PR introduces eight typeclasses for monotonicity of left/right scalar multiplication by nonnegative elements:
* `PosSMulMono`: If `a ≥ 0`, then `b₁ ≤ b₂` implies `a • b₁ ≤ a • b₂`.
* `PosSMulStrictMono`: If `a > 0`, then `b₁ < b₂` implies `a • b₁ < a • b₂`.
* `PosSMulReflectLT`: If `a ≥ 0`, then `a • b₁ < a • b₂` implies `b₁ < b₂`.
* `PosSMulReflectLE`: If `a > 0`, then `a • b₁ ≤ a • b₂` implies `b₁ ≤ b₂`.
* `SMulPosMono`: If `b ≥ 0`, then `a₁ ≤ a₂` implies `a₁ • b ≤ a₂ • b`.
* `SMulPosStrictMono`: If `b > 0`, then `a₁ < a₂` implies `a₁ • b < a₂ • b`.
* `SMulPosReflectLT`: If `b ≥ 0`, then `a₁ • b < a₂ • b` implies `a₁ < a₂`.
* `SMulPosReflectLE`: If `b > 0`, then `a₁ • b ≤ a₂ • b` implies `a₁ ≤ a₂`.

The design is heavily inspired to the corresponding one for multiplication (see `Algebra.Order.Ring.Lemmas`). Note however the following differences:
* The new typeclasses are custom typeclasses instead of abbreviations for the correct `CovariantClass`/`ContravariantClass` invokations. This has the following benefits:
  * They get displayed as classes in the docs. In particular, one can see their list of instances, instead of their instances being invariably dumped to the `CovariantClass`/`ContravariantClass` list.
  * They don't pollute other typeclass searches. Having many abbreviations of the same typeclass for different purposes always felt like a performance issue to me (more instances with the same key, for no added benefit), and indeed a previous version of this PR hit timeouts due to the higher number of `CovariantClass`/`ContravariantClass` instances.
  * `SMulPosReflectLT`/`SMulPosReflectLE` did not fit in the framework since they relate `≤` on two different types. So I would have had to generalise `CovariantClass`/`ContravariantClass` to three types and two relations.
  * Very minor, but the constructors let you work with `a : α`, `h : 0 ≤ a` instead of `a : {a : α // 0 ≤ a}`. This actually makes some instances surprisingly cleaner to prove.
  * The `CovariantClass`/`ContravariantClass` framework was only used to automate very simple logic anyway. It was easily copied over.
* We replace undocumented lemmas stating the equivalence of the four typeclasses mentioning nonnegativity with their positivity version by motivated constructors.
* We abandon series of lemmas of dubious utility. Those were already marked as such in `Algebra.Order.Ring.Lemmas` (by myself).
* `...MonoRev` is replaced by `...ReflectLE` in the hope of being more understandable.
* Some lemmas about commutativity of multiplication don't make sense for scalar multiplication.

This PR links the new typeclasses to `OrderedSMul` and makes all old lemmas in `Algebra.Order.SMul` one-liners in terms of the new lemmas (except when they have the same name, in which case the lemma is simply moved) but doesn't delete the old ones to reduce churn. What remains to be done afterwards is thus:
* finish the transition by deleting the duplicate lemmas from `Algebra.Order.SMul`
* rearrange the non-duplicate lemmas into new files
* generalise (most of) the lemmas from `Algebra.Order.Module` to `Algebra.Order.Module.Defs`
* rethink `OrderedSMul`

This PR also:
* deletes `instModuleOrderDual`, which was accidentally duplicated in #8840.
* fixes the dead links to Wikipedia in `Algebra.Order.SMul` and `Algebra.Order.Module`.
@YaelDillies YaelDillies added awaiting-review t-algebra Algebra (groups, rings, fields etc) t-order Order theory labels Dec 7, 2023
YaelDillies added a commit that referenced this pull request Dec 7, 2023
This is here to reduce the diff of #8869 and help locate breakage in downstream projects.
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
mathlib-bors bot pushed a commit that referenced this pull request Dec 7, 2023
This matches `mul_le_mul`. The old version will be made a lemma again in #8869.
@eric-wieser
Copy link
Member

  • ...MonoRev is replaced by ...ReflectLE in the hope of being more understandable.

Can you spin out a PR to make this change to the Mul typeclasses first?

@YaelDillies
Copy link
Collaborator Author

#8890

@eric-wieser
Copy link
Member

eric-wieser commented Dec 8, 2023

This PR also:

This looks like an easy spin-off too.

@YaelDillies
Copy link
Collaborator Author

#8902

awueth pushed a commit that referenced this pull request Dec 19, 2023
This matches `mul_le_mul`. The old version will be made a lemma again in #8869.
@jcommelin
Copy link
Member

!bench

@jcommelin
Copy link
Member

Hmm, that !bench isn't going to measure anything, because this new API isn't really used yet.

bors merge

@github-actions github-actions bot added ready-to-merge This PR has been sent to bors. and removed awaiting-review labels Dec 19, 2023
mathlib-bors bot pushed a commit that referenced this pull request Dec 19, 2023
This PR introduces eight typeclasses for monotonicity of left/right scalar multiplication by nonnegative elements:
* `PosSMulMono`: If `a ≥ 0`, then `b₁ ≤ b₂` implies `a • b₁ ≤ a • b₂`.
* `PosSMulStrictMono`: If `a > 0`, then `b₁ < b₂` implies `a • b₁ < a • b₂`.
* `PosSMulReflectLT`: If `a ≥ 0`, then `a • b₁ < a • b₂` implies `b₁ < b₂`.
* `PosSMulReflectLE`: If `a > 0`, then `a • b₁ ≤ a • b₂` implies `b₁ ≤ b₂`.
* `SMulPosMono`: If `b ≥ 0`, then `a₁ ≤ a₂` implies `a₁ • b ≤ a₂ • b`.
* `SMulPosStrictMono`: If `b > 0`, then `a₁ < a₂` implies `a₁ • b < a₂ • b`.
* `SMulPosReflectLT`: If `b ≥ 0`, then `a₁ • b < a₂ • b` implies `a₁ < a₂`.
* `SMulPosReflectLE`: If `b > 0`, then `a₁ • b ≤ a₂ • b` implies `a₁ ≤ a₂`.

The design is heavily inspired to the corresponding one for multiplication (see `Algebra.Order.Ring.Lemmas`). Note however the following differences:
* The new typeclasses are custom typeclasses instead of abbreviations for the correct `CovariantClass`/`ContravariantClass` invokations. This has the following benefits:
  * They get displayed as classes in the docs. In particular, one can see their list of instances, instead of their instances being invariably dumped to the `CovariantClass`/`ContravariantClass` list.
  * They don't pollute other typeclass searches. Having many abbreviations of the same typeclass for different purposes always felt like a performance issue to me (more instances with the same key, for no added benefit), and indeed a previous version of this PR hit timeouts due to the higher number of `CovariantClass`/`ContravariantClass` instances.
  * `SMulPosReflectLT`/`SMulPosReflectLE` did not fit in the framework since they relate `≤` on two different types. So I would have had to generalise `CovariantClass`/`ContravariantClass` to three types and two relations.
  * Very minor, but the constructors let you work with `a : α`, `h : 0 ≤ a` instead of `a : {a : α // 0 ≤ a}`. This actually makes some instances surprisingly cleaner to prove.
  * The `CovariantClass`/`ContravariantClass` framework was only used to automate very simple logic anyway. It was easily copied over.
* We replace undocumented lemmas stating the equivalence of the four typeclasses mentioning nonnegativity with their positivity version by motivated constructors.
* We abandon series of lemmas of dubious utility. Those were already marked as such in `Algebra.Order.Ring.Lemmas` (by myself).
* Some lemmas about commutativity of multiplication don't make sense for scalar multiplication.

This PR links the new typeclasses to `OrderedSMul` and makes all old lemmas in `Algebra.Order.SMul` one-liners in terms of the new lemmas (except when they have the same name, in which case the lemma is simply moved) but doesn't delete the old ones to reduce churn. What remains to be done afterwards is thus:
* finish the transition by deleting the duplicate lemmas from `Algebra.Order.SMul`
* rearrange the non-duplicate lemmas into new files
* generalise (most of) the lemmas from `Algebra.Order.Module` to `Algebra.Order.Module.Defs`
* rethink `OrderedSMul`
@leanprover-bot
Copy link
Collaborator

Here are the benchmark results for commit 018bda8.
There were significant changes against commit 31037d9:

  Benchmark                                         Metric                 Change
  ===============================================================================
- build                                             .olean serialization     6.3%
- build                                             import                   5.7%
- build                                             initialization           5.4%
- open Mathlib                                      instructions             5.5%
- open Mathlib                                      task-clock              31.1%
- ~Mathlib.Analysis.NormedSpace.Multilinear.Basic   instructions             2.3%

@mathlib-bors
Copy link
Contributor

mathlib-bors bot commented Dec 19, 2023

Pull request successfully merged into master.

Build succeeded:

@mathlib-bors mathlib-bors bot changed the title feat: Mixins for monotonicity of scalar multiplication [Merged by Bors] - feat: Mixins for monotonicity of scalar multiplication Dec 19, 2023
@mathlib-bors mathlib-bors bot closed this Dec 19, 2023
@mathlib-bors mathlib-bors bot deleted the pos_smul_mono branch December 19, 2023 09:11
YaelDillies added a commit that referenced this pull request Dec 21, 2023
Remove the duplicates introduced in #8869 by sorting the lemmas in `Algebra.Order.SMul` into three files:
* `Algebra.Order.Module.Defs` for the order isomorphism induced by scalar multiplication by a positivity element
* `Algebra.Order.Module.Pointwise` for the order properties of scalar multiplication of sets. This file is new. I credit myself for leanprover-community/mathlib3#9078
* `Algebra.Order.Module.OrderedSMul`: The material about `OrderedSMul` per se. Inherits the copyright header from `Algebra.Order.SMul`. This file should eventually be deleted.

I move each `#align` to the correct file. On top of that, I delete unused redundant `OrderedSMul` instances (they were useful in Lean 3, but not anymore) and `eq_of_smul_eq_smul_of_pos_of_le`/`eq_of_smul_eq_smul_of_neg_of_le` since those lemmas are weird and unused.
mathlib-bors bot pushed a commit that referenced this pull request Dec 23, 2023
Remove the duplicates introduced in #8869 by sorting the lemmas in `Algebra.Order.SMul` into three files:
* `Algebra.Order.Module.Defs` for the order isomorphism induced by scalar multiplication by a positivity element
* `Algebra.Order.Module.Pointwise` for the order properties of scalar multiplication of sets. This file is new. I credit myself for leanprover-community/mathlib3#9078
* `Algebra.Order.Module.OrderedSMul`: The material about `OrderedSMul` per se. Inherits the copyright header from `Algebra.Order.SMul`. This file should eventually be deleted.

I move each `#align` to the correct file. On top of that, I delete unused redundant `OrderedSMul` instances (they were useful in Lean 3, but not anymore) and `eq_of_smul_eq_smul_of_pos_of_le`/`eq_of_smul_eq_smul_of_neg_of_le` since those lemmas are weird and unused.
mathlib-bors bot pushed a commit that referenced this pull request Dec 23, 2023
Remove the duplicates introduced in #8869 by sorting the lemmas in `Algebra.Order.SMul` into three files:
* `Algebra.Order.Module.Defs` for the order isomorphism induced by scalar multiplication by a positivity element
* `Algebra.Order.Module.Pointwise` for the order properties of scalar multiplication of sets. This file is new. I credit myself for leanprover-community/mathlib3#9078
* `Algebra.Order.Module.OrderedSMul`: The material about `OrderedSMul` per se. Inherits the copyright header from `Algebra.Order.SMul`. This file should eventually be deleted.

I move each `#align` to the correct file. On top of that, I delete unused redundant `OrderedSMul` instances (they were useful in Lean 3, but not anymore) and `eq_of_smul_eq_smul_of_pos_of_le`/`eq_of_smul_eq_smul_of_neg_of_le` since those lemmas are weird and unused.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready-to-merge This PR has been sent to bors. t-algebra Algebra (groups, rings, fields etc) t-order Order theory
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants