Status of Wagstaff testing? and testing Mersenne primes for Wagstaff-ness

[diep]

I think another important thing to note is perspective from which you write things. If you work for government you probably have a lousy GPU and relative new CPU.

However, most users at home they have a fast GPU and old outdated CPU most of the cases and your computer works for more years than at the government.

Especially the CAD i'm doing requires fast GPU's and whatever sort of CPU you got is total irrelevant.

Kids that game want a fast GPU and the cpu really is less relevant and has less cores in general.

So the amount of times the GPU is faster than the CPU is far greater than most uni professors over here.

[axn]

Originally Posted by diep

>> Originally Posted by diep View Post
>>a) there is a smaller percentage of numbers left with wagstaff after TF than with >>mersenne.
> I don't know why this should be so... but I'll take your word for it. However this has > no relevance as to whether doing P-1 after TF is worthwhile.

Sir, if you do not understand this one, i propose that you first study this one in depth first before claiming it doesn't matter.

Go ahead. Put forth your argument as to why this is relevant.

Originally Posted by diep

Originally Posted by diep View Post
>> b) nowadays the TF is far far far deeper than years ago with Mersenne
> Due to GPU-TF. If Wagstaff's have also been similarly deeply TF'ed with GPUs, then the P-1 breakeven point would shift

It is a very silly assumption to assume you will not be using some massive gpu's to TF.

The amount of system time to factor with a silly algorithm like P-1 provable is nonsense except if you can do that on hardware that wouldn't be used for PRP-testing otherwise.

GPU's are so much faster than the hardware most have to do PRP-testing, it's just not even funny to compare the 2.

I made no assumptions -- merely noted that if they are used, it will shift the P-1 breakeven point. But you still need to actually model your probabilities to know if P-1 is worthwhile

Originally Posted by diep

Originally Posted by diep View Post
>> Oh it does compared to the alternatives.
> What alternative? P-1 is a complementary method to TF, not an alternative. And ECM is not cost competitive with P-1. What other alternative is there?

You get what you pay for.

What are we trying to do with TF & P-1? When we say P-1 is effective, we mean that running P-1 will reduce overall time to prove a number composite. Thus you'll spend fewer resources figuring out the primality status of all the given candidates. In that respect, ECM is a net loss. You'll save fewer resources of PRP testing than whay you would put into the ECM.

Originally Posted by diep

>> d) we divide by 3 so it's not a +1 number of bits. It's a -1 number of bits.
> Not sure I understand. What do you mean by this?

Wagstaff is a much harder beast than Mersenne.

For same P wagstaff is 1.5 bits smaller than mersenn. Big deal! Makes no difference. If anything, it makes wagstaff tiny bit likelier to be prime, but that's neither here nor there.

Originally Posted by diep

I think another important thing to note is perspective from which you write things. If you work for government you probably have a lousy GPU and relative new CPU.

However, most users at home they have a fast GPU and old outdated CPU most of the cases and your computer works for more years than at the government.

Especially the CAD i'm doing requires fast GPU's and whatever sort of CPU you got is total irrelevant.

Kids that game want a fast GPU and the cpu really is less relevant and has less cores in general.

So the amount of times the GPU is faster than the CPU is far greater than most uni professors over here.

GPU is way faster than CPU in some workloads (generalising since GPUs and CPUs come in wide variety of capability -- we can normalize for cost or power consumption to do apples-to-apples comparison). In other workloads they might be moderately faster or even slower. TF is certainly the first kind. Yet the 4-5 additional bits of TF that GIMPS gets out of GPUs helps the project maybe about 7% faster (compared to if those same GPUs did the LL testing). Not bad, but not earth shattering either.

[diep]

>or same P wagstaff is 1.5 bits smaller than mersenn. Big deal! Makes no >difference. If anything, it makes wagstaff tiny bit likelier to be prime, but that's >neither here nor there.

You seem a few lightyears away from grasping Wagstaff.

Can you compare odds for a prime wagstaff versus mersenne if we just look at the last few PRP's / primes found?

It's like 1.2 for mersenne to the next one and factor 3 to 4 for wagstaff.

that's not a 'tiny bit' of difference.
Please do not just post cheap remarks. My time is more expensive than yours.

[axn]

Originally Posted by diep

Can you compare odds for a prime wagstaff versus mersenne if we just look at the last few PRP's / primes found?

That's not how you do math. Maybe physics. But definitely not math.

[Batalov]

Originally Posted by axn

That's not how you do math. Maybe physics. But definitely not math.

No, not physics either. The word you are looking for is numerology.

We have a fine specimen of a numerologist here. With years of experience. Just search for his past posts.

[CRGreathouse]

Originally Posted by axn

That's not how you do math. Maybe physics. But definitely not math.

You can do math that way, it's called experimental mathematics. But looking at just the last few doesn't give you enough statistical power to say anything meaningful, so I agree that would basically put you back in the realm of numerology.

[GP2]

So far I have lists of factors from ATH, diep, lalera, bearnol... but not from some other major efforts that were active in 2013 and earlier. Perhaps those old factor lists were not conserved. Also FactorDB up to 1M.

ATH in particular "trialfactored: 10k<p<1M to 56bit, 1M<p<2M to 57bit, 2M<p<4M to 58bit, 4M<p<8M to 59bit, 8M<p<16M to 60bit, 16M<p<32M to 61bit, 32M<p<50M to 62bit."


I think TJAOI's method "by k" could also be used to generate factors for Wagstaff numbers, because they have the same 2kp+1 form. And it would probably find a lot more first factors, since Wagstaffs have only been lightly factored compared to Mersennes.

TJAOI's method was described by ATH in this post.

I have no idea how many resources TJAOI is throwing at the problem, but here's the timetable of when he reached each bit level, and also he finished 65 bits on April 12 of this year.

But assuming you only sieve the array up to, say, 50M instead of 1G, presumably it would go a lot faster?

Edit: If I'm reading it correctly, the sieving stage seems to be independent of Mersennes, it would be applicable to anything that has factors of the form 2kp+1. So if the results of that sieving were available as a list of surviving k, perhaps you'd only need to retest those same k, but this time as candidate factors for Wagstaffs instead of Mersennes? Assuming TJAOI conserved that information, of course.

How practical is this idea? And is it more suited to CPUs or GPUs?

[GP2]

There is a well-known heuristic for predicting the frequency of Mersenne numbers.

Do similar considerations apply for Wagstaff numbers?

[CRGreathouse]

Originally Posted by GP2

There is a well-known heuristic for predicting the frequency of Mersenne numbers.

Do similar considerations apply for Wagstaff numbers?

Are all factors of Wagstaff numbers (2^p + 1)/3 of the form 2kp + 1? If so then yes, a similar heuristic would drop out.

[ATH]

Originally Posted by GP2

I think TJAOI's method "by k" could also be used to generate factors for Wagstaff numbers, because they have the same 2kp+1 form. And it would probably find a lot more first factors, since Wagstaffs have only been lightly factored compared to Mersennes.

TJAOI's method was described by ATH in this post.

It cannot be that way TJAOI searches, then he would find factors of varying bit sizes all the time, but he seems to find them 1 bit size at the time.

[GP2]

Originally Posted by CRGreathouse

Are all factors of Wagstaff numbers (2^p + 1)/3 of the form 2kp + 1? If so then yes, a similar heuristic would drop out.

Empirically, yes. I'm sure there's an elementary proof, which the margin of this post is too small to contain.