On Fri, Nov 27, 2009 at 2:11 PM, torbjornalm <talm@...> wrote:

> I am unning a gnfs with 132 digits.
> When mprime decided that enough relations was found and
> gnerated a matrix, it ended up like this.
> How do I get factMsieve to run more relations?

If you are running a recent version of factMsieve.pl you can create a
file called MINRELS.txt in the directory you have your sieving data
files in.  Just put an integer on the first line of the text file.

So if you have say 5000000 relations now and you want it to sieve up
to 6000000 then create a MINRELS.txt file with this content:

6000000

Then it should keep going without calling msieve until you get 6M relations.

Jeff.

I am unning a gnfs with 132 digits.
When mprime decided that enough relations was found and
gnerated a matrix, it ended up like this.
How do I get factMsieve to run more relations?

	 LatSieveTime: 1848
Fri Nov 27 06:42:11 2009
Fri Nov 27 06:42:11 2009
Fri Nov 27 06:42:11 2009  Msieve v. 1.42
Fri Nov 27 06:42:11 2009  random seeds: a3a74980 55d20521
Fri Nov 27 06:42:11 2009  factoring
82216556616613853870730513579814442645798550869595037688886743007132493685639213\
1830862427459377077333233737916217042716402599126613 (132 digits)
Fri Nov 27 06:42:12 2009  searching for 15-digit factors
Fri Nov 27 06:42:13 2009  commencing number field sieve (132-digit input)
Fri Nov 27 06:42:13 2009  R0: -21194483739316555423158216
Fri Nov 27 06:42:13 2009  R1:  422110236873829
Fri Nov 27 06:42:13 2009  A0:  5323181164618050554928321187225
Fri Nov 27 06:42:13 2009  A1:  560054811007657416094390185
Fri Nov 27 06:42:13 2009  A2: -567437746939500803211
Fri Nov 27 06:42:13 2009  A3: -86064614577713393
Fri Nov 27 06:42:13 2009  A4:  29208188490
Fri Nov 27 06:42:13 2009  A5:  192240
Fri Nov 27 06:42:13 2009  skew 202411.95, size 7.654925e-013, alpha -5.916427,
combined = 5.059846e-011
Fri Nov 27 06:42:13 2009
Fri Nov 27 06:42:13 2009  commencing relation filtering
Fri Nov 27 06:42:13 2009  estimated available RAM is 2002.2 MB
Fri Nov 27 06:42:13 2009  commencing duplicate removal, pass 1
Fri Nov 27 06:44:45 2009  error -15 reading relation 11690594
Fri Nov 27 06:44:46 2009  error -15 reading relation 11700485
Fri Nov 27 06:44:46 2009  error -11 reading relation 11710519
Fri Nov 27 06:44:46 2009  found 2343909 hash collisions in 11720359 relations
Fri Nov 27 06:45:09 2009  added 32 free relations
Fri Nov 27 06:45:09 2009  commencing duplicate removal, pass 2
Fri Nov 27 06:46:21 2009  found 2326792 duplicates and 9393599 unique relations
Fri Nov 27 06:46:21 2009  memory use: 82.6 MB
Fri Nov 27 06:46:21 2009  reading ideals above 10420224
Fri Nov 27 06:46:25 2009  commencing singleton removal, initial pass
Fri Nov 27 06:48:47 2009  memory use: 149.2 MB
Fri Nov 27 06:48:47 2009  reading all ideals from disk
Fri Nov 27 06:48:55 2009  memory use: 168.4 MB
Fri Nov 27 06:48:56 2009  commencing in-memory singleton removal
Fri Nov 27 06:48:57 2009  begin with 9393598 relations and 8729410 unique ideals
Fri Nov 27 06:49:05 2009  reduce to 4439191 relations and 3069005 ideals in 18
passes
Fri Nov 27 06:49:05 2009  max relations containing the same ideal: 30
Fri Nov 27 06:49:06 2009  reading ideals above 100000
Fri Nov 27 06:49:06 2009  commencing singleton removal, initial pass
Fri Nov 27 06:51:10 2009  memory use: 74.6 MB
Fri Nov 27 06:51:10 2009  reading all ideals from disk
Fri Nov 27 06:51:17 2009  memory use: 170.7 MB
Fri Nov 27 06:51:18 2009  keeping 4445465 ideals with weight <= 200, target
excess is 24871
Fri Nov 27 06:51:19 2009  commencing in-memory singleton removal
Fri Nov 27 06:51:20 2009  begin with 4469036 relations and 4445465 unique ideals
Fri Nov 27 06:51:29 2009  reduce to 4411061 relations and 4377901 ideals in 10
passes
Fri Nov 27 06:51:29 2009  max relations containing the same ideal: 200
Fri Nov 27 06:51:35 2009  relations with 0 large ideals: 80
Fri Nov 27 06:51:35 2009  relations with 1 large ideals: 35
Fri Nov 27 06:51:35 2009  relations with 2 large ideals: 370
Fri Nov 27 06:51:35 2009  relations with 3 large ideals: 4612
Fri Nov 27 06:51:35 2009  relations with 4 large ideals: 38171
Fri Nov 27 06:51:35 2009  relations with 5 large ideals: 186693
Fri Nov 27 06:51:35 2009  relations with 6 large ideals: 581694
Fri Nov 27 06:51:35 2009  relations with 7+ large ideals: 3599406
Fri Nov 27 06:51:35 2009  commencing 2-way merge
Fri Nov 27 06:51:42 2009  reduce to 2801548 relation sets and 2768403 unique
ideals
Fri Nov 27 06:51:42 2009  ignored 20 oversize relation sets
Fri Nov 27 06:51:42 2009  commencing full merge
Fri Nov 27 06:52:58 2009  memory use: 300.9 MB
Fri Nov 27 06:52:59 2009  found 1454949 cycles, need 1454603
Fri Nov 27 06:52:59 2009  weight of 1454603 cycles is about 102162751
(70.23/cycle)
Fri Nov 27 06:52:59 2009  distribution of cycle lengths:
Fri Nov 27 06:52:59 2009  1 relations: 169073
Fri Nov 27 06:52:59 2009  2 relations: 204905
Fri Nov 27 06:52:59 2009  3 relations: 189097
Fri Nov 27 06:52:59 2009  4 relations: 164005
Fri Nov 27 06:52:59 2009  5 relations: 141671
Fri Nov 27 06:52:59 2009  6 relations: 114634
Fri Nov 27 06:52:59 2009  7 relations: 94061
Fri Nov 27 06:52:59 2009  8 relations: 75614
Fri Nov 27 06:52:59 2009  9 relations: 60708
Fri Nov 27 06:52:59 2009  10+ relations: 240835
Fri Nov 27 06:52:59 2009  heaviest cycle: 28 relations
Fri Nov 27 06:53:00 2009  commencing cycle optimization
Fri Nov 27 06:53:03 2009  start with 8347555 relations
Fri Nov 27 06:53:25 2009  pruned 224446 relations
Fri Nov 27 06:53:25 2009  memory use: 213.0 MB
Fri Nov 27 06:53:25 2009  distribution of cycle lengths:
Fri Nov 27 06:53:25 2009  1 relations: 169073
Fri Nov 27 06:53:25 2009  2 relations: 209421
Fri Nov 27 06:53:25 2009  3 relations: 196771
Fri Nov 27 06:53:25 2009  4 relations: 168430
Fri Nov 27 06:53:25 2009  5 relations: 144387
Fri Nov 27 06:53:25 2009  6 relations: 115143
Fri Nov 27 06:53:25 2009  7 relations: 93720
Fri Nov 27 06:53:25 2009  8 relations: 74280
Fri Nov 27 06:53:25 2009  9 relations: 59145
Fri Nov 27 06:53:25 2009  10+ relations: 224233
Fri Nov 27 06:53:25 2009  heaviest cycle: 28 relations
Fri Nov 27 06:53:34 2009  RelProcTime: 681
Fri Nov 27 06:53:34 2009  elapsed time 00:11:23
Fri Nov 27 06:53:35 2009
Fri Nov 27 06:53:35 2009
Fri Nov 27 06:53:35 2009  Msieve v. 1.42
Fri Nov 27 06:53:35 2009  random seeds: 74daaa44 2789e746
Fri Nov 27 06:53:35 2009  factoring
82216556616613853870730513579814442645798550869595037688886743007132493685639213\
1830862427459377077333233737916217042716402599126613 (132 digits)
Fri Nov 27 06:53:36 2009  searching for 15-digit factors
Fri Nov 27 06:53:37 2009  commencing number field sieve (132-digit input)
Fri Nov 27 06:53:37 2009  R0: -21194483739316555423158216
Fri Nov 27 06:53:37 2009  R1:  422110236873829
Fri Nov 27 06:53:37 2009  A0:  5323181164618050554928321187225
Fri Nov 27 06:53:37 2009  A1:  560054811007657416094390185
Fri Nov 27 06:53:37 2009  A2: -567437746939500803211
Fri Nov 27 06:53:37 2009  A3: -86064614577713393
Fri Nov 27 06:53:37 2009  A4:  29208188490
Fri Nov 27 06:53:37 2009  A5:  192240
Fri Nov 27 06:53:37 2009  skew 202411.95, size 7.654925e-013, alpha -5.916427,
combined = 5.059846e-011
Fri Nov 27 06:53:37 2009
Fri Nov 27 06:53:37 2009  commencing linear algebra
Fri Nov 27 06:53:37 2009  read 1454603 cycles
Fri Nov 27 06:53:40 2009  cycles contain 4320509 unique relations
Fri Nov 27 06:55:00 2009  read 4320509 relations
Fri Nov 27 06:55:07 2009  using 20 quadratic characters above 134217530
Fri Nov 27 06:55:30 2009  building initial matrix
Fri Nov 27 06:56:37 2009  memory use: 505.7 MB
Fri Nov 27 06:56:44 2009  read 1454603 cycles
Fri Nov 27 06:56:49 2009  matrix is 1454425 x 1454603 (412.1 MB) with weight
135450287 (93.12/col)
Fri Nov 27 06:56:49 2009  sparse part has weight 97846832 (67.27/col)
Fri Nov 27 06:57:09 2009  filtering completed in 2 passes
Fri Nov 27 06:57:09 2009  matrix is 1454258 x 1440582 (411.7 MB) with weight
135442010 (94.02/col)
Fri Nov 27 06:57:09 2009  sparse part has weight 97844105 (67.92/col)
Fri Nov 27 06:57:53 2009  read 1440582 cycles
Fri Nov 27 07:00:07 2009  matrix is 1454258 x 1440582 (411.7 MB) with weight
135442010 (94.02/col)
Fri Nov 27 07:00:07 2009  sparse part has weight 97844105 (67.92/col)
Fri Nov 27 07:00:07 2009  matrix must have more columns than rows
Fri Nov 27 19:57:37 2009
Fri Nov 27 19:57:37 2009
Fri Nov 27 19:57:37 2009  Msieve v. 1.42
Fri Nov 27 19:57:37 2009  random seeds: 62068c00 9d8d1237
Fri Nov 27 19:57:37 2009  factoring
82216556616613853870730513579814442645798550869595037688886743007132493685639213\
1830862427459377077333233737916217042716402599126613 (132 digits)
Fri Nov 27 19:57:38 2009  searching for 15-digit factors
Fri Nov 27 19:57:38 2009  commencing number field sieve (132-digit input)
Fri Nov 27 19:57:38 2009  R0: -21194483739316555423158216
Fri Nov 27 19:57:38 2009  R1:  422110236873829
Fri Nov 27 19:57:38 2009  A0:  5323181164618050554928321187225
Fri Nov 27 19:57:38 2009  A1:  560054811007657416094390185
Fri Nov 27 19:57:38 2009  A2: -567437746939500803211
Fri Nov 27 19:57:38 2009  A3: -86064614577713393
Fri Nov 27 19:57:38 2009  A4:  29208188490
Fri Nov 27 19:57:38 2009  A5:  192240
Fri Nov 27 19:57:38 2009  skew 202411.95, size 7.654925e-013, alpha -5.916427,
combined = 5.059846e-011
Fri Nov 27 19:57:38 2009
Fri Nov 27 19:57:38 2009  commencing linear algebra
Fri Nov 27 19:57:39 2009  read 1440582 cycles
Fri Nov 27 19:57:42 2009  cycles contain 4306192 unique relations
Fri Nov 27 19:58:53 2009  read 4306192 relations
Fri Nov 27 19:59:01 2009  using 20 quadratic characters above 134217530
Fri Nov 27 19:59:24 2009  building initial matrix
Fri Nov 27 20:00:29 2009  memory use: 503.9 MB
Fri Nov 27 20:00:31 2009  read 1440582 cycles
Fri Nov 27 20:00:35 2009  matrix is 1454258 x 1440582 (411.7 MB) with weight
135442010 (94.02/col)
Fri Nov 27 20:00:58 2009  sparse part has weight 97844105 (67.92/col)
Fri Nov 27 20:01:10 2009  filtering completed in 1 passes
Fri Nov 27 20:01:11 2009  matrix is 1454258 x 1440582 (411.7 MB) with weight
135442010 (94.02/col)
Fri Nov 27 20:01:11 2009  sparse part has weight 97844105 (67.92/col)
Fri Nov 27 20:01:55 2009  read 1440582 cycles
Fri Nov 27 20:02:05 2009  matrix is 1454258 x 1440582 (411.7 MB) with weight
135442010 (94.02/col)
Fri Nov 27 20:02:05 2009  sparse part has weight 97844105 (67.92/col)
Fri Nov 27 20:02:05 2009  matrix must have more columns than rows

Torbjörn Alm

On Tue, Nov 24, 2009 at 8:34 PM, Jason Papadopoulos <jasonp@...> wrote:
> Quoting Al Edwards <alwards@...>:
>
>> Is there some sort of academic assignment or competition to crack 150-digit
>> numbers? (There seem to be a lot of questions about 150-digit GNFS on a
>> couple of different places these past few days.)
>
> If you said 154-digit or 155-digit, everyone would get suspicious you
> were cracking an RSA key.

Is that to be discouraged? :)  Come on, 512 bit keys?  Who'd be silly enough to
use a key that small?  Texas is big, you'd think they'd have big keys. :)

Cheers,
David

Quoting Al Edwards <alwards@...>:

> Is there some sort of academic assignment or competition to crack 150-digit
> numbers? (There seem to be a lot of questions about 150-digit GNFS on a
> couple of different places these past few days.)

If you said 154-digit or 155-digit, everyone would get suspicious you
were cracking an RSA key.

------------------------------------------------------
This message was sent using BOO.net's Webmail.
http://www.boo.net/

hello, im trying to factor a 150 digit number, i wan wondering about how many
relations this will need, its been running for a few days and has about 20
million relations, any idea on how many more will be needed?

--- In ggnfs@yahoogroups.com,
"fjuno37" <fjuno37@...> wrote:

> I am currently factoring a 150-digit composite number
> for the form 10^420 + 1

Namely:

  {print(#Str(subst(polcyclo(840),x,10)/
  (134401*575794801*67501680066009758096678991121)));}

150

Good luck

David

--- In ggnfs@yahoogroups.com, Freddie Witherden <freddie@...> wrote:
>
> Hi,
>
> > You can always use the 'kill -STOP <pid>' and 'kill -CONT <pid>'
> > commands at a unix
> > shell prompt to stop and continue the process.  This will cause it to
> > no longer use any
> > CPU--plus it will page out if memory is needed.  Maybe a quick cron
> > script to stop/start
>
> Yes, that seems to be just what I need!
>
> I've been playing around with some smaller numbers first -- just to get my
> bearings.
>
> It seems simple to divide up the polynomial selection between multiple
> systems. However, I am unsure how to select the 'best' polynomial. The polysel
> utility that it part of ggnfs seems ideal, but I can not figure out the
correct
> usage of it.
>
> I have a load of polynomials (produced by msieve and then concatenated) along
> with 'n', but can not work out the correct calling convention for the program.
>
> In addition, is there an easy way of gauging if the best polynomial thus far
> is 'good enough'? Is anyone experienced with this?
>
> Other than that everything seems quite well -- msieve is compiled nicely on my
> GNU/Linux and OS X boxes (with the appropriate -march) and the experimental/
> lattice sieve virtually doubles the number of rels/sec for my Core 2 systems.
>
> It is my ultimate aim -- sometime over the Summer -- to write a Python script
> to provide native support for distributing calculations. My current idea is to
> use ssh:// (and by extension the fish:// protocol) for invoking the required
> binaries on target systems) reducing the amount of manual labour required.
>
> Regards, Freddie.
>


Great! Hello, this is the Juno stating that I am currently factoring a 150-digit
composite number for the form 10^420 + 1 and I understood the point of this
advice.

On Saturday 21 November 2009 18:51:58 Al Edwards wrote:
> I have 12 AMD Opteron cores averaging 2.3 GHz, and I run 64-bit Linux so as
>  to use the faster 64-bit lattice sievers and GMP-ECM. The C158 was not
>  bad:

Does GMP-ECM help with polynomial selection? I thought it was just used to
knock-out small factors?

Finally, when selecting the range to sieve did you just divide up the one
msieve deduced by 4?

Regards, Freddie.

Hello,

On Saturday 21 November 2009 16:38:36 i gad wrote:
> i have problem in compiling the source code for sieve file in GNFS
> ihave dev c++ ,vista

In order to help resolve your problem we are going to require some more
information. Firstly, what file is giving you compiler errors and what form do
these errors take?

Secondly, it is my understanding that dev-c++ has not been updated in a *long*
term. It is therefore likely to come with a very old version of MinGW (3.x).
This may be the source of your compiler errors. In addition, newer versions
are *much* faster (i.e, they produce more efficient code). Try installing MinGW
4.4.

Thirdly, GGNFS appears to come with a build file for MSVC. Microsoft now make
the express edition of Visual Studio available freely. Hence it might be worth
trying to compile GGNFS that way.

Fourthly, I believe Windows binaries are available from the sourceforge page.
These may well be sufficient for your purposes.

(It is probably worth pointing out that I am not a Windows user -- and so may
not be able to offer you any further assistance -- nor can I guarantee that my
knowledge is up-to-date. :)

Regards, Freddie.

Quoting Freddie Witherden <freddie@...>:

> Okay. So my current plan is to run a load of msieve instances (one-per-core-
> per-system). However, msieve auto-selects a range between [0,n] for me for a
> given number. Is it worth me splicing the range so that each system gets its
> own range? Or is the search-space large enough that the chances of two
> systems (randomly) trying the same polynomial are unlikely?

Msieve's poly selector does not randomize anything when given a range of
coefficients to search, so you will crunch the same numbers multiple times.
For very large problems there would probably be some benefit in randomizing
the search space, it's on my todo list.

jasonp


------------------------------------------------------
This message was sent using BOO.net's Webmail.
http://www.boo.net/

On Friday 20 November 2009 23:25:32 Al Edwards wrote:
> Most just run the polynomial selection process for a fixed percentage of
>  the time they project the whole process will take. I usually use 5% of the
>  sieving time as a number. As you do a few of these, you'll pile of a list
>  of e values which constitute good enough for numbers of various
>  magnitudes. I don't even bother anymore - mine's zipped up somewhere on a
>  backup drive - as I just run the selection process for however long is
>  appropriate for the number at hand. The good polynomials are not uniformly
>  distributed. I ran 6 core-weeks of selection for a C158, and found good
>  ones only at the very beginning and the very end of the process. This is
>  why you'll hear many people say that it's better to err on the side of too
>  much searching than too little.

Okay. So my current plan is to run a load of msieve instances (one-per-core-
per-system). However, msieve auto-selects a range between [0,n] for me for a
given number. Is it worth me splicing the range so that each system gets its
own range? Or is the search-space large enough that the chances of two systems
(randomly) trying the same polynomial are unlikely?

Other than that, I think I've got the whole polynomial selection bit sussed.
Thank you very much for your help!

Regards, Freddie.

P.S. How did C158 go? Is it feasible with modern hardware?

i have problem in compiling the source code for sieve file in GNFS
ihave dev c++ ,vista

Hi,

> You can always use the 'kill -STOP <pid>' and 'kill -CONT <pid>'
> commands at a unix
> shell prompt to stop and continue the process.  This will cause it to
> no longer use any
> CPU--plus it will page out if memory is needed.  Maybe a quick cron
> script to stop/start

Yes, that seems to be just what I need!

I've been playing around with some smaller numbers first -- just to get my
bearings.

It seems simple to divide up the polynomial selection between multiple
systems. However, I am unsure how to select the 'best' polynomial. The polysel
utility that it part of ggnfs seems ideal, but I can not figure out the correct
usage of it.

I have a load of polynomials (produced by msieve and then concatenated) along
with 'n', but can not work out the correct calling convention for the program.

In addition, is there an easy way of gauging if the best polynomial thus far
is 'good enough'? Is anyone experienced with this?

Other than that everything seems quite well -- msieve is compiled nicely on my
GNU/Linux and OS X boxes (with the appropriate -march) and the experimental/
lattice sieve virtually doubles the number of rels/sec for my Core 2 systems.

It is my ultimate aim -- sometime over the Summer -- to write a Python script
to provide native support for distributing calculations. My current idea is to
use ssh:// (and by extension the fish:// protocol) for invoking the required
binaries on target systems) reducing the amount of manual labour required.

Regards, Freddie.

On Wed, Nov 18, 2009 at 2:28 PM, Freddie Witherden
<freddie@...> wrote:
> # Also, trying to exit with Ctrl-C doesn't seem to work correctly.
>
> Does this make it impossible to suspend/resume the sieving operation?

Freddie,

You can always use the 'kill -STOP <pid>' and 'kill -CONT <pid>'
commands at a unix
shell prompt to stop and continue the process.  This will cause it to
no longer use any
CPU--plus it will page out if memory is needed.  Maybe a quick cron
script to stop/start
it during given hours will help you?

Cheers,
David

On Wednesday 18 November 2009 18:38:04 Al Edwards wrote:
> Even the polynomial selection can now be parallelized: msieve can be run on
>  different coefficient ranges simultaneously.
Yes, I think I remember seeing that when I ran msieve --help (the [X,Y]
range). However, how should one go about determining the overall range (is it
0..Y or X..Y and is the relationship linear, i.e, if the range is halved does
the respective time also half?)

In addition will multiple output files be generated automatically and what
about selecting the overall 'best' polynomial?

>  As for ggnfs, you can use the
>  script to run the lattice-sieving, or call the lattice sievers yourself
>  using the syntax: gnfs-lasieve4I14e -r foo.poly -f 8000000 -c 500000 -o
>  80_85R
> to sieve over rational special-q (use -a to sieve over algebraic ones) from
>  8 million to 8.5 million.
What is the difference between the two? (From math analysis I know the
difference between the rational, Q, and algebraic, A fields -- but am unsure how
they relate to the sieving process.

>  Once you have sieved for the relations, you
>  should use msieve for the post-processing, linear algebra, and square
>  root. See the factMsieve.pl script for details. (This may be incorporated
>  into the factLat.pl script in the latest subversion - I haven't checked in
>  a while.) Anyway, I have just given an outline.
They still appear to be distinct files. Browsing through the source for
factMsieve (W.R.T. multiple lattice sieves):

# Also, trying to exit with Ctrl-C doesn't seem to work correctly.

Does this make it impossible to suspend/resume the sieving operation?

Regards, Freddie.

Hi all,

As inferred from the subject I am interested in factoring an ~150 digit
composite (p*q where p and q are prime; p != q). It is my understanding that
by using GGNFS and Msieve that this is possible in the ~2 month range with
high-end commodity hardware.

(Firepower wise I have 7 GNU/Linux Core 2 systems with between 2-8GiB of
memory each with a 1GBit/s backbone.)

While I have some experience using Mseieve w/QS factoring a 113 digit number I
am quite new to GGNFS and the use of multiple systems/cores to accelerate the
process.

I have successfully compiled/run the SVN versions of both GGNFS and Msieve.
Following the advice given in [1] I have successfully factored some smaller
numbers given in the tests directory for GGNFS.

From what I can discern, in order to factor a 150+ digit number one needs to:
1) Use Msieve to select a polynomial, running it for as long as possible. This
can only be performed on a single system.

2) Use GGNFS to sieve the polynomial and 'solve' the resulting matrix. Sieving
can be easily distributed, matrix solving can not and is memory intensive.

However, I am unsure how to divide up the workload, some of the systems (non-
servers) are not always available and so being able to Ctrl+C and then resume
is seemingly required.

Does anyone have any experience on factoring a number of this magnitude, and
if so what advice can you give me. How did you divide up the workload? Was NFS
(network file system!) or SMB used or were files just copied? I have found some
good information over at http://www.mersenneforum.org but nothing definitive.

[1] http://gilchrist.ca/jeff/factoring/nfs_beginners_guide.html

Regards, Freddie.

On Tue, Nov 17, 2009 at 12:43 AM, H.M.B. Ibrahim <hmb.ibrahim@...> wrote:

> I would be thankful if someone provide me the estimated time to run GGNFS on
different integers.
> You can fix any machine, for example core2 due 2.ghz. and changes the size of
the input , for
> example 100, 110,120, 130, 140, 150. I want this information because I teach
computational
> number theory in math. depart, cairo, egypt.

You can get good estimates from these graphs here:
http://homepage2.nifty.com/m_kamada/math/graphs.htm

There are total time graphs for both GNFS and SFNS,   The GNFS graph
will show you the numbers you want, GNFS difficulty of 150 = 150
digits.

Jeff.

Dear Chris,

Did you have time to make it work?
We will gladly help to hammer on it and try to find and (possibly try to help
to) fix some bugs. Block Wiedemann implementation is of particular interest.
This is priceless.

However, real life should take precedence, so please don't take it as any bit of
pressure. If it's too early, then so it is. No problem.

Thank you in advance,

-Serge

--- In ggnfs@yahoogroups.com, "monico.chris" <monico.chris@...> wrote:
>
> Hello all,
>   Just wanted to let you all know that I finally plan to release a
> beta 1.0 version of GGNFS in the near future. The post-processing
> changes are all quite radical, with a near complete rewrite of
> everything. Notable changes will include:
> ...
> (4) A multi-threaded block Wiedemann implementation for multicore
> chips (I've had a multi-threaded Lanczos implementation lying around
> for a while, but I think I lost interest before hammering out
> all the kinks. Anyway, I think this should be a little better).
> ...
>
>   My hope is to have something beta out within a couple of months;
> perhaps sooner, possibly a little later. But I have a few specific
> experiments I'd like to do, so it will get done. Anyway, just wanted
> to drop a quick little note.
>
> Happy factoring!
> Chris
>

Hi,

I am currently running the command:
perl factmsieve.pl ..\..\example.n

and factmsieve.pl is running pol51opt and pol51m0b searching for leading
coefficients.

If there is a power failure, or I decide to interupt the script, how can I
resume it, so that it will continue searching for leading coefficients?

Please advise.

Thank you.