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]