Thanks so much for the context Oh interesting. In this case I wonder whether we should work on and include a new class (maybe something as simple as a WeightedProjectiveSpace and a curve from this) mirroring the implementation for the plane curves. Alternatively I could go into the old plane curve code and write these useful functions specifically for the hyperelliptic curves (and here even gain that these algorithms can be optimised). For example, I already had to include a `dimension()` method on the curve to properly compute the Jacobian. Potentially AlgebraicScheme_subscheme_toric is indeed the wrong inheritance
On Wednesday, March 13, 2024 at 6:18:12 PM UTC Nils Bruin wrote: > One thing that may deserve a cursory check is the overhead involved in > inheriting from AlgebraicScheme_subscheme_toric class . Some parent > structures are optimized for prolonged use *after* creation and may do a > lot of caching/precomputation. There may be scenarios where one wants to > construct *lots* of hyperelliptic curves (for instance, when computing > reductions of hyperelliptic curves mod lots of primes). An expensive parent > may then add undue overhead. In that case it may be better to spin off the > functionality required into a "lightweight" structure that gets wrapped in > the expensive, full functionality parent. After all, for core algorithms a > hyperelliptic curve is just a 3*g+5 length sequence of ring/field elements: > the coefficients of the defining equation. > > There are of course also odd genus hyperelliptic curves that cover a genus > 0 curve that is not isomorphic to a P^1, but computing in their Jacobians > has its own problems, so you should probably not try to include them in > your current design. > > One thing that may be worthwhile: hyperelliptic curves do inherit some > interesting functionality from plane curves (particularly via their affine > patch) in the form of "riemann_surface". It may be worth keeping that, even > if the particular code there could be expanded to work much more > efficiently on hyperelliptic curves. > > On Wednesday 13 March 2024 at 10:32:08 UTC-7 Giacomo Pope wrote: > >> Thanks David, there's a bunch of nice things we could do for genus two in >> various cases which would be worth including. The inert case, where all >> degree zero divisors (except the identity element) have u with degree 2 >> would probably allow something particularly nice. >> >> As another update I have done a fairly brutish refactoring of the proof >> of concept code to follow the design decisions of the previous >> implementation. https://github.com/GiacomoPope/HyperellipticCurves >> >> Hyperelliptic curves are created from a dynamic class constructor on top >> of the AlgebraicScheme_subscheme_toric class (before this was a curve over >> the plane projective curves) >> A generic class offers most features, but other classes will cover the >> case of finite fields, rational fields and padic fields >> The Jacobian is a small class built on top of `jacobian_generic` which is >> built from the curve >> The set of rational points of the Jacobian is built on top of >> SchemeHomSet and the elements (divisors) are morphisms built on top of >> SchemeMorphism >> >> I will do my best to clean up and refactor code to the standard of code >> which is included into Sage now, but I would love to know any feedback >> advice on whether this structure is still the one to use. The older version >> of this code dates back to the beginning of Sage so it's very possible we >> have new ideas of how things should be done and if we're doing the work or >> rewriting the whole set of classes I may as well do a good job. >> >> Giacomo >> >> On Wednesday, March 13, 2024 at 3:36:09 AM UTC David Roe wrote: >> >>> There is also this old trac ticket >>> <https://github.com/sagemath/sage/issues/23154> about implementing fast >>> arithmetic in genus 2 Jacobians, which never made it into Sage. I've CCed >>> Mike Jabobson, who worked on it. >>> David >>> >>> >>> On Tue, Mar 12, 2024 at 12:10 PM Giacomo Pope <giaco...@gmail.com> >>> wrote: >>> >>>> Thank you for linking this and I agree this is a great way to >>>> cross-compare the work we have been doing. I am not an expert in this area >>>> so I am not sure I should do a full review but I'm happy to look over it >>>> if >>>> this helps. >>>> >>>> As a small update on this work, I now have >>>> >>>> class HyperellipticCurveSmoothModel(AlgebraicScheme_subscheme_toric) >>>> >>>> So this new class builds on top of AlgebraicScheme_subscheme_toric and >>>> the smooth projective model is built using a toric variety. The points on >>>> the curve are currently SchemeMorphism_point_toric_field, potentially I >>>> will need to make a child class of these if methods on the points >>>> themselves are required. >>>> >>>> With the working arithmetic and this new inheritance my work is now >>>> going to be the rather slow and painful rewrite of all hyperelliptic >>>> methods from the current implementation to ensure everything works on the >>>> smooth degree model. >>>> >>>> On Monday, March 11, 2024 at 6:23:38 AM UTC Kwankyu Lee wrote: >>>> >>>>> On Friday, March 8, 2024 at 7:37:04 PM UTC+9 Giacomo Pope wrote: >>>>> >>>>> As a small update, the repository now contains code to >>>>> >>>>> - perform arithmetic for >>>>> - the imaginary model (ramified, one point at infinity) for all cases >>>>> - the real model (split, two points at infinity) for all cases >>>>> - the real model (inert, zero points at infinity) for even genus >>>>> Which allows us to do "as much" as Magma does for Jacobians of >>>>> hyperellipticc curves from the perspective of arithmetic. >>>>> >>>>> My current "test" for the arithmetic is that D - D = 0 for all cases, >>>>> that jacobian_order * D = zero and that order_from_multiple(D) works. If >>>>> people have other ideas for tests, please let me know. Of course at the >>>>> moment these tests are over finite fields but you can reasonable use >>>>> other >>>>> fields (as Sabrina's message shows) but I am less sure about how to do >>>>> randomised testing here. >>>>> >>>>> >>>>> I just set https://github.com/sagemath/sage/pull/35467 to "needs >>>>> review" status. The PR implements Jacobian arithmetic for general >>>>> projective curves. >>>>> >>>>> It is slow compared with Jacobian arithmetic using Mumford >>>>> representation, but could be used to crosscheck the computations. >>>>> >>>> -- >>>> >>> 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+...@googlegroups.com. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/sage-devel/7f646c6d-bd0b-452d-a730-30144415f590n%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/sage-devel/7f646c6d-bd0b-452d-a730-30144415f590n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/9de5eb92-67ca-40fa-b9a1-80b13f56046en%40googlegroups.com.
