Editing PEGWiki:Notational conventions
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
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]]. | 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= | |
===Both text-mode and math-mode=== | ===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>").) | * '''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>) | * Variable assignment should occur through the <math>\gets</math> symbol (LaTeX code: <code>\gets</code>) | ||
− | + | =Technical notation= | |
===Sets and related items=== | ===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. | * 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 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>. | * 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>. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |