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 on the web visit https://groups.google.com/d/msgid/sage-devel/19f66c87-4918-4858-a51a-f5ec71560681n%40googlegroups.com.
