The scripts only need small additions to create the whole html automatically for a new n-value, he knows the handling.

[QUOTE=kar_bon;547696]The scripts only need small additions to create the whole html automatically for a new n-value, he knows the handling.[/QUOTE]
Thanks! I'll quit pestering you guys about it.:smile:

I'm nearly finished coloring in the base 17 and base 8128 tables. Unless I read an objection, I'll try to meet the preliminary requirements (matched parity to prime and others to 100 digits) for base 496. I'm not sure about continuing with it after that, but we'll see.

Thank you all for your help. There has been tremendous progress in the last few weeks.

By next weekend, I will add bases 210, 496, 8128 and maybe one or two more for me if the preliminary calculations are completed by then (510510 and 9699690).

@ EdH : Thank you very much for your offer of help. But as Karsten Bonath says, I know all the manipulations to run the scripts he wrote. All this will be done in the next update. So, can you also cross out base 496 on post #280 please ?

@Happy5214 : If the non-trivial sequences are 100-digit, that's enough to create the base under good conditions.

Base 496 meets the preliminary points, but I haven't taken on filling in anything with orange. Still not sure if I will just yet. Bases 15 and 17 should be fully colored in and 8128 is mostly filled in. Perhaps by the update, it will be done too.

One merge for 496:
[code]
496^3:i168 merges with 22908:i1
[/code]
Edit: I have made an error: There is still one base 17 hold out (17^26). Hopefully I can get it in line by the update. . .

Go ahead and reserve base 496 for me to finish coloring in. Since no one has seemed to claim 1155, I would like to finish coloring it in as well.

Thanks!

Okay, thank you very much, Edwin !


Next update : Sunday, June 14th after 12:00 GMT.


:smile:

Page updated.
Thanks a lot to all !
Very big breakthroughs this week...

:smile:

Thank you for checking each of you for the sequences reserved for you.
I hope I haven't made any mistake and that I haven't forgotten anything !

I have not yet added base 24 of Happy5214 and my two bases of my own : 510510 and 9699690.
This will be done in the next update, when the conditions are reached.

How interesting! I stopped 17^10 when it reached 120 digits at index 545. Now I see it is only 100 digits and has gone through a rather large valley of over 450 more indices. Perhaps it is being run by someone else. I will leave it at index 1001 for now and see if it increases by someone else's work.

Thanks Jean-Luc, for all your work keeping the tables in order.

210^13 merges with 50064. I can't check the indices right now because FactorDB is down, but I matched my log output for that sequence with 50064 using Jean-Luc's "last 80-digit term" list.

Edit: I ran 50064 locally, and it appears 210^13:i320 = 50064:i101 is the merge point.

[QUOTE=garambois;547156]. . .
If someone wants to push the calculations further for base 2, for i beyond 500, I can also extend. I don't have a computer powerful enough at the moment to extend the calculations for base 2. Base 2 is important, it is the only one for which we can know the prime numbers at the end for each sequence.

:smile:[/QUOTE]I think I will play a little here as my machines wind down from the other tables. I will try to finish the 2^500-519 row, unless I read that someone would like me to leave it for them. . .

On a whim, I tried to pass the page through the W3C validator, and it completely barfed on it. It found over 2k errors, the vast majority of which were because the ampersands in the URLs were not escaped. Just replacing "&" with "&amp;" would do wonders for the validator. There were a few other minor issues (the <meta> tag shouldn't have a slash, the <style> tag is missing the type, and there were extraneous semicolons on the headers).

On the subject of the headers (and the colored base summaries, for that matter), it's really poor form to use <a> for non-links. The headers can be changed to <h2> for semantic correctness (you can use CSS to achieve the same inline display, like it is currently, rather than the standard block display), and the summaries should be changed to <span> tags.

I don't know if this should be directed at Karsten (who I've noticed uses <a> tags for non-links elsewhere) or Jean-Luc, but these issues shouldn't be too hard to fix, especially if a script is generating the page.

On an operational note, I've finished the trivial sequences for [I]n[/I]=24 up to 120 digits, and I've gotten the nontrivial sequences up to [I]i[/I]=41 to 100 digits. I'll probably finish the remaining sub-100 digit sequences by the weekend. There have been a surprising number of terminations and merges thus far. I'm also releasing 3^24, 3^26, and 3^30.

[QUOTE=Happy5214;548054]On a whim, I tried to pass the page through the W3C validator, and it completely barfed on it. It found over 2k errors, the vast majority of which were because the ampersands in the URLs were not escaped. Just replacing "&" with "&amp;" would do wonders for the validator. There were a few other minor issues (the <meta> tag shouldn't have a slash, the <style> tag is missing the type, and there were extraneous semicolons on the headers).

On the subject of the headers (and the colored base summaries, for that matter), it's really poor form to use <a> for non-links. The headers can be changed to <h2> for semantic correctness (you can use CSS to achieve the same inline display, like it is currently, rather than the standard block display), and the summaries should be changed to <span> tags.

I don't know if this should be directed at Karsten (who I've noticed uses <a> tags for non-links elsewhere) or Jean-Luc, but these issues shouldn't be too hard to fix, especially if a script is generating the page.

[/QUOTE]


Unfortunately, I don't understand what you're saying in those three paragraphs?
But Karsten Bonath certainly understands what it's all about...

OK for the other informations.
Please, thank you for report all sequence mergers to me.
I take good note of all your messages and I will take them into account in the next update, in a few days...
Thanks a lot !



[QUOTE=EdH;548005]I think I will play a little here as my machines wind down from the other tables. I will try to finish the 2^500-519 row, unless I read that someone would like me to leave it for them. . .[/QUOTE]


OK, I will add the exponents from 501 to 519 for base 2 in the next update.
Beware, beware, the calculations can be very long !
Normally all the sequences of base 2 will end on a prime number.
What would be very exceptional is that you discover an Open-End sequence for base 2 !
Thanks a lot !

[QUOTE=garambois;548067]. . .
OK, I will add the exponents from 501 to 519 for base 2 in the next update.
Beware, beware, the calculations can be very long !
Normally all the sequences of base 2 will end on a prime number.
What would be very exceptional is that you discover an Open-End sequence for base 2 !
Thanks a lot ![/QUOTE]No hurry on the base 2 additions. I'm experimenting with a new script that distributes CADO-NFS via Aliqueit across several machines. I expect to work each sequence to prime, in order. I have looked at the graph of many base 2 sequences and I've not seen any increase anywhere. If there are any, they might be a rare jewel, indeed, and quite worth finding.

[QUOTE=Happy5214;548054]On a whim, I tried to pass the page through the W3C validator, and it completely barfed on it. [...][/QUOTE]

I've sent Jean-Luc small changes of the scripts with the errors you spotted or even the W3C validator spotted.
If those changes are implemented the only warnings the validator shows are the tables with lesser columns in the last row than in the first.
Used the <a>-tags in my old pages but won't update/change there.

OK, page updated !
Base 24 added.
For base 2, i from 501 to 519 added.
New Karsten Bonath scripts executed.
Plus a few other requests.

I ask everyone to check that I have not forgotten one of his requests, or that I have not made a mistake.

Thank you all for your help.
And especially thanks to Karsten Bonath for the new scripts he sent me.

Thanks for catching that I hadn't updated 496^41.:smile: I had two machines working that one testing a couple different setups and neither one updated factordb, even though they both finished days ago. That's OK - the next update should color in the cell - the work is done.

Thanks for all the upkeep!

[I]n[/I]=24 is done to 100 digits. 24^17 and 24^25 both merge (24^17:i282 = 29022:i20 and 24^25:i329 = 620712:i514). I'll continue with my reserved [I]n[/I]=3 sequences before resuming [I]n[/I]=21.

@kar_bon: Thanks for the syntax fixes. The headers still need to be fixed, though. I wasn't expecting you to update to HTML5 (thanks for that), but since you have, the variables ([I]n[/I] and [I]i[/I]) should be in <var> tags instead of <i>, providing the semantics of a variable. You should also group each base under its own <section> tag. The liberal use of double <br> tags should be replaced with paragraphs using <p>.

OK, page updated.
Thanks to all.
Bases 510510 and 9699690 added.


:smile:

I just had an idea that I think would be useful. Can we add the number of sequences that merge into "main project" sequences to the open sequence count as another parenthesized number? For example, [I]n[/I]=3 would have "Open: 108 (108) (8) ➔ 43.03%" or something to that effect.

For the moment, we see no need to specify the number of Open-End sequences that merge with sequences from the "main project".
But if you say you need it, we could try to add it.
Do you confirm that you would need it ?

I'm assuming that this subproject won't continue sequences that merge into "main project" sequences, in deference to the main efforts. If so, there should be an easy way to count the number of sequences that we [i]will[/i] continue through this subproject (in theory, at least) rather than handing off to the "main project". If added, I personally would use an at-a-glance look at merged sequences for different bases, just like I would use the terminated sequence count.

[QUOTE=richs;547115]I will reserve 439^14 since I'm still working it. Thanks![/QUOTE]

439^14 is now at i2812 (added 2140 iterations) and a C130 level with a 2^3 * 3^2 * 5 driver, so I will drop this reservation. The remaining C121 term has been ecm'ed to t37.

Reserving 439^16.

@richs :
OK, Changes will be made at the next update. Many thanks.


@Happy5214 :
What form of display would be most convenient for your needs ? Just like this :
[COLOR=DarkOrange]"Open: 108 (108) (8) ➔ 43.03%"[/COLOR]
But in this case I'm afraid it would be difficult for a newcomer to understand what the numbers in brackets mean.
Or wouldn't it be better to put the line in this form or something to that effect :
[COLOR=darkorange]"Open: 108 (including 108 calculated to 120 digits or more and 8 that merge with the sequences of the main project) ➔ 43.03%"[/COLOR]
or else :
[COLOR=darkorange]"Open: 108 (including 108 orange cells and 8 mergers) ➔ 43.03%"[/COLOR]
[COLOR=darkorange][COLOR=Black]If the English-speaking readers of this post have an opinion and manage to make the line as clear as possible in the shortest possible way, please choose one of these options or suggest something better.[/COLOR]
[/COLOR]

Perhaps you could add an explanation in the Definitions section, something like this:

[QUOTE]Below the table for a base are stats for that base's sequences. "Done" is the number of sequences terminating at primes, "Cycle" is the number of sequences terminating in a cycle, and "Open" is the number of open-ended sequences, in the format "<total open-ended sequences> (<number of sequences calculated to at least 120 digits>, <number of sequences which merge into "main project" sequences>). For example, a base with 20 total open-ended sequences, of which 10 have been calculated to 120 digits and 5 merge, would be described with "20 (10, 5)[/QUOTE]

Whether you do that or not, you should also surround the individual numbers with <abbr> tags and explain their meanings in the title= attribute.

[QUOTE=Happy5214;549200]Whether you do that or not, you should also surround the individual numbers with <abbr> tags and explain their meanings in the title= attribute.[/QUOTE]

On second thought, it's not actually an abbreviation, so use a couple of nested <span> tags (one for each number) with the title= attribute describing what it represents. You may want to add a couple of classes and some CSS to those classes ([c]text-decoration: underline dotted;[/c] would make it look like <abbr> in most browsers).

@Jean-Luc,

The 2^500-2^519 row has only three still orange, which I'm sure won't be green by your next update. But, I hope they will be green by the following update.

Since I am capable of working in that area, I could do another row (2^520-2^539), if that's where you would prefer. Or, if you have somewhere else you would prefer I work, let me know and reserve it for me.

Thanks,
Ed

Edit: Once I have turned a block orange in the tables other than base 2, I probably should be removed from that block as I no longer intend to work there, at least for now. Unfortunately, that may be a lot of work for you at this point. - sorry! If that's the case, leaving me there won't hurt me at all, but may keep others from working on those sequences.

[QUOTE=garambois;549196]@richs :
OK, Changes will be made at the next update. Many thanks.


@Happy5214 :
What form of display would be most convenient for your needs ? Just like this :
[COLOR=DarkOrange]"Open: 108 (108) (8) ➔ 43.03%"[/COLOR]
But in this case I'm afraid it would be difficult for a newcomer to understand what the numbers in brackets mean.
Or wouldn't it be better to put the line in this form or something to that effect :
[COLOR=darkorange]"Open: 108 (including 108 calculated to 120 digits or more and 8 that merge with the sequences of the main project) ➔ 43.03%"[/COLOR]
or else :
[COLOR=darkorange]"Open: 108 (including 108 orange cells and 8 mergers) ➔ 43.03%"[/COLOR]
[COLOR=darkorange][COLOR=Black]If the English-speaking readers of this post have an opinion and manage to make the line as clear as possible in the shortest possible way, please choose one of these options or suggest something better.[/COLOR]
[/COLOR][/QUOTE]
Another suggestion would be to show the merged sequence count with the same yellow background as the merged sequence links.

@ EdH :
Okay, I'll make all the changes in the next update, very soon...


@ Happy 5214 :
Yes, your last idea was also suggested to me by Karsten Bonath.
[U]So the colors like now:[/U]
All: x [COLOR=SeaGreen][Green: Done][/COLOR] [COLOR=Red][Red: Open][/COLOR] [COLOR=RoyalBlue][Blue: Cycle][/COLOR]
[U]And then:[/U]
All: x [COLOR=seagreen][Green: Done][/COLOR] [COLOR=red][Red: Open][/COLOR] [COLOR=Orange][Yellow: merged][/COLOR] [COLOR=royalblue][Blue: Cycle][/COLOR]
And it also seems to me that this solution is the clearest and, as Karsten says, we don't need another explanation to understand.
Do you think that if we proceed in this way, you will be able to do the work that motivated you to make this request ?

Will the merged sequences be taken out of the open count? I think double-counting the merged sequences in both totals would be confusing. Overall, this plan works.

In other news, I've finished work on my [I]n[/I]=3 reservations and am releasing those.

OK, page updated.
A lot of thanks to all for your help.

And once again, a big thank you to Karsten Bonath who sent me the modifications of the scripts.
I'm not comfortable in this area and if I had to make the changes myself, it would most likely take me several hours or even days. And there's no guarantee that my changes would be done successfully... I have already once caused a disaster by wanting to touch the scripts myself !

Please, don't forget to check for updates that concern you personally and report any errors to me.

I have been playing with some programs/scripts to harvest some statistics from the sequences within the tables. Here is a sample of some individual statistics from the base 8128 table:
[code]
Stats for 8128^1:
The complete (current) last line is:
2 . 8128 = 2^6 * 127
Total abundant terms: 0
Total deficient terms: 0
Most sequencial abundant terms: 0
Most sequencial deficient terms: 0
Parity changes even to odd: 0
Parity changes odd to even: 0
The first term is perfect.

. . .

Stats for 8128^30:
The complete (current) last line is:
32 . 2460259041035273743806735759303370898982607278814358187347453 = 2460259041035273743806735759303370898982607278814358187347453
Total abundant terms: 1
Total deficient terms: 31
Most sequencial abundant terms: 1
Most sequencial deficient terms: 31
Parity changes even to odd: 1
Parity changes odd to even: 0
The first term is abundant.
[/code]The full set is attached.

I chose 8128 for this example because it has only 30 sequences and is therefore somewhat smaller than others. If there is interest in these statistics, I can provide files for the other bases. These may be spread out over time.

Additionally, if there are other things that may be of interest, I can try to add those items to my stats.

This particular document shows individual statistics, but an aggregate for an entire table can also be harvested from it, or from a subsequent document with more specifics. An example would be capturing the last prime for all the prime terminated sequences for a count/comparison of common terminations within a table. I can probably find a way to show any perfect endings (as well as current beginnings) also, but I'm still struggling with how to catch cycles of greater than 1.

Let me know of any more things of interest and I'll see if I can figure out how to add them.

EdH,


I'm very interested in your work !
Could you please provide me with the files for all the bases ?
This is exactly the kind of work I started to do to examine the data.
Your data is very complete compared to my work.
I only added one more piece of data: the number of relative maximums in the "Huge graph" of the sequence.
But this number should almost correspond to the number "Parity changes even to odd" with some exceptions. It can be different because a sequence can increase with odd terms and decrease with even terms...


For cycles longer than 1, I propose to consider only the smallest integer of the cycle. This way, we will be sure to talk about the same cycle each time.


I also intend to make a general table showing the following :
For all bases, look at the percentage of the number of sequences that end with all prime numbers up to 1000.
But the first column will give percentages for all integers.
The only problem is that except for base 2, the number of sequences ending with a prime number is small.
Even for base 2, we have only 500 sequences and this is still a statistically low number !


By the way, I confirm you in this post that I found exactly the same thing as you for the prime numbers (or numbers belonging to a cycle) that end the sequences of base 2.
Here is the result of running my program, in a convenient form for use with the Sage software :

[CODE][3, [2, 4, 55, 164, 305, 317]]
[6, [14, 15, 59]]
[7, [3, 10, 12, 141, 278, 387, 421]]
[11, [60, 316, 480, 499]]
[19, [39, 76, 190, 219]]
[31, [5, 101, 146]]
[37, [68, 125, 243]]
[41, [6, 8, 23, 47, 112, 117, 281, 373, 405, 411]]
[43, [9, 62, 210, 271]]
[53, [20, 78, 214, 347, 450]]
[71, [43, 177]]
[89, [32, 82]]
[97, [51, 73]]
[101, [301, 425]]
[241, [279, 346]]
[547, [24, 198]]
[7481, [69, 458]]
[/CODE]This means for example for the first line, that for the prime number 3, we have 2^2, 2^4, 2^55, 2^164, 2^305 and 2^317 ending with the prime number 3.


I'm also working on your idea of (rare) abundant numbers analysis in base 2 sequences.
But this work can be generalized to all bases for sequences that end trivially : those n^i whose exponent i and n have the same parity (green cells). Like for base 2, there is no exception, none of these sequences is Open-End : in no table for no base, there are three orange cells following each other !

Jean-Luc,

I can provide all the tables in a "relatively" short time, but I was waiting to see what other data might be of interest before completing a full run. I have some additions I'm working with. Your extra items should fit right in.

[QUOTE=garambois;549915]...
I only added one more piece of data: the number of relative maximums in the "Huge graph" of the sequence.
But this number should almost correspond to the number "Parity changes even to odd" with some exceptions. It can be different because a sequence can increase with odd terms and decrease with even terms...[/QUOTE]

I think I should be able to add this without too much difficulty, since I detect all changes from abundant to deficient numbers. I should be able catch the final value of all abundant runs. But, should I only track those for runs greater than a certain length? Is a single abundant line of interest?

Is there interest in listings of abundant and deficient lines, or would that just be too much? What about common primes within a sequence? I know there are many trivial primes (2, 3, 5, 7, etc.), but what about a listing of any repeated primes above a particular value?

I believe all cycles' .elf files end with the smallest value, but what I'm having trouble with is detecting that that value is part of a cycle. I'll still work on this, but it's moved to lower on my list until I get some of the other things worked out.

I'm currently reporting on all cells of a table, at their current status, but I'm not reporting whether the sequence terminates. Is that significant? I think I can add that, but I'll see how troublesome it is.

I'll work on a bit of this other stuff and attach some files, hopefully not too far off.

[QUOTE=richs;549163]Reserving 439^16.[/QUOTE]

439^16 is now at i1588 (added about 100 iterations) and a C120 level with a 2 * 3^2 * 5 driver, so I will drop this reservation. The remaining C118 term is well ecm'ed and is ready for NFS.

Reserving 439^24.

Latest Data Harvesting
 

Here's of an example of my latest play. I'm showing 8128^1 through 8128^5, because this range shows all three endings (Cycle, Prime, Open):
[code]
Statistics for Sequences in Base 8128 Table

Stats for 8128^1:
The first term is perfect.
Total abundant terms: 0
Total deficient terms: 0
Most sequential abundant terms: 0
Most sequential deficient terms: 0
Parity changes even to odd: 0
Parity changes odd to even: 0
Number of abundant peaks: 0
The complete (current) last line is:
2 . 8128 = 2^6 * 127
Sequence terminates in a cycle.

Stats for 8128^2:
The first term is abundant.
Total abundant terms: 1
Total deficient terms: 0
Most sequential abundant terms: 1
Most sequential deficient terms: 0
Parity changes even to odd: 1
Parity changes odd to even: 0
Number of abundant peaks: 0
The complete (current) last line is:
1 . 67096703 = 67096703
Sequence terminates in a Prime.

Stats for 8128^3:
The first term is abundant.
Total abundant terms: 31
Total deficient terms: 44
Most sequential abundant terms: 11
Most sequential deficient terms: 30
Parity changes even to odd: 1
Parity changes odd to even: 0
Number of abundant peaks: 7
Greatest abundant peak (13dd): 8188451842630
Greatest peak larger than first term: Yes
The complete (current) last line is:
75 . 588169 = 588169
Sequence terminates in a Prime.

Stats for 8128^4:
The first term is abundant.
Total abundant terms: 1
Total deficient terms: 6
Most sequential abundant terms: 1
Most sequential deficient terms: 6
Parity changes even to odd: 1
Parity changes odd to even: 0
Number of abundant peaks: 1
Greatest abundant peak (16dd): 4433780393574655
Greatest peak larger than first term: Yes
The complete (current) last line is:
7 . 4676239 = 4676239
Sequence terminates in a Prime.

Stats for 8128^5:
The first term is abundant.
Total abundant terms: 668
Total deficient terms: 235
Most sequential abundant terms: 243
Most sequential deficient terms: 27
Parity changes even to odd: 0
Parity changes odd to even: 0
Number of abundant peaks: 30
Greatest abundant peak (108dd): 132753974028868296806704376876902835792862284557288443803825213072201704392301945780093329848100479057972132862079756272
Greatest peak larger than first term: Yes
The complete (current) last line is:
903 . 132753974028868296806704376876902835792862284557288443803825213072201704392301945780093329848100479057972132862079756272 = 2^4 * 3 * 11 * 31 * 73 * 6703
Sequence is still open.
[/code]All comments welcome. . .

Here's a current run for the base 2 table:

Edit: Added bases 3, 5 and 6:

Edit2: Added base 7:

[COLOR=Red] Edit3: I have noticed a flaw![COLOR=Black] For open sequences that are currently riding an abundant climb, I have considered the last term as the current maximum if it is higher than the others. However, the size (xxdd) represents the previous maximum. I will fix this and reattach the affected files.[/COLOR][/COLOR]

[COLOR=Red][COLOR=Black]Edit4: Files replaced with corrected versions.[/COLOR][/COLOR]

[COLOR=Red][COLOR=Black][SIZE=2](Files current as of Edit date shown below.)[/SIZE]
[/COLOR][/COLOR]

[B]@ richs :[/B]
OK, I'll make all the changes in the next update, very soon...
A lot of thanks !



[B]@ EdH :[/B]

Thank you very much for all your files.
Bases 2, 3, 5, 6 and 7 should do me for now.
I will try to verify all of this and try to reproduce the results of your program in a few days.
Because now, I'm focusing on the sequences that end with prime numbers and creating a table to compare the bases between them.
I think I will be able to show this table here in this forum today or tomorrow...

I have a suggestion for the presentation of your results.
If it is not too complicated for you, would it be possible to recreate the files for bases 2, 3, 5, 6 and 7 by doing the modification like this :

[B]Replace this :[/B]
[CODE]Stats for 3^5:
The first term is deficient.
Total abundant terms: 1
Total deficient terms: 6
Most sequential abundant terms: 1
Most sequential deficient terms: 4
Parity changes even to odd: 2
Parity changes odd to even: 2
Number of abundant peaks: 1
Greatest abundant peak (2dd): 16
Greatest peak larger than first term: No
The complete (current) last line is:
7 . 3 = 3
Sequence terminates in a Prime.[/CODE] [B]with this (much easier to operate afterwards) :
[/B][CODE][3, 5, 0, 1, 6, 1, 4, 2, 2, 1, 16, 0, 7, 3][/CODE] Explanation :

[a, b, c, d, e, f, g, h, i, j, k, l, m, n]
a : base
b : exponent
c : 0 if deficient, 1 if abundant
d : number of total abundant terms
e : number of total deficient terms
f : most sequential abundant terms
g : most sequential deficient terms
h : parity changes even to odd
i : parity changes odd to even
j : number of abundant peaks
k : greatest abundant peak (2dd)
l : greatest peak larger than first term 1 if yes and 0 if no
m : last index
n : last term

There's no problem if it's too constraining for you to recreate the files like that, I'd settle for the original form !

:smile:

[B]And to answer some of your questions above :
[/B]
- In my opinion, yes, a single abundant line is of interest.
- Yes, I plan to work in August on all the prime numbers that appear in a sequence and not only on the last one. I'll take into account even the small prime numbers...
- There are so few cycles at the moment in our data that I plan to fix the problem by writing the data manually for only the cycles !
- The work on open-end sequences will only be useful when I work on the prime numbers appearing in all the terms of the sequence and not only on the last terms of the sequences that end.

This should be fairly simple. I have the programs/scripts written and .elfs saved. I just need to modify some things.

I'll skip open sequences for now, since you mention it for later work. That way I won't have to check for updates of any .elfs.

For later, as to primes found within a sequence, will you need a count of each or just a list?

[QUOTE=EdH;550008]
For later, as to primes found within a sequence, will you need a count of each or just a list?[/QUOTE]

Thanks, Ed.
I'll need a count of every prime number, the list alone is not enough !
For a given sequence, how many times have we had the two, three, five, seven...
For example, for the sequence starting at 2^10, that would be :

Sequence :

[CODE]0 . 1024 = 2^10
1 . 1023 = 3 * 11 * 31
2 . 513 = 3^3 * 19
3 . 287 = 7 * 41
4 . 49 = 7^2
5 . 8 = 2^3
6 . 7 = 7[/CODE]Result :
[CODE][[2, 13], [3, 4], [7,4], [11,1], [19, 1], [31, 1], [41, 1]][/CODE]

[QUOTE=garambois;550021]Thanks, Ed.
I'll need a count of every prime number, the list alone is not enough !
For a given sequence, how many times have we had the two, three, five, seven...
For example, for the sequence starting at 2^10, that would be :

Sequence :

[CODE]0 . 1024 = 2^10
1 . 1023 = 3 * 11 * 31
2 . 513 = 3^3 * 19
3 . 287 = 7 * 41
4 . 49 = 7^2
5 . 8 = 2^3
6 . 7 = 7[/CODE]Result :
[CODE][[2, 13], [3, 4], [7,4], [11,1], [19, 1], [31, 1], [41, 1]][/CODE][/QUOTE]I will work on this, but it might be a little bit before I have it complete.

Meanwhile, I am attaching bases 2 - 7 statistics with the new format. I added 2 (prime) and 3 (cycle) to the c position, since they are neither abundant nor deficient. I also skipped all the open sequences. I used the following key, with no title, in the documents:
[code]

[a, b, c, d, e, f, g, h, i, j, k, l, m, n]
a : base
b : exponent
c : 0 if deficient, 1 if abundant, 2 if prime, 3 if perfect
d : number of total abundant terms
e : number of total deficient terms
f : most sequential abundant terms
g : most sequential deficient terms
h : parity changes even to odd
i : parity changes odd to even
j : number of abundant peaks
k : greatest abundant peak (2dd)
l : greatest peak larger than first term 1 if yes and 0 if no
m : last index
n : last term
[/code] I hope I got all this correct!:smile:

Edit: Actually, did you want the size of the highest peak or the term? I provided the term, but I can change that and rerun easily.

Edit2: The attachments were removed because they were flawed. The new (current) files can be found in [URL="https://www.mersenneforum.org/showpost.php?p=550114&postcount=339"]this new post[/URL].

[QUOTE=EdH;550039] I hope I got all this correct!:smile:
[/QUOTE]

I'll check it out, maybe even try to replicate your algorithm.
But I'm not sure I'll have the time to do all this before I go on holiday in a few days : there's nothing you can do against the call of the mountain !
So far I've done some manual checks, everything seems to be fine. But it's laborious to do so...


Before I leave, I think I'll concentrate on counting all the prime numbers of all the terms in a sequence, as in the example above.

In August, when I come back, I will have much more time for everything else.

[QUOTE=EdH;550039]
Edit: Actually, did you want the size of the highest peak or the term? I provided the term, but I can change that and rerun easily.[/QUOTE]

I think for the highest peak, the term is better, because there's more information than if you just give the size.

I have two questions:



1) Please, I'm not sure I understand the meaning of :
[CODE]l: greatest peak larger than first term 1 if yes and 0 if no[/CODE]Why, in the case of 2^i, is it always worth 1 ?
Indeed, the starting term of the sequence is always the largest, isn't it ?




2) The value of c is only about the first term of the sequence, isn't it ?
[CODE]c : 0 if deficient, 1 if abundant, 2 if prime, 3 if perfect[/CODE]

[QUOTE=garambois;550074]I have two questions:



1) Please, I'm not sure I understand the meaning of :
[CODE]l: greatest peak larger than first term 1 if yes and 0 if no[/CODE]Why, in the case of 2^i, is it always worth 1 ?
Indeed, the starting term of the sequence is always the largest, isn't it ?




2) The value of c is only about the first term of the sequence, isn't it ?
[CODE]c : 0 if deficient, 1 if abundant, 2 if prime, 3 if perfect[/CODE][/QUOTE]1) I have something wrong for that value. It is not always 1, but there are 60 sequences (2^1 - 2^539) where a peak exceeds the initial term. For example, see 2^12:
[code]
0 . [B]4096[/B] = 2^12
1 . 4095 = 3^2 * 5 * 7 * 13
2 . [B]4641[/B] = 3 * 7 * 13 * 17
3 . 3423 = 3 * 7 * 163
4 . 1825 = 5^2 * 73
5 . 469 = 7 * 67
6 . 75 = 3 * 5^2
7 . 49 = 7^2
8 . 8 = 2^3
9 . 7 = 7
[/code]Term 2 (4641) > term 0 (4096). Those 60 should show 1. I will have to fix that, but it will have to wait until later tonight or tomorrow morning. Sorry for the delay.:sad:

2) That is correct. The value c is about term 0 only. If term 0 is perfect, s(n)-n is equal to itself (neither deficient nor abundant), if prime, it's equal to 1 (deficient, but unique). I could flag primes as deficient, but it really wouldn't be the same as the others, since there are no terms after a prime termination. How would you like me to reflect perfect and prime for your needs?

[QUOTE=EdH;550078]1)Term 2 (4641) > term 0 (4096). Those 60 should show 1. I will have to fix that, but it will have to wait until later tonight or tomorrow morning. Sorry for the delay.:sad:
[/QUOTE]


Take your time.
As I said before, I'll be working on this in August...


:smile:

The first array is finished.
You can see it as an attachment (.pdf version).

It is difficult to draw definite conclusions because we don't have a lot of sequences that end for large bases after all.
But what I was hoping for is not happening.
[B]Sequences that start on integer powers seem to generally end with the same probability on the same prime numbers as all of the sequences.[/B]
So there's no obvious conjecture to be made... yet.

I will redo all this work by considering all the prime numbers that appear in all the terms of the sequences, as described above.
I will also publish the final array here.

If anyone has any questions or notices things that I wouldn't have seen when looking at this array, please feel free to express them here !

2 years ago I played around with aliquot sequences and graphviz, a free tool to display graphs.

The problem is you can not only include all relations automatically because the graph will grow and isn't easy to handle. So you have to create some sub-graphs to tidy up the image.

I've created a tree of squences ending in 43 with (I think all values<20000, no odd) and the result is an image.
The source is a text file ~10kB in the graphviz syntax (the extension has to be changed into 'gv' for graphviz).
The image was created with
[code]
dot -Tjpg 43.gv >43.jpg
[/code]

The problem here: the filesize is ~1.8MB (too big for jpg) and the dimensions (~10,000 x 2900 pixel, to big, too), so I uploaded it into the [url='https://www.rieselprime.de/z/images/4/4f/43.jpg']Wiki[/url].

Here are corrected statistics for bases 2-7:

I've started base 30 for n=1 to 20. At least half have trivially terminated. It will be slow going because I am using a C2D laptop part-time.

[QUOTE=kar_bon;550096]2 years ago I played around with aliquot sequences and graphviz, a free tool to display graphs.
. . .
[/QUOTE]This is impressive! I remember some of it from much longer ago, when the genealogy thread was active. Does 43 appear to be the most common termination at higher numbered sequences (>1M), as well?

[QUOTE=garambois;550021]Thanks, Ed.
I'll need a count of every prime number, the list alone is not enough !
For a given sequence, how many times have we had the two, three, five, seven...
For example, for the sequence starting at 2^10, that would be :

Sequence :

[CODE]0 . 1024 = 2^10
1 . 1023 = 3 * 11 * 31
2 . 513 = 3^3 * 19
3 . 287 = 7 * 41
4 . 49 = 7^2
5 . 8 = 2^3
6 . 7 = 7[/CODE]Result :
[CODE][[2, 13], [3, 4], [7,4], [11,1], [19, 1], [31, 1], [41, 1]][/CODE][/QUOTE]Do you need the sequence referenced or will the list suffice as each line corresponding to that power?

The table shows some interesting values, but as you say, these base tables are such a tiny portion of the overall, it's tough to find any commonalities.

[B]@RichD :[/B]

OK, many thanks. I will add base 30 in the next update, in 2 or 3 days.



[B]@Kar_bon :[/B]

Yes, this is impressive ! thank you for the link.



[B]@EdH :

To answer your questions :[/B]

1) Yes, I think 43 appears to be the most common termination at higher numbered sequences >1M. On my website, I have a database called "[URL="http://www.aliquotes.com/aliquote_base.htm#alibasefonda"]fundamental database[/URL]." But sorry, all explanations are in french.
Thanks to this base, I was able to determine that among all the sequences that start with the integers from 1 to 10M, there are exactly 666638 that end with the prime number 43! There are 456843 that end with 59 and 437318 that end with 41. [URL="http://www.aliquotes.com/aliquote_base_fond_applic.htm"]See here. [/URL]
But to build this database, I considered the sequences to be open-end as soon as the size of the terms exceeded 50 digits. So there are even more that must end with those prime numbers...

2) I don't need the sequence referenced. The list is enough because each line corresponds to the power.



[B]And a more general comment on the project :[/B]

Frankly, I wonder whether it wouldn't make sense to push all the bases up to 160 digits, but only for sequences that end trivially on a prime number. I'm still not sure whether pushing the calculations that far would bring an interesting gain in terms of improving the statistics ?
Or is it more interesting to calculate other bases up to 120 digits ?

[QUOTE=EdH;550117]This is impressive! I remember some of it from much longer ago, when the genealogy thread was active. Does 43 appear to be the most common termination at higher numbered sequences (>1M), as well?[/QUOTE]

On Wolfgang Creyaufmuellers [url='http://www.aliquot.de/aliquote.htm']page[/url] you can find a [url='http://www.aliquot.de/tabellen/1-1m.txt']table[/url] with endings for all seqs <1M (eventually outdated) (download as zip also available, see on top under the first table "About 1% of all integers are...").

Here the first 5 most families:
[code]
43 78060 7.81%
59 53197 5.32%
41 51012 5.10%
7 42299 4.23%
601 26759 2.68%
[/code]

@garambrois: Does this mean all the sequences <10M are represented in factordb at >= 50 dd? I believe they would be updated gradually by the "elves" only when accessed, but any access would move their last terms. (I might verify that later.)

It would be easier by far to add more bases than to extend to 160 dd. I'm taking roughly 1.5 days on average to factor 15x dd in the base 2 table, with my whole "farm." I think smaller equipped contributors would be less likely to participate.

@kar_bon: Thanks for the links. I haven't been to his page(s) in quite some time. I'll have to spend some more time there.

[QUOTE=garambois;550021]Thanks, Ed.
I'll need a count of every prime number, the list alone is not enough !
For a given sequence, how many times have we had the two, three, five, seven...
For example, for the sequence starting at 2^10, that would be :

Sequence :

[CODE]0 . 1024 = 2^10
1 . 1023 = 3 * 11 * 31
2 . 513 = 3^3 * 19
3 . 287 = 7 * 41
4 . 49 = 7^2
5 . 8 = 2^3
6 . 7 = 7[/CODE]Result :
[CODE][[2, 13], [3, 4], [7,4], [11,1], [19, 1], [31, 1], [41, 1]][/CODE][/QUOTE]I have a script to do what you've shown above:
2^10 matches yours (except for order*):
[code]
[[2, 13], [3, 4], [7, 4], [11, 1], [31, 1], [19, 1], [41, 1]]
[/code]and, 5^4 shows the following:
[code]
[[2, 13], [3, 1], [5, 4], [7, 3], [13, 1], [59, 1], [23, 1], [11, 1], [29, 1], [37, 1]]
[/code]*I haven't provided a sort. Is that necessary?

Now, something I'm concerned about: the practicality of capturing every prime. I ran 5^6 and came up with a single line that was well over 225000 characters. Should I possibly trim the primes in some manner? A full single table will be enormous.

[QUOTE=EdH;550134]@garambrois: Does this mean all the sequences <10M are represented in factordb at >= 50 dd? I believe they would be updated gradually by the "elves" only when accessed, but any access would move their last terms. (I might verify that later.)

It would be easier by far to add more bases than to extend to 160 dd. I'm taking roughly 1.5 days on average to factor 15x dd in the base 2 table, with my whole "farm." I think smaller equipped contributors would be less likely to participate.
[/QUOTE]


1) No, I never entered this data into factordb. But calculating all open-ends up to 10M up to 50 digits should only take a few hours or days...
What takes time in building up my database is the fact that the side tables keep growing (regina_cycles, regina_opens and regina-prems, on [URL]http://www.aliquotes.com/aliquote_base.htm#alibasefonda[/URL]).
Calculations have been in progress for more than 2 years and I'm at 13.5M.

2) OK, I'll take your advice and calculate other bases instead of going up to 160 figures for all the bases. I'll be doing this job in two years, when I have a 64C/128T CPU !

[QUOTE=EdH;550145]I have a script to do what you've shown above:
2^10 matches yours (except for order*):
[code]
[[2, 13], [3, 4], [7, 4], [11, 1], [31, 1], [19, 1], [41, 1]]
[/code]and, 5^4 shows the following:
[code]
[[2, 13], [3, 1], [5, 4], [7, 3], [13, 1], [59, 1], [23, 1], [11, 1], [29, 1], [37, 1]]
[/code]*I haven't provided a sort. Is that necessary?

Now, something I'm concerned about: the practicality of capturing every prime. I ran 5^6 and came up with a single line that was well over 225000 characters. Should I possibly trim the primes in some manner? A full single table will be enormous.[/QUOTE]


1) It is best if you sort the prime numbers in ascending order in the table. But maybe that's too much work ? No problem if it's too much work, I'll be able to program the sorting myself, because I can imagine how much time you spend to write all these algorithms, and really, a big thank you for all this time you give !!!

2) Yes, the tables can be huge !
But it's still interesting to include all the prime numbers, even if at first, I will only use prime numbers below 1000. Sometimes we have surprises. For example, for all the integers from 1 to 10M, there are 69 ending with the prime 4737865361 or 5 ending with the prime 14604141802777 ([URL="http://www.aliquotes.com/aliquote_base_fond_applic.htm"]see here[/URL]). These large prime numbers are sequence "attractors", such as 43.
The question is to know if there are such attractors of any size in the set of all sequences and, as far as our project is concerned, in the set of all sequences starting on numbers composed of only 2, only 3, only 5, only 7...

2) This does cause further questions I had not considered earlier:

a - Does a large termination prime appear earlier as a factor?
b - Do termination primes appear in other sequences in an interesting frequency?

The answers would only be available if all primes are included in the lists.

One thing I've often thought would be a nice feature for factordb, would be all the sequences associated with a single prime. It would be nice if that were available in the "Info" section, but it would be prohibitively large for smaller primes.

I'm done with 21^62 and 21^64 and will release those.

I'll just go ahead and reserve the rest of base 21 to [i]i[/i]=97.

[QUOTE=EdH;550134]It would be easier by far to add more bases than to extend to 160 dd. I'm taking roughly 1.5 days on average to factor 15x dd in the base 2 table, with my whole "farm." I think smaller equipped contributors would be less likely to participate.[/QUOTE]

I concur wholeheartedly. My lowly computer can't do 160 digits. In fact, I'm sitting on a 5-digit downdriver sequence because I don't want to do the C144 cofactor (ECMed to ~t48) until I get newer/better hardware.

[QUOTE=EdH;550166]2) This does cause further questions I had not considered earlier:

a - Does a large termination prime appear earlier as a factor?
b - Do termination primes appear in other sequences in an interesting frequency?

The answers would only be available if all primes are included in the lists.

One thing I've often thought would be a nice feature for factordb, would be all the sequences associated with a single prime. It would be nice if that were available in the "Info" section, but it would be prohibitively large for smaller primes.[/QUOTE]


a) No, in my opinion, we don't need to distinguish between prime numbers at the end of sequences and others here. This study is done with the other program.
I just finished writing the program for all the primes in a sequence. I'm running it for Base 2. I'm taking into account all the sequences, even the open-ends. I'll communicate the results for a few bases in a few hours or tomorrow depending on how long the calculations take...

b) I never thought of that !
It's an interesting question, it's a good idea : I'll think about it...

Knowing all the sequences associated with a prime number would be interesting, but it must be difficult to program and very time-consuming in terms of calculation time and memory. I remember having done some tests on this. But maybe I didn't do it right !

[QUOTE=Happy5214;550168]I'm done with 21^62 and 21^64 and will release those.

I'll just go ahead and reserve the rest of base 21 to [I]i[/I]=97.

I concur wholeheartedly. My lowly computer can't do 160 digits. In fact, I'm sitting on a 5-digit downdriver sequence because I don't want to do the C144 cofactor (ECMed to ~t48) until I get newer/better hardware.[/QUOTE]



Ok, thanks a lot.
I change that in tomorrow's update...

Yes, on reflection, I also agree with you that our computers are not yet able to do the work up to 160 figures in a reasonable time ...

[QUOTE=garambois;550170]. . .
I just finished writing the program for all the primes in a sequence. I'm running it for Base 2. I'm taking into account all the sequences, even the open-ends. I'll communicate the results for a few bases in a few hours or tomorrow depending on how long the calculations take...
. . .[/QUOTE]I, too, have a working program/script that now includes sorting. But, if you already have something working, I won't bother uploading files that may be too large anyway.:smile:

Are you still interested in the earlier abundancy/deficiency, etc. counts for the tables above the five I already provided? I have tables up through base 28 done and can continue with the higher ones.

Yes, I'm still interested in the abundance/deficiency charts. But until base 28, that will be more than enough, no need to go any further.
Thank you very much !

Please, can you check with some base 2 exponents if you get the same thing as me, see in the attached file. That would reassure me for the future work !

[QUOTE=garambois;550185]Yes, I'm still interested in the abundance/deficiency charts. But until base 28, that will be more than enough, no need to go any further.
Thank you very much !

Please, can you check with some base 2 exponents if you get the same thing as me, see in the attached file. That would reassure me for the future work ![/QUOTE]
I added the prefix you used to my output lines and ran the entire base 2 as you did. My result file was identical to yours according to diff. I would say, both our programs have been validated, or at least, they both have the same error(s).:smile:

I'll upload the other abundance/deficiency files later today.

[QUOTE=garambois;550185]Yes, I'm still interested in the abundance/deficiency charts. But until base 28, that will be more than enough, no need to go any further.
Thank you very much !
. . .[/QUOTE]Here are bases 10 through 14:

[QUOTE=garambois;550185]Yes, I'm still interested in the abundance/deficiency charts. But until base 28, that will be more than enough, no need to go any further.
Thank you very much !
. . .[/QUOTE]Here are bases 15 through 28:

Many thanks for all Ed !

I downloaded all the files.
And I'm very happy to learn that our programs are giving the same results !

But what surprises me is that the data analysis I'm doing for a single database takes a lot of time. I must have underestimated the amount of work the computer would need to do all the tests I planned to do.
Base 2 analysis : 8 hours.
Base 3 analysis : I started 12 hours ago and it's not finished.
I will let you know the first results before I leave, as I'm not sure I'll be able to obtain everything before my trip at this pace !

[SIZE=4][COLOR=Red]I think I've come up with a new conjecture ! But I would be very surprised if the experts working on the factorization of Mersenne numbers did not know this conjecture !
Thank you for keeping me informed ![/COLOR][/SIZE]


Unless I'm mistaken, I'm almost certain that the prime number 68625988504811774259364670661552948915363901845035416371912463477873783063 factors all numbers of the form 2^(269*i)-1 if i is an integer. I tried on factordb to factorize 2^2690000 and 2^(2690000-269) and it worked !
It's up to you to try again.

In the same way, I think I can affirm that the prime number 160619474372352289412737508720216839225805656328990879953332340439 factorizes all numbers of the form 2^(241*i) with i integer.

And I have several more like this, see the attached file.

The attached file starts like this :

base 2 prime 10567201 exponent 75
base 2 prime 10567201 exponent 150
base 2 prime 10567201 exponent 225
base 2 prime 10567201 exponent 300
base 2 prime 10567201 exponent 375
base 2 prime 10567201 exponent 450
base 2 prime 10567201 exponent 525

This means that the prime 10567201 is a prime factor that appears in the aliquot sequences 2^75, 2^150, 2^225... and more generally 2^(75*i) with integer i. And I don't know why, but this prime number always appears in the decomposition of the number at index 1 of the sequence. So it factors the numbers 2^(75*i)-1.

I didn't check with all the prime numbers in the file, but for the ones I did, it worked like this...

So the same should happen with all the prime numbers in the file...

12112549 should factor every 2^(164*i)-1.
13264529 should factor every 2^(47*i)-1.
...
...
...
68625988504811774259364670661552948915363901845035416371912463477873783063 should factor every 2^(269*i)-1.


[B]I'll try to do the same work with the other bases...[/B]

Not conjecture, theorem. If [I]p[/I] = [I]ab[/I] ([I]a[/I], [I]b[/I] > 1), then 2^[I]a[/I]-1 and 2^[I]b[/I]-1 both divide 2^[I]p[/I]-1. Ergo, any number that divides 2^[I]n[/I]-1 will also divide 2^([I]ni[/I])-1, for any [I]i[/I] ≥ 1. That's why exponents for Mersenne primes must themselves also be prime.

Thank you very much Happy5214.
I suspected it was already known !

I continue my analysis to try to find something else on the other bases and also on a number of iterations greater than 1 to go further in the sequences ...
But I'm stuck, the data analysis by my programs for base 3 is still not finished after 20 hours of operation !

OK, page updated.
Base 30 added.

A lot of thanks to all.

The next update will not occur until early August.

Have a great trip! I'll see if I can form some intriguing questions while you're away.:smile:

[QUOTE=EdH;550291]Have a great trip! I'll see if I can form some intriguing questions while you're away.:smile:[/QUOTE]


Thank you very much !
Good luck in your quest.


And don't forget to look at the Neowise Comet, it can be seen with the naked eye (but it's very low on the horizon !) : [URL]https://theskylive.com/c2020f3-info[/URL]


:hello:

[QUOTE=Happy5214;550277]Not conjecture, theorem. If [I]p[/I] = [I]ab[/I] ([I]a[/I], [I]b[/I] > 1), then 2^[I]a[/I]-1 and 2^[I]b[/I]-1 both divide 2^[I]p[/I]-1. Ergo, any number that divides 2^[I]n[/I]-1 will also divide 2^([I]ni[/I])-1, for any [I]i[/I] ≥ 1. That's why exponents for Mersenne primes must themselves also be prime.[/QUOTE]Does this apparent observation fit in with a similar theorem?

For all [I]a[SUP]i[/SUP][/I] ([I]a[/I], [I]i[/I] positive integers ≥ 1)
[I]s[/I]([I]a[SUP]i[/SUP][/I]) is a factor of [I]s[/I]([I]a[SUP](i*n)[/SUP][/I]) (for all positive n)

Example:
[code]
s(7[SUP]3[/SUP]) = [B]3 · 19[/B]
s(7[SUP](3*2)[/SUP]) = 2^3 · [B]3 · 19[/B] · 43
s(7[SUP](3*3)[/SUP]) = [B]3[/B]^2 · [B]19[/B] · 37 · 1063
. . .
s(7[SUP](3*33)[/SUP]) = [B]3[/B]^2 · [B]19[/B] · 37 · 199 · 1063 · 1123 · 3631 · 173647 · 293459 · 1532917 · 12323587 · P44
. . .
[/code]Note also from the above:
[code]
s(7[SUP](3*3)[/SUP]) = [B]3^2 · 19 · 37 · 1063[/B]
. . .
s(7[SUP](3*33)[/SUP]) = [B]3^2 · 19 · 37[/B] · 199 · [B]1063[/B] · 1123 · 3631 · 173647 · 293459 · 1532917 · 12323587 · P44
[/code]Edit: Further study seems to suggest the above is only true for odd [I]a[/I]. Additionally, that [I]a[SUP]i[/SUP]+1 [/I]is a factor of[I][I] s(a[SUP](i*n)[/SUP]) [/I][/I]([I][I]n,[/I][/I] a positive even integer)

If n=13 available for reservation I'd like to reserve range from l=80 to 120 digits.

[QUOTE=unconnected;550506]If n=13 available for reservation I'd like to reserve range from l=80 to 120 digits.[/QUOTE]

Well, I've been working in spurts on n=13 for a couple of years. I have reserved only up to 13^60, but I do plan to cover all of it and I've just 2 sequences left to begin in my reservation to 13^60.

I'm not sure what you mean by "from 80 to 120 digits".... is that the starting size of the sequences, or that you want to take all remaining sequences to 120 digits that I haven't reserved? If you mean the latter, how about we split the rest of the sequences- I'll take up to 13^78, you take 13^80 and up?

I mean that I'll take all sequences from 13^80 to 13^106 and promote them to at least 120 digits. If this is OK for you then I'll start.

[QUOTE=unconnected;550730]I mean that I'll take all sequences from 13^80 to 13^106 and promote them to at least 120 digits. If this is OK for you then I'll start.[/QUOTE]

Excellent! Be my guest.

Also, I'd like to reserve 13^60 up to 13^78. I'll start them next week.

[QUOTE=richs;549946]

Reserving 439^24.[/QUOTE]

439^24 is now at i1448 (added over 1300 iterations with a good downdriver along the way) and a C121 level with a 2^2 * 3 * 5 * 7 guide, so I will drop this reservation. The remaining C118 term is well ecm'ed and is ready for NFS.

Reserving 439^26 at i373.

I've finished [I]n[/I]=21 up to [I]i[/I]=70, and I'll release those sequences. Right now, I'm going to fill in the first row of [I]n[/I]=24 (only 3 sequences left).

@Jean-Luc: My version of primes>1 listings are attached below for all the tables currently on the page. Although my listing has a different format from yours, the details in my base2primes listing contain those for your listing and they all appear to match. I've included all primes that show up more than once within a base, even the smaller ones. I haven't done a check for matching primes across bases.

Here's a brief example of my format compared to yours:

base2primes:
[code]
. . .
prime 197748738449921 shows up 2 times (265, 530).
prime 242099935645987 shows up 2 times (198, 396).
prime 332584516519201 shows up 2 times (191, 382).
. . .
[/code][code]
. . .
base 2 prime 197748738449921 exponent 265
base 2 prime 197748738449921 exponent 530

base 2 prime 242099935645987 exponent 198
base 2 prime 242099935645987 exponent 396

base 2 prime 332584516519201 exponent 191
base 2 prime 332584516519201 exponent 382
. . .
[/code]

I went ahead and did all the preliminary work for base 30030. There are two merges:
[code]
30030^1:i1 merges with 22518:i4
30030^19:i841 merges with 41364:i4
[/code] All the opens are at least 100 dd and the rest are terminated with primes. [strike]Leave it unreserved for now. Someone else can have it, if they want. I'm not sure if I'll take the opens to 120 dd later, or not.[/strike]

Edit: I have decided to go ahead and turn all the transparent cells to a shade of orange. (I've crossed out 30030 in post 280.)

Base 30030 is all colored in and I've attached the list of primes that appear more than once.

Row 520-539 for base 2 has completely turned green (all run down to primes).

I am currently doing all the preliminary work for a table to be added for 2310. I'm not sure if I will color in the transparent cells or not (like before with 30030).

[QUOTE=EdH;551828]. . .
I am currently doing all the preliminary work for a table to be added for 2310. I'm not sure if I will color in the transparent cells or not (like before with 30030).[/QUOTE]
All the preliminary work is done for table 2310 (opens at 100* or better dd, all matched parity terminated with primes). There is one merge:
[code]
2310^1:i1 merges with 1578:i4
[/code]*ECM was not performed on final composites.

[QUOTE=richs;550861]Reserving 439^26 at i373.[/QUOTE]

439^26 is now at i515 (added over 140 iterations) and a C131 level with a 2^2 * 3 * 7 guide, so I will drop this reservation. The remaining C120 term is well ecm'ed and is ready for NFS.

Reserving 439^28 at i407.

[I]n[/I]=24 is done to [I]i[/I]=20, and I'm releasing the sequences below that limit. Next, I'll bring [I]n[/I]=21, [I]i[/I]=70 to 80 up to C120 co-factors.

Sorry for the late update, but I just came back from my vacation...
Page updated.
Thank you all for your hard work !
I ask you to please check if the updates concerning you are correct ?

@EDH : I think we need to modify merges for 2310 and 30030.
[CODE]2310^1:i1 merges with 1578:i4
30030^1:i1 merges with 22518:i4[/CODE]Should be :
[CODE]2310^1:i0 merges with 1578:i3
30030^1:i0 merges with 22518:i3[/CODE]Do you confirm that this change is correct ?



I will now be able to continue quietly to examine all the accumulated data. I will be refining and running my analysis algorithms over the next few days. I'll keep you informed if a conjecture should arise, hoping this time it's not already known !

:smile:

Welcome back, Jean-Luc! I hope you had a great time!

You are correct about both merges. Now I have to find out why my program wasn't. I seem to recall correcting this already. Maybe I used an earlier (incorrect) version somehow.

I stumbled around with a couple things in [URL="https://www.mersenneforum.org/showpost.php?p=550299&postcount=364"]post 364[/URL] that might be of interest. I'm sure I don't have it written out properly, but I don't think the very last one is something that will actually turn up via data review, but it might just be a form of what you already found:
[code]
Additionally, that [I]a[SUP]i[/SUP][/I][I][I]+1[/I] [/I]is a factor of[I][I] s(a[SUP](i*n)[/SUP]) [/I][/I]([I][I]n,[/I][/I] a positive even integer)
[/code]Basically, if I have this correct, [I]a[SUP]i[/SUP]+1[/I] will divide evenly, the Aliquot sum of [I]a[SUP](i*n)[/SUP][/I], if [I]n[/I] is a positive even integer.

Of course, I might be way off with something.

Yes, I did see your posts #364 and #371 and I'll look into it.
But it's going to take me a few days to run the data analysis programs.
The execution times are very long and I don't understand why.
I'll try to shorten these execution times.

I also think that to better notice things, I'll have to modify the program that gives the output :
[CODE]base 2 prime 197748738449921 exponent 265
base 2 prime 197748738449921 exponent 530

base 2 prime 242099935645987 exponent 198
base 2 prime 242099935645987 exponent 396

base 2 prime 332584516519201 exponent 19
base 2 prime 332584516519201 exponent 382[/CODE]In order for the output to become something like this :
[CODE]base 2 prime 197748738449921 exponent 265 at index 1
base 2 prime 197748738449921 exponent 530 at index 1

base 2 prime 242099935645987 exponent 198 at index 1
base 2 prime 242099935645987 exponent 396 at index 1

base 2 prime 332584516519201 exponent 19 at index 1
base 2 prime 332584516519201 exponent 382 at index 1[/CODE]Or something more like your idea that you present in post #371, like this :
[CODE]prime 197748738449921 shows up 2 times (265:i1, 530:i1).
prime 242099935645987 shows up 2 times (198:i1, 396:i1).
prime 332584516519201 shows up 2 times (191:i1, 382:i1).[/CODE]Indeed, for the other bases, one does not always find the repetitions of prime numbers at index 1, and besides, it is generally not at index 1 anymore.
More curious : by manually and laboriously examining (hence the need to automatically examine) the data in your file attached to post #374, it even happens that a large prime number repeats itself twice in two terms at two indexes of the same sequence.
And this may be a coincidence, but I prefer to be sure !
Then I also want to know if large prime numbers repeat more than twice in a single sequence and if so, at which indexes.

I will look into adding indices to my prime listings, but for the the smaller primes, it would cause trouble with lengths of the lines. Is there possibly a lower limit I could use. I think your example showed 10^7, possibly?

I can run the prime listing for a single base in a relatively quick fashion with my setup of bash scripts and compiled C++ program. The script divides the search regions into 8 processes to make use of 8 threads on an i7 and then combines the results for the final file. This helps with array sizes that quickly overrun available space in my program.

I'm not sure what other analyses you might be doing. For a little while I was working with finding duplicate primes (>10^6) across the entire set of tables:
[code]
allpbase11:prime 1000117 shows up 1 time(s) (44).
allpbase13:prime 1000117 shows up 1 time(s) (40).
allpbase2:prime 1000117 shows up 1 time(s) (396).

allpbase14:prime 1000847 shows up 1 time(s) (31).
allpbase2:prime 1000847 shows up 1 time(s) (328).
allpbase3:prime 1000847 shows up 1 time(s) (104).

allpbase15:prime 1001123 shows up 1 time(s) (12).
allpbase2:prime 1001123 shows up 1 time(s) (300).

allpbase10:prime 1002511 shows up 1 time(s) (15).
allpbase1155:prime 1002511 shows up 1 time(s) (4).
allpbase2:prime 1002511 shows up 1 time(s) (312).
allpbase7:prime 1002511 shows up 1 time(s) (70).
. . . [/code]Here's a section for >10^5:
[code]
allpbase10:prime 100049 shows up 1 time(s) (33).
allpbase11:prime 100049 shows up 1 time(s) (24).
allpbase13:prime 100049 shows up 1 time(s) (42).
allpbase14:prime 100049 shows up 2 time(s) (46, 89).
allpbase15:prime 100049 shows up 1 time(s) (12).
allpbase2:prime 100049 shows up 1 time(s) (303).
allpbase21:prime 100049 shows up 1 time(s) (28).
allpbase385:prime 100049 shows up 1 time(s) (4).
allpbase6:prime 100049 shows up 2 time(s) (101, 135).
allpbase7:prime 100049 shows up 1 time(s) (32).

allpbase10:prime 100057 shows up 2 time(s) (33, 95).
allpbase11:prime 100057 shows up 1 time(s) (42).
allpbase12:prime 100057 shows up 1 time(s) (67).
allpbase15:prime 100057 shows up 1 time(s) (12).
allpbase17:prime 100057 shows up 1 time(s) (12).
allpbase2:prime 100057 shows up 1 time(s) (375).
allpbase210:prime 100057 shows up 1 time(s) (25).
allpbase3:prime 100057 shows up 2 time(s) (204).
allpbase5:prime 100057 shows up 1 time(s) (16).
allpbase510510:prime 100057 shows up 1 time(s) (3).
allpbase6:prime 100057 shows up 1 time(s) (81).
allpbase7:prime 100057 shows up 3 time(s) (18, 96).

allpbase11:prime 100103 shows up 1 time(s) (48).
allpbase14:prime 100103 shows up 2 time(s) (43, 81).
allpbase2:prime 100103 shows up 1 time(s) (346).
allpbase496:prime 100103 shows up 1 time(s) (19).
allpbase6:prime 100103 shows up 4 time(s) (29, 73, 81).
allpbase7:prime 100103 shows up 2 time(s) (36, 50).
. . .
[/code](All the blank lines were added after for readability.)

I have added unique* index references. Here is a sample from base2primes:
[code]
prime 162259276829213363391578010288127 shows up 5 times (107:i1, 214:i1, 321:i1, 428:i1, 535:i1).
prime 163537220852725398851434325720959 shows up 4 times (133:i1, 266:i1, 399:i1, 532:i1).
prime 1282816117617265060453496956212169 shows up 2 times (247:i1, 494:i1).
prime 2679895157783862814690027494144991 shows up 3 times (145:i1, 290:i1, 435:i1).
prime 4982397651178256151338302204762057 shows up 2 times (231:i1, 462:i1).
prime 73202300395158005845473537146974751 shows up 2 times (235:i1, 470:i1).
prime 383725126655170964501315730676446647 shows up 2 times (263:i1, 526:i1).
[/code]If you would like, I can provide a full set composed of all the current tables from the table pages.

*Unique means that I do not list the same index of an exponent more than once, so if there is a prime with a power, it is listed only once. e.g. 2^7 at index 12 of a particular sequence would be listed as 2:i12 even though there were seven 2s represented. If the prime occurs on a subsequent index it is listed. The count (X times) still represents the total.

Yes, this is exactly the program I have in mind : a program that allows you to see unique indexes.
Your program execution time is much faster than mine.
So I'm very interested in your new tables with indexes, like in your last post.
But I finally have an idea that will allow me to greatly reduce the data analysis time and I will soon be able to quickly reproduce your calculations.
See my next post to understand what I'm looking for...

[SIZE=4][COLOR=Red]I think I've come up with a new conjecture again.
[/COLOR][/SIZE][SIZE=4][COLOR=Red]I don't know if it's already known, please let me know if it is ?[/COLOR][/SIZE]


This new conjecture concerns on the other hand only one prime number for base 3, but what is new is that we have the presence of this prime number always in the decomposition of two consecutive terms of the sequence !
Here is the statement of the conjecture :
[B]For any aliquot sequence starting with a number of the form 3^(26*k), k integer, the prime number 398581 always appears in the decomposition of the terms of [U]index 1 and index 2[/U].[/B]

This is a small conjecture which concerns only a particular case, but perhaps more general conjectures could be found.

To find this, I proceeded as follows :

1) I found this line in the EdH tables : [CODE]prime 398581 shows up 18 times (26, 52, 78, 104, 130, 156, 182, 208, 234).[/CODE]18 times and only 9 exponents, this is not "usual" ! 18/9=2.

2) I ran a program that makes the indexes appear and I saw this :
[CODE]base 3 prime 398581 exponent 26 at index 1
base 3 prime 398581 exponent 26 at index 2
base 3 prime 398581 exponent 52 at index 1
base 3 prime 398581 exponent 52 at index 2
base 3 prime 398581 exponent 78 at index 1
base 3 prime 398581 exponent 78 at index 2
base 3 prime 398581 exponent 104 at index 1
base 3 prime 398581 exponent 104 at index 2
base 3 prime 398581 exponent 130 at index 1
base 3 prime 398581 exponent 130 at index 2
base 3 prime 398581 exponent 156 at index 1
base 3 prime 398581 exponent 156 at index 2
base 3 prime 398581 exponent 182 at index 1
base 3 prime 398581 exponent 182 at index 2
base 3 prime 398581 exponent 208 at index 1
base 3 prime 398581 exponent 208 at index 2
base 3 prime 398581 exponent 234 at index 1
base 3 prime 398581 exponent 234 at index 2[/CODE]The conjecture then appeared immediately !


I'd like to try and find some more conjectures like that. We have to look at all the bases. But I'm not sure how to write the programs to spot this kind of case !
Maybe for a base, we have to find cases where the number of occurrences of the prime number is a multiple of the number of exponents for which the prime number appears ? In the example above, we have 18/9=2, so we have two indexes per sequence where the prime number 398581 appears and moreover, these indexes are consecutive !
Are there ratios of 3 (3 consecutive or not consecutive indexes), or more ?
Answer in a few days or weeks... And certainly other unexpected things will appear !

I've verified this conjecture up to 3^468. 797161 (2*398581-1) also appears in index 1 of all of the sequences I tested with that starting value form. Did you find that in the ones you tested?

Here is a full set of all the bases represented on the page. I forgot to add the latest lines of the sequences that have been updated within the last couple of days. I will try to fix that soon.

Here are the two primes mentioned above as listed in the new files:

base3primes 398581:
[code]
prime 398581 shows up 18 times (26:i1, 26:i2, 52:i1, 52:i2, 78:i1, 78:i2, 104:i1, 104:i2, 130:i1, 130:i2, 156:i1, 156:i2, 182:i1, 182:i2, 208:i1, 208:i2, 234:i1, 234:i2).
[/code]base3primes 797161:
[code]
prime 797161 shows up 19 times (13:i1, 26:i1, 39:i1, 52:i1, 65:i1, 78:i1, 91:i1, 104:i1, 117:i1, 130:i1, 143:i1, 156:i1, 169:i1, 182:i1, 195:i1, 208:i1, 221:i1, 234:i1, 247:i1).
[/code]

@Happy5214 : Yes, I had noticed for the presence of 797161 but I hadn't seen that 797161 = (2*398581-1) !
I also just noticed that 3^13 ends directly on the prime number 797161 at index 1.
Thank you for checking the conjecture even further !

@EdH : Thank you for these precious tables !
I'm going to look at them very closely tomorrow.


[COLOR=Red]But in just a few minutes I have already noticed exactly the same phenomenon with the 37-digit prime number : [/COLOR]1535090713229126909942383374434289901 which is in the decomposition of all terms in index 1 and 2 of all the sequences that start with 3^(206*k), k integer.
And exactly in the same way, 3^103 also ends directly on a prime number (of 49 digits) : 69575965298821529689922251835887181478451547013. On the other hand, I haven't yet found the relation between these two prime numbers, as Happy5214 did for the previous case !
It's this line of the table that made me see this new similar case :
[CODE]prime 1535090713229126909942383374434289901 shows up 2 times (206:i1, 206:i2).[/CODE]I just checked this new conjecture up to 3^824 and it works fine !

@EdH : I think it would be extremely efficient to generate the tables for the different bases by making only the prime numbers >= 10^4 appear and which in addition to that, also appear at several indexes in the same sequence !
I'll be able to do this myself in a few days, but maybe for you it's not too complicated and I'll see the results a few days in advance...
No problem for me if you want to stop now and not generate these new tables, because all this is really a lot of work and requires really a lot of time !


:smile: