![]() |
![]() |
#1673 | |
May 2007
Kansas; USA
29·383 Posts |
![]() Quote:
I only did the calculations on just those two bases and ONLY for the same-parity exponents up to exponent=71. They were uploaded a while ago. I have stopped now. Please take credit for everything. Obviously you did the calculations before me. I have not touched opposite-parity exponents. I'm only now interested in same-parity exponents. I have not been on the project in a couple of years and had no idea that the Navigation section that you mentioned existed about reserving bases that were not yet in the DB. I don't recall it being there a few years ago. I only look at reservations in bases that were already in the DB. I thought we had to look in the threads here to see when people are working on new bases, which is when I saw that you might be working on base 181 after Rich quoted you. That section is a long way down the page and is the last line in the section. When Rich and now you mentioned it, it took me several minutes to find it. Perhaps it can be hi-lighted somehow for new (and old, like me) people. Please accept my apologies. Gary Last fiddled with by gd_barnes on 2022-06-18 at 08:12 |
|
![]() |
![]() |
![]() |
#1674 |
"Garambois Jean-Luc"
Oct 2011
France
2×463 Posts |
![]()
Gary, there's no problem.
You meant well ! If you did the calculations up to exponent 71 for both bases, please enter your results into FactorDB, because I am only at exponent 65 for base 179 and 57 for base 181. And let me know right away so that I can stop my calculations to run my two cores on something else. I think you must have a lot more computing power than I do if you got this far in such a short time. But this mishap does raise the question of the visibility of reservations for new contributors who want to join the project. How can I make this line more visible in the table ? By writing bigger and in colors ? Do you have an idea ? Edwin and I should also make it clearer in the first post of our threads, where we can see the reservations on the main project page ? Otherwise, Gary, if you want to attack new bases and calculate sequences of the same parity, you can do it by reserving for example bases that are prime numbers like RichD does : you can reserve bases from base 233 onwards following RichD. And if you specify that you only do the calculations for the matched parity sequences, I can take care of the other sequences, but you just have to say so. Normally, I make sure that they are all at least 105 digits long. But if you choose to calculate them, you can be satisfied with 100 digits, it must be very fast for you. You can also choose to initialize some bases belonging to cycles on the same principle. I will gladly note your reservations in the appropriate place if you choose. There is also another job that can be done: adding exponents to bases 2, 3 and 5, or even 7. But this is a rather ambitious work, because the starting terms of the sequences start to be very large for these large exponents. |
![]() |
![]() |
![]() |
#1675 |
May 2007
Kansas; USA
29·383 Posts |
![]()
Jean-Luc,
I only did same-parity exponents up to base 71. Nothing with opposite-parity. Everything has been uploaded to the factordb. Not everything terminated. That would take a long time. I stopped if there was a hard cofactor >= 110. For exponents < 60, everything except 181^57 terminated. For exponents > 60, nothing terminated. My computing power for this effort was only one 8-core Windows machine. It only took ~6-7 hours. As you can see above, I did not do the hard stuff. Also I stopped once I realized that you were working on them. You can keep going on as you have on opposite-parity exponents. For same-parity exponents, 181^57 is the lowest one still open and then there's everything for exponents > 60. I wasn't able to add many iterations to the big ones with the above C110 restriction. To save you a little bit of time: All composite cofactors for those remaining same-parity exponents <= 71 have been ECM'd to either 31% for C<117 or t35 for C>=117 so you'll probably want to do some more ECM for C>=117 before going to NFS. Gary Last fiddled with by gd_barnes on 2022-06-18 at 09:30 |
![]() |
![]() |
![]() |
#1676 |
May 2007
Kansas; USA
29·383 Posts |
![]()
You asked for a suggestion on that reservation section. I would say: Just hi-light it with a different color or bold it. You could even move it up the page somewhat.
Thank you for being understanding. I get a little too excited sometimes and forget to pay the appropriate amount of attention to what is going on in the threads. The great camaraderie that you have with people here is a big part of why I chose to come back again. I may take on some new bases for same-parity exponents in the future. For now, I'll keep whittling down the existing same-parity exponents in the easier sequences thread. They are starting to become not so easy any more. :-) I do have a new idea that I'll bring up maybe on Sunday that I'd like to throw out at you. I need to take some time to detail it out first before presenting it. |
![]() |
![]() |
![]() |
#1677 |
"Ed Hall"
Dec 2009
Adirondack Mtns
22×52×47 Posts |
![]()
Maybe the reservations could be moved up the page, to just below the header info (above the "Definitions"). It could be bold and reduced to one line. There aren't any links, so it really isn't a navigation source.
I will look at some kind of note for the other thread, but all the sequences deemed available by that thread are unreserved (as best as I can determine), so work on reserved tables is outside its scope. As long a table does not yet exist, it isn't even considered. When it does exist, reservations within the table are considered. |
![]() |
![]() |
![]() |
#1678 |
"Alexander"
Nov 2008
The Alamo City
3×52×11 Posts |
![]()
The "Open" tab on the data page is not currently useful. I think people forgot what it was supposed to be used for. IIRC it was meant for open sequence bases (i.e. bases that are themselves open sequences, for i=1). I think I requested it when we (I?) started initializing the Lehmer Five, for those specific bases and any similar ones.
|
![]() |
![]() |
![]() |
#1679 |
"Garambois Jean-Luc"
Oct 2011
France
2×463 Posts |
![]()
@Gary :
OK, thanks for the clarification. I will continue my calculations for bases 179 and 181. As for your new idea, I look forward to it ! @all : Maybe I'll try to look at how to make the reservations more visible tomorrow. It all depends on the time I have. The second half of June is always extremely busy for me, even on weekends. So don't be surprised if I don't make full updates in the next few days. I may only update the reservations, or I may only update some of the bases Edwin suggested in his first post. Either way, by the beginning of July, I'll have time to do all the work. |
![]() |
![]() |
![]() |
#1680 |
"Garambois Jean-Luc"
Oct 2011
France
16368 Posts |
![]()
I'm sorry, but it was impossible for me to update the page today, except for the reservations.
And it will probably be the same next weekend, as I already announced. However, I changed the location of the "Reservation" section as suggested below by Edwin. What do you think about it ? Is it clear and is it good English ? |
![]() |
![]() |
![]() |
#1681 | |
"Ed Hall"
Dec 2009
Adirondack Mtns
10010010111002 Posts |
![]() Quote:
Thanks! |
|
![]() |
![]() |
![]() |
#1682 | |
May 2007
Kansas; USA
29×383 Posts |
![]() Quote:
I found one part in the Definitions section that confused me when returning to the effort after a couple years away. For the pink definition (over 140 digits), you state: "Pink with or without name code". Later in the same sentence you state "Free for reservation". This gave me the impression that all pink squares were free for reservation even if they had a name code in then. I quickly realized that those were truly reserved and I needed to ask someone to release them if I wanted to work on them. I think the pink definition needs to be split up onto two separate lines like the orange definition. One line if it has a name code, it is "blocked for reservation". The other line if without a name code, it is "free for reservation". One nit-pick: Base 1152 is shown out of order below base 1155. :-) Last fiddled with by gd_barnes on 2022-06-19 at 21:33 |
|
![]() |
![]() |
![]() |
#1683 |
May 2007
Kansas; USA
101011011000112 Posts |
![]()
Jean-Luc,
This is the idea I was referring to a couple days ago. I've noticed that the cutoff for the size-limit of the bases on your pages seems to vary quite a bit. On the extreme small end, there is base 20. Its largest exponent of 100 is only 131 digits. On the extreme large end, there is base 99. Its largest exponent of 100 is 200 digits! This largest size seems to vary between 131 and 200 digits throughout the table. But most bases, especially the small bases <= 10 tend to cutoff around 160-165 digits. Not very many are > 180 digits. What this does is skew the primes %. Notice that for bases ~20-30, that percentage is unusually high. For bases ~80-100, that percentage is unusually low. These two ranges of bases are on the extreme small or large end of the largest exponent. This causes the unusual percentages. Also, not having the exponents on the smaller end means we are not testing some that could be interesting to the project. So I propose this: Can we add exponents up to 160 digits for all bases on the project? This would involve additions to 22 bases: Bases 20 thru 37 (14 bases), and single bases 288, 338, 385, 392, 1058, 1152, 1155, and 1250. Bases 20 thru 30 would be the most interesting because they would have the most additions due to their small current cutoff of only 131 to 148 digits. A majority of the bases would only require an addition of <= 5 exponents. Let me know what you think. I can start on whatever initialization you think is appropriate. Gary |
![]() |
![]() |
![]() |
Thread Tools | |
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Broken aliquot sequences | fivemack | FactorDB | 46 | 2021-02-21 10:46 |
Broken aliquot sequences | schickel | FactorDB | 18 | 2013-06-12 16:09 |
A new theorem about aliquot sequences | garambois | Aliquot Sequences | 34 | 2012-06-10 21:53 |
poaching aliquot sequences... | Andi47 | FactorDB | 21 | 2011-12-29 21:11 |
New article on aliquot sequences | schickel | mersennewiki | 0 | 2008-12-30 07:07 |