On Sat, Sep 14, 2013 at 11:18 AM, Peter Bruin <pjbr...@gmail.com> wrote:
> Hi Travis, Volker and Simon,
>
> Thanks for your answers. I will definitely have to spend more time thinking
> about this; there are clearly lots of technical issues to wrap one's head
> around. My current (limited and possibly wrong) understanding is as
> follows. ElementMethods is a mechanism for supplying methods to dynamically
> created classes, and that these dynamic classes at the same time inherit
> from a bunch of other classes. This is inspired by the Python construction
>
> type("class name", tuple of base classes, dictionary of methods).
>
> It could be that my question somehow breaks apart into subquestions about
> this construction and its relevance for Sage's category framework.
>
> - Do the methods coming from ElementMethods always take priority over
> (override) those from the base classes?
>
> - Is this a desirable thing in the set-up of Sage's category framework,
> where this construction is called behind the screens, so that one cannot
> control easily which ElementMethods are inserted into our dynamical class?
>
> - Is it clear that there is always one well-defined place where these
> ElementMethods come from?
>
> - The fact that one can supply a set of methods (beyond the ones provided by
> the base classes) gives us one construction for providing methods to
> elements belonging to objects in concrete categories. In what kind of
> examples is this a better construction to use than to inherit from the
> correct base class?
>
> These questions are not very well thought out, but I currently don't have
> too much time.
>
> About some other things that came up:
>
> It is not so obvious to me that one should think of Sage categories as
> having nothing to do with mathematical categories and being just a form of
> syntactic sugar. The documentation seems to suggest the opposite, or at
> least is ambiguous about this. From sage/categories/category.py:
>
> Every Sage object lies in a category. Categories in Sage are
> modeled on the mathematical idea of category, and are distinct from
> Python classes, which are a programming construct.
>
> And from sage/categories/primer.py:
>
> The purpose of categories in Sage is to translate the mathematical
> concept of categories (category of groups, of vector spaces, ...)
> into a concrete software engineering design pattern [...]
>
> [...]
>
> A category is a Python instance representing a mathematical category.
>
> I currently have the impression that the category framework tries do two
> quite different things at the same time: implement mathematical categores
> and implement certain programming constructions. Is there a good reason why
> these two should be intertwined in the way they are in the category
> framework? Is it possible to separate these "mathematical" and "computer
> science" parts/aspects from each other (either mentally or in the actual
> implementation)? I hope these questions vaguely make sense.
>
> Finally, back to the specific example of square vs. non-square matrices: it
> actually turns out that non-square matrices *do* currently inherit from
> RingElement! This should clearly be fixed.
This dates back to before the category framework, when (normal)
inheritance was the only way to get things like this. Yes, it should
be fixed!
> Shouldn't there be a class
> SquareMatrix for methods like is_invertible() and determinant()?
Currently there are many different matrix implementations specialized
on the basering for efficiency (e.g. finite fields of various sizes,
ZZ, QQ, number fields, etc.) Would you suggest that we create
SquareIntegerMatrix, SquareRationalMatrix, etc? Of course to spare
some work one would want a common SquareMatrix that all of these
(multiply) inherit from. (One technicality is that SquareMatrix could
not inherit from RingElement if the base IntegerMatrix class does not
as they would have incompatible C layouts.) Also, this seems like a
lot of busywork--we should be able to automatically generate these
classes for any matrix type when nrows == ncols. But this is exactly
what the category framework gives you (though it could have done so
with a more sophisticated getattr rather than dynamically-constructed
types).
Another good example of this is polynomials. There are various
sparse/dense representations implemented over various representations
of rings. Whether this is a UDF or PID depends on the category of the
basering, trying to (manually) bake this into the inheritance of
elements is painful. But there are some methods that can be
*automatically* provided if the category is right (e.g. gcd).
The primary advantage of RingElement vs Rings().ElementMethods is that
one can place cdef methods on the former, in particular to provide
fast paths for arithmetic and the coercion system (including its
special relationship to ModuleElement). Ideally nothing
category-specific should go here (though there should be a big comment
at the top that Rings().ElementMethods is a common parent for all
RingElements) and actual ring element implementations could descend
from RingElement or not as needed/as the implementation allows. In
fact, there is very little in RingElement that's not about arithmetic
and the coercion model, it could probably be all moved out (with a
clear reference in the docstring about Rings().ElementMethods, and in
the Element class as well). In particular, the mostly-vacuous
hierarchy and deceptive is_X methods starting at
https://github.com/sagemath/sage/blob/8118b2b39e3a129a5a6186fdc9917940f92b87a6/src/sage/structure/element.pyx#L2767
should probably be stripped out.
- Robert
--
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/groups/opt_out.
