Is this better? I did not remove k with found primes from pl_remain.txt, but the other post will have it in that form.

[QUOTE=Puzzle-Peter;253416]Hard to say. I sieved until it felt save to LLR n=25K to 100K which I divided across several cores. So there will be completed tests in the lower 30K region, lower 50K, lower 60K etc.

For k=36 I finished all tests below the prime to make sure it's the smallest. I'll do the same for k=26 in case I find one.[/QUOTE]

I see. I'll change the search limit to n=30K since that's its contiguously searched range at this point.

Here's a hint for dividing sieve files across multiple cores without running a server when you have fewer k's remaining than cores you are using to search them. I'll use 4 cores as an example here:

1. Paste the sieve file into a spreadsheet in column A.

2. Manually type the numbers "1", "2", "3", and "4" in the first 4 rows of column B and copy them the length of the file so that you have a 1,2,3,4,1,2,3,4,1,2,3,4,etc. repeating sequence all the way down.

3. Sort the file by column B primary and column A secondary. All "1"'s, "2"'s, etc. will now be together. This will work well for your effort. In some cases, though, since column A will be an alphanumeric sort (since there is a space in it), if your range crosses over a power of 10 such as from n=50K-150K, you would have to parse out the n-value into column C and use that as a secondary sort to get it to sort correctly. Fortunately that is not an issue for n=25K-100K.

4. Put all the lines with a "1" in them in core 1, lines with a "2" in core 2, etc. and start all cores at the same time.

5. When sending the results, you can either send all 4 files or combine them all and sort them by n-value primary and k-value secondary.

The machine will now search all cores at almost the exact same n-range. You can still go ahead and use the stop-on-prime option so that one core will stop when/if it finds a prime. You'll have to manually stop the other cores.

This works best when you have more k's than cores running them. Then you can divide it up by ranges of k so that the stop-on-prime stops searching a k on the applicable core that it should. But this is the best that you can (easily) do for a single k across multiple cores without a server (that I am aware of) to avoid a lot of unnecessary searching.


Gary

[QUOTE=rogue;253453]Is this better?[/QUOTE]

Barely.

First, I rejected 2 bases. You only included 1. Where is the other one?

Second, wouldn't it be easier to just include the pfgw.log file that the server writes out for the n=2K-25K primes? That's what Ian, Mathew, and others do when searching new bases with a server. It's also exactly what I save off when doing my own searches with a server. Doing an SQL database query to get the primes means that an unnecessary header name and dashes are included in the primes file. It also means that the file is sorted in random fashion with neither k's nor n's in proper order. The pfgw.log file has them in proper n-value order and is quick and easy to save off. I suppose I can live with the SQL primes query. I'll just sort it myself. At least it's a file directly from the server that obviously has not been manipulated in some fashion. That's what I'm mainly concerned about.

You just seem to be making this so very difficult.

R867
 

R867 tested n=25K-100K

6*867^61410-1 is prime

8^867^n-1 is now a 1ker with a weight of 836

Results emailed - Base released

[QUOTE=gd_barnes;253473]
Here's a hint for dividing sieve files across multiple cores without running a server when you have fewer k's remaining than cores you are using to search them. I'll use 4 cores as an example here:

[....]

[/QUOTE]

This is so easy that I have no idea why I didn't think about it myself.

Thanks!

[QUOTE=gd_barnes;253475]Barely.

First, I rejected 2 bases. You only included 1. Where is the other one?

Second, wouldn't it be easier to just include the pfgw.log file that the server writes out for the n=2K-25K primes? That's what Ian, Mathew, and others do when searching new bases with a server. It's also exactly what I save off when doing my own searches with a server. Doing an SQL database query to get the primes means that an unnecessary header name and dashes are included in the primes file. It also means that the file is sorted in random fashion with neither k's nor n's in proper order. The pfgw.log file has them in proper n-value order and is quick and easy to save off. I suppose I can live with the SQL primes query. I'll just sort it myself. At least it's a file directly from the server that obviously has not been manipulated in some fashion. That's what I'm mainly concerned about.

You just seem to be making this so very difficult.[/QUOTE]
A little clarification: the PRPnet server does [I]not[/I] produce a pfgw.log file. It does produce PRP.log, but that gives the primes in the order they were found (not necessarily n order) and in full PRPnet results format with username, email, etc. If Ian is producing a pfgw.log file from PRPnet, then he is first massaging his PRPnet data in some way or another to get it into that format. (As for Mathew...are you sure he's using a PRPnet server to start new bases? I run a private server for him, but we've only ever used that for continuing existing bases at n>25K.)

[QUOTE]If Ian is producing a pfgw.log file from PRPnet, then he is first massaging his PRPnet data in some way or another to get it into that format.[/QUOTE]

I have a VBScript that extracts the primes from the PRP.log file.

[QUOTE=mdettweiler;253525]A little clarification: the PRPnet server does [I]not[/I] produce a pfgw.log file. It does produce PRP.log, but that gives the primes in the order they were found (not necessarily n order) and in full PRPnet results format with username, email, etc. If Ian is producing a pfgw.log file from PRPnet, then he is first massaging his PRPnet data in some way or another to get it into that format. (As for Mathew...are you sure he's using a PRPnet server to start new bases? I run a private server for him, but we've only ever used that for continuing existing bases at n>25K.)[/QUOTE]

I was aware of the file name and what it writes out. I just typed the wrong name. Ian removes the extra information. I may have been mistaken on Mathew using servers to search new(er) bases. Regardless, I'd much rather get that file than an SQL query of primes in random order, especially for small-conjectured bases.

Shouldn't a server write out a "normal" primes file without all of the extra info? Both LLRnet and PRPnet have the same issue in that regard. Karsten's script writes out a "normal file" of primes on the client side but that's not very helpful if you're using multiple machines.

[QUOTE]Shouldn't a server write out a "normal" primes file without all of the extra info?[/QUOTE]I would think so. We are looking for primes. The rest of the stuff in there just makes it harder to read and work with. JMHO

[QUOTE=gd_barnes;253535]I was aware of the file name and what it writes out. I just typed the wrong name. Ian removes the extra information. I may have been mistaken on Mathew using servers to search new(er) bases. Regardless, I'd much rather get that file than an SQL query of primes in random order, especially for small-conjectured bases.

Shouldn't a server write out a "normal" primes file without all of the extra info? Both LLRnet and PRPnet have the same issue in that regard. Karsten's script writes out a "normal file" of primes on the client side but that's not very helpful if you're using multiple machines.[/QUOTE]
The tricky part is that a flat text file would generally have to be written out in the order that primes are found--i.e., somewhat random order. For a manual client, this is not a problem, because it processes a file sequentially; on a server, pairs are handed out sequentially, but different clients return results at different times, so sometimes (particularly at small n) primes can come in out of order.

I imagine it would be trivial to add support in prpserver for a second prime log file that just logs the actual primes, one per line. But the file would still have some primes out of order (unless n is large enough that the primes are far and few between and they never come in out of order).

[QUOTE=mdettweiler;253539]The tricky part is that a flat text file would generally have to be written out in the order that primes are found--i.e., somewhat random order. For a manual client, this is not a problem, because it processes a file sequentially; on a server, pairs are handed out sequentially, but different clients return results at different times, so sometimes (particularly at small n) primes can come in out of order.

I imagine it would be trivial to add support in prpserver for a second prime log file that just logs the actual primes, one per line. But the file would still have some primes out of order (unless n is large enough that the primes are far and few between and they never come in out of order).[/QUOTE]

I'm aware of that issue. Having a very small percentage of primes out of order would not be a problem. As a general rule, a majority of people only use servers for searching at higher n-ranges (n>25K) so they would be in order 99.9%+ of the time.