strange thing happening in factordb

[henryzz]

The new multicore linux version should do that sort of number in a few months without much effort.
There is not much chance of us reaching that sort of level any time soon though. 3000 digits might be a nice place to aim for.

[EdH]

On one of my machines the 135x digit numbers are averaging less than 9 minutes, per. On the other one, they're averaging less than 14 minutes. Of course that says nothing of the processors/memory in use. My first machine is AMD Athlon 64 3GHz dual core, 2G mem and the second one is Pentium 64 2.5GHz dual core, 2G mem. If it is of interest, the certificates that the db provides have the time it took to run them. But, without machine info, I suppose it's just an interesting bit of trivia.

@henryzz: I had wondered why no new 1000-13xx numbers were appearing behind me.

[wblipp]

The latest garbage flooding seems to be 1000 digit numbers. There are a few hundred new PRPs in the high 900 digits. Clicking "more information", these all appear to have come from 1000 digit composites the differ only in a few digits near the middle of the number.

[wblipp]

Today's flood is 10^n-4198862272127.

[wblipp]

In the last 12 hours the number of unfactored composites through 120 digits has jumped from 160K to 250K. Many of these are below 70 digits, where the factordb is automatically factoring them, but they have arrived much faster than factoring can keep up. Sampling these, it looks like they are all in the range of Brent composites (a^n +/- 1, a and n < 10000). The Odd Perfect Number search has been interested in the minus cases where a and n are both prime, but these seem to be the entire Brent range.

One possibility is that somebody has decided to load Brent's entire table, and these are the incompletely factored numbers. Another possibility is that somebody is busy running factor tables to generate all of these. Does anybody know?

[jcrombie]

Originally Posted by wblipp

In the last 12 hours the number of unfactored composites through 120 digits has jumped from 160K to 250K. Many of these are below 70 digits, where the factordb is automatically factoring them, but they have arrived much faster than factoring can keep up. Sampling these, it looks like they are all in the range of Brent composites (a^n +/- 1, a and n < 10000). The Odd Perfect Number search has been interested in the minus cases where a and n are both prime, but these seem to be the entire Brent range.

One possibility is that somebody has decided to load Brent's entire table, and these are the incompletely factored numbers. Another possibility is that somebody is busy running factor tables to generate all of these. Does anybody know?

Yesterday I passed on to Syd my t20 effort for all Brent composites from base 1001 to base 9999. They were also passed on to Prof. Brent, but have yet to appear in his factors.gz file. Mystery solved?

[smh]

It's over 278K now. I started worker for 67 digits, but composites are added much faster than i can facor them.

They all have small factors so I guess somebody is generating the tables instead of uploading the factorizations.

Refactoring the small composites is probably, but for the bigger composites it would be nice if someone can upload the know factorizations instead of refactoring them all.

[jcrombie]

Originally Posted by smh

It's over 278K now. I started worker for 67 digits, but composites are added much faster than i can facor them.

They all have small factors so I guess somebody is generating the tables instead of uploading the factorizations.

Refactoring the small composites is probably, but for the bigger composites it would be nice if someone can upload the know factorizations instead of refactoring them all.

There might be two reasons for the small factors.

One is that I just passed on my Brent factors (see my post above) and they are all greater than 10^9 as per his requirement.

And also, I did not pass on any algebraic factors. Maybe there are some small algebraic factors present?

[wblipp]

Originally Posted by jcrombie

Yesterday I passed on to Syd my t20 effort for all Brent composites from base 1001 to base 9999. They were also passed on to Prof. Brent, but have yet to appear in his factors.gz file. Mystery solved?

Thanks. It's a relief to know this surge represents the integration of extensive factoring external to the factordb, unlike some other events that were mindless drains on the factordb's resources for the amusement of seeing the resources get clogged.

[firejuggler]

I encourage prople to run "the" yafu perl script

#!/bin/perl

use warnings;
use strict;
use LWP::Simple;

while(1){
    print "get composites\n";
    my $rand=int(rand(1000));
    my $contents = get("http://factorization.ath.cx/listtype.php?t=3&mindig=60&maxdig=80&perpage=1&start=$rand&download=1");
    if (!defined $contents or $contents =~ /[a-z]/ ){
        print "$contents\n";
        print "Error, no composites fetched\n";
        sleep(60);
    }
    
    my @composites=split(/\s/, $contents);
    foreach my $composite (@composites) {
        print "Factoring ".length($composite)." digits: $composite\n";
        my @results;
        open(YAFU, "yafu factor($composite) |") or die "Couldn't start yafu!";
        while (<YAFU>) {
                print "$_";
                chomp;
            if (/^[CP].*? = (\d+)/) {
              push( @results, $1 );
            print "*****\n";
          }
        }
        close(YAFU);
        
        if ( scalar(@results) > 0 ) {
            print "===========================================================================\n";
            print "report factors\n";
            my $url="http://factorization.ath.cx/report.php?report=".$composite."%3D".join('*',@results);
            #print "$url\n";
            $contents=get($url);
            #print "$contents\n";

      my $nofactors     = ($contents =~ s/Does not divide//g);
      my $already_known = ($contents =~ s/Factor already known//g);
      my $added         = ($contents =~ s/Factor added//g);
      my $small         = ($contents =~ s/Small factor//g);

      print "\tNew factors added:        " . ($added         ? $added         : 0) . "\n";
      print "\tFactors already known:    " . ($already_known ? $already_known : 0) . "\n";
      print "\tSmall factors:            " . ($small         ? $small         : 0) . "\n";
      print "\tErrors (does not divide): " . ($nofactors     ? $nofactors     : 0) . "\n";
      print "===========================================================================\n";
        }else {
            print "Error, no result found\n";
            sleep(60);
        }
    }
}
die;

[jcrombie]

Originally Posted by wblipp

Thanks. It's a relief to know this surge represents the integration of extensive factoring external to the factordb, unlike some other events that were mindless drains on the factordb's resources for the amusement of seeing the resources get clogged.

Well, the idea was to just pass on my Brent factors directly to Syd instead of him getting them from Prof. Brent. Syd (aka Markus) is the one actually putting them in. Yes, I would also hate to see anything bad happen to this great resource!

Jonathan