[QUOTE=Thomas11;278720]

A few top performers tested to n=220k are:
[CODE]
S 12034494960083 66 170/212402
S 16196964114523 58 169/215818
[/QUOTE]

Thomas11, can you give me the instances of 169 and 170 here, my records show your 172 primes candidate 132395..... M(100) did not hit these levels until

169/172886
170/216664

The current top region of the Sierpinski record table is as follows:

160 101785 1061615018040269 S 106
161 114253 1061615018040269 S 106
162 124847 1323953181459703 S 100
163 129579 1323953181459703 S 100
164 138180 1323953181459703 S 100
165 139073 1323953181459703 S 100
166 141481 1323953181459703 S 100
167 146967 1323953181459703 S 100
168 158967 1323953181459703 S 100
169 172886 1323953181459703 S 100
170 212402 12034494960083 S 66
171 218813 1323953181459703 S 100
172 347004 1323953181459703 S 100

The S66 sequence (at 170/212402) has been tested up to n=230k without finding another prime. Perhaps I should give it another try, since there is a good chance to hit the 172nd prime a little lower than n=347k. But no. 171st must come first...

Kind regards,

Thomas

I have some good news to report.

:smile:

I have been experimenting with the code, and wrote an autonomous routine to modify the various "cutoff" values, and change them when a "justification" warrants it.

The tests I have been doing on R60 have shown that it is now finding the top performing K's up to 10 times faster!

The trick is not to use STATIC weights for the cutoffs, but to dynamically change them during the search. The idea is to not only maximize prime production but also to MINIMIZE the time to yield that production.

Some of the code will be unrecognizable, since I am basically hacking together stuff I do not yet fully understand. But I am good at conducting A.I. searches. I wrote a chess program when I was 19, and I also wrote a complex chess program that plays a game on 80 squares with two new piece types. You can see this "crazy game" here if you are interested:

[URL]http://www.gothicchess.com/images/mate_in_9_big.jpg[/URL]

Anyway, I will continue to try and tune the new "k-cutoff-search" criteria, and send a new copy of the program once I believe it is deemed worthy.

Stay tuned!

[QUOTE=Thomas11;204119]Challenged by that record I started an instance of payam.exe for E178 and just found the following:

[B]S 247058212228131 178[/B] 100/10000 K=1696112986951580714652684523878838207297744376085

which is a 1.6*10^48.[/QUOTE]

Got the record back for the Riesels...largest k value in a VPS

R 418867841188311 178 100/8791 K=approx 2.875*10^48

[QUOTE=robert44444uk;278854]Got the record back for the Riesels...largest k value in a VPS

R 418867841188311 178 100/8791 K=approx 2.875*10^48[/QUOTE]

How about this one:

S 1800486885279425 178 106/9342 K=approx 1.236*10^49

[QUOTE=SaneMur;278840]I have some good news to report.

:smile:

I have been experimenting with the code, and wrote an autonomous routine to modify the various "cutoff" values, and change them when a "justification" warrants it.

The tests I have been doing on R60 have shown that it is now finding the top performing K's up to 10 times faster!

The trick is not to use STATIC weights for the cutoffs, but to dynamically change them during the search. The idea is to not only maximize prime production but also to MINIMIZE the time to yield that production.

Some of the code will be unrecognizable, since I am basically hacking together stuff I do not yet fully understand. But I am good at conducting A.I. searches.

Anyway, I will continue to try and tune the new "k-cutoff-search" criteria, and send a new copy of the program once I believe it is deemed worthy.

Stay tuned![/QUOTE]

looking forward to it! Robert G wrote the software in such a way that he had some thinking in whether to carry an otherwise qualified candidate to the 10000 level. The smith_check forced another set of criteria in addition to that.

But a 10x pick up in time would be wonderful.

At present the software can handle 300,000 iterations - and no-one has really looked beyond 1,000 iterations at any level.

Trying to find the first Payam number at the E268 level, still struggling and I am on iteration 290 already. would've thought I would've found one by now but I am too busy to do the maths.

Regards

Robert

[QUOTE=robert44444uk;279092]looking forward to it! Robert G wrote the software in such a way that he had some thinking in whether to carry an otherwise qualified candidate to the 10000 level. The smith_check forced another set of criteria in addition to that.

But a 10x pick up in time would be wonderful.

[/QUOTE]

It starts out much slower, because I have no pre-conceived search cutoffs. That is, it is a wide-open-window, in alpha-beta search terms.

Next, it "prunes too much," as the average payam number speed/second goes through the roof. It is minimizing the time to produce a payam, but failing miserably in the "prime production maximization."

It attenuates back and forth, back and forth, narrowing down the best ranges, it then goes back to "research" the disastrous zone early on, and it finally will settle on what is believed to be a long-term, steady state solution. Eventually, no changes are made, and the payams/second remain high (over 1500/second even later on in the search) and the number of k's it finds is mind boggling.

I did one stupid thing: it writes out the record table only after an iteration completes, so I have a lot of waiting around. Also, it keeps the "file open" so I have to make a copy of it to see the results. I need to change that code.

I'll have a decent version for you to try in a little while. I am offloading my other projects from the serious hardware this weekend. This new program + the killer hardware should be an amazing combination.

Amazing. Can't wait!

[QUOTE=robert44444uk;279152]Amazing. Can't wait![/QUOTE]

Me too!

In the meantime I did a little modification to the existing code, so that it now reads an existing "recordtable.txt" file (but note: there is no check for different E levels).
The second modification is for updating the recordtable also in case that another (smaller) y is found for a given level. This check is necessary since the ks (or ys) are tested out of order.

To illustrate, here is how the Sierpinski recordtable for E=52 would look after just a few (micro-)iterations without the modification:
[CODE]1 1 1207544912007 S 52
2 2 41624159031 S 52
3 3 41624159031 S 52
4 4 2355970445035 S 52
5 5 1235918750557 S 52
[/CODE]

And after the modification:
[CODE]1 1 422543 S 52
2 2 4407727 S 52
3 3 143238991 S 52
4 4 210898517 S 52
5 5 2937428043 S 52[/CODE]

Please find the modified source code attached. Unfortunately I'm unable to provide a Windows binary (I'm running only Linux machines here).

Hi all - I only run Windoze so can't use Thomas11's invention. I think it would be fun to collect the top 30 or top 100 at each p level and for each E level - records are getting harder and harder to beat! That would require a rewrite of the recordtable routine in the main program.

How are things going Sanemur with your software?

Some absolute records I got this week:

47 245 73807093031125 R 52
48 251 73807093031125 R 52
51 287 73807093031125 R 52

And a Riesel record:

50 284 73807093031125 R 52

Still have not found the elusive first E268 Riesel k. I am up to iteration 477 now.

[QUOTE=robert44444uk;279675]Hi all - I only run Windoze so can't use Thomas11's invention.[/QUOTE]

I was able to compile it on a Windows machine. However it was much more complicated than expected: Since there is no GMP library for Windows, I had to replace it by MPIR. And the Visual Studio compiler seems to be a little more restrictive than the GCC compiler.

At least it works at my end, but I have no clue if it will work on other machines too. So, please try it (attached below) and give me some feedback (regarding missing dependencies and the like...).