#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:421 vbraun]:
> Still, my point that you can't expect to arrive at the normal form by
removing axioms at each step remains.
I agree that the semantic of _without_axioms and _without_axiom is
currently not strongly specified (though I actually believe we could
find a well defined -- but not necessarily useful -- semantic).
In any case, this is a non issue because those methods are used
nowhere in the algorithmic. One only recurse by one step on the
base_category, and the semantic of this is well defined. Granted, at
this point, you have to believe me or convince yourself from the code.
As I said, if you believe this is really worth it (how many pieces of
Sage's infrastructure have been formally proven?) I can go the step of
proving formally the whole thing, but that will take a bit of time.
_without_axioms is only used for finding heuristically a good _repr_.
And it's been doing a good job so far. It's also used for implementing
_without_axiom: as I mentioned earlier the semantic of the later is
not well defined, but is good enough for the single spot where I have
had a need for it (removing the ``facade'' axiom when playing with
posets).
> So just listing supercategories is not a good way of supplying
relations, you need a way to get a handle on all relations (without having
to instantiate all categories on startup).
I believe the relations are trivial enough that you can lazily handle
them along the closure calculation. But I don't have enough room in
the margin to prove it here :-)
> Please do, I'm interested in what you think is "likely unimplementable"
in my proposal or how you are going to go about name conflicts in yours.
The point is "within the desired feature set". For the idiom:
{{{
class C:
class Anyname(MyAxiom.Category):
...
}}}
(1) You need to scan through the entries of ``C`` to decide whether
``C`` implements ``MyAxiom``, right? In particular, you need to
evaluate all those entries to test the inheritance, which means
triggering lazy imports.
I think it's an important feature of the current design that you
can use a category and some of its axioms while completely
ignoring the others. For example, my upcoming tickets will add
rather large categories like Semigroups().JTrivial(); those
categories have no reason to be loaded upon starting Sage, whereas
Semigroups().Commutative() will be constructed.
In general, I believe one should refrain from evaluating all
entries of an object, for some of them might be lazy with good
reasons.
(2) Either you define MyAxiom in a location of its own. But then you
loose some code locality (the code for the axiom is not tied to
the category defining it, which I find important). Or, as I
mentioned before, you take the risk of having non trivial
refactoring in case you generalize the axiom to a super category
later.
Altogether the current design just follows by analogy standard OO
practice: when a class C defines a method or attribute named ``a``,
this fixes the semantic of ``a`` for all subclasses. I don't see that
the names for our axioms would be soooo specifically keen to clashes
that we need to invent a new mechanism and deviate from standard
practice. As usual, if a name is potentially ambiguous within its
field of application, then it should be made more explicit. That's
e.g. what we do with "Associative" w.r.t. "AdditiveAssociative".
For the tuple _base_category_and_axiom: really, if you care, please
have a try yourself; it's a small piece of work anyway. I had given it
a shot at some point and then reverted my changes because it did not
look feel any better after. I'd be happy being proven wrong.
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:423>
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.
