This repository was archived by the owner on Jul 24, 2024. It is now read-only.
[Merged by Bors] - feat(order/well_founded): typeclasses for well-founded < and >#15399
Closed
[Merged by Bors] - feat(order/well_founded): typeclasses for well-founded < and >#15399
< and >#15399Conversation
< and >< and >
fpvandoorn
approved these changes
Jul 20, 2022
Member
fpvandoorn
left a comment
There was a problem hiding this comment.
LGTM
Since it's a change about basic objects, I'd like someone else to take a look, too.
Vierkantor
approved these changes
Jul 27, 2022
Collaborator
Vierkantor
left a comment
There was a problem hiding this comment.
I've been annoyed at the old situation too. Since there are no objections on Zulip so let's get this merged!
bors r+
bors bot
pushed a commit
that referenced
this pull request
Jul 27, 2022
…15399) # Well-founded typeclasses We introduce a new unbundled typeclass `is_well_founded` for a general well-founded relation, and reducible defs `well_founded_lt` and `well_founded_gt` for well-founded `<` and `>` specifically, to be used as mixins. For now, all we do is specialize only the most basic API on well-founded relations to these new typeclasses. This is just an initial development. If this is merged, a subsequent PR will redefine `is_well_order` in terms of `is_well_founded` (and remove the redundant `irrefl` field). Further PRs will focus on providing all the possible instances for this new typeclass, and actually using it throughout mathlib. Moved from #15023. ## Why do we want this? Here's the part where I justify why this is a good thing we want in mathlib. ### Well-ordered `<` There is a need to talk about well-ordered `<` relations, as a quick search for `is_well_order α (<)` or `is_well_order ι (<)` reveals. The most obvious way to spell this condition out, namely `[has_lt α] [is_well_order α (<)]` is actually the most inconvenient, since none of the results for linear orders are available. You actually need to write `[linear_order α] [is_well_order α (<)]` instead. With this new typeclass, the obvious spelling is now the good one: `[linear_order α] [well_founded_lt α]` ### Redundant typeclasses We actually already at least four typeclasses for the well-foundedness of a concrete relation: `category.noetherian_object`, `category.artinian_object`, `topological_space.noetherian_space`, and `wf_dvd_monoid`. One currently needs to specialize the characterizing properties of a well-founded relation to these separate typeclasses in order to use them. Redefining these typeclasses in terms of these new ones, and making them `reducible def`s, would alleviate this problem. ### Typeclass inference Well-founded relations are actually a nice candidate for typeclass inference, since there's many common constructions that automatically preserve well-foundedness. These include taking inverse images (including `measure` and `order.preimage`), maps through relation embeddings (including subtypes), lexicographic sums or products, and adding a top or bottom element. Many of these are currently provided as instances, but only for well-orders. ### Misleading theorem names Perhaps the most useful result on well-founded relations is that every nonempty set has a minimum - when you view the relation as `<`, that is. This leads to misleading theorem names when you're using them on a well-founded `>` relation. With this refactor, we could simply specialize `well_founded.min` into `well_founded_gt.max` and end up with clearer theorem statements. On a related note, given a linear order and a well-founded `<` relation, we can rephrase `well_founded.not_lt_min` into the much more convenient `well_founded_lt.min_le`.
|
Pull request successfully merged into master. Build succeeded: |
< and >< and >
bottine
pushed a commit
to bottine/mathlib
that referenced
this pull request
Jul 30, 2022
…eanprover-community#15399) # Well-founded typeclasses We introduce a new unbundled typeclass `is_well_founded` for a general well-founded relation, and reducible defs `well_founded_lt` and `well_founded_gt` for well-founded `<` and `>` specifically, to be used as mixins. For now, all we do is specialize only the most basic API on well-founded relations to these new typeclasses. This is just an initial development. If this is merged, a subsequent PR will redefine `is_well_order` in terms of `is_well_founded` (and remove the redundant `irrefl` field). Further PRs will focus on providing all the possible instances for this new typeclass, and actually using it throughout mathlib. Moved from leanprover-community#15023. ## Why do we want this? Here's the part where I justify why this is a good thing we want in mathlib. ### Well-ordered `<` There is a need to talk about well-ordered `<` relations, as a quick search for `is_well_order α (<)` or `is_well_order ι (<)` reveals. The most obvious way to spell this condition out, namely `[has_lt α] [is_well_order α (<)]` is actually the most inconvenient, since none of the results for linear orders are available. You actually need to write `[linear_order α] [is_well_order α (<)]` instead. With this new typeclass, the obvious spelling is now the good one: `[linear_order α] [well_founded_lt α]` ### Redundant typeclasses We actually already at least four typeclasses for the well-foundedness of a concrete relation: `category.noetherian_object`, `category.artinian_object`, `topological_space.noetherian_space`, and `wf_dvd_monoid`. One currently needs to specialize the characterizing properties of a well-founded relation to these separate typeclasses in order to use them. Redefining these typeclasses in terms of these new ones, and making them `reducible def`s, would alleviate this problem. ### Typeclass inference Well-founded relations are actually a nice candidate for typeclass inference, since there's many common constructions that automatically preserve well-foundedness. These include taking inverse images (including `measure` and `order.preimage`), maps through relation embeddings (including subtypes), lexicographic sums or products, and adding a top or bottom element. Many of these are currently provided as instances, but only for well-orders. ### Misleading theorem names Perhaps the most useful result on well-founded relations is that every nonempty set has a minimum - when you view the relation as `<`, that is. This leads to misleading theorem names when you're using them on a well-founded `>` relation. With this refactor, we could simply specialize `well_founded.min` into `well_founded_gt.max` and end up with clearer theorem statements. On a related note, given a linear order and a well-founded `<` relation, we can rephrase `well_founded.not_lt_min` into the much more convenient `well_founded_lt.min_le`.
robertylewis
pushed a commit
that referenced
this pull request
Aug 2, 2022
…15399) # Well-founded typeclasses We introduce a new unbundled typeclass `is_well_founded` for a general well-founded relation, and reducible defs `well_founded_lt` and `well_founded_gt` for well-founded `<` and `>` specifically, to be used as mixins. For now, all we do is specialize only the most basic API on well-founded relations to these new typeclasses. This is just an initial development. If this is merged, a subsequent PR will redefine `is_well_order` in terms of `is_well_founded` (and remove the redundant `irrefl` field). Further PRs will focus on providing all the possible instances for this new typeclass, and actually using it throughout mathlib. Moved from #15023. ## Why do we want this? Here's the part where I justify why this is a good thing we want in mathlib. ### Well-ordered `<` There is a need to talk about well-ordered `<` relations, as a quick search for `is_well_order α (<)` or `is_well_order ι (<)` reveals. The most obvious way to spell this condition out, namely `[has_lt α] [is_well_order α (<)]` is actually the most inconvenient, since none of the results for linear orders are available. You actually need to write `[linear_order α] [is_well_order α (<)]` instead. With this new typeclass, the obvious spelling is now the good one: `[linear_order α] [well_founded_lt α]` ### Redundant typeclasses We actually already at least four typeclasses for the well-foundedness of a concrete relation: `category.noetherian_object`, `category.artinian_object`, `topological_space.noetherian_space`, and `wf_dvd_monoid`. One currently needs to specialize the characterizing properties of a well-founded relation to these separate typeclasses in order to use them. Redefining these typeclasses in terms of these new ones, and making them `reducible def`s, would alleviate this problem. ### Typeclass inference Well-founded relations are actually a nice candidate for typeclass inference, since there's many common constructions that automatically preserve well-foundedness. These include taking inverse images (including `measure` and `order.preimage`), maps through relation embeddings (including subtypes), lexicographic sums or products, and adding a top or bottom element. Many of these are currently provided as instances, but only for well-orders. ### Misleading theorem names Perhaps the most useful result on well-founded relations is that every nonempty set has a minimum - when you view the relation as `<`, that is. This leads to misleading theorem names when you're using them on a well-founded `>` relation. With this refactor, we could simply specialize `well_founded.min` into `well_founded_gt.max` and end up with clearer theorem statements. On a related note, given a linear order and a well-founded `<` relation, we can rephrase `well_founded.not_lt_min` into the much more convenient `well_founded_lt.min_le`.
khwilson
pushed a commit
that referenced
this pull request
Aug 2, 2022
…15399) # Well-founded typeclasses We introduce a new unbundled typeclass `is_well_founded` for a general well-founded relation, and reducible defs `well_founded_lt` and `well_founded_gt` for well-founded `<` and `>` specifically, to be used as mixins. For now, all we do is specialize only the most basic API on well-founded relations to these new typeclasses. This is just an initial development. If this is merged, a subsequent PR will redefine `is_well_order` in terms of `is_well_founded` (and remove the redundant `irrefl` field). Further PRs will focus on providing all the possible instances for this new typeclass, and actually using it throughout mathlib. Moved from #15023. ## Why do we want this? Here's the part where I justify why this is a good thing we want in mathlib. ### Well-ordered `<` There is a need to talk about well-ordered `<` relations, as a quick search for `is_well_order α (<)` or `is_well_order ι (<)` reveals. The most obvious way to spell this condition out, namely `[has_lt α] [is_well_order α (<)]` is actually the most inconvenient, since none of the results for linear orders are available. You actually need to write `[linear_order α] [is_well_order α (<)]` instead. With this new typeclass, the obvious spelling is now the good one: `[linear_order α] [well_founded_lt α]` ### Redundant typeclasses We actually already at least four typeclasses for the well-foundedness of a concrete relation: `category.noetherian_object`, `category.artinian_object`, `topological_space.noetherian_space`, and `wf_dvd_monoid`. One currently needs to specialize the characterizing properties of a well-founded relation to these separate typeclasses in order to use them. Redefining these typeclasses in terms of these new ones, and making them `reducible def`s, would alleviate this problem. ### Typeclass inference Well-founded relations are actually a nice candidate for typeclass inference, since there's many common constructions that automatically preserve well-foundedness. These include taking inverse images (including `measure` and `order.preimage`), maps through relation embeddings (including subtypes), lexicographic sums or products, and adding a top or bottom element. Many of these are currently provided as instances, but only for well-orders. ### Misleading theorem names Perhaps the most useful result on well-founded relations is that every nonempty set has a minimum - when you view the relation as `<`, that is. This leads to misleading theorem names when you're using them on a well-founded `>` relation. With this refactor, we could simply specialize `well_founded.min` into `well_founded_gt.max` and end up with clearer theorem statements. On a related note, given a linear order and a well-founded `<` relation, we can rephrase `well_founded.not_lt_min` into the much more convenient `well_founded_lt.min_le`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Well-founded typeclasses
We introduce a new unbundled typeclass
is_well_foundedfor a general well-founded relation, and reducible defswell_founded_ltandwell_founded_gtfor well-founded<and>specifically, to be used as mixins. For now, all we do is specialize only the most basic API on well-founded relations to these new typeclasses.This is just an initial development. If this is merged, a subsequent PR will redefine
is_well_orderin terms ofis_well_founded(and remove the redundantirreflfield). Further PRs will focus on providing all the possible instances for this new typeclass, and actually using it throughout mathlib.Moved from #15023.
Why do we want this?
Here's the part where I justify why this is a good thing we want in mathlib.
Well-ordered
<There is a need to talk about well-ordered
<relations, as a quick search foris_well_order α (<)oris_well_order ι (<)reveals. The most obvious way to spell this condition out, namely[has_lt α] [is_well_order α (<)]is actually the most inconvenient, since none of the results for linear orders are available. You actually need to write[linear_order α] [is_well_order α (<)]instead.With this new typeclass, the obvious spelling is now the good one:
[linear_order α] [well_founded_lt α]Redundant typeclasses
We actually already at least four typeclasses for the well-foundedness of a concrete relation:
category.noetherian_object,category.artinian_object,topological_space.noetherian_space, andwf_dvd_monoid. One currently needs to specialize the characterizing properties of a well-founded relation to these separate typeclasses in order to use them. Redefining these typeclasses in terms of these new ones, and making themreducible defs, would alleviate this problem.Typeclass inference
Well-founded relations are actually a nice candidate for typeclass inference, since there's many common constructions that automatically preserve well-foundedness. These include taking inverse images (including
measureandorder.preimage), maps through relation embeddings (including subtypes), lexicographic sums or products, and adding a top or bottom element. Many of these are currently provided as instances, but only for well-orders.Misleading theorem names
Perhaps the most useful result on well-founded relations is that every nonempty set has a minimum - when you view the relation as
<, that is. This leads to misleading theorem names when you're using them on a well-founded>relation. With this refactor, we could simply specializewell_founded.minintowell_founded_gt.maxand end up with clearer theorem statements.On a related note, given a linear order and a well-founded
<relation, we can rephrasewell_founded.not_lt_mininto the much more convenientwell_founded_lt.min_le.