I'll reserve 9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999.


I'll start on it in 2-3 years when my current prime searches are done.


:smile:

12^100, 12^102, and 12^108 all terminate after short runs. :smile:

I tested all of n=12 up to size 102 and cofactor 97 (fully ECM'd). Here are the updates:

12^7: 1532 U107 (100) +26 iterations
12^9: 1173 U103 (97) +143
12^13: 968 U103 (102) +137
12^17: 1059 U103 (99) +122
12^23: 1034 U109 (103) +10
12^25: 1040 U104 (102) +248
12^27: 1018 U102 (97) +110
12^31: 480 U112 (103) +38
12^33: 518 U103 (101) +30
12^37: 886 U105 (98) +36
12^39: 1032 U103 (101) +190
12^41: 2279 U104 (101) +130
12^45: 578 U104 (101) +39
12^49: 175 U106 (98) +4
12^51: 1575 U102 (97) +85
12^53: 596 U108 (103) +122
12^55: 224 U106 (103) +76
12^57: 632 U103 (100) +88
12^59: 1105 U102 (100) +200
12^61: 2340 U103 (100) +9
12^63: 271 U103 (102) +98
12^65: 201 U102 (99) +155
12^69: 302 U103 (97) +260
12^81: 47 U103 (100) +14
12^83: 110 U102 (100) +15
12^85: 322 U102 (97) +74
12^87: 72 U102 (99) +63
12^89: 65 U107 (97) +54
12^91: 411 U105 (99) +409
12^93: 21 U102 (98) +16
12^95: 32 U107 (106) +25
12^97: 32 U108 (97) +30
12^99: 10 U107 (105) +8
12^101: 29 U114 (112) +18
12^107: 7 U116 (116) +5

Many of these were already updated before I reported them.

I am now working on all of n=13 testing to the same limit. I'll be done in ~2-3 days.

No reservations.

13^97, 13^99, 13^105, and 13^107 all terminate after short runs. :smile:

OK, all is updated !

A special thank you to Karsten Bonath who once again provided scripts to make changes.

Thanks to all for your help !
Thanks to all for checking if the changes corresponded to your expectations !

[QUOTE=Happy5214;501329]I'll reserve 21, but I won't start work on it until my current batch of sequences is done.[/QUOTE]

Happy5214, I don't understand what you're asking ?
Do you want to reserve the base 21 which is not yet created ?

:smile:

10^116 terminated

10^118 terminated

I tested all of n=13 up to size 102 and cofactor 97 (fully ECM'd). Here are the updates:

13^12: 659 U108 (105) +28 iterations
13^18: 961 U107 (97) +21
13^20: 1014 U102 (99) +22
13^22: 771 U103 (97) +45
13^24: 351 U109 (101) +52
13^26: 854 U107 (97) +56
13^28: 634 U103 (98) +3
13^32: 2814 U102 (100) +1864 (a wild ride!)
13^34: 1227 U106 (99) +76
13^36: 940 U104 (98) +24
13^40: 1685 U107 (102) +79
13^42: 306 U103 (100) +25
13^44: 803 U109 (100) +68
13^46: 248 U107 (97) +32
13^48: 1116 U102 (99) +55
13^50: 1216 U105 (104) +128
13^52: 242 U106 (103) +97
13^54: 352 U106 (101) +45
13^56: 607 U107 (104) +66
13^58: 1241 U104 (98) +96
13^60: 290 U105 (101) +46
13^62: 1322 U114 (106) +54
13^64: 921 U105 (101) +40
13^66: 315 U102 (100) +50
13^68: 241 U104 (98) +115
13^70: 352 U105 (99) +51
13^72: 55 U102 (98) +9
13^74: 1874 U111 (104) +1616
13^76: 323 U104 (99) +64
13^78: 95 U103 (100) +26
13^80: 1189 U107 (99) +35
13^82: 288 U103 (98) +62
13^84: 69 U103 (101) +50
13^86: 122 U104 (101) +119
13^88: 31 U102 (97) +25
13^90: 20 U102 (100) +13
13^94: 244 U106 (103) +235
13^98: 3 U108 (103) +1
13^102: 10 U113 (98) +4
13^104: 3 U116 (98) +1
13^106: 11 U115 (100) +9

Many of these were already updated before I reported them.

I am now working on all of n=439 testing to the same limit. I'll be done in ~1-2 days.

No reservations.

I have run 23^8 for rather longer than it probably deserves

10^120 terminated

OK, everything is updated, except for 23^8.

Thank you all !

Thank you especially to Karsten Bonath who fixed a bug !

fivemack, would you like me to create base 23 ?
Do you want to make calculations on this base ?
Otherwise, the results will not be lost, because sooner or later, we will create this base...

Thanks

Tried to download seqs from factorDB an found this:
3^108 got an error at index 1575:
is:
[code]
1574 . 10536346489696420770680 = 2^3 * 5 * 19 * 23 * 919 * 3067 * 423931 * 504457
1575 . 15539970862145288285320 = 2^3 * 5 * 11 * 23 * 1753 * 15733 * 55677051589
1576 . 24287246194437618095480 = 2^3 * 5 * 7 * 31 * 2861 * 7489 * 130592086759
[/code]

should be:
[code]
1574 . 10536346489696420770680 = 2^3 * 5 * 19 * 23 * 919 * 3067 * 423931 * 504457
1575 . 15540084064757285981320 = 2^3 * 5 * 23 * 181 * 593 * 594161 * 264867167
1576 . 21208836326841958327160 = 2^3 * 5 * 47 * 11281295918532956557
[/code]

Perhaps there're more errors there after last offline/update, only checked for n=2 and 3 yet.

I tested all of n=13 up to size 102 and cofactor 97 (fully ECM'd). Here are the updates:

439^6: 286 U110 (104) +32 iterations
439^10: 822 U103 (99) +38
439^14: 671 U106 (104) +40
439^16: 1489 U108 (101) +1236
439^18: 336 U105 (97) +218
439^20: 2153 U103 (101) +1
439^22: 2069 U104 (97) +1946 (A very wild ride!)
439^24: 230 U105 (97) +160
439^26: 373 U104 (101) +299
439^28: 407 U103 (97) +92
439^30: 80 U106 (99) +5
439^32: 421 U125 (123) +6
439^38: 35 U103 (98) +26
439^40: 13 U104 (100) +11
439^42: 15 U114 (109) +8
439^46: 34 U120 (107) +31


All done with that task. I'm now going to work on some downdrivers. :smile:

My first "real" termination here:


13^98 terminates at term 1448 with prime=43 after starting at 110 digits!



:smile::w00t::wacky:

[QUOTE=kar_bon;501789]Tried to download seqs from factorDB an found this:
3^108 got an error at index 1575:
is:
[code]
1574 . 10536346489696420770680 = 2^3 * 5 * 19 * 23 * 919 * 3067 * 423931 * 504457
1575 . 15539970862145288285320 = 2^3 * 5 * 11 * 23 * 1753 * 15733 * 55677051589
1576 . 24287246194437618095480 = 2^3 * 5 * 7 * 31 * 2861 * 7489 * 130592086759
[/code]

should be:
[code]
1574 . 10536346489696420770680 = 2^3 * 5 * 19 * 23 * 919 * 3067 * 423931 * 504457
1575 . 15540084064757285981320 = 2^3 * 5 * 23 * 181 * 593 * 594161 * 264867167
1576 . 21208836326841958327160 = 2^3 * 5 * 47 * 11281295918532956557
[/code]

Perhaps there're more errors there after last offline/update, only checked for n=2 and 3 yet.[/QUOTE]

What can we do about it ?
Is it possible to correct this on DB ?




Thanks gd_barnes, I will update the next weekend.

OK, the page is updated.
Thank you all.

Base 21 added and reserved by Happy5214, in accordance with its request.

21^4 merges at index 46 with seq. 6552:i4

In the larger sequences that begin at > 105 digits, I found several down drivers. I ran those until they were gone. Many had very wild rides. One terminated. Here are the updates:

10^109: 587 U115 (109) +582 iterations
10^113: 455 U104 (97) +451
10^117: 1215 U108 (105) +1211
12^107: 1378 U107 (99) +1371
12^109: 333 U112 (109) +331
13^98: 1448 U2 (2) +1445 (terminated as previously reported!)
13^106: 171 U103 (101) +160

Most of these were already updated before I reported them.

11^66 reached 120 digits, added 3031 lines, driver 2*3

OK, the page is updated.
Thanks to all.

Note :

By me, 3^152, 3^154, 3^156, 3^162, 3^168 at 120 digits or more.
3^164 terminated after 2595 iterations at a P3.

:smile:

Now, in the power table of 3, we can see an isolated white cell : 3^108.
kar_bon had reported this error on DB, a few posts above.

I don't understand what's going on.
I restarted the calculation on my computer, my program is not wrong though !

I don't know how to correct the mistake !

:confused2:

[QUOTE=garambois;502883]I don't know how to correct the mistake ![/QUOTE]

You can't do anything here, Syd has to correct the database entry.

I've attached the corrected ELF-file for seq. 3^108: it's at 122 digits now with 2^6 * 127 driver.

To handle this in the scripts:
- copy the "108.htm" from the zip into the 3-folder (it's not correct in the factorization but in digits/index count)
- insert "rem " in front of the line for 108.htm in the "run4_get.bat" to suppress the download for this seq. (change again after calling "run3_make_download.bat")
- create data for this n as usual

If Syd corrected the database, everything will fine again.

11^36 and 11^42 done to >120digits

Taking 13^12 for a spin.

OK, thanks to kar_bon and VBCurtis !
Page updated.
My own calculations : 3^150, 3^174, 3^176 and 3^182 up to 120 digits.



[QUOTE=kar_bon;503066]You can't do anything here, Syd has to correct the database entry.

I've attached the corrected ELF-file for seq. 3^108: it's at 122 digits now with 2^6 * 127 driver.

To handle this in the scripts:
- copy the "108.htm" from the zip into the 3-folder (it's not correct in the factorization but in digits/index count)
- insert "rem " in front of the line for 108.htm in the "run4_get.bat" to suppress the download for this seq. (change again after calling "run3_make_download.bat")
- create data for this n as usual

If Syd corrected the database, everything will fine again.[/QUOTE]

Thank you very much kar_bon.
But I think I'll leave it like that.
That way, I'll see when the error is corrected by Syd.

How did you find this error ?
You downloaded all the .elf files and checked if the prime factors were the right ones ?
You verified only for n=2 and n=3, right ?
Has the verification for the n>3 not yet been done ?
I will try to write a Sage program to continue the checks for n>3.
I think I can write this program, but DB will cut the data transmission too massive and I will certainly have to do the checks in several steps...

[QUOTE=garambois;503647]How did you find this error ?[/QUOTE]

As you remember. I've made a copy of "SEQAll.txt" to "SEQAll1.txt" by the script, to find differences from the last update. Checking this after downloading all open seqs and running the read-script, I compared them (easy by TotalCommander). I noticed the index of the older entry was higher than the current one, so I had a closer look at it.
Sure the perfect way to check everything is to download and check all elf-files from FactorDB.
I think there're other errors like this, perhaps not for your project but not for sure.

Thanks kar_bon !

I spent several hours writing an independent program to check the aliquots sequences on FactorDB. And my program works very well.
It downloads all the .elf files and checks each index of the aliquot sequences and each passage to the next index.
I ran the program for each base of the project n^i.
The program found only one error on FactorDB : the one already known, 3^108 at index 1575.
There are no other error for any base !
I will restart the verification in a few months....

There was no interruption due to FactorDB when the program ran !

:smile:

Great work!
This should be done with all aliqout sequences sometime, to be sure there're no others errors in FactorDB.
The worst case could be a false termination/merge that never could be found if nobody is testing the ELF files.
Over the last years once in a while there were several false seqs like 3^108.

I could run the program for all aliquots suites from 1 to 10^6.

But, the problem is the time it takes to download .elf files for aliquots sequences. Typically, for 251 aliquots sequences (3^i for i from 1 to 251), it took about two hours !
It is therefore not feasible to test for example all aliquots sequences from 1 to 10^6, it would take several months, even a whole year !

And we would have to do the work beyond 10^6 !

For the blue page that is tracking progress of sequences <3e6 I modified the [URL="https://github.com/ChristianBeer/aliqueit"]aliqueit[/URL] program to check elf files from FDB when a merger or termination is detected. That way we make sure to only delete sequences from the blue page that are verified mergers or terminations. I thought about running this check for all previously finished sequences where we didn't have this tool available but I hope that such a functionality can be built into FDB directly also to avoid broken sequences like 3^108 that happen regularly when the sequence cache gets rebuild.

@Happy: One of the sequences in base 21 reserved by you merges with some 4-starter which is at ~170 digits, reserved (and worked regularly) by Tom. In fact, none of your sequences seem to progress at all. Were you serious about reservation, or just joking? (like "when I finish the current work" can also be next century :razz:)

[QUOTE=LaurV;503942]@Happy: One of the sequences in base 21 reserved by you merges with some 4-starter which is at ~170 digits, reserved (and worked regularly) by Tom. In fact, none of your sequences seem to progress at all. Were you serious about reservation, or just joking? (like "when I finish the current work" can also be next century :razz:)[/QUOTE]

I have no sense of humor. The (then-)current work is now finished, and I've started on 21^10. I have a slow computer by most aliquot-crunching standards (I got it in 2009), but I do have the remaining open base 21 sequences up to 21^30 queued (except the aforementioned 21^4, which I do not intend to advance).

Hm, sorry if I offended you in any way, I was just making sure that you don't spend your time crunching the 170 digits sequence (as it appeared reserved by you) doubling fivemack's work and wasting your resources - crunching that sequence takes a lot of time, and could justify why there was no progress elsewhere. And of course, if I commented, I could not stop myself of pushing a bit and making a bit of fun. But it was no intention to offend.

OK, updated web page.

My own calculations: 3^166, 3^172, 3^180, 3^184 and 3^186 up to 120 digits.

@LaurV
I noticed that you calculated 4 aliquot sequences over 140 digits !
It's a huge job !
:tu:
Have you checked, however, that there is no merges with other aliquot sequences ?

Thank you all !

I was actively working bases 6 and 28 over the holiday, and didn't stop yet. No merges popped up, beside those 3 already shown in your site, and you will remark that I reserved those 3 too on the aliquot reservation thresd (and on the blue page, all 3 were unreserved). I currently have 20 cores on base 28, 10 of them crunching "from the end" and 10 crunching from the beginning of the table.

Reserving new base 14 all exponents to at least size 102, cofactor 97.

OK, updated web page.

My own calculations: 3^178, 3^190, 3^192, 3^194 and 3^200 up to 120 digits.

@gd_barnes
Base 14 added and reserved for you.
I found a merge for 14^7 but not for 14^13 !

@all
Don't forget to check the mergers.

Thank you all !

14^13:i262 = 167748:i33

Thank you Karsten.
I'm going to review my way of identifying mergers !

You updated a few hours too soon! :smile:

I started on base 14 late yesterday. My plan was to post an update today. Here it is:

All even exponents <= 104 have terminated.

Odd exponent merges:
14^7 term 21 merges with sequence 2484 term 9 with a value of 106640
14^13 term 262 merges with sequence 167748 term 33 with a value of 5933240

Odd exponent non-trivial terminations:
14^5 terminates at term 3478 with P=43 after reaching 88 digits
14^9 terminates at term 373 with P=59 after reaching 23 digits
14^19 terminates at term 378 with P=7 after reaching 30 digits
14^21 terminates at term 339 with P=7 after reaching 25 digits
14^23 terminates at term 362 with P=43 after reaching 32 digits
14^25 terminates at term 225 with P=43 after reaching 30 digits

All open sequences with exponents <= 26 have reached size >= 102 and cofactor >= 97.

I'll post a final status update when I am complete with the base. Perhaps 3-6 days.

14^31 term 1396 merges with sequence 65208 term 6 with a value of 1619928. :smile:

14^35 and 14^37 both non-trivially terminate. :smile:

Base 14 is a prolific base for terminations and merges.

The run of terminations continues.

14^45 terminates.

Really beautiful !
I will wait a few days before updating the page.... during the next weekend.
Then the situation will have stabilized.

:smile:

Base 14 all exponents <= 104 is complete to at least size 102, cofactor 97. Highlights:

All even exponents have terminated.

Merges as previously posted:
14^7, 14^13, and 14^31

Odd exponent terminations as previously posted:
14^5, 14^9, 14^19, 14^21, 14^23, 14^25, 14^35, 14^37, 14^45

Additional termination:
14^57 terminates at term 664 with P=1429 after reaching 80 digits.

The base is released.

This was a prolific base. 64 / 104 exponents terminated = 61.5%. It is the 2nd best base > 2 so far searched. Stats:
Base 28: 51 / 82 = 62.2%
Base 14: 64 / 104 = 61.5%
Base 11: 68 / 115 = 59.1%

Base 14 just missed 1st place when 14^91 starting at 105 digits dropped all the way to 17 digits before returning to its original height. Perhaps bases divisible by 7 or 14 have naturally more terminations than the others. :smile:

I'm still plugging away at 439^34.

I added some iterations to some larger sequences that did not have drivers. Here are the updates:

5^154: 19 U109 (102) +15 iterations
6^127: 31 U106 (101) +9
6^129: 27 U106 (106) +22
6^137: 15 U108 (104) +12
7^122: 43 U107 (103) +35
10^107: 20 U106 (106) +9
12^83: 127 U107 (104) +17
12^87: 137 U109 (99) +65
12^103: 14 U114 (99) +10
13^104: 21 U118 (110) +18
13^106: 184 U105 (101) +13
439^38: 52 U106 (103) +17
439^40: 39 U105 (103) +26

Many still do not have drivers. :smile:

No reservations.

I was wondering why nobody took upon themselves to test 82589933^x...
well...
82589933^1 is prime
82589933^2 immediatelly merge with 82589934
82589933^3 terminate quickly at 29
82589933^4 merge with 563353953758481254763660
82589933^5 terminate 34789944176815817522021
... well it seems that even power always merge immediatelly and odd terminate...
I should have know

Garambois, I noticed that for all bases 2 < b < 15 you included all exponents up through and including one final exponent with a size of > 120 digits.

Would it make sense to do the same for bases 21 and 28? :smile: The final exponent that you have shown for those bases only makes a sequence of size 119 digits. If you agree, then 21^91 and 28^83 would need to be added.

To make it easy, I quickly searched both sequences. Results are as follows:
21^91 is trivial and fairly quickly terminated.
28^83 hit a hard C113 after 6 iterations so I stopped there.

Perhaps LaurV would like to add 28^83 to his reservation since he has the base reserved.

[QUOTE=gd_barnes;505575]
Perhaps LaurV would like to add 28^83 to his reservation since he has the base reserved.[/QUOTE]
Yes please! :)

OK, page updated !

Thank you to all.
Thank you to Karsten Bonath, because I didn't know how to do to add some exponents to a base !

Exponents 91 and 83 added for bases 21 and 28.

My own calculations :
3^198 non trivial termination.
3^188, 3^196, 3^198, 3^202, 3^206 up to 120 digits.
3^204 at index 1060 merges with 4788 at index 6.
Reminder : 7^96 at index 1267 merges with 4788 at index 6 too !!!

[QUOTE=firejuggler;505552]I was wondering why nobody took upon themselves to test 82589933^x...
well...
82589933^1 is prime
82589933^2 immediatelly merge with 82589934
82589933^3 terminate quickly at 29
82589933^4 merge with 563353953758481254763660
82589933^5 terminate 34789944176815817522021
... well it seems that even power always merge immediatelly and odd terminate...
I should have know[/QUOTE]


A priori, I don't see anything special in the behavior of aliquot sequences starting on exponents of the prime number 82589933.
Do you want to book the base 82589933 ?

:smile:

Congrats on the nice termination for 3^198 ! :smile:

You can release base 14 for me.

Reserving base 15 all exponents to at least size 102, cofactor 97.

Here are some highlights for some of the smaller exponents so far:

Merges:
15^4 term 3 merges with 3432 term 69 with value 73444
15^8 term 77 merges with 147150 term 7 with value 4458100
15^18 term 98 merges with 81600 term 354 with value 230896

Non-trivial terminations:
15^6 terminates at term 74 with P=41 after reaching 8 digits
15^10 terminates at term 152 with P=7 after reaching 12 digits
15^14 terminates at term 392 with P=43 after reaching 22 digits

It should be done in a few days.

I'll get 82589933 upto C105 and upto ^50, as I have not much ressource.
As for detecting merge.... i do not know how beside checking number by number.

edit because I'm an idiot who can't count! upto ^17

Base 15 has some additional merges and a termination:

Merges:
15^28 term 976 merges with 81084 term 14 with value 931324
15^42 term 819 merges with 3366 term 2 with value 5940

Non-trivial termination:
15^36 terminates at term 2757 with P=59 after reaching 108 digits :smile:

I will report any additional merges or terminations when I am done with the base.

Unreserving 11^12.

Base 15 all exponents <= 102 is complete to at least size 102, cofactor 97. Highlights:

All odd exponents have terminated.

Merges as previously posted:
15^4, 15^8, 15^18, 15^28, and 15^42

Even exponent terminations as previously posted:
15^6, 15^10, 15^14, and 15^36

Additional termination:
15^22 terminates at term 1375 with P=1361 after reaching 65 digits.

New cycle:
15^74 terminates in a cycle at term 1705 with C=6 after reaching 88 digits.

The base is released.

OK, page updated.
Thank you to all !

Bases 15 and 82589933 added.

@gd_barnes :
Bases 14 and 15 released.
I replaced
15^8 term 77 merges with 147150 term 7
by
15^8 term 77 merges with 147150 term 17
:tu:

My own calculations :
3^232 up to 120 digits.
Poor week for my calculations, only aliquot sequences with drivers like 2^2 * 7 !

Some additional work done on base 15:

15^98 had a downdriver at a large size so I continued it. It dropped all the way to 9 digits and so narrowly missed a merge. I added 1048 terms to it. It is now at i=1070, size 106, C97.

15^103 trivially terminated after a short run.

No more work to be done on base 15.

I have nominated myself as the "consistency police". :smile: I noticed that all except a few of the bases > 2 have all exponents listed up thru and including the first trivial exponent > 120 digits. Only bases 12, 28, and 439 are missing that final trivial exponent.

Based on this, I trivially terminated the following sequences:
12^112
28^84
439^47

Would it make sense to go ahead and add these to the page? I suggest it because I think it will be interesting to show percentage of exponents terminated/cycled by base in the future to look for patterns. To do this accurately, all bases would need a consistent stopping point.

6^113 terminates after reaching 103 digits.


:smile:

I extended many unreserved sequences that did not have drivers -or- had a small cofactor. Several had substantial extensions. Here is a list of the extended sequences:

5^124
6^53
6^83
6^99
6^101
6^113 (Terminated as previously reported!)
6^119
6^123
6^125
7^82
7^88
7^98
7^106
7^116
10^51
10^75
10^89
10^93
10^95
10^97
11^72
12^63
12^69
12^71
12^93
13^42
13^48
13^50
13^78
13^88
14^77
15^44
15^82
15^88

If any more info is needed, let me know.

No reservations.

Most (all) unreserved sequences without drivers should be at >= 105 digits now. :-)

OK, page updated.
Thank you to all and especially to gd_barnes.

@gd_barnes :
12^112 added
28^84 added
439^47 added
You're right, it's much cleaner like this !
:smile:
Congratulations for the non-trivial calculation of 6^113.

My own calculations :
3^210-216-218 up to 120 digits. Last week, it was 3^212 and no 3^232 of course !
And (10^10+19)^15 trivially terminated after a few days.

Since the project goal is to search these sequences to 120 digits, I loaded up all remaining unreserved sequences that were at 118 or 119 digits and searched them to >= 120 digits. Here they are:

5^168
5^170
6^151
7^140
11^114
13^104
14^103
15^100

No reservations.

Now you can add a little more color to the page. :smile:

Hi, I noticed that in sequence 3^108, in factordb, the 1575th term is wrong. Can somebody correct it?


It should be 15540084064757285981320 instead of 15539970862145288285320.


I've written the factordb thread.

82589933^2 reached 120 digits, 2^2*7 driver, C111
82589933^4 reached 120 digits, 2^4*3, reached 2^8*3^2 during its course, C107
82589933^6 reached 126 digits, 2^3 *3^2, C109
82589933^8 reached 103 digits,2*3 driver
82589933^10 reached 109 digits, 2^5*3*7 , C100
82589933^12 reached 107 digits 2^3*3^3, C101
82589933^14 reached 105 digits, 2*3 driver, C101
82589933^16 reached 122 digits, 2^4 * 3 * 7, C118


relasing 82589933^2 and 82589933^4. Will probably work a few more iteration on 82589933^6, will continue work on others.

An extension to my most recent post: I loaded up all remaining unreserved sequences that were at 116 or 117 digits and searched them to >= 120 digits. Here they are:

5^166
6^147
6^149
7^58
7^138
10^115
11^100
11^110
14^99
14^101

All previous size >= 116 sequences are now at size >= 120 digits. (except reserved base 3)

No reservations.

More color for the page. :smile:

[QUOTE=ricky;507248]Hi, I noticed that in sequence 3^108, in factordb, the 1575th term is wrong. Can somebody correct it?


It should be 15540084064757285981320 instead of 15539970862145288285320.


I've written the factordb thread.[/QUOTE]


Yes, I also reported this error here :

[URL="https://www.mersenneforum.org/showthread.php?t=19737&page=3"]https://www.mersenneforum.org/showthread.php?t=19737&page=3[/URL]

And Karsten Bonath here :

[URL="https://www.mersenneforum.org/showthread.php?t=23612&page=10"]https://www.mersenneforum.org/showthread.php?t=23612&page=10[/URL]

Hopefully someone can fix it !

OK, page updated.
Thank you to all.
There are indeed a few more colors on the page !

My own calculations :
3^208-214-222-224 up to 120 digits.

That's right, the project goal is to search these sequences to 120 digits.
Ideally, all cells should be green.
But it is not physically possible to push the calculations so far in a reasonable time. 120 digits is a good compromise.
I noticed that LaurV is pushing the calculations a lot further !
Congratulations !

:tu:



It is only for base 2 that we can have green cells for all powers ! What would be extraordinary would be to find an aliquot sequence starting on a power of 2 and that would be Open-End ! You've all noticed that powers of 2 go up to 500. The calculations become very long. I will continue these calculations to turn all the cells green.
Then, I think it will be very interesting to extend the powers beyond 500.
If someone wants to calculate the aliquot sequences that start with 2^501, 2^502 or more, he can already book them. We are sure that these aliquot sequences will go down to a prime number, because from the first iteration, we must obtain odd numbers.
EXCEPT if further on, we had to have a big surprise and if we had to find an even term during the calculations, and then if we had to have terms with a driver !

:smile:

[QUOTE=richs;505433]I'm still plugging away at 439^34.[/QUOTE]

Dropping 439^34 after adding over 2100 terms. Current C115 cofactor at i2124 is fully ECM'ed.

OK, page updated.
Thank you to all.

My own calculations :
3^220-226-230 up to 120 digits.

The next update will be done on the weekend of February 23rd and 24th.

Reserving 439^18

OK, page updated.
Thank you to all.

My own calculations :
2^500 finished on a P29.
The calculations for the powers of 2 are very long !

Taking 13^18 and 13^20.

.. that was quick.
Unreserving 13^18. The C120 cofactor has been ECMed to t35, nearly enough.
I have a new appreciation for the power of 2^3*3*5 to rapidly drive a sequence.

OK, page updated.
Thank you to all.

My own calculations :
2^496 finished on a P146 !!!

OK, page updated.
Thank you to all.

My own calculations :
2^492 not yet finished despite 8 threads constantly calculating on it !

13^12 released.
162 digits, C160 that withstood 2t45 ECM.
2^3*3*5 driver, thing went straight up after a nice downdriver run.

Taking 13^22.

[QUOTE=VBCurtis;509654]I have a new appreciation for the power of 2^3*3*5 to rapidly drive a sequence.[/QUOTE]
"Never underestimate D3!"

(it was my motto here for a while, some time ago)

[QUOTE=VBCurtis;510998]13^12 released.
162 digits, C160 that withstood 2t45 ECM.
[/QUOTE]

162 digits !!!
Thank you...

Please, have you checked if there is a merger ?

Doesn't factordb do that automatically when the sequence is updated?
I did nothing to check for a merger.

Yes, FactorDB do that automatically when the sequence is updated.

But it is then time to report it to me so that I can post it on my own web page.

It is quite easy to see if FactorDB has merged the sequence with another one he already knew. If, for example, you have done the calculations up to 120 digits on your computer and you report your results in FactorDB, and if FactorDB suddenly indicates that the aliquot sequence goes up to 162 digits, it means that there has been a merger. On the other hand, if you have done the calculations yourself up to 162 digits and you report the sequence in FactorDB, and you find that the last term of the sequence in FactorDB is the same as the last term of your own calculation on your computer, there has been no merging.

If there has been a merger, then we have to find with which sequence did this happen. Sometimes it can be a little laborious... at least for me !

I see. No merger, then- I did all the factoring myself up to 162 digits, no magical factorDB jump!

Thank you !
So I don't have to look with which sequence there is a merging for sequence 13^12.

I know how to do if there is a merging with a sequence that starts on a number less than 3*10^6, thanks to the explanations of kar_bon and thanks to this page : [URL="https://www.rechenkraft.net/aliquot/AllSeq.txt"]https://www.rechenkraft.net/aliquot/AllSeq.txt[/URL]
But to find the mergers with the other FactorDB sequences already calculated, which start with numbers greater than 3*10^6, I don't know how to do it !

W.Creyaufmüller gave some [url='http://www.aliquot.de/aliquot.htm#Datenbanken']lists[/url] with C9/C30/C60/C80 indices of ali-seqs: so if a seq. drops down to a C25, you could look when it reaches C30 again, if this C30 was reached by another seq. Only problem is, those data files are very outdated.

To keep current, every open seq has to be scanned about those say C30/C60 values and generate this new list.
This is independent of only the last index of a seq. like in AllSeq.txt, where those last values could differ because of only updating a small amount of all open seqs.

It would indeed be very useful to have a recent list for the C30 and C60 of all numbers generating OE sequences up to at least 10^7 !
But how can FactorDB be efficiently scanned to achieve this ?

In addition, there can be a multitude of C30s or C60s for a single OE sequence that "plays the yo-yo" !
For example, if a sequence encounters a C60, if it then goes up higher and goes down to 60 digits afterwards, it will be necessary to store this second C60 in the list. Because, if there is a fusion of another sequence with this one, there is no guarantee that the fusion will take place before the first C60. This can happen later. The list must always show the last C30 and C60 given by FactorDB.

(I hope my message is clear with my bad English !)

The only way I see is to download all ELFs from open seqs and run a script over these files, scanning for those C30/C60. And perhaps all occurences of a (upgoing) C60 is relevant, not only the last one in a sequence.
Example: [url='http://factordb.com/aliquot.php?type=1&aq=158814&big=1']158814[/url] -> C60's at index 934, 2200 and 2722
So a merge could happen (before) the first C60 but you only be aware until the last C60, ~1800 indices later if only the last C60 will be listed.

I have my own 10, 12, 15, 20, 30, 50, 80 digits lists. That is the first x digits number that some sequence reach, for which I store the "smallest starter" and the "longest sequence". They are huge files, but they can be shared if someone needs. Better is if you have trouble finding a merge, post it and I may help...

[QUOTE=garambois;511121]In addition, there can be a multitude of C30s or C60s for a single OE sequence that "plays the yo-yo"[/QUOTE]
You always store the first. In fact, there are no merges "so high", all merges happen at very low digit count. The reason to store higher lists (people use to keep 80 and 100) is that the search is easier (less items in the list). Low-digits lists are huge. If two sequences "play yo-yo", there is still a "lowest point" where they merge, which is then (after raising) the "first" reach. It doesn't make sense to store all crosses. For example, you have two sequences that reach 10, 20, 30, 40 digits without merging, you will have stored one number for each, at 10, 20, 30, etc. If then both drop and merge, if at least one of them dropped below 7 digits, then the next 10-digits cross is already in the list, from the sequence starting with the last drop. If they drop no lower than 9 digits, then merge, and raise back (as one sequence) to10, 20, 30, 40, you will not detect this, as the new cross into the 10, etc, will not be recorded, because there is no record for sequences starting with 9 or more digits. But immediately when they cross to 50 digits, it will be detected (and recorded).

[QUOTE=kar_bon;511140]The only way I see is to download all ELFs from open seqs and run a script over these files, scanning for those C30/C60. And perhaps all occurences of a (upgoing) C60 is relevant, not only the last one in a sequence.
Example: [url='http://factordb.com/aliquot.php?type=1&aq=158814&big=1']158814[/url] -> C60's at index 934, 2200 and 2722
So a merge could happen (before) the first C60 but you only be aware until the last C60, ~1800 indices later if only the last C60 will be listed.[/QUOTE]

Finally, I agree with kar_bon. I am trying to explain again how I understood the argument of the message quoted above by kar_bon, to make sure I understood correctly.
The example I propose below with C30 remains valid with C60, or C20. But indeed, the problem is that the file size increases if the number of digits of C is smaller.

[U]Example :[/U]

Let's imagine a known S sequence stored in FactorDB:
index 200 : C30
index 1000 : C160
index 1800 : C30

1) I calculate a sequence S_1 on my own computer.
This sequence S_1 merges with S at index 190.
It is necessary to store the C30 of the index 200 of S, otherwise I have to calculate S_1 until the index 1800 to notice the fusion. It will take weeks !

2) I calculate a sequence S_2 on my own computer.
This sequence S_2 merges with S at index 1790.
It is necessary to store the C30 of the index 1800 of S, otherwise, if I have stored in my list only the first C30 of S, I will never notice the merging of S_2 with S.

Thanks to this example, I think we have to store all the C30s (or C20s or C60s... according to my choice) for an aliquot OE sequence from FactorDB.

[QUOTE=LaurV;511189]I have my own 10, 12, 15, 20, 30, 50, 80 digits lists. That is the first x digits number that some sequence reach, for which I store the "smallest starter" and the "longest sequence". They are huge files, but they can be shared if someone needs. Better is if you have trouble finding a merge, post it and I may help...[/QUOTE]

Thanks a lot !

[QUOTE=LaurV;511191]You always store the first. In fact, there are no merges "so high", all merges happen at very low digit count. The reason to store higher lists (people use to keep 80 and 100) is that the search is easier (less items in the list). Low-digits lists are huge. If two sequences "play yo-yo", there is still a "lowest point" where they merge, which is then (after raising) the "first" reach. It doesn't make sense to store all crosses. For example, you have two sequences that reach 10, 20, 30, 40 digits without merging, you will have stored one number for each, at 10, 20, 30, etc. If then both drop and merge, if at least one of them dropped below 7 digits, then the next 10-digits cross is already in the list, from the sequence starting with the last drop. If they drop no lower than 9 digits, then merge, and raise back (as one sequence) to10, 20, 30, 40, you will not detect this, as the new cross into the 10, etc, will not be recorded, because there is no record for sequences starting with 9 or more digits. But immediately when they cross to 50 digits, it will be detected (and recorded).[/QUOTE]

LaurV, I don't know I may have misunderstood your message, but it seems to me that you're saying that we have only to store the first C30 of FactorDB's OE sequences (But maybe I'm wrong !), is that right ?
For the reasons explained at the beginning of this post, I think, like kar_bon, that all the C30s (or C20s, or C60s...) in a sequence should be stored to establish the list that will allow us to find mergers efficiently.

OK, page updated.
Thank you to all.

My own calculations :
2^492 finished after three weeks of computation on it with 8 threads !

OK, page updated.
Thank you to all.

My own calculations :
2^491 and 2^498 finished !

In fact, I believe that in just a few weeks, I could put online an effective database to find aliquot sequence mergers, like Wolfgang Creyaufmuller's old database ([URL="http://www.aliquot.de/aliquot.htm#Datenbanken"]http://www.aliquot.de/aliquot.htm#Datenbanken[/URL]). This database would allow all mergers with all aliquots sequences of the Blue Page to be found, up to 3,000,000.

This database would be a text file like those attached to this post to give two examples (C_60 and C_60_80).

The best option should now be chosen :
1) Should [U]only all[/U] C60s be stored for each aliquot sequence [U]or only all[/U] C80s ([U]or only[/U] larger terms) for each aliquot sequences ? (only one file with C_60 for example)
2) Should [U]all[/U] C60s [U]and all[/U] C80s ([U]and[/U] possibly others) be stored separately, like attached file C_60 for example ? (several files for C_60, C_80...)
3) Should all C60s [U]and[/U] C80s ([U]and[/U] possibly others) be stored [U]on the same page[/U], like attached file C_60_80 for example ? (only one file with C_60, C_80... inside)

It would certainly be necessary to update this page at least once a year, which I could do.

Do you think this work would be useful for all us ?
Do I have to do it and with which options (1, 2 or 3 or another one I wouldn't have thought of ?)

OK, page updated.
Thank you to all.

My own calculations :
2^481, 2^483, 2^485, 2^487, 2^489 and 2^490 finished !
This week, I chose aliquot sequences that are easier to calculate !

:smile:

Drop 439^18
 

[QUOTE=richs;508333]Reserving 439^18[/QUOTE]

Dropping 439^18. Added over 1000 terms and now at 135 digits. The current C130 is ECM'ed to t25.

OK, page updated.
Thank you to all.

My own calculations :
3^228, 3^232 and 3^236 up to 120 digits.