This site is supported by donations to The OEIS Foundation.

User:M. F. Hasler/Programs

From OeisWiki
Jump to: navigation, search

This page describes my philosophy on programs in the OEIS. It may differs in several points from point of view of other OEIS editors & contributors.

Purpose of programs

  1. The most obvious (but not the only) purpose of programs is to allow to compute an arbitrary term of the sequence, say a(n), for n as large as possible, in a reasonable time. Thus one would wish to have a code snippet that can be copy-pasted into the corresponding computer algebra system or other "command line interpreter", which would define the function Axxx, as to be able to compute the term with index n by typing Axxx(n), in the same way as for any other pre-defined function like sin, isprime, ...
    1. For may sequences, especially those defined as "Numbers such that ...", a "random access" to the n-th term is not straightforward and an attempt to provide this, i.e., the function n->a(n) in a strict sense, may be inefficient and/or contrived. In that case, usually one or more of the following are good alternatives:
      1. The characteristic function of the range (= image) of the sequence, is_Axxx : Z → { true, false }. It allows to calculate the terms of the sequence lying within a certain range, by looping over all the values of that range and checking whether the number is part of the sequence.
      2. A function that returns a finite vector of a given subsequence; usually [a(offset),...,a(Nmax)], but sometimes [a(m),...,a(n)] such that MIN ≤ a(m) ≤ ... ≤ a(n) ≤ MAX, for given MAX and MIN (maybe defaulting to 0). (This may be done using the previous is_Axxx function, or also as side effect of Axxx, see /Naming conventions.)
      3. A program that computes the successor (or, predecessor) of a given number (following the example of the nextprime() function). This is particularly natural for iteratively defined sequences, a(n+1) = f(a(n)).
  2. A program may also be a way to "define" the n-th term of a sequence unambiguously, possibly in an alternative way w.r.t. the main definition ("NAME").
  3. In at least two circumstances, a program may also have as purpose "in itself", its pedagogical value:
    1. In the case of particularly "dull"/"easy"/"trivial" sequences, it may make the record a lot more interesting by giving a nontrivial (and/or maybe "funny") way of computing it. (A Serge Lang puts it in chap.1 of his "Algebra", "To remove the essential dullness of this section...")
    2. In case a nontrivial (or just other than the straightforward) way of computing something (maybe relatively trivial) is overwhelmingly more efficient. (E.g., using Mod(k,n)^m==1 rather than k^m%n==1 may speed up some functions by a factor of 100 or more.)

An inherently new, important interest in programs will arise once the server software will be able to use at least certain programs (e.g., written in PHP or JavaScript), to allow computation of more terms on server or on client side as to provide "arbitrary" b-files and/or enhanced graphics on request.


Comments

Generally, programs in the OEIS do not need comments beyond marking authorship, unless there are nontrivial additional optional arguments or similar particularities to be explained. It may also be useful to explain/justify a particular choice of coding ("Using ... here would slow down the code by a factor 50") or alternative ("In older versions of PARI, use....") right next to the code; for other, more involved comments, the COMMENT section may be more appropriate.


Style

Scripts in the OEIS should remain brief (but but also easily readable, except for exceptions).

Input validation is not required, and even usually rather undesirable for various reasons

  • It may be confusing when the programs deals with input values outside the range on which it is supposed to be defined
  • It may be "actively harmful" if the function silently returns "arbitrary" values (e.g., 0) in cases where it is undefined. It can reasonably be argued that a faithful implementation of a function not defined in some point x should not be well-defined for that input value of x. In case of doubt, it is better to issue an error or warning rather than to return 0 or another arbitrary.
  • Often the simpler version is the better one, e.g., n -> if(n<0, 0, n^2) would be rather worse than n -> n^2 in case the sequence "the squares" is to be coded; the same applies to any polynomial sequence where the "simpler" version provides added value and is closer the the "original" meaning of the sequence, which has to be left-truncated only for technical reasons.(See also Doubly infinite sequences and its Index entry.)

For specific considerations in the C resp. PARI/GP languages, see (thanks to Charles R Greathouse IV)

Format

It is most important that the OEIS entry retains an "aesthetic" appearance. Programs should be kept to a minimum reasonable size in order to avoid a cluttered record and also to remain readable/understandable.

Sometimes a sequence is very hard to compute, or computing it efficiently is of importance but not possible using very "pedagogical" code. In case the program is substantially longer than 3-5 lines and/or it requires nontrivial formatting (indentation...) to be understandable, it should be uploaded as "supporting files" and made available via the Links section. In this case, many restrictions that apply in the PROGRAM section do no longer apply here: comments, input validation etc. are permitted and even recommended.

Naming conventions

See the separate page User:M. F. Hasler/Programs/Naming conventions for a detailed discussion of the naming conventions already exposed in the above.


M. F. Hasler, User:M._F._Hasler/Programs. — From the On-Line Encyclopedia of Integer Sequences® (OEIS®) wiki.Available at https://oeis.org/wiki/User:M._F._Hasler/Programs