Evert Willem Beth: Difference between revisions

From formulasearchengine
Jump to navigation Jump to search
en>Kestrel man hoovers in the dark
No edit summary
 
en>Stpasta
No edit summary
Line 1: Line 1:
It is very common to have a dental emergency -- a fractured tooth, an abscess, or severe pain when chewing. Over-the-counter pain medication is just masking the problem. Seeing an emergency dentist is critical to getting the source of the problem diagnosed and corrected as soon as possible.<br><br><br><br>Here are some common dental emergencies:<br>Toothache: The most common dental emergency. This generally means a badly decayed tooth. As the pain affects the tooth's nerve, treatment involves gently removing any debris lodged in the cavity being careful not to poke deep as this will cause severe pain if the nerve is touched. Next rinse vigorously with warm water. Then soak a small piece of cotton in oil of cloves and insert it in the cavity. This will give temporary relief until a dentist can be reached.<br><br>At times the pain may have a more obscure location such as decay under an old filling. As this can be only corrected by a dentist there are two things you can do to help the pain. Administer a pain pill (aspirin or some other analgesic) internally or dissolve a tablet in a half glass (4 oz) of warm water holding it in the mouth for several minutes before spitting it out. DO NOT PLACE A WHOLE TABLET OR ANY PART OF IT IN THE TOOTH OR AGAINST THE SOFT GUM TISSUE AS IT WILL RESULT IN A NASTY BURN.<br><br>Swollen Jaw: This may be caused by several conditions the most probable being an abscessed tooth. In any case the treatment should be to reduce pain and swelling. An ice pack held on the outside of the jaw, (ten minutes on and ten minutes off) will take care of both. If this does not control the pain, an analgesic tablet can be given every four hours.<br><br>Other Oral Injuries: Broken teeth, cut lips, bitten tongue or lips if severe means a trip to a dentist as soon as possible. In the mean time rinse the mouth with warm water and place cold compression the face opposite the injury. If there is a lot of bleeding, apply direct pressure to the bleeding area. If bleeding does not stop get patient to the emergency room of a hospital as stitches may be necessary.<br><br>Prolonged Bleeding Following Extraction: Place a gauze pad or better still a moistened tea bag over the socket and have the patient bite down gently on it for 30 to 45 minutes. The tannic acid in the tea seeps into the tissues and often helps stop the bleeding. If bleeding continues after two hours, call the dentist or take patient to the emergency room of the nearest hospital.<br><br>Broken Jaw: If you suspect the patient's jaw is broken, bring the upper and lower teeth together. Put a necktie, handkerchief or towel under the chin, tying it over the head to immobilize the jaw until you can get the patient to a dentist or the emergency room of a hospital.<br><br>Painful Erupting Tooth: In young children teething pain can come from a loose baby tooth or from an erupting permanent tooth. Some relief can be given by crushing a little ice and wrapping it in gauze or a clean piece of cloth and putting it directly on the tooth or gum tissue where it hurts. The numbing effect of the cold, along with an appropriate dose of aspirin, usually provides temporary relief.<br><br>In young adults, an erupting 3rd molar (Wisdom tooth), especially if it is impacted, can cause the jaw to swell and be quite painful. Often the gum around the tooth will show signs of infection. Temporary relief can be had by giving aspirin or some other painkiller and by dissolving an aspirin in half a glass of warm water and holding this solution in the mouth over the sore gum. AGAIN DO NOT PLACE A TABLET DIRECTLY OVER THE GUM OR CHEEK OR USE THE ASPIRIN SOLUTION ANY STRONGER THAN RECOMMENDED TO PREVENT BURNING THE TISSUE. The swelling of the jaw can be reduced by using an ice pack on the outside of the face at intervals of ten minutes on and ten minutes off.<br><br>If you loved this article and you would like to receive more facts about [http://www.youtube.com/watch?v=90z1mmiwNS8 dentist DC] kindly pay a visit to our own web site.
In [[computer science]], '''Luby transform codes (LT codes)''' are the first class of practical [[fountain code]]s that are near-optimal [[erasure correcting code]]s. They were invented by [[Michael Luby]] in 1998 and published in 2002.<ref name="Luby">[http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1181950 M.Luby, "LT Codes", The 43rd Annual IEEE Symposium on Foundations of Computer Science, 2002.]</ref> Like some other [[fountain code]]s, LT codes depend on sparse [[bipartite graph]]s to trade reception overhead for encoding and decoding speed. The distinguishing characteristic of LT codes is in employing a particularly simple algorithm based on the [[exclusive or]] operation (<math>\oplus</math>) to encode and decode the message.<ref>The ''exclusive or'' (XOR) operation, symbolized by &oplus;, has the very useful property that ''A''&nbsp;&oplus;&nbsp;''A''&nbsp;=&nbsp;0, where ''A'' is an arbitrary string of [[bit]]s.</ref>
 
LT codes are ''rateless'' because the encoding algorithm can in principle produce an infinite number of message packets (i.e., the percentage of packets that must be received to decode the message can be arbitrarily small). They are ''erasure correcting codes'' because they can be used to transmit digital data reliably on an [[binary erasure channel|erasure channel]].
 
The next generation beyond LT codes are [[raptor codes]] (see for example IETF RFC 5053 or IETF RFC 6330), which have linear time encoding and decoding.  Raptor codes use two encoding stages for encoding, where the second stage is an LT encoding.
 
==Why use an LT code?==
 
The traditional scheme for transferring data across an erasure channel depends on continuous two-way communication.
*The sender encodes and sends a packet of information.
*The receiver attempts to decode the received packet. If it can be decoded, the receiver sends an acknowledgment back to the transmitter. Otherwise, the receiver asks the transmitter to send the packet again.
*This two-way process continues until all the packets in the message have been transferred successfully.
 
Certain networks, such as ones used for cellular wireless broadcasting, do not have a feedback channel. Applications on these networks still require reliability. [[Fountain code]]s in general, and LT codes in particular, get around this problem by adopting an essentially one-way communication protocol.
*The sender encodes and sends packet after packet of information.
*The receiver evaluates each packet as it is received. If there is an error, the erroneous packet is discarded. Otherwise the packet is saved as a piece of the message.
*Eventually the receiver has enough valid packets to reconstruct the entire message. When the entire message has been received successfully the receiver signals that transmission is complete.
 
==LT encoding==
 
The encoding process begins by dividing the uncoded message into ''n'' blocks of roughly equal length. Encoded packets are then produced with the help of a [[pseudorandom number generator]].
*The degree ''d'', 1&nbsp;≤&nbsp;''d''&nbsp;≤&nbsp;''n'', of the next packet is chosen at random.
*Exactly ''d'' blocks from the message are randomly chosen.
*If ''M''<sub>''i''</sub> is the ''i''th block of the message, the data portion of the next packet is computed as
 
::<math>
M_{i_1} \oplus M_{i_2} \oplus \cdots \oplus M_{i_d}\,
</math>
 
:where {''i''<sub>1</sub>,&nbsp;''i''<sub>2</sub>,&nbsp;&hellip;,&nbsp;''i''<sub>''d''</sub>} are the randomly chosen indices for the ''d'' blocks included in this packet.
*A prefix is appended to the encoded packet, defining how many blocks ''n'' are in the message, how many blocks ''d'' have been exclusive-ored into the data portion of this packet, and the list of indices {''i''<sub>1</sub>,&nbsp;''i''<sub>2</sub>,&nbsp;…,&nbsp;''i''<sub>''d''</sub>}.
*Finally, some form of error-detecting code (perhaps as simple as a [[cyclic redundancy check]]) is applied to the packet, and the packet is transmitted.
 
This process continues until the receiver signals that the message has been received and successfully decoded.
 
==LT decoding==
 
The decoding process uses the "[[exclusive or]]" operation to retrieve the encoded message.
*If the current packet isn't clean, or if it replicates a packet that has already been processed, the current packet is discarded.
*If the current cleanly received packet is of degree ''d''&nbsp;>&nbsp;1, it is first processed against all the fully decoded blocks in the message queuing area (as described more fully in the next step), then stored in a buffer area if its reduced degree is greater than 1.
*When a new, clean packet of degree ''d''&nbsp;=&nbsp;1 (block ''M''<sub>''i''</sub>) is received (or the degree of the current packet is reduced to 1 by the preceding step), it is moved to the message queueing area, and then matched against all the packets of degree ''d''&nbsp;>&nbsp;1 residing in the buffer. It is exclusive-ored into the data portion of any buffered packet that was encoded using ''M''<sub>''i''</sub>, the degree of that matching packet is decremented, and the list of indices for that packet is adjusted to reflect the application of ''M''<sub>''i''</sub>.
*When this process unlocks a block of degree ''d''&nbsp;=&nbsp;2 in the buffer, that block is reduced to degree 1 and is in its turn moved to the message queueing area, and then processed against the packets remaining in the buffer.
*When all ''n'' blocks of the message have been moved to the message queueing area, the receiver signals the transmitter that the message has been successfully decoded.
 
This decoding procedure works because ''A''&nbsp;<math>\oplus</math>&nbsp;''A''&nbsp;=&nbsp;0 for any bit string ''A''. After ''d''&nbsp;&minus;&nbsp;1 distinct blocks have been exclusive-ored into a packet of degree ''d'', the original unencoded content of the unmatched block is all that remains. In symbols we have
 
:<math>
\begin{align}
& {} \qquad (M_{i_1} \oplus \dots \oplus M_{i_d}) \oplus
(M_{i_1} \oplus \dots \oplus M_{i_{k-1}} \oplus M_{i_{k+1}} \oplus \dots \oplus M_{i_d}) \\
& = M_{i_1} \oplus M_{i_1} \oplus \dots \oplus M_{i_{k-1}} \oplus M_{i_{k-1}} \oplus M_{i_k} \oplus
M_{i_{k+1}} \oplus M_{i_{k+1}} \oplus \dots \oplus M_{i_d} \oplus M_{i_d} \\
& = 0 \oplus \dots \oplus 0 \oplus M_{i_k} \oplus 0 \oplus \dots \oplus 0 \\
& =  M_{i_k} \,
\end{align}
</math>
 
==Variations==
 
Several variations of the encoding and decoding processes described above are possible. For instance, instead of prefixing each packet with a list of the actual message block indices {''i''<sub>1</sub>,&nbsp;''i''<sub>2</sub>,&nbsp;…,&nbsp;''i''<sub>''d''</sub>}, the encoder might simply send a short "key" which served as the seed for the [[pseudorandom number generator]] (PRNG) or index table used to construct the list of indices. Since the receiver equipped with the same RNG or index table can reliably recreate the "random" list of indices from this seed, the decoding process can be completed successfully. Alternatively, by combining a simple LT code of low average degree with a robust error-correcting code, a [[raptor code]] can be constructed that will outperform an optimized LT code in practice.<ref name="MacKay">[http://switzernet.com/people/emin-gabrielyan/060112-capillary-references/ref/MacKay05.pdf Fountain codes], by D.J.C. MacKay, first published in IEEE Proc.-Commun., Vol. 152, No. 6, December 2005.</ref>
 
==Optimization of LT codes==
 
There is only one parameter that can be used to optimize a straight LT code: the degree distribution function (described as a pseudorandom number generator for the degree ''d'' in the '''LT encoding''' section above). In practice the other "random" numbers (the list of indices {&nbsp;''i''<sub>1</sub>,&nbsp;''i''<sub>2</sub>,&nbsp;…,&nbsp;''i''<sub>''d''</sub>&nbsp;}&nbsp;) are invariably taken from a uniform distribution on [0, ''n''), where ''n'' is the number of blocks into which the message has been divided.<ref name="Tirronen">[http://www.netlab.tkk.fi/tutkimus/abi/publ/lt-resim-2006.pdf Optimizing the Degree Distribution of LT Codes with an Importance Sampling Approach], by Esa Hyytiä, Tuomas Tirronen, and Jorma Virtamo (2006).</ref>
 
Luby himself<ref name="Luby"/> discussed the "ideal [[soliton distribution]]" defined by
 
:<math>
\begin{align}
\mathrm{P}\{d=1\}& = \frac{1}{n}\\[2pt]
\mathrm{P}\{d=k\}& = \frac{1}{k(k-1)} \qquad (k=2,3,\dots,n). \,
\end{align}
</math>
 
This degree distribution theoretically minimizes the expected number of redundant code words that will be sent before the decoding process can be completed. However the ideal soliton distribution does not work well in practice because any fluctuation around the expected behavior makes it likely that at some step in the decoding process there will be no available packet of (reduced) degree 1 so decoding will fail. Furthermore, some of the original blocks will not be xor-ed into any of the transmission packets. Therefore, in practice, a modified distribution, the "robust [[soliton distribution]]", is substituted for the ideal distribution. The effect of the modification is, generally, to produce more packets of very small degree (around 1) and fewer packets of degree greater than 1, except for a spike of packets at a fairly large quantity chosen to ensure that all original blocks will be included in some packet.<ref name="Tirronen"/>
 
==See also==
*[[Online codes]]
*[[Raptor codes]]
*[[Tornado codes]]
 
==Notes and references==
<references/>
 
==External links==
* [http://www.codeproject.com/Articles/425456/Your-Digital-Fountain "Implementation of Luby transform Code in C#"]
 
 
[[Category:Coding theory]]

Revision as of 16:10, 16 September 2013

In computer science, Luby transform codes (LT codes) are the first class of practical fountain codes that are near-optimal erasure correcting codes. They were invented by Michael Luby in 1998 and published in 2002.[1] Like some other fountain codes, LT codes depend on sparse bipartite graphs to trade reception overhead for encoding and decoding speed. The distinguishing characteristic of LT codes is in employing a particularly simple algorithm based on the exclusive or operation () to encode and decode the message.[2]

LT codes are rateless because the encoding algorithm can in principle produce an infinite number of message packets (i.e., the percentage of packets that must be received to decode the message can be arbitrarily small). They are erasure correcting codes because they can be used to transmit digital data reliably on an erasure channel.

The next generation beyond LT codes are raptor codes (see for example IETF RFC 5053 or IETF RFC 6330), which have linear time encoding and decoding. Raptor codes use two encoding stages for encoding, where the second stage is an LT encoding.

Why use an LT code?

The traditional scheme for transferring data across an erasure channel depends on continuous two-way communication.

  • The sender encodes and sends a packet of information.
  • The receiver attempts to decode the received packet. If it can be decoded, the receiver sends an acknowledgment back to the transmitter. Otherwise, the receiver asks the transmitter to send the packet again.
  • This two-way process continues until all the packets in the message have been transferred successfully.

Certain networks, such as ones used for cellular wireless broadcasting, do not have a feedback channel. Applications on these networks still require reliability. Fountain codes in general, and LT codes in particular, get around this problem by adopting an essentially one-way communication protocol.

  • The sender encodes and sends packet after packet of information.
  • The receiver evaluates each packet as it is received. If there is an error, the erroneous packet is discarded. Otherwise the packet is saved as a piece of the message.
  • Eventually the receiver has enough valid packets to reconstruct the entire message. When the entire message has been received successfully the receiver signals that transmission is complete.

LT encoding

The encoding process begins by dividing the uncoded message into n blocks of roughly equal length. Encoded packets are then produced with the help of a pseudorandom number generator.

  • The degree d, 1 ≤ d ≤ n, of the next packet is chosen at random.
  • Exactly d blocks from the message are randomly chosen.
  • If Mi is the ith block of the message, the data portion of the next packet is computed as
Mi1Mi2Mid
where {i1i2, …, id} are the randomly chosen indices for the d blocks included in this packet.
  • A prefix is appended to the encoded packet, defining how many blocks n are in the message, how many blocks d have been exclusive-ored into the data portion of this packet, and the list of indices {i1i2, …, id}.
  • Finally, some form of error-detecting code (perhaps as simple as a cyclic redundancy check) is applied to the packet, and the packet is transmitted.

This process continues until the receiver signals that the message has been received and successfully decoded.

LT decoding

The decoding process uses the "exclusive or" operation to retrieve the encoded message.

  • If the current packet isn't clean, or if it replicates a packet that has already been processed, the current packet is discarded.
  • If the current cleanly received packet is of degree d > 1, it is first processed against all the fully decoded blocks in the message queuing area (as described more fully in the next step), then stored in a buffer area if its reduced degree is greater than 1.
  • When a new, clean packet of degree d = 1 (block Mi) is received (or the degree of the current packet is reduced to 1 by the preceding step), it is moved to the message queueing area, and then matched against all the packets of degree d > 1 residing in the buffer. It is exclusive-ored into the data portion of any buffered packet that was encoded using Mi, the degree of that matching packet is decremented, and the list of indices for that packet is adjusted to reflect the application of Mi.
  • When this process unlocks a block of degree d = 2 in the buffer, that block is reduced to degree 1 and is in its turn moved to the message queueing area, and then processed against the packets remaining in the buffer.
  • When all n blocks of the message have been moved to the message queueing area, the receiver signals the transmitter that the message has been successfully decoded.

This decoding procedure works because A  A = 0 for any bit string A. After d − 1 distinct blocks have been exclusive-ored into a packet of degree d, the original unencoded content of the unmatched block is all that remains. In symbols we have

(Mi1Mid)(Mi1Mik1Mik+1Mid)=Mi1Mi1Mik1Mik1MikMik+1Mik+1MidMid=00Mik00=Mik

Variations

Several variations of the encoding and decoding processes described above are possible. For instance, instead of prefixing each packet with a list of the actual message block indices {i1i2, …, id}, the encoder might simply send a short "key" which served as the seed for the pseudorandom number generator (PRNG) or index table used to construct the list of indices. Since the receiver equipped with the same RNG or index table can reliably recreate the "random" list of indices from this seed, the decoding process can be completed successfully. Alternatively, by combining a simple LT code of low average degree with a robust error-correcting code, a raptor code can be constructed that will outperform an optimized LT code in practice.[3]

Optimization of LT codes

There is only one parameter that can be used to optimize a straight LT code: the degree distribution function (described as a pseudorandom number generator for the degree d in the LT encoding section above). In practice the other "random" numbers (the list of indices { i1i2, …, id } ) are invariably taken from a uniform distribution on [0, n), where n is the number of blocks into which the message has been divided.[4]

Luby himself[1] discussed the "ideal soliton distribution" defined by

P{d=1}=1nP{d=k}=1k(k1)(k=2,3,,n).

This degree distribution theoretically minimizes the expected number of redundant code words that will be sent before the decoding process can be completed. However the ideal soliton distribution does not work well in practice because any fluctuation around the expected behavior makes it likely that at some step in the decoding process there will be no available packet of (reduced) degree 1 so decoding will fail. Furthermore, some of the original blocks will not be xor-ed into any of the transmission packets. Therefore, in practice, a modified distribution, the "robust soliton distribution", is substituted for the ideal distribution. The effect of the modification is, generally, to produce more packets of very small degree (around 1) and fewer packets of degree greater than 1, except for a spike of packets at a fairly large quantity chosen to ensure that all original blocks will be included in some packet.[4]

See also

Notes and references

  1. 1.0 1.1 M.Luby, "LT Codes", The 43rd Annual IEEE Symposium on Foundations of Computer Science, 2002.
  2. The exclusive or (XOR) operation, symbolized by ⊕, has the very useful property that A ⊕ A = 0, where A is an arbitrary string of bits.
  3. Fountain codes, by D.J.C. MacKay, first published in IEEE Proc.-Commun., Vol. 152, No. 6, December 2005.
  4. 4.0 4.1 Optimizing the Degree Distribution of LT Codes with an Importance Sampling Approach, by Esa Hyytiä, Tuomas Tirronen, and Jorma Virtamo (2006).

External links