[QUOTE=MisterBitcoin;456030]It might be usefull to add on more admin to CRUS to focus on bases ck>1e6. That would reduce the amount of admin time for you.
I did some testings on S280. Sofar I can see on S280 and S540 the prime density is rising on higher kvalues. We can even see the same on S3. I might usefull to start any base with ck<1e6 before starting any other base. (exept 280)[/QUOTE] That is incorrect. The prime density is lower for higher kvalues. It's a mathematical certainty and could easily be demonstrated. Likely your sample size is too small. Because the smallest primes for higher k values are much higher than for smaller k values meaning fewer n=1, n=2, n=3, etc. primes for them. Just take a look at most bases and see the k's remaining for k<=1000 and k>1000. Why are so many of the project's current participants so enamored by such huge conjectured bases? It was not that way up until a couple of years ago. Perhaps it was the advent of the srbase program. These large conjectured bases will never be proven. The point of the project was originally to prove as many of the conjectures as possible. It even states as much. I would be fine if we just stuck with bases where ck < 1M. If we complete those then moving on to CK=1M2M is fine, etc. I'm spending 75% of my total project update time messing with these thousands and millions of teeny primes, removing duplicate primes for the same k, and removing k's remaining. I just now finished your latest posting for S15. It took me 2030 minutes just for that one base and there are many other things to keep updated. I had to sort the primes, remove the primes that were duplicate for each k (since that was not done like I would prefer), split out the k's remaining for only k=10M50M, remove the primes from the remaining k's file, and format them in a manner that can be shown on the web pages. Then I have to upload the pages to the server. It is no small task. There is virtually no one that would take on the task of doing udpates for monster conjectered bases. It is a huge task. See the above paragraph. KEP had originally taken on ONLY R3 himself as his own side project. He gave it up after less than 3 months because he saw how much effort it was just for one large conjectured base. Don't get me wrong, I enjoy doing the updates but not the huge updates. My favorite thing to do is to change one of the bases from green to gray. :) But I also like removing k's from bases with a few hundred or especially fewer than 10 k's remaining because we can potentially prove those. 
[QUOTE=MyDogBuster;456138]I find it very disappointing that after 9 years and about 200 million tests by me, that the above stat is true. Doesn't instill get up and go. I'd rather not know.[/QUOTE]
Like I said before and KEP aknowledged the figure is extremely over inflated. It does not remove k's with trivial or algebraic factors on bases that have not been started. 
[QUOTE=KEP;456033]No this tracking method, does not remove the k's with trivial and algebraric factors, from the amount of untested k's. However it does remove the k's that you do not show on your website, from the number of remaining k's, from the fully started ranges (ranges=fully started conjecture or partially started and now shown on the CRUS website conjecture).
[/QUOTE] So my point stands. The figure of k's remaining is likely overinflated by double or even triple or more because 99.9+% of the k's remaining are on bases that have not been started. Even if you removed all odd k's on unstarted odd bases, you'd likely remove 10's of trillions of k's. So the figure means little. [QUOTE=KEP;456033] Since srbsieve is not really using much effort to track down the trivially factored and GFN k's, I really don't see the harm in waiting for the day that all ranges are started, to have a statistics that does only show the k's remaining that actually requires quite an effort to remove from the overall total of k's remaining :smile: [/QUOTE] I wish people could understand about the magnitue of storage and computing capacity required for searching 100's of trillions of k's even to only n=10K. They clearly do not. You say srbase is not using much effort for trivially factored and GFN k's. Sure enough but try doing it on every base with 100's of trillions of k's in order to get a reasonably accurate figure for your first post here. I doubt you'll find it to be a trivial effort. 
[QUOTE=gd_barnes;456139]That is incorrect. The prime density is lower for higher kvalues. It's a mathematical certainty and could easily be demonstrated. Likely your sample size is too small. Because the smallest primes for higher k values are much higher than for smaller k values meaning fewer n=1, n=2, n=3, etc. primes for them. Just take a look at most bases and see the k's remaining for k<=1000 and k>1000.
Why are so many of the project's current participants so enamored by such huge conjectured bases? It was not that way up until a couple of years ago. Perhaps it was the advent of the srbase program. These large conjectured bases will never be proven. The point of the project was originally to prove as many of the conjectures as possible. It even states as much. I would be fine if we just stuck with bases where ck < 1M. If we complete those then moving on to CK=1M2M is fine, etc. I'm spending 75% of my total project update time messing with these thousands and millions of teeny primes, removing duplicate primes for the same k, and removing k's remaining. I just now finished your latest posting for S15. It took me 2030 minutes just for that one base and there are many other things to keep updated. I had to sort the primes, remove the primes that were duplicate for each k (since that was not done like I would prefer), split out the k's remaining for only k=10M50M, remove the primes from the remaining k's file, and format them in a manner that can be shown on the web pages. Then I have to upload the pages to the server. It is no small task. There is virtually no one that would take on the task of doing udpates for monster conjectered bases. It is a huge task. See the above paragraph. KEP had originally taken on ONLY R3 himself as his own side project. He gave it up after less than 3 months because he saw how much effort it was just for one large conjectured base. Don't get me wrong, I enjoy doing the updates but not the huge updates. My favorite thing to do is to change one of the bases from green to gray. :) But I also like removing k's from bases with a few hundred or especially fewer than 10 k's remaining because we can potentially prove those.[/QUOTE] I´m sorry about S15 because I used the script for starting the range. I´ll finish my S540 reservation and will make some bases n<100K. 
Gary, you should consider transferring the work for S7/S15/S280 etc to someone else. As you stated management of those bases waste a lot of your time.

[QUOTE=gd_barnes;456141]So my point stands. The figure of k's remaining is likely overinflated by double or even triple or more because 99.9+% of the k's remaining are on bases that have not been started. Even if you removed all odd k's on unstarted odd bases, you'd likely remove 10's of trillions of k's. So the figure means little.
I wish people could understand about the magnitue of storage and computing capacity required for searching 100's of trillions of k's even to only n=10K. They clearly do not. You say srbase is not using much effort for trivially factored and GFN k's. Sure enough but try doing it on every base with 100's of trillions of k's in order to get a reasonably accurate figure for your first post here. I doubt you'll find it to be a trivial effort.[/QUOTE] Something isn't quite right. On ALL odd bases ALL odd k's has been removed. However I cannot without testing all k's for trivial, GFN and MOB, remove any further k's. It would be manageable, to remove the k's but it would mean about 700000+ spreadsheet tables would have to be created and that would require about 2100000+ minutes of work. So it could be managed, but it would make the stats much harder to do :smile: 
[QUOTE=rogue;456167]Gary, you should consider transferring the work for S7/S15/S280 etc to someone else. As you stated management of those bases waste a lot of your time.[/QUOTE]
That´s an good idea. I´m willing to take care about S3/S7/S15, if you let me know what must be done. Managing 1042 (x2) Bases is way to much for 1 person (even for two). 
The correct method would be to give a database the job. It would need some initial programming but would be more efficient long term. It would also allow for through checking of bases by storing all primes n>=1(This would require a lot of disk space for bases like R3 but disk space is cheep.)

This was posted on April 1st... :smile:

[QUOTE=KEP;455954]As of April 1st 2017 the total overall progress is as follows:
563,674,901,215,566 Total Riesel k's to test (all bases) 142,501,532,757,170 Total Sierpinski k's to test (all bases) [B]706,176,433,972,736[/B] Total k's to test (both sides, all bases) 563,642,894,149,240 Untested Riesel k's (all not fully tested bases) 142,494,941,423,544 Untested Sierpinski k's (all not fully tested bases) [B]706,137,835,572,784[/B] Total untested k's (both sides, all not fully tested bases) 648,589 Remaining Riesel k's (all fully and partially tested bases) 186,421 Remaining Sierpinski k's (all fully and partially tested bases) [B]835,010[/B] Remaining k's (both sides, all fully and partially tested bases) [B]706,137,836,407,794[/B] Total k's remaining (both sides, untested+remaining k's) [B]38,597,564,942[/B] Total k's tested or primed 0.0054657112706% of k's tested or primed 99.9945342887294% of k's remaining untested or unprimed[/QUOTE] KEP: How do you count with k's? Do you include trivial k's (i.e. gcd(k+1,b1) is not 1)? I am doubted since some bases (like SR71 and SR280) have very large CK. Besides, do you include the k's with full/partial algebraic factors? And do you include the k's which are rational powers of b? 
The count of the remain k's is not the same as the count of the remain k's in [URL]http://www.noprimeleftbehind.net/crus/tab/CRUS_tab.htm[/URL].

All times are UTC. The time now is 19:15. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2022, Jelsoft Enterprises Ltd.