[QUOTE=R.D. Silverman;169368]My joint paper with Sam Wagstaff: "A Practical Analysis of ECM"
gives an exact abort strategy for when to shift from ECM to QS/NFS.

[/QUOTE]

I was very happy to have gotten a copy from you; and spent many years
relying upon the table for effort (in curves) to find a factor of a given size,
before the appearance of Peter's thesis, and ecm/fft --- with performance
now matched/improved by gmp-ecm. But there's a mis-match in the
assumptions, if I understand correctly. The analysis supposes that the
same resources are being applied to both sieving and ecm. In my case,
sieving is on x86-64 clusters (Opteron and intel/quadcore), while ecm
is being run on a grid of pcs, not suitable for sieving. So -- for me --
it's not a case of deciding when to switch from ecm to sieving; the pcs
are always running ecm, the x86-64s always sieving (when they're not
being applied to higher purposes in grad education).

As far as I can tell, you're the unique person here that doesn't mind finding
p51-p54's by snfs. For me, the optimization is between tedium in running
ecm on a number that we don't expect to have a factor in ecm range,
vs my co-worker being unhappy with an occasional small factor. -Bruce

Yes. There is an implicit assumption that the resources are the same
for both methods.

[QUOTE=bdodson;169404]
As far as I can tell, you're the unique person here that doesn't mind finding
p51-p54's by snfs. For me, the optimization is between tedium in running
ecm on a number that we don't expect to have a factor in ecm range,
vs my co-worker being unhappy with an occasional small factor. -Bruce[/QUOTE]
I don't mind. I take the view that :poop: happens.

To pay for the pleasure of finding an unusually large factor by ECM, you have to take the disappointment of finding an unusually small one by NFS which had previously been missed by ECM.

Paul

[QUOTE=xilman;169468]
To pay for the pleasure of finding an unusually large factor by ECM, you have to take the disappointment of finding an unusually small one by NFS which had previously been missed by ECM.

Paul[/QUOTE]

An interesting observation, on an under-explained possible property
of ecm --- there seems to be a better chance of finding an unusually
large factor by ecm from a collection of numbers that haven't been
substantially searched for factors. Of course, there'll be more small
factors found from a newer collection, but I'm thinking of early large
factors, found well below the number of expected curves. Maybe
this is just an impression, on too sparse data. There aren't many
collections from which factors below p55 have already been removed
(to 80%, 2t55?; a little below, 2t53.5, say), but that oughtn't to have
too seriously depleted factors in [p58,p70], certainly not in [p62,p70],
for very unusually large factors.

I am developing some experience running numbers post 4t50; and
wondering whether there's any reason why to expect (as Paul seems
to suggest) that these numbers would be less likely to produce a
factor in the top 3 of the year? I did run fewer curves in 2008 than
in 2007, perhaps only half as many, but we're getting rather well into
2009 by now. Perhaps I ought to include 2007, with a single p62; except
for the three from p60-p61. The number of curves run here in 2006 was
way below the number in 2007. More in curves in 2008 than 2006. More
in 2006 than in 2005; but those were the years with p66, p67.

Perhaps numbers from c234-c320 with factors below p47 removed include
many more numbers with no factors below p70? I spent a lot of curves/time
there, as well as in parts of c160-c233 with few factors below p52.
-Bruce

[QUOTE=fivemack;169360]
I'd better figure out some polynomial-search parameters, or some indisputably SNFS number of less than 255 digits and difficulty around 265. Help?[/QUOTE]

Is 3, 562+ C255 diff 269 too large? It's way under-tested for ecm.

There's c243 2^1043 - 1 (SNFS 269.12). Also hard is
c241 6^346 + 1 (SNFS 269.24). A number that has been ecm'd is
[code]
c238 3^551 - 1 (SNFS 262.89) [/code]
although Batalov has already looked at parameters (and might reserve
it soon for Batalov+Dodson? ... we could find another one).
Probably no one has looked at c236 7^338 + 1 (SNFS 263.67), likewise
c239 3^563 + 1 (SNFS 268.62). -bd

3,562+
 

I'll give up anything to the mersenneforum! :smile:
(well, [I]almost[/I] anything)
There are plenty of good numbers for everyone!

I think 3,562+ c255 is an excellent number. (I was looking at it, too.)
It will sieve with any old-fashioned siever (I guess this is one of Tom's concerns).

[SIZE=1]3,562+ not to be confused with 5,362+[/SIZE]

Base 3, my hobby horse! I'd be glad to help sieving this one.

Alex

[QUOTE=bdodson;169477]Is 3, 562+ C255 diff 269 too large? It's way under-tested for ecm.

There's c243 2^1043 - 1 (SNFS 269.12). Also hard is
c241 6^346 + 1 (SNFS 269.24). A number that has been ecm'd is
[code]
c238 3^551 - 1 (SNFS 262.89) [/code]
although Batalov has already looked at parameters (and might reserve
it soon for Batalov+Dodson? ... we could find another one).
Probably no one has looked at c236 7^338 + 1 (SNFS 263.67), likewise
c239 3^563 + 1 (SNFS 268.62). -bd[/QUOTE]


2,923+ ????

That's done (Page 110). I fell into the same trap. They did it so fast (Tom+Bruce) that it didn't even register in people's memories.


Here's one that may be interesting (it's a quintic) - 2,979+ c255 (diff.268)

[QUOTE=Batalov;169563]That's done (Page 110). I fell into the same trap. They did it so fast (Tom+Bruce) that it didn't even register in people's memories.


Here's one that may be interesting (it's a quintic) - 2,979+ c255 (diff.268)[/QUOTE]


There are a number of suitable 2,LM candidates; e.g. 2,1762L etc.

For some reason, people seem reluctant to work on the 2LM table.

[QUOTE=akruppa;169533]Base 3, my hobby horse! I'd be glad to help sieving this one.

Alex[/QUOTE]

Yes, the very reason we considered it. The 3- list is getting shorter.

On 2LM, Batalov + Dodson did 2,1618L, will be starting sieving on
2, 1686L as soon as I'm ready for a break from 12+256 (Womack+Dodson),
and have just reserved 2,2086M C268=diff268. -Bruce