Yes, I didn't properly think about breaking changes so if I simply add a new implementation into sage then maybe this thread can switch from a VOTE to simply people giving advice / feedback if they so wish.
On Monday, March 11, 2024 at 10:24:46 PM UTC Nils Bruin wrote: > On Monday 11 March 2024 at 15:04:50 UTC-7 Giacomo Pope wrote: > > I chose the weighting (1 : g + 1 : 1) following Galbraith's textbook > https://www.math.auckland.ac.nz/~sgal018/crypto-book/ch10.pdf when > implementing the arithmetic on the Jacobian. This is not a "good" answer > though. > > I would love to hear from more people about what they use / would want to > use. > > > I think it makes sense because at least it means the representation of > most points is still compatible. > > > As for deprecations, I won't know exactly how much will change before I > start working on this but if anyone's code fundamentally uses the fact it's > a projective variety and the functions coming from this then I suppose > everything will simply have to exist as a second class with deprecation > warnings. I don't know what's best here. > > > Yes, with a change as fundamental as this, I think you may be best of just > copying over the class and make your adjustments there. We'll have two > underlying "implementations" of hyperelliptic curves, with different > projective closures. We'll start out with the bad backward compatible one > as default. At some point, we deprecate that. Then you can change the > default. Then we can delete the old implementation. And then you can > reintroduce the old naming as an alias/default. > > I suspect most code that relies on non-weighted projective closures is > broken anyway, but you'd need pretty strong arguments to deviate from > normal deprecation. > > > Ultimately (even if I wait 2 years) I think it would be good for sage to > have more functioning arithmetic on Jacobians but this is obviously a very > small slice of pie in the whole meal of hyperellptic curves. > > > We can have the functionality without delay. It might just not be > available on "default" objects until 2 years down the road. That's a little > unfortunate and makes it less discoverable, but I think we do need to take > backward compatibility seriously. > > Also note that with this course of action, there is hardly anything > controversial to the first steps: you're just adding functionality. So a > sagedevel vote might not even be necessary. > > -- 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/39d3d787-ab42-4417-bec4-bc00ce345bb1n%40googlegroups.com.
