WhattheTF
 

I requested a TF assignment and got the following:

Factor=4C7AA829E5371BA458897C8B9AC0129A,120171761,72,73

I submitted my results:

no factor for M120171761 from 2^72 to 2^73 [mfaktc 0.21 barrett76_mul32_gs]
no factor for M120171761 from 2^73 to 2^74 [mfaktc 0.21 barrett76_mul32_gs]

The first went through fine and the second was rejected as not needed. When I looked at the exponent it showed my 72 to 73 result and that 71 to 72 had never been done. This has happened several times recently. Any ideas? I was going to do 71 to 72 but the exponent was reassigned. If they do 71 to 72 maybe I can then submit my 73 to 74.

I tried to submit:

no factor for M120172061 from 2^73 to 2^74 [mfaktc 0.21 barrett76_mul32_gs]

And got:

processing: TF no-factor for M120172061 (2^73-2^74)

Error code: 40, error text: TF result for M120172061 was not needed

The exponent status shows that it is needed.

A lot of work was done to fill in missed bit levels and now new ones are being introduced.

Yeah, I've run about 2000 GTX 580 hours into doing skipped bit levels. Still only one factor found. I have another 1000 hours to go or so, to double check everything skipped up to 80M.

I haven't looked at any gaps above 80M.

I really do wish that PrimeNet would accept results for skipped bit levels though, to fix situations like yours.

What bothers me is that this is not a legacy situation. These skipped bit levels are being introduced today for no good reason. Who needs to investigate this?

PrimeNet should never reject results like this, regardless of the state of the exponent. This is a pretty serious issue.

Here is a list of problem exponents:

120171761
120171823
120172007
120172009
120172061
120172109

I expect it to grow with my next submission if nothing is done to fix the problem.

I am not sure but, it looks like I submitted some TF results out of bit order. PrimeNet accepted some of the out of bit order work and then broke the exponent. Since I had turned in the work I had checked out the exponents were assigned again for further work. I think these GIMPSters may have trouble submitting their results for these exponents.

I cannot submit the missing work or any additional work on this category of exponents. For example, the exponent status will show no factors below 2^71. 2^71 to 2^72 will not be in the history while 2^72 to 2^73 is. PrimeNet will accept neither the 2^71 to 2^72 results nor the 2^73 to 2^74 results. I just want to fix the mess I may have made. It would be nice if PrimeNet did not get so easily confused.

The problem with making software idiot proof is that idiots are so darn ingenious.

Error persists
 

Today I attempted to improve the results of M7508981, which has already been heavily factored.

I attempted to refactor ^60-61, because it is recorded as partially factored, and factor ^62-63, ^63-64, ^64-65 and ^65-66.

I received the following check-in results:
[CODE]Splitting composite factor 1187463822966659857 into:
* 45053887
* 26356523311
processing: TF factor 45053887 for M7508981 (2^60-2^61)
Error code: 40, error text: Factoring result for M7508981 was not needed
processing: TF factor 26356523311 for M7508981 (2^60-2^61)
Error code: 40, error text: Factoring result for M7508981 was not needed
Splitting composite factor 7520604071554054769 into:
* 285341279
* 26356523311
processing: TF factor 285341279 for M7508981 (2^62-2^63)
Error code: 40, error text: Factoring result for M7508981 was not needed
processing: TF factor 26356523311 for M7508981 (2^62-2^63)
Error code: 40, error text: Factoring result for M7508981 was not needed
Splitting composite factor 15437029382288298409 into:
* 585700519
* 26356523311
processing: TF factor 585700519 for M7508981 (2^63-2^64)
Error code: 40, error text: Factoring result for M7508981 was not needed
processing: TF factor 26356523311 for M7508981 (2^63-2^64)
Error code: 40, error text: Factoring result for M7508981 was not needed
processing: TF no-factor for M7508981 (2^64-2^65)
Error code: 40, error text: TF result for M7508981 was not needed
processing: TF no-factor for M7508981 (2^65-2^66)
Error code: 40, error text: TF result for M7508981 was not needed[/CODE]

It seems that any bit-range which reveals a known composite factor returns 'Factoring result ... was not needed' and is not recorded as a range which has been completed, whilst 'TF result ... was not needed' is recorded as completed.

So ^60-61, ^62-63, ^63-64 aren't recorded as completed, though they have been, but ^64-65 and ^65-66 are recorded as completed

[QUOTE=mattmill30;439942]Today I attempted to improve the results of M7508981, which has already been heavily factored.[/QUOTE]

mattmill30...

Thank you for your efforts. You might have demonstrated a minor bug.

[QUOTE=mattmill30;439942]
It seems that any bit-range which reveals a known composite factor returns 'Factoring result ... was not needed' and is not recorded as a range which has been completed,[/QUOTE]

Did the text you submitted contain any lines that said "no factor from 2^60 to 2^61" (or similar)? That is, is this a bug in the program output or the server processing?

[QUOTE=mattmill30;439942]Today I attempted to improve the results of M7508981, which has already been heavily factored.[/QUOTE]

This might be useful if it pinpoints a bug in mprime, but it probably wasn't useful in terms of finding new factors for M7508981.

The [URL="http://www.mersenne.org/report_ecm/?txt=0&ecm_lo=1000&ecm_hi=2000&ecmnof_lo=7508000&ecmnof_hi=7509000"]ECM Report[/URL] shows that this exponent has received a full 280 ECM tests at B1=50K (25 digits = about 83 bits) and 207 out of 640 ECM tests at B1=250K (30 digits = about 100 bits). Therefore the odds of finding a new factor of 60–65 bits are vanishingly small.

Note this is extremely deep ECM test coverage for an exponent in this range. The vast majority of 7M exponents have had no more than 3 ECM tests at B1=50K and nothing higher. No doubt people were inspired to push the ECM testing so far because of the unusual circumstance of having so many factors. Of the eleven known factors, ten were discovered by trial factoring and one (the largest, of 81 bits) by ECM.

[QUOTE=Prime95;439959]Did the text you submitted contain any lines that said "no factor from 2^60 to 2^61" (or similar)? That is, is this a bug in the program output or the server processing?[/QUOTE]

I don't have the original results, but I would have expected the 'Factoring result ... was not needed' error to be returned against the following composite factor results:

[CODE][Sat Aug 13 01:14:09 2016]
UID: mattmill30/Lenovo_ThinkPad_T430, M7508981 has a factor: 1187463822966659857 [TF:60:61:mfakto 0.15pre6-Win cl_barrett15_69_gs_4]
[Sat Aug 13 01:14:27 2016]
UID: mattmill30/Lenovo_ThinkPad_T430, found 2 factors for M7508981 from 2^60 to 2^61 [mfakto 0.15pre6-Win cl_barrett15_69_gs_4]

[Sat Aug 13 01:23:57 2016]
UID: mattmill30/Lenovo_ThinkPad_T430, M7508981 has a factor: 7520604071554054769 [TF:62:63:mfakto 0.15pre6-Win cl_barrett15_69_gs_4]
[Sat Aug 13 01:27:24 2016]
UID: mattmill30/Lenovo_ThinkPad_T430, found 1 factor for M7508981 from 2^62 to 2^63 [mfakto 0.15pre6-Win cl_barrett15_69_gs_4]

[Sat Aug 13 01:33:27 2016]
UID: mattmill30/Lenovo_ThinkPad_T430, M7508981 has a factor: 15437029382288298409 [TF:63:64:mfakto 0.15pre6-Win cl_barrett15_69_gs_4]
[Sat Aug 13 01:53:56 2016]
UID: mattmill30/Lenovo_ThinkPad_T430, found 1 factor for M7508981 from 2^63 to 2^64 [mfakto 0.15pre6-Win cl_barrett15_69_gs_4][/CODE]
NB: I did anticipate some sort of error for ^60-61, because I was only submitting 1 factor due to not wanting to duplicate the factor already found by thelegendarymudkip, though the bit-range was summarised as 2 factors having been found. But the processing didn't get beyond the composite factor error, so I assume the completeness of the bit-range wasn't even considered (it certainly wasn't recorded).

Further, I have just attempted to expand upon the [URL="http://www.mersenne.org/M60160447"]M60160447[/URL] factor entry (by providing the TF bit-range) and received the same error for the following results:
[CODE][Sun Aug 14 01:14:09 2016]
UID: mattmill30/Lenovo_ThinkPad_T430, M60160447 has a factor: 2599255729428590429303 [TF:71:72:mfakto 0.15pre6-Win cl_barrett32_76_gs_4]
[Sun Aug 14 12:52:42 2016]
UID: mattmill30/Lenovo_ThinkPad_T430, found 1 factor for M60160447 from 2^71 to 2^72 [mfakto 0.15pre6-Win cl_barrett32_76_gs_4][/CODE]
So record of the completeness of the ^71-72 bit-range for that factor is also lost.

I believe this is an issue for James. His PHP parsing skills will be required.

Further errors
 

These results returned the following errors:

[CODE][Sun Aug 14 15:21:08 2016]
UID: mattmill30/Lenovo_ThinkPad_T430, no factor for M7508981 from 2^66 to 2^67 [mfakto 0.15pre6-Win cl_barrett32_76_gs_4]
[Sun Aug 14 20:52:22 2016]
UID: mattmill30/Lenovo_ThinkPad_T430, no factor for M7508981 from 2^67 to 2^68 [mfakto 0.15pre6-Win cl_barrett32_76_gs_4]
[Mon Aug 15 12:04:52 2016]
UID: mattmill30/Lenovo_ThinkPad_T430, no factor for M7508981 from 2^68 to 2^69 [mfakto 0.15pre6-Win cl_barrett32_76_gs_4]
[Wed Aug 17 04:58:00 2016]
UID: mattmill30/Lenovo_ThinkPad_T430, M7508981 has a factor: 916091463726885012719 [TF:69:70:mfakto 0.15pre6-Win cl_barrett32_76_gs_4]
[Thu Aug 18 04:01:52 2016]
UID: mattmill30/Lenovo_ThinkPad_T430, found 1 factor for M7508981 from 2^69 to 2^70 [mfakto 0.15pre6-Win cl_barrett32_76_gs_4][/CODE]

[CODE]processing: TF no-factor for M7508981 (2^66-2^67)
Error code: 40, error text: TF result for M7508981 was not needed
processing: TF no-factor for M7508981 (2^67-2^68)
Error code: 40, error text: TF result for M7508981 was not needed
processing: TF no-factor for M7508981 (2^68-^269)
Error code: 40, error text: TF result for M7508981 was not needed
Splitting composite factor 916091463726885012719 into:
* 45053887
* 20333239254737
processing: TF factor 45053887 for M7508981 (2^69-2^70)
Error code: 40, error text: Factoring result for M7508981 was not needed
processing: TF factor 20333239254737 for M7508981 (2^69-2^70)
Error code: 40, error text: Factoring result for M7508981 was not needed[/CODE]

On a somewhat unrelated note, the History for this exponent incorrectly shows a composite factor:

[CODE]2014-08-30 thelegendarymudkip F Factor: 1583285088503372039 / TF: 60-61*[/CODE]

1583285088503372039 = 60071849 * 26356523311, and both of these small prime factors were discovered much earlier.

PrimeNet should just accept all TF results. It already accepts LL results even after double-checks have been done, so what's wrong with doing the same for TF?

[QUOTE=ixfd64;440280]PrimeNet should just accept all TF results. It already accepts LL results even after double-checks have been done, so what's wrong with doing the same for TF?[/QUOTE]

There's no way to validate TF work, like there is a residue with LL.

It does accept newly found factors via TF though. We spent quite a bit of time redoing work from known-bad CPUs a year or so ago.

[QUOTE=Mark Rose;440284]There's no way to validate TF work, like there is a residue with LL.[/QUOTE]

Sure there is, just like with an LL.

Run the work a second time with an independent worker.

Wouldn't make sense. But could be done.

[QUOTE=chalsall;440286]Sure there is, just like with an LL.

Run the work a second time with an independent worker.

Wouldn't make sense. But could be done.[/QUOTE]

Good point.

[QUOTE=Mark Rose;440292]Good point.[/QUOTE]

technically if we have the results of an LL test we can double check it using a modified LL but it's been brought up enough times about how useless that would be in practice. edit: given a factor that is.

Well, the situation for LL is the same like for TF, once a double check was done, the residue is displayed in full (i.e. unmasked). My argument in the past that the residue should be NEVER displayed unmasked was not considered by the gods at that time.

Which still bothers me today...

Since we give credits for triple checks (it was not always the case) and we display the residues in full after DC, some credit whore could report thousands of "valid" TCs without doing a minute of real work, and get the credits. Credits by themselves won't bother us, but the process could be used to "verify" computers as being "good" and get low LL work.

So, either mask the residues always, and do the things right, or give credit for double-TF and tripple-TF and make a big mess of everything.... Unfair for the people who really invested a lot of work (and electricity money) into the project...

The best would be to never display the LL residue in full, and to have a checksum stuff when reporting TF and P-1 with GPU work. Then of course, give credits to everybody, and it would not be extremely easy to report fake results (as it is now).

[QUOTE=chalsall;440286]Sure there is, just like with an LL.

Run the work a second time with an independent worker.[/QUOTE]

... which proves nothing. Think about it.

[QUOTE=axn;440305]... which proves nothing. Think about it.[/QUOTE]
It seems that a positive result (factor) can be quickly verified. The proverbial difficulty of proving a negative (prime), at least by means of TF, should apply here.
EDIT: .....and TF returns no residue to match or mismatch.

[QUOTE=kladner;440316].....and TF returns no residue to match or mismatch.[/QUOTE]

Exactamundo:smile:

[QUOTE=axn;440305]... which proves nothing. Think about it.[/QUOTE]

OK, you're correct. It /proves/ nothing in the case of a negative result. If, on the other hand, a positive (a find) comes in when someone else reported a negative, that proves that the original run wasn't good.

And, a bit like science, negatives can't be proven. However, two independent runs reporting a negative reinforces the probability of a negative. Mark did quite a bit of this kind of work a little while ago.

[QUOTE=GP2;440232]On a somewhat unrelated note, the History for this exponent incorrectly shows a composite factor:

[CODE]2014-08-30 thelegendarymudkip F Factor: 1583285088503372039 / TF: 60-61*[/CODE]

1583285088503372039 = 60071849 * 26356523311, and both of these small prime factors were discovered much earlier.[/QUOTE]

It's only in the history, which really just shows what the client reported. Fortunately the server will check the factor:
a) make sure it's really a factor
b) make sure it's a prime factor

Only prime factors get added to the official "factor" list and it seems like that was the case here. Why that client reported a composite factor in the first place... call it a bug in the client I guess? Weird.

[QUOTE=Madpoo;440387]It's only in the history, which really just shows what the client reported. Fortunately the server will check the factor:
a) make sure it's really a factor
b) make sure it's a prime factor

Only prime factors get added to the official "factor" list and it seems like that was the case here. Why that client reported a composite factor in the first place... call it a bug in the client I guess? Weird.[/QUOTE]

$ factor 1583285088503372039
1583285088503372039: 60071849 26356523311

[QUOTE=Mark Rose;440391]$ factor 1583285088503372039
1583285088503372039: 60071849 26356523311[/QUOTE]

Here's the raw result line that client reported. Maybe someone more familiar with the mfakt* code used can speculate on why it would report a composite factor:
[CODE]M7508981 has a factor: 1583285088503372039 [TF:60:61*:mfakto 0.15pre2-Win cl_barrett15_69_gs_4]
[/CODE]

The two prime factors involved were discovered much earlier, back in 2008 (Sep 8).

Seems to me the server probably should have rejected this as "not needed" and probably not give any credit for discovering a composite factor that is the result of two previously known prime factors. Otherwise everyone would just submit composite factors using known info and while it won't show up as a new factor, they may get credit for it anyway. Hmm... don't get any ideas...

[QUOTE=Madpoo;440507]Maybe someone more familiar with the mfakt* code used can speculate on why it would report a composite factor:
[CODE]M7508981 has a factor: 1583285088503372039 [TF:60:61*:mfakto 0.15pre2-Win cl_barrett15_69_gs_4]
[/CODE][/QUOTE]

It is cheaper to trail divide by some composite factors rather than making sure that each of them is a prime. I believe even P95 behavior will be the same. This is best dealt with at server side.

[QUOTE=Madpoo;440507]Here's the raw result line that client reported. Maybe someone more familiar with the mfakt* code used can speculate on why it would report a composite factor:
[CODE]M7508981 has a factor: 1583285088503372039 [TF:60:61*:mfakto 0.15pre2-Win cl_barrett15_69_gs_4]
[/CODE]

The two prime factors involved were discovered much earlier, back in 2008 (Sep 8).

Seems to me the server probably should have rejected this as "not needed" and probably not give any credit for discovering a composite factor that is the result of two previously known prime factors. Otherwise everyone would just submit composite factors using known info and while it won't show up as a new factor, they may get credit for it anyway. Hmm... don't get any ideas...[/QUOTE]

mfakt* looks for any factor of a certain number of bits, by trial factoring. In this case, 60071849 is bigger than the primes used to sieve out composite factors.

It would be nice if it could do a quick PRP test or maybe a few tests once it finds a factor, and report that the factor is composite or PRP. That would not interfere with "normal" operation, if it is only when a factor is found.

To clarify Madpoo's post, there was a guy in the past (Alex? Axon? Sorry if I don't remember the right name and I confuse him with some honest contributor) who used to report small composite P-1 factors and do lots of P-1 credit, but then George penalized him by reverting the sign of his P-1 credit :smile: (so he still had to do "honest" work to come to zero credit). Then George fixed the problem. Now the server should NOT accept composite factors. Also, all composite factors were [U]eliminated[/U] at that time (discussion still on the forum somewhere). Whatever composite factors are still there, they escaped unchecked from that time, but I honestly don't believe so, my feeling is that the issue may be caused by a recent "merge" of some old factor list into the data base. Madpoo, did you do such a merge recently? :razz:

There are 2 issues:

1) The database of known factors never contains a composite factor.
2) The history database does. It merely stores the text reported by the client or input to the manual web results page.

[QUOTE=LaurV;440561]To clarify Madpoo's post, there was a guy in the past (Alex? Axon? Sorry if I don't remember the right name and I confuse him with some honest contributor) who used to report small composite P-1 factors and do lots of P-1 credit, but then George penalized him by reverting the sign of his P-1 credit :smile: (so he still had to do "honest" work to come to zero credit). Then George fixed the problem. Now the server should NOT accept composite factors. Also, all composite factors were [U]eliminated[/U] at that time (discussion still on the forum somewhere). Whatever composite factors are still there, they escaped unchecked from that time, but I honestly don't believe so, my feeling is that the issue may be caused by a recent "merge" of some old factor list into the data base. Madpoo, did you do such a merge recently? :razz:[/QUOTE]

The issue persists:

[CODE][Mon Aug 22 14:13:19 2016]
UID: mattmill30/Lenovo_ThinkPad_T430, M7508981 has a factor: 1221455278191433598713 [TF:70:71:mfakto 0.15pre6-Win cl_barrett32_76_gs_4]
[Fri Aug 26 13:22:11 2016]
UID: mattmill30/Lenovo_ThinkPad_T430, found 1 factor for M7508981 from 2^70 to 2^71 [mfakto 0.15pre6-Win cl_barrett32_76_gs_4]
[Tue Sep 06 18:39:01 2016]
UID: mattmill30/Lenovo_ThinkPad_T430, no factor for M7508981 from 2^71 to 2^72 [mfakto 0.15pre6-Win cl_barrett32_76_gs_4][/CODE]

returned:

[CODE]Found 6 lines to process.
Splitting composite factor 1221455278191433598713 into:
* 20333239254737
* 60071849
processing: TF factor 20333239254737 for M7508981 (270-271)
Error code: 40, error text: Factoring result for M7508981 was not needed
processing: TF factor 60071849 for M7508981 (270-271)
Error code: 40, error text: Factoring result for M7508981 was not needed
processing: TF no-factor for M7508981 (271-272)
Error code: 40, error text: TF result for M7508981 was not needed[/CODE]

and only TF^70-71 was recorded.

Because of this bug it isn't possible to know whether an exponent has been consecutively factored. For example, I can't remember whether I completed TF^69-70.

Surely an appropriate solution would be to report under different circumstances:
a) composite factor only, record 'composite factor(s) only from 2^## to 2^##'
b) composite factor and a non-divisible factor, record 'Factor: ########## / TF: 60-61'.

[QUOTE=LaurV;440561]To clarify Madpoo's post, there was a guy in the past (Alex? Axon? Sorry if I don't remember the right name and I confuse him with some honest contributor) who used to report small composite P-1 factors and do lots of P-1 credit, but then George penalized him by reverting the sign of his P-1 credit :smile: (so he still had to do "honest" work to come to zero credit).[/QUOTE]

I don't know if this is related, but the server currently gives no credit for unsuccessful P−1 tests on exponents that already have at least one known factor. It returns error code 40, result "was not needed". It does give credit for successful P−1 tests on such exponents.

This is in contrast to ECM testing on such exponents, which gets credit for all the curves done, whether it is successful or unsuccessful in finding a factor.

[QUOTE=GP2;441870]... the server currently gives no credit for unsuccessful P−1 tests on exponents that already have at least one known factor. It returns error code 40, result "was not needed"... [/QUOTE]

Except that if you check the same unsuccessful P-1 test in using the manual results page, it is accepted (and credited AFAIK). I tried it just recently for [URL="http://www.mersenne.org/report_exponent/?exp_lo=79070707&full=1"]M79070707[/URL]...

[QUOTE=Syntony;441877]Except that if you check the same unsuccessful P-1 test in using the manual results page, it is accepted (and credited AFAIK). I tried it just recently for [URL="http://www.mersenne.org/report_exponent/?exp_lo=79070707&full=1"]M79070707[/URL]...[/QUOTE]

If you use the manual results page, then reporting unsuccessful P−1 tests for exponents that already have a known factor gives "error 40" and result "was not needed", and in your own account's results page (visible at [url]http://www.mersenne.org/results/[/url] ), it shows 0.0000 GHz-Days credit. At least that's my experience. Nevertheless, the B1 and B2 range is entered into the history database and the NF-PM1 line is displayed whenever "Show full details" is selected.

And if you use Primenet, then unsuccessful P−1 tests for exponents that already have a known factor are [I]not[/I] entered into the history database.

[QUOTE=GP2;441905]If you use the manual results page, then reporting unsuccessful P−1 tests for exponents that already have a known factor gives "error 40" and result "was not needed", and in your own account's results page (visible at [URL]http://www.mersenne.org/results/[/URL] ), it shows 0.0000 GHz-Days credit. At least that's my experience. Nevertheless, the B1 and B2 range is entered into the history database and the NF-PM1 line is displayed whenever "Show full details" is selected.

And if you use Primenet, then unsuccessful P−1 tests for exponents that already have a known factor are [I]not[/I] entered into the history database.[/QUOTE]

Yes, you are right, 0.0000 GHz-Days credit, I stand corrected... :redface:

[QUOTE=Syntony;441917]Yes, you are right, 0.0000 GHz-Days credit, I stand corrected... :redface:[/QUOTE]

It's a pity because there are many exponents that have never had any P−1 testing done, namely the ones for which TF found a factor quickly.

In some cases additional factors have been found by ECM or by further TF to higher limits, but it's clear that no P−1 testing has ever been done on such exponents, not even by [URL="http://www.mersenneforum.org/showthread.php?t=19014"]user TJAOI[/URL], and maybe that's because the lack of credit discourages it.

We can be sure that no P−1 testing has been done on such exponents because every factor of M[SUB]p[/SUB] is of the form 2kp + 1, so if a factor was found by ECM or TF then we can solve for k and retrospectively find out whether it would have been possible to find the factor with P−1. I'm looking at small exponents below 0.1M, and for a handful of such factors it turns out that k is very very smooth, so where it took a few hundred ECM curves and several hours to find that factor, it could have been found with P−1 in a few seconds, with B1 sometimes as low as a few M or even a few hundred K. I've been running some tests in the past few days and have found a number of new factors.

Of course P−1 can only find certain types of factors and will miss the rest, so it's not a substitute for ECM or TF, but it can be a useful supplementary method.

Firstly, whilst NF-PM1 lines may be recorded, it doesn't appear to be the case for NF (TF)s.

Secondly, would it therefore be appropriate for users who report compound factors and receive "Factoring result for M7508981 was not needed" for all of a TF range to then submit "no factor from 2^70 to 2^71", because surely compound factors are not a noteworthy factor (and would provide clarify as to which ranges have been TF'd).

As a follow-up, wouldn't it therefore be appropriate for the result submission system to automate this process and return a "processing: TF no-factor for M7508981 (2^70-2^71)"?

Though I don't know whether it's desirable for composite factor ranged to be reported as not containing a factor, PrimeNet accepted:
no factor for M7508981 from 2^62 to 2^63 [mfakto 0.15pre6-Win cl_barrett32_76_gs_4]
no factor for M7508981 from 2^63 to 2^64 [mfakto 0.15pre6-Win cl_barrett32_76_gs_4]
no factor for M7508981 from 2^69 to 2^70 [mfakto 0.15pre6-Win cl_barrett32_76_gs_4]
no factor for M7508981 from 2^70 to 2^71 [mfakto 0.15pre6-Win cl_barrett32_76_gs_4]