Strange ECM assignment.

[chalsall]

Morning all.

I've just noticed a very strange ECM assignment from the V5 server: 2097152

Since Mersenne Primes must have an exponent which is also prime, I'm wondering why this was handed out.

And, in fact, this was assigned to one of my machines three times. It *did* find a factor (4485296422913), and yet its continuing to work on the same assignment again (and taking several days to do so).

Unfortunately I can't readily access this machine, so I'm going to have to simply wait for it to finish wasting its time.

Any ideas?

[Prime95]

You are doing ecm on the 21st Fermat number. There is one known factor - and the work assignment should tell the client what it is (a bug was fixed in that regard about a week ago). If the assignment is very recent, send me the prime.log file.

[chalsall]

Originally Posted by Prime95

You are doing ecm on the 21st Fermat number. There is one known factor - and the work assignment should tell the client what it is (a bug was fixed in that regard about a week ago). If the assignment is very recent, send me the prime.log file.

Ah, OK. Thanks.

The only other thing I found strange was it assigned the same number to the same machine three times -- and it's diligently finding the same factor...

I'm afraid I don't have easy access to that machine, so I can't send you the prime.log.

[cheesehead]

chalsall,

The nature of ECM's search for factors differs from that of TF or P-1. Those two methodically step through a given search space and are guaranteed to find a factor if one exists within the search space bounded by the given parameters (start and end for TF, B1/B2 for P-1). In each case, after an unsuccessful search concludes, it is possible to later resume at the particular point where the unsuccessful search stopped and then proceed to higher bounds than the previous search covered, without overlap.

Although ECM also has B1/B2 bounds like P-1, it does not methodically step through the search space defined by them, but instead tries random elliptical curves that are defined within that search space. (AFAIK there is no practical way to do an exhaustive search of an ECM search space by methodically stepping through it as with TF or P-1. According to my understanding, another way of saying this is that any attempted methodical choice of curves gets the same or worse result as a random choice of curves, but I'm not an ECM expert so that last part may be wrong.) The more curves it tries, the higher are its chances of finding a factor if one exists within that search space, but there's never a 100% guarantee that it will succeed.

ECM is like fly-fishing (or casting), compared to net-fishing (TF,P-1), but its "fly-fishing" (or casting) can be tried in regions too big for practical "net-fishing".

Originally Posted by chalsall

The only other thing I found strange was it assigned the same number to the same machine three times

... which is normal for ECM, which is designed to try a different set of (pseuo-)random curves (by starting with a different seed for its pseudorandom curve generator) in each assignment.

-- and it's diligently finding the same factor...

Yes, that is what can happen in ECM -- the same factor can show up on different elliptical curves. And the smaller the factor, the more different curves will contain it.

Normally, the ECM assignment should include a list of known factors for the number being ECMed, so that when any of them is (re)found, the program will just skip it instead of reporting it as a found factor. That's what George meant by "There is one known factor - and the work assignment should tell the client what it is".

[xilman]

Originally Posted by cheesehead

but instead tries random elliptical curves

I try not to pick up on speeling mistakes, except for humerus porpoises or when the context demands it. However, I feel duty-bound in this instance to note that they are elliptic curves and not elliptical curves.

Paul

[cheesehead]

Originally Posted by xilman

I try not to pick up on speeling mistakes, except for humerus porpoises or when the context demands it. However, I feel duty-bound in this instance to note that they are elliptic curves and not elliptical curves.

... and I thank you for that.

I mixed up my astronomy with my math.