[seqfan] Re: Submission suggestion
charles.greathouse at case.edu
Sun Nov 6 23:53:36 CET 2011
Another interesting feature of the limitation in the size of sequence
lines is the ability to search for large numbers and subsequences. A
great many sequences contain both 12288 and 20736 (A000027, for
example) but most do not show them early enough to be found in a
search, allowing A178715, for example, to be discovered.
Sidenote: subsequences cannot currently be searched for reliably;
something broke in the transition to the current system.
subseq:12288,20736 does not return the sequence above, for example.
Case Western Reserve University
On Sun, Nov 6, 2011 at 5:32 PM, Richard Mathar
<mathar at strw.leidenuniv.nl> wrote:
> We read in http://list.seqfan.eu/pipermail/seqfan/2011-November/015795.html
> dww> As display, the %STU lines determine which elements are shown in various
> dww> sequence
> dww> views (the sequence page, the internal format page, the list page, the
> dww> pin plot, etc).
> dww> This adds conflicting display requirements. For example, we don't want
> dww> to display too
> dww> many elements, so we must keep the %STU lines down to 260 characters, we
> dww> don't
> dww> want enormous values in the %STU lines, etc. This creates issues for the
> dww> submitter
> dww> when entering sequences; they cannot include too many terms, etc.
> It's evident that for performance reasons the main database needs to
> contain a small snapshot ( say 3 lines with roughly 80 bytes each)
> of anything bigger than that. As Russ already pointed out, you do not
> want to scan tons of b-files each time anyone clicks on a button
> or searches for a number. The splitting between the actual few hundred
> bytes in the main database and the implicit link to the b-files is
> exhibiting exactly this real-world limitation of computational resources.
> Seqfan Mailing list - http://list.seqfan.eu/
More information about the SeqFan