#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 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?
And would it really be particularly difficult to implement? Yes, we would
certainly need to fix a lot of doc tests, and also I guess we would have
to refine some test
{{{
if R in self.category():
}}}
to
{{{
if R in self.category() and
self.base_ring().has_coerce_map_from(R.base_ring())
}}}
(which would actually be more correct than the current test `R in
self.category()`, since this would be unaware of the coercion).
And the `base_ring()` method should become an abstract method, since the
category itself won't know about the basering (hence, couldn't provide a
default parent method).
What other complications would you expect?
> which would, among other things, resolve the current Modules /
> VectorSpaces hack.
Would it? We would still want to see `Modules(Fields()) ==
VectorSpaces()`.
We could of course also keep the sub-categories where the basering is
fixed. As Volker suggested, this amounts to providing an axiom, say,
`FixedBaseRing`, so that we would have
{{{
sage: VectorSpaces().FixedBaseRing(QQ)
Category of vector spaces with fixed base ring Rational Field
}}}
For left- and rightmodules, we might want two axioms, namely for the left
and right basering.
> Of course this goes far beyond the scope of this ticket,
No. Actually I think it ''should'' be done here. First, it would fight a
regression introduced by this ticket. Second, as you stated, it would help
making polynomial rings functorial constructions. So, it also matches the
ticket's topic.
> the
> performance issues that we get are really a side-effect of the
> construction of too many duplicated hierarchies of categories (for no
> real added value) and will vanish soon.
To be more precise: We ''currently'' construct too many duplicated
hierarchies of categories, which becomes a problem with ''this'' ticket,
since it makes the construction a little slower, and hence the duplication
really becomes noticeable. Arguably there are ideas whose scope fits
perfectly within ''this'' ticket that could fix the duplicated
constructions.
I think the current situation is similar to #9138 and #11900/#11935: One
ticket, namely #9138, made all rings use the category framework, but
introduced a huge regression in some examples, which was noticed in some
beta versions. The regressions were fixed on #11900 and #11935. It was
(IIRC) ''not'' the case that #9138 was merged into a release and then the
regression fixed later on, but it was merged only together with one (or
both, I don't recall) of the other tickets.
And similarly, we have here a ticket that certainly yields a huge
conceptual improvement of the category framework, but would introduce (or
make worse) some regression. We could of course open separate tickets to
fix the regression. But these follow-up tickets might eventually be merged
into a release version at the same time than this ticket.
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:508>
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.
