You're not making much sense.

Do the translation before you post. Hopefully that will help.

If you're saying that you're adding all prime numbers, let's get some perspective;

Right now the db contains about 4.6*10^8 numbers, which is roughly equal to the number of primes [B]9 digits or smaller[/B].

Edit: I tried... Wont bother with this anymore.

[QUOTE=cmd;262249]we do not understand, can someone "explain|clarify"
where we make mistakes in [B]your[/B] approach ?
[/QUOTE]

Hello cmd, the reason you are seeing this message is because your activities are putting too many new numbers into the factordb. This limit has been put in place as a nice way of asking people to not flood the factordb with new numbers.

My question is, what is your goal? Are you trying to factor numbers of a certain form? Are you trying to find numbers with a certain property? If you are trying to factor numbers of a special form, I'd recommend using either yafu or msieve. They are both excellent programs. This way, you can continue your mathematical activities without putting a burden on the factordb. If you need help running/using either yafu or msieve, you can open a new thread where we can answer your questions. In any case, I'd like to ask you to stop using the factordb like you are currently using it.

[CODE]mysql> select digits, count(digits) as n from C where digits<100 group by digits having n>10;[/CODE]

This might be an interesting stat. Should a link to a Small Composites [strike]Status[/strike] Summary page be available which is updated periodically?

[QUOTE=RichD;262277][CODE]mysql> select digits, count(digits) as n from C where digits<100 group by digits having n>10;[/CODE]

This might be an interesting stat. Should a link to a Small Composites [strike]Status[/strike] Summary page be available which is updated periodically?[/QUOTE]

Just as a quick dirty hack:
[url]http://factordb.com/stat_1.php[/url]
The query is fast, there's no need to cache it. Btw, left the n>10 out :smile:

[QUOTE=Syd;262291]Just as a quick dirty hack:
[url]http://factordb.com/stat_1.php[/url]
The query is fast, there's no need to cache it. Btw, left the n>10 out :smile:[/QUOTE][quote=factorDB][B]SIZE COUNT[/B]
60 1,195
61 1,286
62 1,326
63 1,308 [/quote]Nice to see that the 60-digit stuff has been (mostly) cleared....

[QUOTE=kar_bon;262234]I'm using the factoring-script DByafu.pl from [url=http://www.mersenneforum.org/showpost.php?p=230762&postcount=894]here[/url] to help, getting rid of those small numbers.[/QUOTE]I'm using a manual upload method since then I don't have to install anything; and if I use a computer that I don't have regular access to, I can just blast through a few numbers when I get a chance.

[QUOTE=cmd;262295]?19[/QUOTE]Why 19 digirts?

Becuase [I]someone[/I] :whistle: is loading [B]thousands[/B] of numbers into the DB. As the DB workers run ECM curves, those small numbers are the leftovers that have to factored....

[QUOTE=lorgix;262031]Would it be realistic, btw, to do some basic ecm/p+1/p-1 automatically? Like TF.[/QUOTE]

Will that become reality?

Btw, are all scan levels necessary? The first is ridiculously fast. And ECM to low bounds is exhausted with only a few curves, I think.

JpGraph Error: 25068
 

Looking at HP[SUB]10[/SUB](49) I clicked 'Show huge graph'.

That brought me to [URL]http://factordb.com/aliquot.php?type=10&aq=7&big=1[/URL]

And this image was displayed;

Seems like someone just put a few thousand RSA-1024 into the db...

Why is there interest in finding the complete factorization of 136^35+n for n odd 1 to one million, and 2^1024+n, n 1 to 1000? It appears both of these sets have been dumped into factordb this week.