Software/instructions/questions
This thread is for software downloads and instructions as well as a forum for any related questions on how to run software related to the effort.
Here is a link to all of the latest software that should be needed: [URL]http://www.rieselprime.de/dl/CRUS_pack.zip[/URL]. The programs are LLR, PFGW, srsieve, sr1sieve, sr2sieve, and a PFGW starting bases script. First an important note for more experienced prime searchers. This first post will be relatively elementary. For the specific sequence of what to run for different efforts here, see the second post. This will be detailed instructions on running each program. Preliminaries: I would suggest creating a separate directory for most of the programs except Srfile. The Sr(n)sieve series of sieving programs have a tendency to use some of the same generic file names and you don't want one sieve overlaying a prior one. Srfile could be copied into each of the 3 directories of the Sr(n)sieve programs. It is used to manipulate files of different types, remove factors from sieved files, and other misc. tasks. Program instructions: LLR  This is a prime finding or PRP (probable prime) finding program. It is the primary one that we will use for finding primes for n > ~3K5K. If the base is a power of 2, (bases 4 and 16 for this effort), it difinitively finds a prime. If not, it only finds probable primes that must be proven by PFGW. To run it, double click it, choose 'Test Input', key in your sieved file name, the name of the file that you would like it to write programs to, and line 1, and press OK. Primes will be in the file you specified and it will write an 'lresults.txt' file that show details about the search. PFGW  This is an outstanding general purpose program that can trial factor, find PRP's (probable primes), and do deterministic tests. It should be used at all times for testing bases that are not a power of 2 and is far faster than anything else for testing. It is also the best program to use when starting a new base because scripts can be written for it to do very specific things such as stop serching k's when a prime is found. You'll want to read the pfgwdoc.txt instructions in the download. It will talk about all of the parameters for the program. To open the program, double click the WinPFGW.exe icon. You'll want to change 'Output Verbose Screen' option to 'Super quiet' or the program will slow down slightly from displaying much info. on the screen. There are two different efforts it will be used for. Commands for each: (1) When proving +1 PRP's found by LLR, use the following command: "PFGW (input file with extension) f0 t l". f0 will cause it to do no initial factoring, t will force it to prove the PRP's prime, and l will cause it to write a more detailed results file. If you have a lot of primes you're proving, just see if the # of lines in the pfgwprime.log file equal the number of primes in yor input. If so, they were all prime. (2) When starting a new base, run PFGW version 3.4.0 or later using the [URL="http://www.noprimeleftbehind.net/crus/newbases4.3.txt"]newbases4.3[/URL] script as an input file. Then use the following command to run it: "(script name) f100 l". f100 will cause it do to a 'normal amount' of initial factoring. See above for l. Regarding the script file, there are very simple instructions in the script. There are only 5 lines that need to be changed for each base. srsieve: This is an allpurpose sieving program that is used as a 'set up' for sr1sieve and sr2sieve as well as sieving very large #'s of k's more quickly than anything else. It also is very effective at sieving starting from n=1 because it does not erroneously remove low nvalues that would make the equation prime. First you need to create an input file of actual equations such as 7*30^n+1, 9*30^n+1, etc., one per line. Then go to the command prompt and use the equations file as input with a command like "srsieve a n 25e3 N 100e3 P 1e9 m 4e9 (input file). a is the type of output file (ABCD filetype in this case) n is the low nvalue of your range, N is the high of the range, P is how far to search (1 billion in this case), and m tells it to not display factors on the screen less than 4G. (Unfortunately you can't set it higher than that but in this case you're not going higher so it keeps it moving by not displaying info. on the screen. sr1sieve: This is the best program to use to sieve one candidate and is far faster than anything else for that purpose. You do need to use srsieve to sieve up to at least the value of k or the base first but I think the creator recommends something greater than P=1G. When running srsieve first, be sure and use the g paramater to create the correctly formatted sieved file. I personally sieve to P=250M or 500M and then let sr1sieve have at it. To run sr1sieve, go to the command prompt and try something like "sr1sieve P 500e6 i (input file) o (output file). See the instructions for additional details. sr2sieve: This one is a little tricky but it is by far the fastest for multik sieving anywhere from 3 k's and up. I will just tell you the steps and not how to do them: (1) Use srsieve to sieve up to about P=1G. Force it to create an 'ABCD' output file using the a paramater. (2) Run sr2sieve using the file in (1) as input. You'll need to specify a P= paramater that tells it how far to sieve. It knows by a value in the input file where pvalue to start at. The command might be something like "sr2sieve P 500e9 i (ABCDinput file). Sr2sieve will not remove primesearch candidates, it will only write factors into a file called factors.txt so one more step is needed. (3) Run srfile with the commnd "srfile G k factors.txt (ABCDinput file from #1). This will cause it to remove all factors found by #2 and write out a file sorted by n that LLR and PFGW can do primality tests on. You're now ready to do primality tests on it. Any questions...just ask. There is a lot of info. in the various README and other help and doc files for the programs, especially for the sr(n)sieve programs. Gary 
Guidelines on doing searches
Below are the suggested guidelines for doing a primesearch effort for the conjectures. All instructions here are the fastest known ways that I am aware of but some of you may not want to take extra steps for speed.
Sieving: 1. If you are sieving more than one k for n > 2500: a. Run srsieve with the a parameter up to P=100M. b. Run sr2sieve up to an appropriate value. c. Run srfile with the G (sorted by n) or g (sorted by k) parameter to remove factors and create input for LLR or PFGW. 2. If you are sieving 1 or 2 k's for n > 2500: a. Run srsieve with the g paramater up to P=100M. b. Run 1 or 2 instances of sr1sieve up to an appropriate value (1 instance for each k). 3. If you are searching any # of k's for n <= 2500, no sieving is needed. A PFGW script using trial factoring is by far the fastest way to go. If you are testing a new base or a new krange for a previously searched base, see important notes about starting a new base below. Primality testing: 1. For bases that are powers of 2: a. Run LLR with the sieve file as input and a file name of prime.txt as output. b. Two files will be created: prime.txt and lresults.txt. Check for and post any primes found and send me the results file. 2. For bases that are not powers of 2: a. Run PFGW with the sieve file as input using the f0 and l switches in order to do PRP tests on the entire range of n. 2 or 3 files will be created: Primes will be in pfgwprime.log, probable primes (PRP's) will be in pfgw.log, and the results will be in pfgw.out. IMPORTANT: If you have to stop PFGW in the middle of testing, it will not remember k's that it has found primes for and will begin searching them again when you restart. See instructions in the next post under #2 (referencing running LLR) for running srfile to remove k's with primes before restarting. b. Run PFGW to prove primality of the pfgw.log output from a. using the f0 switch and (t switch for the Sierp side OR tp switch for the Riesel side). Once all have been proven, as with LLR, please post primes found and send me the results file. [See important notes below if starting a new krange or starting a new base. You'll need to use the PFGW script for new bases as instead of a sieve file as input to PFGW.] Below are IMPORTANT notes on starting from scratch on a NEW BASE. Even with the automated script, if you're new to CRUS, I'd suggest getting with me or one of our regular searchers first. Some of the exceptions can get quite tricky. 1. As shown in the 1st post here, please use the link to the script for starting new bases as input to PFGW. 2. Review the web pages for algebraic factors such as squared k's on Riesels or cubed k's on Riesels and Sierpinski's for removal at the end of the search. Worse than searching for a multiple of the base that might be a duplicate effort would be to search a k that was proven composite for all n without realizing it ahead of time. 3. If you have to stop PFGW in the middle of the search and have to restart it, it will not remember where it left off (because it is running a script). A change to the min_k in the script will be needed before restarting. 4. Please send me the pl_MOB, pl_prime, and pl_remain output files from the new bases script. A results file is not necessary. Also, if it is an even Sierp base, please send me the pl_GFN file. If any of the files would be too large, let me know. For largeconjectured bases such as 3, 7, and 15, I will probably suggest just sending primes for n>1000 while running primes up to n=1000 myself because the files are too large to send around. For ultimate proof in the mathematical world, we'll need a central repository of the primes found for each k. I'll post an Email later on to send them to. Good luck and may the primesearching God's be with us all! :smile: Gary 
Additional info. on searches
Here are some more particulars on the searches now:
 1  If starting a new base, if you're not using the deterministic parameters of t or tp for PFGW (meaning that it is proving all primes as it goes), then it will write out two separate files. They are called pfgw.log and pfgwprime.log. pfgw.log is the PRP's (probable primes) and pfgwprime.log is the proven primes. Even if the deterministic parameters are not set on, PFGW can still prove small primes because with the f100 paramater set on, it automatically attempts factoring up to a certain limit, depending on the size of the number being searched. There is an important difference between these two files: You still need to prove the primes in the pfgw.log file so after running the new base, do the following to prove the PRP's that are in the pfgw.log file prime: 1. Rename the pfgw.log files and pfgw.out files to something of your choosing. pfgw.out is the results file. I like to call them 'primesierpbase16.txt' and 'resultssierpbase16.txt' for Base 16 Sierp so I know exactly what they are if I look at them 6 months from now. 2. For Sierpinski PRP's, run PFGW again using the f0, t, and l parameters with your renamed pfgw.log file from #1 as input to it and that has the PRP's in it. The command is "PFGW (file name from #1) f0 t l". For Riesel PRP's, just change the t parameter to tp. This primality proving step is the same thing you need to do if you are running LLR for bases other than 4 or 16 or if you're running PFGW on any search without the t or tp parameters originally. Clearly, you can avoid all of this hassle of proving primes by using PFGW with the t or tp and the f0 parameters set on for ALL searches in this effort. But your searches will be slower. To me, the extra hoops to do this is worth saving the extra CPU cycles. But more importantly to me, it helped me learn the process of what the software programs do.  2  When running LLR to search for primes, there is no way to make it stop searching k's when primes are found like PFGW can. Once again like in #1, you can choose to run PFGW for all of your searches. This may be more palatable for some people. The script that I showed in the the first post of this thread contains the parameter to make PFGW stop searching a k when a prime is found for it. If you choose to run LLR, you will probably want to manually eliminate k's from your sieved file from time to time to avoid a lot of duplicate testing. For those of you haven't used the srfile software, this is where it comes in very handy. Srfile will eliminate specific sequences (k's) from a sieved file. What you'll need to do is copy your sieved file into the same directory as your srfile software. Then go to the command prompt and for each k where a prime was found, type the following command: srfile G d "1234*56^n+1" sieveinput.txt o sieveoutput.txt". Obviously the form is the k and base that you want to delete. It will now remove all n's for the particular k that you specified. Now do the same thing for each k that you want to remove but be sure and use the sieveoutput.txt as input for the 2nd run with sieveoutput2.txt as output, etc. You'll then need to stop LLR, copy in your new sieved file, determine what line is in the new file to start it at, key that line into the LLR menu and continue seaching where you left off. Because of the hassle involved with this, it is highly recommended that PFGW be used for all bases that are not powers of 2. For bases that are powers of 2, the CPU time savings is likely worth the added hassle of having to occassionaly manually remove k's from time to time. In a nutshell for general prime searching after doing your sieving or on an already sieved file, you can choose to run LLR or PFGW for any base but below is the fastest currently known methods for doing so: For minimum hassle on all bases and the fastest for bases that are NOT a power of 2: 1. Change the first line of the sieved file, i.e. the "XXXXXXXX:1:P:24:257" line to "ABC $a*24^$b+1 // {number_primes,$a,1}". Do not change the $a and $b variables. The only thing that will vary will be the base (24 in this case) and obviously the plus sign will change to a minus if searching Riesel's. In effect, your sieved file will 'contain' your script for input to PFGW at the beginning of it. 2. Run PFGW with the f0, t (Sierp) or tp (Riesel), and l paramaters at the command line. IMPORTANT NOTE: The l is a small case L, not a big case (eye). I can't remember if these are casespecific for PFGW but they are for the sr(n)sieve series of programs. That is it. The pfgwprime.log file will contain primes and the pfgw.out file will be your results file. For a little more hassle on all bases but the fastest for bases that ARE powers of 2: 1. Run LLR with your sieved file as input. No changes to the file or special parameters are needed. 2. Every few hours/days/primes, check the output for primes. If there's 35 of them or more (can vary, if at a high n, I'd to it for every prime, if many around n=5K than maybe 1015) stop LLR and run your sieve file through srfile to eliminate k's where primes have been found. Keep in mind that the primes file may have more than one prime for a k. 3. Restart LLR with the sieved file that has the eliminated k's. IMPORTANT...be sure and change the input line #. Otherwise it will start LLRing much later in the file and you'll miss searching many candidates. 4. Repeat #2 and #3 as many times as needed until LLR is done. 5. If running a base that is not a power of 2, use the output PRP (probable primes) file as input to PFGW to do the proof (determinstic) test with the t or tp parameters as in step #2 for PFGW above. There you have it...two ways to do most of the searches for this effort. Gary 
[quote=gd_barnes;120751]This thread is for software downloads and instructions as well as a forum for any related questions on how to run software related to the effort.
Here is a link to all of the latest software that should be needed: [URL]http://gbarnes017.googlepages.com/conjectureprogs.zip[/URL]. The programs are LLR, NewPGen, PFGW, Sr1sieve, Sr2sieve, Srfile, and Srsieve. ...[/quote] I noticed that the LLR version included in the archive is a little oldit's 3.7.0, whereas the newest version is 3.7.1c, available [URL="http://www.mersenne.org/gimps/llr371c.zip"]here[/URL] for Windows and [URL="http://www.mersenne.org/gimps/llr371clinux.zip"]here[/URL] for Linux. There weren't any major changes, at least for the types of numbers we're working with, between 3.7.1b and 3.7.1c, so if anyone's still using 3.7.1b, they don't have to upgrade (i.e. it's not like they'll get a speed bonus by doing so). However, I don't know if there were any differences in speed between 3.7.0 and 3.7.1b, so to play it safe I'd go with 3.7.1b or later. I'm glad you included NewPGen in the archive, though, as for quite a while the download link on the Prime Pages web site has been broken. I got my copy from another forum member attached to a message. :smile: Everything else in the archive seems up to date, though. :tu: You might want to make a version of the archive for Linux, also. I'd be glad to put it together for you if you want (I've already got the latest versions of most of the programs listed in there downloaded). The only one I'd be missing would be NewPGen, for which the Linux download link is broken too. (The zip file appears to download OK, but then when you try to open it it turns out to be not a zip filemaybe it was an HTML error page saved as the zip file by accident.) If anyone has a Linux copy of NewPGen sitting around, please PM me and I'll give you my email address so you can send it to me. 
[quote=Anonymous;120879]I noticed that the LLR version included in the archive is a little oldit's 3.7.0, whereas the newest version is 3.7.1c, available [URL="http://www.mersenne.org/gimps/llr371c.zip"]here[/URL] for Windows and [URL="http://www.mersenne.org/gimps/llr371clinux.zip"]here[/URL] for Linux. There weren't any major changes, at least for the types of numbers we're working with, between 3.7.1b and 3.7.1c, so if anyone's still using 3.7.1b, they don't have to upgrade (i.e. it's not like they'll get a speed bonus by doing so). However, I don't know if there were any differences in speed between 3.7.0 and 3.7.1b, so to play it safe I'd go with 3.7.1b or later.
I'm glad you included NewPGen in the archive, though, as for quite a while the download link on the Prime Pages web site has been broken. I got my copy from another forum member attached to a message. :smile: Everything else in the archive seems up to date, though. :tu: You might want to make a version of the archive for Linux, also. I'd be glad to put it together for you if you want (I've already got the latest versions of most of the programs listed in there downloaded). The only one I'd be missing would be NewPGen, for which the Linux download link is broken too. (The zip file appears to download OK, but then when you try to open it it turns out to be not a zip filemaybe it was an HTML error page saved as the zip file by accident.) If anyone has a Linux copy of NewPGen sitting around, please PM me and I'll give you my email address so you can send it to me.[/quote] Oops, my bad on LLR. I downloaded all new versions of everything and put them on most of my machines before posting but I thought I had the latest version of LLR already and didn't check for a new one. Thanks for catching that! So if anyone reads this, use Anon's version of LLR instead of the one I included in the link at the top of this thread. That would be great if you could put up link(s) to the Linux versions of the programs. I'm not familiar with Linux and so had completely forgotten there are two different versions of everything. Thanks! Gary 
AFAIK, there has been no speed improvement to LLR (re: base 2) since 3.6. So it doesn't really matter if you don't have the latestandgreatest version.

[quote=axn1;120893]AFAIK, there has been no speed improvement to LLR (re: base 2) since 3.6. So it doesn't really matter if you don't have the latestandgreatest version.[/quote]
I didn't know for sure, I just figured I'd play it safe. Thanks for letting us know, though. :smile: 
[quote=gd_barnes;120892]...
That would be great if you could put up link(s) to the Linux versions of the programs. I'm not familiar with Linux and so had completely forgotten there are two different versions of everything. ... [/quote] I have everything I need to put it together into an archive right now, except for NewPGen. I've already got the Windows version of NewPGen (I'm on a dualboot system, XP and Ubuntu, though I'm using Ubuntu mostly now) [URL="http://www.mersenneforum.org/showpost.php?p=119396&postcount=20"]thanks to axn1[/URL], but I still don't have the Linux version yet. Anyone out there got it? Please PM me and I'll send you my email so you can mail it to me. (Or, even better, just zip it upor, if you rather, make it into a tarball [the Unix/Linux equivalent of a .zip file for those who don't know]and attach it to a post here so anyone can grab it.) :smile: Edit: I forgot to mention that I don't have PFGW either. Does anyone know where to get it? 
You are unable to download the linux version from [URL="http://primes.utm.edu/programs/NewPGen/"]here[/URL]? Then post here, and I'll repeat the procedure :)
You can download PFGW from primeform yahoo group, but first you must join up (easy to do if you have a yahoo mail id). The you can download the Windows or linux version from the "Files" section there. [URL="http://tech.groups.yahoo.com/group/primeform/"]The group[/URL] 
[quote=axn1;120903]You are unable to download the linux version from [URL="http://primes.utm.edu/programs/NewPGen/"]here[/URL]? Then post here, and I'll repeat the procedure :)[/quote]
Oh, I guess it worked this time. :smile: The link must have been fixed since I last checked. I should have checked again before saying that it was still down. :blush: [quote]You can download PFGW from primeform yahoo group, but first you must join up (easy to do if you have a yahoo mail id). The you can download the Windows or linux version from the "Files" section there. [URL="http://tech.groups.yahoo.com/group/primeform/"]The group[/URL][/quote]I don't have a Yahoo account, maybe it would be easier for someone to simply email me their copy (if it's not too much of a bother)? Edit: I wonder why one of the higher ranked members of that group doesn't just use the free Geocities web space that comes with every Yahoo account (if they're part of the group, they obviously already have one) and post it there so that people don't have to join the group to get the program? 
I have updated the zipped file of software at the top of this thread to include the latest Window's version of LLR.
It appears there was no change between version 3.7.0 that I had and version and 3.7.1b that I just now downloaded, which is why I thought I already had the latest version. The date was the same, the size was the same, and it still says version 3.7.0 in the program help. But the llrguide and readme files now show version 3.7.1. Jean or anyone, can you let me know that [URL="http://pagespersoorange.fr/jean.penne/index2.html"]this link[/URL] under category "LLR Version 3.7.1b for MS Windows" is the correct place to get the latest Windows version of LLR? Thanks, Gary 
link
try this link: [url]http://jpenne.free.fr/[/url]
there is a LLR version 3.7.1.c from Dec.11, 2007 (the version is also displayed in the about menu of LLR) karsten 
Can someone who has a copy of the Linux version of pfgw please email it to me? (Or, if you don't have it but wouldn't mind, could someone with a yahoo account that's subscribed to the Primeform group download the Linux version of pfgw, then email it to me?) I'm going to need it to put together the Linux version of the Conjectures 'R Us allinone software pack that I said I was going to make.
My email address is: [IMG]http://bugmesticky.googlepages.com/email.gif[/IMG] (it's all crossed out like that to keep the spambots out, it's should still be human readable though, sort of like a CAPTCHA (did I get the acronym right?)) (After I've been mailed the program I'll ask Gary to use his new modpowers and zap the email address from my post. :smile:) 
Gary, would it be possible that you add a 'news' section to your webpages?

[quote=michaf;121332]Gary, would it be possible that you add a 'news' section to your webpages?[/quote]
I agree, that would be a good idea. 
News page...some input needed
[quote=michaf;121332]Gary, would it be possible that you add a 'news' section to your webpages?[/quote]
I agree, that's probably needed but it's a very general request. I'd like to get a little more input. Do you or others think a separate web page is needed for news? Could it be a separate thread here in the forum instead? It would be quicker for me to update news in a post here than to update the web pages. More questions: What has been most common way to show news and what do people feel like is the kind of news to show? One thing I can think of is my talk about the team drive on Sierp base 16, which is right now in the sieving thread, and that I'm now sieving. That's probably a good starting point for a news page or thread. One note here. I'm going to move some posts around into the correct threads and consolidate the 'how to' instructions here tonight. I will let everyone know if about any posts that I move. I am also going to create a separate thread for primes found and move the post for tcadigan's prime on Sierp Base 16 into it. The 'primes needed' thread is k's where we still need a prime so there's no clear place to report a prime found at the moment. I probably should have called the 'primes needed' thread as 'searches needed'. I'll see if I can change it. Thanks, Gary 
[quote=kar_bon;121253]try this link: [URL]http://jpenne.free.fr/[/URL]
there is a LLR version 3.7.1.c from Dec.11, 2007 (the version is also displayed in the about menu of LLR) karsten[/quote] Thanks Karsten! I'll get the newer version copied into my link tonight. Gary 
[quote=gd_barnes;121372]I agree, that's probably needed but it's a very general request. I'd like to get a little more input. Do you or others think a separate web page is needed for news? Could it be a separate thread here in the forum instead? It would be quicker for me to update news in a post here than to update the web pages.
More questions: What has been most common way to show news and what do people feel like is the kind of news to show? One thing I can think of is my talk about the team drive on Sierp base 16, which is right now in the sieving thread, and that I'm now sieving. That's probably a good starting point for a news page or thread. ... [/quote] I agree, probably a thread in the forum would be the best place for news, for now at leastsince the project does all of its actual work from this forum, this is already the goto place for the Conjectures 'R Us project. 
LLR version 3.7.1c now in link
Newest LLR version 3.7.1c has now been uploaded into the link at the beginning of this thread.

I second this, though a 'the last 10 changes to this file are'section on the webpages would be nice too.
[QUOTE=Anonymous;121376]I agree, probably a thread in the forum would be the best place for news, for now at leastsince the project does all of its actual work from this forum, this is already the goto place for the Conjectures 'R Us project.[/QUOTE] 
Future site updates
[quote=michaf;121390]I second this, though a 'the last 10 changes to this file are'section on the webpages would be nice too.[/quote]
OK, that sounds reasonable. Of course I'll only show substantial changes such as adding sieved files, splitting out bases that are powers of 2, etc. and not insignificant ones where someone just reserves something or we find a prime and eliminate a k...unless it proves a conjecture. Tasks to do in upcoming days after XMAS: 1. Add a scroll bar that allows the titles to be locked on. 2. Add links for sieved files. I'll do this for all of the k's on base 16. Sieving has now passed P=200G on all remaining k's. Any not reserved after sieving is completed will be combined into a team drive (minus a few k's left open for individual efforts). 3. Add a 'last 10 changes' page and combine it with a 'news' section. After seeing the idea for a changes page, I think it makes sense to have 2 sections on the page; one for news and one for changes. I don't want to get into a lot of duplicate maintenance on both the forums and the pages but I think that would be minimal for news. 4. Just added to my list this morning: Separate the Riesel and Sierp reservation page into one separate page each for Riesel and Sierp and add a new column to each for posting sieved files. Of course for Sierp base 16, I'll add the column to that page. This makes more sense then trying to post sieved files on the main info. pages or squeeze them into the current reservation page, which would clutter both greatly. Gary 
hello, i use the llrnet server / client on a home network ... but i have from time to time some errors ...
it's when i work on k*16^n+1, it happen only on some n value [QUOTE]Bit: 60/112983, ERROR: SUM(INPUTS) != SUM(OUTPUTS), 63104943475044 != 63104943475044.01 Possible hardware failure, consult the readme file. Continuing from last save file. Bit: 120/112983, ERROR: SUM(INPUTS) != SUM(OUTPUTS), 17036091150400 != 17036091150399.96 Possible hardware failure, consult the readme file. Continuing from last save file. Disregard last error. Result is reproducible and thus not a hardware problem. Bit: 121/112983, ERROR: SUM(INPUTS) != SUM(OUTPUTS), 510503793337561 != 510503793337561 Possible hardware failure, consult the readme file. Continuing from last save file. Bit: 120/112983, ERROR: SUM(INPUTS) != SUM(OUTPUTS), 17036091150400 != 17036091150399.96 Possible hardware failure, consult the readme file. Continuing from last save file. Disregard last error. Result is reproducible and thus not a hardware problem. Bit: 121/112983, ERROR: SUM(INPUTS) != SUM(OUTPUTS), 510503793337561 != 510503793337561 Possible hardware failure, consult the readme file. Continuing from last save file. Bit: 120/112983, ERROR: SUM(INPUTS) != SUM(OUTPUTS), 17036091150400 != 17036091150399.96 Possible hardware failure, consult the readme file. Continuing from last save file. Disregard last error. Result is reproducible and thus not a hardware problem. Bit: 121/112983, ERROR: SUM(INPUTS) != SUM(OUTPUTS), 510503793337561 != 510503793337561 Possible hardware failure, consult the readme file. Continuing from last save file. Bit: 120/112983, ERROR: SUM(INPUTS) != SUM(OUTPUTS), 17036091150400 != 17036091150399.96 Possible hardware failure, consult the readme file. Continuing from last save file. Disregard last error. Result is reproducible and thus not a hardware problem. Bit: 121/112983, ERROR: SUM(INPUTS) != SUM(OUTPUTS), 510503793337561 != 510503793337561 Possible hardware failure, consult the readme file. Continuing from last save file. Bit: 120/112983, ERROR: SUM(INPUTS) != SUM(OUTPUTS), 17036091150400 != 17036091150399.96 Possible hardware failure, consult the readme file. Continuing from last save file. Disregard last error. Result is reproducible and thus not a hardware problem. Bit: 121/112983, ERROR: SUM(INPUTS) != SUM(OUTPUTS), 510503793337561 != 510503793337561 Possible hardware failure, consult the readme file. Continuing from last save file. Bit: 120/112983, ERROR: SUM(INPUTS) != SUM(OUTPUTS), 17036091150400 != 17036091150399.96 Possible hardware failure, consult the readme file. Continuing from last save file. Disregard last error. Result is reproducible and thus not a hardware problem. Bit: 121/112983, ERROR: SUM(INPUTS) != SUM(OUTPUTS), 510503793337561 != 510503793337561 Possible hardware failure, consult the readme file. Continuing from last save file.[/QUOTE] it happen on different computer (athlon x2 with win2k and intel centrino duo with winxp) but not on the athlon 2500+ ... what's wrong ? i guess something with the sse2 instruction ... the only bypass found at the moment is "remove the k/n pair from the bad computer and throw it to the athlon 2500+" 
double post (too late to edit)
i found a solution: using "llrnet nosse2" no more warning and overall speed increased by 10% 
Site change status
Update on the site changes:
#'s 2 and 4 to add sieved files to the pages and separate the Riesel and Sierp reservations are complete. #'s 1 and 3 to add a scroll bar to lock the titles on and to add a news/last 10 changes page will be looked at after New Year's. I'll add a #5: Add 2 pages (one each for Riesel & Sierp) to allow for searches for k's that are multiples of the base (kMOb) but that yield a different prime than k/b. In conjunction with that, I'll need to come up with a new color scheme for the proof of the conjectures. Right now, when it's proven without accounting for kMOb, I just show it as gray. But in the future, there will have to be 2 indicators, one for 'fully proven' including kMOb and one for 'mostly proven' that doesn't include kMOb. It will be up to the math community to determine which one is considered the proof. I did a quick search on Riesel base 4 up to n=10K to check all kMOb that Jean Penne had previously done. I confirmed that he is correct. When accouting for kMOb, k=19464 is the only k that is added to our list of k's without a prime that yields a different prime than k/b. He said that he is searching that now. I will slowly search bases as I have time for kMOb and see about how many there are that will ultimately yield a different prime than k/b but that are still without a prime. We know there are Generalized Fermat #'s (GFn's) such as 22*22^n+1 & 441*22^n+1 that a prime most likely cannot be found on but most should not be any more difficult than k's that are not MOb. Gary 
Good news for this project! Jean Penne has updated LLR so that it can automatically stop running if a prime is founduseful if you're only running one k by itself in a conjecture search. Here's his post, copied and pasted from the Software forum:
[quote=Jean Penne]Hi All, Thanks to George Woltman, the two distributions of LLR 3.7.1c on the GIMPS site : [URL]http://www.mersenne.org/gimps/[/URL] and on my personal pages : [URL]http://jpenne.free.fr/index2.html[/URL] are now matching exactly. It is now possible to force the program to stop when a prime is found, by using the option : StopOnSuccess=1 in the .ini file. Happy new year! Jean[/quote] 
I'm wondering, if I wanted to do some sieving for one of the oddn/evenn conjectures, would I need to punch in anything special to srsieve? Would I need to remove all even or odd n's manually?
Or, would I simply need to sieve in base 4? (i.e. for an oddn search, sieve the base 2 k, times 2, in base 4; or, for an evenn search, just sieve the exact same k in base 4.) Am I correct? :smile: 
[quote=Anonymous;124180]I'm wondering, if I wanted to do some sieving for one of the oddn/evenn conjectures, would I need to punch in anything special to srsieve? Would I need to remove all even or odd n's manually?
Or, would I simply need to sieve in base 4? (i.e. for an oddn search, sieve the base 2 k, times 2, in base 4; or, for an evenn search, just sieve the exact same k in base 4.) Am I correct? :smile:[/quote] That is correct. Of course you could do it either way but if you run base 4, you wouldn't have to manually remove some of the n's and your sieving would run somewhat faster. Here's a couple of examples for everyone: If running k=6927 for Riesel base2 oddn, you can sieve k=6927*2=13854 for Riesel base 4. If running k=(any) for Riesel base2 evenn, you can run the same k for Riesel base 4. Gary 
Can someone tell me what is the easiest way to delete a k from a abcd file:
I tried d and k niether seemed to work, so I just opened the abcd file & did the k manually. then used srfile G k factor.txt (file name) to make a new file for testing, then manually deleted all n up to point of last prime found. I know there is a better way:confused: 
[QUOTE=grobie;131906]Can someone tell me what is the easiest way to delete a k from a abcd file:
I tried d and k niether seemed to work, so I just opened the abcd file & did the k manually. then used srfile G k factor.txt (file name) to make a new file for testing, then manually deleted all n up to point of last prime found. I know there is a better way:confused:[/QUOTE] to delete a sequence of a abcdfile try: [code] srfile a d"405*2^n1" sr_2.abcd [/code] this deletes from the abcdfile the sequnce for k=405 and writes the result in the same abcdfile! 
[QUOTE=kar_bon;131907]to delete a sequence of a abcdfile try:
[code] srfile a d"405*2^n1" sr_2.abcd [/code] this deletes from the abcdfile the sequnce for k=405 and writes the result in the same abcdfile![/QUOTE] OK, thanks Is there any way to delete the same k in my prp testing file without generating a new one up to n=prime 
[QUOTE=grobie;131909]OK, thanks
Is there any way to delete the same k in my prp testing file without generating a new one up to n=prime[/QUOTE] not with srfile only, but try this:  create from your prpfile for every sequence the npgfile: srfile g mine.prp for every k there is a file like "t17_b2_k405.npg" (here k=405) delete per hand the n's in this file you don't need for this k and save it  call this: copy *.npg >all sort all >all1  edit file 'all1' and delete all headers (like "5000000000000:M:1:2:258") except one (copy it at the top of the file)  call than: srfile G all1 and you have your PRPfile without the n's from that k in! another way could be a script but this works fine too! 
[QUOTE=kar_bon;131910]not with srfile only, but try this:
 create from your prpfile for every sequence the npgfile: srfile g mine.prp for every k there is a file like "t17_b2_k405.npg" (here k=405) delete per hand the n's in this file you don't need for this k and save it  call this: copy *.npg >all sort all >all1  edit file 'all1' and delete all headers (like "5000000000000:M:1:2:258") except one (copy it at the top of the file)  call than: srfile G all1 and you have your PRPfile without the n's from that k in! another way could be a script but this works fine too![/QUOTE] Great, Thanks Kar_bon for your help 
Notes:
The version of PFGW in the 1st post here is well out of date. [URL="http://www.mersenneforum.org/showpost.php?p=183154&postcount=1"]Here[/URL] is a link to a post that contains links to the latest versions of PFGW. The versions of LLR and sr(n)sieve are likely well out of date also. If anyone can provide a "care package" of links that contains all/most of the recent versions of the programs that I have in the link in the 1st post here, I'll update that link. NewPGen should not be necessary since we don't use it. Edit: The 1st post now has all of the latest programs. Gary 
[URL]http://sites.google.com/site/timsorberassite/Home/CRUSpackage.zip?attredirects=0&d=1[/URL]
I included the newest versions of everything except NewPGen. 
Thanks a bunch Tim. I have included your link in the 1st post here. I have also removed all references to NewPGen in the 1st two posts here. NewPGen should not be used for anything at CRUS or NPLB.

Isn't it true that LLR is faster for powerof2 bases and PFGW is faster for other bases? The third post makes it sound like LLR is significantly faster than PFGW for all bases. Besides, it's a lot of hassle to remove k's with primes from LLR, something PFGW can do automatically. (Perhaps you just haven't 'modernized' that post yet to consider PFGW's improvement.)
[quote=gd_barnes;120821]3. Restart LLR with the sieved file that has the eliminated k's. IMPORTANT...be sure and change the input line #. Otherwise it will start LLRing much later in the file and you'll miss searching many candidates.[/quote] I think it's easier to remove all lines before the one you're supposed to run next, then just set the line number to 1. Less room for error, too. :smile: [quote=gd_barnes;120821]2. Change the first line of the sieved file, i.e. the "XXXXXXXX:1:P:24:257" line to "ABC $b*24^$a+1 // {number_primes,$a,1}". Do not change the $b and $a variables.[/quote] Shouldn't that be "$a*24^$b+1"? I'm pretty sure the other way around would take the k as the n and vice versa and stop processing the n when a prime is found for it (or just not work at all). 
[quote=MiniGeek;196162]Isn't it true that LLR is faster for powerof2 bases and PFGW is faster for other bases? The third post makes it sound like LLR is significantly faster than PFGW for all bases. Besides, it's a lot of hassle to remove k's with primes from LLR, something PFGW can do automatically. (Perhaps you just haven't 'modernized' that post yet to consider PFGW's improvement.)
I think it's easier to remove all lines before the one you're supposed to run next, then just set the line number to 1. Less room for error, too. :smile: Shouldn't that be "$a*24^$b+1"? I'm pretty sure the other way around would take the k as the n and vice versa and stop processing the n when a prime is found for it (or just not work at all).[/quote] I only updated the 1st two posts here. I was not intending the update the 3rd post but I'll go ahead and do that after I get back from a business trip. The $a, $b does appear that I goofed originally there. I'll correct that now. To avoid confusion, I put an editors note at the beginning of the 3rd post stating that it is now out of date. Thanks for checking everything closely Tim. It's surprising how difficult it is to keep everything up to date at all times for two projects. 
My recommendation for starting new bases is that you should use the PFGW script only up to 100 or 200. Take the k without primes and run them through srsieve. Sieve from where to stopped to n=1000. You just need to sieve to a few million. This will eliminate a large number of tests very quickly. Create the PFGW input file with srfile. At every hundred or so stop PFGW then use srfile to remove bases which have a prime. You will then need to edit the output from srfile to drop low n and restart PFGW. For Sierpinski base 58, this saved many hours. I estimated that the time it would have taken was about 10 hours to go to n=1000 had I used the script to go that far. Using this method, I shaved off about 90% of that time and got to n=1000 in about an hour. Granted it takes more manual effort, but it saves a lot of time in the long run.

[QUOTE=rogue;196695]My recommendation for starting new bases is that you should use the PFGW script only up to 100 or 200. Take the k without primes and run them through srsieve. Sieve from where to stopped to n=1000. You just need to sieve to a few million. This will eliminate a large number of tests very quickly. Create the PFGW input file with srfile. At every hundred or so stop PFGW then use srfile to remove bases which have a prime. You will then need to edit the output from srfile to drop low n and restart PFGW. For Sierpinski base 58, this saved many hours. I estimated that the time it would have taken was about 10 hours to go to n=1000 had I used the script to go that far. Using this method, I shaved off about 90% of that time and got to n=1000 in about an hour. Granted it takes more manual effort, but it saves a lot of time in the long run.[/QUOTE]
I concur and raise you one! make srsieve give output in ABC format and add [B]// {number_primes,$a,1}[/B] to the end of the first line. That way PFGW will skip k's for you and there is no need for srfile until you exit and restart PFGW. Willem. ABC $a*36^$b1 // {number_primes,$a,1} 
IMHO, that is too much manual effort. I just stick some PFGW scripts on a core or 2 for a few hours or a day or two up to n=1000 or n=2500 and let it hack away until done. Usually there are only a few 100 k's or perhaps a 1000 or 2000 k's remaining. At that point, there should be only a few k's that are multiples of the base or that have algebraic factors that would allow them to be removed, which is what generally takes the time to figure.
With what you are suggesting, you have 1000's or 10000's (or more) k's remaining at n=100 or some other low limit. You're then forced to create a huge equations file for srsieve and continue manually removing them for the several times that you sieve. I suppose it depends on if the ratio of the following is very high: The number of cores that you have divided by the amount of personal time that you have. (lol; funny but true) In the case described by Mark, he's saying that it would have taken 10 CPU hours to run the script to n=1000 vs. 1 CPU hour to do what he did, which I'm assuming probably involved at least an hour of his personal time vs. 510 mins. to create the PFGW sripts correctly. Personally I'd choose the 10 CPU hours every time if it took an hour or more of my personal time. Now...if you're talking 10 CPU days vs. 1 CPU day, that's a different story but for most bases, it doesn't take nearly that long to PFGW with scripts to n=1000. (I actually go to n=2500 on most bases because I don't want to mess with testing any more multiples of the base than I have to or creating huge equations files of k's remaining for srsieve.) So it's really a matter of magnitude. In most cases, PFGWing without sieving to n=1000 or n=2500 doesn't take more than 1 or 2 CPU days so that would be my choice. That's just my two cents anyway...:smile: BTW, I'll do some more updating on posts 2 and 3 here late this week or early next week. Someone please "bump" me if I forget. Gary 
[QUOTE=gd_barnes;120755]
3. When reviewing and reporting the k's remaining, eliminate multiples of the base where k1 is composite (Riesel side) or where k+1 is composite (Sierp side). This effectively avoids running duplicate searches.[/QUOTE] Could you explain the math behind this statement? I presume that one can derive a factorization of k*b^n+/1 under these conditions, but I'm not seeing it right now. 
[quote=rogue;197799]Could you explain the math behind this statement? I presume that one can derive a factorization of k*b^n+/1 under these conditions, but I'm not seeing it right now.[/quote]
(I just worked this myself, so some of the work and/or logic might not be right, but it sounds right to me, and comes to a conclusion that agrees with Gary's result) For every k that is a multiple of the base (say the xth multiple), xb*b^nÂ±1 = x*b^(n+1)Â±1 The reason is simple, but here it is worked out any way: [code]k=xb xb*b^n1= x*b*b^n1 We know that a^b*a^c=a^(b+c), so: x*b^1*b^n1= x*b^(n+1)1[/code]So for every multiple of a base, there is a onetoone mapping to a smaller k. Now the question is: where does the primality of k1 come in? There is indeed a onetoone mapping as previously established, (which might suggest that if one has primes, so does the other) but we only consider nâ‰¥1, so x*b^11=xb*b^01 is ignored for determining if xb is a Riesel/Sierp number. Keep in mind that b^0=1, so xb*b^01=xb1=k1. If xb1 is composite, then xb and x (as k's) will fall into the same category of being or not being Riesel/Sierp numbers, and we can ignore xb and continue working on the smaller x. If it is prime, then x is eliminated at n=1, but xb still remains, so they might not fall into the same category of not being Riesel/Sierp numbers, so we need to check if xb is a Riesel/Sierp number. For some examples of how this works out see: (105=15*7, x=7, b=15, and k1=104 is composite) [URL="http://factordb.com/search.php?query=105*15%5En1"]105*15^n1[/URL] [URL="http://factordb.com/search.php?query=7*15%5En1"]7*15^n1[/URL] Note that 105*15^01=7*15^11=104, 104 is composite so k=7 might be a Riesel number, and that 105*15^n1=7*15^(n+1)1, so every n from 105*15^11=7*15^21 up is a simple onetoone and so if one has a prime, so will the other, so we only have to check one of the two. We decide to check k=7 and ignore k=105 because 7 is smaller. (30=15*2, x=2, b=15, and k+1=31 is prime) [URL="http://factordb.com/search.php?query=30*15%5En%2B1"]30*15^n+1[/URL] [URL="http://factordb.com/search.php?query=2*15%5En%2B1"]2*15^n+1[/URL] Note that 30*15^0+1=2*15^1+1=31, 31 is prime so k=2 is not a Sierp number, but 30 might still be a Sierp number, so we only have to check k=30 for primes. So in the end, we should eliminate k's where k is a multiple of the base and k1 is composite (Riesel side) or k+1 is composite (Sierp side), just like Gary said. That was much easier than I thought it'd be. :smile: 
[QUOTE=MiniGeek;197819]So for every multiple of a base, there is a onetoone mapping to a smaller k.
Now the question is: where does the primality of k1 come in? There is indeed a onetoone mapping as previously established, (which might suggest that if one has primes, so does the other) but we only consider nâ‰¥1, so x*b^11=xb*b^01 is ignored for determining if xb is a Riesel/Sierp number. Keep in mind that b^0=1, so xb*b^01=xb1=k1. If xb1 is composite, then xb and x (as k's) will fall into the same category of being or not being Riesel/Sierp numbers, and we can ignore xb and continue working on the smaller x. If it is prime, then x is eliminated at n=1, but xb still remains, so they might not fall into the same category of not being Riesel/Sierp numbers, so we need to check if xb is a Riesel/Sierp number. For some examples of how this works out see: (105=15*7, x=7, b=15, and k1=104 is composite) [URL="http://factordb.com/search.php?query=105*15%5En1"]105*15^n1[/URL] [URL="http://factordb.com/search.php?query=7*15%5En1"]7*15^n1[/URL] Note that 105*15^01=7*15^11=104, 104 is composite so k=7 might be a Riesel number, and that 105*15^n1=7*15^(n+1)1, so every n from 105*15^11=7*15^21 up is a simple onetoone and so if one has a prime, so will the other, so we only have to check one of the two. We decide to check k=7 and ignore k=105 because 7 is smaller. (30=15*2, x=2, b=15, and k+1=31 is prime) [URL="http://factordb.com/search.php?query=30*15%5En%2B1"]30*15^n+1[/URL] [URL="http://factordb.com/search.php?query=2*15%5En%2B1"]2*15^n+1[/URL] Note that 30*15^0+1=2*15^1+1=31, 31 is prime so k=2 is not a Sierp number, but 30 might still be a Sierp number, so we only have to check k=30 for primes.[/QUOTE] Barring the confusion of some of your phrases, I'm curious about something. Where in the definition of the conjecture does it say that n could be 0 if k is a multiple of b? It can't be 0 for any other k. Why the exception? AFAIAC the above logic is confusing because the exception isn't clearly noted. With the exception I would simply state (in code) that n can start at 0 if k is a multiple of b. The rest of the code handles itself. 
[quote=rogue;197830]Barring the confusion of some of your phrases, I'm curious about something. Where in the definition of the conjecture does it say that n could be 0 if k is a multiple of b? It can't be 0 for any other k. Why the exception?[/quote]
It can't. Sorry for writing in a way that made you think that. We don't consider n=0 to be part of the set of numbers considered in determining if k is a Riesel/Sierp number, whether it's a multiple of the base or not. I was just pointing out that n=1 on x is n=0 on xb (which means this specific number is ignored for k=xb; and also pointing out that k=xb*b^01=x*b^11=k1). Sorry for any confusion that caused. [quote=rogue;197830]AFAIAC the above logic is confusing because the exception isn't clearly noted. With the exception I would simply state (in code) that n can start at 0 if k is a multiple of b. The rest of the code handles itself.[/quote] Sorry for confusing you on this point, but no that's not how it works. That would make xb be exactly the same as x. (except you'd be calling the numbers by a slightly different name) To (hopefully) clarify: k=x and k=xb are the same, except that the n's are offset from each other by 1, and k=x n=1 is k=xb n=0 (the latter of which is ignored, for purposes of Riesel/Sierp number candidacy, like any other n=0). Every number xb*b^n1 with nâ‰¥1 is contained within x*b^n1 with nâ‰¥1. x*b^11 is not within xb*b^n1 with nâ‰¥1 (as it's at n=0). Therefore x*b^11 (which is also xb*b^01, xb1, and k1 when k=xb) is integral to the relationship of x and xb and which one should be tested for further primes. (for a visual example of this, look at the first few numbers for the examples I gave and see that e.g. every 105*15^n1 number is on 7*15^n1, but k=7 has 104 as one of the values while k=105 does not) If x*b^11, (which is also k1 when k=xb, which is where we get the k1 notation) is composite, then k=x and k=xb still remain as possible Riesel numbers. Since from this point on there is no significant difference between the two, we choose to ignore the larger one, k=xb (the same work will be done with k=x). i.e. we remove k's that are multiple of the base when k1 is composite. If x*b^11 is prime, then k=x is eliminated as a Riesel candidate, but k=xb still needs to be checked (although k1 is of the form xb*b^n1, it is with n=0 so we don't consider it as a prime that eliminates xb as a Riesel number). i.e. we keep k's that are multiple of the base when k1 is prime. 
[QUOTE=MiniGeek;197836]If x*b^11, (which is also k1 when k=xb, which is where we get the k1 notation) is composite, then k=x and k=xb still remain as possible Riesel numbers. Since from this point on there is no significant difference between the two, we choose to ignore the larger one, k=xb (the same work will be done with k=x).
i.e. we remove k's that are multiple of the base when k1 is composite. If x*b^11 is prime, then k=x is eliminated as a Riesel candidate, but k=xb still needs to be checked (although k1 is of the form xb*b^n1, it is with n=0 so we don't consider it as a prime that eliminates xb as a Riesel number). i.e. we keep k's that are multiple of the base when k1 is prime.[/QUOTE] The fog has cleared, finally. I think that Gary needs to state this in clear mathematical language in the sticky. 
Using the Riesel side as an example, tell me if this is clear enough:
1. n must be >= 1 for all k. 2. If k*b^n1 where n=1 is prime than k*b (i.e. MOB) will need a different prime because this prime would be kb*b^01. 3. If k*b^n1 where n>1 is prime than k*b will have the same prime (in a slightly different form), i.e. kb*b^(n1)1. 4. Assume that k*b^11 is prime. k*b^11 = kb1. 5. Conclusion: Per #2 and #4 the only time k*b needs a different prime than k is when kb1 is prime. (kb+1 for Sierp) If you have a clearer mathematical way of stating it, I'm all ears. The key is orienting it towards people of highly varying mathematical skills. Therefore I just explained what needed to be eliminated and not why for the layman. One more thing: Willem and I independently of one another came to this same conclusion. Although I stated it here first, I think he concluded it before I did. Before we came up with this (likely almost a year into the project), it was a real hassle coming up with which k's that were MOB that needed to be tested. Gary 
[QUOTE=gd_barnes;197887]Using the Riesel side as an example, tell me if this is clear enough:
1. n must be >= 1 for all k. 2. If k*b^n1 where n=1 is prime than k*b (i.e. MOB) will need a different prime because this prime would be kb*b^01. 3. If k*b^n1 where n>1 is prime than k*b will have the same prime (in a slightly different form), i.e. kb*b^(n1)1. 4. Assume that k*b^11 is prime. k*b^11 = kb1. 5. Conclusion: Per #2 and #4 the only time k*b needs a different prime than k is when kb1 is prime. (kb+1 for Sierp) If you have a clearer mathematical way of stating it, I'm all ears. The key is orienting it towards people of highly varying mathematical skills. Therefore I just explained what needed to be eliminated and not why for the layman. One more thing: Willem and I independently of one another came to this same conclusion. Although I stated it here first, I think he concluded it before I did. Before we came up with this (likely almost a year into the project), it was a real hassle coming up with which k's that were MOB that needed to be tested.[/QUOTE] Let's say k=xb and xb1 is composite. Let's say that x=yb and yb1 is composite. If yb^21 is prime, we can use it to satisfy the conjecture for x, but not for k. Since x was not tested, we still don't have an n for k. Does that make sense? I'm saying that if k = x*b^m and all x*b^j1 are composite for j<m, then we need to verify that the prime for x is when n>m. I'm not thinking of any examples off the top of my head, but I presume they exist. 
[quote=rogue;197904]Let's say k=xb and xb1 is composite. Let's say that x=yb and yb1 is composite. If yb^21 is prime, we can use it to satisfy the conjecture for x, but not for k. Since x was not tested, we still don't have an n for k.
Does that make sense? I'm saying that if k = x*b^m and all x*b^j1 are composite for j<m, then we need to verify that the prime for x is when n>m. I'm not thinking of any examples off the top of my head, but I presume they exist.[/quote] No, not really. I don't understand what you are getting at. On the Riesel side is that if k=x and x*b^11 (i.e xb1 or kb1) is prime, you have to search k=x*b. if x*b^11 is composite, then you do NOT have to search k=x*b. It says nothing about any other k values such as k=x*b^2, k=x*b^3, etc. I suppose you could take it further and say that if x*b^11 is composite and x*b^21 is prime, you don't have to search k=x*b but you DO have to search k=x*b^2 but that's iterative and confusing IMHO. It's easier to just check to see if k=x*b has a prime at n=1. If so, then k=x*b^2 must be searched. If not, then it doesn't need to be searched. Perhaps that is what you are alluding to? Put most easily on the Riesel side, if k=x and x1 is prime, you must search k=x*b. If x1 is composite, you don't need to search k=x*b. But in neither case can you draw any conclusion about whether you must search k=x*b^2, k=x*b^3, etc. I would suggest doing some actual tests on this to convince yourself of the fact. After I concluded it mathematically, I had to convince myself with real world examples. Gary 
I'll have to think this one through.

I don't think it really matters.
(using k=xb and x=yb) If k1 is composite, then k is skipped and x will be considered separately, including a MoB check to see if it needs to be run. If k1 is prime, then x has been eliminated at n=1, and k must be run. This says nothing about y, which will be considered (probably already was, as it's quite a bit smaller than k) as a separate value. 
After much thinking and effort, I have now modified the first 3 posts in this thread to reflect more modern udpates as a result of the improvements in PFGW and the new bases script.
There has been a lot of confusion on new bases and sieving on this project over its first 2 years. I hope the new bases script along with modification to these postings will clear a lot of that up. Gary 
I think that it would be useful to have a script (perl, etc.) that could take a pfgw.log file and remove PRPs from pl_remain.txt and candidates from an input file for PFGW in one fell swoop. This would be very useful for bases with higher k to help keep these files in sync as one goes deeper with them. It is very time consuming (with the manual method I am using) to do this.
If anyone has an easy way of doing this, I would like to hear about it. I wouldn't be surprised if I have made a mistake with my manual edits. Fortunately I could rebuild pl_remain.txt if I needed to as I have keep the other files from the script and the pfgw.log file. 
The Perl script I posted in the first post of [URL]http://www.mersenneforum.org/showthread.php?t=12845[/URL] can do just that for ABCD (by default, it's easily switchable since it goes through srfile) files, through srfile. It doesn't handle the pl_remain.txt file, but I'd think it'd be fairly easy to make a script based on it that does (or, rather, to modify this script to do it in addition to removing it from the sieve file with srfile). (based on this general idea: for each line in the prime file, get the k and look through pl_remain.txt for it, then remove that line from pl_remain.txt)
I'll see about doing that... 
[quote=MiniGeek;202635]The Perl script I posted in the first post of [URL]http://www.mersenneforum.org/showthread.php?t=12845[/URL] can do just that for ABCD (by default, it's easily switchable since it goes through srfile) files, through srfile. It doesn't handle the pl_remain.txt file, but I'd think it'd be fairly easy to make a script based on it that does (or, rather, to modify this script to do it in addition to removing it from the sieve file with srfile). (based on this general idea: for each line in the prime file, get the k and look through pl_remain.txt for it, then remove that line from pl_remain.txt)
I'll see about doing that...[/quote] I figured it out, using cygwin tools on Windows (should be practically identical on Linux). Add this after the srfile line:[code] system("grep v \"@linearray[0]\" pl_remain.txt > temp.txt"); system("sed '1d' temp.txt > pl_remain.txt"); system("del temp.txt"); [/code]Here's what they do: the grep line prints all lines not matching the match string, which is the k, and saves it to temp.txt, but it adds a line saying "File pl_remain.txt:" to the beginning, so... the sed line removes the first line from temp.txt and prints it to pl_remain.txt and, of course, the del cleans up by deleting the temp file. I've tested this briefly. It appears to work. [URL]http://ss64.com/bash/grep.html[/URL] lists a h/nofilename command exists as a "GNU extension", (the cygwin version of grep doesn't support it) so maybe a Linux user could use something like this instead of those other 3 lines:[code] system("grep hv \"@linearray[0]\" pl_remain.txt > temp.txt"); system("del pl_remain.txt"); system("ren temp.txt pl_remain.txt");[/code](with del and ren replaced with appropriate Linux equivalents; or maybe there's a more elegant way to write to a file you're reading from...) I'll post it in the scripts thread too. 
I'm confused as to why this is needed. If you use the stoponprime option in PFGW or use the new bases script, you should never have any more primes than just the lowest one for each k. There should be no reason to remove any primes.
If it is composite PRPs you are referring to, the newest version of the new bases script handles that by writing them to a separate file and continuing to search the k until a "real" prime is found. If it's composite PRPs for higher nvalues, i.e. when you wouldn't be using the new bases script, those are so rare that I've never encountered one. I've never seen a composite PRP for an exponent n>1000; on this project anyway. I strongly recommend against manual editing of files for more than one prime on a k; if that is what you are referring to...much too errorprone. 
[QUOTE=gd_barnes;202660]I'm confused as to why this is needed. If you use the stoponprime option in PFGW or use the new bases script, you should never have any more primes than just the lowest one for each k. There should be no reason to remove any primes.
If it is composite PRPs you are referring to, the newest version of the new bases script handles that by writing them to a separate file and continuing to search the k until a "real" prime is found. If it's composite PRPs for higher nvalues, i.e. when you wouldn't be using the new bases script, those are so rare that I've never encountered one. I've never seen a composite PRP for an exponent n>1000; on this project anyway. I strongly recommend against manual editing of files for more than one prime on a k; if that is what you are referring to...much too errorprone.[/QUOTE] I don't know which item you are referring to, but what happens to me is that sometimes I need to shutdown PFGW during a run. If I use PFGW the number_primes option and primes were found, then when I restart, it will not ignore the k for which a prime was already found. 
It removes k's that have PRPs/primes from sieve files and pl_remain.txt files.
It's not useful when only using the PFGW script to start a base. It is useful for running PFGW with the stoponprime when PFGW must stop for some reason (and so forget which k's to skip), as rogue said. It's also useful for continuing new bases past what you did with the new bases script. 
Oh, I see. Here is what I do when I have to restart PFGW: Put the previous primes at the top of the sieve file and remove pairs previously tested. That way, it quickly finds them prime and doesn't search the k's anymore. I think Ian and/or Kenneth came up with that idea, which I thought was excellent thinking.
Then it's just a matter of quickly deleting the few duped primes and results from pfgw.log and pfgw.out when the run is done. It's quick and is virtually error free because the duped primes/results are all right in a row and quick to spot. 
[QUOTE=gd_barnes;202754]Oh, I see. Here is what I do when I have to restart PFGW: Put the previous primes at the top of the sieve file and remove pairs previously tested. That way, it quickly finds them prime and doesn't search the k's anymore. I think Ian and/or Kenneth came up with that idea, which I thought was excellent thinking.
Then it's just a matter of quickly deleting the few duped primes and results from pfgw.log and pfgw.out when the run is done. It's quick and is virtually error free because the duped primes/results are all right in a row and quick to spot.[/QUOTE] I hadn't thought of that, but it would certainly work. 
Mark,
I see there is an ongoing discussion that you are involved in in the scripts thread. I initially got a little confused as to what was going on there so I stayed out of it. I think I have it figured out now. I think Tim is coming up with a Perl program that removes k's from the pl_remain.txt file for primes found on subsequent searches above the starting new base script. Personally what I do is plug the file into an Excel spreadsheet into column A, plug in the primes in column B, and then use formulas out to the right to parse out the kvalue from each. I then am able to use the k's remaining as a vertical lookup table to see which k's are in the table that contain primes. I then end up with a column that has the k's with primes blanked out. I resort the column with blanked out k's and end up with the k's remaining. That said, although accurate, the above is kind of clunky because it requires manually copying or deleting formulas based on how many k's remaining and manually executing an Excel sort. Having something completely automated like what Tim is working on is pretty cool. Gary 
[quote=gd_barnes;202781]I initially got a little confused as to what was going on there so I stayed out of it. I think I have it figured out now. I think Tim is coming up with a Perl program that removes k's from the pl_remain.txt file for primes found on subsequent searches above the starting new base script.
... That said, although accurate, the above is kind of clunky because it requires manually copying or deleting formulas based on how many k's remaining and manually executing an Excel sort. Having something completely automated like what Tim is working on is pretty cool. Gary[/quote] Yep. It also removes those same k's from your sieve file. (though you can easily comment out one or the other parts, to make it just remove from one of the files) You make it sound like it's still theoretical, but it seems to be working fine to me. I used it for my latest base 3 work and it looks like it's doing it all right. Try it out and tell me if you notice anything wrong. :smile: rogue said he "had problems with my newest script", but I'm not sure what they are (or if he meant the false positive k matching I fixed shortly afterward). Here's the newest version of it, all together (instead of an earlier release and then a oneline "patch"): [URL]http://www.mersenneforum.org/showthread.php?p=202785#post202785[/URL] Note that it uses egrep, which I got from cygwin. It's extremely fast for small files, (eliminating 575 k's from a 1 MB sieve file with 70000 candidates takes a couple of minutes on my PC; anything else is usually done within a couple seconds) and only prints a few status lines. It's also almost completely automated. It just needs to know the file names of your prime file and sieve file (it assumes the remaining k's file is pl_remain.txt). It'd be good if it could decide what to do based on what files you give it instead of assuming it'll have those two files (without modifying the script). Maybe for version 3.2. :smile: 
[quote=MiniGeek;202788]Yep. It also removes those same k's from your sieve file. (though you can easily comment out one or the other parts, to make it just remove from one of the files)
You make it sound like it's still theoretical, but it seems to be working fine to me. I used it for my latest base 3 work and it looks like it's doing it all right. Try it out and tell me if you notice anything wrong. :smile: rogue said he "had problems with my newest script", but I'm not sure what they are (or if he meant the false positive k matching I fixed shortly afterward). Here's the newest version of it, all together (instead of an earlier release and then a oneline "patch"): [URL]http://www.mersenneforum.org/showthread.php?p=202785#post202785[/URL] Note that it uses egrep, which I got from cygwin. It's extremely fast for small files, (eliminating 575 k's from a 1 MB sieve file with 70000 candidates takes a couple of minutes on my PC; anything else is usually done within a couple seconds) and only prints a few status lines. It's also almost completely automated. It just needs to know the file names of your prime file and sieve file (it assumes the remaining k's file is pl_remain.txt). It'd be good if it could decide what to do based on what files you give it instead of assuming it'll have those two files (without modifying the script). Maybe for version 3.2. :smile:[/quote] Oops, I hate it when miscommunication happens. :smile: I couldn't comment on your Perl program because I haven't even looked at it. What I meant was MY process of removing k's from the pl_remain file using Excel is klunky. (Actually, I think klunky is an understatement!) See my references in my last para. to adding/deleting formulas and an Excel sort. I'm pretty sure your Perl program beats that all to heck, especially if you've gotten it to work for huge #'s of k's on base 3. :) I'll give it a whirl in the near future. Gary 
[QUOTE=gd_barnes;202754]Oh, I see. Here is what I do when I have to restart PFGW: Put the previous primes at the top of the sieve file and remove pairs previously tested. That way, it quickly finds them prime and doesn't search the k's anymore. I think Ian and/or Kenneth came up with that idea, which I thought was excellent thinking.
Then it's just a matter of quickly deleting the few duped primes and results from pfgw.log and pfgw.out when the run is done. It's quick and is virtually error free because the duped primes/results are all right in a row and quick to spot.[/QUOTE] If it was my idea, I has purely forgotten it, even though it has quite a resemblance towards my "making of k's remaining list", but anyway it came in handy, since my dad blew one of the fuses today, so a lot of work could have been lost on the Sierp Base 63 conjecture :smile: Thanks again for saving me a bunch of time redoing millions of test or finding duplicate primes. Regards KEP 
Is there an easy(!) way to calculate the optimum size of range to sieve to have a 0.x probability of finding the last remaining k*b^n+1 (of weight w) for a certain conjecture?
(Sieved to optimum depth.) 
[quote=Flatlander;219424]Is there an easy(!) way to calculate the optimum size of range to sieve to have a 0.x probability of finding the last remaining k*b^n+1 (of weight w) for a certain conjecture?
(Sieved to optimum depth.)[/quote] There is no easy way although I can do it with a hard way. :) See below. This is a great question that I have thought of in the past but had not pursued. There is no way that I know of just based on weight since weight is not always 100% correlated to candidates remaining after sieving to higher depths. But it can be done based on # of candidates remaining. Here is what I would do: 1. Sieve some monsterous range that you are sure will have AT LEAST your 0.x probably of a prime to something nominal such at P=1G. (Probably a ratio of minimum n to maximum n of 10 should be sufficient.) 2. Set a running cumulative nonchance of prime to 1; we'll call this N. (To be explained more below.) 3. Repeat the following 4 steps until your chance of prime (we'll call it C) is > than your 0.x probability of finding a prime. a. Plug an n=100K range into the odds of prime spreadsheet and make a note of the chance of prime. So with the 1st go around, if sieving n=100K to 2M, plug in the applicable info. for the # of candidates for n=100K200K. For the nvalue, use a little less than the average of the range; let's say n=140K. For the 2nd go around, do the same for n=200K300K and use n=240K for the nvalue, etc. b. Subtract the chance of prime in the spreadsheet from 1. We'll call this P. It is your chance of NOT finding a prime for this particular range. c. Multiply N by P giving N. This is your cumulative chance of there NOT being a prime. With the first go around, since N=1 before doing the multiplication, N will just be equal to P after the multiplication. d. Subtract N from 1 and call it C. (Don't change the value of N.) C is your chance of prime to this point. If C > your 0.x probability of a prime, then you are done. This was done quickly so if Tim or some other stats guys who are familiar with the odds of prime spreadsheet would like to check it, I'd welcome that. IMPORTANT: Don't try to simplify this by adding up the expected # of primes for each range. As an example, if your expected # of primes is 1.00, then you actually only have about a 6263% chance of finding a prime. Some people make the fallacy of assuming that since the expected # of primes is 0.6, then there is a 60% chance of prime. That is incorrect. It can be easily demonstrated in the 1.00 expected primes example. That is: There is no way that there is a 100% chance of prime just because there should be an average expected 1.00 primes. If the expected is 1 primes, the chance is actually (I believe) the Golden Ratio, which is the ratio of consecutive large Fibonacci numbers, i.e. 0.620.63 somewhere. This also applies to betting at just about anything. In roulette, on an Americal wheel, there are 38 numbers. If you pick any 1 of those numbers at random on a "fair" wheel, there is a 6263% chance that the # will hit at least once in the next 38 spins. Gary 
lol.
Well I think I followed [I]most [/I]of that. Sounds to me that it can be automated by adding more columns to the odds of prime spreadsheet and working left to right filling in the data until C> 0.x is flagged in a cell.(?) Worth doing? As doubling a sieve size increases the time taken by sqr(2), (iirc) I'm assuming there is a bestbangsforbucks sweet spot that would clear some of the 1kleft conjectures in the shortest possible time by aiming for a certain 0.x probability. (I hope that is understandable. I have real difficulty in 'keeping more than one plate spinning' in my head at the same time. It's frustrating to find this stuff so enjoyable but so hard at the same time. :jail: ) 
I'm making a program that calls srsieve then examines the output to give the probabilities of finding a prime by a certain n; as per my question above.
I am using the formulae from your spreadsheet and notice that there is the constant 1.781 in C10. Where does this come from and do I need more significant figures? You recommend sieving to 1G. Will I lose accuracy by choosing 100M to get a quicker result? [QUOTE=gd_barnes;219430] For the nvalue, use a little less than the average of the range; let's say n=140K.[/QUOTE] Why 'a little less'? 
[quote=Flatlander;219670]I'm making a program that calls srsieve then examines the output to give the probabilities of finding a prime by a certain n; as per my question above.
I am using the formulae from your spreadsheet and notice that there is the constant 1.781 in C10. Where does this come from and do I need more significant figures? You recommend sieving to 1G. Will I lose accuracy by choosing 100M to get a quicker result? Why 'a little less'?[/quote] AXN came up with the 1.781 constant back about 3 years ago in an RPS thread. Although most are my own, I incorporated a couple of his formulas in the spreadsheet that were over my head to calculate. Yes, you'll lose a little bit of accuracy with a lower sieve but not a lot. P=1G is pretty fast for one k. You might test the difference. Think about your 2nd question mathematically. Hint: The chance of prime at each nlevel does not drop in a linear fashion. Actually, as n approaches infinity, the % of each nrange that you should use for the "average n" (call it A) would converge on 50, i.e. the true average of the nrange. Technically, the Avalue of 40 that I gave was a very rough estimate. 2 examples at the extremes demonstrate this: Let's say you were doing n=1K1M. The true average is of course near n=500K but A would probably be close to 30, which would mean that you need to use n=300K. For n=10M11M, A would be very near 50 (likely 4547 somewhere), which means you would use n=10.5M. The pattern that holds is: If max n / min n divided by the average size of n (call that R) is extremely high as in the former example, than A is very low, possibly as low as 30. If R is extremely low as in the latter example, than A converges on as high as it can be: 50; that is the true average of the nrange. Actually, I believe it is very possible that the lowest value of A might be the log of 2 base 10, which is .30103. So if max n/min n was very large and the average n was very small, then A would be near 30.103. But I would have to test that to be sure. That is only educated speculation. I could calculate exact figures across many ranges but it would be tedious and have to be done by trial and error because I don't know enough highlevel math to utilize calculus to do it. You would have to take it down to nranges that are 1/100th or 1/1000th of your total nrange and add them all together. I only suggest dividing up your sieve ranges into 10, 20, or 30. What would be more accurate for an n=100K2M range that you might need to sieve would be to use n=135K for the n=100K200K range, n=238K for the n=200K300K range, n=340K for the n=300K400K range, etc. with the nrange being used gradually converging on 50% of the actual nrange being tested so that it is something like n=1.948M for n=1.9M2M. But I have no way to know if those are completely accurate. I chose 40% or n=140K (for n=100K200K) because that is likely to be a reasonably close average over the entire very large nrange that you'd need to sieve just to get a 6070% chance of prime. BTW, one final example: Max and I tested Sierp base 9 from n=360K800K after I sieved n=360K1M. I remembered commenting to Max, after using the exact method that I showed you to use here that we only had a 2025% chance of prime for the entire n=360K1M range. It likely would have needed sieving n=360K3M to get nearly a 70% chance of prime (If there is no prime by n=1M, it would then probably need sieving n=1M7M at least!). And the base 9 k is probably about an averageweight k for the 1k conjectures. Imagine what you would need to sieve for a lowweight k. But that one had already been searched to n=360K. For bases at n=100K, I think you'll be able to sieve n=100K1M for some of them to get a 70% chance of prime, although many will need n=100K2M I think. Iirc, for the lowest k on Riesel base 3, KEP said he had a 5860% chance of prime for n=100K1M, although he did not find one. And that's base 3, which is a far heavierweight base than all others (although that doesn't necessarily mean the k that he tested is higher than the average k remaining on the 1k bases). Gary 
Okay, thanks. I'll have to think about some of that.
I guessed the sieve files needed to be quiet high to get a >50% probability but I didn't guess [I]that [/I]high. I'll continue with the program anyway. It will be interesting to see the stats and maybe a few will be easier to sieve for efficiently than others. :smile: 
[quote=Flatlander;219742]Okay, thanks. I'll have to think about some of that.
I guessed the sieve files needed to be quiet high to get a >50% probability but I didn't guess [I]that [/I]high. I'll continue with the program anyway. It will be interesting to see the stats and maybe a few will be easier to sieve for efficiently than others. :smile:[/quote] I'll clarify on that: What I was quoting was more like a probability of prime closer to 70%. Honestly I don't know what percentage chance of prime is the best to sieve. Also, the S9 example had already been tested to n=360K, meaning we'd need a much larger nrange to have a 70% chance of prime; hence why I gave the estimated range of n=360K3M. But if all you are looking for is a chance of 50% for a single k that is already tested to n=100K, I would guess, on average, you would need to sieve the range of n=100K to n=~1M or 1.5M somewhere. In giving that as a SWAG, I'm using KEP's estimate of 5560% chance of prime for the lowest remaining Riesel base 3 k for n=100K1M; which I independently confirmed as close to accurate for that particular k. But base 3 is heavier weight, on average, than all other bases, so I'm assuming that, on average, for other 1k bases, you'll need to sieve a larger range, even to have a 50% chance of prime. If there any wonder why the final k's are so hard to find a prime for, this example demonstrates why. It's because they are usually one of the lowest weight remaining k's for the base. Tell you what: You have me curious now. I'll manually calculate these for several 1k bases at n=100K. I'll also give the value of A discussed in the last posting for n=100K200K, 200K300K, and 300K400K as well as n=1.8M1.9M and 1.9M2M for future reference. To get a fairly accurate value of A, I'll manually break up each n=100K range into 100 n=1K pieces. Gary 
The program is working and producing stats that look about right.
At the moment I have averagen fixed at the 40% of range mark and 'partitions' of 25k. This is what I have for S bases 266, 335, 337 and 341 (btw 341 and 337 are out of order in the 1k left thread 1st post.) S266 looks doable but the rest are pretty depressing! [CODE]100000000:P:1:266:257 Estimated probabilities of success for a sieve starting from 25001 : Probability for a sieve to 50008 is :0.3046898 Probability for a sieve to 75008 is :0.4392762 Probability for a sieve to 100008 is :0.5179446 Probability for a sieve to 125006 is :0.5703353 Probability for a sieve to 150006 is :0.6103485 Probability for a sieve to 175026 is :0.6401508 Probability for a sieve to 200054 is :0.663662 Probability for a sieve to 225002 is :0.6832097 Probability for a sieve to 250008 is :0.6996617 Probability for a sieve to 275018 is :0.7137238 Probability for a sieve to 300002 is :0.7264972 Probability for a sieve to 325004 is :0.7375231 Probability for a sieve to 350012 is :0.747241 Probability for a sieve to 375008 is :0.756104 Probability for a sieve to 400002 is :0.7638905 Probability for a sieve to 425030 is :0.7711558 Probability for a sieve to 450056 is :0.7778163 Probability for a sieve to 475004 is :0.7840917 Probability for a sieve to 500028 is :0.7896655 Probability for a sieve to 525014 is :0.7947405 Probability for a sieve to 550008 is :0.7994754 Probability for a sieve to 575006 is :0.8039504 Probability for a sieve to 600006 is :0.8081636 Probability for a sieve to 625004 is :0.812016 Probability for a sieve to 650006 is :0.8159369 Probability for a sieve to 675024 is :0.8195084 Probability for a sieve to 700022 is :0.8228505 Probability for a sieve to 725004 is :0.8259242 Probability for a sieve to 750018 is :0.8288481 Probability for a sieve to 775004 is :0.8316786 Probability for a sieve to 800010 is :0.8344177 Probability for a sieve to 825002 is :0.8369706 Probability for a sieve to 850002 is :0.8393937 Probability for a sieve to 875008 is :0.841714 Probability for a sieve to 900012 is :0.8440081 Probability for a sieve to 925002 is :0.8461736 Probability for a sieve to 950006 is :0.8482533 Probability for a sieve to 975006 is :0.8502517 Probability for a sieve to 999986 is :0.8521671 100000000:P:1:335:257 Estimated probabilities of success for a sieve starting from 25001 : Probability for a sieve to 50010 is :0.1355928 Probability for a sieve to 75042 is :0.2004586 Probability for a sieve to 100002 is :0.2464792 Probability for a sieve to 125006 is :0.2789975 Probability for a sieve to 150018 is :0.3062804 Probability for a sieve to 175002 is :0.3266961 Probability for a sieve to 200046 is :0.345123 Probability for a sieve to 225002 is :0.3605122 Probability for a sieve to 250038 is :0.3740461 Probability for a sieve to 275010 is :0.3856604 Probability for a sieve to 300020 is :0.396175 Probability for a sieve to 325092 is :0.4056267 Probability for a sieve to 350046 is :0.4147946 Probability for a sieve to 375002 is :0.4228382 Probability for a sieve to 400010 is :0.4302676 Probability for a sieve to 425010 is :0.4371182 Probability for a sieve to 450122 is :0.4434187 Probability for a sieve to 475034 is :0.4494008 Probability for a sieve to 500022 is :0.4548441 Probability for a sieve to 525008 is :0.4599947 Probability for a sieve to 550058 is :0.4651467 Probability for a sieve to 575090 is :0.4697821 Probability for a sieve to 600006 is :0.4742179 Probability for a sieve to 625034 is :0.4783694 Probability for a sieve to 650006 is :0.4824371 Probability for a sieve to 675014 is :0.4863998 Probability for a sieve to 700002 is :0.4900967 Probability for a sieve to 725040 is :0.4934128 Probability for a sieve to 750086 is :0.4969392 Probability for a sieve to 775038 is :0.500267 Probability for a sieve to 800042 is :0.5034002 Probability for a sieve to 825038 is :0.5064179 Probability for a sieve to 850026 is :0.5092647 Probability for a sieve to 875016 is :0.5120611 Probability for a sieve to 900054 is :0.5148096 Probability for a sieve to 925058 is :0.5174348 Probability for a sieve to 950066 is :0.5200572 Probability for a sieve to 975006 is :0.5225922 Probability for a sieve to 999962 is :0.5249875 100000000:P:1:337:257 Estimated probabilities of success for a sieve starting from 25001 : Probability for a sieve to 50013 is :0.1454151 Probability for a sieve to 75005 is :0.2250329 Probability for a sieve to 100049 is :0.2736259 Probability for a sieve to 125017 is :0.3094109 Probability for a sieve to 150017 is :0.3368471 Probability for a sieve to 175045 is :0.3600681 Probability for a sieve to 200049 is :0.3794001 Probability for a sieve to 225045 is :0.3961254 Probability for a sieve to 250089 is :0.4104187 Probability for a sieve to 275009 is :0.4235383 Probability for a sieve to 300045 is :0.4347367 Probability for a sieve to 325005 is :0.445013 Probability for a sieve to 350017 is :0.4543006 Probability for a sieve to 375049 is :0.4628028 Probability for a sieve to 400005 is :0.4709361 Probability for a sieve to 425013 is :0.4781026 Probability for a sieve to 450045 is :0.4850882 Probability for a sieve to 475025 is :0.4914963 Probability for a sieve to 500009 is :0.497448 Probability for a sieve to 525077 is :0.5028558 Probability for a sieve to 550009 is :0.508113 Probability for a sieve to 575109 is :0.5131022 Probability for a sieve to 600017 is :0.5178083 Probability for a sieve to 625013 is :0.5222524 Probability for a sieve to 650069 is :0.5265204 Probability for a sieve to 675005 is :0.5304789 Probability for a sieve to 700005 is :0.5342233 Probability for a sieve to 725013 is :0.5380203 Probability for a sieve to 750025 is :0.5416164 Probability for a sieve to 775009 is :0.5451453 Probability for a sieve to 800025 is :0.5483705 Probability for a sieve to 825025 is :0.5515493 Probability for a sieve to 850049 is :0.5546204 Probability for a sieve to 875013 is :0.5575707 Probability for a sieve to 900037 is :0.5604132 Probability for a sieve to 925057 is :0.5631033 Probability for a sieve to 950037 is :0.565847 Probability for a sieve to 975005 is :0.5684015 Probability for a sieve to 999989 is :0.570884 100000000:P:1:341:257 Estimated probabilities of success for a sieve starting from 25001 : Probability for a sieve to 50022 is :0.1208785 Probability for a sieve to 75048 is :0.1858103 Probability for a sieve to 100008 is :0.2279986 Probability for a sieve to 125016 is :0.25898 Probability for a sieve to 150024 is :0.2834809 Probability for a sieve to 175008 is :0.303843 Probability for a sieve to 200010 is :0.3207383 Probability for a sieve to 225036 is :0.3358499 Probability for a sieve to 250044 is :0.3486327 Probability for a sieve to 275004 is :0.3599488 Probability for a sieve to 300006 is :0.3701751 Probability for a sieve to 325032 is :0.3792854 Probability for a sieve to 350016 is :0.3877428 Probability for a sieve to 375054 is :0.3954519 Probability for a sieve to 400110 is :0.4024843 Probability for a sieve to 425034 is :0.4092336 Probability for a sieve to 450030 is :0.4152985 Probability for a sieve to 475020 is :0.4208208 Probability for a sieve to 500070 is :0.4261296 Probability for a sieve to 525006 is :0.431372 Probability for a sieve to 550020 is :0.4361647 Probability for a sieve to 575004 is :0.4405598 Probability for a sieve to 600072 is :0.4447985 Probability for a sieve to 625038 is :0.4490166 Probability for a sieve to 650016 is :0.4527816 Probability for a sieve to 675036 is :0.456551 Probability for a sieve to 700026 is :0.4604775 Probability for a sieve to 725070 is :0.4638947 Probability for a sieve to 750072 is :0.4671016 Probability for a sieve to 775008 is :0.470193 Probability for a sieve to 800004 is :0.4732406 Probability for a sieve to 825030 is :0.4761627 Probability for a sieve to 850056 is :0.479094 Probability for a sieve to 875010 is :0.4817891 Probability for a sieve to 900102 is :0.4844173 Probability for a sieve to 925050 is :0.4869543 Probability for a sieve to 950004 is :0.4895191 Probability for a sieve to 975018 is :0.491972 Probability for a sieve to 999942 is :0.4943631 [/CODE]Do these look about right? When you give me details of the best way to set averagen, I will program it in. (In the meantime I'll probably start adding some code now to work through the S and R lists producing probability files.) 
Mark,
I'm sorry, I've lost where the posting is now. Can you post a link to the latest version of srfile that can remove many k's at once? It would be very handy for a new effort that I am working on. Thanks, Gary 
The [url=http://sites.google.com/site/geoffreywalterreynolds/programs/srsieve]link[/url] was in the 33100 base thread (post #666).
Use srsieve V0.6.17 which includes srfile with the new option. 
Tim,
You had provided a link to all of the needed CRUS software that I put in the 1st posting of this thread. The link does not seem to work now. Can you provide a new link or an attachment to the programs that I can upload to my server machine so that I can provide a link. Gary 
Worked for me here!
But the ZIPfiles contains all older versions! @Gary: If you plan to create such download on the CRUSpage, please include the scriptfile "newbases4.3.txt" and perhaps other tiny scripts/tools, too! 
[quote=kar_bon;229265]Worked for me here!
But the ZIPfiles contains all older versions! @Gary: If you plan to create such download on the CRUSpage, please include the scriptfile "newbases4.3.txt" and perhaps other tiny scripts/tools, too![/quote] Not for me. When I click on the word "here" in: "Click here to download your attachment" on the google sites page, I get "Internet Explorer cannot display the webpage". I've tried it 4 times. I'm using IE8 in Windows Vista. If you can post an attachment with the programs, I'll add the starting bases script to it and upload the whole thing to my machine and provide a new link for it. Gary 
I've just uploaded it [url=www.rieselprime.de/dl/CRUS_pack.zip]here[/url] and contains (6.0 MB):
 LLR / cLLR V3.8.1  PFGW WIN V3.5 and V3.6  sr1sieve V1.4.1  sr2sieve V1.8.11  srsieve / srfile V0.6.17  PFGWscript "newbases4.3.txt" 
[quote=kar_bon;229270]I've just uploaded it [URL="http://www.rieselprime.de/dl/CRUS_pack.zip"]here[/URL] and contains (6.0 MB):
 LLR / cLLR V3.8.1  PFGW WIN V3.5 and V3.6  sr1sieve V1.4.1  sr2sieve V1.8.11  srsieve / srfile V0.6.17  PFGWscript "newbases4.3.txt"[/quote] Excellent! Thanks Karsten. I have now changed the link in the 1st posting. If you can leave it on your site, that would be helpful. 
Sure, perhaps there're other small tools or scripts needed here in CRUS, please post and I can inlcude them, too.
I try to update if newer versions are out like LLR! 
Question
Okay, this is almost certainly an incredibly daft question, and I'm figuring it's a definite no, (have I lowered your expectations far enough yet?) but
Is there a way to doublecheck results without testing the values again, and checking that the RES64 residues match? This question has been prompted by my decision (foolish) to check that no primes were missed up to n=5k on S928 (my monster ongoing project.) I've sieved to moderate depth, and just hitting go on the prp tests, but there are a huge number of tests to grind through. Was just wondering if there was a way to use the previously known RES64 values. 
It is indeed a definite no. AFAIK the residue (whether the lowest 64 bits, i.e. the RES64, or even the full residue that's some size smaller than the number you're testing) tells you nothing useful except that if it's 0, it's PRP, (or prime, depending on the test; these tests would be PRP) and if it's not, then it's composite. If there was anything useful in the residue, GIMPS would certainly use it for double checking Mersenne numbers, but they don't.
If you saved interim residues and save files, you could save time on triple checking when there was a problem in one of the tests, but that's only worth it for very large tests where there's a decent chance that any particular one is bad, like GIMPS' tests (but they don't use that because save files, which for GIMPS are easily ~5 MB, are too cumbersome to transmit, at least for some users). More specifically for S928: See [url]http://www.mersenneforum.org/showthread.php?t=13870[/url]. There were some recent changes to gwnum that could make PFGW select an FFT length that was too low for some numbers and make the tests produce an incorrect result without giving a message that there might be a problem. S928 had a very low number of results that had to be retested due to this problem: 30 out of 510105. He's checked them out without discovering anything amiss. This means there is a better chance that none of your tests were wrong. But it's far from a full double check: this just means that any errors caused by this particular bug would have been caught. 
[QUOTE=paleseptember;233201]Okay, this is almost certainly an incredibly daft question, and I'm figuring it's a definite no, (have I lowered your expectations far enough yet?) but
Is there a way to doublecheck results without testing the values again, and checking that the RES64 residues match? This question has been prompted by my decision (foolish) to check that no primes were missed up to n=5k on S928 (my monster ongoing project.) I've sieved to moderate depth, and just hitting go on the prp tests, but there are a huge number of tests to grind through. Was just wondering if there was a way to use the previously known RES64 values.[/QUOTE] Unfortunately, no. You have to rerun the entire PRP test and compare the residues. Note that I looked for missed primes for S928 for n < 15000 by using the updated gwnum and PFGW 3.3.6. A very small percentage of tests needed to be redone, but nothing new was found. I wouldn't want you to waste your time on it. If you want to do anything with S928, take it to n = 25000. IIRC, it has only been tested to n = 15000. 
Thank MiniGeek, thanks Rogue.
My firstpass testing efforts on S928 are at n=15.5K, with this 1K range looking more fruitful already (12 PRPs already!) 
[url]http://www.mersenneforum.org/showthread.php?p=233311#post233311[/url]
[QUOTE=MiniGeek;233311]The odds of prime spreadsheet is very useful, but when the n (or, to a lesser extent, the k) varies greatly, (as is common in CRUS work, or over large areas of any work) it is hard to choose the right average n to get accurate results. I've made a simple command line Java app that has the same function as the odds of prime spreadsheet, but instead of making you pick the average k and n, it reads each k/n pair and works off of that. It reports relevant numbers for primes and twin primes (not triplet or quadruplet). It is attached as a .jar, along with the source (it's not commented, and it includes some other code unused here, but I figured better messy source than no source :smile:). Run it without any arguments (or with h or whatever) to get help on how to use it ("java jar calcPrimes.jar" will do it). Note that it is pretty picky with the sieve depth and sieve file. The sieve depth parser is extremely simple: first replace "G" with 9 zeroes and "T" with 12 zeroes, then use Java's Long.parseLong (e.g. 1.5*10^12, 1.5T, and 15M are all invalid, while 1T, 1500G, and 15000000 are valid). And the sieve file must be in NewPGen format ("k n" on each line) with no header of any sort, just the k and n. This has had very little testing, but I've checked it against the spreadsheet on one file, and the results seems to be accurate.[/QUOTE] [URL="http://www.mersenneforum.org/attachment.php?attachmentid=5799&d=1286977423"]calcPrimes.zip[/URL] 
Nice work Tim.

Today I tried pfgw from the Linux command line with the new bases script. This is what I got:
[code] >pfgw f30 script.txt PFGW Version 3.4.3.64BIT.20101025.x86_Dev [GWNUM 26.4] Script File Switching to Exponentiating using GMP 900000002*3^11 is composite: RES64: [00000000548FAAFE] (0.0000s+0.0098s) 900000002*3^21 is composite: RES64: [000000006E785731] (0.0000s+0.0003s) 900000002*3^31 is composite: RES64: [00000000CEE9CEBC] (0.0000s+0.0002s) 900000002*3^41 is composite: RES64: [00000000AE5D247C] (0.0000s+0.0002s) 900000002*3^51 is composite: RES64: [0000002EC7ABAB86] (0.0000s+0.0002s) 900000002*3^61 is composite: RES64: [0000003D142FA262] (0.0000s+0.0002s) 900000002*3^71 is composite: RES64: [00000110D28E2AC0] (0.0000s+0.0002s) 900000002*3^81 is composite: RES64: [000001A31E929FE4] (0.0000s+0.0002s) 900000002*3^91 is composite: RES64: [00000CD56D36EA13] (0.0000s+0.0002s) 900000002*3^101 is 3PRP! (0.0000s+0.0002s) Primality testing 900000002*3^101 [N+1, BrillhartLehmerSelfridge] Signal SIGILL caught [/code] So the script starts nicely until a problem occurs when a primality test is started. I am not a coder at all, but I dimly remember a problem with the tpsieve software and I had to build the binary myself from the sources for some reason. I think it was something about static or dynamic linking (which I can't even tell apart *lol*). Any ideas? OS is RedHat enterprise, I'd have to look up the exact version tomorrow if needed. 
[QUOTE=PuzzlePeter;253522]Today I tried pfgw from the Linux command line with the new bases script. This is what I got:
[code] >pfgw f30 script.txt PFGW Version 3.4.3.64BIT.20101025.x86_Dev [GWNUM 26.4] Signal SIGILL caught [/code] So the script starts nicely until a problem occurs when a primality test is started. I am not a coder at all, but I dimly remember a problem with the tpsieve software and I had to build the binary myself from the sources for some reason. I think it was something about static or dynamic linking (which I can't even tell apart *lol*). Any ideas? OS is RedHat enterprise, I'd have to look up the exact version tomorrow if needed.[/QUOTE] SIGILL means illegal instruction. It implies that GMP was built with CPU specific optimizations. I keep forgetting to talk to Steven Harvey about that. In the interim, you can build yourself (if desired), but you will need some assistance from me. I have yet to take the time to fix all of the makefile problems. 
[QUOTE=rogue;253526]SIGILL means illegal instruction. It implies that GMP was built with CPU specific optimizations. I keep forgetting to talk to Steven Harvey about that.
In the interim, you can build yourself (if desired), but you will need some assistance from me. I have yet to take the time to fix all of the makefile problems.[/QUOTE] How does building work? Please note that I have no experience with compiler languages other than some turbo pascal 15 years ago. All I do is a little bit of scripting... BTW the problem occured on a XEON X5550, OS is [quote] uname a Linux wumc0519 2.6.18194.17.4.el5 #1 SMP Mon Oct 25 15:50:53 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux [/quote] 
Post to exchange a script file
1 Attachment(s)
Following Mark's instructions, I tried the failing primality test from the command line, using pfgw32 and pfgw64 version 3.4.5 for Linux. They both worked. So I tried running the running the script again. pgw32 worked, pfgw64 produced the SIGILL error as described.
So here's the script I was using, there seems to be no way to attach it to a personal message to Mark. This post can be deleted as soon as he gets the attachment. Thanks, Peter 
[QUOTE=PuzzlePeter;254548]Following Mark's instructions, I tried the failing primality test from the command line, using pfgw32 and pfgw64 version 3.4.5 for Linux. They both worked. So I tried running the running the script again. pgw32 worked, pfgw64 produced the SIGILL error as described.
So here's the script I was using, there seems to be no way to attach it to a personal message to Mark. This post can be deleted as soon as he gets the attachment. Thanks, Peter[/QUOTE] I presume you used f30 with this script. It works on Win64, so I'll need to get access to a Linux box in order to debug it. BTW, if I can't reproduce on a Linux box available to me, would you be able to get me access to your box so that I can debug on it? 
[QUOTE=rogue;254550]I presume you used f30 with this script. It works on Win64, so I'll need to get access to a Linux box in order to debug it.
BTW, if I can't reproduce on a Linux box available to me, would you be able to get me access to your box so that I can debug on it?[/QUOTE] Ugh, yes I forgot to mention f30. These boxes aren't even online, I transfer data via USB stick. I haven't got admin permissions either. Sorry! But I'll be happy to carry out any instructions you give me. It will be a slow and awkward process though. 
[QUOTE=PuzzlePeter;254558]Ugh, yes I forgot to mention f30.
These boxes aren't even online, I transfer data via USB stick. I haven't got admin permissions either. Sorry! But I'll be happy to carry out any instructions you give me. It will be a slow and awkward process though.[/QUOTE] It would be rather hard to do this on an offline box. You need the sources and a compiler (gcc) and the debugging tool (gdb). If you can do these things, then talk to me offline via my email address. 
Steven Harvey has been able to reproduce the problem on his Linux box (where PFGW is built from). He has given me ssh access so I am going to debug it there.

[QUOTE=rogue;254620]Steven Harvey has been able to reproduce the problem on his Linux box (where PFGW is built from). He has given me ssh access so I am going to debug it there.[/QUOTE]
That's great! gcc is available to me, but not gdb... BTW: is there a way to completely suppress screen output? The program ploughs through the k's so fast I am afraid output may slow down the whole thing. I know it does for the sieves at low p levels when run without q. 
[QUOTE=PuzzlePeter;254621]That's great! gcc is available to me, but not gdb...
BTW: is there a way to completely suppress screen output? The program ploughs through the k's so fast I am afraid output may slow down the whole thing. I know it does for the sieves at low p levels when run without q.[/QUOTE] d/l 3.4.6 and use Cquiet. 
[QUOTE=rogue;254623]d/l 3.4.6 and use Cquiet.[/QUOTE]
Thanks! 
[QUOTE=PuzzlePeter;254548]Following Mark's instructions, I tried the failing primality test from the command line, using pfgw32 and pfgw64 version 3.4.5 for Linux. They both worked. So I tried running the running the script again. pgw32 worked, pfgw64 produced the SIGILL error as described.
So here's the script I was using, there seems to be no way to attach it to a personal message to Mark. This post can be deleted as soon as he gets the attachment. Thanks, Peter[/QUOTE] I have fixed the problem, or at least I think I have. I rebuilt GMP using "generic x86" instructions and this no longer fails. I hope to rerelease the Linux soon. 
All times are UTC. The time now is 17:01. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2022, Jelsoft Enterprises Ltd.