#15801: Categories over a base ring category
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: sage-6.2
Component: categories | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
public/categories/over-a-base- | 12afbe46ebafe56cf74661bb6d5ea81af583ba83
ring-category-15801 | Stopgaps:
Dependencies: #10963 |
-------------------------------------+-------------------------------------
Old description:
> Currently, to construct a category of algebras, we need to specify the
> base ring:
> {{{
> sage: Algebras(QQ)
> }}}
>
> A side effect is that the construction of e.g. {{{GF(p)['x']}}} for a
> lot of `p`'s in number theoretic calculations triggers the
> construction of many parallel hierarchies of categories.
>
> This is a waste because in most situations only the category of the
> base ring is relevant. In particular, the generic code provided to
> parents/elements/... only depends on the latter.
>
> The purpose of this ticket is to allow for only specifying the
> category of the base ring, as in:
> {{{
> sage: Algebras(Fields())
> }}}
> with
> {{{
> sage: Algebras(QQ)
> }}}
> constructing a subcategory of the former. Then go trough the code,
> decide in each case whether we want to use {{{Algebras(QQ)}} or
> {{{Algebras(Fields())}}}, and update the doctests accordingly. In most
> case, the latter idiom will be preferable, unless we need some
> operation on the category itself.
>
> This would fix the regression noted on #15792 and made worse by
> #10963.
>
> Further features for this ticket or follow-up tickets would be to:
>
> - make {{{Modules(...)}}} into a covariant functorial
> constructions. This would give a proper framework for the feature
> {{{Modules(QQ)}}} -> {{{VectorSpaces(QQ)}}} instead of having to
> tackle it with a special hack.
>
> - implement a {{{PolynomialRings(...)}}} covariant functorial
> construction.
New description:
Currently, to construct a category of algebras, we need to specify the
base ring:
{{{
sage: Algebras(QQ)
}}}
A side effect is that the construction of e.g. {{{GF(p)['x']}}} for a
lot of `p`'s in number theoretic calculations triggers the
construction of many parallel hierarchies of categories.
This is a waste because in most situations only the category of the
base ring is relevant. In particular, the generic code provided to
parents/elements/... only depends on the latter.
The purpose of this ticket is to allow for only specifying the
category of the base ring, as in:
{{{
sage: Algebras(Fields())
}}}
with
{{{
sage: Algebras(QQ)
}}}
constructing a subcategory of the former. Then go trough the code,
decide in each case whether we want to use {{{Algebras(QQ)}}} or
{{{Algebras(Fields())}}}, and update the doctests accordingly. In most
case, the latter idiom will be preferable, unless we need some
operation on the category itself.
This would fix the regression noted on #15792 and made worse by
#10963.
Further features for this ticket or follow-up tickets would be to:
- make {{{Modules(...)}}} into a covariant functorial
constructions. This would give a proper framework for the feature
{{{Modules(QQ)}}} -> {{{VectorSpaces(QQ)}}} instead of having to
tackle it with a special hack.
- implement a {{{PolynomialRings(...)}}} covariant functorial
construction.
--
Comment (by tscrim):
So `Algebras(Rings())` would cover any algebra (well...any assoc & unital
algebra)?
Also I think we should not loose support for having the category of
algebras over a fixed base ring. For example, given two representations
`V`, `W` of a group algebra `RG` over `R`, the morphisms from `V` to `W`
as `RG`-modules is (significantly) smaller than the morphisms as
`R`-modules. Currently our set of morphisms depends on the category, which
if we keep the current setup, would give that `Hom(V, W, Modules(RG)) is
Hom(V, W, Modules(R))` (well, maybe only `==`).
Actually...`RG` would be the category of group algebras whereas `R` would
be in the category of rings, unless `R` was also the group algebra of some
other group (okay, it's very contrived, but possible). My point is that
just passing the category into `Modules` doesn't always tell us the full
structure (of the homset), and is there some way we can work around this?
--
Ticket URL: <http://trac.sagemath.org/ticket/15801#comment:19>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
