Wouldn't it be a good time for a sixth-degree yet?
(I gathered so far that it is still disabled; 4th and 5th working great.)

E.g. for the c182, or the Dodson's recent break-away c187 for the 2,956+?

[QUOTE=Batalov;187869]Wouldn't it be a good time for a sixth-degree yet?
(I gathered so far that it is still disabled; 4th and 5th working great.)

E.g. for the c182, or the Dodson's recent break-away c187 for the 2,956+?[/QUOTE]

I'd be happy to take 2,956+ for Batalov+Dodson, if you'll take
on figuring out C174 12,299- and another plausible intermediate
ladder-step in-between that and c187. Maybe a c182, or so?
Still, I'd appreciate hearing from Tom and Jason on the suitability
of msieve for the polyn searches. -bd

[QUOTE=bdodson;187878]I'd be happy to take 2,956+ for Batalov+Dodson, ...[/QUOTE]

Ah, this is my recent cofactor; which explains why it's not on
your appc109 list? So that's
[code]
187 2 956 + 287.785 0.648 /gnfs! [/code]
as per your email. Nice!

But on the 4-digit gnfs ladder, twice the run-time, per step;
Tom et. al. (mersenneforum) have already hit c178, which was
smallish for that purpose, looks like
[code]
182 2 1099 + 283.570 0.641816 /7 [/code]
would fit. Still, does msieve's -np stretch out into this range,
or are we going back to looking at ggnfs for the poly search?

-bdodson

The current polynomial selector has been very inconsistent above 150 digits. You two seemed to have found good polynomials by massive brute force, but others have reported not finding any polynomials at all.

The code contains search parameters up to C180, and will work on a C182, but I would use both msieve and pol5 together, the former for small A5 and the latter for all others.

No progress at all on degree 6, I've been buried and will be so for the forseeable future.

Tom, do you think the postprocessing can handle a C187? Is this above the range where 32-bit large primes are optimal?

I would want to spend a CPU-week or so (with ggnfs - see paragraph 3) to find a reasonable straw-man polynomial and do some timings before making a really assured pronouncement, but I suspect a C187 is entirely practical with 32-bit large primes even if 33-bit large primes might be optimal; probably siever 16e rather than 15e.

People who reported zero yield for C150+ were I thought all using the version of msieve which had completely wrong Murphy bounds because there was confusion between Murphy_E and a score that msieve-1.39 used.

I tried to find polynomials for 2-877 and for some randomly-chosen C185 with msieve and ran into problems with 'error: rational leading coefficient is too large' messages; these are still there when I tried a random C182 just now.

I don't think we have a great idea of where the large-prime boundaries are for largish GNFS; I have only eight data points above C150 and a huge gap between 6+383 C165 and 109!+1 C177. I'm pretty confident that lp29 is better than lp28 at C144 and reasonably sure that it's better than lp30 at C159 (using siever 15), lp30 was better than lp29 at C163 for 2^1012+1, A32R31 was better than anything else I tried at C180 but A31R31 was about as good as A32R31 for 2-877 C178. It's probably worth doing short sieves at several Q0 with different parameters and extrapolating to total runtime.

[QUOTE=fivemack;187940]People who reported zero yield for C150+ were I thought all using the version of msieve which had completely wrong Murphy bounds because there was confusion between Murphy_E and a score that msieve-1.39 used.
[/QUOTE]

I was one of the people who reported zero yield for c150+, but the highest version I tested for these was 1.42 beta2

Which version of msieve was the first to have reasonable Murphy bounds for large (say ~c150+) composites? Is it 1.42 (or one of it's beta's), or is it the inofficial (at least I assume it's still inofficial) 1.43?

Btw: Is there a windows binary (32 bit) available for the inofficial 1.43?

The current 1.42 has the corrected bounds, as of course does the svn.

[QUOTE=fivemack;187940]I would want to spend a CPU-week or so (with ggnfs - see paragraph 3) to find a reasonable straw-man polynomial and do some timings before making a really assured pronouncement, but I suspect a C187 is entirely practical with 32-bit large primes even if 33-bit large primes might be optimal; probably siever 16e rather than 15e.
...
I tried to find polynomials for 2-877 and for some randomly-chosen C185 with msieve and ran into problems with 'error: rational leading coefficient is too large' messages; these are still there when I tried a random C182 just now.

I don't think we have a great idea of where the large-prime boundaries are for largish GNFS; I have only eight data points above C150 and a huge gap between 6+383 C165 and 109!+1 C177. I'm pretty confident that lp29 is better than lp28 at C144 and reasonably sure that it's better than lp30 at C159 (using siever 15), lp30 was better than lp29 at C163 for 2^1012+1, A32R31 was better than anything else I tried at C180 but A31R31 was about as good as A32R31 for 2-877 C178. ...[/QUOTE]

I'm interested in how far away our parameters are from the
current [Cunningham] gnfs record c182.
[code]
X5 319200
...
0 64000000 3.82 34 99
0 128000000 3.68 34 99 [/code]
First, isn't this a small c5, that -np would happily have found ...
well, either found or gotten the "large coef error"; but I think I'm seeing
Jason reporting msieve giving the same Murphy, which perhaps means
the number they factored wasn't sufficiently random for Tom's test?

Next, the p90*p91 thread reports those "34" as being the lpb's. I'm
presuming that the equal sieving for 31/32 ... Well, I'm puzzled here;
unless maybe this would be better now with the new 16e code?

I'm hoping that these are smallish issues. Looks like the parameters
are tuned to on purpose produce that gruesome 32M^2 matrix (because
they can ...)? It's always been the case that Bonn/NTT and more
recently Bonn/epfl/NTT shift as much as possible of the computation
away from sieving, over onto the matrix (which fit the models, if the
matrix power's available).

On the .poly search, seems that Thorsten still favors degree 5 in
this range. If we're speculating that c230 (to pick a large number
of digits) might need degree 6 (sounds like along way off and), maybe
Alex could check whether Thorsten could help us out with some more
recent code, but still useful below 200-digits? Just a thought.

-Bruce

Putting
[code]
40110578391052264041861148554716459268983229414539333451230174991088753692631680083117536903827770962397004050099531986516432566148793507442207506158938376891701651464686879545332041
[/code]
into worktodo.ini and running
[code]
msieve-svn/trunk/msieve -v -np 319000,320000
[/code]
does just produce the ' rational leading coefficient is too large ' message.

I would have expected the polynomial to come from whatever Kleinjung has been developing most recently, which is likely to have something in common with the msieve polynomial selection. Jason's comment about murphy scores was because msieve at the time had very wrong parameters for expected-Murphy due to a misunderstanding.

That group always seem to use rather large large-prime bounds; I didn't see any signs that I was being grotesquely sub-optimal when I did a 180-digit GNFS job with 32-bit primes, which is why I'm reasonably confident that even 187-digit GNFS could use 32-bit primes and msieve post-processing.

[QUOTE=fivemack;188157]Putting ...
into worktodo.ini and running
[code]
msieve-svn/trunk/msieve -v -np 319000,320000
[/code]
does just produce the ' rational leading coefficient is too large ' message.

I would have expected the polynomial to come from whatever Kleinjung has been developing most recently, which is likely to have something in common with the msieve polynomial selection. Jason's comment about murphy scores was because msieve at the time had very wrong parameters for expected-Murphy due to a misunderstanding.
[/QUOTE]

Thanks. Degree 5; still; OK. I was having trouble following; which
was about things subsequently fixed, which is still an issue. So Murphy
in msieve _is_ fixed, but we're still on the -np error.

[QUOTE]
That group always seem to use rather large large-prime bounds; I didn't see any signs that I was being grotesquely sub-optimal when I did a 180-digit GNFS job with 32-bit primes, which is why I'm reasonably confident that even 187-digit GNFS could use 32-bit primes and msieve post-processing.[/QUOTE]

That's encouraging, for c187. Perhaps they're more interested in
performance and improvements for 34-bit large primes than factors
of C18x's. Is it plausible that they wanted a big matrix to test, and
chose parameters expected to produce a large matrix? And with
marginal difference in sieving time? Certainly the matrix is large!

-Bruce

[QUOTE=bdodson;188183]Thanks. Degree 5; still; ... Perhaps they're
more interested in performance and improvements for 34-bit large primes
than factors of C18x's. -Bruce[/QUOTE]

Just noticed two updates to PaulZ's page with Thorsten's May 2005 report
on the rsa200 factorization:
[code]
[private communication from 7 Sep 2008: the polynomial used had degree 5.]

[below is the polynomial used, sent by Thorsten Kleinjung, 17 Feb 2009]

27997833911221327870829467638722601621070446786955428537560009929326128400107609345671052955360856061822351910951365788637105954482006576775098580557613579098734950144178863178946295187237869221823983
#skewness 2766778.76 norm 3.83e+27 alpha -6.76 Murphy_E 3.89e-15
X5 374029011720
X4 2711065637795630118
X3 19400071943177513865892714
X2 -33803470609202413094680462360399
X1 -120887311888241287002580512992469303610
X0 38767203000799321189782959529938771195170960
Y1 12722245648421103686881
Y0 -37570227807001155896638712233675454511
M
15240406298121496354551687149477757579964572007055177494848989490034525458250363151996418176514037886590177794384616498567367206741835552043570701523997401432185870335410144421338529115688465539646714
0 200000000 3.8 35 100
0 300B000000 3.7 35 100 [/code]

So this would be one of those large c5's? And, again, with the
35-bit _very_ large large primes; degree 5, rather than deg 6. -bd