Replying here in case readers of this thread are interested -- a **not really finished** PR has now been made to Sage with a lot of the changes we describe above. I kind of want people to look at it and give rough opinions to move the project forward to the point where we can merge it and start improving it
https://github.com/sagemath/sage/pull/39161 On Thursday, October 10, 2024 at 10:58:40 AM UTC+1 Giacomo Pope wrote: > OK -- I'll do my best to break things down into the most manageable sizes > to give this the best chance. > > As for the maths/arithmetic, what we have coded gets Sage to the same > point as Magma, although with a different representation. > > In our implementation, we follow the paper: > https://eprint.iacr.org/2008/265. Generically, a divisor is represented > by (u, v : n) where (u, v) are the Mumford coordinates of the divisor and n > is the coefficient of \infty_+. As we can always deduce the coefficient m > of \infty_- from deg(u) and n, this is omitted. Additionally, when the > curve itself is ramified or inert then we can also deduce n and we instead > represent elements as (u, v). > > Unless I am mistaken, we can handle arithmetic with a unique > representation of all divisors of Jac(C) for all cases with the exception > of inert curves with odd genus. In this case, we raise an error when trying > to perform arithmetic on this case. I believe this is what Magma does to. > > > > On Wednesday, October 9, 2024 at 7:26:18 PM UTC+1 Nils Bruin wrote: > >> On Wednesday 9 October 2024 at 09:31:45 UTC-7 giaco...@gmail.com wrote: >> >> 1. This will be a very large PR, is this generally an OK thing to do? >> >> >> Generally smaller PRs are easier to get merged, but I'm not sure if >> merging n PRs of size m takes more or less time than merging one PR of size >> n*m. If you can easily get some parts split off to merge as smaller PRs >> you'd be able to get a "foot in the door" by getting those merged. But if >> that really doesn't make sense, you could also prefer to stick with the >> large PR. Especially with a large PR, I would recommend to design it such >> that you DON'T change things outside of it. That way, the scope of your >> large PR remains limited. That makes review easier. >> >> Further tie-in into the rest of the infrastructure, where you do need to >> touch files outside your primary domain is probably better done in >> follow-up PRs. You could already make them, but they would have a >> dependence on the main initial PR. >> >> >> 2. I believe it might be easier to make changes to this code in the >> current repo before merging to sage, so if people reading this want to >> contribute then we're discussing the code in the Sage zulip and we'd be >> happy for more people to look at and improve the code >> >> >> You can try that, but I would expect that deviating from the normal flow >> of things (which is: a PR on sagemath) would slow down the review process. >> It's already hard to find people for that, and now you want them to follow >> a custom procedure? You may be able to get the best of both worlds by some >> git magic where you keep your own repo overlayed with the pull request. I >> don't know if a tree can live in two repositories at once or if there are >> ways to conveniently synchronize two subtrees of two distinct projects. >> >> Mathematical comment: you'll get problems for mumford representation on >> nonsplit imaginary hyperelliptic curves of odd genus. You want an odd >> degree divisor to serve as a base of representing all classes and such a >> thing might simply not exist. Indeed, there may be points on the Jacobian >> that do not allow a representing divisor over the base field. >> > -- 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 visit https://groups.google.com/d/msgid/sage-devel/38643a5b-70e6-42da-8a48-5aa9b5dcf0b4n%40googlegroups.com.
