Changes between Version 3 and Version 5 of Ticket #16247


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

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 to Meaning of Modules(R) currently not very clear
  • 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 non-associativity issues.
     1The 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
     11This 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.
    212
    313I'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:
     
    515https://www.dropbox.com/s/oieg1ig0dliz63s/noncomm.txt
    616
    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.
     17It 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.
    818
    919Apparently people have been aware of this for a while; the following warning message is doctested for and not written by me:
     
    1828
    1929There 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
     31Here 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 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.
     36
     37- 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.