Changes between Version 3 and Version 5 of Ticket #16247
 Timestamp:
 04/29/14 02:22:14 (6 years ago)
Legend:
 Unmodified
 Added
 Removed
 Modified

Ticket #16247

Property
Dependencies
changed from
10963
to#10963

Property
Summary
changed from
Abuse of Modules() for modules over noncommutative rings
toMeaning of Modules(R) currently not very clear

Property
Dependencies
changed from

Ticket #16247 – Description
v3 v5 1 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 nonassociativity issues. 1 The doc of `class Modules` currently (#10963) says: 2 {{{ 3 The category of all modules over a base ring `R`. 4 5 An `R`module `M` is a left and right `R`module over a 6 commutative ring `R` such that: 7 8 .. math:: r*(x*s) = (r*x)*s \qquad \forall r,s \in R \text{ and } x \in M 9 }}} 10 11 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 RRbimodule. 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 Rmodule basis of an RRbimodule might not be a right Rmodule basis, and even if it is, the supports of one and the same element with respect to it (one time as a left Rmodule 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. 2 12 3 13 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: … … 5 15 https://www.dropbox.com/s/oieg1ig0dliz63s/noncomm.txt 6 16 7 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.17 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. 8 18 9 19 Apparently people have been aware of this for a while; the following warning message is doctested for and not written by me: … … 18 28 19 29 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. 30 31 Here are some options: 32 33  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). 34 35  Make `Modules` only support RRbimodules which are direct sums of copies of the RRbimodule 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. 36 37  Make `Modules` only support RRbimodules which are sums (not necessarily direct) of copies of the RRbimodule R. This looks like a reasonable category but I know almost none of its properties.