search

sagemath / sage

Main repository of SageMath
https://www.sagemath.org
Other
1.34k stars 452 forks source link

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

Open darijgr opened 10 years ago

darijgr commented 10 years ago

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:

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 commented 10 years ago

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

darijgr commented 10 years ago

Description changed:

--- 
+++ 
@@ -1,4 +1,4 @@
-We have `LeftModules` and `RightModules` functorial constructions (not sure if since #10963 or already before), and they should be used. `Modules` implements left and right multiplication to be *the same*, which causes misleading and counterintuitive non-associativity issues.
+We have `LeftModules` and `RightModules` functorial constructions, and they should be used. `Modules` implements left and right multiplication to be *the same*, which causes misleading and counterintuitive non-associativity issues.

 I'm currently running the (short) doctests of src/sage with a commit that adds a warning every time Modules(A) is called for A noncommutative. I'll post the results once it's done. So far:

@@ -12,3 +12,22 @@
 Doctests interrupted: 231/2069 files tested
 ----------------------------------------------------------------------

+It seems that matrices over noncommutative rings are the main culprit here -- or, rather, matrix spaces being cast as modules over the base rings. They should be bimodules! The reason why this doesn't blow up in the user's face (well, as far as I can tell) is that (I guess) the matrix space classes override the * operator to do the right thing instead of use the defaults from the Modules category. + +Apparently people have been aware of this for a while; the following warning message is doctested for and not written by me: + +```

darijgr commented 10 years ago

Dependencies: 10963

darijgr commented 10 years ago

Description changed:

--- 
+++ 
@@ -12,7 +12,7 @@
 Doctests interrupted: 231/2069 files tested
 ----------------------------------------------------------------------

-It seems that matrices over noncommutative rings are the main culprit here -- or, rather, matrix spaces being cast as modules over the base rings. They should be bimodules! The reason why this doesn't blow up in the user's face (well, as far as I can tell) is that (I guess) the matrix space classes override the * operator to do the right thing instead of use the defaults from the Modules category. +It seems that matrices over noncommutative rings are the main culprit here -- or, rather, matrix spaces being cast as modules over the base rings. They should be bimodules! The reason why this doesn't blow up in the user's face (well, as far as I can tell) is that (I guess) the matrix space classes override the * operator to do the right thing (oops!) instead of use the defaults from the Modules category.

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

darijgr commented 10 years ago

Description changed:

--- 
+++ 
@@ -1,17 +1,9 @@
 We have `LeftModules` and `RightModules` functorial constructions, and they should be used. `Modules` implements left and right multiplication to be *the same*, which causes misleading and counterintuitive non-associativity issues.

-I'm currently running the (short) doctests of src/sage with a commit that adds a warning every time Modules(A) is called for A noncommutative. I'll post the results once it's done. So far:
+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:

-```
-----------------------------------------------------------------------
-sage -t src/sage/groups/finitely_presented.py  # 2 doctests failed
-sage -t src/sage/matrix/matrix_sparse.pyx  # 4 doctests failed
-sage -t src/sage/matrix/matrix0.pyx  # 5 doctests failed
-sage -t src/sage/matrix/matrix2.pyx  # 1 doctest failed
-sage -t src/sage/matrix/matrix_space.py  # 2 doctests failed
-Doctests interrupted: 231/2069 files tested
-----------------------------------------------------------------------
-```
+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. They should be bimodules! The reason why this doesn't blow up in the user's face (well, as far as I can tell) is that (I guess) the matrix space classes override the `*` operator to do the right thing (oops!) instead of use the defaults from the `Modules` category.

 Apparently people have been aware of this for a while; the following warning message is doctested for and not written by me:
@@ -22,11 +14,6 @@
     of left/right and both sided modules, so be careful.
     It's also not guaranteed that all multiplications are
     done from the right side.
-    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.)

nthiery commented 10 years ago
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 commented 10 years ago

Changed dependencies from 10963 to #10963

darijgr commented 10 years ago

Description changed:

--- 
+++ 
@@ -1,10 +1,21 @@
-We have `LeftModules` and `RightModules` functorial constructions, and they should be used. `Modules` implements left and right multiplication to be *the same*, which causes misleading and counterintuitive non-associativity issues.
+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. They should be bimodules! The reason why this doesn't blow up in the user's face (well, as far as I can tell) is that (I guess) the matrix space classes override the `*` operator to do the right thing (oops!) instead of use the defaults from the `Modules` category.
+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:

@@ -18,3 +29,11 @@
 (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.
mkoeppe commented 3 years ago
comment:9

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

pjbruin commented 3 years ago
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 commented 3 years ago
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.