help request for LL double-check

[preda]

It seems to me that the observed behavior could be produced by a b_per_word (bits per word) too-big by 1 on the very last word (i.e., the last word being considered "big-word" when in fact it is always "small-word", for the DWT) [the very last word is tricky for ceil() because it does fall on integer boundary], which swallows one carry to the first word.

OTOH I did verify that my implem correctly generates small-word for the last word, i.e. 18bits for 2M FFT or 9bits for 4M FFT for 39527687.

My code computing the bits-per-word is in genBitlen() here: https://github.com/preda/gpuowl/blob/master/gpuowl.cpp

[preda]

https://www.mersenne.org/report_expo...7999863&full=1 seems to be another case of the off-by-one-residue bug. (I'm not sure as I can't see the last 2digits, but it's probable). Unfortunately I've been unable to locate such a bug in my program.

[preda]

I think I found it (in my program). The reason is related to the balanced-digit representation. When the very last word is negative, it generates one extra carry, which is the "off-by-one". Could be said that the bug is in computing the residue for output.

[Madpoo]

Originally Posted by ATH

I just added the line to the worktodo.txt
Test=39527687,75,1

Technically it would be:
DoubleCheck=39527687,75,1

Although I think in practice that only makes a difference if it hasn't been P-1'd. In that case, the "Test" or "DoubleCheck" is a hint on what the B1/B2 should be... as in, "will P-1 save one test, or two?" If two tests could be saved by finding a factor ("Test=") then the bounds are larger than if only one test would be saved ("DoubleCheck=")

[Madpoo]

Originally Posted by preda

https://www.mersenne.org/report_expo...7999863&full=1 seems to be another case of the off-by-one-residue bug. (I'm not sure as I can't see the last 2digits, but it's probable). Unfortunately I've been unable to locate such a bug in my program.

They are indeed off by one. Your result was one bit higher.

Also, I mentioned this in the other thread, but if your program is using shift-counts (I think CudaLucas does, and sounded like you may have based some code on that?) then that would be specified in the result string for that "offset" value.

It may not be using shift-counts in which case "zero" is appropriate, but if it is in fact using them, then by all means include that value in the result. There have been times when strange bugs were debugged by noticing what the shift-count values were, and just in general it makes sure a verifying run is done with different shift-counts.

[preda]

The initial problem (residue off-by-one) has been fixed. (in gpuOwL, I was not properly reversing the extra carry that was sometimes pushed by the balanced representation from last-word to first-word).

I'll take care to include the correct shift-count (and bump the version) if that becomes implemented.