Deprecation policy for partially broken code
Vincent Macri
https://github.com/sagemath/sage/pull/39161 which rewrites hyperelliptic
curves to use a smooth model, allowing more features to work for all
hyperelliptic curves. Right now, some functionality is unavailable or
broken for even degree curves.
The smooth model ideally would just replace the existing implementation,
but since it changes how the curves are represented internally it could
lead to some calculations giving different results and might be a
breaking change. This change is necessary though, as the smooth model is
needed to correctly handle the even degree case (currently Sage just
gives wrong answers for some calculations for even degree hyperelliptic
curves).
One idea we had was to deprecate HyperellipticCurve, and make the the
new model HyperellipticCurveSmooth experimental until the old
HyperellipticCurve can be deprecated, then
rename HyperellipticCurveSmooth to HyperellipticCurve since that's a
better name. I think this plan follows our deprecation policies, but
it's convoluted and probably more annoying for users than just accepting
the breaking changes to HyperellipticCurve and replacing it with the
smooth model in one go.
Do we have any guidance for how our deprecation policy applies in cases
where we are essentially rewriting an entire Sage package because the
existing code is broken?
--
Vincent Macri (he/him)
Dima Pasechnik
a deprecation period then.
Rename the old code HyperellipticCurveBroken and keep it in the
codebase for a while if you must,
but if the new code fixes bugs it should become default immediately.
What does it mean, by the way: "some calculations giving different
results". Results are either right or wrong.
If a right result is differently packaged, so it be. After all, it's
unusual for different versions of
Sage code to give results which are differently
formatted, or have another representation, another set (but a correct
set) of generators for something, etc.
> 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 visit https://groups.google.com/d/msgid/sage-devel/64d1df9b-ed35-4e17-a6bd-7334988a4d7a%40ucalgary.ca.
Nils Bruin
Giacomo Pope
Vincent Macri
What does it mean, by the way: "some calculations giving different results". Results are either right or wrong. If a right result is differently packaged, so it be. After all, it's unusual for different versions of Sage code to give results which are differently formatted, or have another representation, another set (but a correct set) of generators for something, etc.
The new code works over weighted projective space instead of projective space. So some calculations that were not broken may give different results in the sense that the objects have a different representation. Of course for the calculations that were broken (Jacobian arithmetic for even degree hyperelliptic curves), I don't care about "breaking" them because it's already broken.
The only addition I want to make to this thread is that arithmetic on Jac(H) truly is "broken" when H has an even degree model (zero or two points at infinity) in the sense that the group operation is just incorrect. There are many issues reporting this I can try and find some links...
https://github.com/sagemath/sage/issues/37109
However, because we go from one projective space to the new weighted projective space then things for the odd degree model for the HyperellipticCurve things which weren't broken may not behave slightly differently.
I am personally in favour of directly replacing it but understand that it's not my decision.
I am also in favour of directly replacing it. For the odd degree model, is the only way this change could "break" existing code be if a user was comparing against a specific value? Or in other words, if a user has some Sage code that has no hardcoded values (so no assuming that a specific calculation returns a specific point (X : Y : Z)), would the same code usually work with the new smooth model? So most code will not break, and any code that does break is probably easy to fix?
I think part of the problem you could run into is unanimity on whether the old code is broken. I think, the code in its present form is basically correct for the singular curve. The new code would have different semantics by working with a nonsingular curve in an appropriately weighted projective space. I'm pretty sure I would need the new behaviour whenever I'd ask a computer algebra system, so I wouldn't complain. However, if there is someone out there who actually does want the sematics of the current model, they'd probably point at the documentation and claim it's not "broken" or erroneous (I haven't checked, but I assume the old code is properly documented for what it does).If you can get (very?) close to unanimity then a short-cut may be feasible. I don't even know unanimity in which group you should be striving for, though.
Giacomo explained how the old code is broken for even degree models. As for unanimity in some group to bypass the normal deprecation process, I wasn't sure which group either. That's why I asked here.
I'll tag a few people on the GitHub PR who I know have knowledge about curve arithmetic. If we hear no objections from them or on this mailing list in the next week or so, do people thing it's reasonable to just replace the old hyperelliptic code with the new smooth model implementation without a deprecation period?
As a side note, this is not the only part of Sage that could benefit from a major rewrite and where following deprecation policies to the letter might result in a more difficult transition than just rewriting the whole thing. The backwards-incompatible changes here are fairly minor, but it may be worth thinking about some kind of policy to allow major backwards-incompatible rewrites in the future.