mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Conjectures 'R Us (https://www.mersenneforum.org/forumdisplay.php?f=81)
-   -   Software/instructions/questions (https://www.mersenneforum.org/showthread.php?t=9742)

gd_barnes 2010-09-10 19:31

[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
- PFGW-script "new-bases-4.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.

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

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.

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

rogue 2010-10-12 12:44

[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 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.[/QUOTE]

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

[url]http://www.mersenneforum.org/showthread.php?p=233311#post233311[/url]
[QUOTE=Mini-Geek;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]

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

rogue 2011-02-23 18:36

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

Puzzle-Peter 2011-02-26 05:30

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


All times are UTC. The time now is 09:51.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.