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/83092f47-5fd1-4de1-8632-16ce5aac3f24n%40googlegroups.com.

Reply via email to