Re: ellintpoints(E) workaround

[hermann@stamm-wilbrandt.de]

On 2026-10-09 12:14, John Cremona wrote:
...
> On Friday, October 9th, 2026 at 9:48 AM, Bill Allombert 
> <Bill.Allombert@math.u-bordeaux.fr> wrote:
>
> > On Wed, Oct 07, 2026 at 12:52:18AM +0200, hermann@stamm-wilbrandt.de 
> > wrote:
...
> > > My workaround ellintpoints(E) (named after existing ellratpoints(E)) calls
> > > out to sagemath E.integral_points():
> > >
> > > sage(cmd) = eval(externstr(Str("sage -q -c \"", cmd, "\""))[1]);
> > >
> > > ellintpoints(E) = {
> > >   sage(Str("print([[int(P[0]), int(P[1])] for P in EllipticCurve(",
> > >        E[1..5],").integral_points()])"));
> > > }
> >
> > What gives your function for
> > E = [1, -1, 1, -11, 16]
> > and
> > E = [0, 1, 0, 44, -847]
I wrote 18 line ec_ipts.gp gist to investigate, and the gist comments 
show the output for both:
https://gist.github.com/Hermann-SW/c29697df5e215654f9d5dd92c844b22f

The pointer to SageMath elliptic curve doc shows John Cremona as one of 
the authors.

I asked Gemini for example where sage-pari is non-empty and got infinite 
family, here for 10^9 used in gist:
(sage) hermann@9950x:~/sage$ as="[0, 0, 0, 200000, 1]" gp -q < 
ec_ipts.gp
   E[1..5]=[0, 0, 0, 200000, 1]
ellrank(E)=[2, 2, 0, [[0, 1], [2674, 140195]]]
     #sage=6
     #pari=4
pari-sage []
sage-pari [[10000000000, -1000000000000001], [10000000000, 
1000000000000001]]
(sage) hermann@9950x:~/sage$

Section "Why Sage misses points on your earlier curves" at end of last 
comment
explains why SageMath did miss points, and it states:

' PARI/GP's ellratpoints brute-forces up to the boundary, which makes it 
much safer
for finding "small" coordinates that Sage's algebraic algorithms 
occasionally trip over! '


> NB These are the first two curves where Sage's current code misses one 
> or more points: x=20829482
> for the first which is 7 times the generator;  x=176 and 179 for the 
> second, from  5 and 6 times the
> generator, though it does find 11 times the generator.  I said that 
> that code has bugs!   It is a very
> frustrating algorithm since for rank 1 curves like this it is very fast 
> to check which of the first (say)
> 100 multiples of the generator are integral.
Your statements are experimentally confirmed in this gist comment:
https://gist.github.com/Hermann-SW/c29697df5e215654f9d5dd92c844b22f?permalink_comment_id=6417132#gistcomment-6417132

Regards,

Hermann.