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

Meaning of Modules(R) currently not very clear #16247

Open
darijgr opened this issue Apr 27, 2014 · 11 comments
Open

Meaning of Modules(R) currently not very clear #16247

darijgr opened this issue Apr 27, 2014 · 11 comments

Comments

@darijgr
Copy link
Contributor

darijgr commented Apr 27, 2014

The doc of class Modules currently (#10963) says:

    The category of all modules over a base ring `R`.

    An `R`-module `M` is a left and right `R`-module over a
    commutative ring `R` such that:

    .. math::  r*(x*s) = (r*x)*s \qquad  \forall r,s \in R \text{ and } x \in M

This is not the notion of a module that mathematicians are used to, not even when R is commutative. Instead, this is the definition of an R-R-bimodule. I fear that this is destined to lead to confusion and subtle bugs. For instance, the WithBasis subcategory implements methods like "basis" and "support". But a left R-module basis of an R-R-bimodule might not be a right R-module basis, and even if it is, the supports of one and the same element with respect to it (one time as a left R-module basis, another time as a right one) might be different. I have not seen the WithBasis subcategory being used in problematic cases (i.e., in cases where the left and right structure are different), but I fear that this is bound to eventually happen.

I've run the (short) doctests of src/sage with a commit that adds a warning every time Modules(A) is called for A noncommutative. Here are the relevant results:

https://www.dropbox.com/s/oieg1ig0dliz63s/noncomm.txt

It seems that matrices over noncommutative rings are the main culprit here -- or, rather, matrix spaces being cast as modules over the base rings. I think they should be bimodules, since there is a Bimodules(R, R) category already.

Apparently people have been aware of this for a while; the following warning message is doctested for and not written by me:

    doctest:...: UserWarning: You are constructing a free module
    over a noncommutative ring. Sage does not have a concept
    of left/right and both sided modules, so be careful.
    It's also not guaranteed that all multiplications are
    done from the right side.

(We do have left/right/bi-modules now.)

There are some tracebacks I don't really understand... can it be that some methods in Sage construct matrices consisting of matrices? There's nothing wrong about that; I just think the constructor for the respective matrix spaces should pick the right category for that.

Here are some options:

  • Make Modules only support symmetric modules, i.e. modules M satisfying rx = xr for all r in R and x in M. This is useful almost only for commutative R (in fact, these modules are always modules over the abelianization of R).

  • Make Modules only support R-R-bimodules which are direct sums of copies of the R-R-bimodule R. This allows for doing most things that can be done in the commutative case, and examples are polynomial rings over noncommutative rings, matrix spaces etc. -- I actually like this category. The only problem is that it is more of a "ModulesWithBasis" category than a "Modules" category.

  • Make Modules only support R-R-bimodules which are sums (not necessarily direct) of copies of the R-R-bimodule R. This looks like a reasonable category but I know almost none of its properties.

Depends on #10963

CC: @nthiery @simon-king-jena @orlitzky

Component: algebra

Keywords: modules, associativity, matrices

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

@darijgr darijgr added this to the sage-6.2 milestone Apr 27, 2014
@darijgr
Copy link
Contributor Author

darijgr commented Apr 27, 2014

Changed keywords from modules, associativity to modules, associativity, matrices

@darijgr

This comment has been minimized.

@darijgr
Copy link
Contributor Author

darijgr commented Apr 27, 2014

Dependencies: 10963

@darijgr

This comment has been minimized.

@darijgr

This comment has been minimized.

@nthiery
Copy link
Contributor

nthiery commented Apr 27, 2014

comment:4

Thanks for exploring how to clean this up.

Just for the record: we have had left/right/bimodules since 2009 and probably even before. Also, at this point, they are just categories over a base ring, not functorial constructions.

One thing to check is how this was handled in Axiom. MuPAD was roughly as here: on the lousy side in the non commutative case.

@darijgr
Copy link
Contributor Author

darijgr commented Apr 29, 2014

Changed dependencies from 10963 to #10963

@darijgr

This comment has been minimized.

@darijgr darijgr changed the title Abuse of Modules() for modules over noncommutative rings Meaning of Modules(R) currently not very clear Apr 29, 2014
@sagetrac-vbraun-spam sagetrac-vbraun-spam mannequin modified the milestones: sage-6.2, sage-6.3 May 6, 2014
@sagetrac-vbraun-spam sagetrac-vbraun-spam mannequin modified the milestones: sage-6.3, sage-6.4 Aug 10, 2014
@mkoeppe mkoeppe modified the milestones: sage-6.4, sage-9.3 Aug 17, 2020
@mkoeppe
Copy link
Member

mkoeppe commented Feb 13, 2021

comment:9

Setting new milestone based on a cursory review of ticket status, priority, and last modification date.

@mkoeppe mkoeppe modified the milestones: sage-9.3, sage-9.4 Feb 13, 2021
@mkoeppe mkoeppe modified the milestones: sage-9.4, sage-9.5 Jul 19, 2021
@pjbruin
Copy link
Contributor

pjbruin commented Jul 27, 2021

comment:11

I got here through #32250, in which I propose a precise definition for (magmatic) algebras over an associative unital ring, and #32250 comment:2.

My personal preferred solution would be a variant of the first option in the ticket description: make Modules only support commutative base rings, and define a module over a commutative ring R to be a symmetric (R, R)-bimodule. This feels most in line with how modules are currently used in Sage. Supporting non-commutative rings with this definition would probably be more confusing than justified by the little amount of added functionality.

@orlitzky
Copy link
Contributor

comment:12

Replying to @pjbruin:

My personal preferred solution would be a variant of the first option in the ticket description: make Modules only support commutative base rings, and define a module over a commutative ring R to be a symmetric (R, R)-bimodule. This feels most in line with how modules are currently used in Sage. Supporting non-commutative rings with this definition would probably be more confusing than justified by the little amount of added functionality.

I agree. This is what the existing Modules? docstring is trying to say. The cited UserWarning more or less says that your ring should be commutative, and that your left- and right-module actions had better be the same. The definition should match what Sage is actually capable of.

This would leave us with new problem though, that of defining a symmetric bimodule within sage. Maybe we should just be explicit about the axioms instead of using that term.

@mkoeppe mkoeppe modified the milestones: sage-9.5, sage-9.6 Dec 14, 2021
@mkoeppe mkoeppe removed this from the sage-9.6 milestone Apr 1, 2022
@mkoeppe mkoeppe added this to the sage-9.7 milestone Apr 1, 2022
@mkoeppe mkoeppe modified the milestones: sage-9.7, sage-9.8 Aug 31, 2022
@mkoeppe mkoeppe removed this from the sage-9.8 milestone Jan 29, 2023
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

5 participants