20211006, 09:23  #1 
"Vincent"
Apr 2010
Over the rainbow
2^{2}×11×61 Posts 
Let's finish primality verification through Mp#49*, M(74 207 281)
To this day, 20211006, we have proved that Mp#48 is indeed in the right place.
So, considering the speed of progresssion of the last 6 month (about 20k), it will take us about 7 to 8 years to get to MP#49 Countdown to verifying all tests below M(74β207β281): 268β808 I'm targetting first half of 2029. [edit]Related previous thread: https://www.mersenneforum.org/showthread.php?t=26591 Last fiddled with by Uncwilly on 20211006 at 13:31 
20211006, 09:28  #2 
"University student"
May 2021
Beijing, China
81_{16} Posts 
Congratulations!!!
It's time to add another term for http://oeis.org/A000043! 
20211006, 10:57  #3 
Xebeche
Apr 2019
πΊππΊ
2·3·73 Posts 
Perfectly!
I just love this forum :) Soon I will give my forecast for the timings. This will be M60000000, M65000000, M70000000 and of course M74207281 with a confidence interval of 85%. 
20211006, 11:50  #4 
Xebeche
Apr 2019
πΊππΊ
438_{10} Posts 
My Magic Crystal Ball tells me that all exponents below 74 207 281 will be tested and verified by
March 08, 2025 Β± 64 days (85%). Accordingly: M60000000  May 12, 2022 M65000000  May 28, 2023 M70000000  May 23, 2024 Place your bets gentlemen. Last fiddled with by greenskull on 20211006 at 11:52 
20211006, 12:41  #5  
Feb 2017
Nowhere
1010000010110_{2} Posts 
Quote:
As mentioned earlier in this post in the "countdown to M_{57885161}" thread, I had over two years previously used simple extrapolation for an ETA to M_{57885161} without even adjusting the rate of progress for larger exponents. It proved to be accurate beyond my wildest expectations. It is of course possible that things will happen in the future to change the rate of progress  e.g. faster computing hardware or methods, or hordes of new users joining the project  but such things are imponderable at present. If things do happen that significantly change the rate of progress, the estimate can and IMO should be revised accordingly. 

20211006, 13:04  #6 
Xebeche
Apr 2019
πΊππΊ
438_{10} Posts 
Maybe you will try to hit the bull'seye again? :)

20211006, 13:42  #7 
Feb 2017
Nowhere
1010000010110_{2} Posts 
firejuggler beat me to it. The method I would use is essentially the same as he used. As I said, it might be possible to tweak it a bit, but IMO it isn't worth the effort.
It would be silly at this point to try to make a precise prediction for an ETA. As I have already indicated, a lot could happen to change the rate of progress in the coming days and years. We don't know whether it will, or if it does, what it might be or how much it might affect the rate of progress. I don't take these estimates seriously enough to wager on them. I do take soundness of method seriously. In this case, it seems to me that simple extrapolation of the current rate of progress is a good place to start. It is based on what I call the "assumption of ignorance." Apart from larger exponents requiring more computation to test, we are at present ignorant of any factors that will change the rate of progress appreciably. If we in future learn some reason why present trends will not continue, we revise the estimate accordingly. One presently known factor that might affect the rate of progress slightly is the replacement of first time LL testing with PRP testing with cheap verification. There are AFAIK still unconfirmed LL tests in the pipeline. As those are cleared, things could speed up a bit. Other imponderables besides the ones I already mentioned are possible changes in how the project works: Assignment rules could be changed. Methods might be found to prevent people from deliberately impeding progress. And so on. 
20211006, 13:50  #8 
Sep 2002
Database er0rr
3,943 Posts 

20211006, 14:03  #9 
Xebeche
Apr 2019
πΊππΊ
666_{8} Posts 
The sign of mastery is the ability to repeat it. Otherwise, it's just a coincidence.
This is just an interesting game, there is nothing wrong with a mistake. We learn from mistakes. For example, my short distance M#48 forecast was purely technical and did not take into account fundamental factors. This is because I have just started to learn the essence of the work of the GIMPS project. The understanding the fundamental factors and step triggers can give a tangible advantage at close distances, but comes down to statistical noise at long distances. The long distance is advantageous to me or anyone who is capable of using a more complex extrapolation model than the parabolic one ;) Come on! Last fiddled with by greenskull on 20211006 at 14:05 
20211006, 14:32  #10 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest
2×5×593 Posts 
If you believe that there is still a significant gap in your understanding.
Last fiddled with by kriesel on 20211006 at 14:33 
20211006, 15:44  #11  
Feb 2017
Nowhere
2·3·857 Posts 
Quote:
The question here is when a specific computational task will be completed. It seems to me that the "fundamental factor" in answering that question is the rate of progress. IMO it's analogous to estimating how long it will take to get to a faraway place (here on Earth of course!). How your conveyance works may be "fundamental," but knowing that doesn't help much in giving an ETA. Knowing the total distance to your destination, and the average speed you can maintain, do allow such an estimate, irrespective of any details of how you are moving  be it swimming, walking, running, bicycling, driving, or by aircraft. I accurately estimated when the exponents up to 57885161 would be cleared, two and a half years in advance, without knowing anything about how the work was being assigned, how the computations are done, or any other "fundamental factors." All I knew was how fast exponents were currently being cleared. I did a simple linear extrapolation. At the moment, I don't know a better basis for a predicition. If you think you do, it is incumbent upon you to explain why you think it is better. 

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
[Mission Accomplished] Let's finish primality verification through Mp#48*, M(57β885β161)  kriesel  Marin's Mersennearies  136  20211102 04:40 
Verification of Feitsma's psp(2) data  Happy5214  Computer Science & Computational Number Theory  5  20210331 12:36 
TF NF verification proposal from R. Gerbicz  kriesel  News  0  20190224 15:47 
Unsafe verification?  CuriousKit  PrimeNet  13  20150621 14:49 
Doing more about LL test verification  jasong  Software  13  20100310 18:53 