No prp < 300 Worker
 

The small prp worker hasn't been active for a couple days.

Is there a way to get an .elf file without causing the db to do an entire check of all the existing entries prior to supplying it? Or, possibly an .elf file of only the last line, since Aliqueit can work from there?

Specific example:

I request the .elf for 4788 - [B]about 13 minutes later[/B], I receive the .elf.
I run Aliqueit to clean out any small/medium factors and come up with a current cofactor (Cxxx).
I factor the current Cxxx.
I supply the factors to the db.
If I check the last 20 lines (or, just the last line) via the web page, the factors have been processed.
If I now ask for a new .elf, the db goes off for another 13+ minutes:
[code]
--2013-10-25 [B]20:04:00[/B]-- http://www.factordb.com/elf.php?seq=4788&type=1
Resolving www.factordb.com (www.factordb.com)... 176.9.39.214
Connecting to www.factordb.com (www.factordb.com)|176.9.39.214|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: `alq_4788.elf'

[ <=> ] 989,858 357K/s in 2.7s

2013-10-25 [B]20:17:05[/B] (357 KB/s) - `alq_4788.elf' saved [989858]
[/code]I know I could go to the trouble of saving the html page and clearing out all the extraneous html code to reconstruct the needed line, but there should be an easier way. There probably is one that I'm unaware of. That is the object of my search.

Thanks for any help.

[QUOTE=EdH;357465]Is there a way to get an .elf file without causing the db to do an entire check of all the existing entries prior to supplying it? Or, possibly an .elf file of only the last line, since Aliqueit can work from there?

Specific example:

I request the .elf for 4788 - [B]about 13 minutes later[/B], I receive the .elf.

[snip]

[/QUOTE]No, as far as plain text goes, you're limited to getting the whole file. Not sure why it would take 13 minutes, though. Doing it through my web browser, it takes ~3 minutes after clicking on "Download .elf file" to produce a prompt to save the resulting file. You might try it "by hand" to see how long it takes that way....

[QUOTE=schickel;357482]No, as far as plain text goes, you're limited to getting the whole file. Not sure why it would take 13 minutes, though. Doing it through my web browser, it takes ~3 minutes after clicking on "Download .elf file" to produce a prompt to save the resulting file. You might try it "by hand" to see how long it takes that way....[/QUOTE]
It took just less than 3 minutes by browser click here as well and when I tried it via a terminal, it took about the same:
[code]
wget 'http://www.factordb.com/elf.php?seq=4788&type=1' -O alq_4788.elf
--2013-10-26 00:08:15-- http://www.factordb.com/elf.php?seq=4788&type=1
Resolving www.factordb.com (www.factordb.com)... 176.9.39.214
Connecting to www.factordb.com (www.factordb.com)|176.9.39.214|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: `alq_4788.elf'

[ <=> ] 989,858 403K/s in 2.4s

2013-10-26 00:10:50 (403 KB/s) - `alq_4788.elf' saved [989858]
[/code]I suppose I hit the db at a bad time for a while today, but still, if a single line could be retrieved, it would save a lot of db work. I suppose the ~3 minutes is somewhat taken up translating everything to the text format, but a single line should take next to nothing.

I'll probably go ahead and write something to parse the html code for a single line retrieval. Although it will be a pain, once it's done, I should be able to cut down the wait and the db use. And, I need more work with my regex studies.:smile:

Thanks for all the help...

I wrote a script that now functions in a couple seconds, if that long. Here's what it does:

1. retrieves the html of the last line of an aliquot sequence
2. harvests the id of the final cofactor, since the display of that cofactor is compressed: NNNN...NN
3. retrieves the html of the id from above
4. harvests the cofactor

It hits the db twice now, instead of once, but each hit is so brief, it should be well less load than having the db go through an entire sequence creating an .elf.

There has been some interest in the aforementioned script, so I'm providing it here for review and any correction/advancement it may need. It is currently a bash function and is presented that way (sorry, no internal comments):
[code]
function getnum {
wget 'http://www.factordb.com/sequences.php?se1&aq='$alqnum'&type=1&action=last' -O temp$alqnumll
exec <"temp$alqnumll"
while read line
do
case $line in
*"=110000"*) position=1
while [ $position -gt 0 ]
do
line=${line:${position}+3}
position=`expr index "$line" ?`
done
idline=$line;;
esac
done
position=`expr index "$idline" \"`
idline=${idline:0:${position}-1}

wget 'http://www.factordb.com/index.php?id='${idline} -O temp$alqnumcf
exec <"temp${alqnumcf}"
while read line
do
case $line in
*"query"*) line=${line:42}
position=`expr index "$line" =`
line=${line:$position+1}
line=${line:0:${#line}-2}
ecmIn=$line;;
esac
done
echo ${ecmIn} >${direct}ecmIn
}
[/code]The following is an example bash script:
[code]
#!/bin/bash

alqnum=4788

function getnum {
...
}

getnum
echo $ecmIn
[/code]alqnum is set (in this example, to 4788
getnum is called
--the fist section queries the db for the last line, which is returned as an html page into the file temp4788ll, which is then parsed for the id of the last cofactor, which is then fed to the second section
--the second section queries the db for the number associated with the id from the first section, with this html page returned as temp4788cf, which is then parsed for the cofactor itself

In my example the cofactor is sent to a file named ecmIn and echoed to the screen.

All comments welcome...

A plain text file for an expanded number, without having to parse the html code, one could use:

[CODE]http://factordb.com/getnumber.php?id=<id_num>[/CODE]

Also, for reporting factors, report format 3 is quicker (assuming base 10).

[CODE]--post-data=report=<factor>&format=[B][COLOR="Red"]3[/COLOR][/B] http://factordb.com/index.php?id=<id_num>[/CODE]

[QUOTE=RichD;357753]A plain text file for an expanded number, without having to parse the html code, one could use:

[CODE]http://factordb.com/getnumber.php?id=<id_num>[/CODE]Also, for reporting factors, report format 3 is quicker (assuming base 10).

[CODE]--post-data=report=<factor>&format=[B][COLOR=Red]3[/COLOR][/B] http://factordb.com/index.php?id=<id_num>[/CODE][/QUOTE]
[B]Now[/B], you tell me.:smile:

Thanks! This will help a lot. Where can I get a "list" or such of all the things I can do with the db? Is this a .php thing and if I learn all about .php, I'll know all these things?

[QUOTE=EdH;357761][B]Now[/B], you tell me.:smile:

Thanks! This will help a lot. Where can I get a "list" or such of all the things I can do with the db? Is this a .php thing and if I learn all about .php, I'll know all these things?[/QUOTE]

How did I know you were going to say that!!

The complete subset is posted in this forum.

Seriously, I think someone else has asked the same thing but Syd is too busy and barely has time to keep his site running, though admirably I would have to say.

It looks like [URL="http://factordb.com/index.php?id=1100000000259766196"]1100000000259766196[/URL] has a verified certificate but is still marked as a PRP. I've reverified the certificate with two different verifiers, so that doesn't seem to be a problem.

Some clown has been flooding the database with hundreds of composites all containing the factor 99999999999999999999999999999999999999999999959.