Current status of aliquot sequences with start term below 1 2 3 4 million


This is a page I put together inspired by schickel's AllSeq.txt, combined with the fact that finding a recent copy was a pain in the butt. This is supposed to make things easier (including easier sorting and data mining). This uses Syd's wonderful Factor DataBase to get FDB's last known information about an Aliquot sequence. As such, if a worker hasn't updated the DB in a while or the DB has errors in a sequence, well... there's not much to be done about it.

Instructions:

This table makes use of a wonderful JavaScript library called DataTables created by this awesome group whose work I found thanks to StackOverflow. DataTables in turn depends on jQuery.

It's got some awesome features: you can do multi-column sorts by clicking the primary column, and then shift-clicking the secondary columns (in order of priority); it sorts the table quickly, thanks to deferred rendering, meaning the sorted data is only rendered as you scroll. (This is why repeated PageDowns can cause lag.) Some potential uses of the multi-sort include finding the shortest sequence of size 111, or all sequences with size < 115 with a certain driver. I also encourage you to use the search/filter feature (one of my favorite uses is searching by name), or the exclusion checkboxes.

If you find a sequence you would like to extend, you should reserve it in mersenneforum.org's Aliquot sequence reservations thread; That's the source for the reservations shown in this table. Keep in mind that his work may not be in the FDB (and thus not in this table).

If you'd like to have the basic information available in the old AllSeq.txt format (to e.g. perform an analysis with grep, etc.), that can be found here, while the raw JSON data that the table presents is found here.

Other Information

To keep load on the FDB to a minimum, the Python sequence-update script which tracks the data on this page runs roughly 200 sequences per hour; this is subject to change. To further reduce FDB load, the script queries the FDB ID of the last unfactored line from the previous update. Only if that line is factored does the script actually request the much heavier sequence status page. The underlying Python update code uses a (somewhat ad hoc/arbitrary) "priority" algorithm to determine which sequences are more likely to have made recent progress. To zeroth order, the priority is derived from (time_between_last_update_and_last_movement - time_since_last_update), while being generally floored at zero. (Note that this means a lower priority corresponds to greater importance, and quicker updates.) So sequences that haven't seen progress in years are checked very infrequently. There is a maximum update period, currently 90 days; even the most progress-less sequences will be updated at least that often (roughly). This maximum update period is also subject to change. Each sequence lists the date it was last updated. The current settings of a 90 day max update period, and 200 sequences per hour, is suspected to be more than sufficient to support a table size of at least five halves its current size, i.e. supporting an extension to 5 000 000, with extension to 10e6 also being quite plausible. Such an extension is tabled for now (if you'll pardon the pun), but the "technology" is now here, so to speak.

Drivers and guides: I wrote a short Python module, based on the definitions and notes from Clifford Stern's Analysis page, in order to classify the sequences in the table. The only exception to Clifford's definitions I use is to present the power of two as a "guide" if a "proper" guide is lacking. The guide column does show proper drivers, though there is a checkbox to exclude sequences controlled by a driver (as well as a box to exclude sequences with a (pesky) 3 in them). The class shown is exactly the "class" described by Clifford in his page.

At kar_bon's suggestion, the script now also records the FDB ID of the last line, to try and detect merges. The merge finder is run after each hourly update. The main drawback is that a merged sequence could advance between getting the info for one branch and the info of the other, meaning that such a merge would go undetected. In practice the merge is eventually detected, but occasionally several days after humans first notice it, depending on who or what found the merge.

At fivemack's suggestion, the script now also tracks the last time a sequence was lengthened. If, at the current update, a sequence is longer than at the previous update, the "Recent Progress" column displays the total increase in length. If a sequence has not been extended, then the date of the last extension is shown. (The FDB doesn't seem to have recorded dates before 2011-03-17.) (This feature is the basis of the new priority algorithm.)

As you've probably noticed, the code behind this website is capable of spidering the MersenneForum Aliquot sequences reservations thread. The actual reservations are tracked only in the corresponding column of the table, with no independent "master reservations file" as was previously the case. The reservation update time listed below is the last time the res-thread spider ran. The reservations are all updated independently of the sequence data, meaning every reservation is up to date (modulo the spider frequency), unlike the sequence data.

There is also a statistics page based on the data in the table. Check back every so often for new features.

If you want to request a feature, report a bug, offer an idea for the stats page, or otherwise discuss the table, please use this MF thread.


All times are UTC. Reservations are current as of 2024-12-04 05:40:02.
These sequences are currently broken: none, at the moment


Seq Ind Sz CSz Guide Cls Ab Known Factors Res Prog Last Updated Prio Hidden ID Hidden Driver Bool