[Merged by Bors] - feat: IsROrC.toStarOrderedRing as a scoped instance#6391
[Merged by Bors] - feat: IsROrC.toStarOrderedRing as a scoped instance#6391eric-wieser wants to merge 28 commits intomasterfrom
Conversation
Co-authored-by: Eric Wieser <wieser.eric@gmail.com>
…ty/mathlib4 into IsROrCStarOrderedRing
Mathlib/Analysis/NormedSpace/Star/ContinuousFunctionalCalculus.lean
Outdated
Show resolved
Hide resolved
8b6cd49 to
d044d2e
Compare
j-loreaux
left a comment
There was a problem hiding this comment.
I'm content with this while we decide whether we want a globally available partial order on ℂ.
However, please add a docstring to the StarOrderedRing ℝ instance in Mathlib.Data.Real.Sqrt saying that it exists separate from the IsROrC instance because that one is blocked behind the ComplexOrder scope and we want it to be availble globally.
Mathlib/Data/IsROrC/Basic.lean
Outdated
| namespace IsROrC | ||
|
|
||
| open scoped ComplexOrder in | ||
| /-- Note this is only an instance with `open scoped ComplexOrder`. -/ |
There was a problem hiding this comment.
I think it would be nice to keep this portion of the docstring from the ℂ instance:
| /-- Note this is only an instance with `open scoped ComplexOrder`. -/ | |
| /-- With `z ≤ w` iff `w - z` is real and nonnegative, `IsROrC K` is a star ordered ring. | |
| (That is, a star ring in which the nonnegative elements are those of the form `star z * z`.) | |
| Note this is only an instance with `open scoped ComplexOrder`. -/ |
|
bors d+ |
|
✌️ eric-wieser can now approve this pull request. To approve and merge a pull request, simply reply with |
|
This PR/issue depends on:
|
| rw [lt_iff_re_im, map_zero] at hz hw ⊢ | ||
| simp [mul_re, mul_im, ← hz.2, ← hw.2, mul_pos hz.1 hw.1] | ||
| mul_comm := by intros; apply ext <;> ring_nf | ||
|
|
There was a problem hiding this comment.
Oops, I missed the instance line here
|
This still LGTM after the changes. Feel free to merge. |
|
bors merge I'm pretty confident the instance line won't make any difference to CI |
With `open scoped ComplexOrder`, we current have `StarOrderedRing Complex` (as well as some other order instances). With this PR, that scope puts the same order on `K` where `IsROrC K`. There is an ongoing discussion about whether opening the scope should be required, but there is no need to address that concern simultaneously with improving behavior when the scope is *already* open. There also seems to be fewer downstream instance resolution issues to resolve by leaving it in the scope. Co-authored-by: Eric Wieser <wieser.eric@gmail.com>
|
Pull request successfully merged into master. Build succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page. |
With `open scoped ComplexOrder`, we current have `StarOrderedRing Complex` (as well as some other order instances). With this PR, that scope puts the same order on `K` where `IsROrC K`. There is an ongoing discussion about whether opening the scope should be required, but there is no need to address that concern simultaneously with improving behavior when the scope is *already* open. There also seems to be fewer downstream instance resolution issues to resolve by leaving it in the scope. Co-authored-by: Eric Wieser <wieser.eric@gmail.com>
With
open scoped ComplexOrder, we current haveStarOrderedRing Complex(as well as some other order instances).With this PR, that scope puts the same order on
KwhereIsROrC K.There is an ongoing discussion about whether opening the scope should be required, but there is no need to address that concern simultaneously with improving behavior when the scope is already open. There also seems to be fewer downstream instance resolution issues to resolve by leaving it in the scope.
This is a more conservative version of #6210, which does not simultaneously remove the
ComplexOrderscope.