[QUOTE=GP2;467589]Also, anyone that contributes to these forums would surely manually report any new finds to PrimeNet, which our mystery person is not doing.[/QUOTE]
OK. I know how to report a result from prime95. And I know how to report a result from mfactc. But, a brief search did not reveal the trivially simple manual report form, to report a factor, when I know nothing about the method used for factorization and I do not want credit for a find that isn't mine?

If there is no obvious way to report, then don't expect a report.
7051863324605499849483215166120814618029888281331456062662199692938569

[QUOTE=rcv;468471]If there is no obvious way to report, then don't expect a report.
7051863324605499849483215166120814618029888281331456062662199692938569[/QUOTE]

I added it as anonymous: [url]http://mersenne.org/M1549[/url]

Just log out of mersenne.org if you do not want the credit and then "Manuel Testing" - "Results" and paste in:

[B]M1549 has a factor: 7051863324605499849483215166120814618029888281331456062662199692938569[/B]

[QUOTE=Prime95;468464]Those are in the database -- reported by you.

Are you having mprime report these results to the server? If so, PRP tests with few factors are getting properly recorded (the ones that have the result split across 2 lines are not recorded properly).[/QUOTE]

No, those just were pasted into the [URL="https://mersenne.org/manual_result/"]Manual Results[/URL] form.

So it's recording the one-line results correctly, even though it returns a bogus error code 40? OK, I guess I could pre-select only exponents that have a short list of factors, which will generate only one-line results, unless it's better just to wait for 29.4.

[QUOTE=ATH;468472]I added it as anonymous: [url]http://mersenne.org/M1549[/url][/QUOTE]

Maybe [M]1471[/M] and [M]1489[/M] could be changed to -Anonymous- too in the database, it didn't occur to me that you could report them that way. No need to adjust the credit, since they received 0.0000 due to the assumption of an absurdly low B1.

[QUOTE=GP2;468479]No, those just were pasted into the [URL="https://mersenne.org/manual_result/"]Manual Results[/URL] form.

So it's recording the one-line results correctly, even though it returns a bogus error code 40? OK, I guess I could pre-select only exponents that have a short list of factors, which will generate only one-line results, unless it's better just to wait for 29.4.[/QUOTE]

The manual results web page handles both the one and two line results.

[QUOTE=Prime95;468464]Are you having mprime report these results to the server? If so, PRP tests with few factors are getting properly recorded (the ones that have the result split across 2 lines are not recorded properly).[/QUOTE]

[QUOTE=Prime95;468486]The manual results web page handles both the one and two line results.[/QUOTE]

So, this form:

[B]Mnnnnnnn/fffffffff/fffffff/fffff is not prime[/B]

can be either reported automatically or manually.


Whereas the form

[B]Mnnnnnnn/known_factors is not prime[/B]
[B]Known factors used for PRP test were: fffffffff,fffffff,ffffffffffffffffffffffffff[/B]

can only be reported manually.


Empirically, it turns out that the criterion for mprime using one form or the other is not the number of factors, but the total length of the factor string (including commas, if any). If the length is 40 or more, then mprime will report the result using the two-line "known factors" form.

For example, in the following worktodo line:

PRP=N/A,1,2,6166471,-1,"1039038030559,51421412360713,61664711"

the part between double quotes has length 37, so mprime will report it using the simple one-line form.

So you can segregate all the lines with long (40+) factor strings into a separate work directory that has UsePrimenet=0 in the prime.txt file, and leave all the rest in the main work directory that has UsePrimenet=1.

Typically, in the 6M range where the first-time PRP wavefront is at, less than 10 percent of the exponents have long (length = 40+) factor strings, so only that small fraction of results needs to be manually reported.

[QUOTE=GP2;468692]Empirically, it turns out that the criterion for mprime using one form or the other is not the number of factors, but the total length of the factor string (including commas, if any). If the length is 40 or more, then mprime will report the result using the two-line "known factors" form.[/QUOTE]

So, the server could be modified already to automatic assign exponents to workers requesting PRP work type, as long as a temporary restriction was put in place, to assign an exponent only if its factor string has length less than 40.

mersenne.ca PRP sometimes generates incomplete factor strings
 

When getting PRP assignments from mersenne.ca, the PRP= lines generated for the worktodo file sometimes have missing factors. This is fairly rare, but does happen.

As I mentioned earlier, I am now doing automated reporting of PRP results to mersenne.org, after first filtering out any exponents with factor strings of length 40 or more (which produce the two-line "known_factors" output that requires manual results reporting).

In my prime.log files, I found the following lines:

No CPU credit given for test of already factored M6187451
No CPU credit given for test of already factored M6176983
No CPU credit given for test of already factored M6177151
No CPU credit given for test of already factored M6168247

In my results.txt files, I found:

M6187451/497483435303/51974588401 is not prime.
M6176983/12069824783/395326913 is not prime.
M6177151/149279563697911 is not prime.
M6168247/80187211001 is not prime.

In each case, there is a factor missing.

[M]M6187451[/M] has three factors, the other one is 16042392306210401 (discovered 2014-10-15)
[M]M6176983[/M] has three factors, the other one is 23418769077829996889 (discovered 2017-09-14)
[M]M6177151[/M] has two factors, the other one is 10702995701931497 (discovered 2014-09-12)
[M]M6168247[/M] has two factors, the other one is 19799494695535703 (discovered 2014-11-05)

I was using PRP= lines assigned through mersenne.ca, so it must have been mersenne.ca that generated those lines with missing factors.

The factor discovered 2017-09-14 is understandable, most likely it was discovered after I got the assignment but before I returned the result. However the cases involving factors from 2014 are harder to explain.

If you go to [url]http://www.mersenne.ca/exponent/6187451[/url] it shows all three factors, but the [URL="http://www.mersenne.ca/prp.php?show=2&min_exponent=6187451&max_exponent=6187451"]PRP data[/URL] shows only two factors.

If you go to [url]http://www.mersenne.ca/exponent/6177151[/url] it shows both factors, but the [URL="http://www.mersenne.ca/prp.php?show=2&min_exponent=6177151&max_exponent=6177151"]PRP data[/URL] shows only one factor.

If you go to [url]http://www.mersenne.ca/exponent/6168247[/url] it shows both factors, but the [URL="http://www.mersenne.ca/prp.php?show=2&min_exponent=6168247&max_exponent=6168247"]PRP data[/URL] shows only one factor.

This would appear to confirm that the list of known factors maintained by the PRP sub-section of mersenne.ca is not always in sync with the main list of known factors, and therefore the PRP= lines generated are sometimes missing factors. Any PRP test done with missing factors is not useful.

Fortunately, this situation seems to be fairly rare, maybe one to two percent of the exponents in the 6.1M range, based on a small sample size (three cases out of about 200 so far, not counting M6176983 because its additional factor was very recently discovered).

This might be a longstanding problem, so it is possible that the coverage for exponents below 6.1M might not be as complete as [URL="http://www.mersenne.ca/prp.php?assigned_distribution=1"]the table[/URL] would indicate.

[QUOTE=GP2;468800]When getting PRP assignments from mersenne.ca, the PRP= lines generated for the worktodo file sometimes have missing factors. This is fairly rare, but does happen... Fortunately, this situation seems to be fairly rare, maybe one to two percent of the exponents in the 6.1M range... This might be a longstanding problem, so it is possible that the coverage for exponents below 6.1M might not be as complete as [URL="http://www.mersenne.ca/prp.php?assigned_distribution=1"]the table[/URL] would indicate.[/QUOTE]Thank you for discovering and reporting this.
The PRP table is supposed to be updated when new factors are reported, but clearly there was a problem around Q4-2014 because I found quite a few exponents with mismatches between the PRP list cofactors and the master list of known factors. I didn't count them exactly, but it looks like around 1% as you said, which means as I write this there are now nearly 3000 new small PRP assignments (up to the 6M wavefront).

This shouldn't be an ongoing problem, but to be safe I've added a check to the nightly cronjob to check for missing known factors and reset the PRP list as appropriate.

I submitted 240 results for the first million range, but after accepting the results, I see them again as available.

[QUOTE=alpertron;468837]I submitted 240 results for the first million range, but after accepting the results, I see them again as available.[/QUOTE]My fault, fixed now. I also resubmitted your results and they've been accepted (properly this time).