Skip to content
This repository was archived by the owner on Jul 24, 2024. It is now read-only.

[Merged by Bors] - feat(data/list/min_max): maximum is a fold, bounded prod - #8543

Closed
pechersky wants to merge 4 commits into
masterfrom
pechersky/list-max-fold
Closed

[Merged by Bors] - feat(data/list/min_max): maximum is a fold, bounded prod#8543
pechersky wants to merge 4 commits into
masterfrom
pechersky/list-max-fold

Conversation

@pechersky

Copy link
Copy Markdown
Collaborator

Also provide the same lemmas for multiset.


Open in Gitpod

Also provide the same lemmas for multiset.
@pechersky pechersky added the awaiting-review The author would like community review of the PR label Aug 4, 2021
Comment thread src/data/list/min_max.lean Outdated
Comment thread src/data/list/min_max.lean Outdated
@eric-wieser eric-wieser added awaiting-author A reviewer has asked the author a question or requested changes and removed awaiting-review The author would like community review of the PR labels Aug 4, 2021
@pechersky
pechersky requested a review from eric-wieser August 9, 2021 17:29
Comment thread src/data/list/min_max.lean Outdated
Comment thread src/data/list/min_max.lean Outdated
Comment thread src/data/list/min_max.lean
Comment thread src/data/multiset/fold.lean Outdated
Comment thread src/data/multiset/basic.lean
@pechersky pechersky added awaiting-review The author would like community review of the PR and removed awaiting-author A reviewer has asked the author a question or requested changes labels Aug 15, 2021

@eric-wieser eric-wieser left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bors merge

Thanks 🎉!

@github-actions github-actions Bot added ready-to-merge All that is left is for bors to build and merge this PR. (Remember you need to say `bors r+`.) and removed awaiting-review The author would like community review of the PR labels Aug 18, 2021
bors Bot pushed a commit that referenced this pull request Aug 18, 2021
Also provide the same lemmas for multiset.
@bors

bors Bot commented Aug 18, 2021

Copy link
Copy Markdown

Pull request successfully merged into master.

Build succeeded:

@bors bors Bot changed the title feat(data/list/min_max): maximum is a fold, bounded prod [Merged by Bors] - feat(data/list/min_max): maximum is a fold, bounded prod Aug 18, 2021
@bors bors Bot closed this Aug 18, 2021
@bors
bors Bot deleted the pechersky/list-max-fold branch August 18, 2021 21:30
mathlib-bors Bot pushed a commit to leanprover-community/mathlib4 that referenced this pull request Apr 5, 2024
Take the content of
* some of `Algebra.BigOperators.List.Basic`
* some of `Algebra.BigOperators.List.Lemmas`
* some of `Algebra.BigOperators.Multiset.Basic`
* some of `Algebra.BigOperators.Multiset.Lemmas`
* `Algebra.BigOperators.Multiset.Order`
* `Algebra.BigOperators.Order`

and sort it into six files:
* `Algebra.Order.BigOperators.Group.List`. I credit Yakov for leanprover-community/mathlib3#8543.
* `Algebra.Order.BigOperators.Group.Multiset`. Copyright inherited from `Algebra.BigOperators.Multiset.Order`.
* `Algebra.Order.BigOperators.Group.Finset`. Copyright inherited from `Algebra.BigOperators.Order`.
* `Algebra.Order.BigOperators.Ring.List`. I credit Stuart for leanprover-community/mathlib3#10184.
* `Algebra.Order.BigOperators.Ring.Multiset`. I credit Ruben for leanprover-community/mathlib3#8787.
* `Algebra.Order.BigOperators.Ring.Finset`. I credit Floris for leanprover-community/mathlib3#1294.

Here are the design decisions at play:
* Pure algebra and big operators algebra shouldn't import (algebraic) order theory. This PR makes that better, but not perfect because we still import `Data.Nat.Order.Basic` in a few `List` files.
* It's `Algebra.Order.BigOperators` instead of `Algebra.BigOperators.Order` because algebraic order theory is more of a theory than big operators algebra. Another reason is that algebraic order theory is the only way to mix pure order and pure algebra, while there are more ways to mix pure finiteness and pure algebra than just big operators.
* There are separate files for group/monoid lemmas vs ring lemmas. Groups/monoids are the natural setup for big operators, so their lemmas shouldn't be mixed with ring lemmas that involves both addition and multiplication. As a result, everything under `Algebra.Order.BigOperators.Group` should be additivisable (except a few `Nat`- or `Int`-specific lemmas). In contrast, things under `Algebra.Order.BigOperators.Ring` are more prone to having heavy imports.
* Lemmas are separated according to `List` vs `Multiset` vs `Finset`. This is not strictly necessary, and can be relaxed in cases where there aren't that many lemmas to be had. As an example, I could split out the `AbsoluteValue` lemmas from `Algebra.Order.BigOperators.Ring.Finset` to a file `Algebra.Order.BigOperators.Ring.AbsoluteValue` and it could stay this way until too many lemmas are in this file (or a split is needed for import reasons), in which case we would need files `Algebra.Order.BigOperators.Ring.AbsoluteValue.Finset`, `Algebra.Order.BigOperators.Ring.AbsoluteValue.Multiset`, etc...
* `Finsupp` big operator and `finprod`/`finsum` order lemmas also belong in `Algebra.Order.BigOperators`. I haven't done so in this PR because the diff is big enough like that.
xgenereux pushed a commit to leanprover-community/mathlib4 that referenced this pull request Apr 15, 2024
Take the content of
* some of `Algebra.BigOperators.List.Basic`
* some of `Algebra.BigOperators.List.Lemmas`
* some of `Algebra.BigOperators.Multiset.Basic`
* some of `Algebra.BigOperators.Multiset.Lemmas`
* `Algebra.BigOperators.Multiset.Order`
* `Algebra.BigOperators.Order`

and sort it into six files:
* `Algebra.Order.BigOperators.Group.List`. I credit Yakov for leanprover-community/mathlib3#8543.
* `Algebra.Order.BigOperators.Group.Multiset`. Copyright inherited from `Algebra.BigOperators.Multiset.Order`.
* `Algebra.Order.BigOperators.Group.Finset`. Copyright inherited from `Algebra.BigOperators.Order`.
* `Algebra.Order.BigOperators.Ring.List`. I credit Stuart for leanprover-community/mathlib3#10184.
* `Algebra.Order.BigOperators.Ring.Multiset`. I credit Ruben for leanprover-community/mathlib3#8787.
* `Algebra.Order.BigOperators.Ring.Finset`. I credit Floris for leanprover-community/mathlib3#1294.

Here are the design decisions at play:
* Pure algebra and big operators algebra shouldn't import (algebraic) order theory. This PR makes that better, but not perfect because we still import `Data.Nat.Order.Basic` in a few `List` files.
* It's `Algebra.Order.BigOperators` instead of `Algebra.BigOperators.Order` because algebraic order theory is more of a theory than big operators algebra. Another reason is that algebraic order theory is the only way to mix pure order and pure algebra, while there are more ways to mix pure finiteness and pure algebra than just big operators.
* There are separate files for group/monoid lemmas vs ring lemmas. Groups/monoids are the natural setup for big operators, so their lemmas shouldn't be mixed with ring lemmas that involves both addition and multiplication. As a result, everything under `Algebra.Order.BigOperators.Group` should be additivisable (except a few `Nat`- or `Int`-specific lemmas). In contrast, things under `Algebra.Order.BigOperators.Ring` are more prone to having heavy imports.
* Lemmas are separated according to `List` vs `Multiset` vs `Finset`. This is not strictly necessary, and can be relaxed in cases where there aren't that many lemmas to be had. As an example, I could split out the `AbsoluteValue` lemmas from `Algebra.Order.BigOperators.Ring.Finset` to a file `Algebra.Order.BigOperators.Ring.AbsoluteValue` and it could stay this way until too many lemmas are in this file (or a split is needed for import reasons), in which case we would need files `Algebra.Order.BigOperators.Ring.AbsoluteValue.Finset`, `Algebra.Order.BigOperators.Ring.AbsoluteValue.Multiset`, etc...
* `Finsupp` big operator and `finprod`/`finsum` order lemmas also belong in `Algebra.Order.BigOperators`. I haven't done so in this PR because the diff is big enough like that.
atarnoam pushed a commit to leanprover-community/mathlib4 that referenced this pull request Apr 16, 2024
Take the content of
* some of `Algebra.BigOperators.List.Basic`
* some of `Algebra.BigOperators.List.Lemmas`
* some of `Algebra.BigOperators.Multiset.Basic`
* some of `Algebra.BigOperators.Multiset.Lemmas`
* `Algebra.BigOperators.Multiset.Order`
* `Algebra.BigOperators.Order`

and sort it into six files:
* `Algebra.Order.BigOperators.Group.List`. I credit Yakov for leanprover-community/mathlib3#8543.
* `Algebra.Order.BigOperators.Group.Multiset`. Copyright inherited from `Algebra.BigOperators.Multiset.Order`.
* `Algebra.Order.BigOperators.Group.Finset`. Copyright inherited from `Algebra.BigOperators.Order`.
* `Algebra.Order.BigOperators.Ring.List`. I credit Stuart for leanprover-community/mathlib3#10184.
* `Algebra.Order.BigOperators.Ring.Multiset`. I credit Ruben for leanprover-community/mathlib3#8787.
* `Algebra.Order.BigOperators.Ring.Finset`. I credit Floris for leanprover-community/mathlib3#1294.

Here are the design decisions at play:
* Pure algebra and big operators algebra shouldn't import (algebraic) order theory. This PR makes that better, but not perfect because we still import `Data.Nat.Order.Basic` in a few `List` files.
* It's `Algebra.Order.BigOperators` instead of `Algebra.BigOperators.Order` because algebraic order theory is more of a theory than big operators algebra. Another reason is that algebraic order theory is the only way to mix pure order and pure algebra, while there are more ways to mix pure finiteness and pure algebra than just big operators.
* There are separate files for group/monoid lemmas vs ring lemmas. Groups/monoids are the natural setup for big operators, so their lemmas shouldn't be mixed with ring lemmas that involves both addition and multiplication. As a result, everything under `Algebra.Order.BigOperators.Group` should be additivisable (except a few `Nat`- or `Int`-specific lemmas). In contrast, things under `Algebra.Order.BigOperators.Ring` are more prone to having heavy imports.
* Lemmas are separated according to `List` vs `Multiset` vs `Finset`. This is not strictly necessary, and can be relaxed in cases where there aren't that many lemmas to be had. As an example, I could split out the `AbsoluteValue` lemmas from `Algebra.Order.BigOperators.Ring.Finset` to a file `Algebra.Order.BigOperators.Ring.AbsoluteValue` and it could stay this way until too many lemmas are in this file (or a split is needed for import reasons), in which case we would need files `Algebra.Order.BigOperators.Ring.AbsoluteValue.Finset`, `Algebra.Order.BigOperators.Ring.AbsoluteValue.Multiset`, etc...
* `Finsupp` big operator and `finprod`/`finsum` order lemmas also belong in `Algebra.Order.BigOperators`. I haven't done so in this PR because the diff is big enough like that.
uniwuni pushed a commit to leanprover-community/mathlib4 that referenced this pull request Apr 19, 2024
Take the content of
* some of `Algebra.BigOperators.List.Basic`
* some of `Algebra.BigOperators.List.Lemmas`
* some of `Algebra.BigOperators.Multiset.Basic`
* some of `Algebra.BigOperators.Multiset.Lemmas`
* `Algebra.BigOperators.Multiset.Order`
* `Algebra.BigOperators.Order`

and sort it into six files:
* `Algebra.Order.BigOperators.Group.List`. I credit Yakov for leanprover-community/mathlib3#8543.
* `Algebra.Order.BigOperators.Group.Multiset`. Copyright inherited from `Algebra.BigOperators.Multiset.Order`.
* `Algebra.Order.BigOperators.Group.Finset`. Copyright inherited from `Algebra.BigOperators.Order`.
* `Algebra.Order.BigOperators.Ring.List`. I credit Stuart for leanprover-community/mathlib3#10184.
* `Algebra.Order.BigOperators.Ring.Multiset`. I credit Ruben for leanprover-community/mathlib3#8787.
* `Algebra.Order.BigOperators.Ring.Finset`. I credit Floris for leanprover-community/mathlib3#1294.

Here are the design decisions at play:
* Pure algebra and big operators algebra shouldn't import (algebraic) order theory. This PR makes that better, but not perfect because we still import `Data.Nat.Order.Basic` in a few `List` files.
* It's `Algebra.Order.BigOperators` instead of `Algebra.BigOperators.Order` because algebraic order theory is more of a theory than big operators algebra. Another reason is that algebraic order theory is the only way to mix pure order and pure algebra, while there are more ways to mix pure finiteness and pure algebra than just big operators.
* There are separate files for group/monoid lemmas vs ring lemmas. Groups/monoids are the natural setup for big operators, so their lemmas shouldn't be mixed with ring lemmas that involves both addition and multiplication. As a result, everything under `Algebra.Order.BigOperators.Group` should be additivisable (except a few `Nat`- or `Int`-specific lemmas). In contrast, things under `Algebra.Order.BigOperators.Ring` are more prone to having heavy imports.
* Lemmas are separated according to `List` vs `Multiset` vs `Finset`. This is not strictly necessary, and can be relaxed in cases where there aren't that many lemmas to be had. As an example, I could split out the `AbsoluteValue` lemmas from `Algebra.Order.BigOperators.Ring.Finset` to a file `Algebra.Order.BigOperators.Ring.AbsoluteValue` and it could stay this way until too many lemmas are in this file (or a split is needed for import reasons), in which case we would need files `Algebra.Order.BigOperators.Ring.AbsoluteValue.Finset`, `Algebra.Order.BigOperators.Ring.AbsoluteValue.Multiset`, etc...
* `Finsupp` big operator and `finprod`/`finsum` order lemmas also belong in `Algebra.Order.BigOperators`. I haven't done so in this PR because the diff is big enough like that.
callesonne pushed a commit to leanprover-community/mathlib4 that referenced this pull request Apr 22, 2024
Take the content of
* some of `Algebra.BigOperators.List.Basic`
* some of `Algebra.BigOperators.List.Lemmas`
* some of `Algebra.BigOperators.Multiset.Basic`
* some of `Algebra.BigOperators.Multiset.Lemmas`
* `Algebra.BigOperators.Multiset.Order`
* `Algebra.BigOperators.Order`

and sort it into six files:
* `Algebra.Order.BigOperators.Group.List`. I credit Yakov for leanprover-community/mathlib3#8543.
* `Algebra.Order.BigOperators.Group.Multiset`. Copyright inherited from `Algebra.BigOperators.Multiset.Order`.
* `Algebra.Order.BigOperators.Group.Finset`. Copyright inherited from `Algebra.BigOperators.Order`.
* `Algebra.Order.BigOperators.Ring.List`. I credit Stuart for leanprover-community/mathlib3#10184.
* `Algebra.Order.BigOperators.Ring.Multiset`. I credit Ruben for leanprover-community/mathlib3#8787.
* `Algebra.Order.BigOperators.Ring.Finset`. I credit Floris for leanprover-community/mathlib3#1294.

Here are the design decisions at play:
* Pure algebra and big operators algebra shouldn't import (algebraic) order theory. This PR makes that better, but not perfect because we still import `Data.Nat.Order.Basic` in a few `List` files.
* It's `Algebra.Order.BigOperators` instead of `Algebra.BigOperators.Order` because algebraic order theory is more of a theory than big operators algebra. Another reason is that algebraic order theory is the only way to mix pure order and pure algebra, while there are more ways to mix pure finiteness and pure algebra than just big operators.
* There are separate files for group/monoid lemmas vs ring lemmas. Groups/monoids are the natural setup for big operators, so their lemmas shouldn't be mixed with ring lemmas that involves both addition and multiplication. As a result, everything under `Algebra.Order.BigOperators.Group` should be additivisable (except a few `Nat`- or `Int`-specific lemmas). In contrast, things under `Algebra.Order.BigOperators.Ring` are more prone to having heavy imports.
* Lemmas are separated according to `List` vs `Multiset` vs `Finset`. This is not strictly necessary, and can be relaxed in cases where there aren't that many lemmas to be had. As an example, I could split out the `AbsoluteValue` lemmas from `Algebra.Order.BigOperators.Ring.Finset` to a file `Algebra.Order.BigOperators.Ring.AbsoluteValue` and it could stay this way until too many lemmas are in this file (or a split is needed for import reasons), in which case we would need files `Algebra.Order.BigOperators.Ring.AbsoluteValue.Finset`, `Algebra.Order.BigOperators.Ring.AbsoluteValue.Multiset`, etc...
* `Finsupp` big operator and `finprod`/`finsum` order lemmas also belong in `Algebra.Order.BigOperators`. I haven't done so in this PR because the diff is big enough like that.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

ready-to-merge All that is left is for bors to build and merge this PR. (Remember you need to say `bors r+`.)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants