[QUOTE=EdH;607788]The following isn't (yet) in the format you described, but it seems to show that at least at 10 digits, many of the primes exist in multiple bases, and at various terms. Here is a very small sampling of a current test run:[code]Prime 3258313481:
2^305:11 24^17:1520 Prime 1129552253: 2^341:25 19^18:510 Prime 2159188693: 2^327:18 50^98:7 Prime 1639132051: 2^422:11 22^41:508 Prime 1051654267: 2^468:58 19^22:2102 Prime 1097038783: 2^501:61 67^83:11[/code][/QUOTE] Excellent ! This is very interesting ! I understand that this is only a very small sample ! I will write the same program in early summer and compare our results. I can't wait to see the full file and examine this data. I'm already asking myself a few questions just by seeing this little sample : 1) For each prime number, do we always have one of the two bases that is necessarily base 2 ? (I think this is just due to the way the program is written and the fact that the sample is small ?) 2) Do you also test primes larger than 10 digits ? 3) Do you test all the bases listed on the project page ? Have we then overestimated the computation time that this test would take ? 4) Is this program written in C, python or another language ? 
[QUOTE=garambois;607840]Excellent !
This is very interesting ! I understand that this is only a very small sample ! I will write the same program in early summer and compare our results. I can't wait to see the full file and examine this data. I'm already asking myself a few questions just by seeing this little sample : 1) For each prime number, do we always have one of the two bases that is necessarily base 2 ? (I think this is just due to the way the program is written and the fact that the sample is small ?) 2) Do you also test primes larger than 10 digits ? 3) Do you test all the bases listed on the project page ? Have we then overestimated the computation time that this test would take ? 4) Is this program written in C, python or another language ?[/QUOTE]What I listed was a few lines from an output of one of my tests. Oddly, a complete base 2 run only yielded one more prime that spanned multiple bases, so I'm not sure how I made a grab of the perfect part of an overall list to show what looked like better results. Part of the trouble was that my overall listing also included numbers where the prime digits were within a larger prime. I have since been able to omit such cases. But, I still don't see how my sample was so close to the whole set.:confused: 1) The list was limited to the primes found within the base 2 sequences. This will be expanded later, but I will need to find a way to avoid total duplication of finds. 2) This test is running everything greater than 9 digits. 3) Currently, I'm using all bases through 200, except for the recently added. I haven't run a full update in a while, due to the db limitations. 4) It's a mixture, but mostly bash scripts, with one C++ program that harvests the primes. ATM, I am becoming totally confused! I'm going to take a break until I sort out what I'm doing. 
OK, thanks Edwin for those answers.
In any case, all the sample data seems to match except for one. I can't find the prime number 2159188693 at index 18 of sequence 2^327. Let us know if you do more tests in the next time and if you find other "big" prime numbers that are present in several bases. I will look into this. We never know, we have to check, even if I think that all this is only a coincidence and that we will not have much larger primes being in two different bases. It would surprise me a lot if there were such prime numbers of 12 digits or more ! As far as I'm concerned, I have one fear : I write my programs in python and I'm afraid it's infinitely slower than what you write in C. We'll see in July, because I unfortunately don't have enough time at the moment ! 
[QUOTE=garambois;607850]. . .
I can't find the prime number 2159188693 at index 18 of sequence 2^327. . . . As far as I'm concerned, I have one fear : I write my programs in python and I'm afraid it's infinitely slower than what you write in C. We'll see in July, because I unfortunately don't have enough time at the moment ![/QUOTE]The problem with cleaning things up manually for posting  that should be 2^372:18. I have made that part of the scripts now, and below is another set, with your requested formatting. I didn't verify anything, but something seems very wrong with this listing! I'm going to let it sit for now and try for a clearer "big picture," maybe tomorrow. As for the programming, the C++ program is a very small part and most of the time is spent in the scripts. I hope to do a lot of work refining how the data are collected. I'll also need to do another full update of all my local sequences. I did add all the new bases below 200, so when I resume work, they will be represented. Latest run:[code]1051654267,19,22,2102 1051654267,2,468,58 1097038783,2,501,61 1097038783,67,83,11 1129552253,19,18,510 1129552253,2,341,25 1639132051,22,41,508 1639132051,2,422,11 2159188693,2,372,18 2159188693,50,98,7 3206363219,2,448,19 3206363219,2,516,53 3206363219,59,36,1559 3258313481,2,305,11 3258313481,24,17,1520[/code] 
[QUOTE=EdH;607862]The problem with cleaning things up manually for posting  that should be 2^372:18. I have made that part of the scripts now, and below is another set, with your requested formatting. I didn't verify anything, but something seems very wrong with this listing! I'm going to let it sit for now and try for a clearer "big picture," maybe tomorrow.
As for the programming, the C++ program is a very small part and most of the time is spent in the scripts. I hope to do a lot of work refining how the data are collected. I'll also need to do another full update of all my local sequences. I did add all the new bases below 200, so when I resume work, they will be represented. Latest run:[code]1051654267,19,22,2102 1051654267,2,468,58 1097038783,2,501,61 1097038783,67,83,11 1129552253,19,18,510 1129552253,2,341,25 1639132051,22,41,508 1639132051,2,422,11 2159188693,2,372,18 2159188693,50,98,7 3206363219,2,448,19 3206363219,2,516,53 3206363219,59,36,1559 3258313481,2,305,11 3258313481,24,17,1520[/code][/QUOTE] Thank you very much Edwin for all this work. The format is perfect like this. I can still spot an error : the prime number 3206363219 doesn't seem to appear anywhere in the sequence 2^448. I immediately checked this prime, because it appears in three lines of the list and 516 is not a multiple of 448 and anyway, the indexes are > 1. So it was very intriguing and very unlikely that this prime would appear in 3 lines. Edwin, you are already doing a lot for this whole project ! Only take on this extra work if you find interest in it ! And in any case, take your time, I won't get serious about this until after July 7  10 anyway. But I must admit that you have discovered a very interesting path to explore in my humble opinion. It's risky to go into this alone, there are many sources of error. It is very stimulating to work on such an idea with several people and especially, so, we have means to verify. Thanks Edwin ! 
[QUOTE=garambois;607890]. . .
I can still spot an error : the prime number 3206363219 doesn't seem to appear anywhere in the sequence 2^448. I immediately checked this prime, because it appears in three lines of the list and 516 is not a multiple of 448 and anyway, the indexes are > 1. So it was very intriguing and very unlikely that this prime would appear in 3 lines. . . . [/QUOTE]I must have grabbed this from an earlier run. This was part of my original problem:[code]base2/2^448.elf:19 . 15006007375820463402452561600162328700[COLOR=red]3206363219[/COLOR]75920107434993415977015910414828098588984394591 = 17 * 2389 * 2016739 * 141986827 * 190519331 * 6772722565336945433810924560372709070485550949679612135489377339249[/code]I think I have that fixed. I plan to run base 2 again in a little while. I'll see if 2^448 is absent in those results 
OK, I understand the problem much better with this example, thanks.

My first cut would be:
Put all primes into a flat file, called primes.txt below. [c]sort <primes.txt  uniq repeated >primes.duplicates[/c] That should get a list of all primes that appear more than once in the list. Then see how many there are and decide how to process them. 
Thanks Chris! I will add this into my study.

Yes, many thanks Chris.
I think you are right and the program will be more effective this way. Perhaps even incomparably more effective ! 
@Chris: uniq is definitely helping!
Another wrinkle has made itself known, that I will have to look into: If you check prime 989948318349327032515056706609970813346117930160196095662320313189860502565627388119428970284861410132787555691, you will find six occurrences across as many sequences:[code]3^10:3460 5^26:3674 24^57:5346 47^97:3551 70^3:3478 85^2:3467[/code]But, it's because they all merge with 1134. Additionally, all other primes in those terms from then on will be multiple hits as well:[code]2^4 7 31 107 1747 32869 151597 28936680745039[/code] 
Wow, wow, wow !
It's going to be a lot more complicated than I thought if we have to remove the multiple cases due to mergers. I hadn't thought of that. For the moment, as far as I am concerned, I do not see how to deal with this problem ! 
Well, I am exploring some ideas, but I'll have to see if any work out. One thing going toward identification of these is that, although the term will be different for each sequence, values (comp = factor1 * factor2 * factor3) will all be identical.

[QUOTE=garambois;607631]I also noticed yesterday that the prime 181 was missing from the list of all bases < 200 that are primes. I don't know why we had forgotten 181 ?
I will initialize it.[/QUOTE] Oops, I seem to have missed this. I did some work on base 181. I will stop now. 
[QUOTE=RichD;608023]Oops, I seem to have missed this. I did some work on base 181. I will stop now.[/QUOTE]
OK, now I understand better why the work for some exponents was already done ! Thanks. 
I have not solved the entire problem with merged duplication entirely, but I have come up with some results. I ran some work on all the primes from all the sequences from base 2 through base 200, that have the first digit of 1, against the entire set. In my attempt to cull those that appeared in merged sequences, I did find a couple triplets where a prime exists within merged sequences and outside of them. I suspect many more, but my scripts still need work in this area:[code]These two are merged:
1370602529,276,1,69 1370602529,84,7,158 This one is outside the merged sequences: 1370602529,38,21,5071 These two are merged: 1849563931,15472,9,1741 1849563931,70,15,1582 This one is outside the merged sequences: 1849563931,43,57,1[/code]Here is the entire list (omitting the above triplets):[code]1000066283,157,6,1611 1000066283,80,33,1128 1001655821,20,67,692 1001655821,73,28,1192 1005523957,46,38,48 1005523957,99,44,1332 1006120013,167,6,165 1006120013,7,16,719 1008355279,103,8,1220 1008355279,86,41,38 1010085299,37,6,2502 1010085299,46,65,653 1012433291,101,4,1556 1012433291,30,37,2112 1013226583,6,23,544 1013226583,61,18,3451 1014907567,13,50,1573 1014907567,21,20,329 1027180397,34,71,160 1027180397,51,81,24 1035744623,109,38,628 1035744623,6,47,1523 1038824309,5,48,1350 1038824309,62,57,517 1040789047,10,47,500 1040789047,61,70,232 1051654267,19,22,2102 1051654267,2,468,58 1057464631,119,44,195 1057464631,87,38,1726 1061367701,10,77,3358 1061367701,11,68,2558 10655948837,19,56,310 10655948837,33,36,599 1068398117,113,30,200 1068398117,19,88,141 1068829721,11,68,3819 1068829721,34,49,281 10689931771,30,23,782 10689931771,46,13,392 1070974591,107,40,1628 1070974591,5,136,3285 1071660347,15,34,1721 1071660347,41,28,169 1073335301,50,18,8 1073335301,93,20,20 10749423863,11,116,3078 10749423863,30,5,1531 1078474589,10,37,1132 1078474589,19,76,1235 1088336201,26,73,395 1088336201,54,33,155 1097038783,2,501,61 1097038783,67,83,11 109964639887,193,22,263 109964639887,40,19,182 1104735523,3,106,342 1104735523,7,158,510 1108463827,43,20,227 1108463827,6,53,577 1108476167,11,88,15 1108476167,23,44,3475 1114626413,19,52,2714 1114626413,30,25,267 1117906721,109,36,220 1117906721,11,50,711 1118156813,46,27,334 1118156813,70,19,161 1121641319,10,37,2588 1121641319,57,48,200 1127225591,41,74,127 1127225591,51,58,1063 1128708899,119,20,94 1128708899,26,79,122 1129552253,19,18,510 1129552253,2,341,25 1130529443,26,51,719 1130529443,57,28,2387 1134318569,151,4,144 1134318569,95,26,161 1134335339,17,92,2030 1134335339,73,34,367 1134461173,18,79,74 1134461173,6,35,1513 1134797117,42,9,252 1134797117,7,98,969 1138574441,44,69,1203 1138574441,99,32,2256 1142266651,11,116,2980 1142266651,85,12,4627 1144636907,14,45,396 1144636907,3,146,561 1145898077,10,133,462 1145898077,70,29,1651 1146191047,31,28,66 1146191047,5,72,721 1150135219,11,29,4 1150135219,35,28,209 1153942483,3,211,7 1153942483,44,53,2201 1157788561,22,87,76 1157788561,46,33,1095 1158926663,26,31,550 1158926663,79,12,2168 1167137717,69,20,703 1167137717,79,8,528 1170750769,55,26,1389 1170750769,83,8,282 1180516231,29,15,1366 1180516231,7,104,955 1187125579,55,32,364 1187125579,65,52,79 1193918981,35,10,1480 1193918981,59,4,831 1194671551,191,34,223 1194671551,5,170,627 1195389149,17,22,608 1195389149,61,20,86 1195502977,19,32,1315 1195502977,6,133,785 1198306349,76,25,2555 1198306349,79,24,398 1205900173,12,69,1027 1205900173,38,29,755 1207589143,24,15,466 1207589143,3,58,3357 1221597011,37,22,1144 1221597011,5,82,750 1221597011,6,73,2552 12227903759,20,69,893 12227903759,54,23,1030 1229334677,35,50,540 1229334677,38,27,33 1234453553,3,214,2283 1234453553,94,37,271 1234704811,113,20,179 1234704811,28,43,135 1239548699,5,136,117 1239548699,52,27,797 1257729269,19,46,123 1257729269,77,8,421 1259803487,44,47,175 1259803487,6,73,1724 1264657091,14,71,1359 1264657091,94,45,628 1267449919,26,97,832 1267449919,43,8,2363 1267528987,3,34,252 1267528987,66,9,1037 1270550651,45,24,625 1270550651,76,19,783 12742648307,21,54,2903 12742648307,28,17,151 1274602453,69,56,810 1274602453,97,26,401 12755626837,10,17,754 12755626837,17,6,3969 1277097533,11,18,593 1277097533,74,57,1418 1278222611,39,22,290 1278222611,61,46,368 1279946509,14,89,1255 1279946509,41,24,750 1288234043,26,39,3163 1288234043,70,53,29 1291308467,19,76,2878 1291308467,7,48,1115 1293967729,19,42,92 1293967729,82,41,626 1294170701,30,25,1418 1294170701,37,22,3218 1298562247,29,16,3065 1298562247,60,18,3 1307652473,15,98,15 1307652473,44,35,2513 1309129933,3,68,1069 1309129933,48,31,714 1309588837,101,20,115 1309588837,14,77,208 1317570083,12,71,172 1317570083,29,40,273 1326169571,15,4,853 1326169571,39,32,1557 13273901521,42,65,81 13273901521,75,10,4528 1329031787,17,46,1751 1329031787,58,69,733 1331215709,44,27,657 1331215709,58,9,931 1331502647,24,61,92 1331502647,79,26,398 1334284499,68,45,388 1334284499,82,3,1467 1334602861,197,49,32 1334602861,75,16,852 1339215721,15,36,307 1339215721,69,24,316 13441505989,15,20,908 13441505989,17,20,1044 1349251559,17,92,1245 1349251559,61,68,170 1350352741,11,20,1203 1350352741,22,15,1475 1364492747,29,10,1071 1364492747,66,19,1327 1371644347,38,55,1181 1371644347,77,6,88 1373075419,42,23,661 1373075419,62,27,49 1375618577,5,136,1315 1375618577,51,32,633 1385682629,17,70,199 1385682629,51,74,1313 1388392903,20,25,1069 1388392903,58,11,169 1388696473,22,31,1809 1388696473,99,20,1224 1399913257,45,39,42 1399913257,6,11,298 1400714869,107,22,1039 1400714869,22,13,3897 1417019537,11,36,1691 1417019537,46,31,279 142754777149,101,32,504 142754777149,52,39,640 1428485593,13,16,376 1428485593,74,57,1188 1442122849,10,35,2506 1442122849,19,20,1399 1443633649,105,48,58 1443633649,109,10,386 1447677043,151,24,34 1447677043,28,31,1017 1453059701,35,10,2424 1453059701,57,38,792 1455497123,26,37,2577 1455497123,34,51,1425 1455649541,44,11,307 1455649541,86,15,304 1456319983,10,131,1394 1456319983,5,70,669 1458245561,60,63,96 1458245561,73,61,41 1458985963,3,190,1280 1458985963,59,24,523 1473659471,101,48,77 1473659471,15,34,1246 1476281803,127,42,939 1476281803,58,7,605 1494655627,10,123,334 1494655627,12,51,1186 1514980781,46,63,17 1514980781,99,12,887 1520335771,12,113,137 1520335771,19,105,80 1520459723,22,41,1246 1520459723,29,91,105 1539077593,41,52,232 1539077593,5,164,143 154198251007,17,76,702 154198251007,22,87,1336 1542335789,149,20,506 1542335789,79,10,228 1545539087,56,5,810 1545539087,94,13,2113 1573252489,31,86,120 1573252489,78,43,915 1575372067,10,121,1314 1575372067,35,32,1858 1576788293,54,61,1078 1576788293,55,30,800 1581829609,86,19,305 1581829609,97,40,2150 1592634581,35,10,58 1592634581,58,37,1275 1600807519,30,27,260 1600807519,6,89,821 1622062093,14,89,637 1622062093,46,58,43 1625043389,34,65,1601 1625043389,58,69,845 1639132051,2,422,11 1639132051,22,41,508 16409695231,38,21,2631 16409695231,6,7,253 1646665309,41,26,306 1646665309,99,12,334 1648370369,33,72,491 1648370369,70,62,7 1652665811,119,44,14 1652665811,26,73,1337 1661797037,22,41,396 1661797037,31,50,1756 1662398893,50,64,40 1662398893,68,31,1626 1668820973,12,97,23 1668820973,57,70,327 1671507989,70,29,341 1671507989,79,28,343 1672617637,15,114,298 1672617637,62,23,273 1691208683,55,12,1800 1691208683,93,6,1086 1691734123,109,8,205 1691734123,61,14,219 16955341633,12,23,488 16955341633,74,39,2353 1714204097,34,45,1669 1714204097,44,75,2169 1725886607,10,39,357 1725886607,15,98,1191 1728697067,14,17,563 1728697067,54,7,1236 1738718167,109,46,167 1738718167,23,18,1210 1743048779,10,77,1440 1743048779,3,110,956 1748701403,54,47,974 1748701403,76,11,2431 1751490079,3,152,892 1751490079,6,161,1959 1757771591,3,110,2457 1757771591,62,19,74 1758281221,62,11,1019 1758281221,7,18,472 1767263009,11,70,2398 1767263009,14,53,1440 1770121069,44,35,675 1770121069,57,8,2118 1782789427,33,24,636 1782789427,45,10,679 1786026601,101,22,403 1786026601,40,33,439 1789860791,29,36,654 1789860791,69,22,597 1800704767,127,8,121 1800704767,78,37,2122 1807530251,54,3,233 1807530251,96,11,583 1818419051,22,15,394 1818419051,3,70,1243 1821849553,67,38,1203 1821849553,83,6,1017 1823692711,20,27,1481 1823692711,86,5,1051 1848424423,14,29,365 1848424423,28,51,67 1888970921,17,34,428 1888970921,3,14,1694 1889889973,103,26,1378 1889889973,20,41,1 1897073869,12,37,336 1897073869,90,31,1881 1900569103,21,38,414 1900569103,5,74,2044 1909012393,2,195,46 1909012393,6,99,110 1909553381,167,20,429 1909553381,62,65,407 1912420217,101,36,1187 1912420217,7,132,2790 1930550801,30,3,1761 1930550801,53,58,215 1945784677,33,58,42 1945784677,75,26,582 1978558717,127,24,1546 1978558717,58,41,3703 19805197549,21,34,715 19805197549,28,71,128 1991389019,11,14,614 1991389019,6,33,373 1993048741,137,14,810 1993048741,35,56,526 19971331781,47,68,1399 19971331781,93,12,207[/code]Of note, although I ran the primes against the entire set of bases, only 276 and 15472 appear in the results. And, they're only in the triplets above. I didn't notice any greater than 193 in the last listing. I also didn't notice any triplets that didn't involve merged sequences. There are some primes of greater than 10 digits in the listing. 
[QUOTE=EdH;608032]I have not solved the entire problem with merged duplication entirely, but I have come up with some results. I ran some work on all the primes from all the sequences from base 2 through base 200, that have the first digit of 1, against the entire set. In my attempt to cull those that appeared in merged sequences, I did find a couple triplets where a prime exists within merged sequences and outside of them. I suspect many more, but my scripts still need work in this area:
... ... Here is the entire list (omitting the above triplets):[code]1000066283,157,6,1611 ... [COLOR=red]1221597011[/COLOR],37,22,1144 [COLOR=red]1221597011[/COLOR],5,82,750 [COLOR=red]1221597011[/COLOR],6,73,2552 ... [/code]Of note, although I ran the primes against the entire set of bases, only 276 and 15472 appear in the results. And, they're only in the triplets above. I didn't notice any greater than 193 in the last listing. I also didn't notice any triplets that didn't involve merged sequences. There are some primes of greater than 10 digits in the listing.[/QUOTE] I did some quick checking. I'll take a more detailed look over the next weekend. It looks like there are also some 11digit pairs as you already report. This leads me to think that 12digit pairs must be very rare, with the reduced number of sequences we have to do this research. As for triplets, apart from the cases of mergers that you mention above, they must be very rare too. Otherwise, I also note a triplet that does not involve a merged sequence for the prime [COLOR=red]1221597011[/COLOR] (see above), but for the 37^22 sequence, at index 1144, the term is : 14995180448395695667673983126 = 2  3533  2[COLOR=Red]1221597011[/COLOR]59877677281911 And so, [COLOR=red]1221597011[/COLOR] is not a factor, but the part of writing a factor. Thanks a lot Edwin ! 
[QUOTE=garambois;608040]. . .Otherwise, I also note a triplet that does not involve a merged sequence for the prime [COLOR=red]1221597011[/COLOR] (see above), but for the 37^22 sequence, at index 1144, the term is :
14995180448395695667673983126 = 2  3533  2[COLOR=Red]1221597011[/COLOR]59877677281911 And so, [COLOR=red]1221597011[/COLOR] is not a factor, but the part of writing a factor. Thanks a lot Edwin ![/QUOTE]I weeded out a bunch of those triplets, but I guess I missed one. . . That's the trouble with manually doing this. I still need to do better with programming/scripts. Thanks for keeping me in line. 
I'll start initializing prime bases 223, 227 & 229.

[QUOTE=garambois;607631]For example, I also noticed yesterday that the prime 181 was missing from the list of all bases < 200 that are primes. I don't know why we had forgotten 181 ?
I will initialize it.[/QUOTE] I had also missed this. I am currently in the process of initializing just the sameparity exponents on bases 179 and 181 to add some interesting bases for the easier sequences effort. I started yesterday and it did not appear that those had been worked on because the elves were having to work to terminate the smaller sameparity exponents when I pulled them up. I am currently up to exponent 55 on both bases. I have a batch job set up to initialize all of them up to a starting sequence of 160 digits...exponent 71. For now, the job stops any base that has a hard cofactor (fully ECM'd) of >= 102 digits. I will then run back through and run any remaining exponents until they hit a cofactor of >= 110 digits. Hopefully this is OK. 
1 Attachment(s)
[QUOTE=gd_barnes;608049]I am currently in the process of initializing just the sameparity exponents on bases 179 and 181 to add some interesting bases for the easier sequences effort. I started yesterday and it did not appear that those had been worked on because the elves were having to work to terminate the smaller sameparity exponents when I pulled them up.
I am currently up to exponent 55 on both bases. I have a batch job set up to initialize all of them up to a starting sequence of 160 digits...exponent 71. For now, the job stops any base that has a hard cofactor (fully ECM'd) of >= 102 digits. I will then run back through and run any remaining exponents until they hit a cofactor of >= 110 digits. Hopefully this is OK.[/QUOTE] Both bases are currently assigned according to the reservation table. 
[QUOTE=gd_barnes;608049]I had also missed this.
I am currently in the process of initializing just the sameparity exponents on bases 179 and 181 to add some interesting bases for the easier sequences effort. I started yesterday and it did not appear that those had been worked on because the elves were having to work to terminate the smaller sameparity exponents when I pulled them up. I am currently up to exponent 55 on both bases. I have a batch job set up to initialize all of them up to a starting sequence of 160 digits...exponent 71. For now, the job stops any base that has a hard cofactor (fully ECM'd) of >= 102 digits. I will then run back through and run any remaining exponents until they hit a cofactor of >= 110 digits. Hopefully this is OK.[/QUOTE] Attention, I am calculating myself the sequences of bases 179 and 181, as RichD says. It's just that I hadn't reported the results to FactorDB yet. I am afraid that we have done the same calculations twice. Please look at the last line of the table under the heading "Navigation" on [URL="http://www.aliquotes.com/aliquotes_puissances_entieres/aliquotes_puissances_entieres.html"]the main project page[/URL] : bases 179 and 181 were reserved for me. Should I stop my calculations on these two bases if you have also done them ? Have you also done calculations for the exponents of parity opposite to the base ? 
[QUOTE=RichD;608047]I'll start initializing prime bases 223, 227 & 229.[/QUOTE]
OK, many thanks ! It will extend my area of analysis a bit this summer if we integrated bases that are exhaustively prime numbers further than 200. 
[QUOTE=garambois;608060]Attention, I am calculating myself the sequences of bases 179 and 181, as RichD says.
It's just that I hadn't reported the results to FactorDB yet. I am afraid that we have done the same calculations twice. Please look at the last line of the table under the heading "Navigation" on [URL="http://www.aliquotes.com/aliquotes_puissances_entieres/aliquotes_puissances_entieres.html"]the main project page[/URL] : bases 179 and 181 were reserved for me. Should I stop my calculations on these two bases if you have also done them ? Have you also done calculations for the exponents of parity opposite to the base ?[/QUOTE] I am very sorry JeanLuc. I only did the calculations on just those two bases and ONLY for the sameparity exponents up to exponent=71. They were uploaded a while ago. I have stopped now. Please take credit for everything. Obviously you did the calculations before me. I have not touched oppositeparity exponents. I'm only now interested in sameparity exponents. I have not been on the project in a couple of years and had no idea that the Navigation section that you mentioned existed about reserving bases that were not yet in the DB. I don't recall it being there a few years ago. I only look at reservations in bases that were already in the DB. I thought we had to look in the threads here to see when people are working on new bases, which is when I saw that you might be working on base 181 after Rich quoted you. That section is a long way down the page and is the last line in the section. When Rich and now you mentioned it, it took me several minutes to find it. Perhaps it can be hilighted somehow for new (and old, like me) people. Please accept my apologies. Gary 
Gary, there's no problem.
You meant well ! If you did the calculations up to exponent 71 for both bases, please enter your results into FactorDB, because I am only at exponent 65 for base 179 and 57 for base 181. And let me know right away so that I can stop my calculations to run my two cores on something else. I think you must have a lot more computing power than I do if you got this far in such a short time. But this mishap does raise the question of the visibility of reservations for new contributors who want to join the project. How can I make this line more visible in the table ? By writing bigger and in colors ? Do you have an idea ? Edwin and I should also make it clearer in the first post of our threads, where we can see the reservations on the main project page ? Otherwise, Gary, if you want to attack new bases and calculate sequences of the same parity, you can do it by reserving for example bases that are prime numbers like RichD does : you can reserve bases from base 233 onwards following RichD. And if you specify that you only do the calculations for the matched parity sequences, I can take care of the other sequences, but you just have to say so. Normally, I make sure that they are all at least 105 digits long. But if you choose to calculate them, you can be satisfied with 100 digits, it must be very fast for you. You can also choose to initialize some bases belonging to cycles on the same principle. I will gladly note your reservations in the appropriate place if you choose. There is also another job that can be done: adding exponents to bases 2, 3 and 5, or even 7. But this is a rather ambitious work, because the starting terms of the sequences start to be very large for these large exponents. 
JeanLuc,
I [I]only [/I]did [I]same[/I]parity exponents up to base 71. Nothing with oppositeparity. [B]Everything has been uploaded to the factordb.[/B] Not everything terminated. That would take a long time. I stopped if there was a hard cofactor >= 110. For exponents < 60, everything except 181^57 terminated. For exponents > 60, nothing terminated. My computing power for this effort was only one 8core Windows machine. It only took ~67 hours. As you can see above, I did not do the hard stuff. Also I stopped once I realized that you were working on them. You can keep going on as you have on oppositeparity exponents. For sameparity exponents, 181^57 is the lowest one still open and then there's everything for exponents > 60. I wasn't able to add many iterations to the big ones with the above C110 restriction. To save you a little bit of time: All composite cofactors for those remaining sameparity exponents <= 71 have been ECM'd to either 31% for C<117 or t35 for C>=117 so you'll probably want to do some more ECM for C>=117 before going to NFS. Gary 
You asked for a suggestion on that reservation section. I would say: Just hilight it with a different color or bold it. You could even move it up the page somewhat.
Thank you for being understanding. I get a little too excited sometimes and forget to pay the appropriate amount of attention to what is going on in the threads. The great camaraderie that you have with people here is a big part of why I chose to come back again. I may take on some new bases for sameparity exponents in the future. For now, I'll keep whittling down the existing sameparity exponents in the easier sequences thread. They are starting to become not so easy any more. :) I do have a new idea that I'll bring up maybe on Sunday that I'd like to throw out at you. I need to take some time to detail it out first before presenting it. 
Maybe the reservations could be moved up the page, to just below the header info (above the "Definitions"). It could be bold and reduced to one line. There aren't any links, so it really isn't a navigation source.
I will look at some kind of note for the other thread, but all the sequences deemed available by that thread are unreserved (as best as I can determine), so work on reserved tables is outside its scope. As long a table does not yet exist, it isn't even considered. When it does exist, reservations within the table are considered. 
The "Open" tab on the data page is not currently useful. I think people forgot what it was supposed to be used for. IIRC it was meant for open sequence bases (i.e. bases that are themselves open sequences, for [I]i[/I]=1). I think I requested it when we (I?) started initializing the Lehmer Five, for those specific bases and any similar ones.

@Gary :
OK, thanks for the clarification. I will continue my calculations for bases 179 and 181. As for your new idea, I look forward to it ! @all : Maybe I'll try to look at how to make the reservations more visible tomorrow. It all depends on the time I have. The second half of June is always extremely busy for me, even on weekends. So don't be surprised if I don't make full updates in the next few days. I may only update the reservations, or I may only update some of the bases Edwin suggested in his first post. Either way, by the beginning of July, I'll have time to do all the work. 
I'm sorry, but it was impossible for me to update the page today, except for the reservations.
And it will probably be the same next weekend, as I already announced. However, I changed the location of the "Reservation" section as suggested below by Edwin. What do you think about it ? Is it clear and is it good English ? [QUOTE=EdH;608068]Maybe the reservations could be moved up the page, to just below the header info (above the "Definitions"). It could be bold and reduced to one line. There aren't any links, so it really isn't a navigation source. [/QUOTE] 
[QUOTE=garambois;608113]I'm sorry, but it was impossible for me to update the page today, except for the reservations.
And it will probably be the same next weekend, as I already announced. However, I changed the location of the "Reservation" section as suggested below by Edwin. What do you think about it ? Is it clear and is it good English ?[/QUOTE]I think it all looks good, except for a minor point. If it is important, the other thread is only for reserving smaller (<145 digit) matched parity (and doubled square) sequences. Perhaps, "term <145 digits)" on the end? But, I don't know that it is necessary to add too much explanation. What you have now is probably quite sufficient. Thanks! 
[QUOTE=garambois;608113]I'm sorry, but it was impossible for me to update the page today, except for the reservations.
And it will probably be the same next weekend, as I already announced. However, I changed the location of the "Reservation" section as suggested below by Edwin. What do you think about it ? Is it clear and is it good English ?[/QUOTE] The Reservation section looks great! Clear and concise. No way I could miss that! :) I found one part in the Definitions section that confused me when returning to the effort after a couple years away. For the pink definition (over 140 digits), you state: "Pink with or without name code". Later in the same sentence you state "Free for reservation". This gave me the impression that all pink squares were free for reservation even if they had a name code in then. I quickly realized that those were truly reserved and I needed to ask someone to release them if I wanted to work on them. I think the pink definition needs to be split up onto two separate lines like the orange definition. One line if it has a name code, it is "blocked for reservation". The other line if without a name code, it is "free for reservation". One nitpick: Base 1152 is shown out of order below base 1155. :) 
JeanLuc,
This is the idea I was referring to a couple days ago. I've noticed that the cutoff for the sizelimit of the bases on your pages seems to vary quite a bit. On the extreme small end, there is base 20. Its largest exponent of 100 is only 131 digits. On the extreme large end, there is base 99. Its largest exponent of 100 is 200 digits! This largest size seems to vary between 131 and 200 digits throughout the table. But most bases, especially the small bases <= 10 tend to cutoff around 160165 digits. Not very many are > 180 digits. What this does is skew the primes %. Notice that for bases ~2030, that percentage is unusually high. For bases ~80100, that percentage is unusually low. These two ranges of bases are on the extreme small or large end of the largest exponent. This causes the unusual percentages. Also, not having the exponents on the smaller end means we are not testing some that could be interesting to the project. So I propose this: Can we add exponents up to 160 digits for all bases on the project? This would involve additions to 22 bases: Bases 20 thru 37 (14 bases), and single bases 288, 338, 385, 392, 1058, 1152, 1155, and 1250. Bases 20 thru 30 would be the most interesting because they would have the most additions due to their small current cutoff of only 131 to 148 digits. A majority of the bases would only require an addition of <= 5 exponents. Let me know what you think. I can start on whatever initialization you think is appropriate. Gary 
Here is a list of all 12 digit primes that appear in more than one sequence (excluding merges) throughout the entire set of tables (as far as I can tell):[code]109964639887,193,22,263
109964639887,40,19,182 126249927637,15472,5,113 126249927637,67,75,5 142754777149,101,32,504 142754777149,52,39,640 154198251007,17,76,702 154198251007,22,87,1336 194041181491,439,22,392 194041181491,76,35,2974 220689850709,12496,19,494 220689850709,15,12,3377 389689791443,10,109,4650 389689791443,15,34,1318 392293758937,10,85,807 392293758937,42,23,2984[/code]Some manual editing was done. I hope I didn't introduce any errors this time. 
[QUOTE=EdH;608123]I think it all looks good, except for a minor point. If it is important, the other thread is only for reserving smaller (<145 digit) matched parity (and doubled square) sequences. Perhaps, "term <145 digits)" on the end?[/QUOTE]
Done. [QUOTE=gd_barnes;608124] I found one part in the Definitions section that confused me when returning to the effort after a couple years away. For the pink definition (over 140 digits), you state: "Pink with or without name code". Later in the same sentence you state "Free for reservation". This gave me the impression that all pink squares were free for reservation even if they had a name code in then. I quickly realized that those were truly reserved and I needed to ask someone to release them if I wanted to work on them. I think the pink definition needs to be split up onto two separate lines like the orange definition. One line if it has a name code, it is "blocked for reservation". The other line if without a name code, it is "free for reservation".[/QUOTE] Done. [QUOTE=gd_barnes;608124] One nitpick: Base 1152 is shown out of order below base 1155. :)[/QUOTE] Done. Please check if everything is good according to your remarks. Thank you for your ideas. 
[QUOTE=garambois;608170]Please check if everything is good according to your remarks.
Thank you for your ideas.[/QUOTE] Looks great! 
[QUOTE=gd_barnes;608135]JeanLuc,
This is the idea I was referring to a couple days ago. I've noticed that the cutoff for the sizelimit of the bases on your pages seems to vary quite a bit. On the extreme small end, there is base 20. Its largest exponent of 100 is only 131 digits. On the extreme large end, there is base 99. Its largest exponent of 100 is 200 digits! This largest size seems to vary between 131 and 200 digits throughout the table. But most bases, especially the small bases <= 10 tend to cutoff around 160165 digits. Not very many are > 180 digits. What this does is skew the primes %. Notice that for bases ~2030, that percentage is unusually high. For bases ~80100, that percentage is unusually low. These two ranges of bases are on the extreme small or large end of the largest exponent. This causes the unusual percentages. Also, not having the exponents on the smaller end means we are not testing some that could be interesting to the project. So I propose this: Can we add exponents up to 160 digits for all bases on the project? This would involve additions to 22 bases: Bases 20 thru 37 (14 bases), and single bases 288, 338, 385, 392, 1058, 1152, 1155, and 1250. Bases 20 thru 30 would be the most interesting because they would have the most additions due to their small current cutoff of only 131 to 148 digits. A majority of the bases would only require an addition of <= 5 exponents. Let me know what you think. I can start on whatever initialization you think is appropriate. Gary[/QUOTE] We were already operating on this principle at the beginning of the project. But when we were processing the data, we found it easier to harmonize the largest exponents of each base, because it was easier to remember and it simplified the discussions and even the programs. So we decided to work in "bearings" (I hope I have the good word here !). On the other hand, we can make the jump less brutal, because for base 19, we go up to exponent 140 and for base 20, we go up to exponent 100. In the first instance, we can consider an intermediate bearing and put bases 20 to 40 up to exponent 120 for example. But here we have a big question for all the participants in the project and especially Edwin : Are you willing to do the calculations afterwards ? 
[QUOTE=EdH;608168]Here is a list of all 12 digit primes that appear in more than one sequence (excluding merges) throughout the entire set of tables (as far as I can tell):[code]109964639887,193,22,263
... ... 392293758937,42,23,2984[/code]Some manual editing was done. I hope I didn't introduce any errors this time.[/QUOTE] Thank you very much Edwin. I'll be checking very carefully tomorrow night, as the time is moving fast and unfortunately it's already 9:30 at our house. I didn't think there would be so many 12digit couples ! When you say "throughout the entire set of tables", do you mean "throughout the entire set of bases" ? 
[QUOTE=garambois;608176]. . .
But here we have a big question for all the participants in the project and especially Edwin : Are you willing to do the calculations afterwards ?[/QUOTE]I would be willing to help, at least initializing them, if needed. This would include the same parity sequences as I'm already working. However, keep in mind that if we make this change prior to your data gathering, the present set may be "watered down" a bit. [QUOTE=garambois;608178]Thank you very much Edwin. I'll be checking very carefully tomorrow night, as the time is moving fast and unfortunately it's already 9:30 at our house. I didn't think there would be so many 12digit couples ! When you say "throughout the entire set of tables", do you mean "throughout the entire set of bases" ?[/QUOTE]"Entire set of tables," means all sequences of all bases represented in all the tables. However, this is based on the status of all the sequences at the last update I did. Obviously, the terminated sequences stay the same, but there is more change in the openended sequences than I realized a while ago. I have all the sequences in a local directory and when I run a full update I see a lot of sequences being updated, which means my local last line is different from the db last line. I used to be able to run a full update in a couple hours, but with the current db limitations, I've spread that out to over 24 hours. 
As to the project home page, I will echo Gary. I agree, it "Looks great!":smile:

[QUOTE=garambois;608176]We were already operating on this principle at the beginning of the project.
But when we were processing the data, we found it easier to harmonize the largest exponents of each base, because it was easier to remember and it simplified the discussions and even the programs. So we decided to work in "bearings" (I hope I have the good word here !). On the other hand, we can make the jump less brutal, because for base 19, we go up to exponent 140 and for base 20, we go up to exponent 100. In the first instance, we can consider an intermediate bearing and put bases 20 to 40 up to exponent 120 for example. But here we have a big question for all the participants in the project and especially Edwin : Are you willing to do the calculations afterwards ?[/QUOTE] I feel that making the jump less brutal is a great way to go! Here is something that could be considered: Bases 20,21: exponent 125 (If we only go to exponent 120, we still miss a few <= 160 digits.) Bases 22,23: exponent 120 Bases 24,26: exponent 115 Bases 28 to 31: exponent 110 Bases 33 to 37: exponent 105 Bases 288, 338, 385, and 392: exponent 65 Bases 1058, 1152, 1155, and 1250: exponent 55 If you feel the jumps are too small, maybe combine into: Bases 20,21 to exponent 125, bases 22 to 26 to exponent 120, and bases 28 to 37 to exponent 110. The larger bases jumps would fit right in with the current smaller jumps on larger bases. I have already initialized all sameparity sequences that begin at <= 160 digits on all of these bases, terminating a few. I have also initialized oppositeparity sequences that begin at <= 160 digits for bases 20 and 21. There are not many iterations that can be added at this point for some of the larger ones on oppositeparity. If you agree we can do this, I will continue initializing all that I can in a coordinated effort with Ed and anyone else who wishes to help. 
[QUOTE=gd_barnes;608186]
If you feel the jumps are too small, maybe combine into: Bases 20,21 to exponent 125, bases 22 to 26 to exponent 120, and bases 28 to 37 to exponent 110. The larger bases jumps would fit right in with the current smaller jumps on larger bases. I have already initialized all sameparity sequences that begin at <= 160 digits on all of these bases, terminating a few. I have also initialized oppositeparity sequences that begin at <= 160 digits for bases 20 and 21. There are not many iterations that can be added at this point for some of the larger ones on oppositeparity. If you agree we can do this, I will continue initializing all that I can in a coordinated effort with Ed and anyone else who wishes to help. [/QUOTE] Bases 20 to 25 to exponent 125 Bases 26 to 30 to exponent 120 Bases 31 to 40 to exponent 110 Bases 288, 338, 385, and 392: exponent 65 Bases 1058, 1152, 1155, and 1250: exponent 55 The above extensions seem to me to be a good compromise : I have changed your proposal a bit. I will make these extensions in a few days. [QUOTE=EdH;608181]I would be willing to help, at least initializing them, if needed. This would include the same parity sequences as I'm already working. However, keep in mind that if we make this change prior to your data gathering, the present set may be "watered down" a bit. [/QUOTE] If we make these changes before the summer data gathering, indeed, the present set may be "watered down" a bit. But what matters is the number of points that we will have in the absolute, that is to say the number of sequences that will end with a prime number, especially if this prime number is <100. [QUOTE=EdH;608181] "Entire set of tables," means all sequences of all bases represented in all the tables. However, this is based on the status of all the sequences at the last update I did. Obviously, the terminated sequences stay the same, but there is more change in the openended sequences than I realized a while ago. I have all the sequences in a local directory and when I run a full update I see a lot of sequences being updated, which means my local last line is different from the db last line. I used to be able to run a full update in a couple hours, but with the current db limitations, I've spread that out to over 24 hours.[/QUOTE] Thank you very much for these explanations Edwin. 
[QUOTE=garambois;608226]Bases 20 to 25 to exponent 125
Bases 26 to 30 to exponent 120 Bases 31 to 40 to exponent 110 Bases 288, 338, 385, and 392: exponent 65 Bases 1058, 1152, 1155, and 1250: exponent 55 The above extensions seem to me to be a good compromise : I have changed your proposal a bit. I will make these extensions in a few days. If we make these changes before the summer data gathering, indeed, the present set may be "watered down" a bit. But what matters is the number of points that we will have in the absolute, that is to say the number of sequences that will end with a prime number, especially if this prime number is <100. Thank you very much for these explanations Edwin.[/QUOTE] Sounds like a great compromise! I look forward to it. It won't be watered down too much if we get them mostly initialized by the end of June, which I plan to do. Bases 20, 21, and 22 are now initialized for [I]all[/I] parity exponents <= 160 digits. Bases >= 23 are all initialized for sameparity exponents <= 160 digits. I will continue working my way up for oppositeparity exponents for bases >= 23 and keep you posted. 
Base 223 can be added to the table at the next update.

[QUOTE=RichD;608233]Base 223 can be added to the table at the next update.[/QUOTE]
Are you done working on it? If so, I'll work on some of the sameparity exponents. 
Partially updated page.
Many thanks to all for your help. [B]Added base : 223.[/B] [B]Added exponents for the bases mentioned in the previous posts.[/B] Please notify me of any malfunction or error. I still haven't been able to free up enough time to update the sequences ending with a prime number in the other thread. I've prioritized the work mentioned above to make the overall status of the project clearer. 
@JeanLuc: In preparation for your upcoming data harvest, would you like me to focus on something different from the other thread?
Would you rather we focus on certain bases rather than across all tables? I'm currently in the process of updating my entire local set, which should complete tomorrow, including all the additions. After that I'll revisit my prime searches, but at this point, I can't see anything but randomness in my results. Perhaps the randomness is the pattern? 
[QUOTE=gd_barnes;608245]Are you done working on it?[/QUOTE]
I'm no longer working on any exponents in base 223. 
Bases 227 & 229 can be added at the next update. All my computations are completed.

Initializing bases 233, 239 & 241. This should complete all prime bases up to 250.

[QUOTE=EdH;608297]@JeanLuc: In preparation for your upcoming data harvest, would you like me to focus on something different from the other thread?
[/QUOTE] Thank you very much Edwin. I'm not sure yet when I'll start the big harvest. It's quite possible that in July I'll be refining all my programs and testing on small samples of the data. Some questions and comments may come during this period. Then, after a 3week vacation, around midAugust, I will run the big harvest and the analysis programs on the full data set. And then we will see what happens. Let's finish as many calculations as possible for now. [QUOTE=EdH;608297] Would you rather we focus on certain bases rather than across all tables? [/QUOTE] I would intuitively say that the smaller bases should be preferred. But it's going to be very difficult to finish all the matched parity sequences for all bases <20 by the middle of August, because there are still some nasty sequences left. [QUOTE=EdH;608297] I'm currently in the process of updating my entire local set, which should complete tomorrow, including all the additions. After that I'll revisit my prime searches, but at this point, I can't see anything but randomness in my results. Perhaps the randomness is the pattern?[/QUOTE] Unfortunately, we are perhaps condemned to find only randomness ! And if we were to see something else, would we be able to realize it ? This is the big problem. Because apart from looking with my eyes, I don't really see how to automatically search for aligned points or worse, points belonging to a curve on sets of points as I propose in post [URL="https://www.mersenneforum.org/showpost.php?p=592117&postcount=1360"]#1360[/URL]. Algorithms that do this job must exist, but I'm afraid it's beyond my skills ! 
[QUOTE=RichD;608352]Bases 227 & 229 can be added at the next update. All my computations are completed.[/QUOTE]
[QUOTE=RichD;608391]Initializing bases 233, 239 & 241. This should complete all prime bases up to 250.[/QUOTE] This is very good news, thank you very much ! 
[QUOTE=garambois;608392]. . .
I would intuitively say that the smaller bases should be preferred. But it's going to be very difficult to finish all the matched parity sequences for all bases <20 by the middle of August, because there are still some nasty sequences left. . . .[/QUOTE]But I can opt to work the 150 digits and up terms for the lower bases over working 150 and up elsewhere. I'll focus near the bottom more and see where we get. I think most of the sequences below 150 digit terms have been taken below 145. There are probably less than a dozen left in that region. As to programming, I'll have to look back over what we may have shown interest in for the past and see what we're looking for now. I'm still looking at a more complete list of primes that cross bases, but that is proving to be quite a task and I may have to modify my approach. I did get a full update done for my local set, without any apparent db limits interfering. 
[QUOTE=garambois;608176]So we decided to work in "bearings" (I hope I have the good word here !).
[/QUOTE] I know I'm late to this discussion. I did translate "bearing" to French ("palier") and back to English and got "level", which makes much more sense to me, in case you want to use that in the future. I'm back to working on base 210 right now, though once I'm done to 210^11, I'd like to try to initialize at least some of the remaining open sequence bases less than 1k (these all merge into Lehmer Five sequences, which are already initialized) to fill out the Open tab on the main data page. 
[QUOTE=Happy5214;608433]. . .
I'm back to working on base 210 right now, though once I'm done to 210^11, I'd like to try to initialize at least some of the remaining open sequence bases less than 1k (these all merge into Lehmer Five sequences, which are already initialized) to fill out the Open tab on the main data page.[/QUOTE]Welcome back! Should I pull 210 matched parity sequences out of the other thread? The added exponents aren't showing a reserved status currently. 
[QUOTE=EdH;608436]Welcome back! Should I pull 210 matched parity sequences out of the other thread? The added exponents aren't showing a reserved status currently.[/QUOTE]
I don't plan on going above [I]i[/I]=60 (I lack the patience to do too many NFS runs above C120 on my Core 2 Quad), so you should be fine to keep those. 
[QUOTE=Happy5214;608437]I don't plan on going above [I]i[/I]=60 (I lack the patience to do too many NFS runs above C120 on my Core 2 Quad), so you should be fine to keep those.[/QUOTE]Thanks! I'll add them back.

Base 233 can be added at the next update.

I terminated the following sameparity sequences:
227^53, 227^55, 227^63, 227^67, 229^55, and 229^59 Bases 227 and 229 were recently initialized by Rich so are not on the pages yet. 
[QUOTE=EdH;608396]I'm still looking at a more complete list of primes that cross bases, but that is proving to be quite a task and I may have to modify my approach.[/QUOTE]
This is huge, a lot of thanks ! 
[QUOTE=Happy5214;608433]I know I'm late to this discussion. I did translate "bearing" to French ("palier") and back to English and got "level", which makes much more sense to me, in case you want to use that in the future.[/QUOTE]
OK, thanks, I had hesitated ! 
Page updated.
Many thanks to all for your help. I had very little time to do this update and I could not verify anything. Please let me know of any errors or malfunctions. [B]Added bases : 227, 229 and 233.[/B] [B]Updated bases : All the bases announced below.[/B] [CODE]5^249: Prime  EDH * 10^154: Prime  GDB * 20^102: Prime  GDB * 20^106: Prime  GDB * 21^103: Prime  GDB * 21^105: Prime  GDB * 21^109: Prime  GDB * 22^110: Prime  GDB * 23^105: Prime  GDB * 23^115: Prime  GDB * 23^117: Prime  GDB * 26^104: Prime  GDB * 29^107: Prime  GDB * 31^101: Prime  GDB * 31^103: Prime  GDB * 31^107: Prime  GDB * 48^92: Prime  GDB * 58^86: Prime  GDB * 63^83: Prime  GDB * 65^83: Prime  GDB * 65^85: Prime  GDB * 67^85: Prime  GDB * 68^82: Prime  GDB * 76^78: Prime  GDB * 76^80: Prime  EDH * 77^73: Prime  GDB * 77^79: Prime  GDB * 77^81: Prime  GDB * 88^64: Prime  RCH * 88^70: Prime  GDB * 92^76: Prime  GDB * 94^74: Prime  GDB * 96^80: Prime  GDB * 103^79: Cycle  GDB * 105^71: Prime  GDB * 105^73: Prime  GDB * 107^71: Prime  GDB * 109^75: Prime  GDB * 113^75: Prime  GDB * 127^71: Prime  GDB * 127^73: Prime  OKR * 131^63: Prime  GDB * 131^67: Prime  GDB * 137^71: Prime  GDB * 137^73: Prime  GDB * 139^63: Prime  GDB * 149^63: Prime  GDB * 149^71: Prime  GDB * 151^63: Prime  GDB * 151^65: Prime  GDB * 151^73: Prime  GDB * 173^73: Prime  GDB * 191^59: Prime  GDB * 191^63: Prime  GDB * 193^65: Prime  GDB * 197^67: Prime  GDB * 197^79: Prime  GDB * 210^64: Prime  A * 211^65: Prime  GDB * 220^66: Prime  GDB * 223^55: Prime  GDB * 223^59: Prime  GDB * 223^63: Prime  GDB * 284^62: Prime  GDB * 338^61: Prime  GDB * 564^56: Prime  GDB * 720^54: Prime  GDB * 1058^50: Prime  KRB * 1152^42: Prime  GDB * 1152^44: Prime  GDB * 1250^49: Prime  GDB * 15472^40: Prime  GDB *[/CODE] 
A couple of issues on the web page updates:
48^92 should be terminated by me instead of Yoyo. 24^110 should be terminated. It was terminated yesterday and made it on to Ed's list this morning (U.S.). Perhaps you took a snapshot of the list before he updated it. Thank you for this massive update! :) 
[QUOTE=gd_barnes;608487]
48^92 should be terminated by me instead of Yoyo. [/QUOTE] Please, I don't understand this message : unless I'm mistaken, 48^92 is indeed ended by you on the page, right ? 
[QUOTE=garambois;608477]This is huge, a lot of thanks ![/QUOTE]Right now my primes list for >10^9, which is uniques* for each base and multiples across is 331.3 MB, with 9615120 primes.
Whittled down to multiples across two+ bases, that list is 6.5MB, with 174161 primes, but most of those are due to merges. [QUOTE=garambois;608479]. . . [B]Added bases : 227, 229 and 233.[/B] [B]. . .[/B][/QUOTE]All these new bases will not be represented in my primes list work, yet. * in this case unique means a prime is represented only once for a base, even though it shows up multiple times within that base. As of yet, I haven't noticed any primes that show up multiple times within a single base AND within another base. 
[QUOTE=garambois;608488]Please, I don't understand this message : unless I'm mistaken, 48^92 is indeed ended by you on the page, right ?[/QUOTE]
Oops. You are correct. I was looking at 48^82. I get that mixed up all the time. Mea culpa. :) 
Everything is looking great from my perspective and I've added the new bases to the other thread, although for the near time I won't do any work above base 20 for the other thread.
Thanks for all the work. I hope we aren't giving you too much with the other thread.:smile: Edit: 24^110 is still being carried in the other thread and shouldn't be lost, so it shouldn't be an issue to let it stay there from my viewpoint. 
[QUOTE=EdH;608493]Edit: 24^110 is still being carried in the other thread and shouldn't be lost, so it shouldn't be an issue to let it stay there from my viewpoint.[/QUOTE]
Sound great to me! Right now with the sameparity exponents, if a base has been initialized here but does not show on the web page or you have not had time to include it in your listings in the other thread, I'll report any termination here. If it is shown on the web page and in your listing, of course I'll report it there. 
[QUOTE=EdH;608490]Right now my primes list for >10^9, which is uniques* for each base and multiples across is 331.3 MB, with 9615120 primes.
Whittled down to multiples across two+ bases, that list is 6.5MB, with 174161 primes, but most of those are due to merges. * in this case unique means a prime is represented only once for a base, even though it shows up multiple times within that base. As of yet, I haven't noticed any primes that show up multiple times within a single base AND within another base.[/QUOTE] WOW, this is heavy stuff ! But I think once the mergers are removed, the quantity will decrease a lot, at least if you can do that ! [QUOTE=gd_barnes;608491]Oops. You are correct. I was looking at 48^82. I get that mixed up all the time. Mea culpa. :)[/QUOTE] I also make this kind of mistake regularly ! ;) [QUOTE=EdH;608493] Thanks for all the work. I hope we aren't giving you too much with the other thread.:smile: [/QUOTE] It's great if I have work, it means we are making progress. It's just that I can't always do the updates right away and sometimes it takes 10 or 15 days or even more depending on the period. 
1 Attachment(s)
Here's a full list of all primes >10^9 that occur in two bases, with all merges reflected only once. This listing does not include the most current bases, but otherwise includes the entire set of tables. In the case where a prime was found in several merged sequences, only one of the merged sequences is listed. This list is for all multiples >10^9. Of note, I don't believe there are any triples and there are no examples larger than 12 digits. Here are the 12 digit primes:[code]109964639887,193,22,263
109964639887,40,19,182 126249927637,15472,5,113 126249927637,67,75,5 142754777149,101,32,504 142754777149,52,39,640 154198251007,17,76,702 154198251007,22,87,1336 194041181491,439,22,392 194041181491,76,35,2974 220689850709,12496,19,494 220689850709,15,12,3377 389689791443,10,109,4650 389689791443,15,34,1318 392293758937,10,85,807 392293758937,42,23,2984[/code] 
Bases 239 & 241 can be added at the next update.

[QUOTE=RichD;608653]Bases 239 & 241 can be added at the next update.[/QUOTE]
OK, many thanks Rich ! 
[QUOTE=EdH;608623]Here's a full list of all primes >10^9 that occur in two bases, with all merges reflected only once. This listing does not include the most current bases, but otherwise includes the entire set of tables. In the case where a prime was found in several merged sequences, only one of the merged sequences is listed. This list is for all multiples >10^9. Of note, I don't believe there are any triples and there are no examples larger than 12 digits. Here are the 12 digit primes:[code]109964639887,193,22,263
109964639887,40,19,182 ... 392293758937,10,85,807 392293758937,42,23,2984[/code][/QUOTE] Thank you very much Edwin. This time, everything seems to be perfect. I did several checks, everything is good. I will do some more analysis in 2 weeks. A priori, the occurrences of these primes seem to be completely random. I will have to be creative to try to find something else, I will look, even if I think that there should be nothing else than random. I will also try to find these lists with my own program, to confirm them. I remember that more than two years ago you sent us lists that you had obtained with other programs. And it was only a year later that I noticed something that led to a conjecture. So we will have to be patient ! :smile: 
I have terminated the following sameparity sequences:
239^53, 239^55, 239^57, 239^63, & 239^67 241^53, 241^55, 241^57, & 241^59 
It's been a while, but I'm assuming the inclusion standard for a base is still initializing everything to 100 digits. If that's the case, base 306 (306:i1=396=276:i1, so this falls under the "merges into open" category) can be added. Its sameparity sequences are actually terminated up to 140 digits thanks to some lucky ECM hits.
After some personal Riesel assignments, I'll resume base 210 at 210^9 (210^5 and 210^7 have reached C120+ cofactors, so I'm done with those). 
[QUOTE=Happy5214;608714]It's been a while, but I'm assuming the inclusion standard for a base is still initializing everything to 100 digits. If that's the case, base 306 (306:i1=396=276:i1, so this falls under the "merges into open" category) can be added. Its sameparity sequences are actually terminated up to 140 digits thanks to some lucky ECM hits.
[/QUOTE]If I understand correctly, you have initialized the base 306, right ? 
[QUOTE=Happy5214;608714]It's been a while, but I'm assuming the inclusion standard for a base is still initializing everything to 100 digits. If that's the case, base 306 (306:i1=396=276:i1, so this falls under the "merges into open" category) can be added. Its sameparity sequences are actually terminated up to 140 digits thanks to some lucky ECM hits.[/QUOTE]
I have recently been following up on newly initialized bases by doing additional work on (only) sameparity sequences up to 160 digits. If it's OK with you, I'd like to do that here for those in the 140160 digit range. 
I terminated 306^62.

[QUOTE=garambois;608226]Bases 20 to 25 to exponent 125
Bases 26 to 30 to exponent 120 Bases 31 to 40 to exponent 110 Bases 288, 338, 385, and 392: exponent 65 Bases 1058, 1152, 1155, and 1250: exponent 55 The above extensions seem to me to be a good compromise : I have changed your proposal a bit. I will make these extensions in a few days. [/QUOTE] [QUOTE=gd_barnes;608228]Sounds like a great compromise! I look forward to it. It won't be watered down too much if we get them mostly initialized by the end of June, which I plan to do. Bases 20, 21, and 22 are now initialized for [I]all[/I] parity exponents <= 160 digits. Bases >= 23 are all initialized for sameparity exponents <= 160 digits. I will continue working my way up for oppositeparity exponents for bases >= 23 and keep you posted.[/QUOTE] JeanLuc, I have completed many initializations for the newly added base's exponents shown above for all parities. Specifically for bases 20 to 40 I have initialized all exponents that are <= 160 digits. For bases 288, 338, 385, 392, 1058, 1152, 1155, and 1250, I have completed all newly added exponents of all sizes. I had already completed and you had done full updates for bases 20 thru 23. Here is a detailed list of what I have completed since then: Base ; exponent range 24; 101 to 115 26; 101 to 113 28; 101 to 110 29; 100 to 109 (Exponent=100 is not an initialization but some quick ECM extended some of them.) 30; 101 to 108 31; 100 to 106 33; 100 to 105 34; 100 to 104 35; 100 to 103 37; 100 to 102 38; 101 to 102 (I went to slightly > 160 digits on bases 38 to 40.) 39; 100 to 102 40; 100 to 102 Bases 288, 338, 385, & 392; 61 to 65 (bases fully initialized) Bases 1058, 1152, 1155, & 1250; 51 to 55 (bases fully initialized) Some of these you may have already done full updates last time for them. My plan is now to continue initializing sequences in this area for bases 20 to 40 that are > 160 digits. There are a lot of them! For reference: Here is how I initialize sequences where the size is so large: I run ECM/SIQS/NFS until the cofactor is >= 110 digits. All cofactors are ECM'd to t35 unless the optimum is less than that. This provides a good stopping point. Because of the large size, many times this results in adding very few iterations, sometimes as few as 0 or 1. Gary 
[B][SIZE=4]Information on the summer works[/SIZE][/B]
Thank you all for your hard work. I will try to update this weekend. [B]But if I can't, this work will be done after July 8 when I will have much more time, I will then do a general update for all the bases.[/B] To simplify, let's say that during the month of July, I'm going to perfect my analysis programs and try to reproduce Edwin's work for prime numbers > 10^9. And also, I will do a lot of testing on small samples to see if some calculations need to be pushed a little further. Of course, I'll let you know if I start to observe things that are not random. I will also use this first half of the summer to try to fix the difficulty to scan FactorDB. [B]Then, on August 15, after a final, very thorough update, I'll launch the big FactoDB scan.[/B] It will take maybe 1 or 2 days, I hope not more with all the blockages. Then I'll just have to run my scan programs which will probably run for 1 or 2 days too. Then it will be time to look at the final results. [B]And only then, around August 2025, will I be able to tell you whether something new will come out of these analyses.[/B] I hope so, because we have all worked hard. But we are angling for something and we don't really know if we will find anything. Last year we came up emptyhanded. We'll see this year. The main thing is to try, that's the only way we'll find something. [U]Details of the points examined during this summer's analysis :[/U]  Redo the works explained in post [URL="https://www.mersenneforum.org/showpost.php?p=592117&postcount=1360"]#1360[/URL] with the updated data.  Redo these works with the bases and exponents that are only prime numbers, as my intuition tells me.  Analyze Edwin's results on prime numbers > 10^9.  Crosscheck the data in a different way thanks to new scripts written by Karsten Bonath (thanks a lot to him who works discreetly).  Continue the work initiated two years ago with Edwin on the occurrences of prime numbers in sequences (prime numbers at the end of sequences and also in any term of sequences).  Try to do some work on sequences that end in cycles, but we have very few cycles and this work may still not be possible.  As a reminder, the original purpose of the project is explained in a synthetic way in post [URL="https://www.mersenneforum.org/showpost.php?p=586049&postcount=1328"]#1328[/URL]. ... ... Other ideas than those planned may arise during the work. Ideas can come from anyone and lead in new directions not originally planned, as has happened very recently with Edwin and many times in the past. [B]If a strange idea pops into your head, if you feel like looking at something in the data, if you feel like you notice something that is not random, you should talk about it here on this forum.[/B] No idea will be considered "stupid", even if it is trivial or if someone has had it before on the thread. The thread now has so many pages that it is difficult to remember or read everything before posting. And it is during discussions and sometimes even during misunderstandings that new ideas are born. :smile: 
[QUOTE=garambois;608727]If I understand correctly, you have initialized the base 306, right ?[/QUOTE]
Yes. [QUOTE=gd_barnes;608745]I have recently been following up on newly initialized bases by doing additional work on (only) sameparity sequences up to 160 digits. If it's OK with you, I'd like to do that here for those in the 140160 digit range.[/QUOTE] Sorry for the late reply. I don't consider that base reserved, so go right ahead. 
[QUOTE=gd_barnes;608840]JeanLuc,
I have completed many initializations for the newly added base's exponents shown above for all parities. Specifically for bases 20 to 40 I have initialized all exponents that are <= 160 digits. For bases 288, 338, 385, 392, 1058, 1152, 1155, and 1250, I have completed all newly added exponents of all sizes.[/QUOTE] Bases 20 thru 30 have now been completely initialized for all recently added exponents all sizes. This only leaves bases 31 thru 40 from the above list of bases that were recently extended, which need to be initialized for exponents > 160 digits. I'm working on those now. 
[QUOTE=gd_barnes;608904]Bases 20 thru 30 have now been completely initialized for all recently added exponents all sizes. This only leaves bases 31 thru 40 from the above list of bases that were recently extended, which need to be initialized for exponents > 160 digits. I'm working on those now.[/QUOTE]
All bases for all parities and sizes have now been completely initialized for all recently added exponents. This includes bases 20 thru 40, 288, 338, 385, 392, 1058, 1152, 1155, and 1250. 
Page updated, but only to add 3 bases, nothing more.
I didn't have enough time ! Many thanks to all for your help. [B]Added bases : 239, 241 and 306.[/B] While waiting for a total update in a few days... 
[QUOTE=gd_barnes;608705]I have terminated the following sameparity sequences:
239^53, 239^55, 239^57, 239^63, & 239^67 241^53, 241^55, 241^57, & 241^59[/QUOTE] It looks like it was missed that I was the one who terminated these. :) 
I added 1400+ terms to 13^50. It may now be turned pink on the page, at 163 digits and a fullyECMed C155.

Yoyo terminated 22^67

[QUOTE=gd_barnes;608943]It looks like it was missed that I was the one who terminated these. :)[/QUOTE]
I'm sorry, I must have put the wrong acronym in the last update. I will fix it in a few days at most. 
[QUOTE=VBCurtis;608984]I added 1400+ terms to 13^50. It may now be turned pink on the page, at 163 digits and a fullyECMed C155.[/QUOTE]
Congratulation ! You have pushed the calculations very far. Just for my information, in your opinion, how long should a CADONFS factorization of this C150 cofactor take with a 128thread microprocessor ? I have such a machine at my disposal for 2 days to do tests and I launched a factorization of the c155 of the 27000 sequence of the main project (index 2046), but also of this project, because 27000=30^3. Of course, the cofactor is ECM'd ! 
[QUOTE=gd_barnes;609199]Yoyo terminated 22^67[/QUOTE]
A no matched parity sequence that ends becomes a rare event ! 
Here is a general summary of the work I've done since the last page update:
***** TL ; DR: 1. All bases on the project have had their sameparity exponents initialized if their beginning size is <= 160 digits. It will soon be for all sameparity exponents with beginning size <= 180 digits. 2. Quite a few bases have had their oppositeparity exponents initialized where they weren't previously. ***** (A) Bases that had their exponents extended: Bases 20 thru 40, 288, 338, 385, 392, 1058, 1152, 1155, & 1250: 1. All newly added exponents of both parities are initialized regardless of size. 2. All oppositeparity exponents that did not appear previously initialized (regardless of size) were searched to the above initialized criteria. Searched bases were 24, 28, 385, & 1155. That's the small stuff. :) (B) Bases <= 75: All open sameparity exponents with beginning size of <= 180 digits have been initialized. This involved quick ECM on many exponents but on others the search went long enough to terminate them. (C) Bases 200 thru 400: 1. All oppositeparity exponents that did not appear previously initialized (regardless of size) were searched to the above initialized criteria. Most bases that were not double a square were searched. In this area, generally if an exponent had <= 4 iterations, I considered it not initialized. 2. All open sameparity exponents with beginning size of <= 180 digits have been initialized. (D) All bases not in (A), (B), and (C) above: All open sameparity exponents with beginning size of <= 160 digits have been initialized. A large majority of bases had advancements in some exponents. Ongoing: Continue on (B) to initialize all sameparity exponents on the project with beginning size of <= 180 digits. Remaining: Bases 76 to 199, 400 to 1000, and > 1250. I expect to be done up to base 100 later today and with all bases within ~ 3 days. Definitions: 1. Initialization for oppositeparity exponents = Searched until a hard cofactor of C>=110 is found. For initialization purposes, a hard cofactor is defined as ECM'd to t35 unless the optimum is less than that. 2. Initialization for sameparity exponents = Same as above except cofactor of C>=115 if smallest factor=3 and C>=120 if smallest factor is > 3. Additional details of specific bases and exponents affected can be provided. 
Thank you very much Gary for all this work !
I think the best time to do the full update will be the weekend between July 14 and 17. I don't know how long it will take with all the blockages. I will try to work while logged in as well to see if it changes anything. At the moment I am perfecting my programs, but not only those related to the n^i project. I'm working on [URL="https://www.mersenneforum.org/showthread.php?t=26975"]suli.sage[/URL] in particular. I'm also going to do my first tests of data analysis on small samples to see if everything is OK. 
[QUOTE=garambois;609208]Just for my information, in your opinion, how long should a CADONFS factorization of this C150 cofactor take with a 128thread microprocessor ?
I have such a machine at my disposal for 2 days to do tests and I launched a factorization of the c155 of the 27000 sequence of the main project (index 2046), but also of this project, because 27000=30^3. Of course, the cofactor is ECM'd ![/QUOTE] C155 factoring time by cadonfs with 128 threads : 23 hours 40 minutes. Does this seem like a reasonable time ? 
In general, yes. It depends on the exact hardware, though.

[QUOTE=kruoli;609329]In general, yes. It depends on the exact hardware, though.[/QUOTE]
OK, thank you very much for the information. It was to know if I am using cado effectively, as I will get such a machine dedicated to aliquot sequences in a few months. 
[QUOTE=garambois;609262]C155 factoring time by cadonfs with 128 threads : 23 hours 40 minutes.
Does this seem like a reasonable time ?[/QUOTE] For comparison: I have recently acquired a Ryzen 5950X. Running at factory speed with DDR43200 memory, I can factor a C135 in 4 hours. I haven't yet attempted a C150, but it projects to take 2428 hours on that 16core CPU. A 64core machine is likely to run at around 2/3 the Ghz, something around 2.5x the speed of my 5950X. So, I would estimate a C155 to take on the order of 2025 hours. Your timing data seems fine, then. It's notable that it is now under a day for a (large, expensive) single machine to crack numbers of 512 bits size. 
All times are UTC. The time now is 10:16. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2022, Jelsoft Enterprises Ltd.