#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, | 478de48553d203516cddb47e0cb89c34ccc210ee
#10193, #12895, #14516, #14722, | Stopgaps:
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506 |
-------------------------------------+-------------------------------------
Comment (by SimonKing):
Replying to [comment:326 nbruin]:
> Nicholas has explained his original intent to a large degree in a post
above and I mostly agree with him, except on one place. Apparently, in his
model every category is constructed from a supercategory and an axiom. In
that case there is no need for guessing data: all the data is there when
the category gets constructed.
I think it is two times "no".
1. Some categories have no axiom.
{{{
sage: Magmas.mro()
[sage.categories.magmas.Magmas,
sage.categories.category_singleton.Category_singleton,
sage.categories.category.Category,
sage.structure.unique_representation.UniqueRepresentation,
sage.structure.unique_representation.CachedRepresentation,
sage.misc.fast_methods.WithEqualityById,
sage.structure.sage_object.SageObject,
object]
}}}
No axiom in it.
2. If you look at
`sage.categories.finite_permutation_groups.FinitePermutationGroups`,
you'll find that this ''is not'' coded as the result of applying an axiom
to a super-category. However, it ''can'' be constructed by applying an
axiom to a super-category: The result will be the same.
> I think it's crossing a line. Nowhere else in Python does the makeup of
a name determine the inheritance of properties (which eventually
categories will lead to). As Thierry points out, it's a heuristic one can
avoid, but I think it departs so much from what Python normally does that
it will frequently lead to confusion. I think you should look for a
cleaner paradigm to express these relations concisely, and now is the time
to get it right. It will be more painful to change it afterwards.
+1
With the caveat that the code does sufficient tests to get the axioms
right. These tests make it relatively robust, I think.
> It doesn't sound to me like the category information forms a database in
the sense of a bunch of tables filled with rows and columns. To me it
seems closer to a (rooted?) tree,
No, it is not a tree. It is a digraph, with edges being labelled by
axioms, and I guess one also has a poset structure. But certainly it is
not a tree.
> with edged labelled by axioms. Python has syntax to express rooted
trees: inheritance. The only thing missing is the label. That can be
replaced by a class attribute, simply set to a string.
This is what large parts of Nicolas' model does. However, since we don't
have a tree, some complication arises.
> There is a small amount of boilerplate involved with writing classes,
e.g., one usually has to write `def __init__(self):`. Writing a single
line `axiom = "Finite"` can be considered acceptable boilerplate in my
opinion and removes all guessing. Do you think that having to write that
"Finite" is redundancy because "Finite" already occurs in the `__name__`?
In that case I disagree: everywhere in python people are free to choose
names that they think are most informative (avoiding collisions and key
words), regardless of semantics of the code.
+1.
> Replying to [comment:311 SimonKing]:
> > So, questions to Nils:
> > - Do you intend to handcode everything? Then you need to cover many
cases.
>
> I may misunderstand what is required in the process, but at the moment I
think "yes". If an axiom is a required property for a Category then it
needs to be supplied somewhere, not derived by chopping a part of a
`__name__`.
OK, but it is quite some additional (and rather dull) work involved.
> > - Do you intend to put `PermutationGroups().Finite()` into code that
is executed at startup time, and similarly for ''all'' other categories
with axiom? Then, the startup time would likely to increase, and it would
not be less work than the other way to handcode the construction.
>
> You do not make that sound attractive.
Correct. It would increase startup time. By the way: Did the startup time
improve after removing the deep recursion?
> If the present patch unavoidably leads to convoluted constructs that
that's a strong indication that the design is flawed. In that case it
might be advisable to either redesign or carefully argue what the current
design is and indicate why the nasty bits are really unavoidable.
I think the design is good, robust and clear, but one implementation
detail is flawed: I think you agree with me that a naming scheme is not
the right tool to implement large parts of a digraph structure. It should
better be hardcoded in what currently is a lazy class attribute---even
though it is dull work to put it in.
> This is infrastructure. We'll be living with this for a ''long'' time
(see coercion framework). It's worth trying to get it right.
I think the coercion framework isn't totally flawed either. And it is
about digraphs, too...
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:328>
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.
