To make discussion on this point easier, I have made a GitHub issue: https://github.com/sagemath/sage/issues/37626
For progress on this code, we have all doctests passing from the old implementation except: - we cannot define toric varieties over rings, so we can't have hyperelliptic curves over rings - we cannot use the current rational_points method from algebraic_schemes due to missing methods in the homset of toric varieties We are also working on pairings as well as isomorphisms on top of supporting all older features. On Friday, March 15, 2024 at 6:47:02 PM UTC Giacomo Pope wrote: > Back again with more class questions and general advice help > > While getting all the old sage code into this new project, I realised > there are places where we really rely on the underlying curve classes. One > example is that we need > > ``` > def dimension(): > return 1 > ``` > > To avoid some crashes, but more generally we also need `rational_points()` > which lives all the way inside `Algebraic_scheme`. There's also a whole > bunch of other things... > > I started exploring more and I found `Curve_generic` which we can create > with the data I already have: > > ``` > sage: H = HyperellipticCurveSmoothModel(x^5 + x + 1) > sage: C = Curve_generic(H._projective_model.ambient_space(), > H._projective_model.defining_polynomials()) > sage: type(C) > <class 'sage.schemes.curves.curve.Curve_generic_with_category'> > sage: C > Generic Curve over Rational Field defined by -X^5*Z - X*Z^5 - Z^6 + Y^2 > sage: C.ambient_space() > 2-d toric variety covered by 3 affine patches > ``` > > this gets us some of the way and I think is an OK starting point, but then > things like asking for the curve crash for weighted projective space: > > ``` > sage: Curve(H) > --------------------------------------------------------------------------- > TypeError Traceback (most recent call last) > . > TypeError: ambient space neither affine nor projective > ``` > > and calls to things like C.rational_points() have more issues > > ``` > sage: C.rational_points(bounds=2) > --------------------------------------------------------------------------- > KeyError Traceback (most recent call last) > . > AttributeError: 'SchemeHomset_points_subscheme_toric_field_with_category' > object has no attribute 'points' > ``` > > Which just goes to show that these toric varieties are a little > underdeveloped. > > Something which might be really nice would be > > ``` > class WeightedProjectiveCurve(Curve_generic, > AlgebraicScheme_subscheme_toric): > ``` > > Intended to mirror the similar: > > ``` > class ProjectiveCurve(Curve_generic, AlgebraicScheme_subscheme_projective): > ``` > > This could then be the class which is inherited by the Hyperelliptic curve > class and we could aim for better coverage here. > > Any opinions on this? Any idea of people who might have thought about or > made progress in this area? > > Otherwise, the project continues. Functions for finite fields are all > working, generic functions mostly and the padic functions are a WIP as we > need to adapt to the fact we have different points at infinity (and I dont > know how to properly handle the case when there's two (yet)). > > Finally, looking at the rational_points() method itself, this is something > people have at least considered: > > ``` > .. TODO:: > > Implement Stoll's model in weighted projective space to > resolve singularities and find two points (1 : 1 : 0) and > (-1 : 1 : 0) at infinity. > ``` > > > On Wednesday, March 13, 2024 at 6:23:38 PM UTC Giacomo Pope wrote: > >> 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/6b254142-a007-4cbb-a79e-8e49b188eefan%40googlegroups.com.
