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

Fix base ring conversion of non-associative unital algebras #28328

Closed
orlitzky opened this issue Aug 6, 2019 · 15 comments
Closed

Fix base ring conversion of non-associative unital algebras #28328

orlitzky opened this issue Aug 6, 2019 · 15 comments

Comments

@orlitzky
Copy link
Contributor

orlitzky commented Aug 6, 2019

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!

Component: categories

Author: Michael Orlitzky

Branch/Commit: 3d4b6aa

Reviewer: Travis Scrimshaw

Issue created by migration from https://trac.sagemath.org/ticket/28328

@orlitzky orlitzky added this to the sage-8.9 milestone Aug 6, 2019
@orlitzky
Copy link
Contributor Author

orlitzky commented Aug 6, 2019

Commit: bac6258

@orlitzky
Copy link
Contributor Author

orlitzky commented Aug 6, 2019

Branch: u/mjo/ticket/28328

@orlitzky
Copy link
Contributor Author

orlitzky commented Aug 6, 2019

New commits:

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

@orlitzky
Copy link
Contributor Author

orlitzky commented Aug 6, 2019

Author: Michael Orlitzky

@tscrim
Copy link
Collaborator

tscrim commented Aug 9, 2019

comment:2

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.

@orlitzky
Copy link
Contributor Author

orlitzky commented Aug 9, 2019

comment:3

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.

@tscrim
Copy link
Collaborator

tscrim commented Aug 10, 2019

comment:4

Replying to @orlitzky:

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.

@orlitzky
Copy link
Contributor Author

comment:5

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.

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Aug 10, 2019

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

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

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Aug 10, 2019

Changed commit from bac6258 to 3d4b6aa

@orlitzky
Copy link
Contributor Author

comment:7

I pushed a commit to use the category you suggested.

@tscrim
Copy link
Collaborator

tscrim commented Aug 10, 2019

Reviewer: Travis Scrimshaw

@tscrim
Copy link
Collaborator

tscrim commented Aug 10, 2019

comment:8

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.

@orlitzky
Copy link
Contributor Author

comment:9

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.

@vbraun
Copy link
Member

vbraun commented Aug 12, 2019

Changed branch from u/mjo/ticket/28328 to 3d4b6aa

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants