mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Conjectures 'R Us (https://www.mersenneforum.org/forumdisplay.php?f=81)
-   -   Sierp base 3 - mini-drive Ia (https://www.mersenneforum.org/showthread.php?t=10506)

michaf 2008-10-25 19:09

[quote=Flatlander;146465]40809266*3^89759+1
Is prime.
It's nice that every prime I find here beats my base 3 record. :smile:[/quote]

Ah... you have more luck then I had on my ranges :)

Way to go!

mdettweiler 2008-10-25 19:30

[quote=Flatlander;146129]86-87 finished.
Taking:
[URL="http://gbarnes017.googlepages.com/sieve-sierp-base3-0M-50M-87K-88K.txt"]87K-88K[/URL]
[URL="http://gbarnes017.googlepages.com/sieve-sierp-base3-0M-50M-88K-89K.txt"]88K-89K[/URL][/quote]
[quote=Flatlander;146372]87-88 and 88-89 complete.
Taking 89-90.[/quote]
[quote=Flatlander;146501]89-90 complete.
Taking:
[URL="http://gbarnes017.googlepages.com/sieve-sierp-base3-0M-50M-90K-91K.txt"]90K-91K[/URL][/quote]
Chris, I just noticed something VERY important about these ranges: the results files don't include any residuals whatsoever! Are you forgetting to run Phrot with the -b=3 command line flag so that it records LLR-compatible residuals? (Without the presence of that switch, it simply records no residuals whatsoever.)

Since this is only for a relatively small chunk of n-range, and since your machine is known to be stable, no need to redo these ranges. However, if you could please run Phrot with the -b=3 option on the command line in the future, that would be great. :smile:

Edit: It appears that this also holds true for your Phrot-produced Riesel base 3 results. Again, no need to re-do them, but you'll definitely want to watch this in the future. :smile:

Flatlander 2008-10-25 19:44

Okay.:smile:
I had no idea what the numbers meant in results.out! I thought the numbers in the brackets was some sort of residue that could be doublechecked. Also, from this post: [URL]http://www.mersenneforum.org/showpost.php?p=145781&postcount=79[/URL] I assumed that the LLR residues were invalid anway?
Is that what the *_e executables are for?

I'll add the -b=3 option for future ranges.

mdettweiler 2008-10-25 20:23

[quote=Flatlander;146505]Okay.:smile:
I had no idea what the numbers meant in results.out! I thought the numbers in the brackets was some sort of residue that could be doublechecked. Also, from this post: [URL]http://www.mersenneforum.org/showpost.php?p=145781&postcount=79[/URL] I assumed that the LLR residues were invalid anway?
Is that what the *_e executables are for?

I'll add the -b=3 option for future ranges.[/quote]
Actually, I have no idea what the numbers in brackets are. :smile: I think they may have something to do with some "behind the scenes" stuff related to the PRP test.

As for the validity of the LLR residuals produced by Phrot: no, it seems that that's just an isolated (albeit quite mysterious) circumstance. Most residuals produced by Phrot should exactly match their LLR counterparts--I've confirmed it myself a number of times. :smile:

As for the *_e executables: those have some extra error checking functionality enabled, which might help reduce the chance of an invalid LLR residual in those rare cases where one might pop up. Since I haven't heard of any recorded performance drops from using the error-checking version, you may as well use it instead of the "normal" version. (It simply adds an extra section to each results file line, enclosed in parentheses, detailing various error-checking information, though it all seems Greek to me. :smile:)

Flatlander 2008-10-26 02:03

Taking:
[URL="http://gbarnes017.googlepages.com/sieve-sierp-base3-0M-50M-91K-92K.txt"]91K-92K[/URL]
[URL="http://gbarnes017.googlepages.com/sieve-sierp-base3-0M-50M-92K-93K.txt"]92K-93K[/URL]
Using the -b=3 option with the error checking version. Which (unless I've jumped an FFT or something) appears about 8% slower.

mdettweiler 2008-10-26 02:40

[quote=Flatlander;146559]Taking:
[URL="http://gbarnes017.googlepages.com/sieve-sierp-base3-0M-50M-91K-92K.txt"]91K-92K[/URL]
[URL="http://gbarnes017.googlepages.com/sieve-sierp-base3-0M-50M-92K-93K.txt"]92K-93K[/URL]
Using the -b=3 option with the error checking version. Which (unless I've jumped an FFT or something) appears about 8% slower.[/quote]
Ouch. I actually hadn't checked the timings for the regular vs. error-checking version, so I had no idea that the error-checking one was any slower.

However, from what I can tell, the residual errors are very infrequent and happen mostly on power-of-2 bases (for which it's usually more advisable to use LLR anyway). So, considering the apparent speed difference, you may as well use the regular version after all.

mdettweiler 2008-10-26 02:52

[quote=mdettweiler;146563]Ouch. I actually hadn't checked the timings for the regular vs. error-checking version, so I had no idea that the error-checking one was any slower.

However, from what I can tell, the residual errors are very infrequent and happen mostly on power-of-2 bases (for which it's usually more advisable to use LLR anyway). So, considering the apparent speed difference, you may as well use the regular version after all.[/quote]
Update: I just checked the difference in timings for myself on some Riesel base 37 candidates that I'm currently doing for CRUS. I confirm the speed difference between the error-checking version and the "regular" one--I'm getting about 7-8% speed difference, as you did.

Okay, it looks like the "regular" version is probably the way to go for most purposes. :smile:

Flatlander 2008-10-26 02:54

[quote=mdettweiler;146563]Ouch. I actually hadn't checked the timings for the regular vs. error-checking version, so I had no idea that the error-checking one was any slower.

However, from what I can tell, the residual errors are very infrequent and happen mostly on power-of-2 bases (for which it's usually more advisable to use LLR anyway). So, considering the apparent speed difference, you may as well use the regular version after all.[/quote]

Okay I'll switch back over.

The lost time was more than made up for by this:
26261252*3^91020+1 is prime.:smile:

gd_barnes 2008-10-26 08:16

The last 2 k's with primes have now been removed from all files. 80 k's remain.

Chris, if you click on the 3 links in your reservation posts here, you can get files with the k's removed for n=90K-93K.

Flatlander 2008-10-26 18:56

28071866*3^91455+1
48652642*3^92392+1
Are prime. :shock:

Flatlander 2008-10-26 22:58

30440162*3^90938+1 is prime.


All times are UTC. The time now is 20:56.

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