#10963: More functorial constructions
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-6.2
Component: categories | Resolution:
Keywords: days54 | Merged in:
Authors: Nicolas M. Thiéry | Reviewers: Simon King, Frédéric
Report Upstream: N/A | Chapoton
Branch: | Work issues:
public/ticket/10963-doc- | Commit:
distributive | c718f218fbc726bf3cf7f4c3f20638c9b0c7eea7
Dependencies: #11224, #8327, | Stopgaps:
#10193, #12895, #14516, #14722, |
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506 |
-------------------------------------+-------------------------------------
Comment (by nbruin):
Replying to [comment:508 SimonKing]:
> Replying to [comment:506 nthiery]:
> > Along about a fairly similar line, I think this is pointing once again
> > in the direction of using Algebras(Fields()) rather than
> > Algebras(QQ).
>
> Yes. What is the obstruction for doing so?
>
> I mean, I never understood why we store the base ring information twice
(in the category and in the object). When we create any category with
basering, we should accept a category instead of a ring.
>
> Or are there category operations where knowledge of the basering (and
not just of the category of the basering) is needed?
There are mathematical reasons why you might want to have this
information: For
the category of R-modules to be abelian, one needs R
specified. So, from a category-theoretic point of view it would be
desirable to
have an object "left modules over R", with "R" specified--otherwise you
don't
have an object symbolizing the relevant abelian category. However, we're
finding
that doing so is too costly for all objects, because most objects don't
care
about their category.
It reminds me of the situation where `Integers(p)` doesn't construct
itself to
lie in `Fields()` because the primality test is too expensive in general.
Would
it be an idea to initially put things in the category `Modules(Rings())`
and
then refine the category with the base ring if required?
One would need to very carefully analyse the situations that would have to
trigger a category refinement, which is particularly treacherous because
the
category refinement will have global effects, since the relevant module is
a
parent and hence likely globally unique: You could have a module that
suddenly
changes category because some other piece of code somewhere decides it
needs a
finer category (after all, this strange "category" of "left modules over
rings"
is partitioned in abelian categories of "left R-modules", parametrized by
"R")
Of course, as pointed out, it's not so clear we actually *need* the
category to
ever be refined, other than to accurately model mathematical theory.
There's
nothing actually hanging off the registration of the base with the
category.
So, perhaps this can be taken as an argument for not registering the base
in the
category at all, for now: if we need it at some later point, we could try
and
implement it via category refinement (and deal with all the dragons that
come
with it)
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:514>
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.
