Discussion related to cado-nfs

[Robert Balfour <rhb11931@gmail.com>]

Dear Paul,

Yes, looks like it's fixed now. Thank you!

Best regards,

Robert

On Thu, Sep 9, 2021 at 1:44 PM Paul Zimmermann <Paul.Zimmermann@inria.fr> wrote:

       Dear Robert,

thank you for the bug report. This was a nice bug (see the commit log).

Fixed in commit 271ad1f. Please can you confirm?

It could happen with degree 5 too, as long as you use a large value of nq.

Best regards,
Paul

> From: Robert Balfour <rhb11931@gmail.com>
> Date: Wed, 25 Aug 2021 15:34:27 +0100
>
>
> [1:text/plain Show]
>
>
> [2:text/html Hide Save:noname (6kB)]
>
> Dear all,
>
> While running polynomial selection on a 220-digit composite, I've noticed
> that polyselect will very occasionally find the same polynomial hundreds of
> times. The number of times the polynomial appears is always a number of the
> form 2 mod 14, most commonly 268, though perhaps this is an artefact of the
> parameters I used. I imagine this could be problematic if the polynomial in
> question was high-scoring, as copies of it might take up a large part of the
> priority queue.
>
> The issue may be related to the use of degree 6, as I've run many degree 5
> searches and have never seen this happen before.
>
> An example command is
>
> polyselect -P 12000000 -N
> 5272066026958413205513021090082556639441277154855572268239336980532402881465013381219738819137405617219594641652778228990107677072837959240400905630530715435664638237254654768053674178165309345879869729405448588458952991
> -degree 6 -t 2 -admin 15748320 -admax 15751680 -incr 420 -nq 46656
> -sopteffort 10
>
> which produces 282 copies of the polynomial
>
> # Raw polynomial:
> # n:
> 5272066026958413205513021090082556639441277154855572268239336980532402881465013381219738819137405617219594641652778228990107677072837959240400905630530715435664638237254654768053674178165309345879869729405448588458952991
>
> # Y1: 596510255164295958340450487
> # Y0: -263512688394977973691376832079085729
> # c6: 15748320
> # c5: 13551643
> # c4: -218061793231947823187578164
> # c3: 96330167362975118135560741138283790
> # c2: -24487764364517858671372756757420673
> # c1: -120000488463888088109792094537878702
> # c0: -10924560535761233666606096354806377
> # raw exp_E 75.68, lognorm 77.22, skew 2.03, 6 rroots
> n:
> 5272066026958413205513021090082556639441277154855572268239336980532402881465013381219738819137405617219594641652778228990107677072837959240400905630530715435664638237254654768053674178165309345879869729405448588458952991
>
> Y1: 596510255164295958340450487
> Y0: -262594493282429186537214460134357343
> c6: 182916736800
> c5: 1689358410130515845
> c4: 1316019719459862805924492
> c3: -169471667881071512508976351466
> c2: -31518096396680244263016200886784920
> c1: 1010006169143670592909109654997712502443
> c0: 42583239321072135934692647075740426314870055
> # exp_E 56.48, lognorm 64.31, skew 145018.07, 6 rroots
>
> Best regards,
> Robert Balfour