The probable primes - Page 33

Puzzle-Peter · 2012-12-16, 06:01

Hi Norman,

thanks! It is the nature of records that they will be broken some day. Let's see who will take primo to the next level.

philmoore · 2012-12-17, 00:19

Congratulations, Peter and Marcel! Thanks also to Norman, whose previous work helped Marcel update Primo to the current multi-core version. Only 18 more probable primes to certify to prove the dual Sierpinski conjecture as a theorem!

Puzzle-Peter · 2013-01-16, 17:12

I tried the next candidate, 2^73360+10711 but it wouldn't get past test1. It seems we reached the end of primo's useful range.

henryzz · 2013-01-16, 22:09

Might be worth waiting until http://mersenneforum.org/showthread.php?t=17554 is a viable option.

The method needs to be checked and a program needs to be made public. If ecpp ran in O(x) then this runs in O(x^(3/4)). In other words a lot faster once overhead is insignificant.

philmoore · 2013-01-17, 17:26

Quote:

Originally Posted by Puzzle-Peter

I tried the next candidate, 2^73360+10711 but it wouldn't get past test1. It seems we reached the end of primo's useful range.

Thanks for trying this. I had hoped that maybe the next two, 2^73360+10711 and 2^73845+14717, might yield to primo. I wonder if your log file would be of use to Marcel Martin in case he might be interested in extending the capabilities of the program.

Puzzle-Peter · 2013-01-17, 22:10

Quote:

Originally Posted by philmoore

Thanks for trying this. I had hoped that maybe the next two, 2^73360+10711 and 2^73845+14717, might yield to primo. I wonder if your log file would be of use to Marcel Martin in case he might be interested in extending the capabilities of the program.

So did I hope but Marcel Martin did not sound very interested in making major changes to primo. I am afraid this is the end of that path.

henryzz · 2013-01-17, 22:19

Quote:

Originally Posted by Puzzle-Peter

So did I hope but Marcel Martin did not sound very interested in making major changes to primo. I am afraid this is the end of that path.

It might be worth trying 2^73845+14717. You were unlucky with the smaller one that there was nowhere to backtrack to since it was the first iteration. Maybe that will be more lucky.

Batalov · 2013-01-17, 22:48

...and Peter, you probably already cranked the factoring limits to the top (2^32), right?
_______________

P.S. I started an 8-thread test on 2^73845+14717 (no intent to finish!)
and the .cr file says that it moved on to the 2nd test... but look at that gain! ;-)
[1]
Type=4
Gain=3
Index=1.10120
D=-335755
H/G=96/8:12

Puzzle-Peter · 2013-01-18, 17:08

Quote:

Originally Posted by henryzz

It might be worth trying 2^73845+14717. You were unlucky with the smaller one that there was nowhere to backtrack to since it was the first iteration. Maybe that will be more lucky.

The problem is it might well do several iterations, followed by a lot of backtracking and finally give up. This might easily waste several CPU months, even years and I'm still debating with myself about taking the risk.

Quote:

Originally Posted by Batalov

...and Peter, you probably already cranked the factoring limits to the top (2^32), right?
_______________

P.S. I started an 8-thread test on 2^73845+14717 (no intent to finish!)
and the .cr file says that it moved on to the 2nd test... but look at that gain! ;-)
[1]
Type=4
Gain=3
Index=1.10120
D=-335755
H/G=96/8:12

2^32, yes.

Gain=3 woohoo ;-) I'll have to think about this. I'd love to do some real biggies but the risk of losing lots of time is considerable...

Batalov · 2013-01-18, 18:55

Actually, as I now look at the primo GUI window (I didn't have access to the terminal before, so I simply read the .CR file) -- the gain is not just 3 bits. The progress is show as "Test 2 | Bits 73784/73846", so I don't have a good grasp of the semantic of the "Gain" line. But of course the stalling scenario like you described would be impossible to predict just yet.

If it gets to say Test 10, I can forward you the package?

Another way in the old "Luhnization" routine would be to deliberately start from the very beginning many times in parallel, avoiding the paths already taken by other "threads".

Puzzle-Peter · 2013-01-18, 19:58

I kept a close eye on my primo runs and so far the "Gain=" value always equalled the bit difference from one test to the next. I have no idea what to think of your numbers.

OK I see you're trying every trick in the book to get me enticed. Right. You win. Take it to test 10 and I'll take over ;)

EDIT: What does the .cr file say now? There might have been a backtrack. First path gave a gain of 3 bits which means the next step will give up and backtrack rather early (backtracking is dependent from various factors, one of them being the gain that is sacrificed by going back one step), then a better Step1 with a larger gain was found.

2013-01-17, 22:48	#360
Batalov "Serge" Mar 2008 San Diego, Calif. 10100000011101₂ Posts	...and Peter, you probably already cranked the factoring limits to the top (2^32), right? _______________ P.S. I started an 8-thread test on 2^73845+14717 (no intent to finish!) and the .cr file says that it moved on to the 2nd test... but look at that gain! ;-) [1] Type=4 Gain=3 Index=1.10120 D=-335755 H/G=96/8:12 Last fiddled with by Batalov on 2013-01-18 at 09:17

2013-01-18, 19:58	#363
Puzzle-Peter Jun 2009 2²·5²·7 Posts	I kept a close eye on my primo runs and so far the "Gain=" value always equalled the bit difference from one test to the next. I have no idea what to think of your numbers. OK I see you're trying every trick in the book to get me enticed. Right. You win. Take it to test 10 and I'll take over ;) EDIT: What does the .cr file say now? There might have been a backtrack. First path gave a gain of 3 bits which means the next step will give up and backtrack rather early (backtracking is dependent from various factors, one of them being the gain that is sacrificed by going back one step), then a better Step1 with a larger gain was found. Last fiddled with by Puzzle-Peter on 2013-01-18 at 20:03

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
2^9092392+40291 is a probable prime!	engracio	Five or Bust - The Dual Sierpinski Problem	91	2023-03-06 21:22
generalized minimal (probable) primes	sweety439	sweety439	140	2022-12-20 07:08
probable largest prime.	sudaprime	Miscellaneous Math	11	2018-02-05 08:10
Hi, how can I test my probable prime number?	mohdosa	Information & Answers	22	2014-10-10 11:34
Record probable prime found!	philmoore	Five or Bust - The Dual Sierpinski Problem	18	2009-01-28 19:47

2012-12-16, 06:01	#353
Puzzle-Peter Jun 2009 1010111100₂ Posts	Hi Norman, thanks! It is the nature of records that they will be broken some day. Let's see who will take primo to the next level.

2012-12-17, 00:19	#354
philmoore "Phil" Sep 2002 Tracktown, U.S.A. 2141₈ Posts	Congratulations, Peter and Marcel! Thanks also to Norman, whose previous work helped Marcel update Primo to the current multi-core version. Only 18 more probable primes to certify to prove the dual Sierpinski conjecture as a theorem!

2013-01-16, 17:12	#355
Puzzle-Peter Jun 2009 2²·5²·7 Posts	I tried the next candidate, 2^73360+10711 but it wouldn't get past test1. It seems we reached the end of primo's useful range.

2013-01-16, 22:09	#356
henryzz Just call me Henry "David" Sep 2007 Liverpool (GMT/BST) 3·23·89 Posts	Might be worth waiting until http://mersenneforum.org/showthread.php?t=17554 is a viable option. The method needs to be checked and a program needs to be made public. If ecpp ran in O(x) then this runs in O(x^(3/4)). In other words a lot faster once overhead is insignificant.

2013-01-18, 18:55	#362
Batalov "Serge" Mar 2008 San Diego, Calif. 10269₁₀ Posts	Actually, as I now look at the primo GUI window (I didn't have access to the terminal before, so I simply read the .CR file) -- the gain is not just 3 bits. The progress is show as "Test 2 \| Bits 73784/73846", so I don't have a good grasp of the semantic of the "Gain" line. But of course the stalling scenario like you described would be impossible to predict just yet. If it gets to say Test 10, I can forward you the package? Another way in the old "Luhnization" routine would be to deliberately start from the very beginning many times in parallel, avoiding the paths already taken by other "threads".