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

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

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=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:)

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

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

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

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.

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

30440162*3^90938+1 is prime.