PEGWiki:Notational conventions - Revision history

Brian: /* Both text-mode and math-mode */

2011-11-20T21:15:34Z

‎Both text-mode and math-mode

Brian: /* Both text-mode and math-mode */

2011-11-20T21:12:16Z

‎Both text-mode and math-mode

Brian at 19:58, 28 June 2011

2011-06-28T19:58:13Z

Brian: \mathbb{N}_0, \mathbb{N}_1

2011-06-28T19:02:55Z

\mathbb{N}_0, \mathbb{N}_1

Brian: /* Technical notation */

2009-12-23T17:53:25Z

‎Technical notation

Brian at 18:03, 19 December 2009

2009-12-19T18:03:37Z

Brian: moved PEGWiki:Pseudocode conventions to PEGWiki:Notational conventions: original title is too narrow

2009-12-19T02:01:14Z

moved PEGWiki:Pseudocode conventions to PEGWiki:Notational conventions: original title is too narrow

Brian: /* Technical notation */

2009-12-19T02:00:20Z

‎Technical notation

Brian: /* Technical notation */

2009-12-19T01:59:53Z

‎Technical notation

Brian: /* Text-mode conventions */

2009-12-19T01:47:43Z

‎Text-mode conventions

@@ Line 11: / Line 11: @@
 * If something is not a real command, ''e.g.'' <code>input</code> or <code>print</code>, it should not be written like a function (its parameter list should not have parentheses).
 * Object-oriented code should be used wherever appropriate, and '''nowhere else'''. The members of an object should be indicated by the dot operator <code>.</code>. For example, it makes sense to represent a data structure as an object (which encapsulates the structure's data). However, please do not wrap an entire algorithm in an object as would be done in Java; that is pointless and only leads to clutter.
-* The mod operator should never return a negative result; the number-theoretic convention of always yielding a non-negative integer should be followed. (Note that there is no mainstream programming language in which mod behaves in this way.)
+* The mod operator should never return a negative result; the number-theoretic convention of always yielding a non-negative integer should be followed, as in Scheme.
 ===Text-mode only===

@@ Line 4: / Line 4: @@
 ===Both text-mode and math-mode===
 * '''Structure should be indicated by indentation''', as in Python. Adding braces <code>{}</code> as in C or words such as <code>begin</code> and <code>end</code> as in Pascal would introduce unnecessary clutter into pseudocode blocks. '''Do not use tabs''' for indentation. Five spaces is a good guideline. (In LaTeX pseudocode, this means five full-width spaces (a full-width space is "<code>\ </code>").)
-* The <code>for</code>, <code>if</code>/<code>else</code>, and <code>while</code> statements should not be followed by words like "do" or "then"; pseudocode is intended for humans, not machines.
+* The <code>for</code>, <code>if</code>/<code>else</code>, and <code>while</code> statements should not be followed by words like "do" or "then", as in Pascal, but should stand alone, as in C; pseudocode is intended for humans, not machines.
 * Similarly, statements should not end in semicolons.
 * Indices into arrays should be placed in square brackets, <code>[]</code>. The Pascal convention of separating indices by commas is preferred to the C convention of having a separate set of brackets for each index (simply by virtue of being nicer and more intuitive), but the latter may be occasionally appropriate to reinforce the interpretation of the array's structure. Use your common sense.
 * Parameter lists should be enclosed in parentheses, <code>()</code>, and parameters should be separated by commas.
-* A function header should contain with the word <code>function</code>, the function's name, and the function's parameter list, in that order. The body of a function should be indented.
+* A function header should contain with the word <code>function</code>, the function's name, and the function's parameter list, in that order, as in PHP or JavaScript. The body of a function should be indented.
 * If something is not a real command, ''e.g.'' <code>input</code> or <code>print</code>, it should not be written like a function (its parameter list should not have parentheses).
 * Object-oriented code should be used wherever appropriate, and '''nowhere else'''. The members of an object should be indicated by the dot operator <code>.</code>. For example, it makes sense to represent a data structure as an object (which encapsulates the structure's data). However, please do not wrap an entire algorithm in an object as would be done in Java; that is pointless and only leads to clutter.
-* The mod operator should never return a negative result; the number-theoretic convention of always yielding a non-negative integer should be followed.
+* The mod operator should never return a negative result; the number-theoretic convention of always yielding a non-negative integer should be followed. (Note that there is no mainstream programming language in which mod behaves in this way.)
 ===Text-mode only===

@@ Line 1: / Line 1: @@
 This page documents some conventions to be followed when writing articles on PEGWiki. These are not binding policy on PEGWiki, but following them should minimize confusion and promote consistency across articles. You won't get in trouble for not following them, but what you write is likely to be slightly modified to conform with these conventions if it doesn't initially. If you see arcane or unfamiliar notation anywhere in an article, but especially in a pseudocode block, you may find its meaning here. Changes to these conventions should be discussed on the [[PEGWiki_talk:Notational conventions|talk page]].
-=Pseudocode conventions=
+==Pseudocode conventions==
 ===Both text-mode and math-mode===
 * '''Structure should be indicated by indentation''', as in Python. Adding braces <code>{}</code> as in C or words such as <code>begin</code> and <code>end</code> as in Pascal would introduce unnecessary clutter into pseudocode blocks. '''Do not use tabs''' for indentation. Five spaces is a good guideline. (In LaTeX pseudocode, this means five full-width spaces (a full-width space is "<code>\ </code>").)
@@ Line 27: / Line 27: @@
 * Variable assignment should occur through the <math>\gets</math> symbol (LaTeX code: <code>\gets</code>)
-=Technical notation=
+==Technical notation==
 ===Sets and related items===
 * Items enclosed in braces <math>\{\}</math> and separated by commas form a set or multiset. For example, <math>\{1,2,3\}</math> is a set containing the elements 1, 2, and 3. Normally they form a set; they form a multiset if stated otherwise. The difference is that a set contains no duplicate elements. Sets and multisets should be ''typed'': that is, a set or multiset should not contain elements of different types. However, a set/multiset may itself contain sets/multisets, or any other kind of item.
@@ Line 51: / Line 51: @@
 * The number of vertices in graph <math>G</math> is denoted <math>|V(G)|</math> (the size of the vertex set), and the number of edges <math>|E(G)|</math> (the size of the edge set). When discussing asymptotic performance, however, we generally write just <math>V</math> and <math>E</math>.
 * The weight of an edge from vertex ''u'' to vertex ''v'' is regarded as the value of a ''cost function'' which should be denoted by a sensible name such as <code>wt</code>, hence we have <code>wt(u,v)</code> and so on. A weighted graph is then regarded as the tuple <math>(V,E,\mathrm{wt})</math>.

@@ Line 43: / Line 43: @@
 * A ''list'' is written like a set but with square brackets, <math>[\,]</math>. It is an ordered collection of elements of the same type. A list is like a set in that its size is not fixed but elements can be added and removed. It is like a tuple in that two lists are considered equal if and only if they are of the same size and all pairs of corresponding elements are equal. Hence, <math>[1,2,3] \neq [1,3,2]</math>, as their elements are in different orders.
 * Two lists written with a plus sign between them represents the concatenation of the two lists: hence, <math>[1,2] + [3,4] = [1,2,3,4]</math>. Notice that concatenation is noncommutative.
 ===Graph theory===

@@ Line 32: / Line 32: @@
 * A set/multiset that contains no elements is denoted ∅ (LaTeX: <math>\emptyset</math>).
 * A set/multiset that contains all elements of a given type is denoted <math>U</math>, the universal set. The type can generally be inferred from context.
-* Items enclosed in parentheses <math>()</math> and separated by commas form a ''tuple''. For example, <math>(A,B)</math> is an ordered pair (a tuple with two elements). Tuples, unlike sets and multisets, may contain elements of different types.
+* Items enclosed in parentheses <math>()</math> and separated by commas form a ''tuple''. For example, <math>(A,B)</math> is an ordered pair (a tuple with two elements). Tuples, unlike sets and multisets, may contain elements of different types, and, again unlike sets and multisets, they have a fixed size.
-* Equality of tuples is denoted by an equals sign, <math>=</math>.
+* Equality of tuples is denoted by an equals sign, <math>=</math>. Two tuples are equal if and only if they are equal in size and all corresponding pairs of elements are equal; hence, <math>(B,A) \neq (A,B) \neq (A,B,C)</math>.
 * The symbol ∈ means "is a member of", and ∉ means "is not a member of ".
 * The union of two sets or multisets <math>S</math> and <math>T</math> is denoted <math>S\cup T</math>, their intersection <math>S\cap T</math>, and their difference <math>S\setminus T</math>.
@@ Line 41: / Line 41: @@
 * The complement of a set is denoted <math>S'</math>; the complement is not defined on multisets.
 * The sum of two multisets <math>S</math> and <math>T</math> is denoted <math>S \uplus T</math>; this is not defined on ordinary sets.
 ===Graph theory===

@@ Line 1: / Line 1: @@
-This page documents some conventions to be followed when writing pseudocode on PEGWiki. These are not binding policy on PEGWiki, but following them should minimize confusion and promote consistency across articles. You won't get in trouble for not following them, but what you write is likely to be slightly modified to conform with these conventions if it doesn't initially. If you see arcane or unfamiliar notation anywhere in an article, but especially in a pseudocode block, you may find its meaning here. Changes to these conventions should be discussed on the [[PEGWiki_talk:Pseudocode conventions|talk page]].
+This page documents some conventions to be followed when writing articles on PEGWiki. These are not binding policy on PEGWiki, but following them should minimize confusion and promote consistency across articles. You won't get in trouble for not following them, but what you write is likely to be slightly modified to conform with these conventions if it doesn't initially. If you see arcane or unfamiliar notation anywhere in an article, but especially in a pseudocode block, you may find its meaning here. Changes to these conventions should be discussed on the [[PEGWiki_talk:Notational conventions|talk page]].
-=Universal conventions=
+=Pseudocode conventions=
 * '''Structure should be indicated by indentation''', as in Python. Adding braces <code>{}</code> as in C or words such as <code>begin</code> and <code>end</code> as in Pascal would introduce unnecessary clutter into pseudocode blocks. '''Do not use tabs''' for indentation. Five spaces is a good guideline. (In LaTeX pseudocode, this means five full-width spaces (a full-width space is "<code>\ </code>").)
 * The <code>for</code>, <code>if</code>/<code>else</code>, and <code>while</code> statements should not be followed by words like "do" or "then"; pseudocode is intended for humans, not machines.
@@ Line 12: / Line 13: @@
 * The mod operator should never return a negative result; the number-theoretic convention of always yielding a non-negative integer should be followed.
-=Text-mode conventions=
+===Text-mode only===
 * Variable assignment should occur through the use of a single equals sign, <code>=</code>, although the Pascal notation of <code>:=</code> is also acceptable.
 * Equality testing should also occur through the use of a single equals sign, <code>=</code>, but is distinguished from variable assignment by context. For example, if it is preceded by <code>if</code>, it is an equality test, and if it stands alone, it is an assignment. The C notation of <code>==</code> should be avoided.
-* The symbols <code>&lt;=</code>/<code>&gt;=</code>/<code>&lt;&gt;</code> and <code>&le;/&ge;/&ne;</code> are equally acceptable, but in most other cases a Unicode symbol should be used whenever both necessary and possible. For example, <code>oo</code> for <code>∞</code> is unacceptable.
+* The symbols <code>&lt;=</code>, <code>&gt;=</code>, and <code>&lt;&gt;</code> are equally acceptable as their single-symbol Unicode counterparts <code>&le;</code>, <code>&ge;</code>, and <code>&ne;</code>, but in most other cases a Unicode symbol should be used whenever both necessary and possible. For example, <code>oo</code> for <code>∞</code> is unacceptable.
 * Variables (and named constants) from pseudocode blocks which are referenced in the article text should be in <i>italics</i>; all other items, such as functions and literal constants, should be <code>monospaced</code>. The exception is literal numerical constants; it is acceptable not to format them specially, since they cause no confusion.
-=Math-mode conventions=
+===Math-mode only===
 * The LaTeX <code>\sqrt</code> command is almost always preferable to typing out <math>\operatorname{sqrt}</math>.
 * The vinculum (horizontal bar) to indicate division (produced by the <code>\frac</code> command) is usually best, but if the numerator or denominator is complex, a single slash <math>/</math> is preferable when it improves readability or overall aesthetic appeal.
@@ Line 27: / Line 28: @@
 =Technical notation=
-==Sets and related items==
+===Sets and related items===
-* The symbol ∈ means "is a member of". For example, <math>\pi</math> is a member of the set of real numbers, hence we might write <math>\pi \in \mathbb{R}</math>. Similarly, ∉ means "is not a member of"; <math>\pi \notin \mathbb{Q}</math>. The union of two sets <math>S</math> and <math>T</math> is denoted <math>S\cup T</math>, their intersection <math>S\cap T</math>, and their difference <math>S\setminus T</math>.
+* Items enclosed in braces <math>\{\}</math> and separated by commas form a set or multiset. For example, <math>\{1,2,3\}</math> is a set containing the elements 1, 2, and 3. Normally they form a set; they form a multiset if stated otherwise. The difference is that a set contains no duplicate elements. Sets and multisets should be ''typed'': that is, a set or multiset should not contain elements of different types. However, a set/multiset may itself contain sets/multisets, or any other kind of item.
-* Items enclosed in braces {} and separated by commas form a set or multiset. For example, <math>\{1,2,3\}</math> is a set containing the elements 1, 2, and 3. Normally they form a set; they form a multiset if stated otherwise. The difference is that a set contains no duplicate elements. Sets and multisets should be ''typed'': that is, a set or multiset should not contain elements of different types. However, a set/multiset may itself contain sets/multisets, or any other kind of item.
+* A set/multiset that contains no elements is denoted ∅ (LaTeX: <math>\emptyset</math>).
-* Items enclosed in parentheses () and separated by commas form a ''tuple''. For example, <math>(A,B)</math> is an ordered pair (a tuple with two elements). Tuples may contain elements of different types.
+* A set/multiset that contains all elements of a given type is denoted <math>U</math>, the universal set. The type can generally be inferred from context.
-==Graph theory==
+* Items enclosed in parentheses <math>()</math> and separated by commas form a ''tuple''. For example, <math>(A,B)</math> is an ordered pair (a tuple with two elements). Tuples, unlike sets and multisets, may contain elements of different types.
 * Vertices in graphs should be given either non-negative integers or letters as labels; letters however must be italicized except when in code blocks. Subscripts on letters are okay: we might for example label the vertices of a bipartite graph as <math>A_1,A_2,A_3,A_4,\ldots,B_1,B_2,B_3,B_4,\ldots</math>, in which edges exist only between <math>A</math>s and <math>B</math>s. Subscripts on numbers, however, are not.
 * An edge in a directed graph is an ordered pair of vertices. For example, if a graph has an edge from <math>A</math> to <math>B</math>, then this can be described as <math>(A,B)</math>. An edge in an undirected graph is an unordered pair, or a set containing two vertices: for example, <math>\{A,B\}</math>. (If self-loops are allowed, then it's actually a multiset.)
 * A graph is an ordered pair of two sets: <math>V</math> and <math>E</math>. The former is the set of vertices, and the latter the set of edges. We can write <math>G = (V,E)</math> to indicate that the graph <math>G</math> has vertex set <math>V</math> and edge set <math>E</math>. Also, given some graph <math>G</math>, <math>V(G)</math> is the vertex set of <math>G</math>, and <math>E(G)</math> is the edge set of <math>G</math>. An example of a graph is then <math>(\{A,B,C\},\{(A,B),(B,C),(A,C)\})</math>, for which <math>V=\{A,B,C\}</math> and <math>E=\{(A,B),(B,C),(A,C)\}</math>. This graph has vertices <math>A</math>, <math>B</math>, and <math>C</math>, an edge from <math>A</math> to <math>B</math>, an edge from <math>B</math> to <math>C</math>, and an edge from <math>A</math> to <math>C</math>. Note: we can write <math>(A,B) \in E(G)</math> to indicate that there exists an edge from <math>A</math> to <math>B</math>. However, the notation <math>(A,B) \in G</math> is incorrect.
 * The number of vertices in graph <math>G</math> is denoted <math>|V(G)|</math> (the size of the vertex set), and the number of edges <math>|E(G)|</math> (the size of the edge set). When discussing asymptotic performance, however, we generally write just <math>V</math> and <math>E</math>.

← Older revision	Revision as of 02:01, 19 December 2009
(No difference)