This site is supported by donations to The OEIS Foundation.

Talk:Style Sheet

From OeisWiki
Jump to: navigation, search

For older topics see the archive.

Function names

The Guide to Spelling and Notation covers many cases like prime(n), p(n), cos(x). One that just came up in a sequence: Do we write moebius, mobius, möbius, Moebius, MoebiusMu, mu, μ, 𝜇, ...? I tend to use mu but it's probably best to standardize this.

Charles R Greathouse IV 19:03, 10 July 2011 (UTC)

For what it's worth, I'd prefer Möbius mu across the board. However, for now maybe we should compromise to Moebius mu in OEIS Main and Möbius μ in the OEIS Wiki. (Mathematica programs of course keep MoebiusMu). Alonso del Arte 21:04, 10 July 2011 (UTC)
I certainly prefer Möbius to its other spellings (of course outside of contexts like Mathematica and GP where spelling must be MoebiusMu and moebius), but the main question here is how to handle the sequences since the Style Sheet is still recommending against non-ASCII characters. Moebius mu (when referring to it) and mu(n) (when used as a function) are probably best in that context. Charles R Greathouse IV 22:03, 5 September 2011 (UTC)

naming conventions for programs

I don't know whether this is the place to ask the question, but... I remember one "help" page on the old OEIS where s/o (R.J.Mathar?) tried to establish some naming conventions for (Maple(? and other?)programs, e.g., (symbolically):

  • Axxx = n -> a(n) ;
  • is_Axxx = n-> evalb( n in Axxx ? ) ;
  • Axxx_list (or Axxx_vec ?) = N -> [a(n) $ n=offset..N] ;

... [details may be wrong, this is roughly what I recall and/or use]. Any links, ideas, ...? — M. F. Hasler 00:38, 28 October 2013 (UTC)

I have my thoughts at User:Charles R Greathouse IV/Programs#Naming conventions. - Charles R Greathouse IV 05:10, 28 October 2013 (UTC)
I have mine at User:M._F._Hasler/Programs/Naming_conventions... — M. F. Hasler 05:37, 26 February 2014 (UTC)

Operations over ranges

Motivated by a recent pink box discussion: What is the best way to write the expressions below?

  Min(term(k) : start<=k<=end)
  Max(term(k) : start<=k<=end) 
  Sum(term(k) : start<=k<=end)
  Product(term(k) : start<=k<=end) 
  Integral(term(x) : start<=x<=end)
  min(k=start..end, term(k) ) 
  max(k=start..end, term(k) ) 
  sum(k=start..end, term(k) )
  product(k=start..end, term(k) ) 
  integral(x=start..end, term(x) )
  min_{k=start..end} term(k)  
  max_{k=start..end} term(k)  
  sum_{k=start..end} term(k) 
  product_{k=start..end} term(k)  
  integral_{x=start..end} term(x)

Guiding principle: The notation should follow as close as possible to the standard mathematical practice.

(1) Clearly min and max and not Min and Max is mathematical standard; thus (B) and (C) is to be preferred over (A).

(2) The range of application and the index of operation is bounded to the operation symbol; therefore again (B) and (C) is to be preferred over (A).

(3) I prefer (C) over (B) as it is again closer to the mathematical way of writing. It links the range to the operation by writing op_{..}; this way it is also done with TeX.

Moreover it emphasizes that a sum is not an operation with two variables (ranges and functions) but an operator acting on functions; this I believe is more natural. — Peter Luschny 09:50, 15 September 2011 (UTC)

There are many other ways I've seen in the OEIS, perhaps most prominent (of those missing) being
 sum(k=start, end, term(k))
I don't have strong preferences here, but I would prefer a unified standard. I think (B) and (C) are probably my favorites as they re-uses the range operator already used for b-files, giving the encyclopedia a more consistent feel. I suppose I prefer (B) slightly because of the lack of delimiters on the main term of (C).
I concur with Peter on the case (sum not Sum) and feel obliged to point out that parentheses/round brackets, not brackets/hard brackets, should be used.
Disclosure: I write LaTeX which uses (C) and GP which uses (B1).
Charles R Greathouse IV 19:53, 15 September 2011 (UTC)

It was not my intention to list all variants seen in the OEIS. Rather I believe it is important to formulate a guiding principle which goes beyond the specific example here: "The notation should follow as close as possible to the standard mathematical practice." B1: sum(k=start, end, term(k)) is just another example of the way programming languages and styles become more and more predominant in the OEIS; a shift which I attribute more to some editors then to the authors or users. — Peter Luschny 12:07, 16 September 2011 (UTC)

I'd vote for (2) [sic., (B) I think] because of machine-parsing. Also the following should be listed:

sum(k>=0, f(k) )
sum(k>=1, f(k) )

with >= preferred over >. — Joerg Arndt via Charles R Greathouse IV 13:11, 16 September 2011 (UTC)

I concur with Peter's (1) and (2) and (3). As he points out, (C) is the notation used in mathematics in all of the instances (min/max, sum, ...), (B) is the "generic" syntax of programming languages and CAS, while (A) (capitalized function names Max, Sum,...) is a pure Mathematica artefact and as such to be proscribed anywhere outside the "Mathematica" section, IMHO.
In case of sum/product I think (B) is acceptable as practical alternative of the "correct" mathematical notation, since the latter cannot be implemented as it should (domain of the "variable" as subscript) in plain text, and also because the "computational"/procedural idea of computing the sum by adding up the terms, suggested by (B), is natural in the case of sum/product, but not in the case of min/max.
In the case of min/max, my favourite (since close to standard math) notation would be max { f(k) ; k=1..n }, the maximum of a set. If I have to choose between (B) and (C) then I'm more in favour of (C): the TeX style syntax suggests the variable & range below the "max" operator, as is standard math notation. Conceptually we have the max of a set given by enumeration, S = { x1, x2, x3, ... } = { xi ; i=1,2,3... } = { x(i) ; i ∈ N }. The only argument that "explains" the notation max(x=1..N, f(x)) is the analogy with sum(...), but here it is rather an artefact of a probably inefficient computation of that maximum.
The alternative notation: max(x(i), i=1..n), not proposed above, could be seen as "functional/programming style" writing of max {x(i) ; i=1,2,3,...}. (In favour of this speaks also that the "main information", namely the general term of the sum, is given before the "detail" which is the upper and lower limit, which can often be tacitly understood.)
Summarizing, I'd say the situation is different for min/max which operate on sets, while sum/prod naturally operate on sequences (= functions of the index). The notation (x(i), i=a..b) could be seen as representation of a correct mathematical notation in both cases. M. F. Hasler, 03:26 UTC, 26 November 2012, reworded 8 March 2014 and 14 May 2015.

Function names: LCM and GCD

  • Write lcm in formulas (not LCM)
  • Write gcd in formulas (not GCD)

For example on Wikipedia all occurences of lcm and gcd in formulas are written with lower case letters. (See links below.)

Upper-case letters (LCM and GCD) are only used as an abbreviation in the text.

  • For example, the GCD of 8 and 12 is 4.
  • gcd(8,12) = 4.

Another example: A199806 Alternating LCM-sum: a(n)=sum_{k=1..n} (-1)^(k-1)*lcm(k,n).
And not, as it is: A199806 Alternating LCM-sum: a(n)=sum_{k=1..n} (-1)^(k-1)*LCM(k,n).

Wikipedia LCM Wikipedia GCDPeter Luschny 23:47, 10 November 2011 (UTC)

Any guidance on GCD as opposed to gcd? The former seems to be more prevalent in the OEIS. (This of course is irrelevant for computer programs—Mathematica requires the former and PARI apparently the latter). Alonso del Arte 20:24, 16 September 2012 (UTC)

See the first table on this mathworld page: Graham, Knuth, and Patashnik, Concrete Mathematics, as well as Bressoud and Wagon, Course in Computational Number Theory, as well as Bronshtein, Semendyayev, Musiol, and Muehlig, Handbook of Mathematics, use gcd. This settles this question for me. Peter Luschny 16:22, 17 September 2012 (UTC)

If no one has any objections, I'll go ahead and put your proposals into the Style Sheet. Alonso del Arte 17:51, 17 September 2012 (UTC)
I happily agree! Thanks for the help in defending traditional mathematical notation! — M. F. Hasler 02:50, 26 November 2012 (UTC)

Different/Not equal

In the "Spelling and notation", is it possible to add a line concerning the way(s) it should be rendered: <>, !=, =/=, ... ? --Michel Marcus 07:21, 1 December 2014 (UTC)

GLB or glb, LUB or lub

Greatest lower bound: GLB or glb? Least upper bound: LUB or lub?

Do we use glb and lub to be consistent with the convention for gcd and lcm.— Daniel Forgues 17:33, 17 October 2015 (UTC)

Test your programs!

Something I'd like to add to this Style Sheet: test your programs! Unless you're copying directly from the relevant application immediately following a successful run, copy and paste from the OEIS to the application and execute. That way you might catch some silly tiny mistake like Fiboncaci[n] that causes your program to give nothing besides an error message. - Alonso del Arte 22:05, 1 January 2016 (UTC)

Ob. on topic: +1, but some details such as NUMERIC DIGITS 200 for Rexx-code where the default 9 would fail miserably, or functions depending on the Python-version, should be obvious for folks trying to reproduce a result. While at it, your dash to introduce signatures wasn't obvious for me, I copied it as is into Notepad, saved it as temp. file, opened it in a hex. viewer, and it turned out to be an ordinary US-ASCII hyphen-minus, i.e., no &ndash; or anything else Unicode offers. –Frank Ellermann 23:16, 1 February 2018 (UTC)

References vs. Links

During recent edits it came again across my mind that it might be better if we allowed HTML (i.e., links) also in the REFERENCES section, and left in the LINKS section only material which does not correspond to published papers. (In particular, since actually nowadays almost every [even old] paper has a link to it.) I don't know where else this could be discussed, so I put it here, hoping s/o will see it. MFH 21:16, 25 May 2017 (UTC)

For a link I expect a clickable URL: no subscription, no paywall, and ideally not only an abstract. For a reference I expect trouble like books, journals, and other things outside of open access. –Frank Ellermann 08:27, 11 October 2017 (UTC)


I would suggest clarifying that users should label the version in the code when appropriate. I mention this after finding ~ 642 fairly recent entries using function xrange, which works in Python2 but not Python3. I am unsure if "range" is a direct replacement.--Bill McEachen 14:21, 17 December 2017 (UTC)

Different versions of scripting languages might be slightly out of scope for OEIS, and the range vs. xrange-issue is apparently not too bad. –Frank Ellermann 17:50, 18 December 2017 (UTC)

Referring to table entries

In the FORMULA section, other sequences are usually referred like this:

a(n) = A002620(n+3)-2

What if the sequence being referred represents a table, like A300260? Using its linear index is cumbersome. If I want to sum over one of its antidiagonals, should I write something like

a(n) = Sum_{k=1..n-3} T(n-2-k, k), with T from the table in A300260

? --Jukka Kohonen (talk) 04:43, 9 March 2018 (EST)

Since A300260 has a clear definition of the form "T(n, k) = something" (as it should), writing simply a(n) = Sum_{k=1..n-3} A300260(n-2-k, k) is the best option. --Andrey Zabolotskiy (talk) 14:13, 10 March 2018 (EST)

Roots with higher index

What about cubic roots and higher index roots? — Daniel Forgues 23:56, 13 April 2018 (EDT)