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
Comments
Commit: |
Branch: u/mjo/ticket/28328 |
New commits:
|
Author: Michael Orlitzky |
comment:2
I do not quite agree with the comment in the So I think |
comment:3
Replying to @tscrim:
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
The category here is only used while building the parent homset of the coercion that gets invoked in e.g. |
comment:4
Replying to @orlitzky:
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
for all
So for |
comment:5
Replying to @tscrim:
But where does the non-associative ring come into play? I certainly don't have one in mind. The 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
Ok, no problem. |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:7
I pushed a commit to use the category you suggested. |
Reviewer: Travis Scrimshaw |
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. |
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. |
Changed branch from u/mjo/ticket/28328 to |
When trying to construct a non-associative unital algebra, we get a boom:
Where do rings come into play? Line 107 in unital_algebras.py:
Component: categories
Author: Michael Orlitzky
Branch/Commit:
3d4b6aa
Reviewer: Travis Scrimshaw
Issue created by migration from https://trac.sagemath.org/ticket/28328
The text was updated successfully, but these errors were encountered: