Loading ...
Sorry, an error occurred while loading the content.

Bad matrix: column 10059 = column 10060!

Expand Messages
  • Bob Backstrom
    Sorry if this has been answered in the ggnfs FAQ somewhere or other, but if it has I d appreciate a clue or two :-) It s the old horribly wrong , column a =
    Message 1 of 5 , Jan 2, 2007
    • 0 Attachment
      Sorry if this has been answered in the ggnfs FAQ somewhere or other,
      but if it has I'd appreciate a clue or two :-)

      It's the old "horribly wrong", "column a = column b" nonsense in
      matbuild and matsolve.

      See full screen-shot, below.

      Thanks,
      --Bob.


      ...
      readRelList : [ 100% done]
      Re-read 576772 relations from rels.bin.15 : [8651307, 9228079).
      Loading matrix into RAM...
      Matrix scanned: it should be 671352 x 760610.
      Found 8 dense blocks. Re-reading matrix...
      The dense blocks consist of the following sets of rows:
      [671288, 671351]
      [0, 63]
      [64, 127]
      [128, 191]
      [192, 255]
      [335440, 335503]
      [335504, 335567]
      [335568, 335631]
      Matrix loaded: it is 671352 x 760610.
      Warning: column 12160 is all zero!
      Warning: column 12163 is all zero!
      checkMat() did not like something about the matrix:
      This is probably a sign that something has gone horribly wrong
      in the matrix construction (matbuild).
      However, the number of bad columns is only 2,
      so we will delete them and attempt to continue.
      checkMat() returned an error! Attempting to continue...
      Initial matrix is 671352 x 760608 with sparse part having weight
      104030073.
      (total weight is 159241236)
      Matrix pruned to 629493 x 632913 with weight 88803044.....
      Sanity check: M.numCols = 632913 = C.numFields. passed.
      `depinf' written. You can now run matsolve.
      Total elapsed time: 2826.68 seconds.
      =>"../../bin/autogplot.sh" xprimes.jpg 'ExcessLargePrimes' .lprels
      =>"../../bin/autogplot.sh" relations.jpg 'TotalFF' .rels
      -> Doing matrix step...
      => "../../bin/matsolve"

      __________________________________________________________
      | This is the matsolve program for GGNFS. |
      | Version: 0.77.1-20060513-athlon-xp |
      | This program is copyright 2004, Chris Monico, and subject|
      | to the terms of the GNU General Public License version 2.|
      |__________________________________________________________|
      Using PRNG seed=766468631.
      Verifying column map...done.
      Matrix loaded: it is 629493 x 632913.
      Bad matrix: column 10059 = column 10060!
      Signal 11
      Return value 35584. Terminating...
      /cygdrive/f/ggnfs/tests/n01>
    • gchil0
      I ve found that that I have random matrix problems at times when maxrelsinff is set to 0 in factLat.pl. At times when there are barely enough relations to
      Message 2 of 5 , Jan 8, 2007
      • 0 Attachment
        I've found that that I have random matrix problems at times when
        maxrelsinff is set to 0 in factLat.pl. At times when there are barely
        enough relations to create a matrix and the auto-chosen maxrelsinff is
        in the high-40s or greater, the problems occur. I get around this by
        setting maxrelsinff to 42 or lower in factLat.pl, and only use 0
        during manual runs when I know there are more than enough relations.

        Greg

        --- In ggnfs@yahoogroups.com, "Bob Backstrom" <bobb7772004@...> wrote:
        >
        > Sorry if this has been answered in the ggnfs FAQ somewhere or other,
        > but if it has I'd appreciate a clue or two :-)
        >
        > It's the old "horribly wrong", "column a = column b" nonsense in
        > matbuild and matsolve.
        >
        > See full screen-shot, below.
        >
        > Thanks,
        > --Bob.
        >
        >
        > ...
        > readRelList : [ 100% done]
        > Re-read 576772 relations from rels.bin.15 : [8651307, 9228079).
        > Loading matrix into RAM...
        > Matrix scanned: it should be 671352 x 760610.
        > Found 8 dense blocks. Re-reading matrix...
        > The dense blocks consist of the following sets of rows:
        > [671288, 671351]
        > [0, 63]
        > [64, 127]
        > [128, 191]
        > [192, 255]
        > [335440, 335503]
        > [335504, 335567]
        > [335568, 335631]
        > Matrix loaded: it is 671352 x 760610.
        > Warning: column 12160 is all zero!
        > Warning: column 12163 is all zero!
        > checkMat() did not like something about the matrix:
        > This is probably a sign that something has gone horribly wrong
        > in the matrix construction (matbuild).
        > However, the number of bad columns is only 2,
        > so we will delete them and attempt to continue.
        > checkMat() returned an error! Attempting to continue...
        > Initial matrix is 671352 x 760608 with sparse part having weight
        > 104030073.
        > (total weight is 159241236)
        > Matrix pruned to 629493 x 632913 with weight 88803044.....
        > Sanity check: M.numCols = 632913 = C.numFields. passed.
        > `depinf' written. You can now run matsolve.
        > Total elapsed time: 2826.68 seconds.
        > =>"../../bin/autogplot.sh" xprimes.jpg 'ExcessLargePrimes' .lprels
        > =>"../../bin/autogplot.sh" relations.jpg 'TotalFF' .rels
        > -> Doing matrix step...
        > => "../../bin/matsolve"
        >
        > __________________________________________________________
        > | This is the matsolve program for GGNFS. |
        > | Version: 0.77.1-20060513-athlon-xp |
        > | This program is copyright 2004, Chris Monico, and subject|
        > | to the terms of the GNU General Public License version 2.|
        > |__________________________________________________________|
        > Using PRNG seed=766468631.
        > Verifying column map...done.
        > Matrix loaded: it is 629493 x 632913.
        > Bad matrix: column 10059 = column 10060!
        > Signal 11
        > Return value 35584. Terminating...
        > /cygdrive/f/ggnfs/tests/n01>
        >
      • Bob Backstrom
        ... Thanks Greg. I can t remember when I last played around with $maxRelsInFF in factLat.pl - probably over 12 months ago. No obvious benefits (long
        Message 3 of 5 , Jan 9, 2007
        • 0 Attachment
          --- In ggnfs@yahoogroups.com, "gchil0" <jgchilders@...> wrote:
          >
          > I've found that that I have random matrix problems at times when
          > maxrelsinff is set to 0 in factLat.pl. At times when there are
          > barely enough relations to create a matrix and the auto-chosen
          > maxrelsinff is in the high-40s or greater, the problems occur. I
          > get around this by setting maxrelsinff to 42 or lower in
          > factLat.pl, and only use 0 during manual runs when I know there
          > are more than enough relations.
          >
          > Greg

          Thanks Greg. I can't remember when I last played around with
          $maxRelsInFF in factLat.pl - probably over 12 months ago. No obvious
          benefits (long over-many relations found with great waste of time).

          My current value (the default, I think):

          $maxRelsInFF=28;

          No, what I *really* want is a one or two line :-) change to matsolve
          which will ignore the offending columns (like matbuild *says* it did)
          and go on to sqrt and the factors :-)

          Fingers crossed waiting to hear from someone who has *actually* done
          it.

          --Bob.

          > --- In ggnfs@yahoogroups.com, "Bob Backstrom" <bobb7772004@> wrote:
          > >
          > > Sorry if this has been answered in the ggnfs FAQ somewhere or
          other,
          > > but if it has I'd appreciate a clue or two :-)
          > >
          > > It's the old "horribly wrong", "column a = column b" nonsense in
          > > matbuild and matsolve.
          > >
          > > See full screen-shot, below.
          > >
          > > Thanks,
          > > --Bob.
          > >
          > >
          > > ...
          > > readRelList : [ 100% done]
          > > Re-read 576772 relations from rels.bin.15 : [8651307, 9228079).
          > > Loading matrix into RAM...
          > > Matrix scanned: it should be 671352 x 760610.
          > > Found 8 dense blocks. Re-reading matrix...
          > > The dense blocks consist of the following sets of rows:
          > > [671288, 671351]
          > > [0, 63]
          > > [64, 127]
          > > [128, 191]
          > > [192, 255]
          > > [335440, 335503]
          > > [335504, 335567]
          > > [335568, 335631]
          > > Matrix loaded: it is 671352 x 760610.
          > > Warning: column 12160 is all zero!
          > > Warning: column 12163 is all zero!
          > > checkMat() did not like something about the matrix:
          > > This is probably a sign that something has gone horribly wrong
          > > in the matrix construction (matbuild).
          > > However, the number of bad columns is only 2,
          > > so we will delete them and attempt to continue.
          > > checkMat() returned an error! Attempting to continue...
          > > Initial matrix is 671352 x 760608 with sparse part having weight
          > > 104030073.
          > > (total weight is 159241236)
          > > Matrix pruned to 629493 x 632913 with weight 88803044.....
          > > Sanity check: M.numCols = 632913 = C.numFields. passed.
          > > `depinf' written. You can now run matsolve.
          > > Total elapsed time: 2826.68 seconds.
          > > =>"../../bin/autogplot.sh" xprimes.jpg 'ExcessLargePrimes' .lprels
          > > =>"../../bin/autogplot.sh" relations.jpg 'TotalFF' .rels
          > > -> Doing matrix step...
          > > => "../../bin/matsolve"
          > >
          > > __________________________________________________________
          > > | This is the matsolve program for GGNFS. |
          > > | Version: 0.77.1-20060513-athlon-xp |
          > > | This program is copyright 2004, Chris Monico, and subject|
          > > | to the terms of the GNU General Public License version 2.|
          > > |__________________________________________________________|
          > > Using PRNG seed=766468631.
          > > Verifying column map...done.
          > > Matrix loaded: it is 629493 x 632913.
          > > Bad matrix: column 10059 = column 10060!
          > > Signal 11
          > > Return value 35584. Terminating...
          > > /cygdrive/f/ggnfs/tests/n01>
          > >
          >
        • Raghu Patil
          I faced this probelms many times, and found out that this happens beacuse some duplicates are still in the processed data (rels.bin s).The soloution is dump
          Message 4 of 5 , Jan 11, 2007
          • 0 Attachment
                I faced this probelms many times, and found out that this happens beacuse some duplicates are still in the processed data (rels.bin's).The soloution is  dump the rels.bin's to spairs.dump and rerun the procrels and then matbuild again with new rels.bin's.

            Thanks
            Raghu

            Bob Backstrom <bobb7772004@...> wrote:
            Sorry if this has been answered in the ggnfs FAQ somewhere or other,
            but if it has I'd appreciate a clue or two :-)

            It's the old "horribly wrong", "column a = column b" nonsense in
            matbuild and matsolve.

            See full screen-shot, below.

            Thanks,
            --Bob.

            ...
            readRelList : [ 100% done]
            Re-read 576772 relations from rels.bin.15 : [8651307, 9228079).
            Loading matrix into RAM...
            Matrix scanned: it should be 671352 x 760610.
            Found 8 dense blocks. Re-reading matrix...
            The dense blocks consist of the following sets of rows:
            [671288, 671351]
            [0, 63]
            [64, 127]
            [128, 191]
            [192, 255]
            [335440, 335503]
            [335504, 335567]
            [335568, 335631]
            Matrix loaded: it is 671352 x 760610.
            Warning: column 12160 is all zero!
            Warning: column 12163 is all zero!
            checkMat() did not like something about the matrix:
            This is probably a sign that something has gone horribly wrong
            in the matrix construction (matbuild).
            However, the number of bad columns is only 2,
            so we will delete them and attempt to continue.
            checkMat() returned an error! Attempting to continue...
            Initial matrix is 671352 x 760608 with sparse part having weight
            104030073.
            (total weight is 159241236)
            Matrix pruned to 629493 x 632913 with weight 88803044.... .
            Sanity check: M.numCols = 632913 = C.numFields. passed.
            `depinf' written. You can now run matsolve.
            Total elapsed time: 2826.68 seconds.
            =>"../../bin/ autogplot. sh" xprimes.jpg 'ExcessLargePrimes' .lprels
            =>"../../bin/ autogplot. sh" relations.jpg 'TotalFF' .rels
            -> Doing matrix step...
            => "../../bin/matsolve "

            ____________ _________ _________ _________ _________ _________ _
            | This is the matsolve program for GGNFS. |
            | Version: 0.77.1-20060513- athlon-xp |
            | This program is copyright 2004, Chris Monico, and subject|
            | to the terms of the GNU General Public License version 2.|
            |___________ _________ _________ _________ _________ _________ __|
            Using PRNG seed=766468631.
            Verifying column map...done.
            Matrix loaded: it is 629493 x 632913.
            Bad matrix: column 10059 = column 10060!
            Signal 11
            Return value 35584. Terminating. ..
            /cygdrive/f/ ggnfs/tests/ n01>



            Here’s a new way to find what you're looking for - Yahoo! Answers

          • Bob Backstrom
            ... Thanks, Raghu. I didn t try dumping and re-processing - I ve tried that many times in the past and the results are quite random. Sometimes they work but
            Message 5 of 5 , Jan 13, 2007
            • 0 Attachment
              --- In ggnfs@yahoogroups.com, Raghu Patil <raghupatil2004@...> wrote:
              >
              > I faced this probelms many times, and found out that
              > this happens beacuse some duplicates are still in the processed
              > data (rels.bin's).The soloution is dump the rels.bin's to
              > spairs.dump and rerun the procrels and then matbuild again with
              > new rels.bin's.
              >
              > Thanks
              > Raghu
              >
              >> Bob Backstrom <bobb7772004@...>Wrote:
              >> Sorry if this has been answered in the ggnfs FAQ somewhere or
              >> other, but if it has I'd appreciate a clue or two :-)

              Thanks, Raghu.

              I didn't try dumping and re-processing - I've tried that many times
              in the past and the results are quite random. Sometimes they work
              but mostly they give exactly the same results - matsolve crashes.

              Looking at the matsolve code:

              ...
              qsort(colHash, M->numCols, 2*sizeof(s32), cmp2L1);
              for (i=0; i<(M->numCols-1); i++) {
              if (colHash[2*i]==colHash[2*i+2]) {
              if (colsAreEqual(M, colHash[2*i+1], colHash[2*i+3])) {
              printf("Bad matrix: column %" PRId32 " = column %" PRId32 "!\n",
              colHash[2*i+1], colHash[2*i+3]);

              if (numDel < 2048)
              delCols[colHash[2*i+3]]=c;

              warn=2;
              }
              }
              }
              ...

              it seems that the numDel < 2048 test is supposed to prevent overflow
              in the 2048-length matrix delCols, but what relation does numDel have
              to the value of colHash[2*i+3] I wonder ? None by this code !

              This *precise* line (delCols ... = c) is where the matsolve crash
              occurs, which means that colHash[2*i+3] is probably *much* larger
              than 2048.

              See matsolve.exe.stackdump:

              Exception: STATUS_ACCESS_VIOLATION at eip=004017FD
              eax=0009A851 ebx=03DA0BC0 ecx=00000000 edx=00000029 esi=0000274B
              edi=0000274C ebp=0002E177 esp=0022E810
              program=f:\ggnfs\bin\matsolve.exe, pid 2628, thread main
              cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
              Stack trace:
              Frame Function Args
              2 [main] matsolve 2628 handle_exceptions: Error while dumping
              state (probably corrupted stack)

              ---------------------------------------------

              Commenting out the "if (numDel < 2048) test and setting the warn=2"
              allowed matsolve to complete correctly. The column deletion has
              obviously been proved to be unnecessary :-)

              Oh, and the factors of the number 13*2^603+1, c139 = p48 * p92

              [12/09 00:11:59] GGNFS-0.77.1-20060513-athlon-xp : makefb
              [12/09 00:12:05] name: KL_C139_13,603+
              [12/09 00:12:05] n=959339592441565014426199781571456728845632553
              2981920295359029795661567506770305416572033026463947840121031630
              146932414492867376155336051861 (139 digits)

              ...
              [Long delay between drinks]
              ...

              [01/14 03:03:05] From dependence 4, sqrt obtained:
              [01/14 03:03:05] r1=53099638947458342372050434255014882923351876
              9933 (pp48)
              [01/14 03:03:05] r2=18066781836140612558581760957136347685940200
              789910840123251095798326313277904731506476911017 (pp92)
              [01/14 03:03:05] (pp=probable prime, c=composite)
              [01/14 03:03:05] sqrtTime: 928.6

              --Bob.
            Your message has been successfully submitted and would be delivered to recipients shortly.