[QUOTE=mdettweiler;230613]Are you doing ECM on these prior to QSing them?[/QUOTE]
msieve does all the job (including brief ECM).

Can you please post you Perl Program?

[QUOTE=mdettweiler;230613]Are you doing ECM on these prior to QSing them? From what I've seen, many of the numbers on the list can be easily knocked out in the first couple of rounds of the "scan" button.[/QUOTE]

I wonder what the optimal amount of ECM is for these numbers. msieve does 30 curves at B1 = 2000 if I read the source correctly, plus a good number of P-1 and P+1 tests.

Here is my script.
Please notice that I did not mean to make it comprehensive or fault-tolerant.
Don't blame me if it occasionally resulted in DDoS of factordb.com or something. :smile:
Also, the script highly depends on the current format of data received from factordb.com. Any changes in this format may break the script functionality.
So, use it with caution on your own risk and periodically monitor its activity.

Currently it uses [i]msieve[/i] for factoring and [i]wget[/i] for communicating with factordb.com
You need to specify full path and executable names of these programs in the header.

Multiple instances of the script must be run from different directories.

[code]
#!/usr/bin/perl
use strict;

print("FactorDB Helper 1.2\n");

# wget executable
my $wget = "wget --no-check-certificate";

# msieve executable
my $msieve = "/home/maxal/libs/msieve/msieve/trunk/msieve -t 3";

$| = 1;
$/ = undef;

while(1) {

my @todo;

# getting 100 smallest unfactored numbers
$_ = `$wget -O - http://factordb.com/listtype.php?t=3`;

# however, it may be a good idea to get the second hundred
#$_ = `$wget -O - http://factordb.com/listtype.php?t=3&start=100`;


while( /<a href=\"index\.php\?id=([^\"]*)\"><font color=\"\#002099\">([^<]*)<\/font><\/a><sub>&lt;(\d+)&gt;<\/sub>/gs ) {
my $id = $1;
my $digits = $3;

if( $digits >= 65 ) {
push(@todo,$id);
}
}

if( scalar(@todo) == 0 ) {
print("No suitable numbers. Resting for a while.\n");
sleep 60;
next;
}

#shuffle todo
shuffle(@todo);

print("Todo size: ",scalar(@todo),"\n");

foreach (@todo) {
my $id = $_;

# checking status, just in case
$_ = `$wget -O - http://factordb.com/index.php?id=$id`;
if( /<td>FF<\/td>/ ) {
print("\nid=$id is already factored.\n\n");
next;
}

# getting number in decimal
$_ = `$wget -O - http://factordb.com/index.php?showid=$id`;
if( ! /<td align=\"center\">(\d+)<br>/gs ) {
print("Error 1\n");
sleep 60;
next;
}

my $number = $1;
my $digits = length($number);

print("Factoring $digits-digit number (id=$id)\n");

if( $digits >= 80 ) {
$_ = `$msieve -v -n $number`;
}
else {
$_ = `$msieve -v $number`;
}

if( /prp\d+ factor: (\d+)\s/s ) {
my $factor = $1;
print("\nFactor found: $factor\n\n");
$_ = `$wget --post-data "report=$factor&format=0" -O - http://factordb.com/index.php?id=$id`;
}
else {
print("Error 2\n");
sleep 60;
}
}
}


exit;


sub shuffle {
for (my $i = 0; $i < @_; $i++) {
my $j = rand(@_ - $i) + $i; # pick random element
($_[$i], $_[$j]) = ($_[$j], $_[$i]); # swap 'em
}
}
[/code]

Nice script!

I added a new parameter to listtype.php - perpage. If you want you can display more or less than 100 per page now. Limit is 1000.

Another one:
&scriptmode=1

Displays just the internal id's + the number of digits, seperated by a space. One id per line.

This is a lot faster than retrieving all the other information from the database.

And the last one:

getrandom.php
Parameters:
n: number of numbers [1..100], 1 default
t: type. 2=> Unknown, 3=> Composite, default: Probable prime
mindig: minimum number of digits [40..?] , 65 default

returns the same format as listtype.php with scriptmode enabled.

Maybe these are useful to you :-)

to adapt the script for windows machine, just change the 3 first line to
[code]
#!H:\strawbery\perl <---- [B]where you have installed perl[/B]
use strict;

print("FactorDB Helper 1.2\n");

# wget executable
my $wget = "H:/Docume~1/Vincent/Bureau/script/wget --no-check-certificate";
[B]<--- where you have wget[/B]

# msieve executable
my $msieve = "H:/Docume~1/Vincent/Bureau/script/msieve147 -t 3"; <---- [B]where you have msieve

[/B][/code]and you might want to add a shortcut
with
[code]
H:\strawberry\perl\bin\perl.exe "H:\Documents and Settings\Vincent\Bureau\script\script.pl"
<-- [B]where your script is[/B]
[/code]
and if it is not too much too ask, is there a way to copy the factorisation to a file?

[QUOTE=Syd;230632]
getrandom.php
Parameters:
n: number of numbers [1..100], 1 default
t: type. 2=> Unknown, 3=> Composite, default: Probable prime
mindig: minimum number of digits [40..?] , 65 default

returns the same format as listtype.php with scriptmode enabled.

Maybe these are useful to you :-)[/QUOTE]

Thanks, that's helpful
But n=100 seems to produce only a couple of dozens id's ;(
Also, parameter maxdig would be helpful to avoid factorization of monsters.

On a different topic, could you please add support for cyclotomic polynomials (similarly to Phi() in ecm) ?

[QUOTE=maxal;230639]Thanks, that's helpful
But n=100 seems to produce only a couple of dozens id's ;(
Also, parameter maxdig would be helpful to avoid factorization of monsters.

On a different topic, could you please add support for cyclotomic polynomials (similarly to Phi() in ecm) ?[/QUOTE]

Sure you can. Maxdig is in and the n=100 limit now also works.

For retrieving the numbers there is another script thats maybe helpful:

getnumber.php?id=<id>

returns the Code (C, PRP, ..)+space+all digits. No HTML at all.

I'll add the cyclotomic polynomials later - first I have to read about that topic.

[QUOTE=Syd;230641]I'll add the cyclotomic polynomials later - first I have to read about that topic.[/QUOTE]

Factorizations available [url=http://www.asahi-net.or.jp/~kc2h-msm/cn/]here[/url]

[QUOTE=Syd;230641]Sure you can. Maxdig is in and the n=100 limit now also works.[/QUOTE]
[url]http://factordb.com/getrandom.php?n=100&t=3[/url] produces an empty page ;(

[QUOTE=maxal;230647][url]http://factordb.com/getrandom.php?n=100&t=3[/url] produces an empty page ;([/QUOTE]

Whoops.
Wrong maxdig default. Please try again :smile:

[QUOTE=Syd;230649]Whoops.
Wrong maxdig default. Please try again :smile:[/QUOTE]

It now works. Thanks!

Here is an updated script that uses new features.

[code]#!/usr/bin/perl
use strict;

print("FactorDB Helper 1.3\n");

# wget executable
my $wget = "wget --no-check-certificate";

# msieve executable
my $msieve = "/home/maxal/libs/msieve/msieve/trunk/msieve -t 3";

# min and max number of digits to factor
my $mindig = 65;
my $maxdig = 100;


$| = 1;
$/ = undef;

while(1) {

my @todo;

# getting 100 random unfactored numbers
$_ = `$wget -O - "http://factordb.com/getrandom.php?n=100&t=3&mindig=$mindig&maxdig=$maxdig"`;

# or getting 100 smallest unfactored numbers
#$_ = `$wget -O - "http://factordb.com/listtype.php?t=3&scriptmode=1"`;


while( /(\d{19})\s(\d+)/gs ) {

# /<a href=\"index\.php\?id=([^\"]*)\"><font color=\"\#002099\">([^<]*)<\/font><\/a><sub>&lt;(\d+)&gt;<\/sub>/gs ) {

my $id = $1;
my $digits = $2;

if( ($digits >= $mindig) && ($digits <= $maxdig) ) {
push(@todo,$id);
}
}

print("Todo size: ",scalar(@todo),"\n");

if( scalar(@todo) == 0 ) {
print("No suitable numbers. Resting for a while.\n");
sleep 60;
next;
}

shuffle(@todo);


foreach (@todo) {
my $id = $_;

# checking status and getting the number in decimal
$_ = `$wget -O - http://factordb.com/getnumber.php?id=$id`;
if( ! /(\S+)\s(\d+)/ ) {
print("Error 1\n");
sleep 60;
next;
}

if( $1 eq "FF" ) {
print("\nid=$id is already factored.\n\n");
next;
}

my $number = $2;
my $digits = length($number);

print("Factoring $digits-digit number (id=$id)\n");

if( $digits >= 80 ) {
$_ = `$msieve -v -n $number`;
}
else {
$_ = `$msieve -v $number`;
}

if( /prp\d+ factor: (\d+)\s/s ) {
my $factor = $1;
print("\nFactor found: $factor\n\n");
$_ = `$wget --post-data "report=$factor&format=0" -O - http://factordb.com/index.php?id=$id`;
}
else {
print("Error 2\n");
sleep 60;
}
}
}

exit;


sub shuffle {
for (my $i = 0; $i < @_; $i++) {
my $j = rand(@_ - $i) + $i; # pick random element
($_[$i], $_[$j]) = ($_[$j], $_[$i]); # swap 'em
}
}
[/code]

edit
ok, my fault found the problem : I didn't copy the subroutine at the end, and thanks for the msieve output.
Oon another note, don't worry (for now) about the max size. From what i seen , (listtype.php?t=3&start=10000&perpage=1000 - if I use start=11000 its the same page that appear, and it has 77 digits-) the number of digits take a long time rizing. at the speed of 140 sec by number on my medium comp, it will take 427 hours to do them all on a single cpu.

-damn it. much shorter than i though- ermmm... but since new composite with no know factor are 'discovered' vey often, it may take much longuer to go to 77 digits

Helper script + yafu
 

Hi. I did some refactorization to helper script. This version uses Yafu instead of Msieve.

Changes: shuffle-subroutine from end to begin. Spaces converted to tabs. Yafu insted of Msieve.

[code]
#!/usr/bin/perl
use strict;

print("FactorDB Helper 1.4 with yafu\n");

# wget executable
my $wget = "wget --no-check-certificate";

# min and max number of digits to factor
my $mindig = 71;
my $maxdig = 95;

$| = 1;
$/ = undef;

sub shuffle {
for ( my $i = 0 ; $i < @_ ; $i++ ) {
my $j = rand( @_ - $i ) + $i; # pick random element
( $_[$i], $_[$j] ) = ( $_[$j], $_[$i] ); # swap 'em
}
}

while (1) {

my @todo;

# getting 100 random unfactored numbers
$_ = `$wget -O - "http://factordb.com/getrandom.php?n=100&t=3&mindig=$mindig&maxdig=$maxdig"`;

# or getting 100 smallest unfactored numbers
#$_ = `$wget -O - "http://factordb.com/listtype.php?t=3&scriptmode=1"`;

while (/(\d{19})\s(\d+)/gs) {

my $id = $1;
my $digits = $2;

if ( ( $digits >= $mindig ) && ( $digits <= $maxdig ) ) {
push( @todo, $id );
}
}

print( "Todo size: ", scalar(@todo), "\n" );

if ( scalar(@todo) == 0 ) {
print("No suitable numbers. Resting for a while.\n");
sleep 60;
next;
}

shuffle(@todo);

foreach (@todo) {
my $id = $_;

# checking status and getting the number in decimal
$_ = `$wget -O - http://factordb.com/getnumber.php?id=$id`;
if ( !/(\S+)\s(\d+)/ ) {
print("Error 1\n");
sleep 60;
next;
}

if ( $1 eq "FF" ) {
print("\nid=$id is already factored.\n\n");
next;
}

my $number = $2;
my $digits = length($number);

print("Factoring $digits-digit number (id=$id)\n");

my $yafu = "./yafu \"siqs($number)\" >joo.log";
system($yafu);
my $text = do { local ( @ARGV, $/ ) = "joo.log"; <> };
print "Num: $number\nResults:\n";
my @results;

my @out = split( "\n", $text );
for (@out) {
if (/P.*? = (\d+)/) {
push( @results, $1 );
print "$1\n";
}
}

unlink "joo.log";

if ( scalar(@results) > 0 ) {
my $factors = join("\n",@results);
$_ = `$wget --post-data "report=$factors&format=0" -O - http://factordb.com/index.php?id=$id`;
}
else {
print("Error 2\n");
sleep 60;
}
}
}
[/code]

The helper script works great!
Just 2 small changes:
There has almost no ECM work been done on these numbers, I just pulled a P16 out of a C75 with SIQS. So I changed siqs() to factor() to do proper ECM.
The number does not need to be "FF" if a factor is found, it could be "CF" with a small composite part. So changed the check to != "C".

[CODE]
#!/usr/bin/perl
use strict;

print("FactorDB Helper 1.4 with yafu\n");

# wget executable
my $wget = "wget --no-check-certificate";

# min and max number of digits to factor
my $mindig = 65;
my $maxdig = 95;

$| = 1;
$/ = undef;

sub shuffle {
for ( my $i = 0 ; $i < @_ ; $i++ ) {
my $j = rand( @_ - $i ) + $i; # pick random element
( $_[$i], $_[$j] ) = ( $_[$j], $_[$i] ); # swap 'em
}
}

while (1) {

my @todo;

# getting 100 random unfactored numbers
$_ = `$wget -O - "http://factordb.com/getrandom.php?n=100&t=3&mindig=$mindig&maxdig=$maxdig"`;

# or getting 100 smallest unfactored numbers
#$_ = `$wget -O - "http://factordb.com/listtype.php?t=3&scriptmode=1"`;

while (/(\d{19})\s(\d+)/gs) {

my $id = $1;
my $digits = $2;

if ( ( $digits >= $mindig ) && ( $digits <= $maxdig ) ) {
push( @todo, $id );
}
}

print( "Todo size: ", scalar(@todo), "\n" );

if ( scalar(@todo) == 0 ) {
print("No suitable numbers. Resting for a while.\n");
sleep 60;
next;
}

shuffle(@todo);

foreach (@todo) {
my $id = $_;

# checking status and getting the number in decimal
$_ = `$wget -O - http://factordb.com/getnumber.php?id=$id`;
if ( !/(\S+)\s(\d+)/ ) {
print("Error 1\n");
sleep 60;
next;
}

if ( $1 != "C" ) {
print("\nid=$id has known factors / is already factored.\n\n");
next;
}

my $number = $2;
my $digits = length($number);

print("Factoring $digits-digit number (id=$id)\n");

my $yafu = "H:/PATH/TO/YAFU/yafu \"factor($number)\" >joo.log";
system($yafu);
my $text = do { local ( @ARGV, $/ ) = "joo.log"; <> };
print "Num: $number\nResults:\n";
my @results;

my @out = split( "\n", $text );
for (@out) {
if (/P.*? = (\d+)/) {
push( @results, $1 );
print "$1\n";
}
}

unlink "joo.log";

if ( scalar(@results) > 0 ) {
my $factors = join("\n",@results);
$_ = `$wget --post-data "report=$factors&format=0" -O - http://factordb.com/index.php?id=$id`;
}
else {
print("Error 2\n");
sleep 60;
}
}
}[/CODE]

for Syd version to work(for windows) you need to change
[code]
my $yafu = "./yafu \"factor($number)\" >joo.log"
to
my $yafu = "H:/Docume~1/Vincent/Bureau/script/yafu \"factor($number)\" >joo.log";
[/code]and since the 64- digits are automatically factored, why do 'we' set the min digit limit at 71 digits?
this is a 7 digits disperency

[QUOTE=firejuggler;230675][code]
my $yafu = "H:/Docume~1/Vincent/Bureau/script/yafu \"factor($number)\" >joo.log";
[/code][/QUOTE]

This depends on your computer. Set $yafu without any path and put the pl-script and yafu.exe/ini in the same folder.

i'm using a shortcut to run the script.that need the full path

Here is a new version that supports both msieve and yafu:

[code]#!/usr/bin/perl
use strict;

print("FactorDB Helper 1.5\n");

# wget executable
my $wget = "wget --no-check-certificate";

# msieve and/or yafu executables
my $msieve = "/home/maxal/libs/msieve/msieve/trunk/msieve -t 3";
my $yafu = "/home/maxal/libs/yafu-1.19.2/yafu";

# "M" for msieve, "Y" for yafu
my $MorY = "Y";

# min and max number of digits to factor
my $mindig = 65;
my $maxdig = 100;


$| = 1;
$/ = undef;

while(1) {

my @todo;

# getting 100 random unfactored numbers
$_ = `$wget -O - "http://factordb.com/getrandom.php?n=100&t=3&mindig=$mindig&maxdig=$maxdig"`;

# getiing 100 smallest unfactored numbers
#$_ = `$wget -O - "http://factordb.com/listtype.php?t=3&scriptmode=1"`;


while( /(\d{19})\s(\d+)/gs ) {

# /<a href=\"index\.php\?id=([^\"]*)\"><font color=\"\#002099\">([^<]*)<\/font><\/a><sub>&lt;(\d+)&gt;<\/sub>/gs ) {

my $id = $1;
my $digits = $2;

if( ($digits >= $mindig) && ($digits <= $maxdig) ) {
push(@todo,$id);
}
}

print("Todo size: ",scalar(@todo),"\n");

if( scalar(@todo) == 0 ) {
print("No suitable numbers. Resting for a while.\n");
sleep 60;
next;
}

shuffle(@todo);


foreach (@todo) {
my $id = $_;

# checking status and getting the number in decimal
$_ = `$wget -O - http://factordb.com/getnumber.php?id=$id`;
if( ! /(\S+)\s(\d+)/ ) {
print("Error 1\n");
sleep 60;
next;
}

if( $1 ne "C" ) {
print("\nid=$id has known factors.\n\n");
next;
}

my $number = $2;
my $digits = length($number);

print("Factoring $digits-digit number (id=$id)\n");


my $factor = 0;


if( $MorY eq "M" ) {
# factoring with msieve

if( $digits >= 80 ) {
$_ = `$msieve -v -n $number`;
}
else {
$_ = `$msieve -v $number`;
}
if( /prp\d+ factor: (\d+)\s/s ) {
$factor = $1;
}
}

if( $MorY eq "Y" ) {
#factoring with yafu

$_ = `$yafu "factor($number)"`;
if( /PRP\d+ = (\d+)\s/s ) {
$factor = $1;
}
}

if( $factor == 0 ) {
print("Error 2\n");
sleep 60;
next;
}

# reproting the factor
print("\nFactor found: $factor\n\n");
$_ = `$wget --post-data "report=$factor&format=0" -O - http://factordb.com/index.php?id=$id`;
}
}

exit;


sub shuffle {
for (my $i = 0; $i < @_; $i++) {
my $j = rand(@_ - $i) + $i; # pick random element
($_[$i], $_[$j]) = ($_[$j], $_[$i]); # swap 'em
}
}
[/code]

So far, Yafu seem a bit quicker, so I stay with it.

Here's a slightly changed version of Syd's script (uses only yafu, here WIN) Version 1.4.1.

Changes:

- logging on screen lists only numbers (with FactorDB-id and decimal representation) and factors found
- same logging in file 'log.txt'
- only one number is selected with "getrandom.php" not 100
- changing the digit-range for factoring on the fly:
-- if no number was found in the range of 65 to 75 digits (default) the max range border is increased by 1
-- if 5 numbers were tested in a row of the same digit-range, the max border is decreased by 1

The output looks like this:
[code]
Decreasing range to 65-73 digits.
Factoring C72, id=1100000000215417418
107698193083421293260516846795731434061232959793477539564812373340276287
Factors:
26405284013285459123374233622798414903151
4078660658572519568543061554737

Factoring C71, id=1100000000215417870
28504080459937869696853196518741764601588734850800683566672894693639223
Factors:
1748688300560557
16300263718125547456234420973318896388823562351146807539

Increasing range to 65-74 digits.
Increasing range to 65-75 digits.
Increasing range to 65-76 digits.
Factoring C76, id=1100000000025315182
1974478705750231792145699016077046904574325297781281987720170399119810269059
Factors:
29295408896033352638313544033
67398912667765477451991694259949184848483041123
[/code]

Perhaps the output of the timings of siqs from yafu could also be logged.

Note:
First I used wget 1.8.2 from a UnixUtils package to run that script under WIN, but that version does not support data-upload with the "--post-data" option.
So I searched for another version, comes with gawk.exe but without some needed DLL's.
That 'wget.exe' needs libeay32.dll, libiconv2.dll, libintl3.dll and libssl32.dll.
After I found them, it's working great now.

I've changed the extension of the attached file into *.txt, rename to *.pl again.

Thank you kar bon !
Now i have a other wget.exe with .dll`s and it`s running for me too.
I was wondering me why the factors are not submitted before.
Now it works fine. Thanks again.

Regards Andi_HB

I made a small change so you dont need to "POST" the factors anymore, simple "GET" will do now, too.

Syd you don`t want to increase the Smallest unproven prime from 1000 digits to 2000 digits or more? There are only 8450 Unproven (probable) primes in the List.

[QUOTE=Andi_HB;230875]Syd you don`t want to increase the Smallest unproven prime from 1000 digits to 2000 digits or more? There are only 8450 Unproven (probable) primes in the List.[/QUOTE]

Sure, can do. But it will take a lot of time to prove them all.

Btw.: Whats the best/fastest tool to use for primality proving?

The (few minutes ago) unproven 1000-digit number [url=http://factordb.com/index.php?id=1000000000022451023]10^999+7[/url]:

Here are different callings with pfgw V3.3.6:

[code]
>pfgw -l -t -q"10^999+7"
PFGW Version 3.3.6.20100908.Win_Stable [GWNUM 25.14]
Output logging to file pfgw.out
Primality testing 10^999+7 [N-1, Brillhart-Lehmer-Selfridge]
Running N-1 test using base 5
Calling Brillhart-Lehmer-Selfridge with factored part 0.51%
10^999+7 is PRP! (0.1865s+0.0033s)
[/code]

[code]
>pfgw -l -tp -q"10^999+7"
PFGW Version 3.3.6.20100908.Win_Stable [GWNUM 25.14]
Output logging to file pfgw.out
Primality testing 10^999+7 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 5, base 1+sqrt(5)
Calling Brillhart-Lehmer-Selfridge with factored part 1.30%
10^999+7 is Lucas PRP! (0.4724s+0.0021s)
[/code]

[code]
>pfgw -l -tc -q"10^999+7"
PFGW Version 3.3.6.20100908.Win_Stable [GWNUM 25.14]
Output logging to file pfgw.out
Primality testing 10^999+7 [N-1/N+1, Brillhart-Lehmer-Selfridge]
Running N-1 test using base 5
Running N+1 test using discriminant 13, base 1+sqrt(13)
Calling N+1 BLS with factored part 1.30% and helper 0.51% (4.46% proof)
10^999+7 is Fermat and Lucas PRP! (0.5927s+0.0022s)
[/code]

Those all only gets a PRP.

Using a helper file with the factors of N-1 and N+1:
[code]
2
139
557
3
7
29
25243
44267
93199469863
16622228274680328721
129828685855865750907048113732006068712091646588660399057028288891675878011928140341693521730335952497241789568992132121979762823763531070211612968223909822033434002496345971636586658440721130839012689196098180606762153068539938809143782413354282490083035830899694616965129832580716441426879575325175418028894153009338058058869[/code]

(Note: The last factor is composite! Don't know if this is allowed.)

gives:

[code]
>pfgw -l -tc -hfact.txt -q"10^999+7"
PFGW Version 3.3.6.20100908.Win_Stable [GWNUM 25.14]
Output logging to file pfgw.out
Primality testing 10^999+7 [N-1/N+1, Brillhart-Lehmer-Selfridge]
Reading factors from helper file fact.txt
Running N-1 test using base 5
Running N+1 test using discriminant 13, base 1+sqrt(13)
Calling N+1 BLS with factored part 36.98% and helper 0.51% (111.48% proof)
10^999+7 is prime! (0.8895s+0.0023s)
[/code]

This will give a prime here and all timings are neglectable.

[QUOTE=kar_bon;230885](Note: The last factor is composite! Don't know if this is allowed.)[/QUOTE]

No, it's not allowed:
[CODE] -h Factor Helper file
An argument is required for this switch.
Use this option when you are using the n-1 or n+1 test and run short of
small factors to get to the 33.33% limit. If you have found larger
factors with other programs (ecm, rho, whatever) you can put them in
the helper file one on a line.
[B]You should ONLY use prime factors in this file, or the result is invalid.[/B]
The file can also be made up of expressions, and not simply
numbers Example: pfgw -tp -hhelper.txt
When testing (-t -tp -tm -tc) any factor in this file that is
not part of the N-1 or N+1 (either or both depending upon which method
of testing), will be printed to screen with a warning listing that
this factor does not "fit". (Note this behavior can be overridden
by using the HideNoFactor=true in the pfgw.ini file)
Multiple -h command line switches can be used (for multiple
factor files). Example pfgw -tc -hplus -hminus input_file
[/CODE]
I tested this again with the composite factor removed, and PFGW was only able to PRP it.
[CODE]WinPFGW ran with "-tc -hhelper.txt -q10^999+7"

PFGW Version 3.3.6.20100908.Win_Stable [GWNUM 25.14]

Output logging to file pfgw.out
Primality testing 10^999+7 [N-1/N+1, Brillhart-Lehmer-Selfridge]
Reading factors from helper file helper.txt
Running N-1 test using base 5
Special modular reduction using all-complex FFT length 192 on 10^999+7
Running N+1 test using discriminant 13, base 1+sqrt(13)
Special modular reduction using all-complex FFT length 192 on 10^999+7
Calling N+1 BLS with factored part 4.34% and helper 0.51% (13.53% proof)
10^999+7 is Fermat and Lucas PRP! (0.0888s+0.0404s)[/CODE]
If I'm not mistaken, the known factors have to come to 33.33% of the size of the number. This is rarely possible/easy with 1000-2000 digit numbers.

For this particular number, I have already ran a primality test with Primo. The certificate is attached. The test took about 21 minutes. The verification takes about 0.03 seconds. As far as I know, and without having N-1 or N+1 easily factored to 33.33% of the size of N, this is the fastest way to prove primality for numbers this size.

[QUOTE=Mini-Geek;230891]No, it's not allowed:
[/quote]

Thanks, not read that part.

[quote]
For this particular number, I have already ran a primality test with Primo. The certificate is attached. The test took about 21 minutes. The verification takes about 0.03 seconds. As far as I know, and without having N-1 or N+1 easily factored to 33.33% of the size of N, this is the fastest way to prove primality for numbers this size.[/QUOTE]

Please try the same number with the ECM-applet from D-Alpern, I've tested few numbers some time ago and compared with PRIMO, the applet seems faster if I remember right.

[QUOTE=kar_bon;230892]Please try the same number with the ECM-applet from D-Alpern, I've tested few numbers some time ago and compared with PRIMO, the applet seems faster if I remember right.[/QUOTE]

Yes, a good deal faster.
The applet:[CODE]Factorization complete in 0d 0h 14m 25s
ECM: 0 modular multiplications
Prime checking: 5552675 modular multiplications

Timings:
Primality test of 1 number: 0d 0h 14m 21.2s[/CODE]Primo:[CODE][Running Times]
Initialization=0.48s
1stPhase=19mn 30s
2ndPhase=5mn 50s
Total=25mn 21s
[/CODE]Is there a faster implementation of the method the applet uses? I'd expect an efficient native implementation to run much faster than an applet.

[QUOTE=Mini-Geek;230896]Is there a faster implementation of the method the applet uses? I'd expect an efficient native implementation to run much faster than an applet.[/QUOTE]

As I know the applet uses the APRT-CLE = Adleman-Pomerance-Rumely Test with Cohen-Lenstra Extension and PRIMO uses the ECPP = Elliptic Curve Prime Proving Test.

[QUOTE=kar_bon;230900]As I know the applet uses the APRT-CLE = Adleman-Pomerance-Rumely Test with Cohen-Lenstra Extension and PRIMO uses the ECPP = Elliptic Curve Prime Proving Test.[/QUOTE]

For this number the applet used the "Rabin probabilistic prime check routine" (the ProbabilisticPrimeTest method in the code), where it does a PRP test for N.bitlength()/2 bases (in this case, 1659 bases).

[QUOTE=Mini-Geek;230908]For this number the applet used the "Rabin probabilistic prime check routine" (the ProbabilisticPrimeTest method in the code), where it does a PRP test for N.bitlength()/2 bases (in this case, 1659 bases).[/QUOTE]

What an odd choice, testing more bases for larger numbers.

[QUOTE=CRGreathouse;230914]What an odd choice, testing more bases for larger numbers.[/QUOTE]

It "proves" the numbers (I'm guessing, under RH), not just PRP tests them.

[QUOTE=axn;230951]It "proves" the numbers (I'm guessing, under RH), not just PRP tests them.[/QUOTE]

That's not nearly enough bases for Miller's test. He proved that 70 log^2 x bases suffice under the ERH; I seem to remember a modern version lowering the 70 to 2 or 3. But even in the most generous interpretation that would take 10,582,599 tests, not 1659.

Edit: Actually, not all bases up to 70 log^2 x need be tested -- only those in [url=http://oeis.org/classic/A089105]A089105[/url]. But even if only the primes were included, that's 700,709 tests (and I'm pretty sure A089105 is a superset of A000040).

Table 10^n+1 updatet till n=500 from Alfred Reich / Kamada`s Sites.

[QUOTE=CRGreathouse;230961]That's not nearly enough bases for Miller's test. He proved that 70 log^2 x bases suffice under the ERH; I seem to remember a modern version lowering the 70 to 2 or 3. [/QUOTE]

2 log^2 x by a result from Eric Bach

[QUOTE=R.D. Silverman;231089]2 log^2 x by a result from Eric Bach[/QUOTE]

Yes, that's the result I was thinking of. He proved an auxiliary result with constant 3 and that result with constant 2; now it comes back.

What kind of connection do you have the DB on? If I wanted to automate the downloading of aliquot sequences to check on progress, do I need to worry about using up too much bandwidth or running too many connections to the DB too quickly?

[QUOTE=Syd;230872]I made a small change so you dont need to "POST" the factors anymore, simple "GET" will do now, too.[/QUOTE]Can you give me an example of a GET string to upload a factor? I'm sure it's obvious, but I can't get it to work...

If I know that 35735836391277091 is a factor of (10^3434*15+10^6869-1)/69 , what is correct GET string for that?

Yes, I can upload factors by hand using normal web browser, but it requires too much manual work.

The factordb seems to be down. (It takes a few minutes to load and then gives an empty page.)

Edit: it's up again.

[QUOTE=schickel;231231]What kind of connection do you have the DB on? If I wanted to automate the downloading of aliquot sequences to check on progress, do I need to worry about using up too much bandwidth or running too many connections to the DB too quickly?[/QUOTE]

The max. upload is 3Mbit, no bandwidth limit. Try to keep it below 4 parallel connections, thats enough to keep the server busy.

[QUOTE=schickel;231232]Can you give me an example of a GET string to upload a factor? I'm sure it's obvious, but I can't get it to work...[/QUOTE]

Shame on me, that one is bugged. I'll try to fix it!

[QUOTE=R.D. Silverman;231089]2 log^2 x by a result from Eric Bach[/QUOTE]

Thanks, thats what I was looking for.

Is it still possible to get a range of lines in .elf format rather than having to download an entire sequence in .elf format? That way I would not hit the DB so hard to do an update on reserved sequences. Basically, did you add (or could you add) the "raw=1" parameter?

Hmmm - is the DB down now?

[QUOTE=schickel;231730]Is it still possible to get a range of lines in .elf format rather than having to download an entire sequence in .elf format? That way I would not hit the DB so hard to do an update on reserved sequences. Basically, did you add (or could you add) the "raw=1" parameter?[/QUOTE]Actually, that's not real clear. What I mean is: can you add the "text only" or "raw" option to the "Last 20" option, so I don't have to download the entire elf just to get the last few lines?

[QUOTE=Andi_HB;231771]Hmmm - is the DB down now?[/QUOTE]Sure looks that way....[quote=downforeveryoneorjustme.com]It's not just you! [url]http://factordb.com[/url] looks down from here.[/quote]

Hello Syd. There is known factorizations of lucas and fibonacci numbers: [url]http://mersennus.net/fibonacci/[/url]

The database is all knowing.
[URL="http://www.factordb.com/index.php?query=I%28n%29&use=n&n=1000&sent=Show&VP=on&VC=on&EV=on&OD=on&CF=on&U=on&C=on&perpage=20&format=1"]Fibonacci[/URL], [URL="http://www.factordb.com/index.php?query=lucas%28n%29&use=n&n=1000&sent=Show&VP=on&VC=on&EV=on&OD=on&CF=on&U=on&C=on&perpage=20&format=1"]Lucas[/URL]

Table 2^n+1 updatet till n=1000 - hope i havent missed known factors.

I have a script which adds factors from Kamada tables to the factorDB. It is only run a couple times per week.

P.S. Perhaps I should check if it still works with the new data base.

[QUOTE=RichD;232176]P.S. Perhaps I should check if it still works with the new data base.[/QUOTE]

It appears to be working fine. :)

I love [URL]http://factorization.ath.cx/[/URL]

I don't know how hard it was to realize, because I don't know enough about programming...

But IT IS AWESOME.

What is the server running on now?


Thank you so much for maintaining it!

M6337 just became fully factored because I fed GIMPS data to factordb.

Yay!


....a lot of work ahead.

Any way I could lend a hand?

I'm adding (and finding) big factors for Ms with <2000digits.

M1091 just turned FF.

Finding some 40+digit factors in the process...

Syd, could you add "text, only composite cofactors" option to output formats menu in variable search?

Thank you.

[I]Gives me a blank page atm.

Guess the DB is down.

[/I][B]It's up.[/B]

Something strange with [URL="http://factordb.com/sequences.php?aq=612384&action=last20"]612384[/URL]

and something wrong with [url=http://factordb.com/sequences.php?se=1&eff=2&aq=10601050104&action=last20&fr=0&to=100]10601050104[/url]

Check out "Smallest composite without known factors".

It's faulty at the moment, IIRC the same was there yesterday.

Yesterday there was a power outage here, causing some troubles with the tables, some id's are now used twice.
I'm on it, it should be easy to repair.

[URL="http://www.factordb.com/sequences.php?se=1&eff=2&aq=77142&action=last20&fr=0&to=100"]77142[/URL] seems to be broken too - the DB does not display any iteration of the sequence.

[QUOTE=Andi47;233957][URL="http://www.factordb.com/sequences.php?se=1&eff=2&aq=77142&action=last20&fr=0&to=100"]77142[/URL] seems to be broken too - the DB does not display any iteration of the sequence.[/QUOTE]Interesting....I tried the graph buttons and got this [sic]:[code]<br />
<b>Fatal error</b>: Exception thrown without a stack frame
in <b>Unknown</b> on line <b>0</b><br />[/code]Doesn't look good....

The repairscript just finished its work, looks like the bugs are fixed.

[QUOTE=Syd;233970]The repairscript just finished its work, looks like the bugs are fixed.[/QUOTE]Thanks for the repair.

I've been relying on the DB to keep up to date on the Aliquot project and appreciate all the hard work you've put in to maintaining the DB. Thanks!

Sounds a little low....[URL="http://www.outerstats.com/site/factordb.com"]$69.00[/URL] (USD, I assume...)

[QUOTE=schickel;234184]Sounds a little low....[URL="http://www.outerstats.com/site/factordb.com"]$69.00[/URL] (USD, I assume...)[/QUOTE]

This analysis sucks. I tried it for some sites, and all results were absolute wrong.

Should the "Proving probable primes <1000 digits" worker be bumped to a higher limit?

[QUOTE=RichD;234649]Should the "Proving probable primes <1000 digits" worker be bumped to a higher limit?[/QUOTE]

It seems to be pretty busy as it is, even with the help of the " Proving probable primes <=200 digits" worker.

I guess Syd is the only one with enough insight into the workload to prioritize well.

More workers would be awesome, obv. Perhaps one factoring numbers below a limit between 70 and 1k digits. And one checking the status of numbers below a limit between 1k and 10k digits.

Raising the limit on the factoring worker seems to have been a success.

Anyway, really diggin' this DB.

Something wrong with [URL]http://factorization.ath.cx/index.php?id=1000000000000038219[/URL]

[QUOTE=lorgix;235303]Something wrong with [URL]http://factorization.ath.cx/index.php?id=1000000000000038219[/URL][/QUOTE]
What's wrong with it? If it's the red cofactor you're worried about, that just indicates that it is "status unknown"--i.e., it's sufficiently big that the DB hasn't (yet) gotten to it with a PRP test to determine whether it finishes the factorization or not.

[QUOTE=mdettweiler;235331]What's wrong with it?[/QUOTE]

The factorization is wrong, try in the FactoDB "(2^38219-1)/4381298797428052406300189129".

Hint: The sum of digits of the two cofactors is about 8 digits too small.

Edit: The correct small factor is 165056813708157873340366248563710409!

[QUOTE=kar_bon;235339]The factorization is wrong, try in the FactoDB "(2^38219-1)/4381298797428052406300189129".

Hint: The sum of digits of the two cofactors is about 8 digits too small.

Edit: The correct small factor is 165056813708157873340366248563710409![/QUOTE]

That's it.

Still there. Any idea why?

[QUOTE=lorgix;235343]That's it.

Still there. Any idea why?[/QUOTE]

No. Only Syd can correct this error manually.

[QUOTE=kar_bon;235339]The factorization is wrong, try in the FactoDB "(2^38219-1)/4381298797428052406300189129".

Hint: The sum of digits of the two cofactors is about 8 digits too small.

Edit: The correct small factor is 165056813708157873340366248563710409![/QUOTE]

Actual cofactor of M38219: [URL]http://factorization.ath.cx/index.php?id=1100000000217224855[/URL]

Bad factoring: [URL]http://factorization.ath.cx/index.php?id=1000000000000038219[/URL]

While I'm writing I want to point to the fact that Syd has added yet another worker to the DB (among other things) since last time I posted in this thread. :bow:

Composite numbers with known factors 200,210,902
Woooohoooo - the 200.000.000 Milestone was crossing last Night.
Congratulations Syd :bow wave:

[quote=fivemack] [I]Is there any plan to have the sequence-overview form available on the new database? It saved a lot of either manual work or perl-scripting when planning what to do next using the old database.[/I][/quote]

[quote=Syd]Yes I'm working on it. First I'll have to store the sequences in another format that can also detect merges, the overview can be read directly from it.[/quote]

Any progress here? When these features will be added?

[URL]http://www.stumbleupon.com/url/factorization.ath.cx/[/URL]

[URL]http://www.stumbleupon.com/url/factordb.com/[/URL]

Traffic will probably increase.

I encourage all people who use stumbleupon to 'Like it'.

[QUOTE=lorgix;237096][URL]http://www.stumbleupon.com/url/factorization.ath.cx/[/URL]

Traffic will probably increase.

I encourage all people who use stumbleupon to 'Like it'.[/QUOTE]
Would have been nice to use the shorter factordb.com but liked.

[QUOTE=henryzz;237102]Would have been nice to use the shorter factordb.com but liked.[/QUOTE]

Both work now. Thanks for pointing it out.

ah i noticed that Syd have started to implement sequence merge.
[code]
[B]Additional information for [URL="http://factordb.com/index.php?id=1100000000238578450"][COLOR=#002099]1081888999...[/COLOR][/URL]<120>[/B] [B]Predecessor of sequences[/B] Aliquot sequence: [URL="http://factordb.com/index.php?id=1100000000238578424"][COLOR=#002099]1233979385...[/COLOR][/URL]<120>[/code]
so, some progress has been done. ( the aliquot sequence refered is the preceding term of the sequence-real start is 68067066)

[QUOTE=RichD;232176]I have a script which adds factors from Kamada tables to the factorDB. It is only run a couple times per week.[/QUOTE]

Correction: My script only updates numbers of the following forms.
AA...AAB
ABB...BB
ABB...BBA
ABB...BBC

There seems to be an error in the DB for this composite:
[URL]http://factordb.com/index.php?id=1100000000251375612[/URL]

It reports its factors as 2 * 2^4 * ... instead of 2^5. It's term 1396 of aliquot sequence 1019430, and it looks like this breaks the DB's algorithm for calculating the sum of the factors, so subsequent terms are wrong.

Is posting this here the right way to report an error, or is there some other way?

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?

The workers have been busy... I'm pleased to report that all composites in the DB less than 92 digits (that are more than a couple hours old) have been factored. Not sure how many folks are contributing to this effort, but that's an awful lot of factoring!

[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....

[QUOTE=schickel;240143]Not good. Looks like the server may have dropped a table. We'll have to wait for Syd to fix this locally....[/QUOTE]
Well the server is currently offline for maintenance.

[QUOTE=henryzz;240236]Well the server is currently offline for maintenance.[/QUOTE]Back up, but still no elf files....:sad: