#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:
Dependencies: | Stopgaps:
-------------------------------+------------------------
Comment (by nthiery):
Replying to [comment:3 SimonKing]:
> OK, that's the other possibility: Rather than having a separate mix-in
category `FixedBaseRing(...)`, we would allow both `Algebras(Fields())`
and `Algebras(QQ)`.
>
> I have already done some experiments in that direction. We certainly
want `Algebras(R.category())` among the super-categories of `Algebras(R)`.
But if `C` is a category, do we want that `Algebras(D)` is among the
super-categories of `Algebras(C)`, for all `D` in `C.super_categories()`?
> When I tried it yesterday, Nicolas' bounded C3 algorithm barked at me.
Reason (if I recall correctly, I can't use my laptop right now): We want
that `Algebras(QQ)` and `Algebras(QQ.category()` have the same parent and
element classes, hence, `_make_named_class_key` returns the same, and thus
they also share the cmp-key used in the C3 algorithm. But the C3 algorithm
expects that the items on the given lists (here: the list of all super
categories) have distinct keys.
>
> One possible approach to solve that problem: The strict super-categories
of a category with fixed base ring should ''all'' be categories with
unspecified base rings. Hence, `Algebras(R)` should not have the super-
categories `Rings()` and `Modules(R)`, but `Algebras(R.category())`.
This sounds reasonable. A variant would be, for a category over base
ring C, to set {{{C(R).parent_class}}} explicitly to
{{{C(R.category()).parent_class}}}, bypassing the
{{{_make_named_class_key}}} business since it won't really be needed
anymore anyway (and similarly for the element class and so on).
I'd say that we certainly want {{{Algebras(R)}}} to be a subcategory
of {{{Modules(R)}}}, as tested by {{{is_subcategory}}}. But we could
imagine doing like for joins, and *not* put {{{Modules(R)}}} in
{{{Algebras(R).<all_>super_categories()}}}.
In fact, maybe {{{Algebras(R)}}} should really be a join category:
that of {{{Algebras(Fields()) & Modules(R)}}}.
<ramble> Here Modules(R) would play a role similar to the category
with axiom {{{C().A()}}} associated to the category {{{C}}} defining
the axiom {{{A}}}. We would not have the option to define the analogue
of a ``category with axioms`` for a subcategory, but at this point I
don't foresee a use for it either.</ramble>
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/15801#comment:4>
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/groups/opt_out.
