WhattheTF

[GP2]

Originally Posted by mattmill30

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

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 ECM Report 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.

[mattmill30]

Originally Posted by Prime95

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?

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:

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

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 M60160447 factor entry (by providing the TF bit-range) and received the same error for the following results:

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

So record of the completeness of the ^71-72 bit-range for that factor is also lost.

[Prime95]

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

[mattmill30]

These results returned the following errors:

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

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

[GP2]

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

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

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

[ixfd64]

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?

[Mark Rose]

Originally Posted by ixfd64

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?

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.

[chalsall]

Originally Posted by Mark Rose

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

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.

[Mark Rose]

Originally Posted by chalsall

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.

Good point.

[science_man_88]

Originally Posted by Mark Rose

Good point.

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.

[LaurV]

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).