Riesel base 2 discussion

[Joe O]

Here is a graph of found primes, Yves Gallot's predictions and some speculation.
Note that the last two found primes are far to the right, or far above, the predicted. I would recommend testing from the last found prime on the line.
i.e. n = 2639439
I have a dat file dated 2007-04-29. Does anyone have a more recent version?
If you have a dat or ABCD file, could you send it to factrange at yahoo dot com? I can compare it with what I have.
If anyone has factor files, I would appreciate it you would send them. I have PERL scripts set up to parse them and apply them to dat/ABCD files. The goal is to get as up to date a sieve file as possible.
I am also working on parsing lresult files and using them to trim the sieve file.
Yes, this is risky, but it would allow for a jump start for some LLR work.

#left	k	n	Discoverer     Date
135	267763	264115	Dave Linton   19 Feb 2000
134	27253	272347	Ray Ballinger   10 Oct 1998
133	130139	280296	Dale Andrews   02 Feb 2002
132	159371	284166	Janusz Szmidt   14 Jan 2002
131	245051	285750	Tom Kuechler   15 Nov 2000
130	39269	287048	Richard Heylen   25 Mar 2002
129	376993	293603	Reto Keiser   08 Sep 2002
128	235601	295338	Helmut Zeisel   06 Mar 2003
127	220063	306335	Olivier Haeberlé   03 Sep 1999
126	42779	322908	Ray Ballinger   26 Jul 1999
125	189463	324103	Dave Linton   15 Jul 2000
124	104917	340181	Janusz Szmidt   13 Nov 1999
123	148901	360338	Mark Rodenkirch   05 Mar 2002
122	443857	369457	Nuutti Kuosa   27 Aug 2001
121	398533	419107	Dave Linton   04 Sep 2002
120	416413	424791	Dave Linton   28 Apr 2003
119	46271	428210	Patrick Pirson   29 Apr 2001
118	299617	428917	Dave Linton   22 Jul 2002
117	277153	429819	Jeff Wolfe   21 Nov 2002
116	382691	431722	Ray Ballinger   27 Feb 2003
115	201193	457615	Daval Davis   03 Feb 2003
114	401617	470149	Dave Linton   27 Dec 2002
113	465869	497596	Lucas Schmid   27 Jan 2003
112	144643	498079	Richard Heylen   12 Dec 2000
111	43541	507098	Ray Ballinger   01 Oct 2000
110	401143	532927	Olivier Haeberlé   11 Jun 2003
109	458743	547791	Olivier Haeberlé   22 Oct 2003
108	98939	575144	Olivier Haeberlé   30 Nov 2001
107	89707	578313	Richard Heylen   02 Apr 2003
106	357491	609338	Lucas Schmid   17 Jan 2003
105	222997	613153	Olivier Haeberlé   28 Nov 2001
104	103259	615076	Olivier Haeberlé   23 Dec 2002
103	279703	616235	Dhumil Zaveri & RSP   07 Jan 2004
102	126667	626497	Ray Ballinger   09 Jun 2003
101	109897	630221	Olivier Haeberlé   22 Apr 2003
100	215503	649891	Olivier Haeberlé   28 Apr 2003
99	261221	689422	Sean Faith & RSP   22 Dec 2003
98	204223	696891	Olivier Haeberlé   23 Mar 2003
97	220033	719731	Olivier Haeberlé   19 Apr 2004
96	212893	730387	Olivier Haeberlé   15 Oct 2003
95	246299	752600	Kevin O'Hare & RSP   23 Jan 2004
94	460139	779536	Drew Bishop & RSP   26 Mar 2004
93	659	800516	Dave Linton   01 Mar 2004
92	93997	864401	Guido Stolz & RSP   01 Apr 2004
91	170591	866870	Drew Bishop & RSP   15 Apr 2004
90	309817	901173	Helmut Michel & RSP   07 Jun 2004
89	150847	1076441	Darren Wallace & RSP   15 Aug 2004
88	412717	1084409	Holger Meissner & RSP   22 Aug 2004
87	504613	1136459	Magnus Mischel & RSP   17 Oct 2004
86	500621	1138518	Darren Wallace & RSP   18 Oct 2004
85	350107	1144101	Sean Faith & RSP   24 Oct 2004
84	152713	1154707	Ray Ballinger   23 Oct 2004
83	71009	1185112	Drew Bishop & RSP   05 Dec 2004
82	502541	1199930	Ryan Sefko & RSP   21 Dec 2004
81	192089	1395688	Guido Stolz & RSP   10 May 2004
80	149797	1414137	Peter van Hoof & RSP   13 Mar 2005
79	325627	1472117	Will Fisher & RSP   05 Apr 2005
78	234847	1535589	Darren Wallace & RSP   09 May 2005
77	110413	1591999	Will Fisher & RSP   08 Jun 2005
76	469949	1649228	Steven Wong & RSP   28 Oct 2007
75	357659	1779748	Drew Bishop & RSP   25 Sep 2005
74	417643	1800787	Greg Childers & RSP   05 Oct 2004
73	345067	1876573	Dave Linton   13 Nov 2005
72	467917	1993429	Steven Wong & RSP   25 Dec 2005
71	196597	2178109	Auritania Du & RSP   09 May 2006
70	114487	2198389	Bruce White & RSP   23 May 2006
69	450457	2307905	Jeff Smith & RSP   28 Mar 2006
68	275293	2335007	Japke Rosink & RSP   21 Sep 2006
67	26773	2465343	Anonymous & RSP   01 Dec 2006
66	342673	2639439	Dhumil Zaveri & RSP   28 Apr 2007
65	113983	3201175	Ian Keogh & RSP   01 May 2008
64	485767	3609357	Chris Cardall & RSP   24 Jun 2008

[kar_bon]

see Wilfrid Keller's page here or my overview with all primes for n>8191 here.

i wrote there, the remaining 64 k's left got no prime less than 3.2M,
because that was the last border i was aware when RieselSieve was working, but not for sure for all k's!

[enderak]

So, it looks like there's a new subproject and forum section this morning on Primegrid called "The Riesel Problem"... is this project being taken over by Primegrid?

[KEP]

Originally Posted by Dougal

KEP,i split the file into 5 smaller files,but i only have 4 cores on it,so 1 file is completely untested.i only have about 2000-3000 tests done.

It is actually pretty good job. Do you have an estimate on how long each test approximately takes and at what n they take the time you can/cannot give?

KEP

[Dougal]

takes about 17-18000 seconds(that figure is off the top of my head,but is fairly acurate) at n=2950000 on a 3.00 GHZ pentium4.

[Dougal]

looks to me that Primegrid have started an effort on this,and are sieving it,surely it has enough sieving done for the forseeable future?

[Ken_g6]

Looks like PrimeGrid isn't convinced that they either can use the sieve file (that it's good) or that they should (that they have permission).

But it looks like they are interested in any factors or residues you may have lying about.

[gd_barnes]

So what is the thinking here? Should we attempt anything? We would need some sort of excellent stats tracking system to generate enough interest to make it worthwhile. I have the sieved file and a main public server machine that is used for NPLB and CRUS with a commercial-grade internet set up. I can load the file into an LLRnet server at any time.

Hasn't the file already been sieved into the ground? That was the problem with RieselSieve. They spent way to many resources on sieving and too little on searching. Why is PrimeGrid sieving and looking for factors? It's time to search. You can knock out candidates a lot faster at n=3M than you can sieving at this point. It's almost like people are afraid to search it.

IMHO, the search should start at an even n=3M on all k's except perhaps k=2293 and other known k's where there is verifiable evidence that it was searched to n=~4M or some other depth above n=3M.

BTW, I have renamed this thread to "Riesel base 2 discussion" because RieselSieve no longer exists.


Gary

[mdettweiler]

Originally Posted by gd_barnes

So what is the thinking here? Should we attempt anything? We would need some sort of excellent stats tracking system to generate enough interest to make it worthwhile. I have the sieved file and a main public server machine that is used for NPLB and CRUS with a commercial-grade internet set up. I can load the file into an LLRnet server at any time.

Hasn't the file already been sieved into the ground? That was the problem with RieselSieve. They spent way to many resources on sieving and too little on searching. Why is PrimeGrid sieving and looking for factors? It's time to search. You can knock out candidates a lot faster at n=3M than you can sieving at this point. It's almost like people are afraid to search it.

IMHO, the search should start at an even n=3M on all k's except perhaps k=2293 and other known k's where there is verifiable evidence that it was searched to n=~4M or some other depth above n=3M.

BTW, I have renamed this thread to "Riesel base 2 discussion" because RieselSieve no longer exists.


Gary

According to the thread ken_g6 linked to, they're actually doing the sieving from scratch. Here's why:

The primary reason is that this is PrimeGrid's first venture into the Riesel problem. Prior to this, we did not have a sieve file. This one was started from scratch for the 64 k's remaining for n<50M. We have a complete history with this file and have a record of all factors to our current sieve depth.

We are aware that there exists a sieve file from a previous effort. However, that project ended quite abruptly and we are not privy to the final bounds reached in the sieve file. Also, access to the file was never granted to PrimeGrid, and the file only went to n=20M.

If anyone here has a copy of the old sieve file, they may want to post to that effect in the PrimeGrid forum thread; since the file is already sieved so extremely far anyway, I'd just say heck on the exact depth, let's take what we've got and roll with it. It sounds like they don't have a copy of the RS sieve file, so if they could get their hands on one they may do just that.

Nonetheless, though, I can see the wisdom of starting from scratch. That way they'll have full records of all residuals and factors: i.e., they'll know for sure that they're not missing anything, which is more than they can say for the old file (for which the original factors and residuals are largely lost). And with PrimeGrid's firepower, I imagine they can quite feasibly re-do what was already done in quick enough time that it's probably the way to go.

[gd_barnes]

OK, they've taken it over. Let them have it.

I completely disagree on 2 things:

First, I think the former RieselSieve's file is good. It doesn't matter if we don't know the depth. That can be concluded by attempted searches at different depths. But who cares about the depth until it has been searched to at least n=5M or more? We all know that it has been sieved into the ground. Both KEP and I have the file. I got it from KEP. He got it from the project at least a year before it went away.

Second, as anyone who's been around me for any length of time would know, I completely disagree with sieving n<50M. The original 20M was too large to start with back in 2002-03 or whenever RieselSieve started but that would be a good depth now. Do they think this is SOB with 5 k's remaining? There's a monster difference between searching 5 k's and 64 k's. Sieving 5 k's to n=50M when at a current search depth of n=~14M at this time makes sense (a.k.a. SOB). Sieving 64 k's to n=50M when at a current search depth of n=~3M does not (a.k.a PrimeGrid).

I'll reiterate for the umpteenth time: Doing too much of tomorrow's work when machines/software will be faster with today's slower resources is very inefficient in the long run. It's even more inefficient for conjecture searches where a large part of the file won't be needed for many k's. They should sieve only n<20M now to an optimal depth and start prime searching. Sieving and testing to n=20M will still take 10s of thousands of CPU years. When they reach n=10M-12M in testing, which will likely take at least 10 years (possibly 15-20), THEN they can perhaps begin a sieve for n=20M-50M when computer capacity and software have likely increased 10-fold or more. Any large efficiency gain by sieving a large n-range now is completely wiped out and overwhelmed by future increases in capacity/speed of hardware/software.

I can demonstrate this with an example: Had RieselSieve sieved n<10M to a proper optimum depth, cut off sieving, and spent the last 4-5 years using those same amount of resources doing nothing but primality searching, I bet they easily would have reached n=5M by now. And within the next 1-2 years when they reached n=6M, they could then start a sieve for n=10M-25M that runs concurrently with primality testing. And that sieve would have been conducted 6-7 years later then the original sieve during which time I know for a fact that sr2sieve (I know they used something different but the point still applies) has increased its speed at least 3 times and likely 5-6 times. I've only been in prime searching long enough to know for sure that its speed has increased 3 times. Increases in computer speed/capacity have also likely increased 5 times or more during that time. Multiply them together and it's 25 times more efficient to sieve now than 6-7 years ago. Even if both have increased only 3 times, it's 9 times more efficient.

Sieveing n<50M will take 60% longer to sieve to the same depth as n<20M.

I wish we had the resources to just start searching. I cannot understand why people think things have to be sieved for such huge ranges or so deep for multi-year or multi-decade efforts with today's resources. You cannot and I will yell it CANNOT find primes by sieving! (Well, at least no primes larger than the sieve depth squared, which might be what, 30-35 digits or so? )

Enough of the rant. I suppose it will be several more years before another Riesel base 2 conjecture prime is found. It kind of disgusts me but it's not for me to worry about anymore. I have to remind myself to choose my battles. :-) CRUS will just keep plodding along on all other bases sieving moderate-size ranges, searching, sieving some more, searching some more, etc. We won't use 2010 computers/software to sieve efforts that won't be worked on until 2020 or 2030 for team efforts anyway. Individuals are welcome to do what they want.

One good thing though: CRUS is still keeping the 2 remaining even k's. The way Prof. Caldwell defined the conjectures in a math paper that he had published in late 2008-early 2009 (I believe) as well as the way that CRUS adopted them, k's that are multiples of the base are considered. Therefore, from our perspective, there are 66 k's remaining.

Sometime in the near future, I'll update the CRUS pages to show all of the k's searched to n=3M except for our 2 even k's that are near n=1M and k's known to be searched to a higher depth by individuals coordinating with the former RieselSieve project such as k=2293 that is at n>4M. I'll also show that PrimeGrid now has the other 64 k's reserved.


Gary

[ValerieVonck]

Does anyone have a program to convert a dat file to an input file that can server as input for prp/llrnet?

Regards
C.

Found it on my pc!

Posted it on my site!: http://users.skynet.be/bk261068/RieselConvert.exe