#10963: More functorial constructions
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.1
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 | Commit:
Dependencies: #11224, #8327, | eb7b486c6fecac296052f980788e15e2ad1b59e4
#10193, #12895, #14516, #14722, | Stopgaps:
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506 |
-------------------------------------+-------------------------------------
Comment (by nthiery):
Replying to [comment:443 SimonKing]:
> it seems to me that I still don't see exactly where the theoretical
model ends
> and where the implementation details start. Also, I am not sure if we
talk
> about the same when we both say "consistency". Therefore I try to
formulate
> what I think you claim, asking you to correct where I am wrong, and also
I
> give you an example, asking you to explain to me how to implement it in
your
> model and how your model detects the inconsistency in my example.
Great.
> First, a pledge: Could you please push your latest commits providing the
> latest documentation?
It's done (in my branch u/nthiery/ticket/10963). Ah, I had not
recompiled the doc recently on sagemath.org; done.
> We agree that we should single out a spanning tree. It is useful, e.g.,
for
> getting a proper inheritance of Python classes (think of parent and
element
> classes).
More importantly, it's useful for the algorithmic.
> Questions:
>
> - Do you claim that the choice of a spanning tree doesn't matter at all?
Would any spanning tree work?
Yes. Up to one extra constraint: if Cs().A() coincides with Ds().A(),
with Ds a subcategory of Cs, then the category with axiom should be in
Ds.A.
> - Do you claim that all theorems about categorial identities are and
will in
> future be ''asymmetric'', so that they give a natural choice of a
spanning
> tree?
Yes. Well, at least, all the use case I have met or foreseen so far
are of this form.
> In addition to that (and this is where I think the implementation
deviates from the theoretical model), you say that at each node one should
additionally mark the outgoing
> arrows that belong to the spanning tree: The outgoing arrows belonging
to the
> spanning tree result in class attributes, the other outgoing arrows
result in
> (cached) subcategory methods. Is this a correct description?
Let me refine it a bit: if Cs defines an axiom A, and Ds is a
subcategory, then Ds().A always results in the method
Cs.SubcategoryMethods.A whose job is to add the axiom. And if Ds
further implements A in Ds.A, then the call Ds().A() will use that
class in the process.
> And somehow there
> are these `<Axiom name>_extra_super_categories` methods, which relate
> with the non-spanning-tree-outgoing-arrows as well, right?
In general, the extra_super_categories method can be used to provide
additional inheritance information that can't be derived automatically
by the system, e.g. is not a direct consequence of the commutativity
of axioms.
> This gives rise to a couple of questions:
>
> - Of course, if you do specify the spanning tree both on incoming and
outgoing
> arrows, then this specification should be consistent. Is this what you
mean
> when you talk about a "consistent choice"? Then I agree that it is a
purely
> local problem. I don't think that one needs to test it in the
`TestSuite`,
> because you already test it in `__classget__`.
By consistent I meant that the computed results are what we expect
mathematically (including commutativity of axioms, ...).
> - ''Why'' do you think that one needs to specify the spanning tree twice
> (incoming and outgoing)?
At the level of the classes and the code, the only algorithmically
relevant link is that of the form Sets.Finite = FiniteSets. The
reverse link is only there to allow for calling FiniteSets() as
syntactic sugar for Sets().Finite(). Or Fields() for
DivisionRings().Commutative().
Of course, at the level of the categories, Sets().Finite() needs to
have a link to Sets() for the algorithmic to work, but that link can
be setup later at initialization.
> Related with the second question: I know that in your current
implementation,
> one can not both define `DivisionRings.Finite = FiniteFields` and
> `Fields.Finite = FiniteFields`---but it seems to me that this is
''only''
> because you chose to give the same data twice. So, can you explain '''in
the
> theoretical model''' why it is illegal to assign `DivisionRings.Finite =
FiniteFields` and why it is needed to use all this
> `Finite_extra_supercategories` and cached subcategory methods magic?
> Or is it just because of the implementation? In this case, please
elaborate (or
> give a pointer to a place where you did elaborate already) why providing
the
> same data twice is important and an implementation is hardly doable
without the duplication of information.
For the subcategory method magic, the answer is easy: If Cs defines
the axiom A, then I want Ds().A() to work for every subcategory Ds,
whether Ds implements A or not. Putting A in Cs.SubcategoryMethods
models naturally that Cs defines the axiom for every subcategories.
About not allowing DivisionRings.Finite=Fields.Finite, this is about
the algorithm (so not the model) which is highly recursive; without
that assumption, one needs to detect the situation to avoid running in
a recursion loop, and the detection is tricky. I will elaborate on it
in the documentation and let you know when done.
> Now I come to an example.
Great.
I am going to play with it now and report. Did you have any specific
ideas on which subsets of axioms are actually implemented in your
example? Otherwise, I'll pick a couple typical situations.
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:447>
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.
