Editing PEGWiki:Notational conventions

Jump to: navigation, search

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==
+
=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==
+
=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>.
 
==Coding style==
 
Blocks of code written in real programming languages should be enclosed in <nowiki><syntaxhighlight> ... </syntaxhighlight></nowiki> blocks. A list of supported languages can be found [http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi here]. Longer implementations of algorithms described in articles should be placed in a "subarticle" (''e.g.'', Foo/Bar.cpp).
 
 
Avoid choosing programming languages that programmers and computer scientists would not ordinarily use for implementing complex algorithms. C, C++, Pascal, and Java are preferable; they are the languages most often used in algorithmic programming contests, and they are the languages in which Sedgewick's ''Algorithms'' is available. C#, Python, LISP and its derivatives, Haskell, and ML-derived languages are acceptable. Try to stay away from PHP, Perl, VB, JavaScript, and assembly language (yes, I know Knuth uses assembly language, but still). Specialized programming languages such as Maple and MATLAB are sometimes justifiable but should not be used in general.
 
 
Because you are expected to choose a language that a programmer with a primarily algorithmic (rather than development-based) background would be somewhat familiar with, you can assume that the reader knows the language fairly well, so write code idiomatically whenever possible. It is not necessary to adhere to any particular style site-wide; it's okay for some articles to have beginning curly braces on the following line and others to have them on the same line, but try to be consistent within individual articles.
 

Please note that all contributions to PEGWiki are considered to be released under the Attribution 3.0 Unported (see PEGWiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

Cancel | Editing help (opens in new window)