mersenneforum.org ECM change
 Register FAQ Search Today's Posts Mark Forums Read

2019-11-22, 03:15   #12
R.D. Silverman

Nov 2003

26·113 Posts

Quote:
 Originally Posted by R.D. Silverman The tables under discussion (and for which there was a request to add a column) do not go nearly that high. They max out at exponents ~15K. (i.e. numbers of ~4K digits max). For numbers in the millions of digits convolution methods are clearly out of reach. For 2^p-1, p< 5K I see no reason not to use convolution based step 2. Save the step 1 result then use GMP-ECM for step 2. Furthermore, no one is discussing ECM at B1=800M for numbers of the size you suggest.
Note further that for exponents > 5K B1 only goes up to 11M (so far) and for
exponents > 11K B1 only goes up to ~3M. The ECM testing to 11M for p > 5K isn't
even complete. Nor is the testing to 3M for p > 11K.

For B1 near 3M, putting B2 = 100 B1 is not unreasonable. The default B2 would be 5 x 10^9.

For the numbers you mention (millions of digits) what B1 values have been used?
Indeed. Have any curves been run at all?

For the numbers being run at B1 = 800M, introducing million digit numbers into the
discussion is a complete red herring.

2019-11-22, 03:16   #13
Prime95
P90 years forever!

Aug 2002
Yeehaw, FL

2×3×1,193 Posts

Quote:
 Originally Posted by alpertron It is clear that the should be no need to use Prime95 to discover prime factors of more than 55-60 digits.
Everyone is correct. For ECM on small numbers (up to about 20000 digits) we strongly encourage folks to use GMP-ECM. Note that GMP-ECM can be linked with prime95 FFT routines. This can result in a 2x or 3x speed up in stage 1 for base 2 numbers.

For simplicity's sake, the ECM tables at the server display the curves and bounds needed for B2 = 100*B1 for both small and large numbers.

2019-11-22, 03:28   #14
alpertron

Aug 2002
Buenos Aires, Argentina

101001101012 Posts

Quote:
 Originally Posted by R.D. Silverman For the numbers you mention (millions of digits) what B1 values have been used? Indeed. Have any curves been run at all?
You can see in https://www.mersenne.org/report_ecm/ the effort done on Fermat numbers.

For example, for 2^33554432+1 (F25, about 10 million digits), the 35-digit level was finished and Prime95 has run the equivalent of 684 curves with B1 = 3M, B2 = 300M.

Last fiddled with by alpertron on 2019-11-22 at 03:30

2019-11-22, 03:32   #15
R.D. Silverman

Nov 2003

26·113 Posts

Quote:
 Originally Posted by alpertron The program Prime95 is optimized for huge numbers. Ryan Propper uses GMP-ECM or a similarly step-2 optimized application, and then he sends the results manually to the Primenet server. .
Therefore running 360000 curves at B1 = 800M is massive overkill as I said. The table
does say that 360K curves at 800M have been run for several numbers. e.g. M1277
It says that over 100K curves have been run for some other numbers and over 85K
for some others. [and 70K to 80K for others] For these numbers it is time to increase B1.

The range 1500 < p < 1700 has over 150K curves run. This too is overkill for
B1 = 800M. It is roughly 2*t65.

The range 1400 < p < 1500 hasn't even started a t60, while many larger exponents
have finished t60.

Many numbers report t60 with B1 = 260M and 112K curves as "DONE". This too
is overkill on the number of curves for t60.

Or are these entries wrong?

This is for the table: https://www.mersenne.org/report_ecm/

It seems that a lot of CPU effort has been WASTED by running too many curves for
a given B1.

Last fiddled with by R.D. Silverman on 2019-11-22 at 03:33 Reason: one additional sentence

2019-11-22, 04:43   #16
axn

Jun 2003

23×3×199 Posts

Quote:
 Originally Posted by R.D. Silverman Therefore running 360000 curves at B1 = 800M is massive overkill as I said. It seems that a lot of CPU effort has been WASTED by running too many curves for a given B1.
I think you missed the fact that these are 360,000 "curve equivalents". Noone has run 360k curves with GMP-ECM defaults. They have run the proper amount, and the server is recording it in B2=100B1 equivalent counts.

2019-11-22, 06:59   #17
R.D. Silverman

Nov 2003

11100010000002 Posts

Quote:
 Originally Posted by axn I think you missed the fact that these are 360,000 "curve equivalents". Noone has run 360k curves with GMP-ECM defaults. They have run the proper amount, and the server is recording it in B2=100B1 equivalent counts.
Except that "equivalent" is wrong, or at least misleading. Running 360K curves
with B1=800M and B2=100*B1 may give a 1-1/e probability for t65, but its
probability for say 70 digit factors will be different from running an "equivalent" set
of fewer curves with higher B2. Similarly for other sized target factors.

They are equivalent only for one particular factor size.

Keep in mind that running a set of curves at a given limit gives a pdf. It has
a probability of success for a range of different factor sizes. Running a different
set may give an equal probability AT ONE SIZE, but it will differ for other sizes.

The "equivalence" is not really an "equivalence". When one converts a set of
curves to an "equivalent" set for one size you lose information.

And the term "proper amount" begs the question. Note that the GMP-ECM
defaults are not truly optimal. What is the "proper amount"??

I would prefer to list actual counts and B1, B2. However much of that info has been lost
owing to "conversions to equivalent counts with B2 = 100 B1".

BTW, the headings on the web page should document the "conversion".

2019-11-22, 07:05   #18
R.D. Silverman

Nov 2003

26×113 Posts

Quote:
 Originally Posted by alpertron You can see in https://www.mersenne.org/report_ecm/ the effort done on Fermat numbers. For example, for 2^33554432+1 (F25, about 10 million digits), the 35-digit level was finished and Prime95 has run the equivalent of 684 curves with B1 = 3M, B2 = 300M.
Indeed. You are correct. Some FERMAT numbers for large candidates have been run.

This is another red herring since the discussion is about Mersenne numbers. Why do you
keep deflecting the discussion?

The tables show zippo for Mersenne numbers above exponent 15K.

2019-11-22, 07:19   #19
R.D. Silverman

Nov 2003

26·113 Posts

Quote:
 Originally Posted by R.D. Silverman Except that "equivalent" is wrong, or at least misleading. Running 360K curves with B1=800M and B2=100*B1 may give a 1-1/e probability for t65, but its probability for say 70 digit factors will be different from running an "equivalent" set of fewer curves with higher B2. Similarly for other sized target factors. They are equivalent only for one particular factor size. Keep in mind that running a set of curves at a given limit gives a pdf. It has a probability of success for a range of different factor sizes. Running a different set may give an equal probability AT ONE SIZE, but it will differ for other sizes. The "equivalence" is not really an "equivalence". When one converts a set of curves to an "equivalent" set for one size you lose information. And the term "proper amount" begs the question. Note that the GMP-ECM defaults are not truly optimal. What is the "proper amount"?? I would prefer to list actual counts and B1, B2. However much of that info has been lost owing to "conversions to equivalent counts with B2 = 100 B1". BTW, the headings on the web page should document the "conversion".
Not also that rather than listing "converted curve counts at a given value of B1",
you could also list the effort as a fraction; i.e. what fraction of the effort required to
achieve a search for a particular size has been run.

Example. Rather than list 111K curves with B1 = 800M for M1213, as it does now,
curve counts.

And giving 6 significant digits for the curve counts is also somewhat misleading because
it conveys an impression of accuracy that really isn't there. Especially after a "conversion".

2019-11-22, 07:47   #20
axn

Jun 2003

477610 Posts

Quote:
 Originally Posted by R.D. Silverman Except that "equivalent" is wrong, or at least misleading.
True, but irrelevant. I was responding to your statement that "effort has been WASTED". Can you admit that you were mistaken about that?

Quote:
 Originally Posted by R.D. Silverman The tables show zippo for Mersenne numbers above exponent 15K.
That tables have a couple of input text boxes above them. You can vary the start and end values to get a different ranges. GIMPS is running ECM on all mersennes < 20M

Quote:
 Originally Posted by R.D. Silverman And giving 6 significant digits for the curve counts is also somewhat misleading because it conveys an impression of accuracy that really isn't there. Especially after a "conversion".
It takes more (programmer) work to do all that niceties. Why bother? This is the value that the server uses to decide when to hand out assignments at the next level, so it needs to treat these numbers as exact, even if mathematically that is not proper.
Plus, does it really affect the optimality of ECM if these numbers are off by a few percent? What's the big deal if you do a few percent more or fewer curves than optimal at each level?

 2019-11-22, 08:43 #21 LaurV Romulan Interpreter     Jun 2011 Thailand 3·13·229 Posts I think you are all right, as George said, and about "wasting" the effort, a lot of factors are still coming from the ECM trenches, which means for me (not the LaurV with any minimal math knowledge, but the pragmatic LaurV, with no math, but with logic and common sense) that there is no effort wasted. As long as the factors come, people are producing. How are they equivalating (is this a word?) the hammers and screwdrivers with pneumatic hammers and dynamite, I couldn't care less... If there would be no ore coming, and yet people continue digging, I would say, well, stop the factory, we are wasting time... Last fiddled with by LaurV on 2019-11-22 at 08:44
2019-11-22, 12:48   #22
R.D. Silverman

Nov 2003

26·113 Posts

Quote:
 Originally Posted by axn True, but irrelevant. I was responding to your statement that "effort has been WASTED". Can you admit that you were mistaken about that?
No, because by using a sub-optimal parameterization it took more CPU time than
necessary. We don't know the extent since the "conversion" destroys the information
needed. [exact curve counts, both B1 and B2 values]

Quote:
 It takes more (programmer) work to do all that niceties. Why bother?
I said why. It conveys a mis- impression that the data is more accurate than it is.
Didn't you study the use of sig-figs in scientific tables while you were in secondary
school?

Quote:
 This is the value that the server uses to decide when to hand out assignments at the next level, so it needs to treat these numbers as exact, even if mathematically that is not proper.
OK. I get it. You don't care about being mathematically correct.

Quote:
 Plus, does it really affect the optimality of ECM if these numbers are off by a few percent? What's the big deal if you do a few percent more or fewer curves than optimal at each level?
We don't know if it is just a "few percent" because the data has been destroyed.

What does matter is that the tables convey misinformation about the pdf's. It would
be nice to know, for example, when one runs a t65 what the probability was of
finding/missing factors of OTHER sizes. The conversion makes that impossible.

 Similar Threads Thread Thread Starter Forum Replies Last Post GinoTitan PrimeNet 4 2016-05-29 19:25 deepesh Hardware 5 2016-04-05 05:30 Fred Lounge 8 2016-01-31 17:42 Xyzzy Lounge 5 2009-08-31 12:41 Andriy Information & Answers 1 2009-06-20 12:39

All times are UTC. The time now is 17:35.

Tue Nov 24 17:35:26 UTC 2020 up 75 days, 14:46, 4 users, load averages: 0.97, 1.31, 1.44