[QUOTE=Mini-Geek;239519]Unless I'm missing it, the DB still doesn't have info on aliquot sequence mergings or telling you what aliquot sequence a number is a part of (presumably, it's the same for all sequences, I'm just pointing out aliquot in particular). When will this be reimplemented? Also, is the old DB still up so we can check on that in the mean time?[/QUOTE]Sorry, I thought someone would respond to this.

No, you're not missing it.

Only Syd knows for sure.

No, when he cut over to the new one, the old one went the way of all things obsolete....

[SIZE="1"]What's a snappy answer to what happens to old DBs?

Hmmm....how about: they don't die, they denormalize?[/SIZE]

Possible "input" bug
 

This may be fixed but several weeks ago I encountered a problem with inputting factors.

On the "Search" page after requesting a "Factorize!" there is the ability to input "Report factors". I've noticed if one would add a CR (carriage return) after the last factor none of the inputs would be processed. This includes one factor or multiple ones (one per line). BTW, the default format is left at "Auto detect".

I've noticed this too. Selecting Multiple factors per line, base 10 always seems to process what I throw at it. Perhaps that should be the default.

Just out of curiosity, I explored whether the db held all the composites formed by partial factors of completed composites. My single experiment proved that it doesn't.

For example, I used a 16 digit prime and an 80 digit prime from an aliquot sequence index to form a 96 digit composite:
[code]
8459436595715687 * 14653287880309161044589092842674292343052930286602206880394528560151656381924491

= 123958559742244464497540221271690320401845288752589069609797736575128499708746594193158538190317
[/code]I then asked the db for info on the 96 digit composite. The db responded with no further info, other than the composite I supplied. I then supplied the 16 digit factor and the db completed the factorization. Now, if I enter the 96 digit composite, the db recognizes it and supplies its factors.

OK, I've taken a long way to my question, but here it is:

Would there be practical value in having the db form new composites from all the combinations of prime factors, complete with those factors?

In case all this wasn't clear enough, here's a scaled down version (assume composites [7843, 253, 341, 713] represent large numbers that are not yet in the db and the primes [11, 23, 31] are also large primes):
[code]
7843 = 11 * 23 * 31
11 * 23 = 253
11 * 31 = 341
23 * 31 = 713
[/code]Would it be advantageous to supply the db (or have it create) the composites (253, 341, 713) along with the factorization of the original (7843)?

These composites would then be recognized by the db, if they turn up again. Instead of factoring these composites, the primes would already be known.

I think the probability that doing that would save any time at all in the long run is somewhere from 0 to very low. You're just way too unlikely to come across large numbers (say, >10^60) that are already factored, especially from its factors being parts of another. I'd think that for the most part, the previously-done numbers would usually have to be 3+ way SIQS/GNFS splits to be useful (since otherwise, most of the time, you can rarely combine factors in a way that would make a difficult-to-factor number in their own right). Just all in all: not worth the trouble IMHO.

[QUOTE=EdH;239838]Would there be practical value in having the db form new composites from all the combinations of prime factors, complete with those factors?[/QUOTE]

There are hundreds of millions of primes in the database, call this P. Thus there are 2^P - P - 1 composites that could be formed in this way. This is too large to store in the universe, let alone in the DB.

If we look at just the semiprimes, there are P(P-1)/2 or tens of trillions, so even this is too large for the database (petabytes).

On the other hand, it would be just possible to test a given composite against all (smaller) primes in the database. If each test takes about a microsecond this would take a few minutes: too slow to do from the web page, probably, but could be done from the server.

It may be too much for the database to learn the factorizations of all cofactors of a composite number N. But I think it needs to know some of the more important ones. For example, if the database knows the factorization of N = a^n-1, the database should also know the factorizations of (a^n-1)/(a-1), Phi_n(a), and the Aurifeuillian factors of N. At least, this is how I enter my factorization data to the database.

I agree, it would be nice if the database knew about Aurifeuillian factors.

Downloading of .elf files for aliquot sequences from the DB seems to have broken at about 4am Pacific time. Clicking on the 'Download .elf file' link now gives a page with term 0 of the sequence followed by something like:

delete from orig where a=9772 - Table 'fneu.orig' doesn't exist

Wow... 16 workers connected.

[QUOTE=bchaffin;240122]Downloading of .elf files for aliquot sequences from the DB seems to have broken at about 4am Pacific time. Clicking on the 'Download .elf file' link now gives a page with term 0 of the sequence followed by something like:

delete from orig where a=9772 - Table 'fneu.orig' doesn't exist[/QUOTE]Not good. Looks like the server may have dropped a table. We'll have to wait for Syd to fix this locally....