I think that its high time for another prime. Specifically I predict that there will be a prime found between Oct 15, 2005 and Oct 25, 2005.
Any comments?
Printable View
I think that its high time for another prime. Specifically I predict that there will be a prime found between Oct 15, 2005 and Oct 25, 2005.
Any comments?
Sure. I don't think so. :)
So, you're predicting that there was a missed prime in the 3.5m<n<4m range....
I will actually second Joe's prediction. I've Always been of the stance that there was a missed prime between 2.5M<n<4M.
So maybe I should start my clients again then? :)
I know some of us are dissappointed in doing secondpass tests. Others such as myself are jumping up and down with smiles on our faces when doing these.
I think it just boils down to a stats issue, some people feel as though they are being jipped by the rate. Well, perhaps knowing that, at this point, it's good for the project will make the lower rate easier to swallow.
Any comments now?
:D
Nice prediction.
Jey Joe, what you know you were right!!! Good job SIR. :) I think you been hanging around vjs too long.:D
Glad you were correct in your prediction.
e:)
Eerie.
Do you have another prediction?
I think I'm going to hold off on all predictions until secondpass reaches 5M.
The good news is there is now only about 20K tests between 4M<n<5M
How about Joe. Does he have another prediction?:cheers:
Yes, he does!Quote:
Originally posted by DigitalConcepts
How about Joe. Does he have another prediction?:cheers:
Now should I wait until someone asks me what it is?
I think that 55459 is long overdue, but it may or may not be the next one found. We may have passed it, and will require a third pass to find it. Another one that I consider overdue is 10223.
I also think that we are one prime light right now, but because of the nature of the model I am using, we could still be on track and find one between 10M and 11M. But I really think that we should have found one more before 8.5M.
As to when, that depends on how long we stay on second pass, and whether we go back and do a third pass now for all the k n pairs that do not have a matching residue. This to me increases the chance of our finding a prime between now and January 14th, 2006.
I really would like to refine the model, and will do so as soon as I can. However, I am currently working on refining the sieve program. I am concentratring on lifting the 2^50 limit to 2^52. I would really like to go higher, but one of my goals is to allow the program to work on non x86 machines. Some of these targetted machines have a 2^56 limit without going to a multiprecision package, so I am going to push it as far as I can with this in mind.
If I investigate the primes found, i think there could be one around 2M (thirdpass) and one at 6.5M (secondpass) and I double Joe for 10-11M.Quote:
Originally posted by Joe O
Yes, he does!
Now should I wait until someone asks me what it is?
I think that 55459 is long overdue, but it may or may not be the next one found. We may have passed it, and will require a third pass to find it. Another one that I consider overdue is 10223.
I also think that we are one prime light right now, but because of the nature of the model I am using, we could still be on track and find one between 10M and 11M. But I really think that we should have found one more before 8.5M.
As to when, that depends on how long we stay on second pass, and whether we go back and do a third pass now for all the k n pairs that do not have a matching residue. This to me increases the chance of our finding a prime between now and January 14th, 2006.
I really would like to refine the model, and will do so as soon as I can. However, I am currently working on refining the sieve program. I am concentratring on lifting the 2^50 limit to 2^52. I would really like to go higher, but one of my goals is to allow the program to work on non x86 machines. Some of these targetted machines have a 2^56 limit without going to a multiprecision package, so I am going to push it as far as I can with this in mind.
Wht do you mean with thirdpass? Secondpass with not matching residues? I think the probability is rather high that one of both is right. Actually, it is 1-errorrate^2. Right?
So I don't believe in thirdpass primes.
I don't believe in any predictions, though, but especially not in this one.
Yours H.
This is a very good point. For instance(and I really hope my example isn't even CLOSE to actual error rates) if the error rate is 20%, we shouldn't do second-pass unless we can do 5 second-pass tests for every first-pass test. For third-pass, there's only a .2^2 chance that they're both wrong, which is .04, so you shouldn't do third-pass unless you can do 25 third-pass tests for every first-pass test.Quote:
Originally posted by hhh
Wht do you mean with thirdpass? Secondpass with not matching residues? I think the probability is rather high that one of both is right. Actually, it is 1-errorrate^2. Right?
So I don't believe in thirdpass primes.
I don't believe in any predictions, though, but especially not in this one.
Yours H.
If someone were hardcore convinced we needed a third-pass, I'm sure someone could write a script and send them a file and hacking instructions(if they need them) so that they could prp third-pass tests to their heart's content. As little money as it costs to max out a cpu if the computer's on anyway, I'd be happy to convince someone to run the Monkey Shakespeare project if it suited them.
See Joe's postQuote:
Originally posted by hhh
Wht do you mean with thirdpass? Secondpass with not matching residues? I think the probability is rather high that one of both is right. Actually, it is 1-errorrate^2. Right?
So I don't believe in thirdpass primes.
I don't believe in any predictions, though, but especially not in this one.
Yours H.
Quote:
As to when, that depends on how long we stay on second pass, and whether we go back and do a third pass now for all the k n pairs that do not have a matching residue. This to me increases the chance of our finding a prime between now and January 14th, 2006.
Exactly... thirdpass is definitely for the non-matching residues.
If error rate is 20%, then thirdpass means only 4000 tests per million. If the error rate is 5%, it means only 1000 tests per million, which is not a big deal anyway.
Surely it makes sense to have a complete range all with matching residues? If the error rate is really that low then it will hardly take any time just to be absolutly sure.
I agree we need to make sure we clean up the "and do a third pass now for all the k n pairs that do not have a matching residue." now. Especially just after finding a bypassed prime. I'll be glad to be one of those monkey. I was doing second pass all along believing we bypassed a prime. I also believe whether there is a prime on those k n pairs that do not have a matching residue or not , it needs to be done or we will never be sure.
I hope the admins will tell us the results of their finding and present us with a plan on how to tackle these issues.
e:)
I just want to make clear that I want matching residues for every test, and now, of course, I just don't think we will find a Prime by that. I am against predictions, not against testing. H.
I'm getting a little confused here. I had a post earlier but deleted it because I decided I was getting it wrong, now I'm not so convinced.
OK. Are we talking about doing a third pass because the first two passes didn't produce two matching residues, or because the error rate is so high its worth a third matching residue?
If its the first case, then I'm fairly sure (from memory in reading previous posts) that the tests keep on being giving out in second pass until two of the returned residues match.
The second case seems harder to justify, however, as the probability of having two wrong tests returned with exactly the same wrong residue logically seems to be so minuscule (since the error to produce the wrong residue are random events and a different random event would produce a different wrong residue), that its a waste of processing power to test against it.
What exactly are people suggesting here?
I spoke briefly with digital concepts he proposed an interesting idea, although related to mersenne the facts are basically the same.
I'll simply list them here then add my own:
What is the actual error rate?
The error rate is actually based around two types of computers; those which hardly ever produce an error and a smaller portion of those that produce a large amount of errors.
Good solid machines may only produce an error every couple months, where other machines may produce errors daily. The result is a statistically combined error rate of say
1% for a good computer
60-80% for a bad computer
Perhaps only 5% of the total computers are bad computers
However this becomes more complex when you consider shorter tests. Consider a computer which produces an error a day if the test takes 3 dayas to complete your almost 100% certain that that test is fouled. However the same computer may test 4 or 5 small tests in one dat. Therefore even a very poor computer which produces an error a day, might have a 100% error rate for large n tests but only a 20% error rate for small n tests.
Another note did the project actually keep track of the residues less than 1M? I didn't think they did for the firstpass.
So it makes a difference if we have both residues or not, if we don't have both residues do we assume they were only tested once? I don't think so but we might have to.
Regardless would someone like to come up with an error rate based upon the above stats just for the fun of it?
Also can we assume that test time is directly related to the number of blocks in a test. <-- I'm not sure if this is the case or not.
Does anyone know how many blocks are in tests of say
10M, 7M, 5M, 4M, 3M, 2M, 1M, 500k...
Stim,
Let me reitterate what Joe and others are saying, people please correct me if I'm wrong.
First lets assume that we actually have residues for each test performed... I'm not sure if this is actually the case for firstpass n<1M.
Everytime we complete a server assign test currently a residue is returned.
If we have two matching residues for any k/n pair it does not require further testing ever.
(EVER? well maybe once we reach n=50,000,000,000 but probably not before then). The chances of two matching residues both being incorrect is highly highly highly improbable.
But it is more than possible that we get two mismatching residues, and we don't know that they mismatch unless we have two tests, correct.
So there are two cases of mismatching residues,
One residue is correct the other is incorrect
Both residues are incorrect.
The first case is more likely where only one residue is faulty. So the question becomes when should we preform a thirdpass on mismatching residues?
The thirdpass on mismatching residues is only time efficient for the second case where both residues are incorrect. Since this is the only case where a prime would be missed.
Take the most recent example, someone tested k=4847 n=3M and reported an error on a secondpass we found a prime. We didn't sit back and say well maybe the second test was incorrect and its not prime so lets wait for a thirdpass to investigate this error. We quickly took that test and retested it again to verify the prime result.
(This is why we need a decent error rate so we can optimize our testing levels.)
For an overly simplified approach ignoring alot of issues:
If the error rate is 5%, we should have secondpass at the n-level where the time it takes to test a secondpass is equal to 5% of the time it take to test a first pass.
Considering third pass only where residues are mismatching and where only one residue is on file (even though it's been tested twice).
So what level should thirdpass be at assuming a 5% error rate 0.05^2 = 0.0025.
A thirdpass test should only require 0.25% of the time it takes for a firstpass test.
Time secondpass tests = 0.05 time firstpass
Time thirdpass tests = 0.0025 time firstpass
Jasong,
If you already have a script availabe I'd take it... :D
Might run thirdpass out to 50 or 100k.
Ok. A brief history of lower n tests.... ;)
Lower n tests were tested more than twice and we have at least two residues for them. The first tests for those k/n pairs were performed by previous owners of those k/n pairs. Then we started from where they announced they left off. Then we collected every available residue from their announced results (unfortunately not all of them were available) and integrated to our results. Then we started from scratch to have residues for all k/n pairs for the ones that we do not have residues (that's where secret user came into picture). Then we've started a second pass for those k/n pairs where we did not have two residues (that's where supersecret user came into picture).
After a certain period of time, secret and supersecret users became public. And again after a certain period of time, we started using userQQQsecondpass stuff.
Wow Nuri,
Thanks, I wasn't really around here for that history. So you are saying that when we finish all tests n<4M we will have two residues for everything... that's great it also make the model alot easier.
The other interesting point is we are now past the old secret... I believe those tests started at 3M. Sort of funny that, had that que continued with secret way back when we would have found the most recent prime alot sooner. Peoples guess back then of a missed prime above 3M was basically right on the money.
I since I don't really want to predict the next at this point. I will honestly comment on what I thought before the secondpass prime.
If I remember correctly I thought the missed prime was around ~2.6M with the possibility of another by 4.5M. Although I wasn't a total believer in the two missed primes idea second at 4.5M. At this point, I'm not so certain about another missed one which is why I'm reserving judgement. Until an error rate is known we really can't say. For another firstpass prime, before I was thinking we might not find another until before 11M, now again I'm uncertain.
Personally I'm glad that 4847 is gone for a simple foolish selfish reason. k=4847 was one of the last 4-digit k's so when looking at factors etc the " | " was always off set by these k's. Which made it more difficult when looking throught factors found for secondpass sieve. Secondpass sieve found quite a few missed factors for n<10M and p<100T and b/c of the offset it took extra time to single them out and report.
Looking at the k's remaining we have 5 dense k's and 3 light ones. Considering the most dense k, 55459 is still around is a little weird. But hey, it's all probablility anyways and if we havn't missed one for it already, it should be easier to find.
[EDIT]
[EDIT]
Distribution per k
10223 0.1716
19249 0.0625
21181 0.1468
22699 0.0601
24737 0.1551
33661 0.1462
55459 0.2055
67607 0.0522
Distribution per k
55459 0.2055
10223 0.1716
24737 0.1551
21181 0.1468
33661 0.1462
19249 0.0625
22699 0.0601
67607 0.0522