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.

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)

63 months later, AFAIK almost everything is rendered as is on OEIS proper, the comma to comma space mutilation for a comma not already followed by a space is an exception and should be disabled. There is no =/= in the Style Sheet. only <> and != are listed as okay, what are you talking about? –Frank Ellermann (talk) 04:24, 16 March 2020 (EDT)

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)

Is that related to lim sup and lim inf in Limit superior and limit inferior, and if yes, why not simply write lim sup and lim inf ? –Frank Ellermann (talk) 04:31, 16 March 2020 (EDT)

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)

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)

Conflicting style guidelines for a multi-line Comment from

Check out the edit history of draft/A014561, ignoring the content. I never added a multi-line comment to a sequence, and knew (Start)…(End) only vaguely as a feature, not the details such as upper case S+E. Therefore I looked it up here, and found the first suggestion: Comment from…(Start)…(End) in the Comments section.
However, there is another suggestion From…(Start)…(End) in Signing your name when you contribute to an existing sequence. I've proposed to fix the first suggestion, that didn't make it, therefore I'll now try to fix the second suggestion. –Frank Ellermann (talk) 06:45, 14 March 2020 (EDT)

Resolved, Comment from…(Start)…(End) is recommended, and style changes should be anyway handled in a global edit. –Frank Ellermann (talk) 09:05, 14 March 2020 (EDT)
Editors just changed "Comment from" to "From" in my contribution, although I mentioned the Style Sheet. Although I don't disagree with that edit, this whole situation is pitiable. --Andrey Zabolotskiy (talk) 15:21, 11 April 2020 (EDT)
+1, any consistent style would be acceptable. I managed to get a consistent guide, but of course that's not good enough if the editors hate the Comment from. I really don't get why this minor matter of taste is so important for some editors, and why they don't just adopt what ~njas prefers. :-( –Frank Ellermann (talk) 07:07, 13 April 2020 (EDT)

ld(x), lg(x), ln(x), and li(x)

For terms such as arctan(x) instead of atan(x) a common style helps, because math. libraries sometimes offer atan() and atan2() to confuse me. And if arctan() is good the complete zoo should use sin, tan, cos, cot, etc. consistently with corresponding arc…, e.g., no acot, although it is popular in Machin-like Pi-formulae. Personal vintage 2002 example now on github.
For the similar area zoo I picked sh(), th(), ch(), arsh(), and area(), where the latter is arth() or arch() depending on its argument in rxshell.rex, but I didn't need those functions in real life incl. OEIS and almost two decades. However, arsinh, artanh, arcosh would be consistent with arctan etc., for a value of six letters in consistency, and therefore I'd use that here. Please note how one apparently harmless style decision arctan can have unexpected side-effects:
Example, let's do x^y instead of x**y everywhere caused a several years long let's do f**k you on my side. I still think that it was a bad decision, and some days ago I stumbled over an essay explaining why: Several popular programming languages use ** for powers, several popular programming languages use ^ for other purposes, and one popular operating system uses ^ as its shell escape character, i.e., the same idea as \ in C etc.
But, and it is a big but on my side, not smaller than the ** business, for log(x) I strongly disagree with the suggestion to avoid ln(x), everybody knows what it is, nobody knows what log(x) is, and log_e(x) would be too ugly to talk about. Likewise log_10(x) and log_2(x) are just ugly, nothing is wrong the well-known lg(x) and ld(x). Just four combinations of small Latin letter L with another small Latin letter, ln. lg. ld. and li. 'coz we're geeks and won't touch anything that cannot handle li(x) up to 500 digits immediately. –Frank Ellermann (talk) 20:12, 15 March 2020 (EDT)

If there's a compelling reason to write, e.g., log_2(x) as it just happened in a draft for A333355, where log_3(x) is anyway required and a consistent log_2(x) makes sense (for me), it is of course okay. –Frank Ellermann (talk) 21:55, 15 March 2020 (EDT)