There's a small bug in msieve-1.33. In get_sieve_params(), if the input size is 520 bits or larger, then the last prebuilt_params is used. This sets sieve_size, but sets sieve_begin and sieve_end to 0, so no a's are sieved. This is easily fixed by putting

params->sieve_begin = -params->sieve_size;
params->sieve_end = params->sieve_size;

immediately after the assignment in line 202 of gnfs.c.

Greg

[QUOTE=frmky;126737]There's a small bug in msieve-1.33.[/QUOTE]
Fixed. Maybe I should add SNFS parameters too, that would be triggered by setting a variable in the factor base file, or something.

[QUOTE=jasonp;126770]Fixed.[/quote]

Is there also a fixed windows version?

[quote] Maybe I should add SNFS parameters too, that would be triggered by setting a variable in the factor base file, or something.[/QUOTE]

Perhaps "type = gnfs" or "type = snfs" as it is used in ggnfs polynomial files?

P.S.: It would by nice if msieve would also understand .fb files in ggnfs format, like this:

[code]n: 96680308657334966163649006131900957682484675584085357909654741203214323459469957884360123524265054109609521811665540548899435521
c4: 1
c3: -1
c2: 1
c1: -1
c0: 1
Y1: 3433683820292512484657849089281
Y0: -100000000000000000000000000000000[/code]

[QUOTE=Andi47;126787]
P.S.: It would by nice if msieve would also understand .fb files in ggnfs format, like this:
[/QUOTE]

You can use factMsieve.pl located in the files area of the ggnfs Yahoo group to start with a ggnfs poly file, run the ggnfs lattice sieve, and do all postprocessing with msieve. Just put msieve in your GGNFS bin directory, and it acts as a drop-in replacement for factLat.pl.

Greg

[QUOTE=frmky;126790]You can use factMsieve.pl located in the files area of the ggnfs Yahoo group to start with a ggnfs poly file, run the ggnfs lattice sieve, and do all postprocessing with msieve. Just put msieve in your GGNFS bin directory, and it acts as a drop-in replacement for factLat.pl.

Greg[/QUOTE]

I have already tried to use factlat.pl and didn't get it to run properly in windows (the program starts after I have changed the directory lines to fit with my directory structure, but I am getting "file not found" errors and such, but I didn't find out which file it doesn't find.) So I doubt that I would get factmsieve.pl to run.

I am currently doing occasional nfs factorizations with "manual" input (and manually changing input and output files) using the parameters from the factlat.pl parameter files. I will eventually code up a small script to convert ggnfs polynomial files to msieve.fb files.

[QUOTE=Andi47;126793]I have already tried to use factlat.pl and didn't get it to run properly in windows (the program starts after I have changed the directory lines to fit with my directory structure, but I am getting "file not found" errors and such, but I didn't find out which file it doesn't find.) So I doubt that I would get factmsieve.pl to run.

I am currently doing occasional nfs factorizations with "manual" input (and manually changing input and output files) using the parameters from the factlat.pl parameter files. I will eventually code up a small script to convert ggnfs polynomial files to msieve.fb files.[/QUOTE]

Download the file factMsieve.pl from [url]http://tech.groups.yahoo.com/group/ggnfs/[/url]. It already combined the best of ggnfs and msieve. In other words, use it instead of factLat.pl.

[QUOTE=rogue;126817]Download the file factMsieve.pl from [url]http://tech.groups.yahoo.com/group/ggnfs/[/url]. It already combined the best of ggnfs and msieve. In other words, use it instead of factLat.pl.[/QUOTE]

I am NOT using factlat.pl, because I didn't manage to sort out all "file not found" and "directory not found" errors.

I am currently using the parameters given in the factlat.pl textfiles ("manually") for sieving and then switch to msieve for postprocessing.

I will try factMsieve.pl when I do the next gnfs factorization.

[QUOTE=_dc_;126908]
By the way do you have any plans/ideas about futher development of Msieve?
I'm not sure if it's possible to call this a feature request, but still this could be useful to split sqrt problem on few PCs.
.[/QUOTE]

I disagree. If one were to spend more time developing the code, it would
be much better to implement a better ALGORITHM; i.e. Peter's.

The CWI square root code takes only a small amount of time and only
a small amount of memory.

[quote=R.D. Silverman;126912]I disagree. If one were to spend more time developing the code, it would
be much better to implement a better ALGORITHM; i.e. Peter's.[/quote]
This is way different. I'm not talking about algorithm, just a feature that could be useful (and probably could be used then with another algorithm later).

[quote]The CWI square root code takes only a small amount of time and only a small amount of memory.[/quote]
Is there source code available? I'm new to this area, so don't blame me if it's not available and everyone knows it.
And I doubt it's possible to use CWI suite to continue after Msieve matrix step.

Bob is correct that for heavy-duty industrial use there is no substitute for a Mongtomery/Nguyen square root. I can only get away with not implementing it because it's reasonable to expect multi-gigabytes of RAM in a typical high-end computer nowadays. All of the work on the current square root is just a holding action to incrementally increase the point at which you'd run out of memory. I frankly am amazed that it runs so fast, i.e. for big jobs it only takes an hour or two longer than the M-N code in GGNFS.

Note that for planning purposes the msieve source is 33k lines of code, ~29k of which is needed for NFS, and the square root in GGNFS is around 10k lines. Actually, the software-engineering considerations are secondary to the need to take the time and understand the computational algebraic number theory behind how the square root works, and I've tried to do that with very little success.

The easiest way to run the square root in parallel is to have different machines run different dependencies, after putting the relation file in a shared network directory. You don't want a single machine to process multiple dependencies because of the memory use involved.

PS: The CWI square root is part of the CWI suite, which requires a license from CWI. The code relies on Pari, which is GPL and widely available.

[QUOTE=_dc_;126919]This is way different. I'm not talking about algorithm, just a feature that could be useful (and probably could be used then with another algorithm later).


Is there source code available? I'm new to this area, so don't blame me if it's not available and everyone knows it.
And I doubt it's possible to use CWI suite to continue after Msieve matrix step.[/QUOTE]


All one would have to do is convert the (output of the) msieve matrix
solution to the CWI format and convert the relation format as well.
I believe code exists for the latter.