Bug in ellap() (fwd)

[Karim BELABAS <Karim.Belabas@math.u-psud.fr>]

Hi,

  I have been notified of the following bug [ couldn't get back to the person
who sent it to me, maybe he reads this list? ]. It still occurs in the
development versions, and is not Linux or ix86 specific. It is a bug in
apell1(), my implementation of Shanks/Mestre (with Montgomery's trick).

apell1() is quite fast for "smallish" primes, competitive with more
sophisticated systems like Magma I believe [ in this range. It can't compete
with SEA for large primes ]. Mark Watkins already fixed two fatal bugs in
version 2.2.3 but apparently (at least) one still remains.

I'll see whether I can debug it today and include a fix in the 2.2.4 release.

Cheers,

    Karim.
-- 
Karim Belabas                    Tel: (+33) (0)1 69 15 57 48
Dép. de Mathematiques, Bat. 425  Fax: (+33) (0)1 69 15 60 19
Université Paris-Sud             Email: Karim.Belabas@math.u-psud.fr
F-91405 Orsay (France)           http://www.math.u-psud.fr/~belabas/
--
PARI/GP Home Page: http://www.parigp-home.de/

---------- Forwarded message ----------
From: Mariusz Wodzicki
Subject: Bug in pari 2.1.4/2.2.3alpha

Attached is a transcript of a gp session which demonstrates
that there is a bug in `ellak' for version 2.2.3alpha (using
version 2.1.4 yields identical results). I inserted newlines
for added clarity.

I encountered a few more times similarly anomalous behaviour
of ellak with other elliptic curves.

I should add that the curve E below is *minimal*.

Mariusz Wodzicki

-----------------  transcript  ----------------
[...]
                    GP/PARI CALCULATOR Version 2.2.3 (alpha)
                i686 running linux (ix86 kernel) 32-bit version
[...]
(12:27) gp> \p60
   realprecision = 67 significant digits (60 digits displayed)

(12:27) gp> E=ellinit([0,0,0,-10301051460877581926458079712219,-12725370882271967125361344545020920373899020890])

%1 = [0, 0, 0, -10301051460877581926458079712219, -12725370882271967125361344545020920373899020890, 0, -20602102921755163852916159424438, -50901483529087868501445378180083681495596083560, -106111661199648164770391379334345694007911188530334641857903961, 494450470122123932469987826186512, 10994720442282979596312201686898075203048754048960, 8801325626543617378715342567179875645441710041821751172223331378176, (161935064091375222999942961340808268663260869557849454245947360648340530772065772436358548068 /11790184577738684974487931036710010027437133007841637694272081),
[3706040377703690.00000000000000000000000000000000000000000000]
[-1853020188851832.99999999999999999999999999999999999999999999]
[-1853020188851856.99999999999999999999999999999999999999999999]
, 0.0000000421355987656810350996504853117175654178286539772459306919417, (0.00000048080967492056690534766737916855648085 I), -39039057.591083919369470251185399511402, (-520034125.18279377438408853673963614503 I), 2.0259203545110538634939491248112513723 E-14]

(12:28) gp> isprime(1167254453)
%2 = 1

(12:29) gp> ellak(E,1167254453)
%3 = 9338178810

(12:29) gp> 2*sqrt(1167254453)
%4 = 68330.2115612120726880311365437175076642446854767291314157246

%%% VIOLATES HASSE's INEQUALITY


(12:30) gp> isprime(2015279269)
%5 = 1

(12:30) gp> ellak(E,2015279269)
%6 = 3274667602

(12:30) gp> 2*sqrt(2015279269)
%7 = 89783.7238924739632566262868661064123805896777931596322638617

%%% VIOLATES HASSE's INEQUALITY