73 digit ECM factor
 

[QUOTE="Thorsten Kleinjung"]
Dear all,

we (Joppe Bos, Thorsten Kleinjung, Arjen Lenstra, Peter Montgomery)
found the following 73-digit prime factor
1808422353177349564546512035512530001279481259854248860454348989451026887
of 2^1181-1 by ECM, completing the factorisation of this number.

Some details of this computation:
We used Paul Zimmermann's GMP-ECM program with some modifications:
Stage 1: we implemented arithmetic functions for Playstation3s for
Mersenne numbers. Stage 1 for 24 curves in parallel and for B1=3*10^9
took less than 23 hours on one PS3, i.e., less than one hour per curve
per PS3.
Stage 2: we parallelised some functions, this stage with the default value
of B2 of about 10^14 took about 15 minutes on 4 cores (per curve).
We ran more than 30000 stage 1 and 8800 stage 2 computations.
See below for the output of the lucky job.

This is a nice factor at ECM's 25th anniversary.

Best regards,
Thorsten

[CODE]
GMP-ECM 6.2.3 [powered by GMP 4.3.1] [ECM]
Resuming ECM residue saved by jwbos@node-3-6.ps3 with GMP-ECM 5.0 on Wed Mar 3 14:03:04 2010
Input number is 176185533608779112426057212156915737261973725692777098729042794211002730969474260553528629693362630813445982221616581896014560600230501525946408962727837512415610132135965435178668094176985071980937279402238467438168204332393198436347681167033274334629858331628089772185868567968860006604487 (291 digits)
Using B1=3000000000-3000000000, B2=103971375307818, polynomial x^1, sigma=4000027779
Step 1 took 0ms
Step 2********** Factor found in step 2: 1808422353177349564546512035512530001279481259854248860454348989451026887
Found probable prime factor of 73 digits: 1808422353177349564546512035512530001279481259854248860454348989451026887
Probable prime cofactor 97424992175763507877707709291914998778015966147054584755896881783255837016412999374281145264013986049748696515423136622647352488174403160324612550620242636441380838851457881913863524385273540967010429382172447745964801 has 218 digits
Report your potential champion to Richard Brent <champs@rpbrent.com>
(see http://wwwmaths.anu.edu.au/~brent/ftp/champs.txt)
[/CODE]
[/QUOTE]

Alex

.......stammers........
[ATTACH]4820[/ATTACH]
Wow! Congrats to the monster team!!

Group order is:

[code][2 4]

[3 2]

[13 1]

[23 1]

[61 1]

[379 1]

[13477 1]

[272603 1]

[12331747 1]

[19481797 1]

[125550349 1]

[789142847 1]

[1923401731 1]

[10801302048203 1]

[/code]

:tu::exclaim::alien::cool::shock::showoff:

Wow, this is an incredible milestone. According to Paul Zimmerman's website, this new divisor broke the previous ECM factoring record by five digits. Maybe you guys will discover a new Mersenne prime soon as well! :smile:

omg, congratulations to the team!
I think we need to buy some PS3... one hour for one stage 1 with B1=3e9... :crank:
With ECM 2005 the first 6x-digit factor was found (afaik), now 2010 the first factor with 7x digit. When the first 8x will be found? :wink:
:toot::groupwave::skiing::bounce wave::curtisc:

[QUOTE=jrk;207597]Group order is:

[code] ...
[1923401731 1]

[10801302048203 1]

[/code][/QUOTE]

As long as we're recording "wow's", take a look at the step1 prime,
[code]
1923401731 = step1 prime
3000000000 = B1 [/code]
So B1 = 1900000000 = 1.9e9 would have missed. Likewise, step2.
Small memory might have used B2 = 100*B1 = 300e9, but that's nowhere
near
[code]
10801302048203 step2 prime
= 1.08e13
< 103971375307818 = 1.04e14 = B2 [/code]
the default gmp-ecm step2. That's 8800 of these; wonder what the
memory needed for this step 2 was?

So mostly all of the step 1 bound was needed, and only a factor of
10 below the max possible step2, way far past low-moderate memory
use. I'm presuming that epfl isn't entirely satisfied. Arjen has a
test-case RSA key consisting of a product of four 256-bit primes
(none of this pq stuff, if no one's able to find 70-digit prime factors).
That's somewhere up in 77-digits, decimal, and this 73-digit prime
seems to have taken all that the ps3 1st step/heavy_memory_gmp-ecm_2nd
has. -Bruce

PS -- I've posted a link to Arjen's Gif of the ps3s over in the 2- subthread at
[url]http://www.mersenneforum.org/showthread.php?p=207425#post207425[/url]

I guess we can kiss off any dreams of having the #1 ECM hit this year.

All the p68 through p72 factors I have found are now ECM misses.

WOOOOW!!! :shock::shock::shock::shock: :w00t:

Congrats for this giant factor!!

:bow wave::bow wave::bow wave:

:party:

:toot::toot:

When I saw the thread title I thought it was a hoax. :smile:

[QUOTE=FactorEyes;207618]I guess we can kiss off any dreams of having the #1 ECM hit this year.

All the p68 through p72 factors I have found are now ECM misses.[/QUOTE]

Not unless you've been pulling them out of thousand-bit hard SNFS numbers, which you haven't by definition of 'hard'; doing ECM for longer than it would take to factor the number by SNFS is a definition of stupidity.

Congratulations!!!

So in this year it was found the first known prime factor of F14 and a 7x-digit factor by ECM (demonstrating that the Playstation consoles are very useful for this task), which are very important discoveries in Computational Number Theory.

[QUOTE=FactorEyes;207618] ...
All the p68 through p72 factors I have found are now ECM misses.[/QUOTE]

Mine too; retroactive to 1998. -bd ("Take a breath, already!")

Ah, and Congratulations on carrying through a sustained effort,
including lots of new stuff we hadn't even imagined before.

Postscript: Ooops. Hold the presses. It's only the Mersenne numbers
for which p68-p72 were misses. Perhaps we've displaced the yoyo
p68 record too quickly, as it still holds for non-Mersenne numbers?

[QUOTE=bdodson;207653]Mine too; retroactive to 1998. -bd ("Take a breath, already!")

Ah, and Congratulations on carrying through a sustained effort,
including lots of new stuff we hadn't even imagined before.

Postscript: Ooops. Hold the presses. It's only the Mersenne numbers
for which p68-p72 were misses. Perhaps we've displaced the yoyo
p68 record too quickly, as it still holds for non-Mersenne numbers?[/QUOTE]

It would be nice to know whether any other numbers were attempted
with the same level of effort. It would be an extraordinary surprise if they
succeeded with the only number they tried.

BTW, the yoyo 68-digit result does not seem to be listed on the
top-10 page.

[QUOTE=R.D. Silverman;207835]BTW, the yoyo 68-digit result does not seem to be listed on the
top-10 page.[/QUOTE]

That's because it took place in 2009 (barely). It's on the 2009 top-10 page.

[QUOTE=R.D. Silverman;207835]It would be nice to know whether any other numbers were attempted
with the same level of effort. It would be an extraordinary surprise if they
succeeded with the only number they tried.
[/QUOTE]

The [url=http://www.loria.fr/~zimmerma/records/ecmnet.html]63 digit[/url] find from 2^1187 - 1 looks to have received similar B1 treatment, at least. It would be interesting to know how many were tried which revealed no factors.

[QUOTE=bdodson;207614]PS -- I've posted a link to Arjen's Gif of the ps3s over in the 2- subthread at
[url]http://www.mersenneforum.org/showthread.php?p=207425#post207425[/url][/QUOTE]

That's really impressive. It's nice to see the PS3 being put to good use!

Hello,
congratulation to this big ecm factor!!!
Is the PS3 version of ecm somwhere available and described?
Is a general usable version which can be included into Boinc ;)
yoyo

[QUOTE=yoyo;207877]Hello,
congratulation to this big ecm factor!!!
Is the PS3 version of ecm somwhere available and described?
Is a general usable version which can be included into Boinc ;)
yoyo[/QUOTE]

Why should there be?

There seems to be an (unreasonable IMO) attitude among many people
that the achievements of a research group should be made available
to the general public.

Why should epfl give away the results of their intellectual efforts?

The source for GMP-ECM is available. If you want to run it on machines
of your choice, then do it yourself.

I wonder how much memory they used for stage 2. Trying to repeat 'lucky' sigma run I've received this :surprised

[quote]
Step 1 took 70927813ms
Estimated memory usage: [COLOR=Red]14G [/COLOR]
GNU MP: Cannot allocate memory (size=256)[/quote]

[QUOTE=unconnected;207945]I wonder how much memory they used for stage 2. Trying to repeat 'lucky' sigma run I've received this :surprised[/QUOTE]

I was wondering too, thanks. But I'm not surprized. -Bruce

[quote=R.D. Silverman;207935]Why should there be?

There seems to be an (unreasonable IMO) attitude among many people
that the achievements of a research group should be made available
to the general public.[/quote]

This depends on who funded the work.

I don't know a great deal about EPFL but a lot of academic institutions in Europe obtain a significant proportion of their funding from taxpayers either through national governments or through the European Commission.

If the work was partly or wholly funded by taxpayers (and I am not saying that it was), then there might well be a good case for their efforts being made openly available to those who paid for the work.

Of course taxpayers in one country cannot expect to benefit from work done in other countries. But there seems to be a widespreaad recognition that the benefits of international sharing will often be sufficient to allow taxpayer funded work in one country to be openly exploited internationally for the collective benefit of us all.

Brian Gladman

[QUOTE=R.D. Silverman;207935]Why should there be?

There seems to be an (unreasonable IMO) attitude among many people
that the achievements of a research group should be made available
to the general public.

Why should epfl give away the results of their intellectual efforts?
[/QUOTE]
I didn't say that they should. I only asked if it is available.
But Brian gave a good explanation why there could be a reason to make it public.

yoyo

This is an amazing find, congratulations to all, especially to Mr. Zimmermann for his excellent program.

Two questions:

1. Is GMP-ECM available for Windows? All I have access to are Windows machines and I'm not courageous-enough to attempt to put Linux or any other OS on them, and I have been to Mr. Zimmermann's site but was unable to answer my own question.

2. What is "Group order" per the below post from jrk? I don't have an extensive math background but find the research and results fascinating and would like to learn as much as possible.

[quote=jrk;207597]Group order is:

[code][2 4]

[3 2]

[13 1]

[23 1]

[61 1]

[379 1]

[13477 1]

[272603 1]

[12331747 1]

[19481797 1]

[125550349 1]

[789142847 1]

[1923401731 1]

[10801302048203 1]

[/code][/quote]

Thank you

[QUOTE=WVU Mersenneer;208637]

1. Is GMP-ECM available for Windows? All I have access to are Windows machines and I'm not courageous-enough to attempt to put Linux or any other OS on them, and I have been to Mr. Zimmermann's site but was unable to answer my own question.
[/QUOTE]

[url=http://www.mersenneforum.org/showthread.php?t=4087]Yep.[/url] Also [url=http://gilchrist.ca/jeff/factoring/index.html]here[/url].

[quote=bsquared;208639][URL="http://www.mersenneforum.org/showthread.php?t=4087"]Yep.[/URL] Also [URL="http://gilchrist.ca/jeff/factoring/index.html"]here[/URL].[/quote]

Outstanding! Thank you very much for your quick help, bsquared. :bow:

Does anyone happen to know if GMP-ECM all results are reported here so as to update Mr. Woltman's tables, or if only the impressive successes?

[QUOTE=WVU Mersenneer;208637]

2. What is "Group order" per the below post from jrk? I don't have an extensive math background but find the research and results fascinating and would like to learn as much as possible.



Thank you[/QUOTE]

Read: Crandall & Pomerance: Prime Numbers; A Computational
Perspective. It will explain how ECM works.

Briefly: The set of rational points on an Elliptic curve taken over a
prime field form a group under an operation that looks like addition.
Take any two points and draw a line connecting them. The line intersects
the Elliptic curve at a 3rd point. Reflect that point across the X-axis.
The reflected point is now the "sum" (under the group operation) of
the first two points.

If the field is Z/pZ, then the SIZE of the group (its order) is a random
integer in the range [p - 2sqrt(p) + 1, p+2sqrt(p) + 1]. If this
random integer is SMOOTH, then the elliptic curve algorithm will succeed in finding p.

In practice, p is an unknown divisor of a composite integer N, so the
group computations are done mod N, rather than mod p.

I suggest that you first learn how the Pollard P-1 algorithm works.
Understanding it will make understanding ECM a lot easier.

[QUOTE=R.D. Silverman;208646]

If the field is Z/pZ, then the SIZE of the group (its order) is a random
integer in the range [p - 2sqrt(p) + 1, p+2sqrt(p) + 1]. If this
random integer is SMOOTH, then the elliptic curve algorithm will succeed in finding p.
[/QUOTE]

To elaborate on this a little bit for the benefit of WVU Mersenneer: the particular group being tested at any given time is usually called a "curve" and is specified by a randomly chosen parameter called sigma. Once we find the factors, we can compute the group order for the lucky curve and then factor that group order in order to determine how smooth it was. This is what jrk did.

This is done in order to see either how close we came to missing the factorization (by seeing how close the largest factors of the group order came to the B1/B2 limits), or how smooth the group order was. As in "wow, we could have found this factor with a B1 100 times smaller than we did because this group order turned out to be so smooth!". If you can get excited about the relative smoothness of elliptic curve group orders, then you belong on this forum :smile:

[quote=WVU Mersenneer;208637]2. What is "Group order" per the below post from jrk? I don't have an extensive math background but find the research and results fascinating and would like to learn as much as possible.[/quote]
This page has some good info:
[URL]http://mersennewiki.org/index.php/Elliptic_curve_method[/URL]
Compare to:
[URL]http://mersennewiki.org/index.php/P-1_Factorization_Method[/URL]
Now, to provide a very basic explanation of what all that means in the end (instead of the mathematical details of how it works):
Basically:
the P-1 method will find a factor P if P-1 has at most one factor above B1 and no factor above B2 (the rest of the factors would be below B1, of course), and
ECM will find a factor P if P's group order (determined by the sigma, which is chosen randomly) has at most one factor above B1 and no factor above B2 (the rest of the factors would be below B1, of course).

The group order posted is really the group order's prime factorization. The format shown is:
[code][p1 q1]
[p2 q2]
...
[pz qz][/code]where N=p1^q1*p2^q2*...*pz^qz is N's prime factorization.
As its largest factors are 1923401731 and 10801302048203, we know that the minimum B1 and B2 to find this factor in step 2 are 1923401731 and 10801302048203, respectively. Or the minimum B1 to find this factor in step 1 is 10801302048203 (without step 2, the B2 value doesn't matter).

Sincere respect, appreciation, and thanks to Dr. Silverman and bsquared for the summarized yet powerful explanation and education. I will do my best to locate the text suggested and I thank you for that additional suggestion.

Might I also ask what "branch" of mathematics best deals with the teachings Dr. Silverman and bsquare provided above? Perhaps I can also pick up a text book or two from the library and learn more or find the appropriate professor on campus of whom to ask further questions.

I was also wondering, and forgive me if this is an ignorant question or will be answered by reading the text Dr. Silverman suggested, but I have noticed that Mersenne numbers, when subtracted by and additional 1, are always divisible by 6 and then easily divisible into other small prime factors, one of the factors always being the power of 2 used to obtain the Mersenne number.

For example:
(2^31 - 1) - 1 = 2,147,483,646
2,147,483,646 / 6 = 357,913,941
357,913,941 = 3 * 7 * 11 * [COLOR=red]31[/COLOR] * 151 * 331

(2^89 - 1) - 1 = 618,970,019,642,690,137,449,562,110
618,970,019,642,690,137,449,562,110 / 6 = 103,161,669,940,448,356,241,593,685
103,161,669,940,448,356,241,593,685 = 5 * 17 * 23 * [COLOR=red]89[/COLOR] * 353 * 397 * 683 * 2113 * 2,931,542,417

Furthermore, some of the factors found using this "method" are found in more than one "Mersenne - 1", sometimes the factors being factors of non-prime Mersennes.

Is this "related" in any way to the Pollard P-1 algorithm or any other legitimate algorithm, or is this just a useless coincidence upon which I stumbled?

Mini-Geek, please consider yourself added to the appropriate thanks I hopefully gave to Dr. Silverman and bsquared above.

I have read the links you provided dozens of times prior to posting here, and as you have assuredly already guessed, it was far above my comprehension. However, I do also appreciate your "dumbing down" those explanations for me, and I feel I can almost grasp that. Hopefully once I learn what "branch" this all falls under I can locate a book or two to study and learn more, or that I remember more from the Number Theory course I took 12 years ago.

My thanks to all.

[quote=WVU Mersenneer;208655]Is this "related" in any way to the Pollard P-1 algorithm or any other legitimate algorithm, or is this just a useless coincidence upon which I stumbled?[/quote]
I'm guessing useless coincidences. :smile: (though possibly useless side effects of known-and-used facts, or rediscovered truths; let's find out...)
[quote=WVU Mersenneer;208655]I was also wondering, and forgive me if this is an ignorant question or will be answered by reading the text Dr. Silverman suggested, but I have noticed that Mersenne numbers, when subtracted by and additional 1, are always divisible by 6 and then easily divisible into other small prime factors, one of the factors always being the power of 2 used to obtain the Mersenne number.

Furthermore, some of the factors found using this "method" are found in more than one "Mersenne - 1", sometimes the factors being factors of non-prime Mersennes.[/quote]
To put them in other ways:
(2^p-2 is divisible by 6, which is equivalent to...)
[tex]2^p-2 \equiv 0 \pmod 6[/tex]
This is true for every 2^n-2 with odd n. While I can't properly explain the [I]why[/I] of the matter, it is a fact, as is easily seen here:
[tex]2^1 \equiv 2 \pmod 6[/tex]
[tex]2^2 \equiv 4 \pmod 6[/tex]
[tex]2^3 \equiv 2 \pmod 6[/tex]
[tex]2^4 \equiv 4 \pmod 6[/tex]
And this pattern repeats (2*2=4 mod 6, 4*2=2 mod 6). So 2^n-2 with odd n is always divisible by 6.
(while we're sort of on the subject, there's a [URL="http://primes.utm.edu/notes/faq/six.html"]trivially-proven observation[/URL] that all primes above 3 are of the form 6*n-1 or 6*n+1 for some n)

(2^p-2 is divisible by p, which is equivalent to...)
[tex]2^p-2 \equiv 0 \pmod p[/tex]
This is Fermat's Little Theorem with a=2:
[tex]a^p \equiv a \pmod{p}[/tex] (Little Theorem)
[tex]2^p-2 \equiv 0 \pmod p[/tex] (your observation)
So your observation is correct.

(2^p-2 is pretty smooth)
(see below)

[quote=WVU Mersenneer;208655]Furthermore, some of the factors found using this "method" are found in more than one "Mersenne - 1", sometimes the factors being factors of non-prime Mersennes.[/quote]
Sometimes, but not all the time? Is there a pattern as to when it does/doesn't happen?
For Mersenne numbers there is such a known identity:

[tex]2^{ab}-1=(2^a-1)\cdot \left(1+2^a+2^{2a}+2^{3a}+\cdots+2^{(b-1)a}\right)\ [/tex]
(from [URL]http://en.wikipedia.org/wiki/Mersenne_prime#Searching_for_Mersenne_primes[/URL])
This means that the factors of 2^a-1 will also be in the factors of every 2^(ab)-1.

And, as 2^p-2=2*(2^(p-1)-1), (e.g. 2^61-2=2*(2^60-1)=2*(2^2-1)*...) you might be running in to this with your 2^p-2 numbers.
Maybe you're seeing that?

That might also explain the smoothness of 2^p-2. If p-1 is itself quite smooth (as with 60), then it will leave only very small prime factors.

[QUOTE=WVU Mersenneer;208655]

I was also wondering, and forgive me if this is an ignorant question or will be answered by reading the text Dr. Silverman suggested, but I have noticed that Mersenne numbers, when subtracted by and additional 1, are always divisible by 6 and then easily divisible into other small prime factors, one of the factors always being the power of 2 used to obtain the Mersenne number.

Is this "related" in any way to the Pollard P-1 algorithm or any other legitimate algorithm, or is this just a useless coincidence upon which I stumbled?[/QUOTE]

A basic requirement for studying this subject (Number Theory) is that you
thoroughly understand basic secondary school level algebra. The
"coincidence" you discuss above results from totally trivial FIRST YEAR
algebra.

If N = 2^p-1, then N-1 = 2^p-2. Now factor this expression.
Pull out the factor of 2. What remains is trivially the difference of two
squares. You do know how to factor the difference of two squares, don't
you?

More high school algebra: You do know how to show that n(n+1)(2n+1)
is divisible by 6, don't you? (for n \in Z), This expression should be
familiar to anyone who has mastered high school level mathematics.

Now use the same technique on 2^p-2.

[QUOTE=Mini-Geek;208663]
Sometimes, but not all the time? Is there a pattern as to when it does/doesn't happen?
For Mersenne numbers there is such a known identity:

[tex]2^{ab}-1=(2^a-1)\cdot \left(1+2^a+2^{2a}+2^{3a}+\cdots+2^{(b-1)a}\right)\ [/tex]
.[/QUOTE]

Sigh. You need to go back an thoroughly relearn the basic algebra that
you failed to learn in high school. The above identity, which you seem
to think is a mystery, is a trivial consequence of elementary polynomial
algebra. You did study factorization of polynomials, didn't you?


Here's a high school level exercize:

Given the polynomial x^ab - 1 for a,b, odd integers, PROVE that
it is divisible by x^a-1, and x^b-1. (and, of course, x-1).

The proof uses nothing more than elementary facts about polynomials.
Hint: One such proof uses the roots of the polynomials. You do know
the remainder theorem for polynomials?? If not, I give it as
an exercize:

Given a polynomial over R: f(x) = sum a_i x^i, i=0,...N,
PROVE: f(r) = the remainder when f(x) is divisible by (x-r).

I do not know you personally and intend no insult, but anyone who
can not do the above exercizes has no business dabbling in number theory.
Such a person simply lacks too much basic algebra.

[QUOTE=Mini-Geek;208663]I'm guessing useless coincidences. :smile: (though possibly useless side effects of known-and-used facts, or rediscovered truths; let's find out...)

To put them in other ways:
(2^p-2 is divisible by 6, which is equivalent to...)
[tex]2^p-2 \equiv 0 \pmod 6[/tex]
This is true for every 2^n-2 with odd n. While I can't properly explain the [I]why[/I] of the matter, it is a fact, as is easily seen here:
.[/QUOTE]

If one can't explain why, one has no business dabbling in this domain.
'Why' comes from trivial first year algebra, plus a little thought
about when an integer might be divisible by 3.

(1) 2^p-2 is trivially divisible by 2.
(2) 2(2^(p-1) - 1) is, with a little more work, easily seen to be divisible by 3.
Think about difference of squares.

The math involved is TRIVIAL HIGH SCHOOL ALGEBRA. If K is even, then
either K+1 or K-1 is divisible by 3. If one can't explain this, one has no
business trying to discuss number theory. Such a person is simply too
ignorant about elementary high school algebra to have any hope of
understanding this subject.

I have said this multiple times, but the message does not get through.
Elementary number theory can be learned with just minimal background,
but that minimal background MUST include [b]mastery[/b] of high
school algebra, plus the ability to put together a mathematical argument
from basic principles, rather than just parroting from memory.

[QUOTE=R.D. Silverman;208739]The math involved is TRIVIAL HIGH SCHOOL ALGEBRA. If K is even, then either K+1 or K-1 is divisible by 3. If one can't explain this, one has no business trying to discuss number theory. Such a person is simply too ignorant about elementary high school algebra to have any hope of understanding this subject.[/QUOTE]

Hmm, sounds like you need to take your own advice!

Nice pair, now. Congratulations!

[QUOTE=xilman;212379]They are two alternative spellings for the same word. I'm sure you're familiar with that concept.[/QUOTE]Hehe, not quite what I meant. Nevermind, all this could lead to a terrible argument over the ambiguity of a word ... or three.

[size=1][color=#c0c0c0]Is it not true that [u]all[/u] words are invented words?[/color][/size]

Here is the second p73's group order

[CODE]

Magma V2.16-6 Mon Apr 19 2010 20:22:13 [Seed = 2434200602]
-------------------------------------

[ <2, 2>, <3, 2>, <5, 1>, <23, 1>, <1429, 1>, <28229, 1>, <139133, 1>, <249677,
1>, <389749, 1>, <15487861, 1>, <47501591, 1>, <111707179, 1>, <431421191, 1>,
<13007798103359, 1> ]

Total time: 6.549 seconds, Total memory usage: 17.75MB

[/CODE]

So using the default B2, a B1 of 8e8 would have been sufficient to find this factor.

Interesting sigmas:
4000027779
3000085158
3000000588

Stepping sequentially from a starting value rather than relying on random numbers not to repeat? Not sure I'd have that much confidence in my coordination skills.

[quote=frmky;212434]Stepping sequentially from a starting value rather than relying on random numbers not to repeat? Not sure I'd have that much confidence in my coordination skills.[/quote]This is purely a guess, but perhaps they have a program onto which they offload the co-ordination.

Paul

[QUOTE=frmky;212434]So using the default B2, a B1 of 8e8 would have been sufficient to find this factor.

Interesting sigmas: ... [/QUOTE]

With a sequential choice of sigma they can be certain that there
aren't two repetitions. GMP-ECM has kept 32-bit sigmas, perhaps on
the expection that no single number would be run far enough to have
more than one or two duplicate sigma. The BKLM runs have been doing
30000 curves, as in Thorsten's report on the first p73 ... well, still not
much chance of more than one or two; but none-for-sure going
sequentially. I had an impression that there was confidence in 32-bits
of randomness, less so about 64-bits worth. (Being carefull to the new
forum protocol on public attribution of private conversation. The above
version as an "impression" is my own, extrapolated from several sources.)
If DES is our best analyzed attempt at 56-bits, we know that 2^47 chosen
plain texts sufficies to determine the 56-bits --- not that brute force wasn't
far quicker, but under "perfect security" requirements that might be taken
as only 47-bits of randomness achieved? Then there's the "internal" cipher
in the fiestal, using 48-bit keys. I asked an expert on random numbers
about this view (cf. the "Numerical Recipes in C" CD), and got back "47-bits
is pretty good!", rather than a dispute.

I was just looking at 3 months of ecm spread over [c234-c289 plus "the
Mn, Pn up to c366"], with B1 = 260M; and found 62K curves without any
repeated sigma. That's 7t55 or 1.4t60, without finding any more of
Aoki's p50/p51 factors; just a single p54.

Nevermind. On Greg's point, B1=8e8 is rather close to the value
B1=850M sometimes given as p65-optimal, with the ECM-GMP default B2.
Using B1=260M instead, Alex's "expected number of curves" to find
a p65 is 263K. That's after I gave up on being able to run a sufficient
number of 850M-curves to give ecm a chance. With hindsight, the curves
that first broke 50-digits (p53) and 60-digits (p66) using substantially
suboptimal B1's may not have been reliable indicators for an effort to
break 70-digits. I'm not entirely sure that 3 years of ecm on 500 fast pcs
(1500 cpuyears, more or less) is a sufficient test of the effectiveness of
p60-limits at finding a p70; but this second BKLM p73 might suggest that
access to sufficiently many pcs to run step2 with p65-optimal limits for
several hundred cpuyears might have a better chance. (The Cunningham
targets here were mostly < c234, to keep the curve counts up.)

-Bruce

PS - Alternatively, if p60-optimal is insufficient for a plausible chance at
a p70; and the expected factor size in the portion of the current Cunningham
list from c234-c366 is closer to p55, dropping back to p55-limits might be
better use of the (public) cptime. Cf. Jason's reference to my post in
favor of the objective of effectively hitting singles -vs- "swinging for the
fences". It's baseball season over here.

[QUOTE=MatWur-S530113;207609]
With ECM 2005 the first 6x-digit factor was found (afaik), now 2010 the first factor with 7x digit. When the first 8x will be found? :wink:
:toot::groupwave::skiing::bounce wave::curtisc:[/QUOTE]

well with that time line I'm guessing somewhere in 2015

[quote=science_man_88;212593]well with that time line I'm guessing somewhere in 2015[/quote]
i would suspect earlier as we have just had a breakthrough in technology(PS3s)
The difference between 2004 and 2009 isnt that great in comparison.

[quote=henryzz;212595]i would suspect earlier as we have just had a breakthrough in technology(PS3s)
The difference between 2004 and 2009 isnt that great in comparison.[/quote]
With respect, the PS3 is [b]not[/b] a breakthrough in technology. It is rather outdated technology.

What the EPFL people have done is build a large cluster of PS3s and have programmed the special purpose hardware (the cell processors) inside them. They've undoubtedly been clever, and all kudos to them, but the technology is not that impressive.

Just wait until massively parallel GPU computation hits the mainstream. It seems entirely plausible that thousands of ECM curves can be run in parallel on 32-bit GHz gpus hosted in hundreds of cpus, each of which can run several curves concurrently.

Some of us are working towards that end.


Paul

[QUOTE=xilman;212614]With respect, the PS3 is [b]not[/b] a breakthrough in technology. It is rather outdated technology.

What the EPFL people have done is build a large cluster of PS3s and have programmed the special purpose hardware (the cell processors) inside them. They've undoubtedly been clever, and all kudos to them, but the technology is not that impressive.

Just wait until massively parallel GPU computation hits the mainstream. It seems entirely plausible that thousands of ECM curves can be run in parallel on 32-bit GHz gpus hosted in hundreds of cpus, each of which can run several curves concurrently.

Some of us are working towards that end.


Paul[/QUOTE]

They are also CHEAP.

[quote=R.D. Silverman;212615]They are also CHEAP.[/quote]As are graphics cards.

Paul

[QUOTE=xilman;212619]As are graphics cards.

Paul[/QUOTE]

Sure. But graphic cards need a parent platform.

[quote=R.D. Silverman;212624]Sure. But graphic cards need a parent platform.[/quote]Which, these days, are pretty near ubiquitous. Phones and games consoles are about the only mass-market platform which do not (at present) have a programmable gpu.

Example: at the end of last year I bought a cheap and cheerful laptop. It came with a nVIDIA GT240M with a dedicated 1GB of RAM. It may not be up there with the Tesla systems but it still has 48 32-bit cpus running at 1.2GHz.

Paul

For problems which run well enough in parallel, GPUs are also by far the best proposition for individual resource-constrained contributors. The GPU on my test system cost $109 and is ~50x faster at NFS polynomial selection than the machine it's plugged into. Even if I could afford 50 machines to replace it, where would I put them? My basement?

I could also narrow the gap between CPU and GPU, perhaps to the point where a core2 system was only 5x slower, but where would I put 5 more machines? My basement?

[QUOTE=jasonp;212642]I could also narrow the gap between CPU and GPU, perhaps to the point where a core2 system was only 5x slower, but where would I put 5 more machines? My basement?[/QUOTE]

You could put them in my basement. :smile:

:smile::big grin:[QUOTE=jasonp;212642]For problems which run well enough in parallel, GPUs are also by far the best proposition for individual resource-constrained contributors. The GPU on my test system cost $109 and is ~50x faster at NFS polynomial selection than the machine it's plugged into.[/QUOTE]

Nice!

NFS sieving runs very well in parallel. How well does your GPU perform
when sieving?

[quote=R.D. Silverman;212742]:smile::big grin:

Nice!

NFS sieving runs very well in parallel. How well does your GPU perform
when sieving?[/quote]My guess, and it is only a guess, is that it doesn't perform at all. Porting general purpose code to a GPU is rarely a simple matter of recompilation.

GPUs are also (by and large) superb at arithmetic and not very good at memory access. That said, porting a siever to a GPU would be very much a worthwhile exercise. Do you fancy taking on the challenge? A bunch of people here could try to give assistance.


Paul

[QUOTE=Jeff Gilchrist;212676]You could put them in my basement. :smile:[/QUOTE]
My basement has a 466MHz Alpha, a 400MHz G4 and a 1.4GHz P4, that all work fine and are not even worth turning on. And that's just the computers that work :)
[QUOTE=xilman]
GPUs are also (by and large) superb at arithmetic and not very good at memory access. That said, porting a siever to a GPU would be very much a worthwhile exercise. Do you fancy taking on the challenge? A bunch of people here could try to give assistance.
[/QUOTE]
Algorithms that are dominated by memory latency and random byte addressing would be very hard to code on a GPU. Several have already tried to port a lattice sieve with disappointing results

Is anyone working on ECM on GPUs? That's the second biggest CPU sink in factoring.

Chris K

[quote=chris2be8;212963]Is anyone working on ECM on GPUs? That's the second biggest CPU sink in factoring.

Chris K[/quote]Yes.

Paul

Dan Bernstein has code available that runs ECM (stage 1) using Edwards curves on a GPU; IIRC his input size is very limited, essentially to support factorization of sieve reports from very large NFS runs.

[QUOTE=wreck;212386]Here is the second p73's group order

[CODE]

Magma V2.16-6 Mon Apr 19 2010 20:22:13 [Seed = 2434200602]
-------------------------------------

[ <2, 2>, <3, 2>, <5, 1>, <23, 1>, <1429, 1>, <28229, 1>, <139133, 1>, <249677,
1>, <389749, 1>, <15487861, 1>, <47501591, 1>, <111707179, 1>, <431421191, 1>,
<13007798103359, 1> ]

Total time: 6.549 seconds, Total memory usage: 17.75MB

[/CODE][/QUOTE]

Looks like the third large factor is a p66
[code]
694217535399847678048415113186577758507635822252803808473674680017
2^1073+1 3e9 3000000623 2010-05-31 J.Bos,T.Kleinjung,A.Lenstra,P.Montgomery [/code]
C281 = p66*p215; that's sigma = 3000000623.

(6th on the top50, in between the other two p66's by ecm)

[QUOTE=bdodson;216842]Looks like the third large factor is a p66
[code]
694217535399847678048415113186577758507635822252803808473674680017
2^1073+1 3e9 3000000623 2010-05-31 J.Bos,T.Kleinjung,A.Lenstra,P.Montgomery [/code]
C281 = p66*p215; that's sigma = 3000000623.

(6th on the top50, in between the other two p66's by ecm)[/QUOTE]

That would be 2^1073-1, yes?

I'm finding it slightly uncanny that these large ECM runs on the not-very-many numbers of the form 2^10xx \pm 1 are finding so many factors that it would be post-facto infuriating to have found by kilobit SNFS.

I don't think I can quantify 'slightly uncanny', though I'm sure there are people who can.

[quote=bdodson;216842]Looks like the third large factor is a p66
[code]
694217535399847678048415113186577758507635822252803808473674680017
2^1073+1 3e9 3000000623 2010-05-31 J.Bos,T.Kleinjung,A.Lenstra,P.Montgomery [/code]C281 = p66*p215; that's sigma = 3000000623.

(6th on the top50, in between the other two p66's by ecm)[/quote]Arjen and I are now both at Eurocrypt in Nice&Monaco. I learned about this result as soon as he did and, I suspect, before anyone else outside EPFL. Joppe Bos is also here, but Thorsten and Peter are not. Aoki, however, is here. All the CNT people have been chatting together, as you may expect.

Very little number theory at this year's event. :sad:


Paul

[QUOTE=axn;216845]That would be 2^1073-1, yes?[/QUOTE]

Uhm, yes. +1 would have been larger news; not sure why my mouse
switched signs - I copied it from the ecmnet cgi report, which correctly
reads -1, along with Sam's page.

[QUOTE=fivemack;216846]I'm finding it slightly uncanny that these large ECM runs on the not-very-many numbers of the form 2^10xx \pm 1 are finding so many factors that it would be post-facto infuriating to have found by kilobit SNFS.

I don't think I can quantify 'slightly uncanny', though I'm sure there are people who can.[/QUOTE]

I don't find it uncanny at all. They are using B1 (and probably B2) limits
that are much larger than anyone else has tried. They are running ECM
on a fairly small set of numbers. It is not a surprise (to me, at least)
that they are finding ECM factors not found by others.

[QUOTE=bdodson;216842]Looks like the third large factor is a p66
[code]
694217535399847678048415113186577758507635822252803808473674680017
2^1073+1 3e9 3000000623 2010-05-31 J.Bos,T.Kleinjung,A.Lenstra,P.Montgomery [/code]
C281 = p66*p215; that's sigma = 3000000623.

(6th on the top50, in between the other two p66's by ecm)[/QUOTE]

It looks like it was a big luck, found the p66 divisor at the 624th(?) curve (B1=3e9).

[QUOTE=xilman;216849]Arjen and I are now both at Eurocrypt in Nice&Monaco. I learned about this result as soon as he did and, I suspect, before anyone else outside EPFL. Joppe Bos is also here, but Thorsten and Peter are not. Aoki, however, is here. All the CNT people have been chatting together, as you may expect.

Very little number theory at this year's event. :sad:


Paul[/QUOTE]

So sounds like Eurocrypt gets the RSA768 paper?

It's not on the program...

Of course I wouldn't need to work that hard to justify a trip to the french riviera.

[quote=bdodson;217024]So sounds like Eurocrypt gets the RSA768 paper?[/quote]It's not here. Not sure where it will appear. Crypto, perhaps, or Asiacrypt?


Paul

[QUOTE=xilman]It's not here. Not sure where it will appear. Crypto, perhaps, or Asiacrypt?


Paul[/QUOTE]

It's on the program for Crypto. rather more specifically at 10:55 Aug. 17th.

[QUOTE=tcadigan;217119]It's on the program for Crypto. rather more specifically at 10:55 Aug. 17th.[/QUOTE]

Just to be complete:
Emmanuel Thome gave the presentation today. With focus on parallel block Wiedemann used in the Linear Algebra.

The fourth factor has 68 digits.
[code]5949 2,1139- c313 12947560801881275212486900476122097688373975262784709656768032387833. p246 Bos+Kleinjung+AKLenstra+Montgomery ECMNET[/code]

[QUOTE=warut;228560]The fourth factor has 68 digits.
[code]5949 2,1139- c313 12947560801881275212486900476122097688373975262784709656768032387833.
p246 Bos+Kleinjung+AKLenstra+Montgomery ECMNET[/code][/QUOTE]

This would be the fifth BKLM factor (after the new coding). Plus the first
of the two p63's, listed just as Bos+Kleinjung, which is also B1=3e9/PS3/epfl.
There's also a Bos/Kleinjung p61 found with B1=260e6, which wasn't listed
on the epfl report of PS3 factors. That one was after the first p63/PS3, but
before the recoding. All but the p61 and the new p68 are easy to find;
listed in the top10.

Thanks for the early report! (Ah; from Sam's page. The above is from
the ECMNET reports.) -Bruce

(bumps my smaller p62.)

Thanks for the correction. I forgot the actual fourth factor by BKLM because it was reported on [URL="http://mersenneforum.org/showthread.php?p=224446#post224446"]another thread[/URL].

[quote=R. Gerbicz;217004]It looks like it was a big luck, found the p66 divisor at the 624th(?) curve (B1=3e9).[/quote]
Actually, for 2^1073-1, BKLM ran ~25,000 stage 1 on the PS3 cluster (plus an addition 1,460 stage 2 on conventional computers).

[QUOTE=warut;228560]The fourth factor has 68 digits.
[code]5949 2,1139- c313 12947560801881275212486900476122097688373975262784709656768032387833. p246 Bos+Kleinjung+AKLenstra+Montgomery ECMNET[/code][/QUOTE]

Here's the (n+1)st:
[code]
p59=46654722984595033623595915319018639089714063407438899506169
2^937-1 C212 260e9 260003949 2010-10-18 BKLM[/code]
That's B1 = 2.6e11 ... a large new jump again. Just in; I haven't seen
the cofactor (Sam's page isn't updated yet; this is from the ecmnet
cgi page.) -Bruce

[QUOTE=bdodson;233695]Here's the (n+1)st:
[code]
p59=46654722984595033623595915319018639089714063407438899506169
2^937-1 C212 260e9 260003949 2010-10-18 BKLM[/code]
That's B1 = 2.6e11 ... a large new jump again. Just in; I haven't seen
the cofactor (Sam's page isn't updated yet; this is from the ecmnet
cgi page.) -Bruce[/QUOTE]


The cofactor is prime.

[QUOTE=R.D. Silverman;233698]The cofactor is prime.[/QUOTE]

It's interesting that a p59 was missed at 3 x 10^9......

[QUOTE=R.D. Silverman;233700]It's interesting that a p59 was missed at 3 x 10^9......[/QUOTE]

I had a previous p57 ... does seem like the p59 could have been found
earlier. But do we know that 2,937- had a full run with B1=3e9? -Bruce

[QUOTE=bdodson;233720]I had a previous p57 ... does seem like the p59 could have been found
earlier. But do we know that 2,937- had a full run with B1=3e9? -Bruce[/QUOTE]Do we know the group order? It's possible that only a small fraction of the (normally) indicated B2 range was run.


Paul

[QUOTE=xilman;233745]Do we know the group order? It's possible that only a small fraction of the (normally) indicated B2 range was run.


Paul[/QUOTE]

[CODE][ <2, 4>, <3, 1>, <11, 1>, <20021, 1>, <556007, 1>, <717419, 1>, <2342731, 1>,
<3724261, 1>, <61043881, 1>, <245849333, 1>, <84498517303, 1> ][/CODE]Min. B1 ~= 2.46e8, min. B2 ~= 8.45e10

[QUOTE=Mini-Geek;233777][CODE][ <2, 4>, <3, 1>, <11, 1>, <20021, 1>, <556007, 1>, <717419, 1>, <2342731, 1>,
<3724261, 1>, <61043881, 1>, <245849333, 1>, <84498517303, 1> ][/CODE]Min. B1 ~= 2.46e8, min. B2 ~= 8.45e10[/QUOTE]

So B1=3e9 with B2=103971375307818 = 1.04e14 would have more
than sufficed. This number wasn't on their June curve count list for
B1 = 3e9. Maybe they wanted a smaller number for a test case with
the new B1? Uhm, err ... or perhaps the c212 was a gnfs candidate?

-Bruce

Command line unix ecm "found" the p59 too, - with a default param curve at B1=260e6 (3e9 would have been 11 times longer)
[FONT=Arial Narrow]Step 1 took 1474 048ms
Step 2 took 681 698ms[/FONT]

[QUOTE=Batalov;233816]Command line unix ecm "found" the p59 too, - with a default param curve at B1=260e6 (3e9 would have been 11 times longer)
[FONT=Arial Narrow]Step 1 took 1474 048ms
Step 2 took 681 698ms[/FONT][/QUOTE]Mystery solved. Paul (the other one) has posted a report from Thorsten that B1 was actually 2.6e8 and that the factor was found on a PC.

Paul (this one)

[QUOTE=xilman;233828]Mystery solved. Paul (the other one) has posted a report from Thorsten that B1 was actually 2.6e8 and that the factor was found on a PC.

Paul (this one)[/QUOTE]

Yes, thanks. The cgi line is now saying
[code]
260e6 [/code]
too. Just to remove any possible question, here's the log Thorsten
sent to PaulZ and Sam (as posted to ECMNET by PaulZ)
[code]
Input number is
49065003020440088020233565530981034575278730829197795102034752497286737689958440672064128091671366305592919451423049625508883886628462923775201492141273267361171535761978676893172985484995759934256009764879575937
(212 digits)
Using B1=260000000, B2=3178559884516, polynomial Dickson(30),
sigma=260003949
Step 1 took 3020468ms
Step 2 took 1116034ms
********** Factor found in step 2:
46654722984595033623595915319018639089714063407438899506169
Found probable prime factor of 59 digits:
46654722984595033623595915319018639089714063407438899506169
Probable prime cofactor
1051662080099391159250990850668031334695175372192528921233670913813412325120288431142374453093538999808223119264936281688325783724087706106729415181782473
has 154 digits [/code]
so step1 was done on the "pc". This number is from the range that got
just barely over t55 (at c. 6t50), so the p59 no longer appears to have
arrived out of order; right in-range for a search of ecm factors in [p57,p62]
after no (more) factors found in t55. -Bruce

[QUOTE=bdodson;233695]Here's the (n+1)st:
[code]
p59=46654722984595033623595915319018639089714063407438899506169
2^937-1 C212 260e6 260003949 2010-10-18 BKLM[/code]
[corrected!] -Bruce[/QUOTE]

Here's another BKLM pc factorization
[code]
2, 953- c215 210604142476977747806569755290105170291449495120790656457721
. p115 Bos+Kleinjung+Lenstra+Montgomery ECMNET [/code]
also
[code]
p60 = 210604142476977747806569755290105170291449495120790656457721
2^953-1 260e6 260008981 2010-11-07 J.Bos,T.Kleinjung,A.Lenstra,P.Montgomery [/code]
-Bruce

It is interesting: c215=p60*p115.

[QUOTE=R. Gerbicz;235975]It is interesting: c215=p60*p115.[/QUOTE]

Sam's page had c212 = p59 * p212 on the previous epfl pc factor, for
a few days; of equal interest. The ECMNET reports, including PaulZ's
emails, don't include cofactors. -bd

[QUOTE=bdodson;228586]This would be the fifth BKLM factor (after the new coding). Plus the first
of the two p63's, listed just as Bos+Kleinjung, which is also B1=3e9/PS3/epfl.
There's also a Bos/Kleinjung p61 found with B1=260e6, which wasn't listed
on the epfl report of PS3 factors. That one was after the first p63/PS3, but
before the recoding. All but the p61 and the new p68 are easy to find;
listed in the top10. ... -Bruce [/QUOTE]

After two ECMNET pc factors; here's the next one that appears to
have larger step1, like the ones done on the PS3 network
[code]
5978 2, 961- c254 8685373022907062443109907561762261051459356481790933999405609
. p193 Bos+Kleinjung+Lenstra+Montgomery ECMNET

with

p61 = 8685373022907062443109907561762261051459356481790933999405609
2^961-1 1e9 3000011437 2010-11-23 J.Bos,T.Kleinjung,A.Lenstra,P.Montgomery [/code]
If the report is correct; the 1e9 is new/smaller than the 3e9 of the previous
PS3 factors, but the sigma looks PS3-ish. -bd

I had that down as a possible SNFS candidate (to the point that I'd determined parameters), but Bos+Kleinjung+Lenstra+Montgomery have saved a CPU-decade or so.

It appears that they sweeped once to the top (and even beyond with M1237) and started again from the bottom with another set of parameters (and/or ideas!).

P69
 

Sam Wagstaff just found a P69 factor of 3^1443+1.

[QUOTE=R.D. Silverman;238498]Sam Wagstaff just found a P69 factor of 3^1443+1.[/QUOTE]

What is it? I trust this completes the factorization.

[QUOTE=CRGreathouse;238502]What is it? I trust this completes the factorization.[/QUOTE]

It is available on the ECMNET 'latest' webpage. I did not extract its
value.

That's a very nice factor. Now, I am pretty sure that my p63 won't survive top-10 for the year. Which is pretty impressive if we compare top-2010 to top-2009 for example.


[SIZE=1]P.S. Note that base 3 PRP test is no good for these 3+ and 3- extensions. It is easy to step into it. For example, the c204 composite cofactor for 3,748+ is a 3-PRP. But this 3,1343L c154 factorization is indeed complete.[/SIZE]

[QUOTE=Batalov;238534]That's a very nice factor. Now, I am pretty sure that my p63 won't survive top-10 for the year. Which is pretty impressive if we compare top-2010 to top-2009 for example.


[SIZE=1]P.S. Note that base 3 PRP test is no good for these 3+ and 3- extensions. It is easy to step into it. For example, the c204 composite cofactor for 3,748+ is a 3-PRP. But this 3,1343L c154 factorization is indeed complete.[/SIZE][/QUOTE]

Please note that 3^k+1 is going to be a 3-PRP......

Of course. As well as Eisenstein Mersenne norms, and GFN3'. There was a storm in a glass of water in the corresponding OEIS sequences once...

[QUOTE=R.D. Silverman;238498]Sam Wagstaff just found a P69 factor of 3^1443+1.[/QUOTE]

I want to know, why this number was being done by using ECM, after such an extended effort. After all, this number was only 154 digits, could have been done so by using GNFS. Was it really ECM, first of all? Or that was it an arbitrary sigma, B1 values that was being entered into that factor form as ECM, rather? ;-) In my opinion, clearly that for now ECM time could be spent upon that much harder candidates.

@bdodson: I have released with 10,590M 2,985- for now. You may feel free to reserve it up. (If you wish to do so - if it was the case that you had with these two numbers as an active target before itself). They certainly require with gnfs-lasieve4I16e lattice siever, that takes up with more memory. I am concentrating upon 2,2334M 2,1930M 2,2334L sieving at this moment. If they go unreserved, then rather I will take them up depending upon my availability of resources, a few more months later on.

[QUOTE=Raman;238559]I want to know, why this number was being done by using ECM, after such an extended effort. ... [/QUOTE]

Sam reported a bunch of ecm factors from the 3+ extension using
B1 =350M. I don't see evidence of a test to p60 having been completed;
and am still running short tests with p60-limits, submitting 5700 curves,
B1 = 260M (c. 3t50 << t55) on the numbers Sam's promoted from the
3- extension to the regular Cunningham tables.

There was a previous factor from Sam using B1 = 500M. I'm guessing that
he ran a few curves on each number in the 3+ extension, then bumped his
limits up to the B1 = 600M used to find this p69 (the very first found by
ecm, and record for non-PS3 ecm!). Unless you have some reason to
believe that there were 10,000s of curves run on this C154?

[QUOTE]
... In my opinion, ...

@bdodson: I have released with 10,590M 2,985- for now. You may feel free to reserve it up. (If you wish to do so - if it was the case that you had with these two numbers as an active target before itself). They certainly require with gnfs-lasieve4I16e lattice siever, that takes up with more memory. I am concentrating upon 2,2334M 2,1930M 2,2334L sieving at this moment. If they go unreserved, then rather I will take them up depending upon my availability of resources, a few more months later on.[/QUOTE]

Thanks, I noticed that these went from reserved "Raman" to being still
listed on Sam's "who's factoring" page, but open to whoever wants them
soonest. I think that you've complied with Bob's comment on your number
reservations being more than you'd be able to do in a month or two. I wasn't
clear whether he intended to try sieving these specific numbers; and
believe I recall that he was considering switching to ecm, if they were too
difficult.

So far as I've heard, I don't think that Serge would consider reserving these
numbers for B+D if there's still a chance that you'll be able to get to them
(including doing the matrix) before your current resources time out. We
still have the more wanted 5p394 that's available in our current range; and
I expect to be sieving 5p397 (snfs) and Tom's 2p956 (gnfs) for some time.

-Bruce