Jump to content

Gray code

From Niidae Wiki
Revision as of 03:34, 5 May 2025 by imported>GreenC bot (Reformat 1 archive link. Wayback Medic 2.5 per WP:USURPURL and JUDI batch #27al)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Template:Short description Template:Use dmy dates Template:Gray code by bit width

The reflected binary code (RBC), also known as reflected binary (RB) or Gray code after Frank Gray, is an ordering of the binary numeral system such that two successive values differ in only one bit (binary digit).

For example, the representation of the decimal value "1" in binary would normally be "Template:Mono", and "2" would be "Template:Mono". In Gray code, these values are represented as "Template:Mono" and "Template:Mono". That way, incrementing a value from 1 to 2 requires only one bit to change, instead of two.

Gray codes are widely used to prevent spurious output from electromechanical switches and to facilitate error correction in digital communications such as digital terrestrial television and some cable TV systems. The use of Gray code in these devices helps simplify logic operations and reduce errors in practice.<ref>Template:Cite web</ref>

Function

[edit]

Many devices indicate position by closing and opening switches. If that device uses natural binary codes, positions 3 and 4 are next to each other but all three bits of the binary representation differ:

Decimal Binary
... ...
3 Template:Mono
4 Template:Mono
... ...

The problem with natural binary codes is that physical switches are not ideal: it is very unlikely that physical switches will change states exactly in synchrony. In the transition between the two states shown above, all three switches change state. In the brief period while all are changing, the switches will read some spurious position. Even without keybounce, the transition might look like Template:MonoTemplate:MonoTemplate:MonoTemplate:Mono. When the switches appear to be in position Template:Mono, the observer cannot tell if that is the "real" position 1, or a transitional state between two other positions. If the output feeds into a sequential system, possibly via combinational logic, then the sequential system may store a false value.

Template:AnchorThis problem can be solved by changing only one switch at a time, so there is never any ambiguity of position, resulting in codes assigning to each of a contiguous set of integers, or to each member of a circular list, a word of symbols such that no two code words are identical and each two adjacent code words differ by exactly one symbol. These codes are also known as unit-distance,<ref name="Tompkins_1956"/><ref name="Kautz_1958"/><ref name="Susskind_1958"/><ref name="Chinal_1973"/><ref name="MIL_1991"/> single-distance, single-step, monostrophic<ref name="Spaulding_1954"/><ref name="Russell_1964"/><ref name="Chinal_1973"/><ref name="MIL_1991"/> or syncopic codes,<ref name="Spaulding_1954"/> in reference to the Hamming distance of 1 between adjacent codes.

Invention

[edit]
File:Reflected binary Gray 2632058.png
Gray's patent introduces the term "reflected binary code"

In principle, there can be more than one such code for a given word length, but the term Gray code was first applied to a particular binary code for non-negative integers, the binary-reflected Gray code, or BRGC. Bell Labs researcher George R. Stibitz described such a code in a 1941 patent application, granted in 1943.<ref name="Stibitz_1941"/><ref name="Winder_1959"/><ref name="Knuth_2014"/> Frank Gray introduced the term reflected binary code in his 1947 patent application, remarking that the code had "as yet no recognized name".<ref name="Gray_1947"/> He derived the name from the fact that it "may be built up from the conventional binary code by a sort of reflection process".

File:Gray code tesseract.svg
Visualized as a traversal of vertices of a tesseract
File:Gray code number line arcs.svg
Gray code along the number line

In the standard encoding of the Gray code the least significant bit follows a repetitive pattern of 2 on, 2 off Template:Nowrap the next digit a pattern of 4 on, 4 off; the i-th least significant bit a pattern of 2i on 2i off. The most significant digit is an exception to this: for an n-bit Gray code, the most significant digit follows the pattern 2n−1 on, 2n−1 off, which is the same (cyclic) sequence of values as for the second-most significant digit, but shifted forwards 2n−2 places. The four-bit version of this is shown below:

Decimal Binary Gray
0 Template:Mono Template:Mono
1 Template:Mono Template:Mono
2 Template:Mono Template:Mono
3 Template:Mono Template:Mono
4 Template:Mono Template:Mono
5 Template:Mono Template:Mono
6 Template:Mono Template:Mono
7 Template:Mono Template:Mono
8 Template:Mono Template:Mono
9 Template:Mono Template:Mono
10 Template:Mono Template:Mono
11 Template:Mono Template:Mono
12 Template:Mono Template:Mono
13 Template:Mono Template:Mono
14 Template:Mono Template:Mono
15 Template:Mono Template:Mono

For decimal 15 the code rolls over to decimal 0 with only one switch change. This is called the cyclic or adjacency property of the code.<ref name="Goldberg_1989"/>

In modern digital communications, Gray codes play an important role in error correction. For example, in a digital modulation scheme such as QAM where data is typically transmitted in symbols of 4 bits or more, the signal's constellation diagram is arranged so that the bit patterns conveyed by adjacent constellation points differ by only one bit. By combining this with forward error correction capable of correcting single-bit errors, it is possible for a receiver to correct any transmission errors that cause a constellation point to deviate into the area of an adjacent point. This makes the transmission system less susceptible to noise.

Despite the fact that Stibitz described this code<ref name="Stibitz_1941"/><ref name="Winder_1959"/><ref name="Knuth_2014"/> before Gray, the reflected binary code was later named after Gray by others who used it. Two different 1953 patent applications use "Gray code" as an alternative name for the "reflected binary code";<ref name="Breckman_1953"/><ref name="Ragland-Schultheis_1953"/> one of those also lists "minimum error code" and "cyclic permutation code" among the names.<ref name="Ragland-Schultheis_1953"/> A 1954 patent application refers to "the Bell Telephone Gray code".<ref name="Domeshek-Reiner_1954"/> Other names include "cyclic binary code",<ref name="Winder_1959"/> "cyclic progression code",<ref name="Petherick_1953"/><ref name="Winder_1959"/> "cyclic permuting binary"<ref name="Evans_1960"/> or "cyclic permuted binary" (CPB).<ref name="Evans_1961"/><ref name="Newson_1965"/>

The Gray code is sometimes misattributed to 19th century electrical device inventor Elisha Gray.<ref name="Knuth_2014"/><ref name="Heath_1961"/><ref name="Cattermole_1969"/><ref name="Edwards_2004"/>

History and practical application

[edit]

Mathematical puzzles

[edit]

Reflected binary codes were applied to mathematical puzzles before they became known to engineers.

The binary-reflected Gray code represents the underlying scheme of the classical Chinese rings puzzle, a sequential mechanical puzzle mechanism described by the French Louis Gros in 1872.<ref name="Gros_1872"/><ref name="Knuth_2014"/>

It can serve as a solution guide for the Towers of Hanoi problem, based on a game by the French Édouard Lucas in 1883.<ref name="Lucas_1883"/><ref name="Parville_1883"/><ref name="Allardice-Fraser_1883"/><ref name="Lucas_1892"/> Similarly, the so-called Towers of Bucharest and Towers of Klagenfurt game configurations yield ternary and pentary Gray codes.<ref name="Herter-Rote_2016"/>

Martin Gardner wrote a popular account of the Gray code in his August 1972 "Mathematical Games" column in Scientific American.<ref name="Gardner_1972"/>

The code also forms a Hamiltonian cycle on a hypercube, where each bit is seen as one dimension.

Telegraphy codes

[edit]

Template:AnchorWhen the French engineer Émile Baudot changed from using a 6-unit (6-bit) code to 5-unit code for his printing telegraph system, in 1875<ref name="Zeman-Fischer_1877"/> or 1876,<ref name="Froehlich-Kent_1991"/><ref name="Fischer_2000"/> he ordered the alphabetic characters on his print wheel using a reflected binary code, and assigned the codes using only three of the bits to vowels. With vowels and consonants sorted in their alphabetical order,<ref name="Rothen_1884"/><ref name="Pendry_1920"/><ref name="MacMillan_2010"/> and other symbols appropriately placed, the 5-bit character code has been recognized as a reflected binary code.<ref name="Knuth_2014"/> This code became known as Baudot code<ref name="ITU_1909"/> and, with minor changes, was eventually adopted as International Telegraph Alphabet No. 1 (ITA1, CCITT-1) in 1932.<ref name="ITU_1933_FR"/><ref name="ITU_1933_EN"/><ref name="MacMillan_2010"/>

Template:AnchorAbout the same time, the German-Austrian Template:Ill<ref name="Zemanek_1979"/> demonstrated another printing telegraph in Vienna using a 5-bit reflected binary code for the same purpose, in 1874.<ref name="Zemanek_1976"/><ref name="Knuth_2014"/>

Analog-to-digital signal conversion

[edit]

Frank Gray, who became famous for inventing the signaling method that came to be used for compatible color television, invented a method to convert analog signals to reflected binary code groups using vacuum tube-based apparatus. Filed in 1947, the method and apparatus were granted a patent in 1953,<ref name="Gray_1947"/> and the name of Gray stuck to the codes. The "PCM tube" apparatus that Gray patented was made by Raymond W. Sears of Bell Labs, working with Gray and William M. Goodall, who credited Gray for the idea of the reflected binary code.<ref name="Goodall_1951"/>

File:US02632058 Gray.png
Part of front page of Gray's patent, showing PCM tube (10) with reflected binary code in plate (15)

Gray was most interested in using the codes to minimize errors in converting analog signals to digital; his codes are still used today for this purpose.

Position encoders

[edit]
File:Encoder Disc (3-Bit).svg
Rotary encoder for angle-measuring devices marked in 3-bit binary-reflected Gray code (BRGC)
File:Gray code rotary encoder 13-track opened.jpg
A Gray code absolute rotary encoder with 13 tracks. Housing, interrupter disk, and light source are in the top; sensing element and support components are in the bottom.

Gray codes are used in linear and rotary position encoders (absolute encoders and quadrature encoders) in preference to weighted binary encoding. This avoids the possibility that, when multiple bits change in the binary representation of a position, a misread will result from some of the bits changing before others.

For example, some rotary encoders provide a disk which has an electrically conductive Gray code pattern on concentric rings (tracks). Each track has a stationary metal spring contact that provides electrical contact to the conductive code pattern. Together, these contacts produce output signals in the form of a Gray code. Other encoders employ non-contact mechanisms based on optical or magnetic sensors to produce the Gray code output signals.

Regardless of the mechanism or precision of a moving encoder, position measurement error can occur at specific positions (at code boundaries) because the code may be changing at the exact moment it is read (sampled). A binary output code could cause significant position measurement errors because it is impossible to make all bits change at exactly the same time. If, at the moment the position is sampled, some bits have changed and others have not, the sampled position will be incorrect. In the case of absolute encoders, the indicated position may be far away from the actual position and, in the case of incremental encoders, this can corrupt position tracking.

In contrast, the Gray code used by position encoders ensures that the codes for any two consecutive positions will differ by only one bit and, consequently, only one bit can change at a time. In this case, the maximum position error will be small, indicating a position adjacent to the actual position.

Genetic algorithms

[edit]

Due to the Hamming distance properties of Gray codes, they are sometimes used in genetic algorithms.<ref name="Goldberg_1989"/> They are very useful in this field, since mutations in the code allow for mostly incremental changes, but occasionally a single bit-change can cause a big leap and lead to new properties.

Boolean circuit minimization

[edit]

Gray codes are also used in labelling the axes of Karnaugh maps since 1953<ref name="Karnaugh_1953"/><ref name="Wakerly_1994"/><ref name="Brown_2012"/> as well as in Händler circle graphs since 1958,<ref name="Händler_1958"/><ref name="Steinbuch-Wagner_1967"/><ref name="ISER_1"/><ref name="ISER_2"/> both graphical methods for logic circuit minimization.

Error correction

[edit]

In modern digital communications, 1D- and 2D-Gray codes play an important role in error prevention before applying an error correction. For example, in a digital modulation scheme such as QAM where data is typically transmitted in symbols of 4 bits or more, the signal's constellation diagram is arranged so that the bit patterns conveyed by adjacent constellation points differ by only one bit. By combining this with forward error correction capable of correcting single-bit errors, it is possible for a receiver to correct any transmission errors that cause a constellation point to deviate into the area of an adjacent point. This makes the transmission system less susceptible to noise.

Communication between clock domains

[edit]

Template:Main article

Digital logic designers use Gray codes extensively for passing multi-bit count information between synchronous logic that operates at different clock frequencies. The logic is considered operating in different "clock domains". It is fundamental to the design of large chips that operate with many different clocking frequencies.

Cycling through states with minimal effort

[edit]

If a system has to cycle sequentially through all possible combinations of on-off states of some set of controls, and the changes of the controls require non-trivial expense (e.g. time, wear, human work), a Gray code minimizes the number of setting changes to just one change for each combination of states. An example would be testing a piping system for all combinations of settings of its manually operated valves.

A balanced Gray code can be constructed,<ref name="Bhat-Savage_1996"/> that flips every bit equally often. Since bit-flips are evenly distributed, this is optimal in the following way: balanced Gray codes minimize the maximal count of bit-flips for each digit.

Gray code counters and arithmetic

[edit]

George R. Stibitz utilized a reflected binary code in a binary pulse counting device in 1941 already.<ref name="Stibitz_1941"/><ref name="Winder_1959"/><ref name="Knuth_2014"/>

A typical use of Gray code counters is building a FIFO (first-in, first-out) data buffer that has read and write ports that exist in different clock domains. The input and output counters inside such a dual-port FIFO are often stored using Gray code to prevent invalid transient states from being captured when the count crosses clock domains.<ref name="Donohue_2003"/> The updated read and write pointers need to be passed between clock domains when they change, to be able to track FIFO empty and full status in each domain. Each bit of the pointers is sampled non-deterministically for this clock domain transfer. So for each bit, either the old value or the new value is propagated. Therefore, if more than one bit in the multi-bit pointer is changing at the sampling point, a "wrong" binary value (neither new nor old) can be propagated. By guaranteeing only one bit can be changing, Gray codes guarantee that the only possible sampled values are the new or old multi-bit value. Typically Gray codes of power-of-two length are used.

Sometimes digital buses in electronic systems are used to convey quantities that can only increase or decrease by one at a time, for example the output of an event counter which is being passed between clock domains or to a digital-to-analog converter. The advantage of Gray codes in these applications is that differences in the propagation delays of the many wires that represent the bits of the code cannot cause the received value to go through states that are out of the Gray code sequence. This is similar to the advantage of Gray codes in the construction of mechanical encoders, however the source of the Gray code is an electronic counter in this case. The counter itself must count in Gray code, or if the counter runs in binary then the output value from the counter must be reclocked after it has been converted to Gray code, because when a value is converted from binary to Gray code,<ref group="nb" name="NB_Arithmetic_conversion"/> it is possible that differences in the arrival times of the binary data bits into the binary-to-Gray conversion circuit will mean that the code could go briefly through states that are wildly out of sequence. Adding a clocked register after the circuit that converts the count value to Gray code may introduce a clock cycle of latency, so counting directly in Gray code may be advantageous.<ref name="Hulst_1957"/>

To produce the next count value in a Gray-code counter, it is necessary to have some combinational logic that will increment the current count value that is stored. One way to increment a Gray code number is to convert it into ordinary binary code,<ref name="Powell_1968"/> add one to it with a standard binary adder, and then convert the result back to Gray code.<ref name="Mehta-Owens-Irwin_1996"/> Other methods of counting in Gray code are discussed in a report by Robert W. Doran, including taking the output from the first latches of the master-slave flip flops in a binary ripple counter.<ref name="Doran_2007"/>

Gray code addressing

[edit]

As the execution of program code typically causes an instruction memory access pattern of locally consecutive addresses, bus encodings using Gray code addressing instead of binary addressing can reduce the number of state changes of the address bits significantly, thereby reducing the CPU power consumption in some low-power designs.<ref name="Su-Tsui-Despain_1994"/><ref name="Guo-Parameswaran_2010"/>

Constructing an n-bit Gray code

[edit]
File:Binary-reflected Gray code construction.svg
The first few steps of the reflect-and-prefix method.
File:Gray code permutation matrix 16.svg
4-bit Gray code permutation

The binary-reflected Gray code list for n bits can be generated recursively from the list for n − 1 bits by reflecting the list (i.e. listing the entries in reverse order), prefixing the entries in the original list with a binary Template:Mono, prefixing the entries in the reflected list with a binary Template:Mono, and then concatenating the original list with the reversed list.<ref name="Knuth_2014"/> For example, generating the n = 3 list from the n = 2 list:

2-bit list: Template:Mono, Template:Mono, Template:Mono, Template:Mono  
Reflected:   Template:Mono, Template:Mono, Template:Mono, Template:Mono
Prefix old entries with Template:Mono: Template:Mono, Template:Mono, Template:Mono, Template:Mono,  
Prefix new entries with Template:Mono:   Template:Mono, Template:Mono, Template:Mono, Template:Mono
Concatenated: Template:Mono, Template:Mono, Template:Mono, Template:Mono, Template:Mono, Template:Mono, Template:Mono, Template:Mono

The one-bit Gray code is G1 = (Template:Mono). This can be thought of as built recursively as above from a zero-bit Gray code G0 = ( Λ ) consisting of a single entry of zero length. This iterative process of generating Gn+1 from Gn makes the following properties of the standard reflecting code clear:

  • Gn is a permutation of the numbers 0, ..., 2n − 1. (Each number appears exactly once in the list.)
  • Gn is embedded as the first half of Gn+1.
  • Therefore, the coding is stable, in the sense that once a binary number appears in Gn it appears in the same position in all longer lists; so it makes sense to talk about the reflective Gray code value of a number: G(m) = the mth reflecting Gray code, counting from 0.
  • Each entry in Gn differs by only one bit from the previous entry. (The Hamming distance is 1.)
  • The last entry in Gn differs by only one bit from the first entry. (The code is cyclic.)

These characteristics suggest a simple and fast method of translating a binary value into the corresponding Gray code. Each bit is inverted if the next higher bit of the input value is set to one. This can be performed in parallel by a bit-shift and exclusive-or operation if they are available: the nth Gray code is obtained by computing <math>n \oplus \left\lfloor \tfrac{n}{2} \right\rfloor</math>. Prepending a Template:Mono bit leaves the order of the code words unchanged, prepending a Template:Mono bit reverses the order of the code words. If the bits at position <math>i</math> of codewords are inverted, the order of neighbouring blocks of <math>2^i</math> codewords is reversed. For example, if bit 0 is inverted in a 3 bit codeword sequence, the order of two neighbouring codewords is reversed

Template:Block indent

If bit 1 is inverted, blocks of 2 codewords change order: Template:Block indent

If bit 2 is inverted, blocks of 4 codewords reverse order: Template:Block indent

Thus, performing an exclusive or on a bit <math>b_i</math> at position <math>i</math> with the bit <math>b_{i+1}</math> at position <math>i+1</math> leaves the order of codewords intact if <math>b_{i+1} = \mathtt{0}</math>, and reverses the order of blocks of <math>2^{i+1}</math> codewords if <math>b_{i+1} = \mathtt{1}</math>. Now, this is exactly the same operation as the reflect-and-prefix method to generate the Gray code.

A similar method can be used to perform the reverse translation, but the computation of each bit depends on the computed value of the next higher bit so it cannot be performed in parallel. Assuming <math>g_i</math> is the <math>i</math>th Gray-coded bit (<math>g_0</math> being the most significant bit), and <math>b_i</math> is the <math>i</math>th binary-coded bit (<math>b_0</math> being the most-significant bit), the reverse translation can be given recursively: <math>b_0 = g_0</math>, and <math>b_i=g_i \oplus b_{i-1}</math>. Alternatively, decoding a Gray code into a binary number can be described as a prefix sum of the bits in the Gray code, where each individual summation operation in the prefix sum is performed modulo two.

To construct the binary-reflected Gray code iteratively, at step 0 start with the <math>\mathrm{code}_0 = \mathtt{0}</math>, and at step <math>i > 0</math> find the bit position of the least significant Template:Mono in the binary representation of <math>i</math> and flip the bit at that position in the previous code <math>\mathrm{code}_{i-1}</math> to get the next code <math>\mathrm{code}_i</math>. The bit positions start 0, 1, 0, 2, 0, 1, 0, 3, ...<ref group="nb" name="NB_OEIS_A007814"/> See find first set for efficient algorithms to compute these values.

Converting to and from Gray code

[edit]

The following functions in C convert between binary numbers and their associated Gray codes. While it may seem that Gray-to-binary conversion requires each bit to be handled one at a time, faster algorithms exist.<ref name="Dietz_2002"/><ref name="Powell_1968"/><ref group="nb" name="NB_Arithmetic_conversion"/>

<syntaxhighlight lang="C"> typedef unsigned int uint;

// This function converts an unsigned binary number to reflected binary Gray code. uint BinaryToGray(uint num) {

   return num ^ (num >> 1); // The operator >> is shift right. The operator ^ is exclusive or.

}

// This function converts a reflected binary Gray code number to a binary number. uint GrayToBinary(uint num) {

   uint mask = num;
   while (mask) {           // Each Gray code bit is exclusive-ored with all more significant bits.
       mask >>= 1;
       num   ^= mask;
   }
   return num;

}

// A more efficient version for Gray codes 32 bits or fewer through the use of SWAR (SIMD within a register) techniques. // It implements a parallel prefix XOR function. The assignment statements can be in any order. // // This function can be adapted for longer Gray codes by adding steps.

uint GrayToBinary32(uint num) {

   num ^= num >> 16;
   num ^= num >>  8;
   num ^= num >>  4;
   num ^= num >>  2;
   num ^= num >>  1;
   return num;

} // A Four-bit-at-once variant changes a binary number (abcd)2 to (abcd)2 ^ (00ab)2, then to (abcd)2 ^ (00ab)2 ^ (0abc)2 ^ (000a)2. </syntaxhighlight>

On newer processors, the number of ALU instructions in the decoding step can be reduced by taking advantage of the CLMUL instruction set. If MASK is the constant binary string of ones ended with a single zero digit, then carryless multiplication of MASK with the grey encoding of x will always give either x or its bitwise negation.

Special types of Gray codes

[edit]

In practice, "Gray code" almost always refers to a binary-reflected Gray code (BRGC). However, mathematicians have discovered other kinds of Gray codes. Like BRGCs, each consists of a list of words, where each word differs from the next in only one digit (each word has a Hamming distance of 1 from the next word).

Gray codes with n bits and of length less than 2n

[edit]

It is possible to construct binary Gray codes with n bits with a length of less than Template:Math, if the length is even. One possibility is to start with a balanced Gray code and remove pairs of values at either the beginning and the end, or in the middle.<ref>Template:Cite web</ref> OEIS sequence A290772 <ref>Template:OEIS</ref> gives the number of possible Gray sequences of length Template:Math that include zero and use the minimum number of bits.

n-ary Gray code

[edit]
Ternary number → ternary Gray code
Template:Monodiv

There are many specialized types of Gray codes other than the binary-reflected Gray code. One such type of Gray code is the n-ary Gray code, also known as a non-Boolean Gray code. As the name implies, this type of Gray code uses non-Boolean values in its encodings.

For example, a 3-ary (ternary) Gray code would use the values 0,1,2.<ref name="Herter-Rote_2016"/> The (nk)-Gray code is the n-ary Gray code with k digits.<ref name="Guan_1998"/> The sequence of elements in the (3, 2)-Gray code is: 00,01,02,12,11,10,20,21,22. The (nk)-Gray code may be constructed recursively, as the BRGC, or may be constructed iteratively. An algorithm to iteratively generate the (Nk)-Gray code is presented (in C):

<syntaxhighlight lang="C"> // inputs: base, digits, value // output: Gray // Convert a value to a Gray code with the given base and digits. // Iterating through a sequence of values would result in a sequence // of Gray codes in which only one digit changes at a time. void toGray(unsigned base, unsigned digits, unsigned value, unsigned gray[digits]) { unsigned baseN[digits]; // Stores the ordinary base-N number, one digit per entry unsigned i; // The loop variable

// Put the normal baseN number into the baseN array. For base 10, 109 // would be stored as [9,0,1] for (i = 0; i < digits; i++) { baseN[i] = value % base; value = value / base; }

// Convert the normal baseN number into the Gray code equivalent. Note that // the loop starts at the most significant digit and goes down. unsigned shift = 0; while (i--) { // The Gray digit gets shifted down by the sum of the higher // digits. gray[i] = (baseN[i] + shift) % base; shift = shift + base - gray[i]; // Subtract from base so shift is positive } } // EXAMPLES // input: value = 1899, base = 10, digits = 4 // output: baseN[] = [9,9,8,1], gray[] = [0,1,7,1] // input: value = 1900, base = 10, digits = 4 // output: baseN[] = [0,0,9,1], gray[] = [0,1,8,1] </syntaxhighlight>

There are other Gray code algorithms for (n,k)-Gray codes. The (n,k)-Gray code produced by the above algorithm is always cyclical; some algorithms, such as that by Guan,<ref name="Guan_1998"/> lack this property when k is odd. On the other hand, while only one digit at a time changes with this method, it can change by wrapping (looping from n − 1 to 0). In Guan's algorithm, the count alternately rises and falls, so that the numeric difference between two Gray code digits is always one.

Gray codes are not uniquely defined, because a permutation of the columns of such a code is a Gray code too. The above procedure produces a code in which the lower the significance of a digit, the more often it changes, making it similar to normal counting methods.

See also Skew binary number system, a variant ternary number system where at most two digits change on each increment, as each increment can be done with at most one digit carry operation.

Balanced Gray code

[edit]

Although the binary reflected Gray code is useful in many scenarios, it is not optimal in certain cases because of a lack of "uniformity".<ref name="Bhat-Savage_1996"/> In balanced Gray codes, the number of changes in different coordinate positions are as close as possible. To make this more precise, let G be an R-ary complete Gray cycle having transition sequence <math>(\delta_k)</math>; the transition counts (spectrum) of G are the collection of integers defined by

<math display="block">\lambda_k = |\{ j \in \mathbb{Z}_{R^n} : \delta_j = k \}| \, , \text { for } k \in \mathbb{Z}_n</math>

A Gray code is uniform or uniformly balanced if its transition counts are all equal, in which case we have <math>\lambda_k = \tfrac{R^n}{n}</math> for all k. Clearly, when <math>R = 2</math>, such codes exist only if n is a power of 2.<ref>Template:Cite journal</ref> If n is not a power of 2, it is possible to construct well-balanced binary codes where the difference between two transition counts is at most 2; so that (combining both cases) every transition count is either <math>2\left\lfloor \tfrac{2^n}{2n} \right\rfloor</math> or <math>2\left\lceil \tfrac{2^n}{2n} \right\rceil</math>.<ref name="Bhat-Savage_1996"/> Gray codes can also be exponentially balanced if all of their transition counts are adjacent powers of two, and such codes exist for every power of two.<ref name="Suparta_2005"/>

For example, a balanced 4-bit Gray code has 16 transitions, which can be evenly distributed among all four positions (four transitions per position), making it uniformly balanced:<ref name="Bhat-Savage_1996"/> Template:Block indent Template:Block indent Template:Block indent Template:Block indent whereas a balanced 5-bit Gray code has a total of 32 transitions, which cannot be evenly distributed among the positions. In this example, four positions have six transitions each, and one has eight:<ref name="Bhat-Savage_1996"/> Template:Block indent Template:Block indent Template:Block indent Template:Block indent Template:Block indent

We will now show a construction<ref name="Flahive-Bose_2007"/> and implementation<ref name="Strackx-Piessens_2016"/> for well-balanced binary Gray codes which allows us to generate an n-digit balanced Gray code for every n. The main principle is to inductively construct an (n + 2)-digit Gray code <math>G'</math> given an n-digit Gray code G in such a way that the balanced property is preserved. To do this, we consider partitions of <math>G = g_0, \ldots, g_{2^n-1}</math> into an even number L of non-empty blocks of the form

<math display="block">\left\{g_0\right\}, \left\{g_1, \ldots, g_{k_2}\right\}, \left\{g_{k_2+1}, \ldots, g_{k_3}\right\}, \ldots, \left\{g_{k_{L-2}+1}, \ldots, g_{-2}\right\}, \left\{g_{-1}\right\}</math>

where <math>k_1 = 0</math>, <math>k_{L-1} = -2</math>, and <math>k_{L} \equiv -1 \pmod{2^n}</math>). This partition induces an <math>(n+2)</math>-digit Gray code given by

Template:Block indent

If we define the transition multiplicities

<math display="block">m_i = \left|\left\{ j : \delta_{k_j} = i, 1 \leq j \leq L \right\}\right|</math>

to be the number of times the digit in position i changes between consecutive blocks in a partition, then for the (n + 2)-digit Gray code induced by this partition the transition spectrum <math>\lambda'_i</math> is

<math display="block"> \lambda'_i = \begin{cases} 4 \lambda_i - 2 m_i, & \text{if } 0 \leq i < n \\ L, & \text{ otherwise } \end{cases} </math>

The delicate part of this construction is to find an adequate partitioning of a balanced n-digit Gray code such that the code induced by it remains balanced, but for this only the transition multiplicities matter; joining two consecutive blocks over a digit <math>i</math> transition and splitting another block at another digit <math>i</math> transition produces a different Gray code with exactly the same transition spectrum <math>\lambda'_i</math>, so one may for example<ref name="Suparta_2005"/> designate the first <math>m_i</math> transitions at digit <math>i</math> as those that fall between two blocks. Uniform codes can be found when <math>R \equiv 0 \pmod 4</math> and <math>R^n \equiv 0 \pmod n</math>, and this construction can be extended to the R-ary case as well.<ref name="Flahive-Bose_2007"/>

Long run Gray codes

[edit]

Long run (or maximum gap) Gray codes maximize the distance between consecutive changes of digits in the same position. That is, the minimum run-length of any bit remains unchanged for as long as possible.<ref>Template:Cite journal</ref>

Monotonic Gray codes

[edit]

Monotonic codes are useful in the theory of interconnection networks, especially for minimizing dilation for linear arrays of processors.<ref name="Savage-Winkler_1995"/> If we define the weight of a binary string to be the number of 1s in the string, then although we clearly cannot have a Gray code with strictly increasing weight, we may want to approximate this by having the code run through two adjacent weights before reaching the next one.

We can formalize the concept of monotone Gray codes as follows: consider the partition of the hypercube <math>Q_n = (V_n, E_n)</math> into levels of vertices that have equal weight, i.e.

<math display="block">V_n(i) = \{ v \in V_n : v \text{ has weight } i \}</math>

for <math>0 \leq i \leq n</math>. These levels satisfy <math>|V_n(i)| = \textstyle\binom{n}{i}</math>. Let <math>Q_n(i)</math> be the subgraph of <math>Q_n</math> induced by <math>V_n(i) \cup V_n(i+1)</math>, and let <math>E_n(i)</math> be the edges in <math>Q_n(i)</math>. A monotonic Gray code is then a Hamiltonian path in <math>Q_n</math> such that whenever <math>\delta_1 \in E_n(i)</math> comes before <math>\delta_2 \in E_n(j)</math> in the path, then <math>i \leq j</math>.

An elegant construction of monotonic n-digit Gray codes for any n is based on the idea of recursively building subpaths <math>P_{n,j}</math> of length <math>2 \textstyle\binom{n}{j}</math> having edges in <math>E_n(j)</math>.<ref name="Savage-Winkler_1995"/> We define <math>P_{1,0} = (\mathtt{0}, \mathtt{1})</math>, <math>P_{n,j} = \emptyset</math> whenever <math>j < 0</math> or <math>j \geq n</math>, and

<math display="block"> P_{n+1,j} = \mathtt{1}P^{\pi_n}_{n,j-1}, \mathtt{0}P_{n,j} </math>

otherwise. Here, <math>\pi_n</math> is a suitably defined permutation and <math>P^{\pi}</math> refers to the path P with its coordinates permuted by <math>\pi</math>. These paths give rise to two monotonic n-digit Gray codes <math>G_n^{(1)}</math> and <math>G_n^{(2)}</math> given by

<math display="block"> G_n^{(1)} = P_{n,0} P_{n,1}^R P_{n,2} P_{n,3}^R \cdots \text{ and } G_n^{(2)} = P_{n,0}^R P_{n,1} P_{n,2}^R P_{n,3} \cdots </math>

The choice of <math>\pi_n</math> which ensures that these codes are indeed Gray codes turns out to be <math>\pi_n = E^{-1}\left(\pi_{n-1}^2\right)</math>. The first few values of <math>P_{n,j}</math> are shown in the table below.

Subpaths in the Savage–Winkler algorithm
<math>P_{n,j}</math> j = 0 j = 1 j = 2 j = 3
n = 1 Template:Mono
n = 2 Template:Mono Template:Mono
n = 3 Template:Mono Template:Mono Template:Mono
n = 4 Template:Mono Template:Mono Template:Mono Template:Mono

These monotonic Gray codes can be efficiently implemented in such a way that each subsequent element can be generated in O(n) time. The algorithm is most easily described using coroutines.

Monotonic codes have an interesting connection to the Lovász conjecture, which states that every connected vertex-transitive graph contains a Hamiltonian path. The "middle-level" subgraph <math>Q_{2n+1}(n)</math> is vertex-transitive (that is, its automorphism group is transitive, so that each vertex has the same "local environment" and cannot be differentiated from the others, since we can relabel the coordinates as well as the binary digits to obtain an automorphism) and the problem of finding a Hamiltonian path in this subgraph is called the "middle-levels problem", which can provide insights into the more general conjecture. The question has been answered affirmatively for <math>n \leq 15</math>, and the preceding construction for monotonic codes ensures a Hamiltonian path of length at least 0.839Template:Px2N, where N is the number of vertices in the middle-level subgraph.<ref name="Savage_1997"/>

Beckett–Gray code

[edit]

Another type of Gray code, the Beckett–Gray code, is named for Irish playwright Samuel Beckett, who was interested in symmetry. His play "Quad" features four actors and is divided into sixteen time periods. Each period ends with one of the four actors entering or leaving the stage. The play begins and ends with an empty stage, and Beckett wanted each subset of actors to appear on stage exactly once.<ref name="Goddyn_1999"/> Clearly the set of actors currently on stage can be represented by a 4-bit binary Gray code. Beckett, however, placed an additional restriction on the script: he wished the actors to enter and exit so that the actor who had been on stage the longest would always be the one to exit. The actors could then be represented by a first in, first out queue, so that (of the actors onstage) the actor being dequeued is always the one who was enqueued first.<ref name="Goddyn_1999"/> Beckett was unable to find a Beckett–Gray code for his play, and indeed, an exhaustive listing of all possible sequences reveals that no such code exists for n = 4. It is known today that such codes do exist for n = 2, 5, 6, 7, and 8, and do not exist for n = 3 or 4. An example of an 8-bit Beckett–Gray code can be found in Donald Knuth's Art of Computer Programming.<ref name="Knuth_2014"/> According to Sawada and Wong, the search space for n = 6 can be explored in 15 hours, and more than Template:Val solutions for the case n = 7 have been found.<ref name="Sawada-Wong_2007"/>

Snake-in-the-box codes

[edit]

Template:Snakes and coils in the box.svg Snake-in-the-box codes, or snakes, are the sequences of nodes of induced paths in an n-dimensional hypercube graph, and coil-in-the-box codes,<ref name="Richards_1971"/> or coils, are the sequences of nodes of induced cycles in a hypercube. Viewed as Gray codes, these sequences have the property of being able to detect any single-bit coding error. Codes of this type were first described by William H. Kautz in the late 1950s;<ref name="Kautz_1958"/> since then, there has been much research on finding the code with the largest possible number of codewords for a given hypercube dimension.

Single-track Gray code

[edit]

Yet another kind of Gray code is the single-track Gray code (STGC) developed by Norman B. Spedding<ref name="Spedding_1994_1"/><ref name="Spedding_1994_2"/> and refined by Hiltgen, Paterson and Brandestini in Single-track Gray Codes (1996).<ref name="Hiltgen-Paterson-Brandestini_1996"/><ref name="Hiltgen-Paterson_2001"/> The STGC is a cyclical list of P unique binary encodings of length n such that two consecutive words differ in exactly one position, and when the list is examined as a P × n matrix, each column is a cyclic shift of the first column.<ref name="Etzion-Schwartz_1999"/>

File:Animated Graycode.gif
Animated and color-coded version of the STGC rotor.

The name comes from their use with rotary encoders, where a number of tracks are being sensed by contacts, resulting for each in an output of Template:Mono or Template:Mono. To reduce noise due to different contacts not switching at exactly the same moment in time, one preferably sets up the tracks so that the data output by the contacts are in Gray code. To get high angular accuracy, one needs lots of contacts; in order to achieve at least 1° accuracy, one needs at least 360 distinct positions per revolution, which requires a minimum of 9 bits of data, and thus the same number of contacts.

If all contacts are placed at the same angular position, then 9 tracks are needed to get a standard BRGC with at least 1° accuracy. However, if the manufacturer moves a contact to a different angular position (but at the same distance from the center shaft), then the corresponding "ring pattern" needs to be rotated the same angle to give the same output. If the most significant bit (the inner ring in Figure 1) is rotated enough, it exactly matches the next ring out. Since both rings are then identical, the inner ring can be cut out, and the sensor for that ring moved to the remaining, identical ring (but offset at that angle from the other sensor on that ring). Those two sensors on a single ring make a quadrature encoder. That reduces the number of tracks for a "1° resolution" angular encoder to 8 tracks. Reducing the number of tracks still further cannot be done with BRGC.

For many years, Torsten Sillke<ref name="Sillke_1997"/> and other mathematicians believed that it was impossible to encode position on a single track such that consecutive positions differed at only a single sensor, except for the 2-sensor, 1-track quadrature encoder. So for applications where 8 tracks were too bulky, people used single-track incremental encoders (quadrature encoders) or 2-track "quadrature encoder + reference notch" encoders.

Norman B. Spedding, however, registered a patent in 1994 with several examples showing that it was possible.<ref name="Spedding_1994_1"/> Although it is not possible to distinguish 2n positions with n sensors on a single track, it is possible to distinguish close to that many. Etzion and Paterson conjecture that when n is itself a power of 2, n sensors can distinguish at most 2n − 2n positions and that for prime n the limit is 2n − 2 positions.<ref name="Etzion-Paterson_1996"/> The authors went on to generate a 504-position single track code of length 9 which they believe is optimal. Since this number is larger than 28 = 256, more than 8 sensors are required by any code, although a BRGC could distinguish 512 positions with 9 sensors.

An STGC for P = 30 and n = 5 is reproduced here:

Single-track Gray code for 30 positions
Angle Code Angle Code Angle Code Angle Code Angle Code
Template:Mono 72° Template:Mono 144° Template:Mono 216° Template:Mono 288° Template:Mono
12° Template:Mono 84° Template:Mono 156° Template:Mono 228° Template:Mono 300° Template:Mono
24° Template:Mono 96° Template:Mono 168° Template:Mono 240° Template:Mono 312° Template:Mono
36° Template:Mono 108° Template:Mono 180° Template:Mono 252° Template:Mono 324° Template:Mono
48° Template:Mono 120° Template:Mono 192° Template:Mono 264° Template:Mono 336° Template:Mono
60° Template:Mono 132° Template:Mono 204° Template:Mono 276° Template:Mono 348° Template:Mono

Each column is a cyclic shift of the first column, and from any row to the next row only one bit changes.<ref name="Ruskey_2005"/> The single-track nature (like a code chain) is useful in the fabrication of these wheels (compared to BRGC), as only one track is needed, thus reducing their cost and size. The Gray code nature is useful (compared to chain codes, also called De Bruijn sequences), as only one sensor will change at any one time, so the uncertainty during a transition between two discrete states will only be plus or minus one unit of angular measurement the device is capable of resolving.<ref name="Alciatore-Histand_1999"/>

File:9-bit, Single-Track Gray Code.gif
9-bit, single-track Gray code, displaying one degree angular resolution.

Since this 30 degree example was added, there has been a lot of interest in examples with higher angular resolution. In 2008, Gary Williams,<ref name="Experts_Exchange_Williams_2008">Template:Cite web</ref>Template:Ugc based on previous work,<ref name="Etzion-Paterson_1996"/> discovered a 9-bit single track Gray code that gives a 1 degree resolution. This Gray code was used to design an actual device which was published on the site Thingiverse. This device<ref name="Thingiverse_9-Bit_Singletrack_Gray_Code_Rotorary_Encoder">Template:Cite web</ref> was designed by etzenseep (Florian Bauer) in September 2022.

An STGC for P = 360 and n = 9 is reproduced here:

Single-track Gray code for 360 positions
Angle Code Angle Code Angle Code Angle Code Angle Code Angle Code Angle Code Angle Code Angle Code
Template:Mono 40° Template:Mono 80° Template:Mono 120° Template:Mono 160° Template:Mono 200° Template:Mono 240° Template:Mono 280° Template:Mono 320° Template:Mono
Template:Mono 41° Template:Mono 81° Template:Mono 121° Template:Mono 161° Template:Mono 201° Template:Mono 241° Template:Mono 281° Template:Mono 321° Template:Mono
Template:Mono 42° Template:Mono 82° Template:Mono 122° Template:Mono 162° Template:Mono 202° Template:Mono 242° Template:Mono 282° Template:Mono 322° Template:Mono
Template:Mono 43° Template:Mono 83° Template:Mono 123° Template:Mono 163° Template:Mono 203° Template:Mono 243° Template:Mono 283° Template:Mono 323° Template:Mono
Template:Mono 44° Template:Mono 84° Template:Mono 124° Template:Mono 164° Template:Mono 204° Template:Mono 244° Template:Mono 284° Template:Mono 324° Template:Mono
Template:Mono 45° Template:Mono 85° Template:Mono 125° Template:Mono 165° Template:Mono 205° Template:Mono 245° Template:Mono 285° Template:Mono 325° Template:Mono
Template:Mono 46° Template:Mono 86° Template:Mono 126° Template:Mono 166° Template:Mono 206° Template:Mono 246° Template:Mono 286° Template:Mono 326° Template:Mono
Template:Mono 47° Template:Mono 87° Template:Mono 127° Template:Mono 167° Template:Mono 207° Template:Mono 247° Template:Mono 287° Template:Mono 327° Template:Mono
Template:Mono 48° Template:Mono 88° Template:Mono 128° Template:Mono 168° Template:Mono 208° Template:Mono 248° Template:Mono 288° Template:Mono 328° Template:Mono
Template:Mono 49° Template:Mono 89° Template:Mono 129° Template:Mono 169° Template:Mono 209° Template:Mono 249° Template:Mono 289° Template:Mono 329° Template:Mono
10° Template:Mono 50° Template:Mono 90° Template:Mono 130° Template:Mono 170° Template:Mono 210° Template:Mono 250° Template:Mono 290° Template:Mono 330° Template:Mono
11° Template:Mono 51° Template:Mono 91° Template:Mono 131° Template:Mono 171° Template:Mono 211° Template:Mono 251° Template:Mono 291° Template:Mono 331° Template:Mono
12° Template:Mono 52° Template:Mono 92° Template:Mono 132° Template:Mono 172° Template:Mono 212° Template:Mono 252° Template:Mono 292° Template:Mono 332° Template:Mono
13° Template:Mono 53° Template:Mono 93° Template:Mono 133° Template:Mono 173° Template:Mono 213° Template:Mono 253° Template:Mono 293° Template:Mono 333° Template:Mono
14° Template:Mono 54° Template:Mono 94° Template:Mono 134° Template:Mono 174° Template:Mono 214° Template:Mono 254° Template:Mono 294° Template:Mono 334° Template:Mono
15° Template:Mono 55° Template:Mono 95° Template:Mono 135° Template:Mono 175° Template:Mono 215° Template:Mono 255° Template:Mono 295° Template:Mono 335° Template:Mono
16° Template:Mono 56° Template:Mono 96° Template:Mono 136° Template:Mono 176° Template:Mono 216° Template:Mono 256° Template:Mono 296° Template:Mono 336° Template:Mono
17° Template:Mono 57° Template:Mono 97° Template:Mono 137° Template:Mono 177° Template:Mono 217° Template:Mono 257° Template:Mono 297° Template:Mono 337° Template:Mono
18° Template:Mono 58° Template:Mono 98° Template:Mono 138° Template:Mono 178° Template:Mono 218° Template:Mono 258° Template:Mono 298° Template:Mono 338° Template:Mono
19° Template:Mono 59° Template:Mono 99° Template:Mono 139° Template:Mono 179° Template:Mono 219° Template:Mono 259° Template:Mono 299° Template:Mono 339° Template:Mono
20° Template:Mono 60° Template:Mono 100° Template:Mono 140° Template:Mono 180° Template:Mono 220° Template:Mono 260° Template:Mono 300° Template:Mono 340° Template:Mono
21° Template:Mono 61° Template:Mono 101° Template:Mono 141° Template:Mono 181° Template:Mono 221° Template:Mono 261° Template:Mono 301° Template:Mono 341° Template:Mono
22° Template:Mono 62° Template:Mono 102° Template:Mono 142° Template:Mono 182° Template:Mono 222° Template:Mono 262° Template:Mono 302° Template:Mono 342° Template:Mono
23° Template:Mono 63° Template:Mono 103° Template:Mono 143° Template:Mono 183° Template:Mono 223° Template:Mono 263° Template:Mono 303° Template:Mono 343° Template:Mono
24° Template:Mono 64° Template:Mono 104° Template:Mono 144° Template:Mono 184° Template:Mono 224° Template:Mono 264° Template:Mono 304° Template:Mono 344° Template:Mono
25° Template:Mono 65° Template:Mono 105° Template:Mono 145° Template:Mono 185° Template:Mono 225° Template:Mono 265° Template:Mono 305° Template:Mono 345° Template:Mono
26° Template:Mono 66° Template:Mono 106° Template:Mono 146° Template:Mono 186° Template:Mono 226° Template:Mono 266° Template:Mono 306° Template:Mono 346° Template:Mono
27° Template:Mono 67° Template:Mono 107° Template:Mono 147° Template:Mono 187° Template:Mono 227° Template:Mono 267° Template:Mono 307° Template:Mono 347° Template:Mono
28° Template:Mono 68° Template:Mono 108° Template:Mono 148° Template:Mono 188° Template:Mono 228° Template:Mono 268° Template:Mono 308° Template:Mono 348° Template:Mono
29° Template:Mono 69° Template:Mono 109° Template:Mono 149° Template:Mono 189° Template:Mono 229° Template:Mono 269° Template:Mono 309° Template:Mono 349° Template:Mono
30° Template:Mono 70° Template:Mono 110° Template:Mono 150° Template:Mono 190° Template:Mono 230° Template:Mono 270° Template:Mono 310° Template:Mono 350° Template:Mono
31° Template:Mono 71° Template:Mono 111° Template:Mono 151° Template:Mono 191° Template:Mono 231° Template:Mono 271° Template:Mono 311° Template:Mono 351° Template:Mono
32° Template:Mono 72° Template:Mono 112° Template:Mono 152° Template:Mono 192° Template:Mono 232° Template:Mono 272° Template:Mono 312° Template:Mono 352° Template:Mono
33° Template:Mono 73° Template:Mono 113° Template:Mono 153° Template:Mono 193° Template:Mono 233° Template:Mono 273° Template:Mono 313° Template:Mono 353° Template:Mono
34° Template:Mono 74° Template:Mono 114° Template:Mono 154° Template:Mono 194° Template:Mono 234° Template:Mono 274° Template:Mono 314° Template:Mono 354° Template:Mono
35° Template:Mono 75° Template:Mono 115° Template:Mono 155° Template:Mono 195° Template:Mono 235° Template:Mono 275° Template:Mono 315° Template:Mono 355° Template:Mono
36° Template:Mono 76° Template:Mono 116° Template:Mono 156° Template:Mono 196° Template:Mono 236° Template:Mono 276° Template:Mono 316° Template:Mono 356° Template:Mono
37° Template:Mono 77° Template:Mono 117° Template:Mono 157° Template:Mono 197° Template:Mono 237° Template:Mono 277° Template:Mono 317° Template:Mono 357° Template:Mono
38° Template:Mono 78° Template:Mono 118° Template:Mono 158° Template:Mono 198° Template:Mono 238° Template:Mono 278° Template:Mono 318° Template:Mono 358° Template:Mono
39° Template:Mono 79° Template:Mono 119° Template:Mono 159° Template:Mono 199° Template:Mono 239° Template:Mono 279° Template:Mono 319° Template:Mono 359° Template:Mono
Starting and ending angles for the 20 tracks for a single-track Gray code with 9 sensors separated by 40°
Starting angle Ending angle Length
3 4 2
23 28 6
31 37 7
44 48 5
56 60 5
64 71 8
74 76 3
88 91 4
94 96 3
99 104 6
110 115 6
131 134 4
138 154 17
173 181 9
186 187 2
220 238 19
242 246 5
273 279 7
286 289 4
307 360 54

Two-dimensional Gray code

[edit]
File:16QAM Gray Coded.svg
A Gray-coded constellation diagram for rectangular 16-QAM

Two-dimensional Gray codes are used in communication to minimize the number of bit errors in quadrature amplitude modulation (QAM) adjacent points in the constellation. In a typical encoding the horizontal and vertical adjacent constellation points differ by a single bit, and diagonal adjacent points differ by 2 bits.<ref name="Krishna_2008"/>

Two-dimensional Gray codes also have uses in location identifications schemes, where the code would be applied to area maps such as a Mercator projection of the earth's surface and an appropriate cyclic two-dimensional distance function such as the Mannheim metric be used to calculate the distance between two encoded locations, thereby combining the characteristics of the Hamming distance with the cyclic continuation of a Mercator projection.<ref name="Strang-Dammann-Roeckl-Plass_2009"/>

Excess Gray code

[edit]

If a subsection of a specific codevalue is extracted from that value, for example the last 3 bits of a 4-bit Gray code, the resulting code will be an "excess Gray code". This code shows the property of counting backwards in those extracted bits if the original value is further increased. Reason for this is that Gray-encoded values do not show the behaviour of overflow, known from classic binary encoding, when increasing past the "highest" value.

Example: The highest 3-bit Gray code, 7, is encoded as (0)100. Adding 1 results in number 8, encoded in Gray as 1100. The last 3 bits do not overflow and count backwards if you further increase the original 4 bit code.

When working with sensors that output multiple, Gray-encoded values in a serial fashion, one should therefore pay attention whether the sensor produces those multiple values encoded in 1 single Gray code or as separate ones, as otherwise the values might appear to be counting backwards when an "overflow" is expected.

Gray isometry

[edit]

The bijective mapping { 0 ↔ Template:Mono, 1 ↔ Template:Mono, 2 ↔ Template:Mono, 3 ↔ Template:Mono } establishes an isometry between the metric space over the finite field <math>\mathbb{Z}_2^2</math> with the metric given by the Hamming distance and the metric space over the finite ring <math>\mathbb{Z}_4</math> (the usual modular arithmetic) with the metric given by the Lee distance. The mapping is suitably extended to an isometry of the Hamming spaces <math>\mathbb{Z}_2^{2m}</math> and <math>\mathbb{Z}_4^m</math>. Its importance lies in establishing a correspondence between various "good" but not necessarily linear codes as Gray-map images in <math>\mathbb{Z}_2^2</math> of ring-linear codes from <math>\mathbb{Z}_4</math>.<ref name="Greferath_2009"/><ref name="Hazewinkel-Sole_2016"/>

[edit]

Template:Excessive citations

There are a number of binary codes similar to Gray codes, including:

  • Template:AnchorDatex codes or Giannini codes (1954), as described by Carl P. Spaulding,<ref name="Spaulding_1954"/><ref name="Spaulding_1965"/><ref name="Wheeler_1969"/><ref name="Dokter-Steinhauer_1973"/><ref name="Dokter-Steinhauer_1975"/><ref name="MIL_1991"/> use a variant of O'Brien code II.
  • Template:Anchor Codes used by Varec (c. 1954),<ref name="Varec_1954"/><ref name="Bishup-Repeta-Giarrizzo_1963"/><ref name="Whessoe_1993"/><ref name="Emerson"/> use a variant of O'Brien code I as well as base-12 and base-16 Gray code variants.
  • Template:AnchorLucal code (1959)<ref name="Lucal_1959"/><ref name="Sellers-Hsiao-Bearnson_1968"/><ref name="Doran_2007"/> aka modified reflected binary code (MRB)<ref name="Lucal_1959"/><ref name="Sellers-Hsiao-Bearnson_1968"/><ref group="nb" name="NB_Modified"/>
  • Template:AnchorGillham code (1961/1962),<ref name="Wheeler_1969"/><ref name="Wightman_1972"/><ref name="MIL_1991"/><ref name="Phillips_1998"/><ref name="Stewart_2010"/> uses a variant of Datex code and O'Brien code II.
  • Template:AnchorLeslie and Russell code (1964)<ref name="Leslie-Russell_1964"/><ref name="Russell_1964"/><ref name="Leslie_1974"/><ref name="Wightman_1972"/>
  • Template:AnchorRoyal Radar Establishment code<ref name="Wightman_1972"/>
  • Template:AnchorHoklas code (1988)<ref name="Hoklas_1989"/><ref name="Hoklas_2005_1"/><ref name="Hoklas_2005_2"/>

The following binary-coded decimal (BCD) codes are Gray code variants as well:

  • Template:AnchorPetherick code (1953),<ref name="Petherick_1953"/><ref name="Petherick-Hopkins_1958"/><ref name="Baumgartner_1963"/><ref name="Charnley-Bidgood-Boardman_1965"/><ref name="Powell_1968"/><ref name="Hoklas_2005_1"/><ref group="nb" name="NB_Petherick_OBrien-II"/> also known as Royal Aircraft Establishment (RAE) code.<ref name="Hollingdale_1958"/>
  • Template:AnchorO'Brien codes I and II (1955)<ref name="O'Brien_1955"/><ref name="Steinbuch_1962"/><ref name="Steinbuch-Weber-Heinemann_1974"/><ref name="Dokter-Steinhauer_1973"/><ref name="Dokter-Steinhauer_1975"/><ref name="Hoklas_2005_1"/> (An O'Brien type-I code<ref group="nb" name="NB_OBrien-I_Glixon"/> was already described by Frederic A. Foss of IBM<ref name="Foss_1954_1"/><ref name="Foss_1954_2"/> and used by Varec in 1954. Later, it was also known as Watts code or Watts reflected decimal (WRD) code and is sometimes ambiguously referred to as reflected binary modified Gray code.<ref name="Evans_1958"/><ref name="Evans_1960"/><ref name="Evans_1961"/><ref name="Benjamin-Nicholls_1963"/><ref name="Klinkowski_1964"/><ref name="Klinkowski_1966"/><ref name="EDN_1967"/><ref name="Toth-Zentai_1979"/><ref name="Savard_2018"/><ref group="nb" name="NB_Arithmetic_conversion"/><ref group="nb" name="NB_Modified"/> An O'Brien type-II code was already used by Datex in 1954.<ref group="nb" name="NB_Petherick_OBrien-II"/>)
  • Template:AnchorExcess-3 Gray code (1956)<ref name="Turvey_1956"/> (aka Gray excess-3 code,<ref name="Dokter-Steinhauer_1973"/><ref name="Dokter-Steinhauer_1975"/><ref name="MIL_1991"/> Gray 3-excess code, reflex excess-3 code, excess Gray code,<ref name="Hoklas_2005_1"/> Gray excess code, 10-excess-3 Gray code or Gray–Stibitz code), described by Frank P. Turvey Jr. of ITT.<ref name="Turvey_1956"/>
  • Template:AnchorTompkins codes I and II (1956)<ref name="Tompkins_1956"/><ref name="Steinbuch_1962"/><ref name="Steinbuch-Weber-Heinemann_1974"/><ref name="Dokter-Steinhauer_1973"/><ref name="Dokter-Steinhauer_1975"/><ref name="Hoklas_2005_1"/>
  • Template:AnchorGlixon code (1957), sometimes ambiguously also called modified Gray code<ref name="Glixon_1957"/><ref name="Powell_1968"/><ref name="Borucki-Dittmann_1971"/><ref name="Kämmerer_1969"/><ref name="Steinbuch_1962"/><ref name="Steinbuch-Weber-Heinemann_1974"/><ref name="Dokter-Steinhauer_1973"/><ref name="Dokter-Steinhauer_1975"/><ref name="Hoklas_2005_1"/><ref group="nb" name="NB_Modified"/><ref group="nb" name="NB_OBrien-I_Glixon"/>
4-bit unit-distance BCD codes<ref group="nb" name="NB_Other_codes"/>
Name Bit 0 1 2 3 4 5 6 7 8 9 Weights<ref group="nb" name="NB_Weights"/> Tracks Compl. Cyclic 5s Comment
Template:AnchorGray BCD 4 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono 0–3 4 (3<ref group="nb" name="NB_Tracks_Inverse"/>) No (2, 4, 8, 16) No <ref name="Steinbuch_1962"/><ref name="Steinbuch-Weber-Heinemann_1974"/>
3 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
2 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
1 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
Template:AnchorPaul 4 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono 1–3 4 (3<ref group="nb" name="NB_Tracks_Inverse"/>) No 2, 10 No <ref name="Paul_1995"/>
3 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
2 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
1 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
Glixon 4 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono 0–3 4 No 2, 4, 8, 10 (shifted +1) <ref name="Glixon_1957"/><ref name="Steinbuch_1962"/><ref name="Steinbuch-Weber-Heinemann_1974"/><ref name="Borucki-Dittmann_1971"/><ref name="Kämmerer_1969"/><ref group="nb" name="NB_OBrien-I_Glixon"/>
3 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
2 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
1 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
Tompkins I 4 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono 0–4 2 No 2, 4, 10 Yes <ref name="Tompkins_1956"/><ref name="Steinbuch_1962"/><ref name="Steinbuch-Weber-Heinemann_1974"/>
3 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
2 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
1 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
O'Brien I (Watts) 4 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono 0–3 4 9<ref name="Hoklas_2005_1"/><ref name="Hoklas_2005_2"/><ref group="nb" name="NB_Complement_InvertTop"/> 2, 4, 10 Yes <ref name="O'Brien_1955"/><ref name="Steinbuch_1962"/><ref name="Steinbuch-Weber-Heinemann_1974"/><ref group="nb" name="NB_OBrien-I_Glixon"/>
3 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
2 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
1 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
Petherick (RAE) 4 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono 1–3 3 9<ref name="Hoklas_2005_1"/><ref name="Hoklas_2005_2"/><ref group="nb" name="NB_Complement_InvertTop"/> 2, 10 Yes <ref name="Petherick_1953"/><ref name="Charnley-Bidgood-Boardman_1965"/><ref group="nb" name="NB_Petherick_OBrien-II"/>
3 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
2 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
1 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
O'Brien II 4 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono 1–3 3 9<ref name="Dokter-Steinhauer_1973"/><ref name="Hoklas_2005_1"/><ref name="Hoklas_2005_2"/><ref group="nb" name="NB_Complement_InvertTop"/> 2, 10 Yes <ref name="O'Brien_1955"/><ref name="Steinbuch_1962"/><ref name="Steinbuch-Weber-Heinemann_1974"/><ref group="nb" name="NB_Petherick_OBrien-II"/>
3 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
2 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
1 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
Template:AnchorSusskind 4 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono 1–4 3 9<ref group="nb" name="NB_Complement_InvertTop"/> 2, 10 Yes <ref name="Susskind_1958"/>
3 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
2 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
1 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
Template:AnchorKlar 4 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono 0–4 4 (3<ref group="nb" name="NB_Tracks_Inverse"/>) 9<ref group="nb" name="NB_Complement_InvertTop"/> 2, 10 Yes <ref name="Klar_1970"/><ref name="Klar_1989"/>
3 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
2 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
1 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
Tompkins II 4 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono 1–3 2 9<ref group="nb" name="NB_Complement_Tompkins"/> 2, 10 Yes <ref name="Tompkins_1956"/><ref name="Steinbuch_1962"/><ref name="Steinbuch-Weber-Heinemann_1974"/>
3 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
2 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
1 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
Template:Nowrap 4 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono 1–4 4 9<ref name="Hoklas_2005_1"/><ref name="Hoklas_2005_2"/><ref group="nb" name="NB_Complement_InvertTop"/> 2, 10 Yes <ref name="MIL_1991"/><ref name="Hoklas_2005_1"/>
3 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
2 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono
1 Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono Template:Mono

See also

[edit]

Notes

[edit]

Template:Reflist

References

[edit]

Template:Reflist

Further reading

[edit]

Template:Refbegin

Template:Refend

[edit]

Template:Refbegin

Template:Refend