On the [STRIKE]"active assignments"[/STRIKE] [I]"Account Assignment Details"[/I] page, there is a digit on top of the page that was not there previoulsly (see picture). The page functions otherwise normally, as far as I can tell.

[QUOTE=kruoli;548150]On the "[url=https://www.mersenne.org/workload/]Account Assignment Details[/url]" page, there is a digit on top of the page that was not there previoulsly (see picture).[/QUOTE][I]Three shall be the number thou shalt count, and the number of the counting shall be three.[/I]

Somehow I left a hardcoded "3" on the page (presumably a clumsy-fisted typo). I have removed it.

[QUOTE=James Heinrich;548152][I]Three shall be the number thou shalt count, and the number of the counting shall be three.[/I]

Somehow I left a hardcoded "3" on the page (presumably a clumsy-fisted typo). I have removed it.[/QUOTE]

I think it was the ghost of Nikola Tesla that did it.

Odd entries on Mersenne primes
 

[URL]https://www.mersenne.org/report_exponent/?exp_lo=2&exp_hi=&full=1[/URL] has what I believe is a bogus P-1 result attached.
The bounds are absurdly high for M(2)=3.

M(3) has 3 of them.
M(5) has 1.
M(7) has 2.
M(11) has 1.
M(61) has 1. (stopped looking here) There are probably more.

82589933 looks ok.
216091 has a composite result.

George or Aaron will have to clean up the database of any results that shouldn't be there (if they make note of which and email me I'll purge them from mersenne.ca too).
I'm not sure how those results got recorded, whether via the Manual Results form or API, but I have adjusted the manual form to block further results for known Mersenne Primes.

Prp cofactor testing page shows the non-censored residue when a number already has factor(s). I know there is res2048, security-code and shift and interim residue sending... But even if these prevents fakery, the page still shouldn't show the uncensored hex afaik.(?) examples:
[URL]https://www.mersenne.org/m10005683[/URL]
[URL]https://www.mersenne.org/m10432249[/URL]


plus extra, weird result
[URL]https://www.mersenne.org/m37811[/URL] the top ("type 5") result is the correct one.

Can one still reserve CAT1 exponents for TF ?
 

Two weeks ago a user reserved some exponents for manual TF work, from the "Newer Milestones" thread :[QUOTE=retina;549327]lolapus also has 499 TF assignments at 52M

[url]https://www.mersenne.org/assignments/?exp_lo=52000000&exp_hi=53000000&execm=1&exdchk=1&exfirst=1&exp1=1[/url]

No expiry date. No ETA.

Why does the server allow these?[/QUOTE]Problem is indeed that the server assigned or accepted to assign some 500 exponents for manual TF work that, at that moment, where already in CAT 1 for double checking. Shouldn't at least the rules for that category be respected (no manual testing...) If only that user would factor those exponents quickly, but as far as we can see there is not much work done on those exponents (24 done in two weeks means it will take 40 weeks : more than nine months.)

Jacob

[QUOTE=S485122;549917]Two weeks ago a user reserved some exponents for manual TF work, [/QUOTE]I think that I will start 'poaching' those as when I can get them done. They have been taken 1 bit beyond the GPU72 bit level. So, there is no need to do more TF on them. I will post which ones I am working on in a thread to be created in the
[URL="https://www.mersenneforum.org/forumdisplay.php?f=30"]Marin's Mersenne-aries[/URL] forum. Others who currently are working routinely in the DC Cat 1 and 0 range are welcome to join me (provided you post which expos your are taking.)

There are 808 exponents that need testing below 53000000. Of those 335 are assigned to DC. But, 468 are still tied up by unneeded TF assignments. Because of this, those that are working in the tail end of the DC are going to have to wait to help clear 53000000.

Why is one joker allowed to hold things like this?

[QUOTE=Uncwilly;550357]Why is one joker allowed to hold things like this?[/QUOTE]

Indeed. A similar situation exists in [URL="https://www.mersenne.org/assignments/?exp_lo=93000000&exp_hi=94000000&exdchk=1"]93M[/URL]...

That is the same user. They have ZERO LL and PRP results ever.

I could not find a way to search for their TF results. But, they need to have all their TF manual assignments voided and check their IP and see if it matches any previously known troublemakers.