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.

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!

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.

Might be worth waiting until [URL]http://mersenneforum.org/showthread.php?t=17554[/URL] 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.

[QUOTE=Puzzle-Peter;324922]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.[/QUOTE]

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.

[QUOTE=philmoore;325046]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.[/QUOTE]

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.

[QUOTE=Puzzle-Peter;325064]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.[/QUOTE]
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.

...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! ;-)
[FONT=Arial Narrow][1][/FONT]
[FONT=Arial Narrow]Type=4[/FONT]
[FONT=Arial Narrow]Gain=3[/FONT]
[FONT=Arial Narrow]Index=1.10120[/FONT]
[FONT=Arial Narrow]D=-335755[/FONT]
[FONT=Arial Narrow]H/G=96/8:12[/FONT]

[QUOTE=henryzz;325065]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.[/QUOTE]

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=Batalov;325069]...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! ;-)
[FONT=Arial Narrow][1][/FONT]
[FONT=Arial Narrow]Type=4[/FONT]
[FONT=Arial Narrow]Gain=3[/FONT]
[FONT=Arial Narrow]Index=1.10120[/FONT]
[FONT=Arial Narrow]D=-335755[/FONT]
[FONT=Arial Narrow]H/G=96/8:12[/FONT][/QUOTE]

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...

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 [B]73784/73846[/B]", 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".

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.