Elliptic curves over generic rings

[maelhos]

This draft PR aims at designing a first interface to generic ring elliptic curves. The main motivation is refactoring ECPP (e269d38) and ECM (fmpz_factor_ecm_double(nn_ptr x, nn_ptr z, nn_ptr x0, nn_ptr z0)).

The proposed interface handles multiple curves and points representation and automatically does conversion when it's worth it (for example, switching to Jacobian coordinates for point multiplication). The focus is on really preserving genericity and handling curves over generic commutative rings while having dedicated efficient routines for the main cases of interest (finite fields and Q).

Currently the performance of elliptic curve arithmetic either matches or outperforms ecpp_point_mul_gr but the interface and documentation (AI generated) are a bit heavy and clunky.

For now I'm focusing on simplifying the interface (the AI version exposes A LOT of things) and making the documentation human-readable.

Feel free to comment on this draft for any recommendations on clarity / interface / technical stuff.

[fredrik-johansson]

Looks quite good at a glance.

Consider changing gr_ec_ctx_t to a typedef for gr_ctx_t with the data stored in an inner context, and adding method tables, so that basic manipulation can be done via the generic interface without an extra wrapper layer.

There is gr_test_multiplicative_group but could also be gr_test_additive_group for generic testing.

[maelhos]

Consider changing gr_ec_ctx_t to a typedef for gr_ctx_t with the data stored in an inner context, and adding method tables, so that basic manipulation can be done via the generic interface without an extra wrapper layer.

I was thinking the same, but gr is for rings, no? The best we can do for elliptic curves is a $\mathbb Z$-module (since it's an abelian additive group). Silverman seemed to confirm that there are no good ways of making ring structures on EC (https://mathoverflow.net/questions/77859/can-we-make-a-useful-ring-on-an-elliptic-curve)

If we are ok with gr_mul/gr_sqr failing and that gr_mul_[ui/si/fmpz/] represents the $\mathbb Z$-module scalar multiplication, then gr_mul_fmpq fails when

• curve over Q and the denominator's division polynomial has no root
• curve over Fp and the denominator is not prime, then the k-torsion may be non-trivial, and we have multiple possibilities. We can say that we return one point up to k-torsion.
  Also depending on the case, if we have to use polynomial division, this is very costly: ~O(k^2).

And same thing for the division, powering, sqrt, gcd, factoriation, fractions and etc, so a lot of things would just fail. From a mathematic standpoint that's a bit weird.

There is gr_test_multiplicative_group but could also be gr_test_additive_group for generic testing.

I'll look into it

[fredrik-johansson]

GR is really generics, just designed with rings as the main use case. We already have GR structures that are just groups (permutation groups, Dirichlet groups, the modular group), vector spaces/modules (e.g. n x m matrices over R) or just sets that happen to support arithmetic between some of their elements (e.g. the set of matrices of any shape over R).

[GiacomoPope]

Elliptic curves are really groups and not rings / fields etc. I don't think they should be treated as gr_ctx_t.

For example, it's natural to feed elements of type gr_ctx_t into a polynomial, but I would not expect anyone to try and make a polynomial whose coefficients are points (for example)

One could argue that the whole system could be generalised with some general group gg or i suppose even general monoid gm then within a ring you would have both a group (from the action of +) and the monoid from the action of multiplication (then two groups for the case of fields)

However, this level of abstraction I think offers little value to the end user. Rather a new type curve which can have coefficients defined within anything of type gr would be interesting. There's even some nice cases of allowing elliptic curves to be defined where the coefficients are themselves elements of a polynomial ring. the gr_ctx_t is suitable for all of this I believe.

I do however also see that as soon as you start adding something like elliptic curves, FLINT is exposing itself to enormous scope creep and you end up with a TODO list which looks a lot like trying to match PARI.

When I had more free time I was working on Arrowhead precisely because i thought elliptic curves in flint would be a fun job, so I support the creation of ec_gr_ctx_t or gr_ec_ctx_t depending on how this type is best to be communicated

[GiacomoPope]

GR is really generics, just designed with rings as the main use case.

oh! I thought GR meant general rings

[maelhos]

Personally I really don't mind, I guess from a design perspective it can be nice to have most structure integrated in gr. As long as it is fine to make almost all gr function fail I think it's not really a problem integrating it.

[maelhos]

Looks quite good at a glance.

Consider changing gr_ec_ctx_t to a typedef for gr_ctx_t with the data stored in an inner context, and adding method tables, so that basic manipulation can be done via the generic interface without an extra wrapper layer.

There is gr_test_multiplicative_group but could also be gr_test_additive_group for generic testing.

Both should be done, I still haven't fully implemented a few nice features like letting $\mathbb Q$ partially act on elliptic curve point if the denominator allows it.

About that matter, I saw that gr_div_nonunique existed, I imagine then that if a division IS nonunique or the denominator of a multiplication with and fmpq element triggers that then we should return GR_DOMAIN right ?

Also, since we have different point representations, for now I kept the points as their own thing, and only the elliptic curve itself is included in the generic structures that gr supports. We could also have elliptic curve points be tied to gr but I fear that this makes a lot of things quite spaghetti and quite slower, since we would have a function table dispatch at each point operation.

[maelhos]

@fredrik-johansson Also I have a few questions on integration within gr, right now, gr includes mostly arithmetic stuff, and for example for elliptic curve specific stuff like computing the order of the group (if it is finite) is handled via gr_ec and not via overloaded function table. Since on the resultant PR you suggested the latter option, what is your stance in this case ?

[fredrik-johansson]

Operations specific to one structure don't need to be generic method.

The order of a group seems common enough to be generic. Just like there is gr_ctx_fq_order we could have something like gr_ctx_group_order. Or, since the structure doesn't really matter, these could just be captured by a common operation, something like gr_ctx_cardinality_fmpz.