[ add ] Algebra.Construct.Centre.X of an algebra X, following #2863#2885
[ add ] Algebra.Construct.Centre.X of an algebra X, following #2863#2885jamesmckinna wants to merge 24 commits intoagda:masterfrom
Algebra.Construct.Centre.X of an algebra X, following #2863#2885Conversation
JacquesCarette
left a comment
There was a problem hiding this comment.
Only change needed: delete commented out code.
|
This is ready to go, so if someone is willing either to offer an additional review, or else support merging as-is, please do so! |
|
I guess we need to explicitly ping people like @Taneb and @MatthewDaggitt since I've already done my part! |
|
So hopefully I've now dealt with the feedback above, EXCEPT:
I suggest it's better to tackle these downstream! UPDATED: I've now been persuaded to take a more maximalist approach to exports ... not clear to me, until these constructions are exercised in anger, that we see exactly what is and is not necessary here. |
JacquesCarette
left a comment
There was a problem hiding this comment.
I'm still good on this. Only need @gallais to re-review.
|
@gallais back to you now... |
This PR is a clean do-over of #2863 , avoiding any dependency/coupling on
either #2872 or#2854 .Issues:
Centreof aGroupetc. #2863 ie. the centre of aGroupis defined in terms of the centre of its underlyingMonoid, iterated down as far as a bareCenterCentretype based on the (components of) an underlyingRawMagma.Sub.X(eg as in [ draft ] Alternative design for sub- and quotient-(Abelian)Groups #2859 ) until the discussion on that PR and Normal subgroups and quotient groups #2854 stabilises with an agreed hierarchy for such sub-algebras.Relation.Binary.Morphism.Construct.On#2872 and/or [ rename/deprecate ] RenameAlgebra.Properties.Monoid.ε-comm#2883 get merged, etc. UPDATED: DONEAlgebra.Construct.Centre.Ring(and develop the infrastructure for the 'missing' intermediate algebras...)NB. the hierarchy of
IsXMonomorphismstructures unfortunately (;-)/!?) goes against the grain of how these things are all built up successively here, so downstream we might think about refactoring that hierarchy, or else introducing more 'smart' constructors for such things.