Sierp base 3 - mini-drive Ia

[michaf]

Originally Posted by Flatlander

40809266*3^89759+1
Is prime.
It's nice that every prime I find here beats my base 3 record.

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

Way to go!

[mdettweiler]

Originally Posted by Flatlander

86-87 finished.
Taking:
87K-88K
88K-89K

Originally Posted by Flatlander

87-88 and 88-89 complete.
Taking 89-90.

Originally Posted by Flatlander

89-90 complete.
Taking:
90K-91K

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.

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.

[Flatlander]

Okay.
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: http://www.mersenneforum.org/showpos...1&postcount=79 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]

Originally Posted by Flatlander

Okay.
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: http://www.mersenneforum.org/showpos...1&postcount=79 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.

Actually, I have no idea what the numbers in brackets are. 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.

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

[Flatlander]

Taking:
91K-92K
92K-93K
Using the -b=3 option with the error checking version. Which (unless I've jumped an FFT or something) appears about 8% slower.

[mdettweiler]

Originally Posted by Flatlander

Taking:
91K-92K
92K-93K
Using the -b=3 option with the error checking version. Which (unless I've jumped an FFT or something) appears about 8% slower.

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]

Originally Posted by mdettweiler

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.

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.

[Flatlander]

Originally Posted by mdettweiler

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.

Okay I'll switch back over.

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

[gd_barnes]

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]

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

[Flatlander]

30440162*3^90938+1 is prime.