Stephan Ehlen on Tue, 23 Jul 2013 10:54:37 +0200 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: Bug in bnfcertify? |
Will the patch be included in the next stable release? (And when will that be?) I'm asking because I would like to make sure that the next sage release also fixes this issue for sage. Best, Stephan On Mon, Jul 22, 2013 at 9:22 PM, Stephan Ehlen <ehlen@mathematik.tu-darmstadt.de> wrote: > Great! > > Thanks a lot for your reply. > (Of course, I should have mentioned the version number... it is 2.5.1.). > > Best, > Stephan > > > On Mon, Jul 22, 2013 at 8:45 PM, Karim Belabas > <Karim.Belabas@math.u-bordeaux1.fr> wrote: >> Hallo, >> >> * Stephan Ehlen [2013-07-22 19:49]: >>> I tried to compute class numbers of Hilbert class fields of several >>> imaginary quadratic fields, originally using sage but sage basically >>> interfaces pari/gp for this purpose. In one particular example, the >>> computation took very long, so I tried to find out what was going on. >>> If I perform bnfinit() in pari/gp with the polynomial that defines the >>> Hilbert class field in this case, the process terminates after less >>> than a minute or so on my laptop. It is the bnfcertify that takes so >>> long. Well, in order to see if we end up in an infinite loop or so, I >>> turned on debugging and was a bit surprised to see that pari continued >>> with the function testprimes beyond the Minkowski bound in this case. >> >> (Actually, Zimmert's twin class bound) >> >>> Looking at the source code only briefly, it seems that the second for >>> loop in 'testprimes' in the file buch2.c does never terminate. >> >> In 'master' (2.6.1, development git-6446ba6), the computation stops for >> p = 1015919 as expected (with default primelimit). >> >> In 'stable' (2.5.4), the second loop in testprimes() indeed does not >> terminate :-(. The attached patch fixes this. >> >> >> 2.6.0 and later are not affected because all loops over consecutive primes >> have been rewritten (and simplified) using the new forprime_next() iterator. >> >> 2.3.* and earlier are not affected because a loop over primes larger than >> primelimit in this function simply raised an exception. >> >> Cheers, >> >> K.B. >> -- >> Karim Belabas, IMB (UMR 5251) 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-bordeaux1.fr/~kbelabas/ >> F-33405 Talence (France) http://pari.math.u-bordeaux1.fr/ [PARI/GP] >> `