On Mar 2, 2:48 pm, "Georg S. Weber" <georgswe...@googlemail.com> wrote: > > But the "no binary objects whatsoever" criticism from Harald is > justified (due to the mercurial history, even erasing .png files later > will not help --- the increase in size will last forever), as well as > the question of maintainability.
There are already a couple of images in the documentation of the "homology" Sage module that nobody has complained about so far. I don't think this is an issue. I wouldn't want to read documentation of the > Frankly, I see no benefit in having these new parts being coded in C/C+ > + compared to using the already existing Python/Cython framework of > ArithmeticSubgroups. To the contrary, the C/C++ code seems to use > internally C/C++ int's for the entries of the 2x2 matrices and is thus > vulnerable w.r.t. overflow issues --- on 32bit platforms earlier than > on 64bit platforms (one could have easily used e.g. int64_t's instead, > but the basic problem remains). Whereas the current Sage code uses > internally fast arbitrary precision Integer arithmetic. This last statement is false: lots of functions in sage/modular/ arithgroup/congroup_pyx.pyx use C ints for speed, and it's never been an issue AFAIK. I don't think anyone's likely to be computing modular symbols of level too big to fit in an int any time soon -- the execution time and memory requirements get unmanageable long before integer overflow rears its head. > Don't get me wrong, I definitely do want the #11709 code to be > incorporated as soon as possible, and not only because it's a first > time contribution to Sage (from Hartmut Monien, and someone else who > still has to remove the Umlaut in his name from at least one of the > patch files, IIRC)! > > But as soon I can free a minimum of time of mine to do some > refactoring and enhancing of the Sage ArithmeticSubgroups I need for > my own work, I hardly believe that any C/C++ code will survive that > (only its functionality, refactored and enhanced, e.g. to work > directly with subgroups of SL2Z instead of PSL2Z, for e.g. generators > and cosets, special treatment of subgroups that are invariant under > the Shimura main involution, some nice speedups, ...). Your planned code does sound great, but it will take time until it's finished, and more time until it's reviewed. > Since we already have this thread open for discussion --- what do you > think are the benefits of having this functionality coded in C/C++ > instead of Python/Cython (sorry if that question is too Off-Topic)? > The only benefit I can see is: "It already exists and is (almost) > ready for inclusion, whereas e.g. Chris Kurth's KFarey spkg does not > seem to be available any longer via the web". I was the one who adapted those parts of Kurth's KFarey that are already in Sage (with his permission, of course) -- that was the foundation of the ArithmeticSubgroup_Permutation (lousy name!) module. I attempted to implement Farey symbols too, but I never finished it, largely because I didn't understand the theory well enough at the time but also because implementing it in pure Python was very very slow. I agree that in an ideal world it would be nice if we had Farey symbols implemented in Cython, using native Sage datatypes, rather than interfacing with an external library with its own data structures and thus wasting time converting data -- or wasting even more time *not* converting data. At the moment, if you install Hartmut's patch and then do sage: G = <some arithmetic subgroup> sage: _ = G.coset_reps() sage: FareySymbol(G) then the FareySymbol code will calculate coset representatives for G in SL2Z again from scratch, rather than using the ones that are computed and cached by the coset_reps call. Perhaps surprisingly, Sage's native code seems to be a bit quicker than Hartmut's C++ code at calculating the coset representatives; and this will be even more the case if someone reviews my patch at http://trac.sagemath.org/sage_trac/ticket/12233 which optimizes arithmetic with SL2Z elements a great deal (hint hint!). But we have a saying in English about birds in hands and bushes, and another one that I first saw on Sage trac: "the perfect is the enemy of the good". I'm strongly in favour of merging Hartmut's code once the minor issues I pointed out on the trac ticket are resolved. So that's my 2p worth. Regards, David -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
