#10963: More functorial constructions
-------------------------------------------------------------------------+--
Reporter: nthiery |
Owner: stumpc5
Type: enhancement |
Status: needs_work
Priority: major |
Milestone:
Component: categories |
Resolution:
Keywords: |
Work issues: Reduce startup time by 5%. Avoid "recursion depth exceeded
(ignored)". Trivial doctest fixes.
Report Upstream: N/A |
Reviewers: Simon King
Authors: Nicolas M. Thiéry |
Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 |
Stopgaps:
-------------------------------------------------------------------------+--
Comment (by nthiery):
Hi Simon!
Thanks for all your work on the review of this ticket! I am currently
on vacations, so my answers might be slow.
Replying to [comment:44 SimonKing]:
> If I understand correctly, the reason for creating a `JoinCategory`
> is to get the correct supercategories.
The reason to call "join" is indeed to get the correct supercategories
for {{{C.MyAxiom()}}}. Note that, on the other hand and unless I
screwed up somewhere, there should be no {{{JoinCategory}}} produced
(unless of course the end result of {{{C.MyAxiom()}}} itself is such a
{{{JoinCategory}}}).
> But there are alternative ways to get the supercategories right. I
> could imagine to use a dynamic class instead. So, the aim of this
> post is to present an alternative approach that avoids joins.
In general, I agree that joins are called quite often and it would be
nice to optimize them and/or call them less often. However, I think we
really want to call a join to get the full power of the
architecture. Imagine for example that:
- C is a super category of A and B
- {{{A.MyAxiom()}}} implies {{{A.MyOtherAxiom()}}}
- {{{B.MyOtherAxiom()}}} is non trivial
Then we want {{{C.MyAxiom().super_categories()}}} to automatically
include {{{B.MyOtherAxiom()}}}, for otherwise we would need to
basically replicate the information that {{{A.MyAxiom()}}} implies
{{{A.MyOtherAxiom()}}} over and over in subcategories, and this would
not scale.
Handling this kind of stuff is precisely the core of the logic in
``join``. So if you see a way to optimize the computation of the super
categories of {{{C.MyAxiom()}}} while preserving the above feature,
then I believe you actually have found a way to optimize ``join`` in
the first place.
Cheers,
Nicolas
PS: let's keep in mind this idea of using the reduction. It could indeed
be that it could be used in a place or two to simplify the logic.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:47>
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.
