[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: