If it's mainly luck, they should try ecm on 2,1061- :smile:

(there are still plenty of curves for the 60 digit level to be done...)

See the thread [url]http://www.mersenneforum.org/showthread.php?t=7850[/url]. All the usual suspects agree that there is a rumour that someone allegedly might possibly have, per chance, started sieving 2,1061-. But of course, that is completely unofficial.

Alex

[QUOTE=akruppa;104467]See the thread [url]http://www.mersenneforum.org/showthread.php?t=7850[/url]. All the usual suspects agree that there is a rumour that someone allegedly might possibly have, per chance, started sieving 2,1061-. But of course, that is completely unofficial.

Alex[/QUOTE]

With their ressources AND luck A. Bhargava/S. Pelissier could possibly crack M1061 within a few days - with a record-smashing factor :wink:

I really, [I]really[/I] don't think they will run ECM on this number.

Alex

[QUOTE=akruppa;104469]I really, [I]really[/I] don't think they will run ECM on this number.

Alex[/QUOTE]

As you see on my smilies, I am just joking.

P.S.: @akruppa: Have you looked into the GMP-ECM memory estimation thread?

[QUOTE=Andi47;104468]With their resources AND luck A. Bhargava/S. Pelissier could possibly crack M1061 within a few days - with a record-smashing factor :wink:[/QUOTE]

Even the smilie doesn't make this a plausible joke. One of the
"resources" important in ecm is knowing when to quit. Sam's page
gives the current

[QUOTE]
Largest penultimate prime factor (ultimate factor shown also):
5331 p120*p155 6,353- Aoki+Kida+Shimoyama+Ueda
5373 p108*p136 5,349- Kruppa/Franke/Kleinjung/Bahr/CWI
[/QUOTE]

Those are from composites with c. 244-digits and 275-digits; while
M1061 has 320-digits, and might very well be worse. Recall that the
upper range of what we're imagining might be the next ecm record
is p7x, say p77 for 256-bits for an upper bound. Time spent on
composites with smallest prime factor of p90-or-above is virtually
certain to be wasted. That's the reason my current Opteron run
is in c190-c233; and one of the reasons the smaller memory xp's
working in c234-c250 (last 18 numbers, last 500 curves needed
for t50) and on the parts of the 2- and 2+ list in c280-c355,
n < 1200 (last 17 numbers, last 1000 curves needed for t50)
have a much smaller chance of producing a record-sized prime
factor. It's also an advantage for the BMtR numbers which (iirc)
have smaller upper-size bound, as compared to the (regular)
Cunninghams.

People that prefer to impose Brent's restriction on the ratio
(size-of-composite)/(size-of-prime-factor) > 2.2 for "Champion"
ecm factors might argue as above, despite the fact that the
size-of-composite is a lower order term in the runtime. To recall,
the new p61, from a c132, didn't meet this condition. And, by
contrast, when we're discussing the "hardest" ecm factorization,
one can make a good case for Aoki's p64, from the previous
kilo-bit snfs candidate R311 = C311 = 111...1 (311-digits), rather
than the larger p66/p67. Aoki reports

[QUOTE]
We spent 7.91 PC years to find the factor, and the calendar time is
about 3 month. The above PC means Opteron 2.0GHz with 4GB RAM, and,
of course, we used many kind of PCs. I presented the statistics for
R311 factorization at Japanese domestic workshop: SCIS2006. If you
are interested in this manuscript, I will send it, but the manuscript
is written in Japanese. [/QUOTE]

There's a certain amount of bravery (and/or foolhardiness) needed
to spend this amount of effort of such a hard number (cf. Richard's
p40 from F10, with over 500-digits, and prime cofactor). The only
plausible justification (in Aoki's case) being interest in the kilobit
snfs. Since M1061 is/was the next most likely case (after Peter's
favorite R311 broke), this is yet another reason why M1061 isn't
a good candidate (aside from the reason Alex refers to for it being
a VERY bad candidate). -Bruce

To be precise: I'm not saying that M1061 is a bad candidate for ECM. What I'm saying is that I am certain that Bhargava and Pelissier are not running ECM on it.

Alex

[QUOTE=bdodson;104548]Even the smilie doesn't make this a plausible joke. One of the
"resources" important in ecm is knowing when to quit. Sam's page
gives the current

<snip>

There's a certain amount of bravery (and/or foolhardiness) needed
to spend this amount of effort of such a hard number (cf. Richard's
p40 from F10, with over 500-digits, and prime cofactor). [/QUOTE]

Applause. We are in violent agreement. Chasing M1061 iwith ECM is
almost certainly pointless at this point.

I assume 500 digits was a typo? F10 only has 309 digits.

[QUOTE=akruppa;104467]See the thread [url]http://www.mersenneforum.org/showthread.php?t=7850[/url]. All the usual suspects agree that there is a rumour that someone allegedly might possibly have, per chance, started sieving 2,1061-. But of course, that is completely unofficial.

Alex[/QUOTE]

Which program is able to do kilobit SNFS, and how long would it take? (i.e. if the rumors are true - can we expect the result before 2010?)

[QUOTE=Andi47;104562]Which program is able to do kilobit SNFS, and how long would it take? (i.e. if the rumors are true - can we expect the result before 2010?)[/QUOTE]Several can do it. Some can do it more efficiently than others.

How long it takes depends on how many resources you have available. (Ask a silly question, get a silly answer. :wink: )

I would expect to see an answer long before 2010, unless by that you mean "before bedtime".


Paul

[QUOTE=R.D. Silverman;104554]Applause. We are in violent agreement. Chasing M1061 iwith ECM is
almost certainly pointless at this point.

I assume 500 digits was a typo? F10 only has 309 digits.[/QUOTE]

Mis-connected memory curcuit. The cofactor is p252. Perhaps
I had F10 and F11 mixed, the latter has a p564 -- but doesn't
take so much effort to find (in retrospect), the 2nd largest prime
was p22 (1983, also Brent). I think I know why Alex is sure
B&P wouldn't be running M1061. Actually, I never heard directly
that M1061 was the target; but other people did, apparently.
But the time-frame was supposed to be a few months, which was
a few months ago. If we were setting an office pool, I'd want
"before ***". Unless something went wrong in the next-to-last
step. And don't ask, already! We'll know soon enough. Or not.
-Bruce