This site is supported by donations to The OEIS Foundation.

User:M. F. Hasler/dynamic content

From OeisWiki
Jump to: navigation, search

This page is about dynamic content on OEIS, i.e., several parts of the OEIS records (in particuliar LINKS, PROGRAMs, b-files, lists, tables & graphs) that can (and maybe should) be computed by the web server software or on client side (javascript, ...), rather than computed/written by the submitter and/or stored & retreived as a static file or part of the record.

There are many possibilities for doing so which in many cases require almost no effort for changes in the server software, nor additional server load, please read on.

Dynamic content

Basic principles

Dynamic content, as defined in the header, could be produced and stored in several ways:

  • Upon submission of a contribution (to be discussed, maybe depending on the precise item, whether this should be done as soon as a contribution is proposed, or upon "approval").
Most certainly, this should be the case for most material that goes into the "record" itself (LINKS, ...; PROGRAMs might be an exception due to so many possible languages that it is more reasonable to produce them on demand), as opposed to supporting files (b-file, graphics, ...)
  • on server side upon request (e.g., a b-file, produced by following a fixed link or by sumbitting a form, e.g., by entering the number of desired terms into an "input" text field and hitting "Enter"). Depending on the precise case, this could produce a file which remains stored "forever", just cached for some fixed time (days or months), or just sent to the client without ever be stored in a file.
  • on client side, via javascript or similar. See the example of #Implementations for a Javascript that produces a given number of terms for sequences defined by a linear recurrence.
  • Some other rudimentary forms of "dynamic content" are already implemented or could be added on the submission form:
    • The check of DATA against existing sequences,
    • The LINK creation/completion for b-files (Name of author, and MIN / MAX,)
    • More of this sort would be useful, e.g., a template to SeqFan posts or Wikipedia pages.

Keywords

  • Keywords could play an important rôle in dynamic content. A minimalistic idea is already implemented via the "tabl" keyword, which produces a link which displays the sequence as triangle, square array or upper right triangular matrix.
Keywords with parameters: [User:M._F._Hasler/Work_in_progress/Improvements_of_OEIS#I._Keywords_with_parameters see this page] for a detailed account in how KW with parameters might easily add many interesting functionalities with minimal effort, for many types of sequences: tabl, cofr, frac, lrec, ....
One concrete and simple example could be the "lrec" keyword: for linear recurrences we have the following:
  • either we have a LINK (usually the last one) giving its signature. Presence of that link could toggle the "lrec" keyword, with signature as additional arguments.
  • but that link could also be produced dynamically when the "lrec" KW is present: either with signature as additional args, or with order as additional arg, or without additional arg: the order and signature could be determined from DATA. (This could also be done w/o the lrec KW, but there are false positive [DATA may suggest an LREC where we don't really have one. Then the "lrec" KW added by hand would confirm the conjectured LREC. And/or a missing "LREC" kw could toggle a COMMENT "DATA suggests that this is an LREC of order ##, signature (...), but absence of the "LREC" keyword suggests that might not be the case. If you can prove or disprove it, please add a comment.")
  • given the signature we can *easily* (e.g., standard JavaScript) compute any desired number of terms. These could
    • be added incrementally in the DATA section, and/or
    • be made available through a custom "b-file" link (which might comprise an input field to enter the desired length and/or desired format, to be produced on the fly, client-side (through JS for example) or otherwise.
  • knowledge of the signature also straightforwardly allows producing various PROGRAMs in various languages (see page ...)

LINKS

  • For "lrec" sequences, a link to "Index entries for recurrent... signature (...)." could be produced automatically. For example, assuming an extended keyword "lrec:c1:c2:...:cN" is to be parsed:
/* assume $kw holds "lrec:1:4:3:1" for linear recurrence a(n+1)= 1*a(n) + 4*a(n-1) +.... */
$coeffs = preg_split(":",$kw); $order=sprintf("%02d",count($coeffs)-1);
$signature=implode(", ",array_slice($coeffs,2)));
$links .= "\n<a href='/index/Rec#order_$order'>Index to linear recurrences with constant coefficients, order "
 .(int)$order.", signature ($signature)</a>";
  • The "lrec" keyword, either with the coefficients as additional parameters, or using data from the LINKS section, or by analysing the DATA field, could be made a link which pops up a requester for producing DATA for a range of indices and format to be chosen by the user (b-file, a list in '[x, y, ..., z]' format, or ...)
  • As noted above, links to some standard websites such as: wikipedia.org, seqfan.eu, mathworld,... could be processed semi-automatically: pasting the bare link into an empty line of the editing field (and maybe hitting some button) could "decorate" it with what is needed: Author, HREF tag, further explanation.
/* assume the LINKS section is updated with new line that just contains a bare link */
$links = explode( "\n", $links );
foreach ($links as $index => $line):
  if( $pieces = preg_match( '/\$http.*[.]seqfan.eu/pipermail/seqfan/\)\(2015\)-\([A-Za-z]*\).*/', $line)):
    $links[$index] = "Authors, <a href='$line'>Title_Of_The_Post</a>, SeqFan mailing list, $pieces[3] $pieces[2]." 
  elseif( $pieces = preg_match( '/\$http.*[.]wikipedia.org/wiki/\(.*\)/', $line)):
    $links[$index] = "Wikipedia, <a href='$line'>$pieces[1]</a>, retrieved on ".date("M d Y").".";
  elseif (...other similar checks...):
  endif;
endforeach;
$links = implode( "\n", $links );

Other Possibilities

...

Implementations

Brainstorming and discussion

[This part page is to be reformatted and "wikified"... anyone, feel free to edit and/or add your comments whereever you wish!]

Above this section goes the "refined content", below is initial brainstorming which should probably re rephrased, wikified, etc., specifically:


The basic idea

[e-mail sent to editors-in-chief, Feb 10 2011]

Dear "staff",

making some minor edits to very basic sequences (m^n mod p), I had an idea I wish to submit, for what it's worth.

Basically, it's the idea of creating b-files (and maybe other stuff) "on the run", for very simple sequences. For example, for periodic sequences, I think it would create minimal load for the server to create and/or send a b-file of "arbitrary" size.

One could imagine several links for receiving 1000, 10 000 or 100 000 terms, e.g.

"Table of n, a(n) for
<a href="http://oeis.org/A000004/b000004.txt?1000">n=1...1000</a> -
<a href="http://oeis.org/A000004/b000004.txt?10000">n=1...10000</a> -
<a href="http://oeis.org/A000004/b000004.txt?100000">n=1...100000</a>."

Depending on what is preferrable for the server, once they have been created, they could be cached for some given time, or permanently remain there and a "hard wired" link could be made to that b-file.

This could be coded in a very few lines of script.

To this end, one could implement keywords period:N (where N is the length of the period), and then create the terms using those already present in the %S lines (provided that there are enough terms corresponding to at least one full period, perhaps preceded by some initial terms not part of the period).

The same could be done for linear recurrences with constant coefficients, again with practically no computing power needed.

Alternatively, these links could produce the requested data by executing very simple Javascript on client side (i.e., in the visitor's browser) so that no server load at all would be produced; it would even save the existing server load and bandwith due to search engines and other robots downloading over and over again all the (partially huge) b-files. [Remark added Jun 27 2015]

In a second step one could go further and automatically create code snippets (in PARI, C, Maple, ...) for these sequences; at least for periodic sequences, but also for linear recurrences (among which all polynomial sequences), this would again be extremely easy (1 line of code). I offer to write the code (e.g., in PHP) which would create the desired output, if the idea is favourably accepted by the "system gurus".

Regards,

Maximilian

PS: maybe an intermediate (or even better ?) solution would be to provide some buttons, on the "edit" screen, for creating these elements (b-file & link ; PARI/Maple/... code) and then add them statically, without changing anything in the normal functionning of the OEIS.

Reply from Charles Greathouse

I've often thought about automating the display of basic features of simple sequences, for example linear recurrences. There are probably 5-10,000 such sequences in the OEIS and their quality is uneven. Doing a project like this would be an opportunity to bring these sequences all up the the same level and offer new tools. (Also, one would hope that this would reduce the number of edits submitted of the form, "%F a(0) = x, a(n) = y + a(n-1)"...)

Examples of things that could be done:

  • Automatic b-file generation, as Maximilian suggests. This could be one-time (create b-files and links of the form "Autobot, Table of n, a(n) for n = 0..10000"), on-demand (click the link and a new b-file is created and stored), static (no b-file is ever stored, but they're generated as needed), or client-side (the server sends only a snippet of code, which the viewer's computer uses to generate a b-file). The last costs almost no resources but doesn't allow graphing.
  • Programs for generating terms in lots of languages. There are thousands of polynomial sequences in the OEIS, too many to have code in even the three main languages, but others (e.g., Scheme) have almost no coverage. By putting them 'all in one place' we could have high-quality code in many languages.
  • Basic properties could be listed in a standard format. This would make it easier to search through them as a user, as well as ensuring that all the properties are actually there. For example: I might look up a sequence in hopes of finding its asymptotic growth, but many sequences don't list it. It wouldn't be that hard to do this in one place for all linear recurrences. (What other sorts of sequences can be similarly parametrized?)

Maximilian, maybe you should make a page on the wiki for discussing this? — Charles Greathouse, 10 February 2011


This is "done" -- well, almost... ;) — M. F. Hasler 16:07, 10 February 2011 (UTC)

See also

History of this document

  • M. F. Hasler created this document, 10 February 2011
  • M. F. Hasler reformatted it and added much more details and material, 27 July 2015