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
feat(algebra/magma_algebra): define the magma algebra associated to a magma and a semiring of coefficients #6571
Conversation
⏳ Alright! Looks like we need to wait for some dependencies: 💡 Don't worry, I will continue watching the list above and keep this comment updated. To add or remove a dependency please update this issue/PR description. Brought to you by Dependent Issues (:robot: ). Happy coding! |
be5e7a9
to
08440a3
Compare
Despite initial reluctance, I am beginning to be persuaded. The names are not serious suggestions, especially as if this works, what we are really defining is non-unital algebras since we can make the existing `algebra` definition allow for non-associativity for free. For now I just want to see whether this compiles.
_Probably_ a more useful set of ancestors.
For reasons I haven't tried to understand this breaks the proof of `multiset.prod_map_add`. Having seen this, I think it's best to revert this since there's already plenty of surface area in these changes to break things.
If this doesn't work, I think I'll give up on inserting `mul_one_class` / `add_zero_class` into the `monoid` / `add_monoid` definitions.
The most recent build failure (topology/locally_constant/algebra.lean:52:73) has persuaded me to abandon this part of the work. It could be done but it's too much of a diversion / time sink in what is already a tangent.
… magma and a semiring of coefficients
Now that we have |
/-- The embedding of a magma into its magma algebra. -/ | ||
def of : mul_hom M (magma_algebra R M) := |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this statement and lift
below are currently not stated for monoid_algebra
, but we could probably add them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is worth adding of
and lift
here to monoid_algebra
. I claim this justifies the creation of:
set_option old_structure_cmd true
structure linear_mul_hom (R : Type u) (A : Type v) (B : Type w)
[semiring R] [non_unital_non_assoc_semiring A] [non_unital_non_assoc_semiring B]
[module R A] [module R B] extends A →ₗ[R] B, mul_hom A B
By using module
instead of algebra
in this definition, we avoid the algebra
issue and lose nothing really.
Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@riccardobrasca actually could have done with an object of this type very recently, for linear_map.fst
and linear_map.snd
.
I think non_unital_alg_hom
might be a better name for that structure, and it suggests we should probably have non_unital_ring_hom
too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding a new bundled hom comes with lots of boilerplate unfortunately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll give it a go!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, yes, I proved needed exactly this for linear_map.inl
and linear_map.snd
!
I'm going to settle its fate today or tomorrow. I had a quick look this morning and I think some of the constructions in |
Closing in favour of #7932 |
Related conversation on Zulip.