Running GGNFS

[jasonp]

v1.40 will print all the intermediate polynomials to msieve.dat.p in GGNFS format but I have not changed the parsing code to read polynomials in GGNFS format. IMO the two codebases should not have to be 100% format-compatible.

[Jeff Gilchrist]

Originally Posted by jasonp

v1.40 will print all the intermediate polynomials to msieve.dat.p in GGNFS format but I have not changed the parsing code to read polynomials in GGNFS format. IMO the two codebases should not have to be 100% format-compatible.

I totally agree, I was talking more about changing the factMsieve.pl perl script to be able to understand both GGNFS and msieve format polynomials not change the msieve program itself.

henryzz pointed out that lots would be changing but if you are just changing the internals and now how the polynomial is output at the end or in the msieve.fb file, then it doesn't matter what we change in the perl script.

[miklin]

Originally Posted by Jeff Gilchrist

Instead of posting a link to a specific binary each time, I have made a web page that will always contain my latest compiled Windows binaries of GGNFS (and other like GMP-ECM and msieve). You can find those here:
http://gilchrist.ca/jeff/factoring/

Does not work ggnfs-svn334-win64-core2.zip .

14948778481169367776297742488597387007382141969852375065438072866949945808476834
77459.
-> Attempting to run polyselect...
-> Selected default polsel parameters for 154 digit level.
-> Selected default factorization parameters for 154 digit level.
-> Selected lattice siever: ../../ggnfs/bin/gnfs-lasieve4I14e.exe
-> Searching leading coefficients from 1 to 1000.
=>  "../../ggnfs/bin/pol51m0b.exe" -b test.polsel.work2.3488 -v -v -p 7 -n 4.86E
+023 -a 0 -A 1 > test.polsel.work2.3488.log
=>  "../../ggnfs/bin/pol51opt.exe" -b test.polsel.work2.3488 -v -v -n 6.13E+021
-N 1.48E+019 -e 2.59E-012 > test.polsel.work2.3488.log
'"/cat.exe"' is not recognized as an internal or external command,
operable program or batch file.
'"/cat.exe"' is not recognized as an internal or external command,
operable program or batch file.
-> =====================================================
-> Best score so far: 0.000000e+000 (goodScore=2.590000e-012)
-> =====================================================

-> Searching leading coefficients from 1001 to 2000.
=>  "../../ggnfs/bin/pol51m0b.exe" -b test.polsel.work2.3488 -v -v -p 7 -n 4.86E
+023 -a 1 -A 2 > test.polsel.work2.3488.log
aux_factor_phi
Abnormal return value 256. Terminating...
C:\GGNFS\test>

C:\GGNFS\block-20000000>call "gnfs-lasieve4I14e.exe" -k -o spairs.20000000-21000
000.out -v -a block-20000000.job -n1234
Warning: Ignoring input line:
name: test_gnfs-lasieve4I14e

FBsize 1270142+0 (deg 5), 5761454+0 (deg 1)
-7497 572068886263742577 565 548 92953389957708711 41 7935 1813266771690922871 3
total yield: 50, q=20000023 (0.44406 sec/rel)6387 339597059292850337 433 -1177 2
20433363827250137 121 5531 520230066744402465 331 -3298 12246619252319841 117 65
39 561574562974045029 127 2552 126749191163379853 89 -2456 261821777104281209 16
7 4112 112122225128630307 433 7571 172415309099507277 381 Terminate batch job (Y/N)?

To correct gnfs-lasieve4Ixxe it is possible here so.
For windows in root VC9 it is necessary to make still a file rint.h

rint.h

#ifndef __RINT_H__
#define __RINT_H__

double rint(double);
float rintf(float);

#endif

Sergey

[10metreh]

Originally Posted by miklin

Does not work ggnfs-svn334-win64-core2.zip .

14948778481169367776297742488597387007382141969852375065438072866949945808476834
77459.
-> Attempting to run polyselect...
-> Selected default polsel parameters for 154 digit level.
-> Selected default factorization parameters for 154 digit level.
-> Selected lattice siever: ../../ggnfs/bin/gnfs-lasieve4I14e.exe
-> Searching leading coefficients from 1 to 1000.
=>  "../../ggnfs/bin/pol51m0b.exe" -b test.polsel.work2.3488 -v -v -p 7 -n 4.86E
+023 -a 0 -A 1 > test.polsel.work2.3488.log
=>  "../../ggnfs/bin/pol51opt.exe" -b test.polsel.work2.3488 -v -v -n 6.13E+021
-N 1.48E+019 -e 2.59E-012 > test.polsel.work2.3488.log
'"/cat.exe"' is not recognized as an internal or external command,
operable program or batch file.
'"/cat.exe"' is not recognized as an internal or external command,
operable program or batch file.
-> =====================================================
-> Best score so far: 0.000000e+000 (goodScore=2.590000e-012)
-> =====================================================
 
-> Searching leading coefficients from 1001 to 2000.
=>  "../../ggnfs/bin/pol51m0b.exe" -b test.polsel.work2.3488 -v -v -p 7 -n 4.86E
+023 -a 1 -A 2 > test.polsel.work2.3488.log
aux_factor_phi
Abnormal return value 256. Terminating...
C:\GGNFS\test>

C:\GGNFS\block-20000000>call "gnfs-lasieve4I14e.exe" -k -o spairs.20000000-21000
000.out -v -a block-20000000.job -n1234
Warning: Ignoring input line:
name: test_gnfs-lasieve4I14e
 
FBsize 1270142+0 (deg 5), 5761454+0 (deg 1)
-7497 572068886263742577 565 548 92953389957708711 41 7935 1813266771690922871 3
total yield: 50, q=20000023 (0.44406 sec/rel)6387 339597059292850337 433 -1177 2
20433363827250137 121 5531 520230066744402465 331 -3298 12246619252319841 117 65
39 561574562974045029 127 2552 126749191163379853 89 -2456 261821777104281209 16
7 4112 112122225128630307 433 7571 172415309099507277 381 Terminate batch job (Y/N)?

To correct gnfs-lasieve4Ixxe it is possible here so.
For windows in root VC9 it is necessary to make still a file rint.h

rint.h

#ifndef __RINT_H__
#define __RINT_H__
 
double rint(double);
float rintf(float);
 
#endif

Sergey

Hopefully that problem will not matter when msieve 1.40 comes out.

[jasonp]

Msieve v1.40 will have improvements to its own poly selection but includes neither a lattice siever nor the pol5 code that is failing above. 64-bit poly selection using msieve also has a failure somewhere.

[miklin]

Originally Posted by 10metreh

Hopefully that problem will not matter when msieve 1.40 comes out.

I so think that it is necessary to develop such programs. As pol51m0bx, pol51optx, gnfs-lasieve4Ixxe and msieve.

It actually it is very important.
In each of these programs there are pluses though there are also minuses.

Here for example to take at least gnfs-lasieve4Ixxe in it it is necessary to add definition of type of the processor (by analogy PRIMENET (library gwnum) and we already have the smart tool. The potential of these programs still far is not developed.

With project GGNFS one problem. The owner at the project like is, and the project dangles in free swimming Here and result. Everyone corrects as wants on the discretion.
Here with MSIEVE with it all is just good. There is a strategy of development and there is an owner. MSIEVE without disputably smart program. But here to develop in its my opinion too it is possible methods modules pol, lasieve and so on.

It in turn presumes to change modules operatively. As a rule frequently everyone conducts the researches with numbers and it is not always good when many important parametres are rigidly collected in the project (for example def-nm-params, def-par) it is good when all well turns out. And here when well all is bad for example with poly. Dances with tambourines begin.

And that concerning strategy certainly it is 1024 bits. And at once the set of problems in the bottom keys will come to light.

Excuse if what not so has told. This my personal opinion.

P.S And in general it is necessary to unite both these of the project in one. And to develop all it under a sensitive management jasonp. I for also am ready to help. It is necessary to understand accurately only what the help is necessary. And all will go much faster. And so it turns out that all of us sit and we wait well when there is a new version. Also that in it will be.

Yours faithfully Sergey Miklin.

[Jeff Gilchrist]

Originally Posted by miklin

Does not work ggnfs-svn334-win64-core2.zip .

Thanks for letting me know. As jasonp pointed out there seems to be something wrong with compiling the polynomial code in msieve with Visual Studio in 64bit as well. I'm not sure I can understand the code well enough to fix that.

Originally Posted by miklin

To correct gnfs-lasieve4Ixxe it is possible here so.
For windows in root VC9 it is necessary to make still a file rint.h

rint.h

#ifndef __RINT_H__
#define __RINT_H__

double rint(double);
float rintf(float);

#endif

I'm not really sure what you mean here. Including this file will remove the extra output that gnfs-lasieve is producing? Do you make any other changes to the code such as including #include rint.h somewhere?

Jeff.

[miklin]

Originally Posted by Jeff Gilchrist

Thanks for letting me know. As jasonp pointed out there seems to be something wrong with compiling the polynomial code in msieve with Visual Studio in 64bit as well. I'm not sure I can understand the code well enough to fix that.



I'm not really sure what you mean here. Including this file will remove the extra output that gnfs-lasieve is producing? Do you make any other changes to the code such as including #include rint.h somewhere?

Jeff.

Who that that that has told and at once hands have fallen. If one person has made that another can always break. A file rint.h create and put near to rint.c in root VC9 and there will be to you a happiness. And all.

After that changes gnfs-lasieve will deduce correctly.

http://mersenneforum.org/showthread....078#post144078


Seergey Miiklin

[Jeff Gilchrist]

Originally Posted by miklin

Who that that that has told and at once hands have fallen. If one person has made that another can always break. A file rint.h create and put near to rint.c in root VC9 and there will be to you a happiness. And all.

After that changes gnfs-lasieve will deduce correctly.
http://mersenneforum.org/showthread....078#post144078

Ah ok, so the rint.h file fixes the pol5 code. I thought you meant it got rid of the extra output of the lasieve in the 64bit version. When I tried that it didn't make a difference, but I will try that for the pol5 code now.

Thanks,
Jeff.

[Jeff Gilchrist]

Originally Posted by miklin

To correct gnfs-lasieve4Ixxe it is possible here so.
For windows in root VC9 it is necessary to make still a file rint.h

rint.h

#ifndef __RINT_H__
#define __RINT_H__

double rint(double);
float rintf(float);

#endif

Sergey

Hi Sergey,

So I was able to correct the pol51m 64bit binary by creating your rint.h file, and also adding #include "rint.h" in the pol51m0b.c file.

But I cannot seem to get the extra output in the lasieve4I1*e binary from stopping. How exactly did you do this? You must have changed some other file or a setting in Visual Studio than just creating the rint.h file?

Oh, it looks like pol51m0b.exe didn't get fully fixed. I tried to use factLat.pl to generate a polynomial and it just crashed.

n: 2074722246773485207821695222107608587480996474721117292752992589912196684750549658310084416732550077

...

-> Searching leading coefficients from 97001 to 98000.
=> nice -n 19  "D:/DC/factoring/test/pol51m0b.exe" -b test2.polsel.Q9550.3908 -v
 -v -p 4 -n 5.56E+014 -a 97 -A 98 > test2.polsel.Q9550.3908.log
=> nice -n 19  "D:/DC/factoring/test/pol51opt.exe" -b test2.polsel.Q9550.3908 -v
 -v -n 2.86E+013 -N 3.56E+011 -e 2.80E-009 > test2.polsel.Q9550.3908.log
-> =====================================================
-> Best score so far: 3.610000e-09 (goodScore=2.800000e-09)
-> =====================================================

-> Searching leading coefficients from 98001 to 99000.
=> nice -n 19  "D:/DC/factoring/test/pol51m0b.exe" -b test2.polsel.Q9550.3908 -v
 -v -p 4 -n 5.56E+014 -a 98 -A 99 > test2.polsel.Q9550.3908.log
lambda-comp
Abnormal return value 256. Terminating...

So a different error than you got but still crashing.

Jeff.

[Jeff Gilchrist]

Actually that "lambda-comp Abnormal return value 256. Terminating..." error is also happening in the 32bit version so maybe it is the test value n that I'm using with a problem.