[QUOTE=debrouxl;282074]Heh, jasonp kept a better track of the topic links than I did :smile:
Note that I intentionally never posted links to those topics on MersenneForum, so as to protect both the guilty, and the hopes-dasher (myself) from their wrath.

But we may be venturing into somewhat off-topic territory... mentioning the adventures of some people in the TI community was not my intention when posting about RSA-210 and RSA-704 :smile:[/QUOTE]

Just for fun I'll carry the off-topic stuff a little further :smile:. (mods do as you see fit)

Do I understand the cspire_lfsr code you posted correctly in that it attempts to trial divide by random 512 bit odd integers (with a tiny bit of trial division on the random p before doing the full n mod p)?


The TFing could be made 100x faster by using a sieve starting from some random p to elimiate a lot of composites prior to testing n % p.

Not that that would get you any closer to factoring n, but thought I'd point it out :whistle:

[edit]
For the heck of it, I tried this out over my lunch break. Saw about a 70x speedup.

[QUOTE=fivemack;281933]NFS@home is very happily doing large SNFS jobs, with I think significantly more resources than the forum can offer (apart of course from Bruce's ...)

The polynomial-finding code has been worked on a lot recently; getting the parameters right for larger numbers is probably not completely uninteresting.[/QUOTE]
More than mine, as well; one kilobit down, the next one to finish sieving
soon (a month, perhaps). On gnfs, our previous was gnfs197, and doubling
the difficulty leaves us well short of RSA210 (who is contributing ... to the
sieving, I mean)?

Are there other candidates to consider, with M1009 and 3p748 from
204-digits the best current? Perhaps having the snfs poly for M1009
has the advantage of setting a target for (gnfs) poly selection, like
the poly actually used to factor RSA768 (Thorsten, et. al.) for comparison
in the recent test of the gpu -vs- cpu msieve upgrade. -Bruce

Less than c204s, there's only
c202 12 299 + 297.8 0.678 /13
that looks much less likely to be gnfs than 2,1009-. And there's the newcomer
c202 3 745 + 284.3 0.8 /5q/likely_gnfs(or octic? :-) )

[QUOTE=Batalov;282087]Less than c204s, there's only
c202 12 299 + 297.8 0.678 /13
that looks much less likely to be gnfs than 2,1009-. And there's the newcomer
c202 3 745 + 284.3 0.8 /5q/likely_gnfs(or octic? :-) )[/QUOTE]

2,2218M?

[QUOTE=R.D. Silverman;282099]2,2218M?[/QUOTE]
Mentioned in Serge's previous post,
[QUOTE=Serge]
Or there's
206 2 2218 M 333.8 0.615 /gnfs
That's a tall order for sure. [/QUOTE]
Seemed to me that gnfs197 to gnfs204 is a steep enough step, without
stretching to gnfs206 (cf. gnfs210). Depends on how ambitious Tom wants
to be --- if you're expressing a preference for a base-2, wouldn't
M1009 be your first choice? -Bruce

Old, validated* gnfs targets are sparse. Nothing between 197 and 204 (maybe, 202 with a stretch of imagination).


[SIZE=1]*/ Pharma lingo. A gene target (for a future drug) is validated when a significant lot is known about it. Unlike last decade, no department wants "novel" targets anymore - because they drop like dead flies in the later pipeline when a significant effort is already spent and then there's nothing to show for the effort. I think the parallels are clear.[/SIZE]

They would need more ECM, but [URL="http://factorization.ath.cx/index.php?id=1100000000012549379"]1361^107-1[/URL] and [URL="http://factorization.ath.cx/index.php?id=1100000000126320612"]22576753^47-1[/URL] seem to be in the range you are looking at.

FWIW, I've launched msieve -np1 on the composite cofactor of M1009, [url]http://factordb.com/index.php?id=1100000000019320428[/url] .

I've run -np1 1,1000 (7.5 hours on geforce 275, 9419 hits), then -np2 which took 46 hours and gave 52638 hits (and myriads of 'too many line iterations' messages). Best was E=1.919e-15 and still significantly slower than the SNFS polynomial on a trial-sieve ... indeed, slow enough that I'm wondering if there are problems with the siever at ludicrous skew: with
[code]
lpbr: 32
lpba: 33
mfbr: 64
mfba: 96
alambda: 3.6
rlambda: 2.6
alim: 400000000
rlim: 400000000
[/code]
and siever 16e, I'm still getting
[code]
gnfs-lasieve4I16e -a -f 400000000 -c 10000
total yield: 4513, q=400010057 (24.43317 !!! sec/rel)
[/code]

(against a yield of about 2.3 and times around 1.5 sec/rel for 7+374)

snfs for comparison is also intractably slow:
[code]
n: 511723119647870982096966393397179429123821780791609426362473853284317421442953557435166610895933390722879695053104391499366375434314647024796083015465856876642832067947449473241839773740706589007306261239
skew: 0.9
c6: 2
c0: -1
Y1: -1
Y0: 374144419156711147060143317175368453031918731001856
lpbr: 32
lpba: 33
mfbr: 64
mfba: 96
alambda: 3.6
rlambda: 2.6
alim: 400000000
rlim: 400000000

gnfs-lasieve4I16e -a -f 400000000 -c 10000
total yield: 8018, q=400010057 (5.69129 sec/rel)
[/code]

(but maybe the SNFS should be done on the rational side, or maybe I should be using three big primes both sides ... trying those tonight)

What am I doing wrong? Can someone explain me step by step how to run polynomial search? What flags and files do I have to use and create. Thank you.

[code]
E:\msieve>msieve -np1 -v


Msieve v. 1.49
Fri Dec 16 22:04:50 2011
random seeds: 96f7f1f8 d3e7bad4
factoring 5117231196478709820969663933971794291238217807916094263624738532843174
21442953557435166610895933390722879695053104391499366375434314647024796083015465
856876642832067947449473241839773740706589007306261239 (204 digits)
searching for 15-digit factors
commencing number field sieve (204-digit input)
commencing number field sieve polynomial selection
error: no parameters for 204 digit inputs

[/code]

SNFS poly has E = 2.775e-15.
GNFS may reach that with a bit of luck. (but will it sieve as well is indeed an open question) 6th degree gnfs, perhaps?

SNFS -r sieving seems to be better for the posted poly.