#10963: More functorial constructions
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-6.2
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-doc- | Commit:
distributive | 1cdc128a85851dd007b3b77ec53a4853a10e1de4
Dependencies: #11224, #8327, | Stopgaps:
#10193, #12895, #14516, #14722, |
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506, |
#15757, #15759 |
-------------------------------------+-------------------------------------
Comment (by nthiery):
Replying to [comment:566 darij]:
> Part 2: the beginning of `sage/categories/category_with_axiom.py`.
>
> - I don't understand this:
> {{{
> - From an object oriented point of view, any subcategory ``Cs()``
> of :class:`~sage.categories.sets_cat.Sets` inherits from a
``Finite`` method, and ``Cs``
> can complement this method with extra data (here a mixin class)
> in the form of a class attribute ``Cs.Finite``.
> }}}
> "inherits from" should be "inherits", right?
Yes.
> What does "extra data (here a mixin class)" mean? Should a class
attribute (not a class method) really override a method? Or does "class
attribute" mean "class method" here? And what does this paragraph actually
say? That I can override any method from a higher-up category? Isn't that
clear anyway?
Ok, let me try a variant:
{{{
- From an object oriented point of view, any subcategory ``Cs()``
of :class:`~sage.categories.sets_cat.Sets` inherits a
``Finite`` method. To complement this method, ``Cs`` would
usually override it with a method ``Cs.Finite`` which would
make a super call to ``Sets.Finite``, and then do extra stuff.
In the case at hand, ``Cs`` also wants to complement
``Sets.Finite``, though not by doing more stuff, but by
providing it with an additional mixin class containing the code
for finite Cs. To keep the analogy, this mixin class is to be
put in ``Cs.Finite``.
}}}
> - This reads weird:
> {{{
> This is undoubtedly a code smell. Nethertheless it should be kept as
> is, first to resolve the import order properly, and more
> importantly as a reminder that the category would be best not
> constructed upon Sage's startup. This to entice developpers to
> reduce the number of parents (and therefore categories) that are
> constructed upon startup. Each "at_startup=True" that will be
> removed will be a measure of progress in this direction.
> }}}
> "it should be kept as is" probably was intended to mean that the
warnings at startup time should be preserved, not that the lazy import at
startup time should be preserved.
Yes!
> I don't understand the use of "entice" in this paragraph.
I was looking for something stronger than "encourage" ...
> - I don't understand this:
> {{{
> .. NOTE::
>
> In principle, due to a limitation of :class:`LazyImport` with
> nested classes (see :trac:`15648`), one should pass the option
> ``as_name`` to :class:`LazyImport`::
>
> Finite = LazyImport('sage.categories.finite_groups',
'FiniteGroups', as_name='Finite')
>
> in order to prevent ``Groups.Finite`` to keep on reimporting
> ``FiniteGroups``.
>
> Given that passing this option introduces some redundancy and is
> error prone, the axiom infrastructure includes a little workaround
> which makes the ``as_name`` unnecessary in this case.
> }}}
> But it sounds like something that can eventually bite me in the ass. Can
I have some more detail?
Yes, in general you need to be careful when using LazyImport for
nested classes. See #15648. If that nested class implements an axiom,
you are safe though.
> - Line 251:
> {{{
> We don't recommend using this syntax which may eventually be
> deprecated.
> }}}
> What syntax? `Algebras.WithBasis(QQ)`?
Yes.
> What is the general pattern here (other than "declaration of base
needlessly delayed")?
It's more like that there already is a syntax for this, namely
Algebras(QQ).WithBasis(), and that syntax bears nicely a meaning:
Among the QQ-algebras, give me those with a basis. Whereas the meaning
of Algebras.WithBasis(QQ) is not so clear; first because the class
Algebras (not the object Algebras()) does not really model anything;
second because the syntax suggests that you are doing two unrelated
things at the same time: asking for the algebras endowed with a
distinguished basis, and asking for those with QQ as base ring.
> - My 2 cents on one of the pain-in-the-ass issues: I do *not* oppose the
syntax-based guessing of base category class and axiom, as long as it is
used as a last resort and can always be manually overridden if it turns
out to be less than smart. After all, am I seeing it right that if it
*does* return a guess, the guess is guaranteed to be correct (`assert
getattr(base_category_class, axiom, None) is cls`)?
That's right!
> If this is indeed the case, you should proudly point this out in the
documentation, because "heuristic" and "guesses" are words that make
people like myself very scared. (Also, maybe add some instructions for
users of categories on how to add doctests that verify that it is
successful at guessing?)
Good point. I'll do that now!
> - Why talk of arborescences rather than just rooted trees? Do you want
to stress a poset/digraph structure?
Well it used to be rooted trees (actually rooted forests). But Nathann
asked for arborescences :-)
> - Wait...
> {{{
> For example, the fact that a cartesian product of associative magmas
> (i.e. of semigroups) is associative
> }}}
> Really? Isn't that the typical associativity-up-to-equivalence situation
where the equivalence can usually be ignored in proofs but comes back with
a vengeance if taken too lightly in code? Specifically, is ((1,2),3) ==
(1,(2,3)) ?
Here we are not speaking about the associativity of the cartesian
product, but the associativity of the componentwise * operation.
For all of the above: I would very much appreciate if you could use my
answers (assuming they indeed clarified the confusion) to rephrase the
documentation as you see fit. Indeed, as a reader, you have a much
better idea on how it's perceived, and what needs to be fixed to avoid
the confusion in the first place.
Thanks!
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:576>
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/d/optout.
