## Other

drummers-lowrise

Message boards : Sieving : Manual Sieving Stats

 Subscribe SortOldest firstNewest firstHighest rated posts first
Author Message
Allen Paschke

Joined: 12 Nov 15
Posts: 31
ID: 428118
Credit: 42,787,356
RAC: 25,714

Message 133073 - Posted: 21 Sep 2019 | 14:02:36 UTC

Comparing the 20 Sept vs. the 21 Sept Manual Sieving Stats for GFN18:
- I ran no GFN18, so my total "P's" Run remained unchanged at 309
- The Factors Found increased by 4,323 from 1,429 to 5,772
- The Removed from Sieve increased by 1,349 from 467 to 1,816

Does this make any sense, considering I made no GFN18 runs on 20 Sept?

Kellen

Joined: 10 Jan 18
Posts: 484
ID: 967938
Credit: 1,600,003,090
RAC: 0

Message 133074 - Posted: 21 Sep 2019 | 14:18:32 UTC - in response to Message 133073.
Last modified: 21 Sep 2019 | 14:19:32 UTC

Hi Allen,

Those increases are approximately a factor of 4, because Jim put the first 20,000P of sieving to 2G into the system for GFN18. The range went from 100M to 400M now for the stats :)

Regards,
Kellen

JimB
Honorary cruncher

Joined: 4 Aug 11
Posts: 918
ID: 107307
Credit: 977,945,376
RAC: 0

Message 133075 - Posted: 21 Sep 2019 | 14:24:47 UTC
Last modified: 21 Sep 2019 | 17:58:27 UTC

What he said. Let me explain more fully.

<rambling_long_explanation>

Originally sieving on all the GFN went to bmax=100M. Back then that was as far as the Genefer program could test to. But Yves kept making improvements to Genefer and adding new transforms. In its current form Genefer can test up to b=400M but with the addition of (slower) code it could easily test beyond that.

The sieving program we use used to be hardcoded to stop at b=100M but it turns out that it was always calculating up to b=2G and just not outputting those factors. The programs (there are two versions) were changed to output all factors found. When this happened, it was in the middle of sieving most n's and we had a mixture of bmax=100M and bmax2G. We've since resieved all of the GFN15, GFN16 and GFN17 that used to have a bmax of 100M to bmax=2G. For GFN18, all the sieving above p=20000P was from the newer sieve version and everything under that was from the older one. I took it upon myself to resieve GFN18 from 0-20000P over the summer. On Friday 20 September I recreated the stats sieve and updated everything. The stats cover only sieving within the range of the sieve file I use there. Right now, GFN15-18 and GFN22 have stats for b=0-400M, GFN19-21 have b=0-100M, and through me being half-asleep GFN23 has b=0-2G. I'm going to redo GFN23 to b=0-400M today because processing the entire b range several times a day takes too long.

However, the stats sieve is not used to generate new candidates. For new candidates I have sieves on the machine I'm typing this on and they all go to either b=0-100M (GFN19-21) or b=0-2G (everything else). Why do I have two copies? Well, there are some candidates not removed by sieving which we nonetheless know are not prime, like any b that's a power of 2 (2, 4, 16, 32, etc.) and others that won't be tested because we already tested the equivalent number in a different n. Trivial example: 2^4194304+1 = 16^1048576+1 = 256^524288+1. I don't remove those from the sieving stats, but do from the sieve used to generate work.

So, what you witnessed was me starting from a b=0-400M sieve rather than a b=0-100M sieve and my programs counting a much wider range of factors to put into the stats. The reason I used smaller sieves for stats was to decrease how much time it takes to produce those stats. It's also a good way to ensure that I have two independent copies of all the factor files in addition to everything being kept on our server. If we ever start testing candidates for b>400M then I'll redo the stats at that time. Starting from p=0 it takes close to an entire day to do that, which is why I don't change the stats sieve very often.

And by the way, once a bunch of work is done I create a new sieve at some p level. For example the GFN22 sieve I'm using at the moment is for p=950869P. So all factor files below that level are already included and don't have to be looked at again. That keeps the stats computation time down. When sieving starts taking a long time I create a new sieve or if we're near the end of the current max sieving range I'll wait it out until I can create a "final" sieve. Or at least final until sieving on that n is reopened. An example of that is me using a p=300000P sieve for GFN18. I'm waiting for one final range to be completed and then I'll create a p=420000P sieve.

</rambling_long_explanation>

JimB
Honorary cruncher

Joined: 4 Aug 11
Posts: 918
ID: 107307
Credit: 977,945,376
RAC: 0

Message 133110 - Posted: 22 Sep 2019 | 11:16:31 UTC

GFN23 stats now reflect a b=0-400M sieve like every other n sieved to b=2G.

Kellen

Joined: 10 Jan 18
Posts: 484
ID: 967938
Credit: 1,600,003,090
RAC: 0

Message 133111 - Posted: 22 Sep 2019 | 13:04:34 UTC - in response to Message 133075.

Hi Jim,

Another great "behind-the-scenes" explanation; thanks! These details are always much appreciated.

Regards,
Kellen

GDB

Joined: 15 Nov 11
Posts: 285
ID: 119185
Credit: 3,936,291,729
RAC: 2,124,060

Message 133907 - Posted: 15 Oct 2019 | 15:21:06 UTC - in response to Message 133110.

GFN23 stats now reflect a b=0-400M sieve like every other n sieved to b=2G.

GFN23 user stats are identical to GFN22 user stats.

JimB
Honorary cruncher

Joined: 4 Aug 11
Posts: 918
ID: 107307
Credit: 977,945,376
RAC: 0

Message 133941 - Posted: 16 Oct 2019 | 1:46:39 UTC - in response to Message 133907.

GFN23 stats now reflect a b=0-400M sieve like every other n sieved to b=2G.

GFN23 user stats are identical to GFN22 user stats.

You are correct. Or you were, now fixed. Thanks for spotting it.

Message boards : Sieving : Manual Sieving Stats