Software/instructions/questions - Page 8

gd_barnes · 2010-09-10, 19:31

Quote:

Originally Posted by kar_bon

I've just uploaded it here 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
- PFGW-script "new-bases-4.3.txt"

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.

kar_bon · 2010-09-10, 19:37

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!

paleseptember · 2010-10-12, 05:45

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

Mini-Geek · 2010-10-12, 12:40

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 http://www.mersenneforum.org/showthread.php?t=13870. 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.

rogue · 2010-10-12, 12:44

Quote:

Originally Posted by paleseptember

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

Unfortunately, no. You have to re-run 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.

paleseptember · 2010-10-12, 22:06

Thank Mini-Geek, thanks Rogue.

My first-pass testing efforts on S928 are at n=15.5K, with this 1K range looking more fruitful already (12 PRPs already!)

Mini-Geek · 2010-10-13, 13:51

http://www.mersenneforum.org/showthr...311#post233311

Quote:

Originally Posted by Mini-Geek

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

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

calcPrimes.zip

gd_barnes · 2010-10-13, 18:07

Nice work Tim.

Puzzle-Peter · 2011-02-23, 17:10

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^1-1 is composite: RES64: [00000000548FAAFE] (0.0000s+0.0098s)
900000002*3^2-1 is composite: RES64: [000000006E785731] (0.0000s+0.0003s)
900000002*3^3-1 is composite: RES64: [00000000CEE9CEBC] (0.0000s+0.0002s)
900000002*3^4-1 is composite: RES64: [00000000AE5D247C] (0.0000s+0.0002s)
900000002*3^5-1 is composite: RES64: [0000002EC7ABAB86] (0.0000s+0.0002s)
900000002*3^6-1 is composite: RES64: [0000003D142FA262] (0.0000s+0.0002s)
900000002*3^7-1 is composite: RES64: [00000110D28E2AC0] (0.0000s+0.0002s)
900000002*3^8-1 is composite: RES64: [000001A31E929FE4] (0.0000s+0.0002s)
900000002*3^9-1 is composite: RES64: [00000CD56D36EA13] (0.0000s+0.0002s)
900000002*3^10-1 is 3-PRP! (0.0000s+0.0002s)
Primality testing 900000002*3^10-1 [N+1, Brillhart-Lehmer-Selfridge]

Signal SIGILL caught

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.

rogue · 2011-02-23, 18:36

Quote:

Originally Posted by Puzzle-Peter

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

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.

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.

Puzzle-Peter · 2011-02-26, 05:30

Quote:

Originally Posted by rogue

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.

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.18-194.17.4.el5 #1 SMP Mon Oct 25 15:50:53 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

2010-10-12, 05:45	#80
paleseptember Jun 2008 Wollongong, .au 3×61 Posts	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 double-check 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.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Useless SSE instructions	__HRB__	Programming	41	2012-07-07 17:43
Questions about software licenses...	WraithX	GMP-ECM	37	2011-10-28 01:04
Software/instructions/questions	gd_barnes	No Prime Left Behind	48	2009-07-31 01:44
Instructions to manual LLR?	OmbooHankvald	PSearch	3	2005-08-05 20:28
Instructions please?	jasong	Sierpinski/Riesel Base 5	10	2005-03-14 04:03

2010-09-10, 19:37	#79
kar_bon Mar 2006 Germany 5533₈ Posts	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!

2010-10-12, 12:40	#81
Mini-Geek Account Deleted "Tim Sorbera" Aug 2006 San Antonio, TX USA 17·251 Posts	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 http://www.mersenneforum.org/showthread.php?t=13870. 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.

2010-10-12, 22:06	#83
paleseptember Jun 2008 Wollongong, .au 3·61 Posts	Thank Mini-Geek, thanks Rogue. My first-pass testing efforts on S928 are at n=15.5K, with this 1K range looking more fruitful already (12 PRPs already!)

2010-10-13, 18:07	#85
gd_barnes May 2007 Kansas; USA 10403₁₀ Posts	Nice work Tim.