I am reserving (belatedly) [I]n[/I]=162=2*3^4 to [I]i[/I]=54 (120 digits). I've already terminated everything up to 162^44 using a combination of FactorDB, local yafu, and Dario Alpern's browser ECM/QS calculator.

[QUOTE=RichD;557064]Looks like 31^4 and 31^18 may have merged. Can someone verify this?

I am releasing all base 20 numbers.[/QUOTE]
Verified:
[code]
31^4:i2 merges with 14100:i2
31^18:i241 merges with 25396:i984
[/code]

I am terminating all the newly-added odd powers of 13; I'll have them all done by the weekend update.

Releasing 21^78 (yes, I know I squared the 7).

[I]n[/I]=162 is complete to [I]i[/I]=48, and 162^49 is in progress as I type. 21^80 will be next after I finish with 162.

[I]n[/I]=162 is done to [I]i[/I]=54 (120 digits), and I'll stop there. 21^80 is next.

[QUOTE=VBCurtis;557074]I am terminating all the newly-added odd powers of 13; I'll have them all done by the weekend update.[/QUOTE]

I lied- 13^141 and 13^143 are in progress, not yet complete. Odd powers up to 13^139 are complete.

[QUOTE=yoyo;557054]I will currently not go above C139. You can book it to EdH.
For base 18 volunteers have only 18^126 and 18^138 running.[/QUOTE]
18^126 is now sitting with a c149 cofactor. Is your work finished with that sequence?

Yes I finished this sequence. I have nothing more running for base 18.

OK, page updated.
Thank you all for your contribution !

Base 31 added.
Base 162 added.

Thank you all to check again your information on the updated page, to see if there are no errors...

21^80 went up quickly. Releasing. 21^82 is next.

I plan to continue 21 until at least 21^97, as those currently show sub-C120 cofactors on FactorDB.

I hope to be close to running the rest of the base 18 table to prime by the next update. If you would like, go ahead and reserve the rest of base 98 for me and I'll work there as well.

All of base 18 and a few more of base 98 should be green now. . .

OK, page updated.
Thanks a lot to all for your help !

:smile:

I think 31^36 may have merged.

[QUOTE=RichD;558264]I think 31^36 may have merged.[/QUOTE]
I don't show any merge, but that should not be considered conclusive. . .

[QUOTE=RichD;558264]I think 31^36 may have merged.[/QUOTE]


If there was a merge of 31^36, then it is not with a sequence from the main project.
It must be with another sequence whose last 80 digits term is not on my page : [URL]http://www.aliquotes.com/OE_3000000_C80.txt[/URL]
I don't know how to find this merge ?

[QUOTE=garambois;558275]If there was a merge of 31^36, then it is not with a sequence from the main project.[/QUOTE]

At index 1924, that term was added to FDB by me today.
At index 1925 (and forward), that composite was added Nov 4, 2018.
A quick snapshot is at: [url]http://factordb.com/sequences.php?se=1&aq=31%5E36&action=range&fr=1922&to=1930[/url]

Unfortunately, I don't know how to determine which sequence was merged with if it's not with a sequence from the main project !
I don't even know how you were able to determine when the old sequence was entered ?

[QUOTE=RichD;558277]At index 1924, that term was added to FDB by me today.
At index 1925 (and forward), that composite was added Nov 4, 2018.
A quick snapshot is at: [url]http://factordb.com/sequences.php?se=1&aq=31%5E36&action=range&fr=1922&to=1930[/url][/QUOTE]

Numbers 18 digits and smaller are preloaded into the database (hence why they match their own ID numbers rather than having sequentially assigned ones in the 1100.... range), so that's probably the last date the database was refreshed.

[QUOTE=garambois;558333]Unfortunately, I don't know how to determine which sequence was merged with if it's not with a sequence from the main project !
I don't even know how you were able to determine when the old sequence was entered ?[/QUOTE]

Click on the composite in question, say the one at index 1924. A new page will be displayed. Click the little green arrow after More information. It shows a Create Time of Sep 29, 2020. Repeat the process for index 1925. In fact the last composite at index 3829 shows a Create Time of Dec 15, 2019.

Edit: The next to last number, a C102 at index 3828, was added on Nov 4, 2018. It took over a year to advance one term - whatever sequence this is. :smile:

[QUOTE=RichD;558343]Edit: The next to last number, a C102 at index 3828, was added on Nov 4, 2018. [/QUOTE]

[QUOTE=factordb]Before November 4, 2018, 12:20 am[/QUOTE]
All numbers with Nov 4 date is a lie. It just means the database was rebuilt on that date and they lost all history of any existing numbers. Hence the "before"

[QUOTE=axn;558347]All numbers with Nov 4 date is a lie. It just means the database was rebuilt on that date and they lost all history of any existing numbers. Hence the "before"[/QUOTE]

Ah, OK. The point is "that sequence" was known before I started working on 31^36 this week. It found (merged with?) an existing sequence and suddenly advanced nearly 2000 terms. I was simply stating what I thought the merge point might be.

[QUOTE=RichD;558343]Click on the composite in question, say the one at index 1924. A new page will be displayed. Click the little green arrow after More information. It shows a Create Time of Sep 29, 2020. Repeat the process for index 1925. In fact the last composite at index 3829 shows a Create Time of Dec 15, 2019.

Edit: The next to last number, a C102 at index 3828, was added on Nov 4, 2018. It took over a year to advance one term - whatever sequence this is. :smile:[/QUOTE]


Thank you very much, I didn't know that such information could be found on factordb !!!

[QUOTE=RichD;558264]I think 31^36 may have merged.[/QUOTE]
Found:
[code]
31^36:i2015 merges with 3762570:i457
[/code]Not found earlier because it is above Jean-Luc's C80 listing.

Please reserve base 79 for me.

[QUOTE=EdH;558401]Found:
[code]
31^36:i2015 merges with 3762570:i457
[/code]Not found earlier because it is above Jean-Luc's C80 listing.[/QUOTE]


Please, how could you find this :question:

[QUOTE=unconnected;558406]Please reserve base 79 for me.[/QUOTE]


OK, thank you very much ! It will be done at the next update next weekend...

It appears 29^50 may have merged.

[QUOTE=RichD;558549]It appears 29^50 may have merged.[/QUOTE][code]
29^50:i1210 merges with 9999286:i5
[/code]But, there are many other merges (due to it terminating with a large number of small terms) and I don't know which to treat as the lowest.

[QUOTE=garambois;558534]Please, how could you find this :question:[/QUOTE]
I wrote a script to work its way back through an Aliquot sequence via the factordb, identifying terms that have more than one source. The "More information" for Aliquot composite terms includes any previous composite Aliquot terms that result in that Aliquot sum. In the above example for RichD, if you look at "More information" for [URL="http://www.factordb.com/index.php?id=2409946"]2409946[/URL]:
[code]
[B]Others:[/B]
Aliquot sequence: [COLOR=Black][URL="http://www.factordb.com/index.php?id=3012410"]3012410[/URL]
[/COLOR]Aliquot sequence: [COLOR=Black][URL="http://www.factordb.com/index.php?id=3340358"]3340358[/URL][/COLOR]
[/code]you can see two sources. By following the sources, you can reach a first term.

Unfortunately, my script also tends to crash the computer it is run on and I had some LAN trouble at the same time. Coincidence? Which preceded which? No answers. But I don't want to post the script due to the crashes.

[QUOTE=EdH;558564][code]
29^50:i1210 merges with 9999286:i5
[/code]But, there are many other merges (due to it terminating with a large number of small terms) and I don't know which to treat as the lowest.
. . .
[/QUOTE]In the case of open sequences, the lowest starting term is considered the sequence into which others merge. What determines the sequence into which others merge for terminated sequences? Is it the lowest untouchable sequence or is it the terminating prime?

[QUOTE=EdH;558620]In the case of open sequences, the lowest starting term is considered the sequence into which others merge. What determines the sequence into which others merge for terminated sequences? Is it the lowest untouchable sequence or is it the terminating prime?[/QUOTE]
Personally, I would skip describing the merge and just say it terminates at the prime/cycle. I don't think there's a satisfactory way to describe such a large number of merges in as quick a succession as that.

[QUOTE=Happy5214;558653]Personally, I would skip describing the merge and just say it terminates at the prime/cycle. I don't think there's a satisfactory way to describe such a large number of merges in as quick a succession as that.[/QUOTE]
That sounds OK, but for 29^50, it merged with something to take it to termination. I guess that it can still be left as just 29^50 terminated.

The base 98 table should all be green at next update.

[QUOTE=EdH;558564][code]
29^50:i1210 merges with 9999286:i5
[/code]But, there are many other merges (due to it terminating with a large number of small terms) and I don't know which to treat as the lowest.


I wrote a script to work its way back through an Aliquot sequence via the factordb, identifying terms that have more than one source. The "More information" for Aliquot composite terms includes any previous composite Aliquot terms that result in that Aliquot sum. In the above example for RichD, if you look at "More information" for [URL="http://www.factordb.com/index.php?id=2409946"]2409946[/URL]:
[code]
[B]Others:[/B]
Aliquot sequence: [COLOR=Black][URL="http://www.factordb.com/index.php?id=3012410"]3012410[/URL]
[/COLOR]Aliquot sequence: [COLOR=Black][URL="http://www.factordb.com/index.php?id=3340358"]3340358[/URL][/COLOR]
[/code]you can see two sources. By following the sources, you can reach a first term.

Unfortunately, my script also tends to crash the computer it is run on and I had some LAN trouble at the same time. Coincidence? Which preceded which? No answers. But I don't want to post the script due to the crashes.[/QUOTE]




Thanks Edwin for these explanations !

OK, page updated.
Many thanks to all for your help !

Note : I don't specify merges for sequences that end on a prime number, like 29^50. Because anyway, all the sequences that end merge with another one towards the end, as Happy5214 says in post #613 !

[QUOTE=richs;556978]Taking 439^20 at i2157.[/QUOTE]

439^20 is now at i2253 (added 96 iterations) and a C128 level with a 2^9 * 3^2 driver, so I will drop this reservation. The remaining C102 term is well ecm'ed and is ready for siqs.

Taking 439^40 at i39.

[QUOTE=richs;559060]439^20 is now at i2253 (added 96 iterations) and a C128 level with a 2^9 * 3^2 driver, so I will drop this reservation. The remaining C102 term is well ecm'ed and is ready for siqs.

Taking 439^40 at i39.[/QUOTE]
SIQS for a C102? The "official" cutoff (according to yafu) on my Linux Core 2 box is 98-99 digits, though I've noticed recently that 99-digit GNFS jobs actually take [i]less[/i] time than 98-digit SIQS jobs. :confused2:

In actual progress news, I'm finished with 21^82 and 21^84, and those are released.

[QUOTE=Happy5214;559320]SIQS for a C102? The "official" cutoff (according to yafu) on my Linux Core 2 box is 98-99 digits, though I've noticed recently that 99-digit GNFS jobs actually take [i]less[/i] time than 98-digit SIQS jobs. :confused2:[/QUOTE]

Using the tune function of yafu on my i3 results in a siqs/gnfs crossover at C104 for that laptop. On my i7, the yafu crossover is C106.

The table elements for base 72 through exponent 88 are complete (although the table is not shown due to corrupted sequences within the db).

For all of the corrupted sequences, index 1 and beyond has been entered into the db, so when the initial terms are fixed all will be available as normal. In the meantime, for anyone maintaining a local set of .elfs for their study, I have attached a correct set of the corrupted sequences.

[QUOTE=richs;559327]Using the tune function of yafu on my i3 results in a siqs/gnfs crossover at C104 for that laptop. On my i7, the yafu crossover is C106.[/QUOTE]

Those cutoffs are nuts! maybe try timing a C102 both ways to see if tune is accurate? Is gnfs via factmsieve.py?

For CADO vs siqs, my cutoff is 93 digits. CADO is over twice as fast as yafu by 99 digits.
Doesn't help windows users, alas.

Yafu siqs is very fast / fine tuned. Except for very old versions and CPU, the cutoffs were always around 100 digits, a bit over. I also get 103..106 depending on what else the computer does.

[QUOTE=VBCurtis;559333]CADO is over twice as fast as yafu by 99 digits.
[/QUOTE]


Wow, really? Is there anything in your setup that makes it so, or do you think that's true across the board?

[QUOTE=Mr. Odd;559337]Wow, really? Is there anything in your setup that makes it so, or do you think that's true across the board?[/QUOTE]

I hand-tuned the CADO params files for speed- they're posted in the CADO subforum [url]https://mersenneforum.org/showthread.php?t=24274[/url]. Most of my files are 20-30% faster than the factory defaults, but the C100 file in particular is slow by default (quartic poly, for one). I think non-hyperthreaded machines will not be quite as fast running CADO as HT-enabled.

Similar work can be done for factmsieve/GGNFS, particularly on the relations-wanted values that trigger the first filtering run. I haven't run factmsieve in quite a while, but I think the stock settings filter a whole bunch of times, stalling sieving quite a bit. Edit- I've never run GGNFS controlled by Yafu, so I can't comment on its efficiency.

My best CADO C100 timing is a tick under 6 minutes wall-clock time, on a single-socket Xeon 12x2.5Ghz. On an haswell-i7 (6x3.3ghz), I have 9.5 minutes for C101 on CADO.

On C93, I have 226 sec on CADO, 229 sec on siqs (both 12-threaded on 12 cores).

EDIT: As noted in the above-referenced thread, Skylake-yafu using AVX-512 is much faster, with a crossover to CADO around 97-98 digits.

Yafu siqs on 93 digit semiprime (p47*p47) on 10 cores, 10 threads, ~84k relations needed, 166 seconds.

NFS on the same number is about [STRIKE]30[/STRIKE] 40 seconds slower.

[QUOTE=EdH;559331]The table elements for base 72 through exponent 88 are complete (although the table is not shown due to corrupted sequences within the db).

For all of the corrupted sequences, index 1 and beyond has been entered into the db, so when the initial terms are fixed all will be available as normal. In the meantime, for anyone maintaining a local set of .elfs for their study, I have attached a correct set of the corrupted sequences.[/QUOTE]


Thanks a lot Ed !

:smile:

OK, page updated.
Many thanks to all for your help !

I released base 50. Calculation times are getting too long for me.

Next update : not before Sunday, October 25...


I also take this opportunity to thank the person who added on the blue page the two broken aliquot sequences that I had reported.

[QUOTE=garambois;559553]. . .
I released base 50. Calculation times are getting too long for me.
. . .[/QUOTE]I'll work on "greening" up the orange sequences for base 50. . .

[QUOTE=EdH;559678]I'll work on "greening" up the orange sequences for base 50. . .[/QUOTE]


OK, thanks a lot Edwin !

The odd powers of 13 are finished up to 13^145.
I am now back to working on the even powers of 13 up to 78.

I added 700+ terms to 13^58.

OK, many thanks VBCurtis.
At the next update after October 25th, I will extend base 13 to the power i=145.

79^56 terminates!

[QUOTE=unconnected;560097]79^56 terminates![/QUOTE]
Nice! Another mixed parity from a non-square related base!

The rest of base 50 (through exponent 95) should all turn green at next update.

Base 21 is finished (at least ECMed C120 cofactors) to 21^90, and I'm releasing everything up to that exponent. I plan on extending that base to 21^97 before moving on to my two other reserved bases.

I did a few updates to n=20 and a lot more to n=29. Make sure those tables are included in the update to show the latest advances.

79^52 merges with 660!

OK,
79^52 merges at index 2041 with 660:i25.
Thanks.

OK, page updated.
Many thanks to all for your help.

:smile:


@Happy5214 : Is it normal that for the completed sequences of base 21, there are only "A" for the attributions or did I make a mistake during the last update ?

[QUOTE=garambois;561171]@Happy5214 : Is it normal that for the completed sequences of base 21, there are only "A" for the attributions or did I make a mistake during the last update ?[/QUOTE]

Looks right to me.

[QUOTE=Happy5214;561201]Looks right to me.[/QUOTE]


OK.
Thanks !

If you'd like, you can expand the base 496 table to exponent 58 next time you do an update. It should be all orange and green.

OK, fine : I'll extend to exponent 58 for base 496 in the next update. Thanks a lot !

Base 162 doesn't show any reservations for the orange cells. I'll start working on those from the high end. Would anyone like to work toward me from the low end? Or, if someone wants that section let me know.

I release base 2 and take base 20 and 23.

[QUOTE=yoyo;561482]I release base 2 and take base 20 and 23.[/QUOTE]
I'll work on greening up the six base 2 exponents that are left for that table.

Base 21 is done to [I]i[/I]=97. I don't plan on continuing that base beyond that point. Sadly, there were no nontrivial terminations or merges resulting from my work on this base. :sad:

After a brief break catching up on GIMPS and RPS, I'll try my hand on some main project sequences before resuming work on base 24.

I'll take base 21 too.

Since there wasn't other interest, I'm working both ends of the orange area toward the middle now for base 162, so I guess that whole section can be attributed to me at the next update. They won't all be green yet, but some have already made the change.

I am performing preliminary work on Tables 220 and 284.

It appears 284^3 has merged.

[QUOTE=RichD;561738]. . .
It appears 284^3 has merged.[/QUOTE]
It does:
[code]
284^3:i701 merges with 21432:i50
[/code]

I'm really sorry.
It's totally impossible to do the update !
Already last week, it had been very laborious to scan factordb : it was very long compared to usual !
But today, I can't even scan base 3, it blocks for a while. It's very long for each exponent.

I don't know what's going on ?

This does not prevent us from continuing our calculations.
But we have to watch the posts since post #640 of the last update to be sure not to do the same calculations as someone else.

Thank you all for your help !
I will take into account all your requests in the next update. But this next update will only be partial if the problem remains !

Looks like someone flooded factordb with thousands of small composites.
[url]http://factordb.com/stat_1.php[/url]

[QUOTE=RichD;561738]I am performing preliminary work on Tables 220 and 284.
[/QUOTE]


Perfect, it's a job that was on hold.
At least we will have two bases which are amicable numbers. I don't think anything special is going to happen. But we have to check to be sure !

[QUOTE=unconnected;561779]Looks like someone flooded factordb with thousands of small composites.
[URL]http://factordb.com/stat_1.php[/URL][/QUOTE]


I don't know what to do ?
Should I try again today ?
Last week, there was a similar problem ?

There is work being done on the db and all sequences will rebuild when accessed at some point, so everything will be quite slow.

On a bright note, Syd has informed me that he has fixed the three broken sequences and all the base 72 issues, so once we are able to access it again in a reasonable way, you should be able to add the base 72 table. I haven't been able to verify anything and will be out today, but will check either later or tomorrow.

[QUOTE=richs;559060]Taking 439^40 at i39.[/QUOTE]

439^40 is now at i554 (added 515 lines) and a C122 level with a 2^2 * 5 * 7 driver, so I will drop this reservation. The remaining C116 term is well ecm'ed and is ready for nfs.

Taking 439^42 at i15 and 439^44 at i2.

[QUOTE=EdH;561793]There is work being done on the db and all sequences will rebuild when accessed at some point, so everything will be quite slow.

On a bright note, Syd has informed me that he has fixed the three broken sequences and all the base 72 issues, so once we are able to access it again in a reasonable way, you should be able to add the base 72 table. I haven't been able to verify anything and will be out today, but will check either later or tomorrow.[/QUOTE]


[B]Thank you very much for this very very very good news !!![/B]
[B]A lot of thanks to Syd !!![/B]

I'm just going to do a quick update for the few bases for which you reported changes to me : bases 2, 3, 20, 21, 23, 162, 439, 496.

For the addition of bases 72, 220 and 284, I will wait to hear from you...

:smile:

I did some work on base 29. Bases 220 and 284 will be ready at the next update.

[QUOTE=RichD;561822]I did some work on base 29. Bases 220 and 284 will be ready at the next update.[/QUOTE]


Yes, a lot of work has been done on many other bases. But it is impossible to scan everything for today's update. Sometimes it takes me more than two hours to update a single base. I will update the other bases in the next few weeks.

Page updated, but only for bases 2, 3, 20, 21, 23, 162, 439, 496.
31^36 and complete base 385 are reserved for me.

Thanks to all for your help !
Please check if all your requests have been taken into account.

The other bases will be updated in the next few weeks, as it takes a lot of time for each base .

I checked the three sequences that had been broken and Aliqueit now verifies their .elfs.

I checked the base 72 sequences that were broken and all of them appear to be correct now. So, at next update, you should be able to add base 72 through exponent 88 and the entire table should show green.

I have some scripts that work with an entire range, such as the tables. Maybe over the next few days (or longer) I'll touch each of the sequences for all the tables. That should allow for easier updates down the way.

[QUOTE=EdH;561927]I checked the three sequences that had been broken and Aliqueit now verifies their .elfs.

I checked the base 72 sequences that were broken and all of them appear to be correct now. So, at next update, you should be able to add base 72 through exponent 88 and the entire table should show green.

I have some scripts that work with an entire range, such as the tables. Maybe over the next few days (or longer) I'll touch each of the sequences for all the tables. That should allow for easier updates down the way.

[/QUOTE]


Thanks a lot Edwin for your help !

Base 162 table should be all "greened up" now.

I've started "touching" all the sequences for the tables and it took a couple hours to do five tables this morning. I have started a script to run all of the tables except 220 and 284, since they're just being initialized and probably won't need any "help." I'm curious how long the script will actually take to get through everything.

I was greeted this morning with the finished script, so every sequence in the current tables and base 72, has been accessed. Hopefully, that will get the update time back near normal.

Really a big thank you to you Edwin !
This will change everything for me in the next update.
I think that now, during the next weekend, I will be able to update all the bases and finally add base 72.


:smile:

79^30 terminates!

[QUOTE=unconnected;562575]79^30 terminates![/QUOTE]
Good! Another mixed parity catch!

[QUOTE=unconnected;562575]79^30 terminates![/QUOTE]


Yes, very, very good !
And we have an other mixed parity found by yoyo : 12^119 !

[QUOTE=garambois;562615]Yes, very, very good !
And we have an other mixed parity found by yoyo : 12^119 ![/QUOTE]
Good finds!

The high 4, base 2 cells (exponents 556-559) have turned green. The other two will be taking a while.

Page updated !
All the bases have been updated !
I only had problems with base 29, but it's all fixed now.
Bases 72, 220 and 284 added.
There is no abnormal behavior for bases 220 and 284. But we still had to check.

Thank you all for your precious help !
I also thank you to check if nothing seems abnormal for the bases you have been working on after this big update.

Since last summer, we have accumulated a very large amount of new data. And it's still going on.

:smile:

The last two base 2 table holdouts have been convinced to turn green!

Okay, thank you very much Edwin.
The table of base 2 will be all green at the next update... And I love green !

Page updated.
Many thanks to all for your help !

The next update will take place in 2 or 3 weeks, depending on the number of requests that will be posted here.
Because now, the calculations will progress more slowly, since the sequences have all arrived at large terms.

How unusual is it to break 2^4 * 31? I don't think I've done it before tonight.

Edit: The sequence went 2^4 * 3 * 31 to 2^4 * 3 * 31^2 to 2^6 * 3 * 31, and picked up the downdriver a few terms later.

Please, which sequence ?

13^64. It got down under 50 digits, but picked up 2 * 3 so it's back above 110 dig now.

13^58, 60, 62 can be updated on your page also.

[QUOTE=VBCurtis;563992]How unusual is it to break 2^4 * 31? I don't think I've done it before tonight.

Edit: The sequence went 2^4 * 3 * 31 to 2^4 * 3 * 31^2 to 2^6 * 3 * 31, and picked up the downdriver a few terms later.[/QUOTE]
I scanned all the sequences for all the tables for the project page and came up with the following:

For 957 sequences that contain at least one 2[SUP]n[/SUP] * 31 run, no matter the length, 74 of these sequences still have 2[SUP]n[/SUP] * 31 within their last term, which leaves 883 which have broken it. I used values of 4 through 16 for n and this power may have changed within the run. I did not look for exponents for 31. If a sequence had more than one run of 2[SUP]n[/SUP] * 31, only one was counted.