mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Aliquot Sequences (https://www.mersenneforum.org/forumdisplay.php?f=90)
-   -   Aliquot sequences that start on the integer powers n^i (https://www.mersenneforum.org/showthread.php?t=23612)

RichD 2021-02-14 13:35

More merges? 43^16 & 43^34

EdH 2021-02-14 15:30

[QUOTE=garambois;571573]. . .
Edit : When I look at the tables for bases 37 and 41, I think we forgot some merges, especially for base 37 ! But sorry, I really don't have enough time today to take care of this ! I will see for the next update ...[/QUOTE]I have a script that will run a whole table against current sequences checking for merges. I'll run it on all the new tables and see what it turns up. At that point there will be a list that can be referenced instead of digging through posts. I'll try to have that later today.

Note that it uses the 80 digit file, so it won't pick up those few merges we found that are outside that.

garambois 2021-02-14 15:48

[QUOTE=EdH;571585]I have a script that will run a whole table against current sequences checking for merges. I'll run it on all the new tables and see what it turns up. At that point there will be a list that can be referenced instead of digging through posts. I'll try to have that later today.

Note that it uses the 80 digit file, so it won't pick up those few merges we found that are outside that.[/QUOTE]


OK, many thanks for your help, because I don't have a script : I look for the mergers manually and it can take a long time !
Does it use my 80 digit file, on my website ?
Because I know that I will also have to update this file : in a year, things move because of the sequences which merge and which end !
And I hope that when I scan the over 27,000 sequences in the main project, I won't find any broken aliquot sequences !

EdH 2021-02-14 16:06

[QUOTE=garambois;571587]OK, many thanks for your help, because I don't have a script : I look for the mergers manually and it can take a long time !
Does it use my 80 digit file, on my website ?
Because I know that I will also have to update this file : in a year, things move because of the sequences which merge and which end !
And I hope that when I scan the over 27,000 sequences in the main project, I won't find any broken aliquot sequences ![/QUOTE]Yes, it uses your 80 digit file (currently the 2020 version). My script still has the i0/i1 error, so I have to remember to manually check those, but the others "seem" to be correct when I do spot checks. I, too, hope this year brings a set with no broken sequences.

I have some expansion to do with my script, so I can call it easier and I need to address the i0/i1 error. At some point, if I get it working the way I'd like, I'll post it here. It's a simple Bash script that runs on one of my RPi machines.

Here are some runs for today:
[code]
Running base 37:
37^6:i126 merges with 109920:i1275
37^8:i151 merges with 1632:i37
37^12:i1057 merges with 10824:i28
37^18:i1430 merges with 3366:i2
37^22:i519 merges with 1567300:i0 (*Manually fixed*)
37^30:i1193 merges with 35856:i3
Done in 221 seconds.

Running base 41:
41^4:i66 merges with 36468:i17
41^32:i386 merges with 271980:i46
Done in 108 seconds.

Running base 43:
43^16:i204 merges with 1299520:i4
43^34:i639 merges with 5208:i10
Done in 109 seconds.

Running base 450:
Done in 24 seconds.

Running base 882:
Done in 19 seconds.

Running base 33550336:
Done in 34 seconds.
[/code]

RichD 2021-02-14 16:19

[QUOTE=EdH;571585]I have a script that will run a whole table against current sequences checking for merges. I'll run it on all the new tables and see what it turns up. At that point there will be a list that can be referenced instead of digging through posts. I'll try to have that later today.

Note that it uses the 80 digit file, so it won't pick up those few merges we found that are outside that.[/QUOTE]

@EdH: You can include base 43 in your script. All exponents (up to 77) are initialized but not ready to be inserted in the master table.

Edit: Oops, late to party for posting...

EdH 2021-02-14 17:07

[QUOTE=RichD;571589]@EdH: You can include base 43 in your script. All exponents (up to 77) are initialized but not ready to be inserted in the master table.

Edit: Oops, late to party for posting...[/QUOTE]No problem, Rich. I hadn't gone all the way to i=77, so I reran it to 77, and it turned out the same, anyway..

Unfortunately, I looked at my script and found it calls a C++ program that I wrote to do part of the work, so it's a little more complicated than I considered before. I'll have to see if I can translate the C++ portion into Bash, if I'm going to post a script here. This may be a while.

garambois 2021-02-14 18:12

OK, thanks for the mergers. I suspected that there would be a lot for base 37. I will check these mergers before the next update.
It is difficult for me to find mergers, but it is much faster for me to verify them.
Edwin, I hope I can use the script you are going to send us !

EdH 2021-02-14 23:02

[QUOTE=garambois;571594]. . .
Edwin, I hope I can use the script you are going to send us ![/QUOTE]
Well, I see now why I used a C++ program with my Bash script - I'm working on a purely Bash script and finding that what my original Bash/C++ setup did in a few seconds, it is taking the purely Bash script many minutes to perform. It is taking two minutes just to read the 80 digit text file into two arrays!

i might just provide the C++ program and the compile command line. But, I need to clean it up first.

More later. . .

EdH 2021-02-15 01:23

1 Attachment(s)
The pure Bash script appears to take about 6 times longer to run, but a second script can call the first multiple times and can be left to walk through tables overnight.

A sample run:
[code]
$ bash alimerge3.sh 37 1 80
Reading OE_3000000_C80.txt . . . done! (104 seconds)
Checking base 37 from 1 through 80 . . .
37^6:i126 merges with 109920:i1275
37^8:i151 merges with 1632:i37
37^12:i1057 merges with 10824:i28
37^18:i1430 merges with 3366:i2
37^22:i519 merges with 1567300:i0
37^30:i1193 merges with 35856:i3
Run time: 1211 seconds
[/code]

Here's the script:
[code]
#!/bin/bash
###################################################################
### This script is designed to find merges in the tables at the ###
### "Aliquot sequences starting on integer powers n^i" page: ###
### http://www.aliquotes.com/aliquotes_puissances_entieres.html ###
### To use this script, you first need a copy of the 80 digit ###
### file "OE_3000000_C80.txt" found at: ###
### http://www.aliquotes.com/OE_3000000_C80.txt ###
### If the file is not found in the working directory, a prompt ###
### allows it to be downloaded. Then, supply a command line ###
### with the base, first and last exponents to check. ###
### For example: ###
### $ bash <this script name> 37 1 80 ###
### Alternately, you can just call the script and it will ###
### prompt for the base, first and last values. ###
###################################################################

IFS='
'
declare -a seqs
declare -a C80s
scount=0

if [ ${#1} -lt 1 ]
then
printf "Base: "
read base
else
base=${1}
fi

if [ ${#2} -lt 1 ]
then
printf "Starting exponent: "
read start
else
start=${2}
fi

if [ ${#3} -lt 1 ]
then
printf "Last exponent: "
read last
else
last=${3}
fi

if [ ! -e OE_3000000_C80.txt ]
then
echo "OE_3000000_C80.txt not found! Retrieve it from:"
echo "http://www.aliquotes.com/OE_3000000_C80.txt?"
printf "(y/[n]): "
read retyn in
if [ "$retyn" == "y" ]
then
wget "http://www.aliquotes.com/OE_3000000_C80.txt" -q -O OE_3000000_C80.txt
fi
fi

if [ -e OE_3000000_C80.txt ]
then
printf "Reading OE_3000000_C80.txt . . . "
exec <"OE_3000000_C80.txt"
while read line
do
case $line in
" "*) temp=${line:1}
space=$(echo `expr index "$temp" \ `)
seqs[scount]=${temp:0:${space}-1}
C80s[scount]=${temp:${space}}
let scount=${scount}+1
;;
esac
done
echo "done! ($SECONDS seconds)"
fi

if [ $scount -gt 1000 ]
then
echo "Checking base ${base} from ${start} through ${last} . . ."
for (( i = ${start}; i <= ${last}; i++ ))
do
tempC80=""
aliseq1=""
wget "http://www.factordb.com/elf.php?seq=${base}^${i}&type=1" -q -O aliseq0
exec <"aliseq0"
while read line
do
period=$(echo `expr index "$line" .`)
equals=$(echo `expr index "$line" =`)
let diff=${equals}-${period}
if [ $diff -eq 85 ]
then
tempC80="${line:${period}+3:80}"
fi
done
if [ ${#tempC80} -eq 80 ]
then
for (( j = 0; j < $scount; j++ ))
do
if [ "${tempC80}" == "${C80s[$j]}" ]
then
aliseq1=${seqs[$j]}
fi
done
fi
if [ ${#aliseq1} -gt 2 ]
then
declare -a tempseq0
ali0i=0

exec <"aliseq0"
while read line0
do
period=$(echo `expr index "$line0" .`)
tempseq0[$ali0i]=${line0:${period}}
let ali0i=${ali0i}+1
done

wget "http://www.factordb.com/elf.php?seq=${aliseq1}&type=1" -q -O aliseq1
declare -a tempseq1
ali1i=0
exec <"aliseq1"
while read line1
do
period=$(echo `expr index "$line1" .`)
tempseq1[$ali1i]=${line1:${period}}
let ali1i=${ali1i}+1
done

for (( k = 0; k < $ali0i; k++ ))
do
for (( l = 0; l < $ali1i; l++ ))
do
if [ "${tempseq0[$k]}" == "${tempseq1[$l]}" ]
then
echo "$base^${i}:i${k} merges with ${aliseq1}:i${l}"
l=$ali1i
k=$ali0i
fi
done
done
unset tempseq0
unset tempseq1
fi
done
fi

echo "Run time: $SECONDS seconds"
[/code]The script is also attached below.

Happy5214 2021-02-15 01:36

[QUOTE=EdH;571614]The pure Bash script appears to take about 6 times longer to run, but a second script can call the first multiple times and can be left to walk through tables overnight.

[Code blocks omitted.][/QUOTE]

A couple of notes. One, can you reformat the existence test for OE_3000000_C80.txt to retrieve it using wget if it's not already there? Second, you wouldn't need to say "bash" on the command line if the shebang were formatted properly. It's basically useless as it is.

EdH 2021-02-15 02:18

[QUOTE=Happy5214;571615]A couple of notes. One, can you reformat the existence test for OE_3000000_C80.txt to retrieve it using wget if it's not already there? Second, you wouldn't need to say "bash" on the command line if the shebang were formatted properly. It's basically useless as it is.[/QUOTE]
Thanks! I fixed the shebang. I always use "bash " because if I don't, I have to manually change the permissions to reflect "Allow executing file as program" for any script I write.

I'll add the file retrieval if not found. I normally shy away from adding that into scripts, but in this case, the script is already going to the db for files. Maybe I'll add it as a choice. Let me play with it a bit before I change it here.

Edit: OK, I added the option to download the 80 digit file. . .

Thanks for all the help, Happy5214!

EdH 2021-02-15 13:34

Anyone who has looked at my script for Aliquot merges, please see the note in the [URL="https://www.mersenneforum.org/showpost.php?p=571614&postcount=785"]original post[/URL]. Any assistance would be appreciated.

Happy5214 2021-02-15 13:49

[QUOTE=EdH;571648]Anyone who has looked at my script for Aliquot merges, please see the note in the [URL="https://www.mersenneforum.org/showpost.php?p=571614&postcount=785"]original post[/URL]. Any assistance would be appreciated.[/QUOTE]
All of the lines in the code block have trailing spaces.

EdH 2021-02-15 14:09

[QUOTE=Happy5214;571649]All of the lines in the code block have trailing spaces.[/QUOTE]Thank You! For all but one line, it probably wouldn't matter, but:
[code]
IFS='
'
[/code]was truly corrupted.

Now, both the code block and the attachment work for me.

Much appreciated!

garambois 2021-02-15 17:40

Many, many thanks Edwin !
I manage to get this program to work !
This tool will be very valuable to me !
I'll keep it running regularly and I keep you posted if I spot any malfunctions.

Did I understand correctly, you also have a C++ program that does this job faster ? This other program would also interest me.

EdH 2021-02-15 18:32

[QUOTE=garambois;571665]Many, many thanks Edwin !
I manage to get this program to work !
This tool will be very valuable to me !
I'll keep it running regularly and I keep you posted if I spot any malfunctions.

Did I understand correctly, you also have a C++ program that does this job faster ? This other program would also interest me.[/QUOTE]Thanks for letting me know it works for you and all feedback is quite welcome.

Actually, my local script calls two C++ programs to accomplish what the provided one does. I think I can speed up the posted script by better use of arrays, though. I plan to do some study in that direction before I work much more with the C++ programs, although I'm sure a fully C++ program would still be considerably faster.

RichD 2021-02-15 19:52

Base 43 can be added at the next update. All expected terminating sequences are terminated and all remaining composites are greater than C78.

Starting initial work on base 47.

EdH 2021-02-16 19:34

1 Attachment(s)
[QUOTE=garambois;571665]. . .
Did I understand correctly, you also have a C++ program that does this job faster ? This other program would also interest me.[/QUOTE]Here is the source for a C++ program. I'm afraid it's probably a bit "amateurish," and it has very little internal commenting, but it should compile on linux with:
[code]
g++ alimerge3.cpp -o alimerge3
[/code]and can then be invoked by:
[code]
./alimerge3 37 1 80
[/code]to run the entire base 37 table. Here's an example (wrapped in date calls to provide timing)*:
[code]
$ date;./alimerge3 37 1 80;date
Tue 16 Feb 2021 02:19:01 PM EST
Running base 37 from 1 through 80 . . .
37^6:i126 merges with 109920:i1275
37^8:i151 merges with 1632:i37
37^12:i1057 merges with 10824:i28
37^18:i1430 merges with 3366:i2
37^22:i519 merges with 1567300:i0
37^30:i1193 merges with 35856:i3
Tue 16 Feb 2021 02:22:27 PM EST [/code]That comes in at about 3:26 to run the entire base 37 table. That's about 206 vs. 1211 seconds for the Bash version.

* I tried to add an elapsed time function, but for some reason the timing was extremely inaccurate with the several methods I tried, so I left it out.

garambois 2021-02-17 08:06

[QUOTE=RichD;571672]Base 43 can be added at the next update. All expected terminating sequences are terminated and all remaining composites are greater than C78.

Starting initial work on base 47.[/QUOTE]


OK, a lot of thanks !
The next update will be next weekend.

garambois 2021-02-17 08:34

[QUOTE=EdH;571769]Here is the source for a C++ program.[/QUOTE]


OK, a lot of thanks !
I will test this program very quickly, but I can't get it to work at the moment, I don't know why yet ?

Otherwise, more generally, in three days, I will be on vacation.
I will try to do some data analysis.
Hopefully the large amount of new data accumulated allows us to formulate new small conjectures ... that is our goal !

:smile:

EdH 2021-02-17 13:54

[QUOTE=garambois;571790]OK, a lot of thanks !
I will test this program very quickly, but I can't get it to work at the moment, I don't know why yet ?

Otherwise, more generally, in three days, I will be on vacation.
I will try to do some data analysis.
Hopefully the large amount of new data accumulated allows us to formulate new small conjectures ... that is our goal !

:smile:[/QUOTE]The source code I provided works under various linux machines here, compiling with no issues. It even compiles on my RPi machines. Let me know of any errors/warnings if any occur. I do now have a version that includes timing. If I add that one, I'll still leave the other.

The source should compile on Windows, as well, but it's been so long since I've worked with Windows, that I wouldn't be able to even try.

If there is some data in particular you'd like harvested, let me know and I can try to do that as well. I'm trying to keep a local up-to-date set of all the tables, at the ready for such work.

Have a Great Vacation!

garambois 2021-02-17 18:27

Most of this vacation, I am going to work on the aliquot sequences. I have already started the preliminary work, I am writing and running programs.

But I would need a little help !

Would someone be able to calculate the following sequences, but only up to index 2, and of course, to enter the results on factordb :
(9699690 * 23)^20
(9699690 * 23 * 29 * 31)^14
(9699690 * 23 * 29 * 31 * 37)^14
Indeed, my computer is very busy and that would allow me to have the results already next weekend.
I still need more sequences, but the calculations will be shorter and I can handle them.

@Edwin : I'm on a track... Since I looked again at your "2-Stats.txt" file ([URL="https://www.mersenneforum.org/showthread.php?t=23612&page=31#339"]from here[/URL]), I got a new idea because of the fourth column.

But I have to do some more analysis to be sure that it is worth it that I expose you on this forum what I noticed. The calculations I am requesting above relate to this work.

EdH 2021-02-17 19:04

I have queued up index 1 for both of the first two, but they will take a little while to finish. Do you need index 2 also fully factored or just reach index 2? The bulk of my machines are running a rather large job right now, so I am somewhat limited.

garambois 2021-02-17 20:59

[QUOTE=EdH;571826]I have queued up index 1 for both of the first two, but they will take a little while to finish. Do you need index 2 also fully factored or just reach index 2? The bulk of my machines are running a rather large job right now, so I am somewhat limited.[/QUOTE]


I need just to reach index 2 but not to factor. Thank you very much Edwin !

EdH 2021-02-17 22:23

[QUOTE=garambois;571840]I need just to reach index 2 but not to factor. Thank you very much Edwin ![/QUOTE]
The first two are at index 2. The third is in work.

garambois 2021-02-17 22:33

Thank you very much Ed !

EdH 2021-02-18 00:49

[QUOTE=garambois;571825]. . .
(9699690 * 23 * 29 * 31 * 37)^14
. . .[/QUOTE]Third one is at index 2, also.

Glad to be helpful. I'm looking forward to your findings.

garambois 2021-02-18 17:10

[QUOTE=EdH;571862]Third one is at index 2, also.

Glad to be helpful. I'm looking forward to your findings.[/QUOTE]




Thanks a lot.
These calculations would have really taken me a lot more time !

EdH 2021-02-18 19:38

[QUOTE=garambois;571922]Thanks a lot.
These calculations would have really taken me a lot more time ![/QUOTE]You're quite welcome.

Have you been looking into updating the 80 digit file? If not, you might want to wait just a bit longer. I'm playing with some stuff that will probably allow me to create an updated file in the near future. If this all works well, I hope later updates will be even easier and maybe even C30/C60, etc. will be easy.

garambois 2021-02-18 20:02

Yes, I am planning to update the C80 digit file very quickly. But the scan of the 27,000 sequences takes several days (21 days !).
I will also create a C80 file for all the Open End sequences in our project, as advertised here :
[URL]https://www.mersenneforum.org/showthread.php?t=23612&page=65#714[/URL]
Please keep me posted if you are doing any work in this direction as well !

EdH 2021-02-18 21:15

[QUOTE=garambois;571938]Yes, I am planning to update the C80 digit file very quickly. But the scan of the 27,000 sequences takes several days (21 days !).
I will also create a C80 file for all the Open End sequences in our project, as advertised here :
[URL]https://www.mersenneforum.org/showthread.php?t=23612&page=65#714[/URL]
Please keep me posted if you are doing any work in this direction as well ![/QUOTE]
I'm doing some experiments now, that will provide some better info, but initial results seem to point to me being able to get all 27645 sequences in a timely manner, and then use the local set for all my "playing."

My overall intention is to create a local set of all open sequences (<3M). Then, create scripts (or C++ programs) for the following:
- Update entire set by comparing last lines and only retrieving sequences that have changed since the last time run - to be used only a couple times a year.
- Create lists of last occurrences of various digit sizes (C9/C30/C60/C80).
- Check for merges against local sequences rather than the db. Since the C80 listing will reflect data harvested from the local set, there should not be a need to check against the db.
- Whatever else I may think of.

I already have a local copy of all the sequences in the base tables, and a method to update all open sequences in all the tables. I should be able to create a script to harvest C9/C30/C60/C80 lists from that, as well. I will consider it.

Of course, all this hinges on my ability to actually create the scripts. But, I will update here as I progress.

Edit: It looks like I'm able to d/l 1000 .elfs in a little over two hours without the db being anywhere near complaining. I don't plan to let it run unattended overnight, so I'm probably looking at a few days to complete the set. But, I don't need the full set to begin writing scripts.

EdH 2021-02-18 23:38

Addendum to last post
 
I also intend to search the new set for any new merges or terminations that may have occurred. I plan to have that done by the script(s), to try to remove as much as possible the need for manual intervention.

I do wonder how much the list will have really changed over the past 9 months. Most of those sequences were well over 80 digits and probably few fell that far again. A quick examination of the first 100 sequences didn't reveal any difference between a new list and last year's. But, then, again, most of the work was probably in the higher sequences.

RichD 2021-02-19 09:12

Base 47 can be added at the next update - to i=45.. There is still many computations to be done. There is also a merge but I didn't record it because we have this new tool.

EdH 2021-02-19 13:32

450^49 and 450^50 have turned green.

578 is finished (green) through 578^50, with the exceptions of 578^46, 578^49 and 578^50, which are in work.

RichD 2021-02-19 14:21

[QUOTE=RichD;571997]Base 47 can be added at the next update - to i=45.. There is still many computations to be done. There is also a merge but I didn't record it because we have this new tool.[/QUOTE]

Correction: i through 75.

EdH 2021-02-19 14:46

[QUOTE=RichD;571997]Base 47 can be added at the next update - to i=45.. There is still many computations to be done. There is also a merge but I didn't record it because we have this new tool.[/QUOTE]
Actually, it shows two:
[code]
Running base 47 from 1 through 75 . . .
47^4:i1 merges with 106080:i0
47^40:i1455 merges with 875060:i6
Run took 92 seconds.
[/code]I will try to run it against the entire set of tables later today and make a list of any merges not already noted.

garambois 2021-02-19 17:39

[QUOTE=EdH;571949]I'm doing some experiments now, that will provide some better info, but initial results seem to point to me being able to get all 27645 sequences in a timely manner, and then use the local set for all my "playing."

My overall intention is to create a local set of all open sequences (<3M). Then, create scripts (or C++ programs) for the following:
- Update entire set by comparing last lines and only retrieving sequences that have changed since the last time run - to be used only a couple times a year.
- Create lists of last occurrences of various digit sizes (C9/C30/C60/C80).
- Check for merges against local sequences rather than the db. Since the C80 listing will reflect data harvested from the local set, there should not be a need to check against the db.
- Whatever else I may think of.

I already have a local copy of all the sequences in the base tables, and a method to update all open sequences in all the tables. I should be able to create a script to harvest C9/C30/C60/C80 lists from that, as well. I will consider it.

Of course, all this hinges on my ability to actually create the scripts. But, I will update here as I progress.
[/QUOTE]


I will follow your work closely if you share it with us here.

At the moment, I'm having a hard time figuring out the usefulness of creating a list of the last occurrences of various digit size : C9 / C30 / C60 / C80.
Isn't it enough to create C80 ? With C80, you are sure to find the right fusion sequence. The risk that a C9 belongs to two sequences of the main project does not seem negligible to me, but it should be checked.
Also, if a sequence is yo-yoing, there is no reason the merge occurred during the last "low peak". The merger may have occurred on an earlier "low peak" (Merges almost always occur on the low peaks).
But you must have your reasons for wanting to create lists of last occurrences of various digit sizes (C9/C30/C60/C80).



[QUOTE=EdH;571949]
Edit: It looks like I'm able to d/l 1000 .elfs in a little over two hours without the db being anywhere near complaining. I don't plan to let it run unattended overnight, so I'm probably looking at a few days to complete the set. But, I don't need the full set to begin writing scripts.[/QUOTE]


1000 downloads of .elf in 2 hours : This is not at all what I experienced in April 2020. I had instead a speed of an .elf file in 60 seconds.
So this is very good news, maybe factodb's server is much faster now. I will give it a try over the next week.



[QUOTE=EdH;571966]I also intend to search the new set for any new merges or terminations that may have occurred. I plan to have that done by the script(s), to try to remove as much as possible the need for manual intervention.

I do wonder how much the list will have really changed over the past 9 months. Most of those sequences were well over 80 digits and probably few fell that far again. A quick examination of the first 100 sequences didn't reveal any difference between a new list and last year's. But, then, again, most of the work was probably in the higher sequences.[/QUOTE]


There really isn't a lot of change in a year. Each year you have to delete the sequences that have ended or that have merged with a smaller one from the main project.
These are the ones that are reported on the last pages of this topic :
[URL]https://www.mersenneforum.org/showthread.php?t=11837[/URL]

garambois 2021-02-19 17:43

@RichD : Thank you very much for your work on base 47.

@Edwin : Thank you very much for your work on bases 450 and 578.

garambois 2021-02-19 17:57

[QUOTE=EdH;572018]Actually, it shows two:
[code]
Running base 47 from 1 through 75 . . .
47^4:i1 merges with 106080:i0
47^40:i1455 merges with 875060:i6
Run took 92 seconds.
[/code]I will try to run it against the entire set of tables later today and make a list of any merges not already noted.[/QUOTE]


Thank you for all this, because it is a help that makes things easier for me !

A few days ago, I also realized that some mergers already noted on our project page could become obsolete.
Indeed, if one of our sequence n^i has merged with a sequence of the main project and that then, this sequence of the main project has merged with another smaller sequence of the main project, the fusion noted on our page then becomes false !
Periodically, I will therefore have to run your script which automatically detects the mergers and check them all, even those already noted on my project page !
This represents an additional amount of work !

EdH 2021-02-19 18:43

[QUOTE=garambois;572031]I will follow your work closely if you share it with us here.

At the moment, I'm having a hard time figuring out the usefulness of creating a list of the last occurrences of various digit size : C9 / C30 / C60 / C80.
. . [/QUOTE]I am also not thinking of a need for C9/C30/C60 ATM, but remember them being done in the past and the addition to (or removal from) my script is simple. I will be sharing my adventures with this thread, as I am hoping what I do is of benefit to the project, rather than just myself.
[QUOTE=garambois;572031]1000 downloads of .elf in 2 hours : This is not at all what I experienced in April 2020. I had instead a speed of an .elf file in 60 seconds.
So this is very good news, maybe factodb's server is much faster now. I will give it a try over the next week. [/QUOTE]I do think this is a speedup since last year. At this point, I have d/led >11k sequences.

I am using the AllSeq.txt from the "Blue Page" and intend to check any changes from your 2020 file. Is there a better source (other than your 2020 file)?

[QUOTE=garambois;572031]There really isn't a lot of change in a year. Each year you have to delete the sequences that have ended or that have merged with a smaller one from the main project.
These are the ones that are reported on the last pages of this topic :
[URL]https://www.mersenneforum.org/showthread.php?t=11837[/URL][/QUOTE]I already have a script that can run the entire set looking for terminations, once I have all the sequences. I also intend to have a script that will check the C80 file itself for merges. My hope is to cut down on the need for manual searches.

EdH 2021-02-19 18:51

[QUOTE=garambois;572034]Thank you for all this, because it is a help that makes things easier for me !

A few days ago, I also realized that some mergers already noted on our project page could become obsolete.
Indeed, if one of our sequence n^i has merged with a sequence of the main project and that then, this sequence of the main project has merged with another smaller sequence of the main project, the fusion noted on our page then becomes false !
Periodically, I will therefore have to run your script which automatically detects the mergers and check them all, even those already noted on my project page !
This represents an additional amount of work ![/QUOTE]I'm guessing there will still be some manual checking needed, to compare a new run of merges with those in the tables. I will see how involved it is when I have a complete list. I can already see that there will be quite a few merges to check, with all the tables we now have. The total run itself is plodding along rather slowly. It is only on base 14 right now. But, with the larger bases, there will be less sequences, so it should speed up near the end. Maybe I can add a method to compare what's on the page with what is in the run and flag any out-of-date merge info.

garambois 2021-02-19 20:30

[QUOTE=EdH;572041]I am also not thinking of a need for C9/C30/C60 ATM, but remember them being done in the past and the addition to (or removal from) my script is simple. I will be sharing my adventures with this thread, as I am hoping what I do is of benefit to the project, rather than just myself.

I already have a script that can run the entire set looking for terminations, once I have all the sequences. I also intend to have a script that will check the C80 file itself for merges. My hope is to cut down on the need for manual searches.[/QUOTE]


[QUOTE=EdH;572044]I'm guessing there will still be some manual checking needed, to compare a new run of merges with those in the tables. I will see how involved it is when I have a complete list. I can already see that there will be quite a few merges to check, with all the tables we now have. The total run itself is plodding along rather slowly. It is only on base 14 right now. But, with the larger bases, there will be less sequences, so it should speed up near the end. Maybe I can add a method to compare what's on the page with what is in the run and flag any out-of-date merge info.[/QUOTE]


Thank you for all this information and for all the work.
I look forward to your results and conclusions !

garambois 2021-02-19 20:33

[QUOTE=EdH;572041]
I am using the AllSeq.txt from the "Blue Page" and intend to check any changes from your 2020 file. Is there a better source (other than your 2020 file)?
[/QUOTE]


Personally, I don't know of any other source.

EdH 2021-02-19 23:22

Ok, I have some scripts that allow me to check the entire set of tables for sequences that merge. Then, they check to see if the merge is already listed in a table and provide a list of those already within the tables (found) and a list of those not already within the tables (missing). They then list those two sets:
[code]
These merges were already present:
3^10:i15 merges with 1134:i9
3^14:i2 merges with 158814:i544
3^28:i429 merges with 25968:i10
3^42:i418 merges with 186192:i15
3^48:i400 merges with 27450:i55
3^58:i1001 merges with 40092:i6
3^74:i1432 merges with 619200:i4
3^204:i1060 merges with 4788:i6
5^6:i1 merges with 3906:i0
5^8:i3 merges with 564:i12
5^14:i98 merges with 607386:i315
5^22:i265 merges with 660:i21
5^26:i229 merges with 1134:i9
5^28:i165 merges with 20208:i10
6^7:i9 merges with 95280:i20
6^67:i890 merges with 27860:i2
6^81:i703 merges with 388600:i7
7^10:i18 merges with 171040:i1
7^12:i153 merges with 121392:i168
7^20:i1345 merges with 660:i25
7^96:i1267 merges with 4788:i6
10^9:i24 merges with 31240:i2
10^19:i273 merges with 11408:i15
10^29:i450 merges with 14022:i19
10^31:i324 merges with 64980:i48
10^71:i831 merges with 42532:i2
10^129:i2229 merges with 2173380:i159
11^4:i1 merges with 1464:i0
11^10:i257 merges with 45792:i35
11^24:i2001 merges with 903872:i5
12^15:i294 merges with 3366:i2
12^19:i120 merges with 23324:i10
12^29:i790 merges with 1778224:i0
12^35:i380 merges with 3876:i5
12^43:i488 merges with 2484:i8
12^47:i1301 merges with 1374120:i189
13^14:i50 merges with 555300:i10
13^16:i660 merges with 14320:i25
13^30:i728 merges with 3876:i11
14^7:i21 merges with 2484:i9
14^13:i262 merges with 167748:i33
14^31:i1396 merges with 65208:i6
15^4:i3 merges with 3432:i69
15^8:i77 merges with 147150:i17
15^12:i3841 merges with 368688:i2
15^18:i98 merges with 81600:i354
15^28:i976 merges with 81084:i14
15^42:i819 merges with 3366:i2
17^4:i21 merges with 1632:i37
17^6:i1 merges with 967278:i4
19^14:i765 merges with 755460:i25
20^7:i60 merges with 7044:i129
20^9:i27 merges with 709900:i10
20^37:i1855 merges with 660:i25
21^4:i46 merges with 6552:i4
22^5:i19 merges with 86388:i4
22^29:i321 merges with 5208:i6
22^41:i1065 merges with 14676:i15
23^12:i144 merges with 78660:i2
23^44:i1830 merges with 7560:i251
24^17:i282 merges with 29022:i20
24^25:i329 merges with 620712:i514
26^15:i350 merges with 2360:i4
26^35:i503 merges with 87612:i4
26^55:i458 merges with 871000:i0
28^21:i4035 merges with 818880:i7
29^6:i51 merges with 2441868:i4
29^15:i37 merges with 18528:i0
30^43:i2207 merges with 39060:i2
31^4:i2 merges with 14100:i2
31^18:i241 merges with 25396:i984
33^8:i275 merges with 48024:i10
33^10:i94 merges with 1009656:i2
37^18:i1430 merges with 3366:i2
41^32:i386 merges with 271980:i46
79^52:i2041 merges with 660:i25
210^13:i320 merges with 50064:i101
284^3:i701 merges with 21432:i50
385^4:i403 merges with 903872:i5
385^6:i244 merges with 3876:i5
496^3:i168 merges with 22908:i1
770^3:i29 merges with 165876:i98
1155^4:i36 merges with 1290378:i273
1155^6:i112 merges with 25968:i10
2310^1:i0 merges with 1578:i3
30030^1:i0 merges with 22518:i3
30030^19:i841 merges with 41364:i4
510510^1:i4 merges with 425052:i7

These merges were not found:
15^88:i963 merges with 562032:i26
30^3:i0 merges with 27000:i0
37^6:i126 merges with 109920:i1275
37^8:i151 merges with 1632:i37
37^12:i1057 merges with 10824:i28
37^22:i519 merges with 1567300:i0
37^30:i1193 merges with 35856:i3
41^4:i66 merges with 36468:i17
47^4:i1 merges with 106080:i0
47^40:i1455 merges with 875060:i6
[/code]I did just a few spot checks and all "seemed" accurate, but please check them for validity.

I will need to do more work on the scripts before I post them (possibly combining them into one), but I wanted to get the above to you for use for the next update.

Edit: If a new merge has replaced an old merge, it should just show as listed in the "not found" group, since the index numbers will have been different.

garambois 2021-02-20 08:43

WAOUH, WAOUH, WAOUH !!!

But how did you manage to write such a program ? What a fantastic, wonderful tool !
I suspected that there were sequences which merged but which were not listed, like 15^88 !
A very big thank you for this work : "He removes a thorn from our foot" (We say that in French !).

For 30^3, I knew about it ! But your program is beautifully written if it detected it. Indeed, 30^3 = 27000.
It is therefore not a merger, it cannot merge with itself.
Do you think I should note this fusion with himself on the project page ?
Note that 30^3 is the only Open-End sequence that belongs to our project and to the main project at the same time.
I already wanted to calculate it, but I don't have enough computing power right now.

EdH 2021-02-20 15:00

[QUOTE=garambois;572069]WAOUH, WAOUH, WAOUH !!!

But how did you manage to write such a program ? What a fantastic, wonderful tool !
I suspected that there were sequences which merged but which were not listed, like 15^88 !
A very big thank you for this work : "He removes a thorn from our foot" (We say that in French !).

For 30^3, I knew about it ! But your program is beautifully written if it detected it. Indeed, 30^3 = 27000.
It is therefore not a merger, it cannot merge with itself.
Do you think I should note this fusion with himself on the project page ?
Note that 30^3 is the only Open-End sequence that belongs to our project and to the main project at the same time.
I already wanted to calculate it, but I don't have enough computing power right now.[/QUOTE]I totally glossed over the i0=i0. Very unobservant of me. It isn't something to note. Rather I wonder if I should provide a filter to remove it from future listings. I probably won't since we are aware of it, and as you say, it isn't a merger, just a hit with the 80 digit file.

Speaking of the 80 digit file, I'm at 20k of the downloads. I ran my termination detection across those I already had at the time, with no hits, but if the AllSeq.txt from the Blue Page is anything near current, I shouldn't get any hits at this time. That may not be true of merges within the AllSeq.txt. If nothing has changed in merge detection for the Blue Page, it is quite possible (maybe even probable) that there will be undetected merges. That's one of the next scripts I'll be working on.

I still need to find a way to compare last lines, so I can limit updates to those sequences that have changed. Then I can do full set updates in a much more timely manner. I'm actually going to be doing that with my table sets, as well. In the past, I've been updating the full set by downloading the entire .elf for any that weren't terminated. But, the number of tables (and, therefore sequences) has grown considerably since then. As soon as I do another full update of the table .elfs, I'll work on an 80 digit file for them, too.

My "farm" is quite tied up with a larger job than I expected, or should have tried. It may well be into next month before I can even free the bulk of the machines and then my main machine will be busy for a long time with the LA, if I'm able to actually do it. Otherwise, I could run the c151 for 27000. [STRIKE]I wonder, since it is an open sequence of the main project, if we might make a case for it to become a Team Project like 276, 3408, 3366 and 4788. All of those mentioned are at uncomfortably high composites. Maybe we could make a case for working this one, in that it is the only known open-ended sequence of its type and would offer some smaller composites for those interested in the Team Projects, but turned away by the sizes.[/STRIKE]


Edit: I was thinking of a different sequence. Please disregard the struck-out text. I'll go back into seclusion now (at least for a while). The one I was confusing with 27000 is 18528 which is the merge for 29^15, which was expected to terminate in a manner consistent with all the odd powered base 29 sequences. In light of that, would it be of interest to try for a Team Effort for that main project sequence?

EdH 2021-02-20 23:29

1 Attachment(s)
Let's see if I can redeem myself a little from that last oops. . .

I have attached a list of the C80s for all the open sequences represented in all the tables. Additionally, I found several merges within the tables:
[code]
5^26:i221 merges with 3^10:i7

3^204:i1053 merges with 7^96:i1260

37^18:i1428 merges with 12^15:i292
15^42:i810 merges with 12^15:i285

13^30:i728 merges with 385^6:i250
12^35:i371 merges with 385^6:i235

12^43:i489 merges with 14^7:i21

37^8:i150 merges with 17^4:i20

7^20:i1345 merges with 5^22:i269
20^37:i1855 merges with 5^22:i269
79^52:i2041 merges with 5^22:i269

11^24:i1993 merges with 385^4:i395

1155^6:i100 merges with 3^28:i428
[/code]As can be seen, three other sequences merge with 5^22:i269. I did not run down the merges between those three. There are also a couple others with multiple merges.

I think I may be taking a break. This last endeavor took a lot more manual intervention than expected. . .

EdH 2021-02-21 01:57

I've attached a new C80 list. I believe it has 51 fewer sequences than the 2020 list. All are unique and open-ended. I did not add a preface to the list. Feel free to make full use of it.

Of note, the Blue Page provided one sequence (1750944) in its AllSeq.txt which has not yet reached 80 digits. All the rest seemed to be what was expected.

[B]Note:[/B] The outdated list was removed from this post and a new one can be found in [URL="https://www.mersenneforum.org/showthread.php?p=572187#post572187"]post #848[/URL].

EdH 2021-02-21 03:14

578^46 has turned green.

garambois 2021-02-21 08:12

[QUOTE=EdH;572091]I totally glossed over the i0=i0. Very unobservant of me. It isn't something to note. Rather I wonder if I should provide a filter to remove it from future listings. I probably won't since we are aware of it, and as you say, it isn't a merger, just a hit with the 80 digit file.
[/QUOTE]

I don't think it's worth removing it from the list, on the contrary, it makes us aware of it !


[QUOTE=EdH;572091]
Speaking of the 80 digit file, I'm at 20k of the downloads. I ran my termination detection across those I already had at the time, with no hits, but if the AllSeq.txt from the Blue Page is anything near current, I shouldn't get any hits at this time. That may not be true of merges within the AllSeq.txt. If nothing has changed in merge detection for the Blue Page, it is quite possible (maybe even probable) that there will be undetected merges. That's one of the next scripts I'll be working on.

I still need to find a way to compare last lines, so I can limit updates to those sequences that have changed. Then I can do full set updates in a much more timely manner. I'm actually going to be doing that with my table sets, as well. In the past, I've been updating the full set by downloading the entire .elf for any that weren't terminated. But, the number of tables (and, therefore sequences) has grown considerably since then. As soon as I do another full update of the table .elfs, I'll work on an 80 digit file for them, too.
[/QUOTE]

OK, thanks !


[QUOTE=EdH;572091]
My "farm" is quite tied up with a larger job than I expected, or should have tried. It may well be into next month before I can even free the bulk of the machines and then my main machine will be busy for a long time with the LA, if I'm able to actually do it. Otherwise, I could run the c151 for 27000. [STRIKE]I wonder, since it is an open sequence of the main project, if we might make a case for it to become a Team Project like 276, 3408, 3366 and 4788. All of those mentioned are at uncomfortably high composites. Maybe we could make a case for working this one, in that it is the only known open-ended sequence of its type and would offer some smaller composites for those interested in the Team Projects, but turned away by the sizes.[/STRIKE]

Edit: I was thinking of a different sequence. Please disregard the struck-out text. I'll go back into seclusion now (at least for a while). The one I was confusing with 27000 is 18528 which is the merge for 29^15, which was expected to terminate in a manner consistent with all the odd powered base 29 sequences. In light of that, would it be of interest to try for a Team Effort for that main project sequence?[/QUOTE]

OK, seen. Personally, I do not feel the right to answer this question since in general, I do not participate in the collective effort to calculate the very large sequences which are reserved for a Team Effort.
I therefore let other possible people give their opinion on this question.

garambois 2021-02-21 08:34

[QUOTE=EdH;572104]Let's see if I can redeem myself a little from that last oops. . .

I have attached a list of the C80s for all the open sequences represented in all the tables. Additionally, I found several merges within the tables:
[code]
5^26:i221 merges with 3^10:i7

3^204:i1053 merges with 7^96:i1260

37^18:i1428 merges with 12^15:i292
15^42:i810 merges with 12^15:i285

13^30:i728 merges with 385^6:i250
12^35:i371 merges with 385^6:i235

12^43:i489 merges with 14^7:i21

37^8:i150 merges with 17^4:i20

7^20:i1345 merges with 5^22:i269
20^37:i1855 merges with 5^22:i269
79^52:i2041 merges with 5^22:i269

11^24:i1993 merges with 385^4:i395

1155^6:i100 merges with 3^28:i428
[/code]As can be seen, three other sequences merge with 5^22:i269. I did not run down the merges between those three. There are also a couple others with multiple merges.

I think I may be taking a break. This last endeavor took a lot more manual intervention than expected. . .[/QUOTE]


WAOUH AGAIN !

I had never been aware of such a phenomenon ! This is extremely curious, especially for 5^22:i269 !
I think that here you may have opened up a new field of research in our project !

But I notice that all the sequences in this list merge with sequences from the main project.
Have you tried to do a search if we don't have the following case :
[B]n^j:ixxx merges with m^k:iyyy[/B] [I](ixxx and iyyy merge indexes)[/I]
with the sequence m^y which does not merge with a sequence of the main project ?

And for the attached file, I keep it carefully, because I plan to write a program in the next few days that generates precisely this file.
It's wonderful to be able to check the correct functioning of a program by comparison! Many thanks.

garambois 2021-02-21 08:52

[QUOTE=EdH;572108]I've attached a new C80 list. I believe it has 51 fewer sequences than the 2020 list. All are unique and open-ended. I did not add a preface to the list. Feel free to make full use of it.

Of note, the Blue Page provided one sequence (1750944) in its AllSeq.txt which has not yet reached 80 digits. All the rest seemed to be what was expected.[/QUOTE]


Thanks a lot for all this !

I have two remarks :

1) 51 sequences less than on the 2020 list sounds like a lot, but why not ? I'll check it on my side with my own program in the coming days.

2)[B] I think we have a problem with the sequence 1750944.[/B]
On factordb, the last term caculated is index 1080 (75 digits).
On the blue page, it is indicated that the last term calculated is that of the index 1655 (144 digits).
I don't understand what's going on, there's bound to be an error somewhere !

garambois 2021-02-21 08:57

[QUOTE=EdH;572109]578^46 has turned green.[/QUOTE]


OK, thank you.
Next update : today but I don't know what time because there is a lot to fix and check. And there are bases to add, to extend ...

garambois 2021-02-21 10:47

[QUOTE=EdH;572060]Ok, I have some scripts that allow me to check the entire set of tables for sequences that merge. Then, they check to see if the merge is already listed in a table and provide a list of those already within the tables (found) and a list of those not already within the tables (missing). They then list those two sets:
[code]
These merges were already present:
31^4:i2 merges with 14100:i2
31^18:i241 merges with 25396:i984
[/code]I did just a few spot checks and all "seemed" accurate, but please check them for validity.

I will need to do more work on the scripts before I post them (possibly combining them into one), but I wanted to get the above to you for use for the next update.

Edit: If a new merge has replaced an old merge, it should just show as listed in the "not found" group, since the index numbers will have been different.[/QUOTE]


I think I found an error in "[U]These merges were already present:[/U]".
But it's very curious, it seems to be the only error.
In the tables, for base 31, there are 3 fusions.
The fusion of 31^36 is missing !
I don't know why your program couldn't find it ???

[I]Just for information : I've been working for 3 hours and still haven't started the updates yet.
[/I][I]I have only done error checking and research for now ! And I haven't finished.
[/I][I]So I don't know if the update will be done today.
[/I][I]Maybe tomorrow...[/I]

Happy5214 2021-02-21 10:48

[QUOTE=garambois;572126]2)[B] I think we have a problem with the sequence 1750944.[/B]
On factordb, the last term caculated is index 1080 (75 digits).
On the blue page, it is indicated that the last term calculated is that of the index 1655 (144 digits).
I don't understand what's going on, there's bound to be an error somewhere ![/QUOTE]

I checked it with aliqueit, and it failed validation at index 1068. I reported it in the FactorDB forum.

garambois 2021-02-21 10:52

[QUOTE=Happy5214;572133]I checked it with aliqueit, and it failed validation at index 1068. I reported it in the FactorDB forum.[/QUOTE]


Many thanks !

EdH 2021-02-21 13:03

[QUOTE=garambois;572125]WAOUH AGAIN !

I had never been aware of such a phenomenon ! This is extremely curious, especially for 5^22:i269 !
I think that here you may have opened up a new field of research in our project !

But I notice that all the sequences in this list merge with sequences from the main project.
Have you tried to do a search if we don't have the following case :
[B]n^j:ixxx merges with m^k:iyyy[/B] [I](ixxx and iyyy merge indexes)[/I]
with the sequence m^y which does not merge with a sequence of the main project ?

And for the attached file, I keep it carefully, because I plan to write a program in the next few days that generates precisely this file.
It's wonderful to be able to check the correct functioning of a program by comparison! Many thanks.[/QUOTE]I think this might be less extraordinary than its first impression. The other sequences merge at different values with each other and then the one with lowest connection with the smallest valued sequence merges and all take on the lowest value. I think it's just a small portion of the genealogy work we did long ago with certain sequences capturing many others along the way. (Or, maybe I'm missing something early in my morning.)

[QUOTE=garambois;572126]Thanks a lot for all this !

I have two remarks :

1) 51 sequences less than on the 2020 list sounds like a lot, but why not ? I'll check it on my side with my own program in the coming days.

2)[B] I think we have a problem with the sequence 1750944.[/B]
On factordb, the last term caculated is index 1080 (75 digits).
On the blue page, it is indicated that the last term calculated is that of the index 1655 (144 digits).
I don't understand what's going on, there's bound to be an error somewhere ![/QUOTE]I plan to seek out each lost sequences and run down the "why."

[QUOTE=garambois;572132]I think I found an error in "[U]These merges were already present:[/U]".
But it's very curious, it seems to be the only error.
In the tables, for base 31, there are 3 fusions.
The fusion of 31^36 is missing !
I don't know why your program couldn't find it ???

[I]Just for information : I've been working for 3 hours and still haven't started the updates yet.
[/I][I]I have only done error checking and research for now ! And I haven't finished.
[/I][I]So I don't know if the update will be done today.
[/I][I]Maybe tomorrow...[/I][/QUOTE]I will have to look into this.

[QUOTE=Happy5214;572133]I checked it with aliqueit, and it failed validation at index 1068. I reported it in the FactorDB forum.[/QUOTE]Darn! I had intended to run Aliqueit against all the sequences before compiling the list and totally forgot about it.

Thanks for looking after me, Happy5214.


As to the possible Team Project suggestion, I'll look into this at some point.

EdH 2021-02-21 14:29

[QUOTE=garambois;572125]. . .
It's wonderful to be able to check the correct functioning of a program by comparison! Many thanks.[/QUOTE]This part is especially exciting to me. Verification, whether it shows success or failure, is important to me in my scripts and programs.

I have a script running Aliqueit against all the sequences ATM. It's much slower than some of my other work, but should be done today.

I'll be looking at the other things as well, hopefully today.

EdH 2021-02-21 15:37

[QUOTE=garambois;572132]I think I found an error in "[U]These merges were already present:[/U]".
But it's very curious, it seems to be the only error.
In the tables, for base 31, there are 3 fusions.
The fusion of 31^36 is missing !
I don't know why your program couldn't find it ???
[I]. . .[/I][/QUOTE]Ah, yes! The reason it is not found is because a fresh copy of your 2020 80 digit file only goes to 3M, and 3762570 is above that cut. I have a local file which has that entry added, so it is found against that file, but not against the original. The list I provided also ends prior to 3M.

VBCurtis 2021-02-21 16:29

[QUOTE=EdH;572138]As to the possible Team Project suggestion, I'll look into this at some point.[/QUOTE]

When you're ready to do some work on that sequence, make a thread for it in the same place as the 3366 and 4788 threads. Sean and I will surely help with ECM and other work- as you observe, most of the current team sequences are over 200 digits and rather difficult to work on.

EdH 2021-02-21 17:23

[QUOTE=EdH;572138]. . .
Darn! I had intended to run Aliqueit against all the sequences before compiling the list and totally forgot about it.

Thanks for looking after me, Happy5214.

As to the possible Team Project suggestion, I'll look into this at some point.[/QUOTE]I have run the entire set through Aliqueit and found two broken sequences. I have not yet explored further:
[code]
1750944 ERROR: @index 1068: value != sigma - n
2796840 ERROR: @index 1068: value != sigma - n
[/code](I did check and both of them do show index 1068. An odd coincidence?) [QUOTE=VBCurtis;572150]When you're ready to do some work on that sequence, make a thread for it in the same place as the 3366 and 4788 threads. Sean and I will surely help with ECM and other work- as you observe, most of the current team sequences are over 200 digits and rather difficult to work on.[/QUOTE]Thanks Curtis. I will work on an appropriate post, hopefully later today.

garambois 2021-02-21 17:42

[QUOTE=EdH;572138]I think this might be less extraordinary than its first impression. The other sequences merge at different values with each other and then the one with lowest connection with the smallest valued sequence merges and all take on the lowest value. I think it's just a small portion of the genealogy work we did long ago with certain sequences capturing many others along the way. (Or, maybe I'm missing something early in my morning.)
[/QUOTE]

The future will tell !
I have a hunch that this will lead us to notice some interesting things, but it's only a hunch at the moment !


[QUOTE=EdH;572146]Ah, yes! The reason it is not found is because a fresh copy of your 2020 80 digit file only goes to 3M, and 3762570 is above that cut. I have a local file which has that entry added, so it is found against that file, but not against the original. The list I provided also ends prior to 3M.[/QUOTE]

OK, I understand what's going on !
Thanks !


[QUOTE=EdH;572153](I did check and both of them do show index 1068. An odd coincidence?) [/QUOTE]

This is strange !
I will also be checking in the next few days ...

garambois 2021-02-21 17:43

[QUOTE=VBCurtis;572150]When you're ready to do some work on that sequence, make a thread for it in the same place as the 3366 and 4788 threads. Sean and I will surely help with ECM and other work- as you observe, most of the current team sequences are over 200 digits and rather difficult to work on.[/QUOTE]


Thank you very much Curtis !

EdH 2021-02-21 18:08

2 Attachment(s)
Here are the corrected .elfs for the two broken sequences. I need to do some other things before I post a new C80 list.

garambois 2021-02-21 18:09

@yoyo :

Please, I noted the following thing :
[I]Base 42 up to exponent 80.[/I]

But I searched on this forum, I cannot find the following information, unless I am mistaken :
[I]Base 34 up to the exponent ???
Base 35 up to the [/I][I][I]exponent[/I] ???
Base 8589869056 until the exponent ???[/I]

Can you please provide me with that information ?
If not, I will look at FactorDB to try and see how far the calculations have been made, but doing so can lead to errors.

Thank you very much.

yoyo 2021-02-21 18:44

I start all up to exponent 100.
But they fall out of my queue fast because I stop if composite is > C139.

garambois 2021-02-21 19:10

@yoyo :

OK.
Is base 42 up to exponent 100 too ?

I just randomly checked for base 20.
I think you also calculated the sequences up to the exponent 100 for this base !
And the project page only goes up to exponent 92 for base 20.
I'm not sure the project page shows all of the calculations that were done by yafu.
[B]Are you able to give me the exponents up to which you made all the calculations for all the bases reserved for you ?[/B]
If not, I can try to find this information in another way, but I think it would be a bit laborious !
So we would see all the work that has been done by yafu.
This job is even more important than I thought.
It is very easy for me to add exponents for bases.

Many thanks !

yoyo 2021-02-21 19:19

Here is everything I added: [url]https://yafu.myfirewall.org/yafu/download/ali/y/[/url]

EdH 2021-02-21 20:16

I've managed to resolve the missing 51 sequences from the 2020 list to the new list. One was the troublesome 1750944.*

Next, 15 have merged:
[code]
399296^1:i5182 merges with 316960:i3
1444668^1:i6883 merges with 21546:i69
1999854^1:i2024 merges with 52374:i647
2073120^1:i5555 merges with 3876:i11
2212008^1:i1989 merges with 418080:i3
2324490^1:i5000 merges with 33870:i12
2338548^1:i3683 merges with 2127104:i7
2400840^1:i3436 merges with 17544:i6
2422868^1:i4216 merges with 14320:i25
2435784^1:i2709 merges with 1135584:i538
2482794^1:i1832 merges with 584802:i105
2502990^1:i2073 merges with 487172:i10
2506536^1:i1367 merges with 239700:i23
2545956^1:i3429 merges with 49236:i6
2564484^1:i2066 merges with 79842:i17
[/code]and, the following 35 have terminated:
[code]
95448
306408
1739160
1928262
1991080
2055144
2110320
2229246
2279670
2325636
2356674
2358432
2378952
2380158
2383668
2408226
2428320
2448564
2453022
2457000
2463636
2466132
2475000
2484054
2496648
2499000
2503284
2504334
2515536
2540610
2546472
2546760
2548404
2588238
2620074
[/code]1 + 15 + 35 = 51. So, all 51 are accounted for, if all my research is correct.

* 1750944 and 2796840 are now corrected in my set, and I'm running Aliqueit against the entire set again. The next run "should" provide a new complete up-to-date list. I will remove the earlier one I posted and attach the new one to a new post when I have it complete.

Thanks for all the help, everyone.

garambois 2021-02-21 20:40

OK perfect Edwin : everything matches !

:smile:



@All : This is a detail, but of course, in post #841, replace the word "exhibitor" with "exponent".
Translation mistake !
Edwin, could you please do this unless you think it doesn't matter ?

garambois 2021-02-21 21:02

[QUOTE=yoyo;572171]Here is everything I added: [URL]https://yafu.myfirewall.org/yafu/download/ali/y/[/URL][/QUOTE]


OK, thank you very much yoyo !

So I'll add exponents on the page for most of the bases calculated by yoyo with yafu.
A lot of calculations are already done.
On the other hand, for bases greater than 200 reserved by yoyo, the exponents always go up to 100.
However, 8128^100>10^390 and 8589869056^100>10^990 !
It therefore seems unnecessary to me to increase on the page the number of exponents up to 100 for bases greater than 200.
I will proceed as below to display only reasonably computable sequences on the page :
Base 220 up to exponent 80
Base 284 up to exponent 70
Base 439 up to exponent 60
Base 496 up to exponent 60
Base 770 up to exponent 60
Base 1155 up to exponent 50
Base 8128 up to exponent 40
Base 33550336 up to exponent 25
Base 8589869056 up to exponent 20

EdH 2021-02-21 21:55

1 Attachment(s)
OK, here's the latest C80 listing. I think I've done all the checking needed, but of course validation is always welcome.

garambois 2021-02-22 11:24

OK, page updated.

Biggest update in the history of the project !
Thank you all for your help !
Lots of little issues were fixed over 10 hours of work, not to mention all the time spent communicating with you here on the forum !
Thank you for reporting any errors regarding your work, your reservations, your mergers or another thing !
I really hope I haven't forgotten anything, and made no mistakes !

[B]Bases with additions of exponents :[/B] 15, 17, 18, 19, 20, 21, 23, 26, 29, 30, 31, 33, 34, 35, 37, 41, 42, 200, 220, 284, 439, 496, 770, 1155, 8128, 33550336

[B]Added bases :[/B] 34, 35, 42, 43, 47, 578, 8589869056, 2*3*5*7*11*13*17*19*23, 2*3*5*7*11*13*17*19*23*29, 2*3*5*7*11*13*17*19*23*29*31, 2*3*5*7*11*13*17*19*23*29*31*37

The last four base additions relate to some new findings that I will be presenting to you in a few days.


@Edwin : Thanks for correcting post #841.

garambois 2021-02-22 11:26

[QUOTE=EdH;572187]OK, here's the latest C80 listing. I think I've done all the checking needed, but of course validation is always welcome.[/QUOTE]


Many thanks Edwin !

EdH 2021-02-22 13:16

Glad I'm of help.

I have added a post to see if there is interest for a team project on the number 29^15 merged with. There is already a little. We'll see if there is more.

This brings me to another thought that I hadn't as of yet: If we merge with a sequence from the main project, we should check that it is not a reserved sequence, if we intend to continue with it. I think most of us have stopped when a merge was discovered because it met our limit, but we've raised our limit in many cases. I bring this up in case it hasn't been thought of, yet.

Happy5214 2021-02-22 14:01

Before the page gets too long, we may want to think about how we want to organize the bases. My suggestion is to sort them into different categories based on their form or notability (e.g. primes, 2 times a square, perfect numbers, cycles, primorials, etc.), either by re-sorting them into sections on the page and listing by type or by providing a navigation section near the top with the types that links to the bases, or possibly both. It would be useful to convert the base section headers from <a> to the proper HTML header tags in the process so they could be used as anchors, especially if we use the navigation section idea, and perhaps we should sort all of them under an <h2> header for the data. Honestly, I sort of prefer the latter plan since there's some overlap in the types (e.g. 2 (prime and 2 times a square) and 6 (perfect and primorial)).

EdH 2021-02-22 14:04

[QUOTE=EdH;572224]. . .
This brings me to another thought that I hadn't as of yet: If we merge with a sequence from the main project, we should check that it is not a reserved sequence, if we intend to continue with it. I think most of us have stopped when a merge was discovered because it met our limit, but we've raised our limit in many cases. I bring this up in case it hasn't been thought of, yet.[/QUOTE]I ran a reservation check against the lists of merges and found quite a number:
[code]

These merges were already present:
3^10:i15 merges with 1134:i9 Paul Zimmerman
3^48:i400 merges with 27450:i55 Batalov
3^204:i1060 merges with 4788:i6 mersenneforum
5^6:i1 merges with 3906:i0 dleclair
5^8:i3 merges with 564:i12 Paul Zimmerman
5^22:i265 merges with 660:i21 Paul Zimmerman
5^26:i229 merges with 1134:i9 Paul Zimmerman
6^7:i9 merges with 95280:i20 LaurV
6^67:i890 merges with 27860:i2 LaurV
6^81:i703 merges with 388600:i7 LaurV
7^10:i18 merges with 171040:i1 yafu@home
7^20:i1345 merges with 660:i25 Paul Zimmerman
7^96:i1267 merges with 4788:i6 mersenneforum
11^4:i1 merges with 1464:i0 Christophe Clavier
12^15:i294 merges with 3366:i2 mersenneforum
12^35:i380 merges with 3876:i5 Christophe Clavier
12^43:i488 merges with 2484:i8 Christophe Clavier
13^30:i728 merges with 3876:i11 Christophe Clavier
14^7:i21 merges with 2484:i9 Christophe Clavier
14^13:i262 merges with 167748:i33 yafu@home
15^4:i3 merges with 3432:i69 Christophe Clavier
15^8:i77 merges with 147150:i17 yafu@home
15^12:i3841 merges with 368688:i2 Sergiosi
15^42:i819 merges with 3366:i2 mersenneforum
17^4:i21 merges with 1632:i37 Christophe Clavier
20^7:i60 merges with 7044:i129 schickel
20^37:i1855 merges with 660:i25 Paul Zimmermann
22^29:i321 merges with 5208:i6 Christophe Clavier
23^44:i1830 merges with 7560:i251 Christophe Clavier
28^21:i4035 merges with 818880:i7 LaurV
37^18:i1430 merges with 3366:i2 mersenneforum
79^52:i2041 merges with 660:i25 Paul Zimmermann
385^6:i244 merges with 3876:i5 Christophe Clavier
770^3:i29 merges with 165876:i98 yafu@home
2310^1:i0 merges with 1578:i3 Walter Krickau
[/code].[code] These merges were not found:
37^8:i151 merges with 1632:i37 Christophe Clavier
37^22:i519 merges with 1567300:i0 yafu@home
[/code]Most, if not all, of these were probably at a level that we stopped work when they merged, but should we also have a reservation flag in the tables? Some of the reservations are "Contributors" to the tables, but many are not. Should we perhaps have a "Main Project Reservation (MPR)" entry, and keep track of them? I don't think we should check for dropped reservations, but we may want to check any new found merges for existing reservations in the Main Project.

garambois 2021-02-22 16:35

[QUOTE=EdH;572224]
I have added a post to see if there is interest for a team project on the number 29^15 merged with. There is already a little. We'll see if there is more.
[/QUOTE]

Yes, I saw this. Thank you very much ! I can't wait to see where this sequence goes ...


[QUOTE=EdH;572224]
This brings me to another thought that I hadn't as of yet: If we merge with a sequence from the main project, we should check that it is not a reserved sequence, if we intend to continue with it. I think most of us have stopped when a merge was discovered because it met our limit, but we've raised our limit in many cases. I bring this up in case it hasn't been thought of, yet.[/QUOTE]

I have asked myself this question before.
I think we should not reserve on our page sequences that merge with a sequence from the main project.
If someone wants to calculate such a sequence, it is infinitely easier if he is going to reserve it in the main project, if it has not yet been reserved before by someone else.

garambois 2021-02-22 17:01

[QUOTE=Happy5214;572228]Before the page gets too long, we may want to think about how we want to organize the bases. My suggestion is to sort them into different categories based on their form or notability (e.g. primes, 2 times a square, perfect numbers, cycles, primorials, etc.), either by re-sorting them into sections on the page and listing by type or by providing a navigation section near the top with the types that links to the bases, or possibly both. It would be useful to convert the base section headers from <a> to the proper HTML header tags in the process so they could be used as anchors, especially if we use the navigation section idea, and perhaps we should sort all of them under an <h2> header for the data. Honestly, I sort of prefer the latter plan since there's some overlap in the types (e.g. 2 (prime and 2 times a square) and 6 (perfect and primorial)).[/QUOTE]



I have to admit that I am starting to confuse the basics, because there are a lot of them now.
The advantage of the current presentation is that the numbers are arranged in ascending order.
I don't know if I understand your entire message correctly.
If I understand correctly, you are suggesting to leave as it is now, but to add buttons to click at the beginning of the page, on which we could click.
These buttons would be titled "primorial", "perfect", "cycles", '2 times a square ", ....
And when we click on these buttons, it would only reveal the bases included in the category.
Is that your idea ?
I think it's a very good idea !

On the other hand, I am totally unable to realize the code to do this. I will have to ask the great architect of the page, Karsten Bonath, that I do not can never thank enough for all his help.
Can you confirm to me that I understand your idea correctly ?
Does anyone else have an opinion on this matter ?

garambois 2021-02-22 17:18

[QUOTE=EdH;572229]I ran a reservation check against the lists of merges and found quite a number:
[code]
...
...

[U][B]These merges were not found: [/B][/U]
37^8:i151 merges with 1632:i37 Christophe Clavier
37^22:i519 merges with 1567300:i0 yafu@home
[/code]Most, if not all, of these were probably at a level that we stopped work when they merged, but should we also have a reservation flag in the tables? Some of the reservations are "Contributors" to the tables, but many are not. Should we perhaps have a "Main Project Reservation (MPR)" entry, and keep track of them? I don't think we should check for dropped reservations, but we may want to check any new found merges for existing reservations in the Main Project.[/QUOTE]


Look at post #854 which also gives my opinion on the issue of reserving sequences that merge with sequences from the main project.
But maybe other people will have a different opinion ?

Otherwise, I don't understand why the 37 ^ 8 and 37 ^ 22 sequences are classified under the heading : "[U][B]These merges were not found:[/B][/U]" ?

garambois 2021-02-22 17:26

[QUOTE=EdH;572187]OK, here's the latest C80 listing. I think I've done all the checking needed, but of course validation is always welcome.[/QUOTE]


I just started running my own program.
I hope we will have the same result !
I also hope there won't be new broken sequences.
Result in a few days, I confirm, it is going much faster than a year ago.
What happiness !
It is even now possible to scan a main project which would consider all sequences <10^7 !

EdH 2021-02-22 18:22

[QUOTE=garambois;572255]. . .
Otherwise, I don't understand why the 37 ^ 8 and 37 ^ 22 sequences are classified under the heading : "[U][B]These merges were not found:[/B][/U]" ?[/QUOTE]
I did a cut/paste from the earlier posting, at which time they were not yet included. I should have removed those headers. Sorry 'bout that!

garambois 2021-02-22 18:35

OK, no problem, thanks.
I should have thought about it.

EdH 2021-02-22 18:53

[QUOTE=garambois;572258]I just started running my own program.
I hope we will have the same result !
I also hope there won't be new broken sequences.
Result in a few days, I confirm, it is going much faster than a year ago.
What happiness !
It is even now possible to scan a main project which would consider all sequences <10^7 ![/QUOTE]
I'm looking forward to your results.

After I "fixed" the two broken sequences in my local set, I did a full test with Aliqueit again. I expect that they are not fixed yet in the db, so you should find them. But the corrected ones are a few posts back.

Still, I think it took me more than 48 total hours for 27.5k+ sequences. If my math is correct (often not the case), that would still be nearly 2 years for <10^7. . .

garambois 2021-02-22 20:00

[QUOTE=EdH;572267]
Still, I think it took me more than 48 total hours for 27.5k+ sequences. If my math is correct (often not the case), that would still be nearly 2 years for <10^7. . .[/QUOTE]


2 years ? 2-3 days to scan the main project down to 3 * 10^6 so about roughly 27,000 or let's round up to 30,000 sequences.
So up to 10 * 10^6 = 10^7 so about 90,000 sequences, it takes about 6 days or a week, right ?

EdH 2021-02-22 20:19

[QUOTE=garambois;572273]2 years ? 2-3 days to scan the main project down to 3 * 10^6 so about roughly 27,000 or let's round up to 30,000 sequences.
So up to 10 * 10^6 = 10^7 so about 90,000 sequences, it takes about 6 days or a week, right ?[/QUOTE]My confusion is that I was thinking of total sequences, whereas I "think" you are referring to open sequences. Do you have a listing of open sequences between 3M and 10M? If all are to be retrieved and checked for status, that's still 7M.

Happy5214 2021-02-23 03:02

[QUOTE=garambois;572248]I have to admit that I am starting to confuse the basics, because there are a lot of them now.
The advantage of the current presentation is that the numbers are arranged in ascending order.
I don't know if I understand your entire message correctly.
If I understand correctly, you are suggesting to leave as it is now, but to add buttons to click at the beginning of the page, on which we could click.
These buttons would be titled "primorial", "perfect", "cycles", '2 times a square ", ....
And when we click on these buttons, it would only reveal the bases included in the category.
Is that your idea ?
I think it's a very good idea !

On the other hand, I am totally unable to realize the code to do this. I will have to ask the great architect of the page, Karsten Bonath, that I do not can never thank enough for all his help.
Can you confirm to me that I understand your idea correctly ?
Does anyone else have an opinion on this matter ?[/QUOTE]

Sorry, I tend to ramble to a point that non-native English speakers (and some native speakers) can't understand me.

Sort of. I'll write some mock-ups of my ideas and post them as attachments.

garambois 2021-02-23 07:33

[QUOTE=EdH;572275]My confusion is that I was thinking of total sequences, whereas I "think" you are referring to open sequences. Do you have a listing of open sequences between 3M and 10M? If all are to be retrieved and checked for status, that's still 7M.[/QUOTE]


Yes, I have such a list in my fundamental database and I even have this list up to 14,000,000.
This is the file called "[U]regina_opens.tar.lzma[/U]" here :
[URL="http://www.aliquotes.com/aliquote_base.htm#alibasefonda"]http://www.aliquotes.com/aliquote_base. htm # alibasefonda[/URL]
But the problem is that in this database, I consider a sequence to be Open-End as soon as the size of its terms first reaches 10^50.
There are just over 142,000 Open-End sequences up to 14,000,000 in my database.

garambois 2021-02-23 07:39

[QUOTE=Happy5214;572289]Sorry, I tend to ramble to a point that non-native English speakers (and some native speakers) can't understand me.

Sort of. I'll write some mock-ups of my ideas and post them as attachments.[/QUOTE]


Ok thank you !
Being non-English speaking, I also wonder if sometimes you have no trouble understanding what I'm saying.
I trust machine translation a lot !

EdH 2021-02-23 13:11

[QUOTE=garambois;572299]Yes, I have such a list in my fundamental database and I even have this list up to 14,000,000.
This is the file called "[U]regina_opens.tar.lzma[/U]" here :
[URL="http://www.aliquotes.com/aliquote_base.htm#alibasefonda"]http://www.aliquotes.com/aliquote_base. htm # alibasefonda[/URL]
But the problem is that in this database, I consider a sequence to be Open-End as soon as the size of its terms first reaches 10^50.
There are just over 142,000 Open-End sequences up to 14,000,000 in my database.[/QUOTE]Then that seems much more doable. Now that you mention this, I remember it from some time quite a while ago. But, I couldn't bring it to the forefront yesterday. Sorry to be such an annoyance at times. . .

garambois 2021-02-23 18:24

I would also like to warmly thank Karsten Bonath for all the help he gives me in writing the lines of code that generate the reservations page.
I will be saving a lot of time with some new and recent scripts !
This well done and readable page is fundamental in our project.
It greatly contributes to the good visualization of the data in order to then correctly orient the more in-depth data analyzes and to know what calculations we have to do.

Happy5214 2021-02-24 01:33

1 Attachment(s)
Here are the mock-ups. I decided against splitting up the data due to the categorical overlap. There are four levels of progression from the existing HTML file. powers.html shows the file with the proper semantic HTML markup I brought up several months ago, including <h2> headers and <section> tags for the base sections, renamed CSS classes to reflect usage rather than color, using <var> tags for the variables instead of <i> (or nothing at all in some cases), and enclosing text in <p> paragraph tags. powers1.html simply adds a new <h2> heading for the bases and converts the individual base headers to <h3>. powers2.html moves the table open/close button after the header in the HTML code for semantic reasons and floats it to the left to achieve the same display effect. powers3.html actually adds the navigation table, which is simply a two-row table with the header and lists as the second row. Most lists are ordered, adding additional structure to the series categories. The visual appeal needs some work, though the idea is basically what is shown.

Edit: I did just realize that the navigation header styling doesn't match. That's a simple CSS fix.

garambois 2021-02-24 10:16

1 Attachment(s)
Now I understand your idea better.
And I think your idea for the "powers3" html file would bring more clarity to the page and make it easier to exploit the results.
Do you think it would be useful to add the possibility of clicking on the column headers of the "Navigation" table so that only the bases of a single category appear ?
For example, we could click on "Perfect" in the header of the fourth column and that would open the html page that I present below (see "Attached Files").
Thus, one would more easily notice properties specific to perfect numbers.
These html pages for each of the categories are easy for me to generate.
Unless these other pages are not necessary and we can only display the bases of a single category while hiding all the others ?
On the other hand, I do not understand your comments on the tags.
This is completely outside my area of ​​expertise.
I leave that to the specialists (I also tell myself that the other html pages of my own site must be frankly "disgusting" for a specialist !).

Small detail : should 6 appear in the "others" column ?

garambois 2021-02-24 13:31

Until now, the odd bases that we have calculated are often "special" odd numbers : they are prime, primorial ...
For my work in progress, I'm missing some odd bases which are "any" numbers.
I have launched several new bases for a few days, but I will not succeed alone if I want to be able to present this new work to you during my current vacation.

I am missing the following sequences :

- Base 45 up to exponent i = 90, only odd exponents
- Base 75 up to exponent i = 90, only odd exponents
- Base 231 up to exponent i = 70, only odd exponents

If anyone can do any of these calculations, I'm extremely interested ...

As far as I am concerned, I have been working for several days on bases which are primorial numbers and on bases 105 and 15015 which are primorials without the factor 2.
In a few days, you will understand my interest in these bases.

yoyo 2021-02-24 16:04

Here here, here, I take base 45, 75 and 231.

garambois 2021-02-24 18:00

OK, many thanks yoyo !

Happy5214 2021-02-25 01:45

[QUOTE=garambois;572414]Now I understand your idea better.
And I think your idea for the "powers3" html file would bring more clarity to the page and make it easier to exploit the results.
Do you think it would be useful to add the possibility of clicking on the column headers of the "Navigation" table so that only the bases of a single category appear ?
For example, we could click on "Perfect" in the header of the fourth column and that would open the html page that I present below (see "Attached Files").
Thus, one would more easily notice properties specific to perfect numbers.
These html pages for each of the categories are easy for me to generate.
Unless these other pages are not necessary and we can only display the bases of a single category while hiding all the others ?
[/quote]

So you want separate pages for the different categories? I think that would lead to a lot of duplication, as you'd have to repeat the definitions, contributor list, stylesheet, and header info on each page, as well as a few bases. I could probably put it all on one page, add classes to each section tag, put some checkboxes in the navigator, and write a jQuery script to show/hide the sections based on the values of the boxes. I'm not sure how everyone feels about third-party JavaScript libraries (even a FOSS one you could host yourself if you wanted to), but it is significantly easier with jQuery than with plain JS. I'll code up another mock-up and get back to you.

[QUOTE=garambois;572414]On the other hand, I do not understand your comments on the tags.
This is completely outside my area of ​​expertise.
I leave that to the specialists (I also tell myself that the other html pages of my own site must be frankly "disgusting" for a specialist !).[/quote]

I'm not even that skilled of a web designer. If you look at my personal website, which I think is linked from my profile, it's very rudimentary. I'm just very standards conscious.

[QUOTE=garambois;572414]Small detail : should 6 appear in the "others" column ?[/QUOTE]

It should not. I copied it to my personal private web server so I could show a family member on my phone (it looks terrible on mobile, by the way), and I did a facepalm when I noticed 6 in the "Others" column, since it's in both the primorial and perfect columns.


All times are UTC. The time now is 21:07.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2023, Jelsoft Enterprises Ltd.