Factor missed by TF
 

I ended up finding a factor through ECM, [URL]http://www.mersenne.ca/exponent.php?exponentdetails=8316221[/URL], and I noticed on James' site that TF to 64 had been done.

I realize the TF was probably done too long ago to know what was used, but I'm curious, how often is a factor missed by TF?

Hmmm, interesting. Makes you want to start all TF assignments from 1 instead of dispensed bit level. Takes a few seconds on current hardware, anyway (for higher exponent levels).

As a lark, I altered the next number I was (double) checking in the worktodo (31998653) to check from 2 to 64 before it checked from 69 to 70. Took 3m, 8s on the 480. (69-70 took 13m, 16s).

GTX 580:

[I]no factor for M31998653 from 2^1 to 2^64 [mfaktc 0.20 75bit_mul32]
tf(): total time spent: 2m 34.743s[/I]

Yes, it seems to lose about 85% of performance, as mfaktc is not optimized for bit levels this low.

I have not tried the less-classes version.

This is on my "buggy" 560...

[CODE]got assignment: exp=8316221 bit_min=1 bit_max=64 (0.43 GHz-days)
Starting trial factoring M8316221 from 2^1 to 2^64 (0.43 GHz-days)
k_min = 0
k_max = 1109082122379
Using GPU kernel "75bit_mul32"
[date time] exponent : percent class #, seq | GHz | time | ETA | #FCs | rate | SieveP. | CPU wait |
[Apr 24 19:23] M8316221 : 85.0% 3924/4620,816/960 | 64.31 | 0.599s | 1m26s | 66.98M | 111.82M/s | 2000 | 0.95% |
M8316221 has a factor: 13796400499804569169
[/CODE]

How many factors did we miss?...

- Prime95 (the software...) used to stop as soon as it discovered a factor, so some ranges may not be completed.
- From version 20.3, Mprime no longer searches for a smaller factor when trial factoring discovers a factor.
- Before version 19.0, factoring was not "layered" (one bit at a time) and limited to 2^64.
- On version 22.11, A bug that caused factors to be missed in the last stage of P-1 and ECM factoring was fixed. The bug was introduced in executables built after Sept. 28, 2002.
- On version 22,12, A bug was fixed that caused some factors to be missed in stage 2 of P-1 when the available memory did not let the program allocate 12 temporary variables. If testing a number in the 16 millions using an FFT size of 768K, then each temporary takes 768K * 8 bytes or 6MB. If your memory setting was less than 72MB (6MB * 12 temporaries) then you were affected by the bug. Actual the program allocates some fixed tables so anything less than about 75MB triggered the bug.
- Version 24.13: SSE2 trial factoring code had a bug when factoring very large exponents.
- Version 25.8: A crash bug doing 61 and 62 bit trial factoring on Pentium CPUs that do not support the CMOV instruction was fixed. On these same CPUs a bug was fixed when factors smaller than 2^60 was found.

Luigi

[QUOTE=TObject;338189]Hmmm, interesting. Makes you want to start all TF assignments from 1 instead of dispensed bit level. Takes a few seconds on current hardware, anyway (for higher exponent levels).[/QUOTE]

Of course, because any factor will be of the form 2kp+1, the smallest possible factor would be 2p+1, which for many of the numbers with which we work, will be at least 20 or so bits. So there's no need to start from bit level 1, though on today's hardware, it only makes probably a few microseconds of difference.

[QUOTE=NBtarheel_33;338261]Of course, because any factor will be of the form 2kp+1, the smallest possible factor would be 2p+1, which for many of the numbers with which we work, will be at least 20 or so bits.[/QUOTE]

That's an excellent point. Even DCTF'ing the 31M range (31M<p<32M), thats 62M-64M, 26 bits. Taking the couple minutes to check 26-64 on ever number I do though would decrease my throughput by about 16% though, w/o better optimized kernel functions. Maybe those should be double checked, but probably not without some recoding.

EDIT: From another thread:

[QUOTE=James Heinrich;338200]Also: [LIST][*]GPU sieving is not available for < 2[sup]64[/sup] (the kernels that support such small factors are old (and notably slower than the more modern kernels available for "normal" GIMPS-range work) and haven't been rewritten to support GPU sieving)[/LIST][/QUOTE]
James reminds me that the reason my 480 card took 3 minutes to do that factoring is that I was running prime95 on all my cpu cores at the time and factoring for < 64 bits is still sieved on the cpu. It probably would have gone a lot faster if I hadn't been running prime95 at the time.

[QUOTE=NBtarheel_33;338261]Of course, because any factor will be of the form 2kp+1, the smallest possible factor would be 2p+1, which for many of the numbers with which we work, will be at least 20 or so bits. So there's no need to start from bit level 1, though on today's hardware, it only makes probably a few microseconds of difference.[/QUOTE]I suspect it actually makes no difference (not just small difference). As far as I know, all TF software will operate on k values and only use the supplied bit level values to calculate min/max k values for the run. So whether you specify a starting bitlevel of 1 or 10 or anything up to the actual minimum bitsize of a k=1 factor for that exponent, the actual starting k will end up being the same value, so actually no performance difference.

For what it's worth, there aren't any missed factors smaller than k=10000, I checked them all in Sept 2012. I found about 300,000 factors that PrimeNet didn't previously know about (as far as I recall they were all n[sup]th[/sup] factors for already-factored exponents).

Gaps in exponent report
 

Tell me if I'm reading this right. On several of my LL assignments, it appears to me that some of the TF ranges were missed. On [URL]http://www.mersenne.org/report_exponent/?exp_lo=67422577&full=1[/URL] the typical "no factor to 2^63" at the bottom of the display is missing, and the range from 2^71 -> 2^72 is not present. On [URL="http://www.mersenne.org/report_exponent/?exp_lo=67422577&full=1"]http://www.mersenne.org/report_exponent/?exp_lo=69589171&full=1[/URL] the range from 2^62 -> 2^63 and 2^63 -> 2^64 are missing. Other LL assignments to me have similar gaps.

Is there a way I can force a TF test to fill and cover these gaps? Were these "missing" gaps done anyways by some unknown (to me) process? Prime95, win7.

[QUOTE=scubabob;407210]Is there a way I can force a TF test to fill and cover these gaps? Were these "missing" gaps done anyways by some unknown (to me) process? Prime95, win7.[/QUOTE]


Factor=assignment ID,exponent,how far factored,how far to factor to

add the line

Factor=67422577,71,72

to worktodo.ini which after the client has contacted the server will appear as

Factor=N/A,67422577,71,72

Someone, a volunteer, should compile a list of all such gaps and make it available for distribution.