Hi Vincent, On 2013-09-12, Vincent Delecroix <20100.delecr...@gmail.com> wrote: >> Still missing: >> >> - the implementation of Sage Parent/Element scheme for a better >> integration in Sage > > Do you need some help for that point? It is not clear what to do. On a > manifold you have points (and more generally segments, geodesics, > triangles, ...) which might be Element and the manifold itself which > might be the Parent (this is what I used in my patch for #9439). On > the other hand, you can consider the set of all manifolds as a Parent > in which case the manifold would be an Element...
I believe it is *totally* clear what to do. Clearly, manifolds are objects in a category, and they contain something. Hence, they are parents, by the usual notions in Sage. Is there even such thing as the "set(!) of all manifolds"? IIRC, manifolds do not form a set. Hence, one must not use sage.structure.Element for implementing manifolds, because this would be for elements of a set. So, one should 1) create the categories of differential and of topological (and PL?) manifolds, perhaps also of *compact* diff/top/PL manifolds 2) inherit from sage.structure.parent.Parent to implement manifolds 3) inherit from sage.structure.element.Element to implement points in manifolds. 4) provide the class from 3) as an attribute named "Element" to the class from 2), and implement _element_constructor_ in 2). The usual stuff, that is explained in the thematic tutorial on categories and coercion. > In an algebraic context it is most of the time clear what is Parent > and what is Element (but not always as you may consider the set of > vector spaces with the operation of direct sum as a monoid... which > turns vector spaces into elements). I do not think that the current > Parent/Element structure allows that kind of construction. Am I right > ? Geodesics etc. in a manifold M couldn't rightfully be considered elements of *M*, but perhaps it makes sense to describe them as elements of another manifold. This would be similar to ideals in a commutative ring: sage: P.<x,y> = QQ[] sage: I = P*x sage: x.parent() Multivariate Polynomial Ring in x, y over Rational Field sage: I.parent() Monoid of ideals of Multivariate Polynomial Ring in x, y over Rational Field So, even though for technical reasons it is not possible to inherit simultaneously from Parent and from Element, it is totally possible to have elements (such as ring ideals or geodesics) that, themselves, contain elements that are actually elements of a different parent (such as ring elements or points of a manifold). So, my recommendation concerning geodesics is: Inherit from sage.strucutre.element.Element, but construct a mathematically meaningful parent containing all geodesics (I guess the set of all geodesics of a differentiable manifold M has a nice structure). > I think that if you not have any benefit from the Parent/Element > structure (ie if Element does not ask questions to the Parent) it > makes no sense to use it. I very strongly disagree. At some point, you want to do more constructions (starting with the obvious: *maps* between manifolds). If you don't use the existing infrastructure in Sage, you would certainly shoot yourself into the foot at some point. > One good point of categories is if you have > several implementations of the same type of Parent/Element (let say > manifold defined by chart and embedded manifold in R^n defined by > equations). That way you could provide a template (and default > implementation) for both of them by creating a category. You should have a look at "parents with realizations". I guess sage.combinat.sf.sfa (symmetric functions) is a good source of ideas of how to implement a parent with different ways of representing elements, and with smooth transitions between the different representations. +1 of having some default implementations in the category of (diff/top/PL) manifolds. But for speed, you would probably want to have specialised implementations somewhere. > Note that if you start using Parent/Element it makes no sense to have > a separate spkg. +1 --- at least if you don't have a lot of (third party?) C/lisp/Fortran code. But if all code is Python and Cython, then creating an spkg won't make sense even if you *don't* use Parent/Element. > For symbolic computation it will not change anything to use Cython. In > the best case it will not slow. What do you mean by "symbolic computations" in this context? Do you mean "using sage.symbolic.expression.Expression to describe manifolds"? At least if you use polynomal maps, it would be much more efficient to use polynomials rather than symbolic expressions. But other than that, I guess the question of whether to use Python or Cython depends on things like "how often do you iterate over a list or test for containment in dicts or have tight loops or test equality of objects from which you *know* that they are integers", etc. Best regards, Simon -- 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.
