11 Coding theory—II

จากบทก่อนควรชัดเจนสองเรื่อง ก่อนอื่น เราต้องการให้ความยาวเฉลี่ย L ของข้อความที่ส่งมีค่าน้อยที่สุดเท่าที่ทำได้ (เพื่อประหยัดการใช้ทรัพยากร) ประการที่สอง ทฤษฎีนี้ต้องเป็นทฤษฎีเชิงสถิติ เพราะเราไม่สามารถรู้ล่วงหน้าว่าจะส่งข้อความใดได้ แต่เราสามารถรู้สถิติบางอย่างได้จากข้อความที่ผ่านมา โดยสมมติว่าอนาคตน่าจะเหมือนอดีต สำหรับทฤษฎีที่ง่ายที่สุด ซึ่งเป็นสิ่งที่เราจะพูดถึงที่นี่ เราต้องการความน่าจะเป็นของการเกิดแต่ละสัญลักษณ์ในข้อความ วิธีการหาค่าเหล่านี้ไม่อยู่ในขอบเขตของทฤษฎีโดยตรง แต่สามารถได้มาจากการตรวจสอบประสบการณ์ที่ผ่านมา หรือตั้งสมมติฐานเกี่ยวกับการใช้งานในอนาคตของระบบที่คุณออกแบบ

ดังนั้นเราต้องการโค้ดที่ถอดรหัสได้ทันทีและมีการถอดรหัสแบบเอกลักษณ์สำหรับชุดสัญลักษณ์นำเข้า s_i พร้อมด้วยความน่าจะเป็นของแต่ละตัว p_i เราควรกำหนดความยาว l_i อย่างไร (โดยต้องเป็นไปตาม Kraft inequality) เพื่อให้ได้ความยาวเฉลี่ยของโค้ดต่ำที่สุด? Huffman แก้ปัญหาการออกแบบโค้ดนี้ได้

Huffman แสดงก่อนว่าอสมการต่อไปนี้ต้องเป็นจริงสำหรับโค้ดที่มีความยาวน้อยที่สุด: หาก p_i เรียงจากมากไปน้อยแล้ว l_i จะต้องเรียงจากน้อยไปมาก

สรุป: For suppose the p_i are in this order but at least one pair of the _l_i are not. Consider the effect of interchanging the symbols attached to the two which are not in order. Before the interchange the two terms contributed to the average code length _L an amount

สรุป: and after the interchange the terms would contribute

เทอมอื่นๆ ในผลรวม L จะเหมือนเดิม ความต่างสามารถเขียนได้เป็น

สรุป: One of these two factors was assumed to be negative, hence upon interchanging the two symbols we would observe a decrease in the average code length L. Thus for a minimum length code we must have the two running inequalities.

ต่อมา Huffman สังเกตว่าโค้ดที่ถอดรหัสได้ทันทีมีโครงสร้างเป็นต้นไม้ตัดสินใจ (decision tree) และทุกโหนดการตัดสินใจควรมีสองทางออก มิฉะนั้นจะเป็นการใช้แรงงานอย่างเปล่าประโยชน์ ดังนั้นจะต้องมีสองสัญลักษณ์ที่ยาวที่สุดซึ่งมีความยาวเท่ากัน

สรุป: To illustrate Huffman coding we use the classic example. Let p(s_1) = 0.4, _p(s_2) = 0.2, _p(s_3) = 0.2, _p(s_4) = 0.1, and _p(_s_5) = 0.1. We have it displayed in Figure 11.1. Huffman then argued on the basis of the above he could combine (merge) the two least frequent symbols (which must have the same length) into one symbol having the combined probability with common bits up to the last bit which is dropped, thus having one fewer code symbol. Repeating this again and again he would come down to a system with only two symbols, for which he knew how to assign a code representation, namely one symbol 0 and one symbol 1.

Figure 11.1—Huffman encoding (การเข้ารหัสแบบ Huffman)

สรุป: Figure 11.2—Decoding tree

เมื่อย้อนกระบวนการกลับไปเพื่อยกเลิกขั้นตอนการรวม ในแต่ละขั้นตอนเราต้องแยกสัญลักษณ์ที่เกิดจากการรวมของสองสัญลักษณ์ออก โดยเก็บบิตนำเดิมไว้ แล้วเพิ่ม 0 ให้กับสัญลักษณ์หนึ่งและเพิ่ม 1 ให้กับอีกสัญลักษณ์ ด้วยวิธีนี้เขาจะได้โค้ดที่มีค่า L ต่ำสุด หากมีโค้ดอื่นที่มีความยาว L' น้อยกว่า การทำขั้นตอนเดินหน้า ซึ่งเปลี่ยนความยาวเฉลี่ยของโค้ดด้วยปริมาณคงที่ จะนำไปสู่สองสัญลักษณ์ที่มีความยาวเฉลี่ยน้อยกว่า 1 — ซึ่งเป็นไปไม่ได้ ดังนั้นการเข้ารหัสแบบ Huffman ให้โค้ดที่มีความยาวต่ำสุด ดู Figure 11.2 สำหรับต้นไม้การถอดรหัสที่สอดคล้อง

โค้ดไม่เป็นเอกลักษณ์ ในขั้นแรก ในแต่ละขั้นตอนของกระบวนการย้อนกลับเป็นการกำหนดอย่างอิสระว่าจะให้สัญลักษณ์ใดเป็น 0 และสัญลักษณ์ใดเป็น 1 อีกทั้งถ้าในขั้นตอนใดมีสองสัญลักษณ์ที่มีความน่าจะเป็นเท่ากัน ก็ไม่สำคัญว่าจะวางอันไหนเหนืออีกอันหนึ่ง ซึ่งบางครั้งจะทำให้ได้โค้ดที่ดูต่างกันมากแต่มีความยาวเฉลี่ยเท่ากัน

ถ้าเราจัดวางเทอมรวมให้สูงที่สุดเท่าที่จะทำได้ เราจะได้ Figure 11.3 พร้อมต้นไม้การถอดรหัสที่สอดคล้อง Figure 11.4 ความยาวเฉลี่ยของทั้งสองโค้ดเท่ากัน แต่โค้ดและต้นไม้การถอดรหัสจะแตกต่างกัน แบบแรกเป็นรูปแบบ “ยาว” ส่วนแบบที่สองเป็นรูปแบบ “พุ่ม” (bushy) ซึ่งแบบที่สองจะมีความแปรปรวนน้อยกว่าแบบแรก

สรุป: Figure 11.3—Huffman encoding

Figure 11.4—Decoding tree (ต้นไม้การถอดรหัส)

สรุป: We now do a second example so you will be sure how Huffman encoding works, since it is natural to want to use the shortest average code length you can when designing an encoding system. For example, you may have a lot of data to put into a backup store, and encoding it into the appropriate Huffman code has been known at times to save more than half the expected storage space! Let p(s_1) = 1/3, _p(s_2) = 1/5, _p(s_3) = 1/6, _p(s_4) = 1/10, _p(s_5) = 1/12, _p(s_6) = 1/20, _p(s_7) = 1/30, and _p(_s_8) = 1/30. First we check that the total probability is 1. The common denominator of the fractions is 60. Hence we have the total probability

ตัวอย่างที่สองนี้แสดงใน Figure 11.5 โดยเราได้ละตัวเศษ 60 ในตัวส่วนของความน่าจะเป็นเพราะขนาดสัมพัทธ์เท่านั้นที่สำคัญ แล้วความยาวเฉลี่ยต่อสัญลักษณ์เป็นเท่าไร? เราคำนวณได้ว่า

สำหรับบล็อกโค้ดที่มีแปดสัญลักษณ์ แต่ละสัญลักษณ์จะมีความยาว 3 และความยาวเฉลี่ยจะเป็น 3 ซึ่งมากกว่า 2.58

Figure 11.5—Huffman encoding (การเข้ารหัสแบบ Huffman)

สังเกตว่ากระบวนการนี้เป็นเรื่องเชิงกลสำหรับเครื่องคอมพิวเตอร์ ทุกขั้นตอนเดินหน้า (forward stage) ของโค้ด Huffman เป็นการทำซ้ำของกระบวนการเดียวกัน: รวมสองความน่าจะเป็นต่ำสุด ใส่ผลรวมใหม่ลงในตำแหน่งที่ถูกต้องในอาร์เรย์ แล้วทำเครื่องหมาย ในกระบวนการย้อนกลับ ให้เอาสัญลักษณ์ที่ถูกทำเครื่องหมายมาแยกออก เหล่านี้เป็นโปรแกรมง่าย ๆ ที่เขียนให้คอมพิวเตอร์ทำได้ ดังนั้นโปรแกรมคอมพิวเตอร์สามารถหารหัส Huffman เมื่อได้รับ s_i และความน่าจะเป็น p_i ในทางปฏิบัติคุณควรกำหนดสัญลักษณ์ escape ที่มีความน่าจะเป็นน้อยมากเพื่อให้สามารถออกจากกระบวนการถอดรหัสได้เมื่อจบข้อความ จริง ๆ แล้วคุณสามารถเขียนโปรแกรมที่สุ่มตัวอย่างข้อมูลที่จะเก็บ หา estimate ของความน่าจะเป็น (ความผิดพลาดเล็ก ๆ จะทำให้ L เปลี่ยนไม่มาก) หาโค้ด Huffman ทำการเข้ารหัส และส่งก่อนหน้าด้วยอัลกอริทึมการถอดรหัส (ต้นไม้) แล้วตามด้วยข้อมูลที่เข้ารหัส ทั้งหมดโดยไม่ต้องมีการแทรกแซงจากมนุษย์ เมื่อฝั่งถอดรหัสคุณก็จะได้รับต้นไม้การถอดรหัสแล้ว ดังนั้นเมื่อเขียนเป็นไลบรารีโปรแกรม คุณก็สามารถใช้มันได้เมื่อคิดว่าจะมีประโยชน์

สรุป: Huffman codes have even been used in some computers on the instruction part of instructions, since instructions have very different probabilities of being used. We need, therefore, to look at the gain in average code length L we can expect from Huffman encoding over simple block encoding, which uses symbols all of the same length.

ถ้าความน่าจะเป็นทั้งหมดเท่ากันและมีสัญลักษณ์จำนวนเท่ากับ 2^k จะเห็นได้จากกระบวนการของ Huffman ว่าจะได้โค้ดแบบบล็อกปกติที่แต่ละสัญลักษณ์มีความยาวเท่ากัน แต่ถ้าคุณไม่มีจำนวนสัญลักษณ์เท่ากับ 2^k บางสัญลักษณ์จะถูกทำให้สั้นลง แต่ยากจะบอกได้ว่าจะมีหลายตัวที่สั้นลงหนึ่งบิตหรือสองบิตหรือมากกว่าในแต่ละกรณี ในทุกกรณี ค่า L จะใกล้เคียงและไม่ต่ำมากนักเมื่อเทียบกับโค้ดบล็อกที่สอดคล้องกัน

สรุป: On the other hand, if each p_i is greater than two-thirds the sum of all the probabilities that follow except the last, then you will get a comma code, one which has one symbol of length 1 (0), one symbol of length 2 (10), etc., down to the last, where at the end you will have two symbols of the same length, _q – 1, 1111…10 and 1111…11. For this the value of L can be much less than the corresponding block code.

กฎ: การเข้ารหัสแบบ Huffman จะคุ้มเมื่อความน่าจะเป็นของสัญลักษณ์แตกต่างกันมาก และจะไม่คุ้มมากเมื่อพวกมันค่อนข้างเท่ากัน

เมื่อมีความน่าจะเป็นสองค่าที่เท่ากันเกิดขึ้นในกระบวนการ Huffman เราสามารถจัดลำดับได้ตามต้องการ ดังนั้นโค้ดที่ได้อาจแตกต่างกันมาก แม้ความยาวเฉลี่ยในทั้งสองกรณีจะเท่ากัน การถามว่าควรเลือกลำดับอย่างไรเมื่อตัวความน่าจะเป็นเท่ากันเป็นคำถามที่สมเหตุสมผล เกณฑ์ที่สมเหตุสมผลคือการลดความแปรปรวนของโค้ด เพื่อให้ข้อความที่มีความยาวเท่ากันในสัญลักษณ์ต้นฉบับจะมีความยาวใกล้เคียงกันในข้อความที่เข้ารหัส คุณไม่ต้องการให้ข้อความต้นฉบับสั้นถูกเข้ารหัสเป็นข้อความยาวโดยบังเอิญ กฎง่าย ๆ คือเมื่อใส่ความน่าจะเป็นใหม่ในตาราง ให้ใส่มันให้สูงที่สุดเท่าที่จะทำได้ ถ้าคุณวางมันเหนือสัญลักษณ์ที่มีความน่าจะเป็นสูงกว่าเล็กน้อย โดยทั่วไปจะลดความแปรปรวนอย่างมากและในเวลาเดียวกันเพิ่ม L เล็กน้อย ดังนั้นเป็นกลยุทธ์ที่ดี

สรุป: Having done all we are going to do about source encoding (though we have by no means exhausted the topic), we turn to channel encoding, where the noise is modeled. The channel, by supposition, has noise, meaning some of the bits are changed in transmission (or storage). What can we do?

การตรวจจับความผิดพลาดเดี่ยวเป็นเรื่องง่าย ต่อบล็อกของ n – 1 บิต เราแนบบิตที่ n_th ซึ่งถูกตั้งค่าให้ทำให้บิตทั้งหมด n มีจำนวนของ 1 เป็นจำนวนคู่ (หรือเป็นคี่ถ้าคุณชอบ แต่ในทฤษฎีนี้เราจะยึดคู่) เรียกการตรวจสอบนี้ว่า even (odd) parity check หรือเรียกสั้น ๆ ว่า parity check

สรุป: Thus if all the messages I send to you have this property, then at the receiving end you can check to see if the condition is met. If the parity check is not met then you know at least one error has happened; indeed, you know an odd number of errors has occurred. If the parity does check, then either the message is correct, or else there are an even number of errors. Since it is prudent to use systems where the probability of an error in any position is low, then the probability of multiple errors must be much lower.

เพื่อให้ง่ายทางคณิตศาสตร์ เราสมมติว่าช่องทางมี white noise หมายความว่า (1) แต่ละตำแหน่งในบล็อกของ n บิตมีความน่าจะเป็นของความผิดพลาดเท่ากันกับตำแหน่งอื่น ๆ และ (2) ความผิดพลาดในตำแหน่งต่าง ๆ เป็นอิสระต่อกัน ภายใต้สมมติฐานเหล่านี้ ความน่าจะเป็นของการเกิดความผิดพลาดเป็นดังนี้:

สรุป: From this, if, as is usually true, p is small with respect to the block length n (meaning the product np is small), then multiple errors are much less likely to happen than single errors. It is an engineering judgment of how long to make n for a given probability of error p. If n is small then you have a higher redundancy (the ratio of the number of bits sent to the minimum number of bits possible, n/(n – 1)) than with a larger n, but if np is large, then you have a low redundancy but a higher probability of an undetected error. You must make an engineering judgement on how you are going to balance these two effects.

เมื่อคุณพบความผิดพลาดเดี่ยว คุณสามารถร้องขอการส่งใหม่และคาดว่าจะถูกต้องในครั้งที่สอง ถ้ายังไม่ถูกต้องก็ขอครั้งที่สาม เป็นต้น อย่างไรก็ตาม ถ้าข้อความที่เก็บไว้ในสตอเรจผิดพลาด คุณจะร้องขอการส่งซ้ำไปเรื่อย ๆ จนกว่าจะเกิดความผิดพลาดอีกครั้ง และคุณอาจจะมีสองความผิดพลาดที่ผ่านการตรวจไม่พบในสเกมของการตรวจจับความผิดพลาดแบบเดียวนี้ ดังนั้นการใช้การส่งซ้ำหลายครั้งควรขึ้นกับลักษณะคาดหวังของข้อผิดพลาด

โค้ดประเภทนี้ถูกใช้อย่างแพร่หลาย แม้แต่ในยุครีเลย์ บริษัทโทรศัพท์ในศูนย์กลางสื่อสารและในคอมพิวเตอร์รีเลย์ยุคแรกหลายแห่งใช้โค้ด 2-out-of-5 หมายความว่าสองและมีเพียงสองจากห้ารีเลย์เท่านั้นที่ต้อง "up" โค้ดนี้ใช้แทนตัวเลขทศนิยม เพราะ C(5, 2) = 10 หากไม่ได้มีรีเลย์สองตัวที่ขึ้นพอดี นั่นคือข้อผิดพลาดและต้องส่งซ้ำ นอกจากนี้ยังมีโค้ด 3-out-of-7 ซึ่งชัดเจนว่าเป็นรหัสตรวจ parity แบบคี่

ผมเจอโค้ด 2-out-of-5 เหล่านี้ครั้งแรกเมื่อใช้คอมพิวเตอร์รีเลย์ Model 5 ที่ Bell Labs และผมประทับใจ: ไม่เพียงแต่พวกมันช่วยให้ได้คำตอบที่ถูกต้อง แต่สำคัญกว่านั้น ในมุมมองของผม พวกมันช่วยให้คนบำรุงรักษาสามารถดูแลเครื่องได้ดีขึ้น ข้อผิดพลาดใด ๆ ถูกจับได้โดยเครื่องแทบจะในขณะที่มันเกิดขึ้น และดังนั้นชี้ชัดให้ทีมบำรุงรักษาทราบส่วนที่มีปัญหา แทนที่จะให้พวกเขามั่วซั่วปรับแต่งชิ้นส่วนที่ปกติดีเพื่อหาชิ้นที่เสีย

ข้ามลำดับเวลาออกไปบ้าง แต่ยังคงตามแนวคิดเดียวกัน ผมถูกถามโดย at&t ว่าจะเข้ารหัสอย่างไรเมื่อมนุษย์ใช้ตัวอักษร 26 ตัว ตัวเลข 10 ตัว และช่องว่าง (space) นี่เป็นปัญหาที่พบได้ในการตั้งชื่อชิ้นส่วน สต็อก และการตั้งชื่ออาคาร เป็นต้น จากข้อมูลข้อผิดพลาดการกดหมายเลขของโทรศัพท์ และประสบการณ์การคำนวณด้วยมือมายาวนาน ผมรู้ว่ามนุษย์มีแนวโน้มสูงที่จะสับเปลี่ยนตัวเลขที่อยู่ติดกัน (เช่น 67 อาจกลายเป็น 76) รวมถึงเปลี่ยนตัวเดียวๆ (มักจะทำให้ตัวเลขผิดพลาดเป็นการคิดซ้ำ ตัวอย่างเช่น 556 อาจกลายเป็น 566) ดังนั้นการตรวจจับความผิดพลาดเดี่ยวจึงไม่พอ ผมชวนคนฉลาดสองคนมาร่วมประชุมและเสนอโจทย์ ข้อเสนอหลายอย่างผมปฏิเสธจนกระทั่งหนึ่งในนั้นคือ Ed Gilbert เสนอ weighted code โดยเฉพาะเขาเสนอให้กำหนดค่า 0, 1, 2, …, 36 ให้กับสัญลักษณ์ 0, 1, …, 9, A, B, …, Z, space ต่อไปเขาไม่ได้คำนวณผลรวมของค่านี้โดยตรงแต่ถ้าสัญลักษณ์ลำดับที่ k มีค่า (เพื่อความสะดวก) เป็น s_k สำหรับข้อความที่มี n สัญลักษณ์ เราคำนวณ

“modulo” หมายถึงนำผลรวมถ่วงน้ำหนักนี้หารด้วย 37 แล้วเอาเศษมาเท่านั้น ในการเข้ารหัสข้อความที่มี n สัญลักษณ์ ให้เว้นสัญลักษณ์ตัวแรก k = 1 ไว้ แล้วไม่ว่ารอยเศษจะเป็นเท่าไรก็ตาม (ซึ่งมีค่าน้อยกว่า 37) ให้เอาค่านั้นไปลบจาก 37 และใช้สัญลักษณ์ที่สอดคล้องกันเป็นสัญลักษณ์ตรวจสอบ (check symbol) ซึ่งจะถูกใส่ในตำแหน่งแรก ดังนั้นข้อความทั้งหมด เมื่อมีสัญลักษณ์ตรวจสอบในตำแหน่งแรก จะมีผลรวมตรวจสอบ (check sum) เท่ากับ 0 เมื่อคุณตรวจดูการสลับตำแหน่งของสัญลักษณ์สองตัวที่ต่างกัน รวมถึงการเปลี่ยนแปลงของสัญลักษณ์เดี่ยว คุณจะเห็นว่ามันจะทำลายการตรวจสอบ parity ถ่วงน้ำหนักโมดูล 37 (โดยมีข้อแม้ว่าสองสัญลักษณ์ที่แลกตำแหน่งกันนั้นไม่ได้ห่างกันเป็น 37 ตำแหน่งพอดี!) โดยไม่ลงรายละเอียดมากนัก สิ่งสำคัญคือ modulus ต้องเป็นจำนวนเฉพาะ ซึ่ง 37 เป็นจำนวนเฉพาะ

ในการหาผลรวมถ่วงน้ำหนักของสัญลักษณ์ (จริง ๆ คือค่าของพวกมัน) คุณสามารถหลีกเลี่ยงการคูณและใช้เพียงการบวกและการลบได้ หากต้องการ ให้วางตัวเลขตามลำดับในคอลัมน์และคำนวณผลรวมสั่งการ (running sum) แล้วคำนวณผลรวมสั่งการของผลรวมสั่งการ modulo 37 แล้วทำการเติมเต็ม (complement) ตาม 37 แล้วจะได้สัญลักษณ์ตรวจสอบ ตารางต่อไปนี้เป็นภาพประกอบโดยใช้ w, x, y, และ z

สัญลักษณ์	ผลรวม	ผลรวมของผลรวม
w	w	w
x	w + x	2w + x
y	w + x + y	3w + 2x + y

| z | w + x + y + z | 4w + 3x + 2y + z
\= weighted check sum |

ที่ฝั่งรับคุณจะนำ modulus มาลบซ้ำ ๆ จนกว่าจะได้ค่าเป็น 0 (สัญลักษณ์ถูกต้อง) หรือค่าเป็นลบ (สัญลักษณ์ผิด)

ถ้าคุณจะใช้การเข้ารหัสนี้ เช่น สำหรับชื่อชิ้นส่วนในระบบคลังสินค้า ครั้งแรกที่มีชื่อชิ้นส่วนผิดพลาดเข้ามาในคอมพิวเตอร์ (เช่น ในเวลาส่งหรือตั้งคำสั่งสั่งซื้อ) ข้อผิดพลาดจะถูกจับได้; คุณจะไม่ต้องรอจนคำสั่งไปถึงสำนักงานใหญ่และถูกแจ้งว่าชิ้นส่วนนั้นไม่มีอยู่หรือส่งผิด ก่อนที่คำสั่งจะออกจากสถานที่ของคุณ ข้อผิดพลาดจะถูกจับและแก้ไขได้ง่ายในเวลานั้น เรื่องดูเรียบง่ายใช่ไหม? ใช้งานได้ดีต่อความผิดพลาดของมนุษย์ (เมื่อเทียบกับ white noise ก่อนหน้านี้) ใช่!

จริง ๆ แล้วคุณเห็นโค้ดแบบนี้บนหนังสือของคุณในปัจจุบันกับ ISBN มันเป็นโค้ดเดียวกันยกเว้นว่าพวกเขาใช้เฉพาะตัวเลขทศนิยมสิบตัวเท่านั้น และเพราะสิบไม่ใช่จำนวนเฉพาะ พวกเขาต้องเพิ่มสัญลักษณ์ที่สิบเอ็ด ชื่อว่า X ซึ่งอาจปรากฏเป็นสัญลักษณ์ตรวจสอบเป็นครั้งคราว — แท้จริงแล้วประมาณหนึ่งในสิบเอ็ดหนังสือของคุณจะมี X เป็นตัวสุดท้ายของ ISBN เสมอ ขีดกลางเป็นเพียงตกแต่งและไม่ได้ใช้ในโค้ด ลองตรวจสอบเองในตำราเรียนของคุณ องค์กรใหญ่หลายแห่งอื่น ๆ ก็สามารถใช้โค้ดเช่นนี้ได้อย่างมีประสิทธิผล หากพวกเขาต้องการลงแรง

ผมเคยบอกซ้ำแล้วซ้ำเล่าว่าผมเชื่อว่าอนาคตจะเกี่ยวข้องกับข้อมูลในรูปสัญลักษณ์มากขึ้นและเกี่ยวกับสิ่งของทางกายภาพน้อยลง ดังนั้นทฤษฎีการเข้ารหัส (การแทนข้อมูล) ในรูปแบบโค้ดที่เหมาะสมเป็นหัวข้อที่ไม่ใช่เรื่องเล็ก วัสดุข้างต้นให้ตัวอย่างโค้ดตรวจจับความผิดพลาดอย่างง่ายสำหรับสถานการณ์แบบเครื่อง และโค้ดถ่วงน้ำหนักสำหรับการใช้งานของมนุษย์ ทั้งสองเป็นตัวอย่างสองตัวของสิ่งที่ทฤษฎีการเข้ารหัสสามารถนำมาสู่หน่วยงานในจุดที่ความผิดพลาดจากเครื่องและมนุษย์อาจเกิดขึ้น

สรุป: When you think about the man-machine interface, one of the things you would like is to have the human make comparatively few keystrokes—Huffman encoding in a disguise! Evidently, given the probabilities of you making the various branches in the program menus, you can design a way of minimizing your total keystrokes if you wish. Thus the same set of menus can be adjusted to the work habits of different people rather than presenting the same face to all. In a broader sense than this, “automatic programming” in the higher-level languages is an attempt to achieve something like Huffman encoding so that for the problems you want to solve comparatively few keystrokes are needed, and the ones you do not want are the others.