User:M. F. Hasler/Work in progress/Improvements of OEIS

(Edit this Sect.0) Already some time ago, I made several suggestions to add some functionality to the OEIS server resp. user interface.
Many of these could be realized with almost no effort and, I think, huge benefit (for users, but also for editors).

See also the "To do" page with links to several other similar pages, and the Category:To-do lists.

I. Keywords with parameters

Description

Extending classical keywords by allowing to append parameters in parentheses(*), which would provide useful additional data pertaining to that particular keyword. This additional data would in general be optional: Lacking it would just produce the existing (non)behaviour, but when given, it would enable additional features, especially for nicer display.

(*) Update: Charles R Greathouse IV suggested to use ":" to separate keyword and argument(s), see column "keyword v.1" in this table. I think this is an excellent idea, to be preferred over my initial suggestion of "(...,...)". Among others, this saves 1 character and allows to use "," exclusively as keyword separator, which has technical advantages.

Implementation

In a first approach, the implementation could simply consist in removing existing validity checks and thus allowing (on a purely technical level) just any keyword, with some minor restrictions on non-alphanumerical characters . (E.g., don't allow any, apart from ":" and ",".) In that event, editors(-in-chief) would only have to have a glance to the KW section before approving sequences, to avoid that unacceptable things are published. (They should have this already now, to avoid wrong or missing keywords.)

This already allows users (and/or "global search & replace") to add these new (and possibly extended) keywords. This yields an immediately available more refined search, without requiring any other change on server side.

In a second step, additional functionality, going beyond the more refined search, can be added at any desired rate. It will basically consist in adding a hook to the display routine, which allows some further processing when one of these new/extended keywords is present. This will mainly involve adding some additional HTML code (links, maybe javascript), and finally of course implement the required functionality when such a link is followed.

Examples

tabf(Axxx,o)

When Axxx is given, this specifies the sequence of row lengths. Clicking such an extended tabf(...) keyword would then allow to display nicely the "tabf" table.

If the second optional parameter is given, it specifies the offset to use for the row-length sequence (if that existed in OEIS but not with the proper offset), i.e., tabf(Axxx,o) means that the length of row n of the table is given by Axxx(n+o).

frac(Axxx,n/d)

When Axxx is given, this specifies the sequence of denominators for the sequence of fractions whose numerators are the present sequence (or conversely). If "n" or "d" is given as optional second argument, this fixes which should be the role (numerator or denominator) of the current sequence (and thus of the other one), overriding possible default choices:

• If one is nonn and one is sign, then sign(ed) one will be the seq. of numerators
• Else, the one having more(*) zero terms than the other will be the seq. of numerators. [(*) One could imagine a sequence starting with a(0) = infinity = 1/0....]
• Else, the one having the lower A-number will be the seq. of numerators, OR:
• whichever of the two you choose to display, it will be displayed as numerators, and the other one as denominators; a link should be provided to display the other one [as numerators].
• The same *possibility* can be re-implemented by specifying, e.g., optional 2nd arg "n" in BOTH sequences.

lrec(c1,...,cN)

See the main article: /keyword lrec.

Linear recurrent sequence with coefficients c1,...,cN, i.e., a(n) = sum( c_i a(n-i), i=1..N ).

Would allow

• identification of N-th order lin.rec. sequences (a special convention, e.g. lrec(N,0) or lrec(order:N) could be used to specify the order without giving the coefficients (maybe useful in special cases, e.g. very large N)
• classification (in the classical index, or a automatically built special index for LREC sequences)
• "on the fly" computation of an arbitrary number of terms, assuming that the "regular part" of the recurrence has started sufficiently early such that this can be done based on the N last terms given as DATA.

Update: According to the above remark (*), the syntax would become "lrec:c1:...:cN".

See the main article /keyword lrec for further information and code snippets.

II. Categories of sequences

Goal

Allow a general, precise, flexible, easy, intuitive and powerful method for

1. linking from one sequence to others ("cross-references"), in a simple and nonetheless meaninngful way
2. classifying and indexing sequences

with almost no server software change required.

These categories are (in a first approximation) noting else than general keywords, with (in a second step) some additional search features.

Implementation

Implementation requires nearly no work at all, and each step of implementation is

1. backward compatible (everything that exists will still work as before)
2. adding additional functionality on its own, and does not need to proceed to the next step to have some benefit.

See the dedicated page User_talk:M._F._Hasler/Categories for details.

Level 1 of implementation: Simply allow completely general, user-defined keywords or key phrases ("Riemann hypothesis", "Zeta function", ...)

Level 2 of implementation: Any keyword/keyphrase not among the list of otherwise defined "classical" keywords is considered as "Category". This means it is automatically clickable, and a click on it will do a search for all sequences having this same keyword (or having the name Category:<this-keyphrase>).

Level 3 of implementation: Special display routines for sequences named "Category:<anything>". Such (pseudo)sequences,

• created and edited as any other sequence (without the requirement of having DATA and OFFSET)
• hold a more developed description and further information about this category
• could be displayed in some particular manner when the "Category is displayed" (i.e., search for "keyword:Name-of-that-Category")
• can have again Category keywords, making the present category a sub-category of others.
• could hold, in the DATA field, a list of subcategories or sequences (maybe: to be displayed on top of other "search results" = category member sequences, and/or for performance issues).

In turn, sub-categories of a given category could be displayed in a special manner at top or bottom of the "search results" = category member sequences.

It could be desired to display the search results (member sequences of a category) in a (slighly to radically) shorter style:

1. Display only A-number, title, offset and data
2. Display only A-number, title and 1 line of data
3. Display only A-number and title, limited to 1 line, data available as "popup"
4. Display only A-number and data limited to 1 line, title available as "popup"
5. Display only the A-numbers, titles available as "popup"

Further reading & discussion

Please see the dedicated page User talk:M. F. Hasler/Categories.

III. User interface related

More functionality

"clickable" items and "buttons" (for 1-click- or more complex functions):

• any (sufficiently long) word or number would be hyperlinked do a search for that term
• editing individual fields
• for Editors, standard replies that can be filled into the pink boxes, using a single click

Personal preferences

• allow personal customization and/or auto-save of choices, e.g.,
  • "short" (or alternate) style display of search results
  • "home page" (e.g.: pending drafts, recent sequences,...) where oeis.org would redirect to
  • choice of alternate style files:
    • dark/light background, colours of other items (title, fields, headers, ...)
    • font name and size (maybe for individual fields)
    • fixed or variable width of display, ...
    • place of "navigation menu" (traditionally on bottom, could be a column to the left or the right, or on top of the page)

enhanced display of sequences and/or search results

• alternate display template, e.g.

<Name of the sequence>:

A123456(offset,...) = (terms of the sequence)

• custom choice (auto-saved user preference) of which fields to display in search results

variable b-files

• download b-files of various (user-selectable) size and format:
  • classical b-file;
  • terms only, 1 per line;
  • terms separated by comma and/or as vector [a(1),....,a(n)]; etc...

• "on the run" computation of terms, when required (e.g. PHP) code is given.

=> for more, see the dedicated page on dynamic content.

Popup-titles with sequence names for A-numbers in the Index

A must: Sequence names should be available as pop-up titles (as elsewhere on the main OEIS), at least in the Index (which is, IMO, deceivingly useless without), if not anywhere on the wiki.

I know that the present request (Tony Noe's email of Jan.22(?) 2013) did not concern the wiki, but the Index is (or should (or would ;-) be) an integral part of the "main" OEIS, even though it is "hosted" on the wiki.

Link to discussion pages

Another "trans-OEIS" suggestion: To diminish proliferation of contibutions which are not of rigorous mathematical nature, but speculative, philosophical, or simply very long, I suggest a link in every entry of the main OEIS, to a talk page specific to that sequence: <a href="https://oeis.org/wiki/Talk:A000000">Discuss about this sequence</a>

Short signatures

From: M. F. Hasler <oeis@hasler.fr>
Date: Wed, Feb 5, 2014 at 5:54 PM
Subject: Re: [OEIS-editors]

(...) contributions like cross-references (especially !), formulas & significant comments should be more valued than "New sequences". (...)

The "short signatures" I proposed since a long time ago (*): just initials as superscripts, which show the full information as "popup", would be an acceptable solution?
e.g., a signature of "_A. U. Thor_, Mmm DD YYYY" could be converted to

<a style="vertical-align:super;font-size:tiny" title="A. U. Thor, Mmm DD YYYY" href="http://oeis.org/wiki/User....">[AUT]</a>

and be rendered as: ^[AUT], with a pop-oup title displaying "A. U. Thor, Mmm DD YYYY" when the pointer hovers over it (or equivalent on mobile device, e.g. long press), and linking to the User page (or to the user's contribution history, or to that edit in the revision history, or ...)

(and one day these tags could be created automagically from the history... but that's another story, while the above is an easy "5 minutes hack".)

(*) On Mon, Nov 15, 2010 at 6:43 AM, Maximilian Hasler wrote to NJAS, CC: Charles, David, Klaus, Ray, Richard, Russ, Tony:

...This would also allow to have a rather tiny "signature" next to each contribution, which could pop up (on hovering the mouse over it) additional information and/or links to the user page and/or contact form;
That signature could, e.g., be reduced to the initials of the contributor and the date in condensed form, e.g.: [MFH, 13-Nov-10], and the pop-up could display the full name and full time stamp (Weekday, day, month, year, hh:mm:ss TZ) and link to the user page.

automatic formatting of links

In the LINKS section of the "edit" form, it would be great (& easy to implement) to be able just to paste a link like

http://mathworld.wolfram.com/Icosidodecahedron.html
or http://en.wikipedia.org/wiki/Dodecahedron

and click on a button which would properly format them, i.e., add the author, <A HREF=...> tag, title of page and maybe the date (if easily available, as on WP and SeqFan).

I suggest built-in support at least for: mathworld, wikipedia, seqfan.eu, and maybe some more discussion groups.

Many people, me included, would then add such links much more frequently.

For non recognized web adresses, a "template" (as is done for the b-file link)

Author, <a href="...">Name</a>, website, date.

would already be fine.

IV. User and Privilege management

Fine-tune and "automatize" management status of OEIS users:

1. newbie
2. regular contributor (from 100+ edits or so)
3. editor (promotion from "contributor" to "editor" requires, say, 20 "votes" from other editors, or 3-5 "votes" from Editors-in-Chief)
4. editor-in-chief (requires 5-10 "votes" from other Ed-in-Chief).
5. admin / bureaucrat: can only be nominated by other users of that kind. These can up- and downgrade the status of any other non-admin user whenever they want.

It should be possible to display at any time a list of "(hot) candidates" for each of the possible "promotions", i.e., users who have requested, and/or are close to the requirements, to be "upgraded".

Display user stats: # (= number of) sequences authored, # signed contributions, # other edits (this will distinguish the true "elite"...), # wiki pages created, # edits on the wiki, ...