Le jeudi 12 septembre 2013 18:30:21 UTC+2, vdelecroix a écrit : > > > > 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 had more in mind the tensor fields: shall we introduce the space of all tensor fields (or of tensor fields of a given type (p,q)) as the Parent? For instance, in his implementation of differential forms, Joris Vankerschaver introduced the algebra of all differential forms as the Parent. 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 > ? > 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. > 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. > > Note that if you start using Parent/Element it makes no sense to have > a separate spkg. > What do you mean by "separate" spkg ? > - extrinsic geometry of submanifolds > > - computation of geodesics > > Note that for the two points above there is yet #10132 which I hope > will soonly be positively reviewed... It concerns only embedded > surfaces in R^3 but I am sure it would be better to use the code > already there. > For sure ! (with some adaptation of course). > > > - better graphical outputs > > - better efficiency (migrating some parts to Cython?) > > For symbolic computation it will not change anything to use Cython. In > the best case it will not slow. > Thanks for this advice ! Eric. -- 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.
