Prime95 version 29.4

[GP2]

Originally Posted by bayanne

Any other suggestions would be most welcome

Look at the file prime.txt

It should have a line of the form

WorkPreference=

with a numerical value.

Is the numerical value 150 or 151? Or perhaps even 0?

If it's anything other than 2, then stop the program, and change that value to 2, then restart the program.

[bayanne]

Originally Posted by GP2

Look at the file prime.txt

It should have a line of the form

WorkPreference=

with a numerical value.

Is the numerical value 150 or 151? Or perhaps even 0?

If it's anything other than 2, then stop the program, and change that value to 2, then restart the program.

No, it is already set at 2 ...

[Prime95]

Check all the CPUs at mersenne.org website. Perhaps your computer spontaneously renamed itself (it has been known to happen). Sorry, I'm on a cruise ship right now and cannot peer into any of the server databases.

[preda]

Originally Posted by bayanne

It has just grabbed yet another PRP.

This is beginning to get tiresome ...

Probably what the server is really trying to say is, that you really shouldn't do TF on the CPU, and that PRP is a better choice :)

(that was a joke; but speaking seriously probably a CPU is better used to do any of LL, LL-DC, PRP. Anyway, that does not invalidate your choice).

[kladner]

Originally Posted by bayanne

Not really with you there, sorry ...

Whereabouts on my system is it finding that I want PRP?

I know this sounds flaky. However, in the past there were situations in which P95/PrimeNet were balky about work type changes. This procedure worked back then. Now, the same factors (no pun intended) may not be in play, what with the new functions being addressed.

[Dubslow]

Originally Posted by kladner

On the client, try changing the work type to anything but your target. Make it communicate with the server, and send new completion dates. Check online to see if the change carried over. Assuming that it did, reset to your desired type on the client. Manually communicate again, with completion dates checked. See if the server matched the type change.

In the past, this sequence would usually get things in sync. If the server is not responding to the changes, I am not sure what to do next.

Once the server and client are in agreement you can unreserve unwanted assignments.

Originally Posted by bayanne

Not really with you there, sorry ...

Whereabouts on my system is it finding that I want PRP?

kladner's advice is quite good. Generally, in our collective experience, if Prime95 refuses to get the right type of work, it's because the server's saved workpreference differs from the client's saved workpreference. kladner's list of instructions is a way to "flush" the settings so that the client and server are synchronized. It's the best advice I've seen so far in this thread, so I definitely recommend trying to understand his post one more time.

[ATH]

Originally Posted by Prime95

Sorry, I'm on a cruise ship right now and cannot peer into any of the server databases.

Ahh so you are on vacation?!?!? That is usually the time we find a new Mersenne Prime!! *crosses fingers*

(We really need a *crosses fingers* or *hoping* smiley)

[bayanne]

Originally Posted by Prime95

Check all the CPUs at mersenne.org website. Perhaps your computer spontaneously renamed itself (it has been known to happen). Sorry, I'm on a cruise ship right now and cannot peer into any of the server databases.

That was it, the cpu in question had not changed itself on the server to TF and was still showing PRP

Now all I need is someone who is able to compile mfaktc on a Mac ...

[kladner]

Glad you found the glitch!

[GP2]

Prime95 29.4 build 5 is refusing to do PRP-CF on a few exponents:

In my results.txt files:

4456310665879544089 does not divide M2207441
12415622589540644657 does not divide M2233183
1219861756779140901119 does not divide M2233019

All of these statements are false, actually.

It should be very straightforward to do modular exponentiation with a GMP library function. The condition 2^p (mod f) == 1 is obviously true if f is a factor of 2^p − 1

Some previous versions were able to do these exponents.

Just now, it seems that YarBer completed PRP-CF for M2233183, I'm not sure with what version, but the result shows as "Verified (Factored)" rather than Verified, which basically means it's not considered a match with the currently known factors.

[R. Gerbicz]

Originally Posted by GP2

Prime95 29.4 build 5 is refusing to do PRP-CF on a few exponents:

In my results.txt files:

4456310665879544089 does not divide M2207441
12415622589540644657 does not divide M2233183
1219861756779140901119 does not divide M2233019

All of these statements are false, actually.
.

On each exponent there are problems, see for example:

M2207441/211914337/325862722477981217/4456310665879544089/4456310665879544089 is not prime. Res64: 6550ADD498325C__

for q=4456310665879544089 it is true that q divides M2207441, but here q^2 doesn't divide, so the posted number M2207441/factors is not even an integer. [This also means that if you see it in this way the posted message could be even true, because the second(!) q factor doesn't divide M2207441].