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

opposite rings #1940

Merged
merged 13 commits into from
May 2, 2024
Merged

opposite rings #1940

merged 13 commits into from
May 2, 2024

Conversation

Alizter
Copy link
Collaborator

@Alizter Alizter commented Apr 30, 2024

This is a start on #1921. I've opened it now so I can get some comments before starting ideals.

TODO

  • deduplicate theory of ideals
  • right modules (perhaps in a later PR?)

<!-- ps-id: 4377567b-f2e2-437c-aae2-02b81f1b088c -->

Signed-off-by: Ali Caglayan <[email protected]>
@Alizter Alizter force-pushed the ps/rr/opposite_rings branch from 884c11c to b0c83eb Compare April 30, 2024 22:44
test/Algebra/Rings/Ring.v Outdated Show resolved Hide resolved
@Alizter
Copy link
Collaborator Author

Alizter commented May 1, 2024

Mystery solved: Coq makes the :> fields in records "reversible" meaning that there is a term inserted during elaboration. We don't see this since we didn't include the following in our prelude:

#[universes(polymorphic=yes)] Definition ReverseCoercionSource (T : Type) := T.
#[universes(polymorphic=yes)] Definition ReverseCoercionTarget (T : Type) := T.
#[warning="-uniform-inheritance", reversible=no, universes(polymorphic=yes)]
Coercion reverse_coercion {T' T} (x' : T') (x : ReverseCoercionSource T)
  : ReverseCoercionTarget T' := x'.
Register reverse_coercion as core.coercion.reverse_coercion.

In this case, our CRing is being coerced (by a reversible coercion) to Ring. Then the involution happens definitionally giving us the same Ring. Coq then says this was coerced by a reversible coercion so let me insert the inverse and brings it back to a CRing.

I believe this is unintentional for this coercion to be marked as reversible and has been fixed upstream. coq/coq#18705 Edit: actually this won't fix this, but :> should always be regarded as reversible from now on. Not a big issue, but something to keep in mind.

We should add the code above so that Set Printing All better displays reversed coercions.

Thanks @SkySkimmer for explaining the behaviour on Zulip.

Signed-off-by: Ali Caglayan <[email protected]>
@jdchristensen
Copy link
Collaborator

Ok, that's interesting. In any case, I still think we want to define crng_op and should change test2 to use it.

@Alizter
Copy link
Collaborator Author

Alizter commented May 2, 2024

I simplified the theory of ideals using the opposite ring. However in doing so I redefined the quotient/colon ideal as an intersection of the "left" and "right" versions. This has made the entire thing much more complicated so I don't know what to do with it.

I have scoured all the literature I know on noncommutative rings and I couldn't find anything about colon ideals in this generality. It only seems to appear in commutative algebra/algebraic geometry, in fact this was my original motivation for adding them as they describe complements in the Zariski topology.

I'm tempted to just move all the colon ideal stuff to CRing and only have the single two-sided definition.

@Alizter Alizter marked this pull request as ready for review May 2, 2024 02:41
@jdchristensen
Copy link
Collaborator

I simplified the theory of ideals using the opposite ring.

That turned out quite well!

I'm tempted to just move all the colon ideal stuff to CRing and only have the single two-sided definition.

I don't know much about this, but specializing to commutative rings seems fine to me, if that's all you can find written about this.

@Alizter Alizter requested a review from jdchristensen May 2, 2024 16:38
Comment on lines 428 to 433
- exact (fun x y z => mult_assoc_opp z y x).
- exact ri.
- exact li.
- exact (fun x y z => rd y z x).
- exact (fun x y z => ld z x y).
- exact (fun x y z => mult_assoc z y x).
Copy link
Collaborator

Choose a reason for hiding this comment

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

If we have mult_assoc_opp take its arguments in the reverse order, then lines 428 and 433 will become simpler, and so rng_op will be slightly smaller. Probably worth it. For Is1Cat too.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Same for the distributivity laws (which also comes up in my last commit, where I needed a fun x y => ...).

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I've changed mult_assoc_opp like you've suggested but I don't think its worth touching the distributivity laws in general. Your specific case isn't actually using the mathclasses distributivity but the ring law version.

However changing the order of those arguments will be confusing during use. The opp field isn't supposed to actually be used by anybody anyway.

@jdchristensen
Copy link
Collaborator

Do you still want to simplify colon ideals? It's ok with me either way.

@Alizter
Copy link
Collaborator Author

Alizter commented May 2, 2024

I think I won't touch it for the moment.

@jdchristensen
Copy link
Collaborator

LGTM

@Alizter Alizter merged commit 2ac6280 into HoTT:master May 2, 2024
23 checks passed
@Alizter Alizter deleted the ps/rr/opposite_rings branch May 2, 2024 19:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants