Re: bug in ellglobalred()

["Karim Belabas" <belabas@math.u-bordeaux1.fr>]

* Igor Schein [2005-11-08 21:56]:
> On Mon, Nov 07, 2005 at 07:27:43PM +0100, Karim Belabas wrote:
> > * Bill Allombert [2005-11-02 19:52]:
> > > We should probably use elldata to build a comprehensive test-suite for
> > > ellglobalred().
> > 
> > John sent me a nice script doing exactly this. I've included it as
> > 
> > 'make test-ellglobalred'
> > 
> > (~ 5 minutes to check all conductors up to 10^4). Having installed elldata
> > is a pre-requisite.
> 
> It did take 5m yesturday, today it takes less than 2s.  What happened?

ellsearch is horrendously slow when used in a loop: it must parse and load in
memory a large table even if only 1 curve (or 1 conductor as here) is
needed. 

In the bench script, I replaced ellseach by something like

  checkfile(n) =
  { local(v);
    v = read( Str(default(datadir,,1), "/elldata/ell", n) );
    for (i = 1, #v, check(v[i]))
  }

which checks all curves in a given 'elldata' file [ loading it only once of
course ].

If that inefficiency is a problem, there are a few possible improvements :

1) use direct access as above

2) caching (leave the "current" table in memory for later accesses)

3) implement a forell(N = min, max, ...) control structure, as has
   been already suggested [ with the same net effect as 2) ]

4) saving the 'elldata' files in binary format (using writebin instead of
   write) results in files which are 3.5 times larger [ compressed or not,
   no difference ], but load 15 times faster [ compressed or not, no
   difference again ].

   We can't distribute the tables in that format, which would make them
   architecture-dependant, but we can provide scripts automating the
   translation on a given machine.

    Karim.
-- 
Karim Belabas                  Tel: (+33) (0)5 40 00 26 17
Universite Bordeaux 1          Fax: (+33) (0)5 40 00 69 50
351, cours de la Liberation    http://www.math.u-bordeaux.fr/~belabas/
F-33405 Talence (France)       http://pari.math.u-bordeaux.fr/  [PARI/GP]