Try uncommenting '#define CHECK' at the top of gnfs/poly/stage1/stage1_sieve.c ; that should cause more output.

The root sieve has already needed a major overhaul to deal with the very large search spaces generated by big inputs; perhaps it needs another :)

andi: the search parameters used are definitely too conservative for inputs < 98 digits. The latter optimization stages are very expensive and happen very often in those circumstances, and you are right that it only checks the clock every so often. I can't help that everyone wants to use that code for aliquots before it's ready. v1.42 will have some tuning and also support degree 4 (it's coming along, just needs some more work in stage 2)

hhh: Nothing in the NFS code depends on the relative size of the factors. There have been filtering changes between v1.39 and v1.41, and when just enough relations have accumulated then I guess the behavior is a bit unpredictable. EDIT: the culprit is probably that v1.41 exposes more of the factor base to the filtering when the input is small, so that filtering is more effective (but slightly more relations are needed).

J-
I have found some pairs of identical polynomials in a .dat.p file (never more than pairs, but quite a few of them, ~10%).
Are some regions of the search space visited more than once? Local minimization from neighboring ridges descend into the same valley?
-S

When generating polynomials, the root sieve runs in two phases. The first uses line sieving (remember that this is for polynomial selection) in a small region, because the size of the polynomial is unusually small in the region and you don't want to miss out on a good alpha nearby. The second phase uses lattice sieving, and is the reason that msieve can go through enormous regions looking for good alpha values. The two phases do occaisionally find the same polynomials, so redundancy is unfortunately expected. It's possible to use a hashtable to avoid this happening, but the root sieve is complex enough now that I want to hold off until I understand it better.

[quote=Batalov;171988]J-
I have found some pairs of identical polynomials in a .dat.p file (never more than pairs, but quite a few of them, ~10%).
Are some regions of the search space visited more than once? Local minimization from neighboring ridges descend into the same valley?
-S[/quote]

I've noticed this too. Once I found the best one had been duplicated!

Is there any compatibility between msieve and yafu .dat files?

At first sight only the first two lines are different, but i can't seem to complete a yafu factorization with msieve.

[quote=smh;172103]Is there any compatibility between msieve and yafu .dat files?

At first sight only the first two lines are different, but i can't seem to complete a yafu factorization with msieve.[/quote]


Right now, yafu stores A coefficients as a bigint, while msieve stores the indices into the factor base of the factors of A. Also, I think I use a N on the first line and msieve doesn't. I believe relations are stored the same.

So they are not compatible as is, but the differences are slight.
I guess there's no reason for them not to be, so I can try to make them compatible on the next revision of yafu.

Funny that this question comes up while I'm contemplating changing msieve's relation format to deal with silly problems that come up in big distributed QS runs :)

Since these are rare, those changes have never had high priority.

Why don't the two of you talk those issues over to come up with the One True Format (TM).

[quote=jasonp;172182]Funny that this question comes up while I'm contemplating changing msieve's relation format to deal with silly problems that come up in big distributed QS runs :)

Since these are rare, those changes have never had high priority.[/quote]

What problems come up? If all jobs use a different savefile name, then simply concatenating the files should work, right? There is still the issue that one doesn't know when exactly to stop the job, but that is a separate issue I think.

I'm working right now to make yafu multi-threaded, and my plan of record for now is to cause each thread to write to a different file, along with storing each relation in a separate in-memory buffer. In parallel, one extra thread will be reading from all thread's buffers, adding relations to a master cycle list, and then removing from the buffers. This extra thread then knows when to stop the whole job, and the routine can then concatenate the savefiles and proceed as normal.

[QUOTE=bsquared;172125]Right now, yafu stores A coefficients as a bigint, while msieve stores the indices into the factor base of the factors of A. Also, I think I use a N on the first line and msieve doesn't. I believe relations are stored the same.

So they are not compatible as is, but the differences are slight.
I guess there's no reason for them not to be, so I can try to make them compatible on the next revision of yafu.[/QUOTE]I did replace the first two lines of the yafu dat file with the first two lines from msieve.dat and started msieve but i get errors on every line.

I did this because the 32 bits yafu failed to find factors of a c105 and aliqueit started all over again with msieve.

Using the same relations, the 64 bit version of yafu did find the factors.

[quote=smh;172203]I did replace the first two lines of the yafu dat file with the first two lines from msieve.dat and started msieve but i get errors on every line.

I did this because the 32 bits yafu failed to find factors of a c105 and aliqueit started all over again with msieve.

Using the same relations, the 64 bit version of yafu did find the factors.[/quote]

What's your gnfs_cutoff? I would have thought GNFS would be faster for a C105.