Dear Volker,
Thanks much for your time on expressing here your opinion! Hopefully
this will help others have a synthetic view of the situation and bring
in their opinion so that we can reach quickly a consensus.
Just two micro-notes.
On Fri, Mar 07, 2014 at 05:25:12AM -0800, Volker Braun wrote:
> I also think we agree that the implementation where a recursive
> computation is done on startup is not ideal. Relatively simple
> implementation mistakes in new category/axioms end up with an infinite
> recursion on startup, which I think is rather unhelpful for developers.
> There is also no way to doctest this recursion beyond "sage manages to
> start up".
To be precise, the recursion error occurs on startup only if you
fiddle with those fundamental categories that are created upon Sage's
startup. And you can already run into a similar problem without this
ticket if you screw up your implementation of the super_categories
methods (I did a bunch of times!). Recursion errors are not unusual
when you apply an algorithm for acyclic graphs on a graph that
accidently contains a cycle :-)
But yes we certainly agree that one has to be a bit more careful
because of the deduction rules, and that there is room for improvement
in the error reporting.
> What really bothers me with the ticket is the reliance on implicit magic
> over explicitly specifying relations between categories. From the ticket,
> this example:
> sage: class Cs(Category):
> ....: def super_categories(self):
> ....: return [Sets()]
> ....: class Finite(CategoryWithAxiom):
> ....: class ParentMethods:
> ....: def foo(self):
> ....: print "I am a method on finite C's"
> implements
> sage: P = Parent(category=Cs().Finite())
> sage: P.foo() # ok, nice
> I am a method on finite C's
> sage: P.is_finite() # Where does that come from?
> True
> The theory here is that Sets defines a Finite axiom, and by some metaclass
> magic the inner class Cs.Finite ends up being a subcategory of
> Sets.Finite. But none of that is apparent from reading the code, you can
> pretty much only figure it out through reading the
> sage/categories/sets_cat.py or introspection if your Sage install manages
> to start up. It is well documented, which is nice but IMHO it would be
> even nicer if you could understand what is going on by just reading the
> code. Nicolas thinks this amount of breverity is a desirable feature, and
> I think we should make Cs.Finite be explicit about which axiom it
> implements (and, therefore, not require that it is named Cs.Finite if you
> don't want to). We've explored various ways to implement this syntax,
> either through inheritance or a class attribute, but Nicolas doesn't like
> any.
My point being that you can infer this information from the code by
using the math:
P is a finite Cs. A Cs is a set. Therefore P is a finite set.
This indeed requires to learn, beyond standard Python, that Cs.Finite
implements the category of finite Cs, that super_categories specifies
the relation between Cs and Sets, and that Sage will do this kind of
deduction. But that's not a whole lot of documentation to digest
either.
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nthi...@users.sf.net>
http://Nicolas.Thiery.name/
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
