#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 nthiery):
Replying to [comment:508 SimonKing]:
> Yes. What is the obstruction for doing so?
I foresee no serious obstruction but taking the time to implement it,
and 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, as was mentioned in other comments, when we want to do
operations on the category itself.
> > which would, among other things, resolve the current Modules /
> > VectorSpaces hack.
>
> Would it? We would still want to see `Modules(Fields()) ==
VectorSpaces()`.
Yes, but we would not need to make a special case for it. It would be
an automatic side effect of the functorial construction.
> > 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.
Well, yes the ticket's topic ``more functorial constructions`` is
rather broad. At this rate we could keep on working on it for years
:-)
Seriously: this ticket is really about axioms; by legacy reason it
contains a bunch of related stuff that would have been best in
separate tickets (I take the blame for it); let's not add more!
I just created #15801 for this.
> 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.
As you noted in your benchmarks, the regression already exists without
this ticket. This ticket certainly makes it worst, but not by orders
of magnitude. I believe we can live with the regression between the
time #10963 ticket is merged and the next one is too. If both tickets
can go in the same release of Sage, so much the better, but that's it.
And in the mean time we have a clean code base to work on.
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:522>
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.
