* Karim Belabas [2016-11-02 22:47]:
> * Bill Allombert [2016-11-01 23:18]:
> > On Tue, Nov 01, 2016 at 02:31:34PM -0700, John Jones wrote:
> > > Found a new problem with rnfkummer
[...]
>>> ? default(realprecision,1000)
>>> ? pol=x^7 - 658
>>> %2 = x^7 - 658
>>> ? allocatemem(2^32)
>>> *** Warning: new stack size = 4294967296 (4096.000 Mbytes).
>>> ? bnf=bnfinit(subst(pol,x,y),1);
>>> ? B=[[56, 0, 0, 0, 0, 0, 0; 0, 4, 0, 0, 0, 0, 0; 0, 0, 4, 0, 0, 0, 0; 0, 0,
>>> 0, 4, 0, 0, 0; 0, 0, 0, 0, 4, 0, 0; 0, 0, 0, 0, 0, 4, 0; 0, 0, 0, 0, 0, 0,
>>> 4], [1]];
>>> ? bnr=bnrinit(bnf,B,1);
>>> ? sgl = subgrouplist(bnr,[2],1);
>>> ? rnfkummer(bnr,sgl[6])
>>> %7 = 0
>>
>> Indeed. The first bad commit is :
>>
>> commit c3a8e9cb16a4a80111959456557316d3ef0442c2
>> Author: Karim Belabas <Karim.Belabas@math.u-bordeaux.fr >
>> Date: Sun Sep 11 13:35:27 2016 +0200
>>
>> 30- [libpari] pr_uniformizer, prV_lcm_capZ
>>
>> - rewrite unif_mod_fZ -> pr_uniformizer (+allow t_INT result)
>> - cleanup idealtwoelt2 (+ fix bug where hnfdivrem called with 'a'
>> not a ZV)
>
> It seems that both versions are wrong, in a different way:
>
> 1) one returns 0, the other returns x, at the given realprecision.
>
> 2) both return degree 2 polynomials (different but defining isomorphic
> extensions!) at precision 10000
>
> So it's definitely a problem, but not a regression. It's actually due to
> the known fact that we don't compute signs of real embeddings (signatures)
> reliably for elements of titanic size, as here (the regulator is ~ 4.8 E8),
> so bnrisprincipal results are essentially random when the accuracy is too low.
>
> There's an easy and reliable algorithm for signatures, but much slower
> (about 1000 times slower in this particular case). Not sure how it would
> impact the whole computation, but my guess is that the slowdown would be
> noticeable. I'll try once the kb-nfCRT branch is merged (this patch reduces
> the need for such computations...)
I merged the branch and incorporated the new algorithm in 'master'. I did not make
it 100% safe: it starts by a floating point computation and only
switches to the slow reliable algorithm if in doubt. This way there is
no slowdown (because the new algorithm is rarely exercised).
I can no longer reproduce this class of bugs, at all precisions, including \p38.
Can you test this ?
Cheers,
K.B.
P.S. bnrinit no longer needs (the previously mandatory) flag = 1 in master:
bnrinit(bnf, B) is enough; in principle flag = 1 is now only useful for
debugging purposes (a few functions still needs to be upgraded, but
nothing in the rnfkummer range).
--
Karim Belabas, IMB (UMR 5251) Tel: (+33) (0)5 40 00 26 17
Universite de Bordeaux Fax: (+33) (0)5 40 00 21 23
351, cours de la Liberation http://www.math.u-bordeaux.fr/~kbelabas/ Talence (France) http://pari.math.u-bordeaux.
F-33405fr/ [PARI/GP]
`