I assume that small composites are in the database because the script that produced them did an upload, and that the next upload will factor that small composite, so doing it yourself is a complete waste of time.

(it looks as if most small composites come from aliquot sequences at the moment; the ones that come from someone casually doing 12345^n+3 are really not worth factoring automatically since if they were actually interested in the result they'd have done the factoring)

[QUOTE=fivemack;308639]I assume that small composites are in the database because the script that produced them did an upload, and that the next upload will factor that small composite, so doing it yourself is a complete waste of time.

(it looks as if most small composites come from aliquot sequences at the moment; the ones that come from someone casually doing 12345^n+3 are really not worth factoring automatically since if they were actually interested in the result they'd have done the factoring)[/QUOTE]
Why upload numbers without factors if you intend to factor them immediately?

[QUOTE=lorgix;308644]Why upload numbers without factors if you intend to factor them immediately?[/QUOTE]

To keep things like dubslow's aliquot-sequence-status database up to date, and as a backup in case the hamsters escape from your CPU and run riot across your filesystem. I have a tool that I run each morning which lists the factorisations in aliquot sequences that the 30 factoring scripts on my largish machine found overnight, and I upload that.

[QUOTE=fivemack;308645]To keep things like dubslow's aliquot-sequence-status database up to date, and as a backup in case the hamsters escape from your CPU and run riot across your filesystem. I have a tool that I run each morning which lists the factorisations in aliquot sequences that the 30 factoring scripts on my largish machine found overnight, and I upload that.[/QUOTE]
OK, that makes sense.

Maybe it'd be interesting to only get composites that have been in the db for a certain time.

[QUOTE=lorgix;308647]OK, that makes sense.

Maybe it'd be interesting to only get composites that have been in the db for a certain time.[/QUOTE]

That makes automatic progress down aliquot sequences rather slow; of course, there's also little point in finding the small algebraic factors of something like

(1171^252-1)/1170

by ECM either.

I think I would be inclined to switch effort away from factoring 'composites from the DB' and towards 'composites at the end of aliquot sequences which have been untouched for a while'; I notice that the missing-composites at the moment include a whole load of p^10-1 p=31680000... and I can't help thinking that people interested in the factors of such numbers might as well factor them themselves. Likewise there's 2^a+2^b+1 for quite a range of a,b; I agree that optimising SNFS for such numbers can be vaguely non-trivial if a/b is not very near a simple rational but I'm not sure that doing that optimisation is the job for a general factorisation database.

It would be really helpful if the missing-composites list labelled numbers from aliquot sequences with the first number in the sequence; at the moment I recognise them because the great^n-parent has a factor that looks like an aliquot-sequence driver.

[QUOTE=fivemack;308651]
I think I would be inclined to switch effort away from factoring 'composites from the DB' and towards 'composites at the end of aliquot sequences which have been untouched for a while'[/QUOTE]
and are not reserved. We fully agree with it. (the addition is because I have reservations which I did not "touch" for a while, and other which I "touched" but not reported, I won't be happy if someone - elves excluded :razz: for sequences intentionally left in the elves range - starts factoring them...

@Syd: Not sure if you catch entries from other threads - some of the following is mentioned elsewhere.

1) ID 1100000000426724016 (1894 digits) has tied up one of the workers for over a week processing its primality certificate.

2) ID 1100000000518654034 (583 digits) still shows up in the probable primes listing although it has a processed certificate on file (as of July 1, 2012, 6:47 am).

3) ID 1100000000489773674 (638 digits) still shows up in the probable primes listing although it has a processed certificate on file (as of February 16, 2012, 1:56 pm).

The listing of #2 and #3 does not affect any operations that I can tell. They are omitted from Primo downloads.

OTOH, #1 appears to be tying up a worker.

Thanks for all,
Ed

I see ID 1100000000426724016 (1894 digits) has been resolved. I noticed it fell off the worker list without certification, but I left it alone for the last couple days. I'm glad to see someone else has gotten it certified.

I'm "playing around" with my AliWin project again and have my setup on a virtual WinXP machine on my Fedora Desktop. I've always had a long delay getting the .elf files from the db using AliWin, but this setup isn't retrieving them at all. I have connectivity with the Internet and factordb resolves and connects via wget, but it doesn't receive the file. I've built into my program a give-up element at two minutes, in case of a hang. It really shouldn't take over that to retrieve an .elf.

Here's the console session:
[code]
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = c:/progra~1/wget/etc/wgetrc
--2012-09-14 21:12:23-- http://factordb.com/elf.php?seq=4788&type=1
Resolving factordb.com|176.9.39.214|:80... connected.
HTTP request sent, awaiting response...
[/code]Two minutes later, the window closes...

Any ideas?

[QUOTE=EdH;311674]I'm "playing around" with my AliWin project again and have my setup on a virtual WinXP machine on my Fedora Desktop. I've always had a long delay getting the .elf files from the db using AliWin, but this setup isn't retrieving them at all. I have connectivity with the Internet and factordb resolves and connects via wget, but it doesn't receive the file. I've built into my program a give-up element at two minutes, in case of a hang. It really shouldn't take over that to retrieve an .elf.

Here's the console session:
[code]
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = c:/progra~1/wget/etc/wgetrc
--2012-09-14 21:12:23-- http://factordb.com/elf.php?seq=4788&type=1
Resolving factordb.com|176.9.39.214|:80... connected.
HTTP request sent, awaiting response...
[/code]Two minutes later, the window closes...

Any ideas?[/QUOTE]Maybe try with a smaller one. I just tried downloading from a browser session and it took something >4 minutes to bring up the save dialog (sorry, I forgot I was waiting on it and went away for a minute. so I can't be more precise than that).

I do know that when Syd switched to the new server, my downloads started taking very much longer than before....

Here's a short one that took ~30 seconds for the save dialog to show up:[code]911484 401. sz 123 2^2 * 3 * 10037[/code]

Are you using `--cache=off` with wget?

[QUOTE=Batalov;309167][QUOTE=Dubslow;309161]
Edit: Batalov (or someone else), could you please tell me how to use wget to retrieve elf files from the db?[/QUOTE][CODE]set i=158592
wget --cache=off "http://factordb.com/elf.php?seq=$i&type=1" -O alq_$i.elf

foreach i (`cat myList`)
wget --cache=off "http://factordb.com/elf.php?seq=$i&type=1" -O alq_$i.elf
end
[/CODE][/QUOTE]