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. Shouldn't there be a class
SquareMatrix for methods like is_invertible() and determinant()?
Thanks again,
Peter
Op vrijdag 13 september 2013 20:23:21 UTC+1 schreef Peter Bruin:
>
> Hello,
>
> A discussion was just started at http://trac.sagemath.org/ticket/15192about
> the reason why categories in Sage have a class ElementMethods. In
> this ticket, Julian Rüth moved the method is_unit from RingElement to
> Rings().ElementMethods to fix a certain bug. I thought this wasn't the
> only possible fix and wondered why the latter existed in the first place.
> We thought it would be a good idea to move the discussion here.
>
> For now let me just quote myself out of context (see the ticket for
> context):
>
> Parents describe relations between elements; e.g. a ring is a set whose
> elements satisfy certain axioms. Categories are on a higher level; they
> describe relations between objects, and it shouldn't matter too much what
> the elements of these objects are, or even if the objects are sets at all.
>
> Whether an element is unit depends on relations satisfied *within* its
> parent, not on relations between the parent and *other* parents. In other
> words, the category its parent is in should not play any role. It is true
> that some categories (like the category of rings) *are* in a sense
> defined by relations between the *elements* of objects, but exploiting
> this to influence the behaviour of elements is confusing two different
> levels of abstraction, in my opinion.
>
> Hence, I don't see a good mathematical reason for putting methods in
> Ring.ElementMethods instead of RingElement. I can see why one would want
> a Category to have ObjectMethods (which are now called ParentMethods) and
> perhaps MorphismMethods (which only exist in a doctest). With
> ElementMethods, however, I somehow get the feeling that the authors of
> the category framework are aiming for world domination!
> (Last sentence is tongue-in-cheek, of course.)
>
> Can someone more familiar with the category framework motivate the reason
> for ElementMethods? Are there methods that cannot or should not be put in
> the relevant element classes (such as RingElement above)?
>
> Thanks,
>
> Peter
>
>
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
