[QUOTE=yoyo;487028]The hanging C50 is fixed now.[/QUOTE]
Just noticed this too!
The C98 is still there, but the factor <70 worker is running and that's what important.

[QUOTE=sean;486985]I think there are others higher up as well. My efforts to sweep downwards from 120 digit numbers also periodically hit them. Unfortunately, I haven't been able to isolate any of the higher ones to exact ids.[/QUOTE]
From your query you should be able to see which composite size it has.

[QUOTE=DukeBG;487029]
The C98 is still there, but the factor <70 worker is running and that's what important.[/QUOTE]

A complete check is running now. So, I assume this will be fixed in the next hours.

And the C98 has been fixed. Many thanks to whoever did it.

Chris

There's an erroneous C50 causing problems. I've updated my script to factor from 51 digits upwards as a temporary measure.

Chris

[I]I added 23 certificates while I was logged in. The server handeled these as uploaded by "Anonymous".[/I]
[I]I´m a bit confused...
[/I]

[QUOTE=chris2be8;490433]There's an erroneous C50 causing problems. I've updated my script to factor from 51 digits upwards as a temporary measure.

Chris[/QUOTE]




The C50 has been fixed. :smile:

[url]http://factordb.com/index.php?id=1100000001046468738[/url]
This number ((2^692-1)*5197#+1)/5547257/231841261 is NOT a PRP. Not sure why it shows "PRP base 2~255" on the page.

[QUOTE=wpolly;492800][url]http://factordb.com/index.php?id=1100000001046468738[/url]
This number ((2^692-1)*5197#+1)/5547257/231841261 is NOT a PRP. Not sure why it shows "PRP base 2~255" on the page.[/QUOTE]
Because the actual expression stored in factor db is "((2^692-1)*692##+1)/1286083057971077" which when passed to PFGW interprets as "((2^692-1)*692#+1)/1286083057971077", which after integer division, does yield a PRP.
This is a known issue. Any PRP with ## symbol in the expression is bogus.

EDIT:- Here is how that actual PRP looks like: [url]http://factordb.com/index.php?id=1100000001161045736[/url]

[URL="http://factordb.com/index.php?id=1100000000938546746"]http://factordb.com/index.php?id=1100000000938546746[/URL]
[URL="http://factordb.com/index.php?id=1100000000900935563"]http://factordb.com/index.php?id=1100000000900935563[/URL]

OK, so they are actually primes, and the correct version of them also exists somewhere in the database, but for some reason they are not merged.... Is it possible to manually remove these two glitched primes from the list of composites(or from the database altogether)?

Not very important, but they're pretty irritating.....

aliquot sequence 2700984 is broken at index 2172. The correct term is 18329938571785935602136356 and it quickly moves downwards until it merges with 2623402 at index 2312.