#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, | 8045aa4a4b7ada735b3eb6055382f9b341a39f1e
#10193, #12895, #14516, #14722, | Stopgaps:
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506 |
-------------------------------------+-------------------------------------
Comment (by nthiery):
Replying to [comment:375 nbruin]:
> Great work writing up the documentation. It's very accessibly written
and very friendly in tone.
Thanks :-)
> I see you're not done yet.
Yup. I'll be back to it tomorrow morning.
> One (in my view major) point I don't see addressed yet:
>
> '''base_category''':
> While you argue why the code is ''written'' like a (spanning) tree of
the acyclic digraph, I don't see it argued why it needs to be reflected in
further data structures. In particular, I don't see why "base_category" is
necessary at all. Surely we need to know what the super categories are,
but I don't see why one needs to be preferred.
``base_category`` is used in a few spots for computing stuff
recursively. This is includes _without_axioms (a trivial recursion),
and more importantly the calculations of the super categories (a
tricky recursion).
I agree that this is mostly for internal use. But it's consistent with
functorial constructions and the like to have the .base_category() method.
> In fact, as soon as classes get implemented in their own module rather
than as a nested class, there isn't a natural tree structure anyway.
The tree structure is still there, given by the links
"Finite=...". And it is used extensively by the underlying
algorithmic.
> '''old style classes''': If you type `class ElementMethods:`, you create
a nested class that is an old-style class in python 2. Since you're
basically only interested in `ElementMethods.__dict__` anyway, this is
perhaps not such an issue. Old-style classes have some semantic
differences. I don't know if they have any significant performance
differences, and probably they don't have any performance differences that
matter for your very limited application.
Yup. We have been using ElementMethods and friends since 2009 while
being aware of this artifact. As you mention, those are just bags of
methods and the semantic difference does not pop up in practice (well,
it did once, but it was trivial).
> '''nested classes''': are a little strange in python. The syntax
suggests the class would become a kind of closure with the enveloping
class as scope closed over. That is ''not'' the case, however, which is
probably good for your purposes. It's one reason why nested classes aren't
very popular, however: they add an extra indentation level and they aren't
any different from a separate class, even though the lexical context might
suggest differently. So I'd lean towards ''not'' nesting axiom classes. At
the cost of one attribute assignment `Finite=FiniteGroups` (or something
like that), you're being spared extra indentation on ''many'' lines. It
probably also makes the code easier to read for people who don't usually
use a code-folding editor.
Well, we have been using extensively nested classes from the beginning
of the category code in late 2008. It really helps seeing the
structure of the code. See magmas.py for an example. Maybe it's time
to advertise them more to the Python community :-)
I agree that we should not nest too much for the indentation to not
become too large; which is why I want the code to support both nesting
and links to other files or elsewhere.
I agree that code-folding is a killer tool there. And I am blaming
emacs everyday for not supporting it easily. But I still managed
writing quite some category code without it :-)
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:378>
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.
