I've not had any problems. And I'm running a script to add algebraic factors to numbers in factordb so I've been doing about 1 access per second so would notice any outage.

Chris

I saw this already mentioned in another thread, numbers of the form k*2^n+1 are called Cullen numbers in the "More information - Listed as or is factor of listed special form" tab on factordb.

Example: [URL="http://factordb.com/index.php?query=2%5E700*3%2B1"]2^700*3+1[/URL] (click on more information)

The respective -1 form has --- none --- in that field.

I tried for a while to transform 3*2^700+1 to Cullen form, but got stuck at 48 * 256^87 + 1 ;)

[QUOTE=bur;575874]I saw this already mentioned in another thread, numbers of the form k*2^n+1 are called Cullen numbers in the "More information - Listed as or is factor of listed special form" tab on factordb.

Example: [URL="http://factordb.com/index.php?query=2%5E700*3%2B1"]2^700*3+1[/URL] (click on more information)

The respective -1 form has --- none --- in that field.

I tried for a while to transform 3*2^700+1 to Cullen form, but got stuck at 48 * 256^87 + 1 ;)[/QUOTE]
That is definitely not a Cullen number. Please rename that category to "Proth numbers" or restrict it to numbers where [I]k[/I]==[I]n[/I], the actual definition of Cullen numbers, in order to match the Woodall category.

Yep, Proth is altogether missing from factordb, these numbers are consistently called Cullen at the site. It would probably be sufficient to exchange one string for the other.

Somebody is spamming FactorDB by adding a bunch of random small-ish numbers, differing by appending digits. Keep an eye out.

[URL="http://factordb.com/index.php?id=1100000000801122579"](9^4451+7^4451)/16[/URL] has been certificated to be prime (there is a [URL="http://factordb.com/cert.php?id=1100000000801122579"]certificate[/URL] for this number in factordb), but the status of this number in factordb is still "PRP", not "P"

The recent crop of "unconfirmed" numbers is mostly made up of products of numbers of special forms (i.e. they have simple algebraic factors), but FactorDB is not just simply applying them. In fact, on some numbers that have too many factors to submit in one request (which is a problem in and of itself; who's submitting these massive products?), it's refused my repeated attempts to divide by some of the algebraic factors in favor of a "piece-by-piece" automated approach of picking off smaller factors. Sometimes, dividing by a different set of algebraic factors seems to [I]undo[/I] the previous division, leaving me with a [I]larger[/I] cofactor. It's very frustrating. Please make FactorDB attempt dividing by algebraic factors immediately upon discovering them.

The link [URL="http://factordb.com/help.php?page=1"]http://factordb.com/help.php?page=1[/URL] is broken.

atm, a lot of composite below 70digits (40 000 atm) have been posted on the db.
I use this simple script from long ago to grab composite, factor them then sending them back to the db.
This is a perl/python script that require [STRIKE]ecm and[/STRIKE] yafu.