Seeking help verifying possible unlisted j-invariant with rank 3

[Chris Rice]

Dear LMFDB Support Team,

I’m seeking help verifying whether a rational elliptic curve I’ve been studying is already listed in the LMFDB, or whether it might be a valid candidate for inclusion.

The curve has minimal model:

    y^2 + x*y = x^3 - x^2 + 46*x + 121

Its j-invariant is:

    j = 10633486599 / 13734361

If I have used it correctly, Sage reports that the curve has rank 3 and forms its own isogeny class. I used a banded height scan to recover twelve rational points, including one that matches a generator returned by `.gens()`. All twelve points were verified to lie in the Mordell–Weil lattice via canonical height pairing and Gram matrix projection.

The curve was identified as part of a programmatic search over thousands of randomly generated Weierstrass models. From a filtered set of over 300 rank-1 to rank-4 candidates, this was the first rank-3 curve encountered. I could not find its j-invariant listed at:

    https://www.lmfdb.org/EllipticCurve/Q/?jinv=10633486599/13734361

I apologize if I’ve overlooked something, I’m still learning how to use the database interface. If there’s an equivalent model already catalogued, or if I’ve misunderstood anything, I’d very much appreciate any guidance. I’m happy to share the full writeup, point data, or verification scripts if that would help.

Many thanks for your time and expertise.

Sincerely,  

Christopher David Rice  

Independent researcher

[John Cremona]

Your curve has conductor 13734361 = 2389 * 5749 so is not in the
collections which the LMFDB currently contains, which are listed here:
https://www.lmfdb.org/EllipticCurve/Q/Completeness.

It is trivial to write down random Weierstrass equations and not hard
to find curves of rank 3 or more, these are not rare. It is not very
interesting to broadcast every one you find!

Since (as you say) Sage can very easily find the rank and generators,
it is a triviality to generate as many rational points on the curve as
you want by taking linear combinations of the generators. Your
statement "I used a banded height scan to recover twelve rational

points, including one that matches a generator returned by `.gens()`.
All twelve points were verified to lie in the Mordell–Weil lattice via

canonical height pairing and Gram matrix projection." suggests that
you are not doing this.

John Cremona

> --
> You received this message because you are subscribed to the Google Groups "lmfdb-support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to lmfdb-suppor...@googlegroups.com.
> To view this discussion, visit https://groups.google.com/d/msgid/lmfdb-support/4d28482c-ecea-4360-9a0b-6dac0bcf7284n%40googlegroups.com.

[Chris Rice]

Dear Professor Cremona,

Thank you sincerely for taking the time to respond. I’m truly honored, and I appreciate your clarity. I now better understand what LMFDB seeks to catalog in terms of mathematical significance and nontriviality.

You were absolutely right to point out that I did not find points by taking linear combinations of known generators. In fact, I used a structured, height-based rational scan (banded in x) to find points before calling .gens(). The generator basis returned by Sage was used afterward to confirm that all twelve recovered points lie in the Mordell–Weil lattice, and that none appeared to be torsion (we explicitly checked torsion order and canonical heights). Interestingly, one of the twelve points matched one of Sage’s generators (up to sign), though that was only recognized in hindsight.

I realize now that my message did not explain this well... My curiosity about the j-invariant and possible inclusion in the database got ahead of a clear explanation. Your reply helped me calibrate what would actually make a curve interesting or relevant to the community.

I’m now working to adapt this method to higher-rank curves, particularly in the range r>4, where Sage’s generator detection sometimes becomes less reliable. I’m curious to see whether structured point-finding might help identify independent points in such settings, though I recognize the limitations without full descent machinery.

Thank you again for your time and expertise.

Sincerely,  

Christopher David Rice

[John Cremona]

I meant to add that another way to prove that points are independent
without relying on the precision of height computations (though it is
fast to do those to high precision) is described in my old paper here:
https://www.jstor.org/stable/44238903?seq=1.

This is implemented in my C++ library eclib (the program is called
indep_test, not just indep as in the paper), but I never got round to
wrapping that or re-implementing that in Sage. This has the advantage
of only relying on a matrix over F_2 has full rank, rather than that
some large real matrix has nonzero determinant. However, when the
points are dependent, this method does not give you a relation,
whereas that is possible using the height pairing -- with care, owing
to precision issues. Of course, if floating point computations give
you a relation, then you can check that it holds exactly using exact
arithmetic; but if the precision is not high enough then you may miss
genuine relations. This is implemented in Magma in the function
IsLinearlyIndependent(Plist) but it is not yet in Sage (something else
on my long to-do list).

John

[Chris Rice]

Thanks for pointing me to your paper and the indep_test tool, that’s really helpful. It might be exactly what I’ve needed. So far, my point-finder seems solid for lower-rank curves and recovering rational points, but confirming whether those points are generators has been out of reach. I’m now starting to explore higher-rank cases where Sage may stop returning full generator sets, so having a binary test for independence that avoids floating-point thresholds would be ideal.

I am really grateful for your guidance so far and the tools you’ve made available.

P.S. If and when your time permits, I’d truly appreciate the chance to stay in touch as I continue developing these tools alongside yours, but I completely understand how busy you must be.

Chris