Hi Nils, On 21 Okt., 09:56, Nils Bruin <[email protected]> wrote: > Have you checked that the elliptic curve computations *use* > all_super_categories? > ... > Reducing overhead is a lofty goal, but it can't beat removing it (or > not introducing it in the first place). Can this attribute be lazy?
Sorry, I have to name a few technical details. In one word: With #9138, they *do* use all_super_categories implicitly, but with #11900 they don't. Namely, by #9138, GF(3)['x'] is initialised as an object in "Join of Category of euclidean domains and Category of commutative algebras over Finite Field of size 3". Hence, the join category must be created and its parent_class determined. Computing a join of two categories using Category.join([...]) involves testing whether one category is a sub-category of another. And that involves calling all_super_categories. Part of #11900 is to avoid these implications: One knows the result of the join, hence, one can directly construct a JoinCategory, which does *not* involve the subcategory tests that are part of Category.join([...]). With #9138 plus #11900, GF(3)['x'] is still initialised as an object in "Join of Category of euclidean domains and Category of commutative algebras over Finite Field of size 3", but the overhead becomes so small that it is hardly noticeable in the elliptic curve computations. Concerning lazyness: Another part of #11900 is to postpone the category initialisation of matrix algebras. MatrixSpace(GF(p),n) is an algebra, and by #9138 it would be initialised as such. However, the elliptic curve code (and I guess most other code as well) uses the matrix space just as a container, so that the category initialisation is totally useless. The solution proposed at #11900 is to *not* initialise the category during creation of a matrix space, but to add a method to initialise the category later. And if, in addition, one makes the parent_class of a category independent of the category's base ring, which is taken care of at #11935, then the elliptic curve computations actually become *faster* than they were prior to #9138. Hence, with #9138+#11900+#11935, one has category initialisation and (at least for the tests we considered) a speed-up! Back to the subject of this thread: Even if the use of all_super_categories can often be avoided, I think it is still a good idea to make it as fast as possible, in the range I mentioned: Using the C3 algorithm on few lists of length not more than 60. Best regards, Simon -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
