# Changes between Version 3 and Version 5 of Ticket #16247

Ignore:
Timestamp:
04/29/14 02:22:14 (6 years ago)
Comment:

### Legend:

Unmodified
• Property Dependencies changed from 10963 to #10963
• Property Summary changed from Abuse of Modules() for modules over noncommutative rings to Meaning of Modules(R) currently not very clear
 v3 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: 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.