Factoring small composites

[EdH]

Originally Posted by warachwe

This is what I guess was happened.
On 15^th November, someone enter a number of form bⁿ with b<20000 and n<1000 or somewhere around that ballpark. Since then DB slowly determined whether each number is prime, and while doing so produced a factor which is product of small prime. When that factor is more than 19 digit it won't get factor more. (I think the DB automatically does this for all unknown number less than 20,000 digits). This is where those small composite came from.

The problem is there might be up to 10^7 unknown number waiting in queue, according to Distribution of numbers by digits. Those will continue to produce small composite for quite a while.

2.2M <70 when I checked a few minutes ago. Why would the db not pull out p1-p10 primes first if it was breaking down larger composites? Almost all of these are made up of <10 digit primes.

Originally Posted by penlu

I can't get enough numbers to run into the page request limit. Instead I've been running into the "IDs created" limit. Submitting a factorization of a number into a product of many small (< 10000) primes seems to create many IDs; I don't understand why.

Any time a "never before seen" number arrives, it is added to the db and generates a new ID. It does seem odd that many of these small composites are composed of primes not already known. I would think this would eventually not be the case, unless the db handles small primes in a different manner from others. But, the IDs for primes <19 are the prime itself. Perhaps these primes are not kept which forces a new generation flag every time it shows up.

On a somewhat related issue, can anyone untar the .bz2 files generated on the Downloads page? I tried List of 1.000 randomly chosen, small composite numbers and I can't open the file with anything. I just get errors.

Similarly, can several factorizations be uploaded at once instead of individually?

[kruoli]

The .bz2 file is not in tar format. It is pure bzip2. 7-zip opens it just fine!

The report page enables you to upload multiple things at once; I'm not quite sure about the format. I guess something like number = factor1 * ... * factorN, one number per line?

[EdH]

Originally Posted by kruoli

The .bz2 file is not in tar format. It is pure bzip2. 7-zip opens it just fine!

The report page enables you to upload multiple things at once; I'm not quite sure about the format. I guess something like number = factor1 * ... * factorN, one number per line?

Well, that's embarrassing! It just so happens all my Ubuntu machines open it fine (why didn't I try any?). My main (Fedora) machine doesn't seem to have any 7-zip program. More study is needed.

As to the report, I haven't tried a multiple line upload yet, but I hope to soon.

Thanks!

[chris2be8]

There have been a load of a few thousand digit numbers added to factordb recently. When factordb tries to factor them it runs ECM, which often finds a composite factor which is the product of most of the smallish factors of the number. That's probably the source of most of the small numbers with many factors.

And the reason why there are over 121000 PRPs under 3000 digits!

Try picking a few and clicking "More information" to see what it's a factor of and following the chain. That should show you where stuff is being added now.

Chris

[penlu]

Originally Posted by EdH

As to the report, I haven't tried a multiple line upload yet, but I hope to soon.

This is how I upload my results, but I advise not to do this because you might create many new IDs -- I set my stuff to upload only the largest factor found.

I realize this probably increases the load on factordb since for small composites the cofactor is often under the 19-digit autofactor threshold. But it seems to result in a higher clearance rate. The incentive is a little perverse?

[EdH]

Originally Posted by chris2be8

There have been a load of a few thousand digit numbers added to factordb recently. When factordb tries to factor them it runs ECM, which often finds a composite factor which is the product of most of the smallish factors of the number. That's probably the source of most of the small numbers with many factors.

And the reason why there are over 121000 PRPs under 3000 digits!

Try picking a few and clicking "More information" to see what it's a factor of and following the chain. That should show you where stuff is being added now.

Chris

At least the explanations provide an acceptable reason for the huge inpouring. The PRPs I hadn't noticed! Might be time to shift in that direction for a while. I'll have to think about that. I had a set of scripts to work through a range across several machines, but I'd have to figure out which one was the server and how I ran them. I think I had an RPi acting as server.

Originally Posted by penlu

This is how I upload my results, but I advise not to do this because you might create many new IDs -- I set my stuff to upload only the largest factor found.

I realize this probably increases the load on factordb since for small composites the cofactor is often under the 19-digit autofactor threshold. But it seems to result in a higher clearance rate. The incentive is a little perverse?

I used to do the same - only return the largest prime. But, currently I'm sending the whole set of found factors back. I did just hit the limit, though, so I might have to rework my scripts to only the largest again.

I'm also running Colab sessions and don't worry about them because they are only single threaded and unique IP'ed. All of my scripts presently do the full circle of retrieve composite - factor - return results - repeat. But, I plan to look into retrieving several, factoring all and returning all at once. I'm not sure there's a method for larger composites, though. They may have to be retrieved one at a time if you want randomness.

[chris2be8]

Originally Posted by EdH

I plan to look into retrieving several, factoring all and returning all at once.

That would reduce the number of page requests per hour, but increase the risk of a collision. I'd only recommend it working well below 70 digits, in a range no one else is working on. And keep the number requested fairly small, no more that 10.

But several Colab sessions working at once sounds very nice. Thank you.

Chris

[EdH]

Originally Posted by chris2be8

That would reduce the number of page requests per hour, but increase the risk of a collision. I'd only recommend it working well below 70 digits, in a range no one else is working on. And keep the number requested fairly small, no more that 10.

But several Colab sessions working at once sounds very nice. Thank you.

Chris

Yeah, I've been shying away from the bulk runs for the reason you gave.

But, I have added a Colab PARI/GP thread, based on the earlier posted script* to the forum at:

How I Create a Colab Session That Factors factordb Small Composites with PARI/GP

I have some of these running with larger "totalrun" values. Being single-threaded, they don't seem to be bumping the limits. But, I added number checking to (hopefully) alleviate any such overruns.

*If anyone is running the earlier posted (in this thread) script, they should copy it again. I found and fixed a bug in the original script and edited it in the original post.

[EdH]

I factored just over 12k small primes out of the digit sizes for 92 through 97 so far today. Despite that 12k composites were removed, the region GREW by nearly 3k!

However, <91 briefly looks better. . .

[richs]

I ran another i3 core on the C28's yesterday and factored about 12k also.

[richs]

Restarted another i3 core on C28's.