Opened 2 years ago

Closed 2 years ago

#28328 closed defect (fixed)

Fix base ring conversion of non-associative unital algebras

Reported by: mjo Owned by:
Priority: minor Milestone: sage-8.9
Component: categories Keywords:
Cc: Merged in:
Authors: Michael Orlitzky Reviewers: Travis Scrimshaw
Report Upstream: N/A Work issues:
Branch: 3d4b6aa (Commits, GitHub, GitLab) Commit: 3d4b6aa6808d633888142e6cd3b99c68a7e91779
Dependencies: Stopgaps:

Status badges

Description

When trying to construct a non-associative unital algebra, we get a boom:

sage: from sage.categories.magmatic_algebras import MagmaticAlgebras
sage: C = MagmaticAlgebras(QQ).WithBasis().Unital()
sage: F = CombinatorialFreeModule(QQ, (1,), category=C)
...
ValueError: Free module generated by {1} over Rational Field is not in Category of rings

Where do rings come into play? Line 107 in unital_algebras.py:

H = Hom(base_ring, self, Rings()) # TODO: non associative ring!

Change History (10)

comment:1 Changed 2 years ago by mjo

  • Authors set to Michael Orlitzky
  • Branch set to u/mjo/ticket/28328
  • Commit set to bac6258192ee0c471b0b9ef7101d2388b211794d
  • Status changed from new to needs_review

New commits:

bac6258Trac #28328: fix base ring coercions for non-associative UnitalAlgebras.

comment:2 follow-up: Changed 2 years ago by tscrim

I do not quite agree with the comment in the else: part (because I also do not agree with the original comment). Mainly, as an algebra over what? Well, we probably should have that that every ring is an algebra over itself, but I am a little less sure of the axioms of an algebra over a non-associative ring. I think that requires more care in general, but it is a little too far from my expertise to say for certain. Do you know of any references about this?

So I think Magmas().Unital() is good, but you can also use the join category with CommutativeAdditiveGroups() and add in the distributive axiom to make it have more of the properties you want/expect.

comment:3 in reply to: ↑ 2 ; follow-up: Changed 2 years ago by mjo

Replying to tscrim:

I do not quite agree with the comment in the else: part (because I also do not agree with the original comment). Mainly, as an algebra over what? Well, we probably should have that that every ring is an algebra over itself, but I am a little less sure of the axioms of an algebra over a non-associative ring. I think that requires more care in general, but it is a little too far from my expertise to say for certain. Do you know of any references about this?

In Sage, all rings are associative, so we don't have to worry about that.

Ultimately, all this function wants to do is construct a function that takes a scalar (in the base ring) to the same multiple of the algebra's unit element (in the algebra). So, for example, "r" maps to "r*I" if "I" is the algebra's multiplicative identity. The problem is that, since this is a coercion, the aforementioned function needs to be a morphism, and thus it needs to live in some category/homset. Which one? A priori, the smallest one that works: and since this is a method on unital algebras, the category of unital algebras would be perfect. But, alas, not every ring lives in the category of unital algebras in Sage, so that category won't work, and we have to weasel around the issue.

Like you said, every (associative) ring should be an (associative) unital algebra over itself. The category of magmatic algebras is not *necessarily* associative, but that doesn't matter. Since e.g. the rationals form an associative unital algebra over themselves, they also form a not-necessarily-associative unital algebra. So that category *should* work, and is why I repeated the comment in the else: clause.

So I think Magmas().Unital() is good, but you can also use the join category with CommutativeAdditiveGroups() and add in the distributive axiom to make it have more of the properties you want/expect.

The category here is only used while building the parent homset of the coercion that gets invoked in e.g. A(3). Is that map or its homset even user-visible? Your category is more accurate, but it feels like overkill if the category information is essentially tossed out as soon as the algebra is constructed. I'm willing to change it in any case.

comment:4 in reply to: ↑ 3 ; follow-up: Changed 2 years ago by tscrim

Replying to mjo:

Replying to tscrim:

I do not quite agree with the comment in the else: part (because I also do not agree with the original comment). Mainly, as an algebra over what? Well, we probably should have that that every ring is an algebra over itself, but I am a little less sure of the axioms of an algebra over a non-associative ring. I think that requires more care in general, but it is a little too far from my expertise to say for certain. Do you know of any references about this?

In Sage, all rings are associative, so we don't have to worry about that.

Ultimately, all this function wants to do is construct a function that takes a scalar (in the base ring) to the same multiple of the algebra's unit element (in the algebra). So, for example, "r" maps to "r*I" if "I" is the algebra's multiplicative identity. The problem is that, since this is a coercion, the aforementioned function needs to be a morphism, and thus it needs to live in some category/homset. Which one? A priori, the smallest one that works: and since this is a method on unital algebras, the category of unital algebras would be perfect. But, alas, not every ring lives in the category of unital algebras in Sage, so that category won't work, and we have to weasel around the issue.

Like you said, every (associative) ring should be an (associative) unital algebra over itself. The category of magmatic algebras is not *necessarily* associative, but that doesn't matter. Since e.g. the rationals form an associative unital algebra over themselves, they also form a not-necessarily-associative unital algebra. So that category *should* work, and is why I repeated the comment in the else: clause.

What I am asking about is the notion of an algebra over a non-associative ring. This is far less structured from what I can gather from a quick internet search. For example, an algebra A over a Lie algebra L should satisfy

   [x,y]a = x(ya) - y(xa)

for all x,y \in L and a \in A because you also want it to be a Lie algebra module/representation. In this case, it makes it equivalently an algebra over the universal enveloping algebra of L (in other words, over an equivalent associative algebra). In short, I am asking what the analogous axiom for the usual scalar axiom (xy)v = x(yv) should be. Just require that the base should have an (natural) action? I am guessing you have a specific use-case for this and likely some extra structure. Maybe this is not important, but I am slightly worried about it being an honest morphism. In general, I do agree with you that it should work.

So I think Magmas().Unital() is good, but you can also use the join category with CommutativeAdditiveGroups() and add in the distributive axiom to make it have more of the properties you want/expect.

The category here is only used while building the parent homset of the coercion that gets invoked in e.g. A(3). Is that map or its homset even user-visible? Your category is more accurate, but it feels like overkill if the category information is essentially tossed out as soon as the algebra is constructed. I'm willing to change it in any case.

So for R acting on the R-algebra A, you ask for the coercion map from R to A you get the morphism. This means the homset is also available to the user. I think it is better to be more explicit with the category when possible. It also makes it more future-proof should extra features get added.

comment:5 in reply to: ↑ 4 Changed 2 years ago by mjo

Replying to tscrim:

What I am asking about is the notion of an algebra over a non-associative ring. This is far less structured from what I can gather from a quick internet search... I am guessing you have a specific use-case for this and likely some extra structure. Maybe this is not important, but I am slightly worried about it being an honest morphism.

But where does the non-associative ring come into play? I certainly don't have one in mind.

The base_ring in this section of the code is really a ring as far as sage is concerned, and ring multiplication is associative by definition in sage. My algebra multiplication isn't associative, so my algebra with vector addition/multiplication does *not* form a ring in sage -- that's why the existing "if" case doesn't work for me. But my algebra is still a magmatic algebra, since MagmaticAlgebras(...) are not necessarily associative.

Mathematically, the base ring should be an (associative) algebra over itself. Thus it would also be a non-necessarily-associative algebra over itself, and a morphism of not-necessarily-associative algebras would suffice. I don't think there's anything intricate to verify here: the base ring is still associative, it's only the algebra multiplication that isn't.

FWIW, my Euclidean Jordan algebra code is public,

http://gitweb.michael.orlitzky.com/?p=sage.d.git

and that's the only use case I have in mind. For now I still have the _no_generic_basering_coercion = True hack in there.

So for R acting on the R-algebra A, you ask for the coercion map from R to A you get the morphism. This means the homset is also available to the user. I think it is better to be more explicit with the category when possible. It also makes it more future-proof should extra features get added.

Ok, no problem.

comment:6 Changed 2 years ago by git

  • Commit changed from bac6258192ee0c471b0b9ef7101d2388b211794d to 3d4b6aa6808d633888142e6cd3b99c68a7e91779

Branch pushed to git repo; I updated commit sha1. New commits:

3d4b6aaTrac #28328: use a smaller category for unital algebra base ring morphism.

comment:7 Changed 2 years ago by mjo

I pushed a commit to use the category you suggested.

comment:8 Changed 2 years ago by tscrim

  • Reviewers set to Travis Scrimshaw
  • Status changed from needs_review to positive_review

Okay, that was a bit where my confusion was coming from. I was thinking you were allowing the base ring to not necessarily be associative. So that should still implicitly be there. Thanks for making the changes. I am still not very convinced by the else comment, but it makes the situation no worse than what is currently there. So I am going to set a positive review.

comment:9 Changed 2 years ago by mjo

Thanks, that comment is not particularly important to me, so if you have another suggestion I'm willing to change it. Ultimately, I think the solution will be to make all (associative) sage rings an algebra over themselves -- then the whole problem goes away.

comment:10 Changed 2 years ago by vbraun

  • Branch changed from u/mjo/ticket/28328 to 3d4b6aa6808d633888142e6cd3b99c68a7e91779
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.