हफमैन कोडिंग एन्ट्रापी को समाप्त क्यों करता है जो लेम्पेल-ज़िव नहीं करता है?

Question

लोकप्रिय DEFLATE एल्गोरिथ्म Luffel-Ziv के शीर्ष पर हफमैन कोडिंग का उपयोग करता है।

सामान्य तौर पर, यदि हमारे पास डेटा का यादृच्छिक स्रोत (= 1 बिट एन्ट्रापी / बिट) है, तो हफ़मैन सहित कोई एन्कोडिंग, औसतन इसे संपीड़ित करने की संभावना नहीं है। यदि लेम्पेल-ज़िव "परिपूर्ण" थे (जो कि स्रोतों के अधिकांश वर्गों के लिए दृष्टिकोण करता है, क्योंकि लंबाई अनंत तक जाती है), हफ़मैन के साथ पोस्ट एन्कोडिंग मदद नहीं करेगा। बेशक, लेम्पेल-ज़िव परिपूर्ण नहीं है , कम से कम परिमित लंबाई के साथ, और इसलिए कुछ अतिरेक रहता है।

यह यह शेष अतिरेक है जिसे हफ़मैन कोडिंग आंशिक रूप से समाप्त कर देता है और जिससे संपीड़न में सुधार होता है।

मेरा सवाल है: हफमैन कोडिंग और एलजेड द्वारा न केवल इस शेष अतिरेक को सफलतापूर्वक समाप्त क्यों किया गया है? Huffman बनाम LZ के क्या गुण हैं? बस LZ फिर से चल रहा होगा (जो कि LZ के साथ LZ संपीड़ित डेटा को दूसरी बार एन्कोडिंग करता है) कुछ इसी तरह पूरा होता है? यदि नहीं, तो क्यों नहीं? इसी तरह, पहले हफमैन के साथ संपीड़ित करना और फिर एलजेड काम के साथ, और यदि नहीं, तो क्यों?

अद्यतन: यह स्पष्ट है कि LZ के बाद भी कुछ अतिरेक बना रहेगा। कई लोगों ने उस बिंदु को बनाया है। यह स्पष्ट नहीं है: LZ की तुलना में हफमैन द्वारा संबोधित शेष अतिरेक क्यों बेहतर है? मूल स्रोत अतिरेक के साथ इसके विपरीत क्या अद्वितीय है, जहां एलजेड हफमैन की तुलना में बेहतर काम करता है?

Answer 1

यह मूल रूप से एक टिप्पणी थी, लेकिन यह बहुत लंबा हो गया।

यदि आप DEFLATE को देखते हैं, तो हफमैन द्वारा जो संकुचित किया जा रहा है वह LZ77 का आउटपुट है; LZ77 काम करता है (जब यह कच्चे डेटा की तुलना में कम बिट लेता है) एक सूचक को पहले स्ट्रिंग में भेजा जा रहा है, और एक मैच की लंबाई जो बताता है कि सूचक के बाद कितने प्रतीकों को लेना है। सिद्धांत से पता चलता है कि, अतिरिक्त संपीड़न के बिना भी, यह तकनीक अंततः स्रोत एन्ट्रॉपी में परिवर्तित हो जाती है। हालाँकि, डेटा कम्प्रेशन में, किसी भी समय आपके पास एक वितरण है जो पूरी तरह से यादृच्छिक नहीं है, आप इसे कंप्रेस भी कर सकते हैं। यह मानने का कोई कारण नहीं है कि LZ77- पॉइंटर्स और मैच की लंबाई का आउटपुट पूरी तरह से यादृच्छिक है। उन्हें स्पर्शोन्मुख सीमा में यादृच्छिकता को पूरा करने के लिए अभिसरण करना होगा, क्योंकि LZ77 विषमतम रूप से इष्टतम है, लेकिन व्यवहार में आप केवल एक परिमित शब्दकोश का उपयोग करते हैं, इसलिए वे संभवतः पूरी तरह से यादृच्छिक होने से बहुत दूर रहते हैं कि आप उन पर आगे संपीड़न करके जीतते हैं। स्वाभाविक रूप से, आप पॉइंटर्स के लिए एक हफ़मैन कोड का उपयोग करते हैं और दूसरा मैच की लंबाई के लिए, क्योंकि इन दोनों प्रक्रियाओं में अलग-अलग आँकड़े हैं।

संपीड़न के दूसरे दौर के लिए LZ के बजाय हफ़मैन का उपयोग क्यों करें? HZman पर LZ का बड़ा फायदा प्रतीकों के बीच निर्भरता का इलाज करना है। अंग्रेजी में, यदि एक अक्षर 'q' है, तो अगला 'u' होने की संभावना है, और इसी तरह। यदि प्रतीक स्वतंत्र घटनाएँ हैं, तो हफ़मैन सरल है और छोटे तारों के लिए भी बेहतर या बेहतर काम करता है। LZ77 के आउटपुट के लिए, मेरा अंतर्ज्ञान यह है कि प्रतीकों को काफी स्वतंत्र होना चाहिए, इसलिए हफ़मैन को बेहतर काम करना चाहिए।

Comments

मैं आपके पहले पैराग्राफ पर आपके साथ हूं: LZ अभी भी सेक करने के लिए कुछ अतिरेक छोड़ता है। लेकिन आपका दूसरा पैराग्राफ अभी भी उछलता हुआ प्रतीत हो रहा है, यदि हाथ लहराते नहीं हैं। दो दावे हैं: 1. LZ के बाद शेष अतिरेक शून्य-क्रम (जो है, p (X_n) लगभग है) x_n-1 से स्वतंत्र है; मैं शून्य-क्रम शब्द का उपयोग शून्य-क्रम मॉडल के रूप में कर रहा हूं, जैसे; data-compression.com/theory.shtml ) और 2. शून्य-क्रम अतिरेक पर, Huffman LZ से बेहतर काम करता है; उच्च-क्रम अतिरेक पर, एलजेड बेहतर काम करता है। शायद ये दावे दोनों सच हैं, लेकिन आपने उचित नहीं है

— SRobertJames

@ रॉबर्ट: उच्च-क्रम के सहसंबंधों का हफमैन कोडिंग पर कोई प्रभाव नहीं पड़ता है। एलजेड उच्च-क्रम अतिरेक के लिए asymptotically आशावादी रूप से काम करता है, लेकिन अतिरिक्त ओवरहेड की आवश्यकता होती है इसका मतलब यह है कि यह परिमित-लंबाई शून्य-क्रम स्रोतों पर भी नहीं करता है। यह कहीं न कहीं साहित्य में प्रयोगात्मक रूप से अध्ययन किया गया होगा; हो सकता है कि कोई अन्य व्यक्ति एक संदर्भ के लिए एक संकेत दे सकता है। बिंदु 1 के लिए, मेरा अंतर्ज्ञान यह है कि LZ के बाद शेष कोई उच्च-क्रम अतिरेक किसी भी सरल कोडिंग योजना में उपयोग करने के लिए बहुत जटिल है, लेकिन मेरे पास इसे सही ठहराने का कोई अच्छा तरीका नहीं है।

— पीटर शोर

Answer 2

डेटा संपीड़न वास्तव में दो चीजों के बारे में है: मॉडलिंग और एन्कोडिंग। एलजेड परिवार के एल्गोरिदम पाठ को सटीक पुनरावृत्तियों के संयोजन के रूप में मॉडल करते हैं, जो कि कई यादृच्छिक स्रोतों के लिए समान रूप से इष्टतम है और कई वास्तविक ग्रंथों के लिए यथोचित रूप से अच्छा है। कुछ इनपुट्स के लिए, यह मॉडल काफी खराब हो सकता है। उदाहरण के लिए, आप LZ का उपयोग किसी प्रत्यय सरणी को सीधे संपीड़ित करने के लिए नहीं कर सकते हैं, भले ही प्रत्यय मूल पाठ की तरह संक्षिप्त हो।

LZ77 इनपुट को ट्यूपल्स अनुक्रम के रूप में दोहराता है , एक प्रति पुनरावृत्ति, जहां एक पूर्ववर्ती घटना का सूचक है, पुनरावृत्ति की लंबाई है, और अगला वर्ण है। आमतौर पर इस अनुक्रम में कई (यथोचित लंबे) सटीक दोहराव नहीं होते हैं, इसलिए हम इसे संपीड़ित करने के लिए एक और एलजेड-आधारित एल्गोरिथ्म का उपयोग नहीं कर सकते हैं। इसके बजाय, हमें अन्य मॉडलों की तलाश करनी होगी।पी ℓ $(p, \ell, c)$$p$$\ell$$c$

टपल के तीन घटकों में से, पॉइंटर को एक बड़े यादृच्छिक पूर्णांक के रूप में सोचा जा सकता है, इसलिए इसे -bit पूर्णांक (लंबाई इनपुट के लिए ) के रूप में एन्कोडिंग एक बहुत अच्छा विकल्प है। दूसरी ओर, पुनरावृत्ति की लंबाई आमतौर पर छोटी होती है, इसलिए हमें उन्हें कोड के साथ सांकेतिक शब्दों में बदलना चाहिए जो बड़ी संख्या में छोटी संख्या का पक्ष लेते हैं। हफ़मैन एक उपयुक्त कोडिंग योजना है, और अन्य भी हैं। पुनरावृत्ति के बाद वर्ण शायद समान रूप से वितरित नहीं किए जाते हैं, इसलिए हम शून्य-क्रम वाले कंप्रेसर का उपयोग कर सकते हैं जैसे कि हफमैन सबसे स्पष्ट अतिरेक को निचोड़ने के लिए।$\log n$$n$

तो संक्षेप में, हफमैन ट्यूप को संपीड़ित करने में एलजेड को हरा देता है, क्योंकि इसका मॉडल (निश्चित वितरण बनाम सटीक पुनरावृत्ति) डेटा के लिए एक बेहतर मेल है।

Comments

शुक्रिया, जौनी। ऐसा लगता है कि मुख्य अतिरेक छोड़ दिया गया है कि प्रतिनिधि लंबाई आमतौर पर बड़े होने के बजाय छोटी होती है (समान रूप से [0,2 ^ [] पर वितरित नहीं होती)। हफ़मैन इस शून्य आदेश विषमता पर अच्छा करता है, जबकि LZ को वास्तव में अच्छी तरह से काम करने के लिए बड़ी विशेषताओं की आवश्यकता होती है। क्या वो सही है? और हफ़मैन का उपयोग शुरू करने के लिए क्यों नहीं - एलजेड के साथ बिल्कुल परेशान क्यों?

— SRobertJames

यदि हम सीधे हफ़मैन के साथ पाठ को संपीड़ित करते हैं, तो हमें शून्य-ऑर्डर एन्ट्रॉपी से बेहतर संपीड़न नहीं मिल सकता है। हालांकि, अधिकांश वास्तविक ग्रंथों में अतिरेक के महत्वपूर्ण स्रोत हैं जो शून्य-क्रम एन्ट्रॉपी के साथ पर्याप्त रूप से मॉडलिंग नहीं कर सकते हैं। कई मामलों में, Huffman से पहले LZ का उपयोग करने से हम इस अतिरेक को संकुचित कर सकते हैं।

— जौनी साइरन

Answer 3

मैं जवाब खोज शब्द आकार में निहित है।

डेटा में स्थानीयता की भावना है (यह कहना है, यदि डेटा का एक टुकड़ा उपयोग किया गया है, तो यह संभावना है कि इसे जल्द ही फिर से उपयोग किया जाएगा), और LZ एल्गोरिथ्म लुकअप डिक्शनरी निर्माण में इसका लाभ उठाता है। यह लुकअप को तेज़ रखने के लिए , संभव नोड्स की परिमित मात्रा के साथ एक ट्राइ उत्पन्न करता है । जब यह आकार की सीमा से टकराता है, तो यह पिछले एक के बारे में "भूल" करने के लिए एक और त्रिकोणीय बनाता है। तो इसे फिर से सरल अक्षरों के लिए लुकअप टेबल का निर्माण करना होता है, लेकिन अगर कुछ शब्दों का अब उपयोग नहीं किया जाता है, तो उन्हें अब मेमोरी में नहीं रखा जाता है, इसलिए छोटे एन्कोडिंग का उपयोग किया जा सकता है।

इसलिए, HZman एन्कोडिंग के साथ एक LZ आउटपुट को और कम किया जा सकता है, लुकअप कोशिशों के निर्माण में इस अतिरेक के लिए सांख्यिकीय विश्लेषण द्वारा पता लगाया जा सकता है।

Comments

मैं पहले पैराग्राफ को स्वीकार करता हूं: आप समझाते हैं कि एलजेड अतिरेक क्यों छोड़ता है। लेकिन दूसरा पैराग्राफ काफी छलांग लगता है: हफमैन इस अतिरेक को क्यों पकड़ता है? क्यों नहीं LZ फिर से? और, अगर हफमैन अधिक व्यापक है, तो इसे शुरू करने के लिए क्यों नहीं?

— SRobertJames

Answer 4

शायद मैं यहाँ से ट्रैक कर रहा हूँ, लेकिन हफ़मैन एन्कोडिंग अपनी एन्कोडिंग टेबल (पेड़) बनाने के लिए पूरे इनपुट को देखता है, जबकि लेम्पेल-ज़िव के साथ-साथ एनकोड करता है। यह हफमैन के लिए एक फायदा और नुकसान दोनों है। असमानता अप्रिय है, अर्थात् हमें शुरू करने से पहले पूरे इनपुट को देखना होगा। फायदा यह है कि हफ़मैन खाते के आँकड़ों को ध्यान में रखेगा जो इनपुट में कहीं भी होता है, जबकि लेम्पेल-ज़िव को उत्तरोत्तर इसका निर्माण करना होता है। या इसे एक अलग तरीके से रखने के लिए, लेम्पेल-ज़िव में एक "दिशा" है जो हफ़मैन नहीं करता है।

लेकिन यह सब सिर्फ कल्पना का मेरा भोला तरीका है कि चीजें कैसी हैं। हमें यहां एक वास्तविक प्रमाण की आवश्यकता है कि यह देखने के लिए कि हफमैन ने लेम्पेल-ज़िव को कैसे समझा।

Comments

लोगों ने अनुकूली हफ़मैन कोडिंग को परिभाषित किया है, जो केवल एक बार इनपुट को देखता है। इस चर्चा के प्रयोजनों के लिए, अनुकूली और गैर-अनुकूली हफ़मैन कोडिंग काफी समान व्यवहार करेंगे।

— पीटर शोर

Answer 5

संक्षिप्त उत्तर है, LZ एक "सार्वभौमिक" एल्गोरिथ्म है जिसमें इसे स्रोत के सटीक वितरण को जानने की आवश्यकता नहीं है (बस इस धारणा की आवश्यकता है कि स्रोत स्थिर और एर्गोडिक है)। लेकिन हफमैन नहीं है; इसे उस सटीक वितरण को जानने की जरूरत है जिससे स्रोत का नमूना लिया जाता है (हफमैन पेड़ बनाने के लिए)। यह अतिरिक्त जानकारी हफ़मैन तंग संपीड़न गारंटी प्राप्त करती है। हालांकि व्यावहारिक फ़ाइल संपीड़न एल्गोरिदम के लिए हफ़मैन कम अनुकूल हो सकता है क्योंकि इसे पहले फ़ाइल के अनुभवजन्य आंकड़े इकट्ठा करने की आवश्यकता होगी और फिर दूसरी छमाही में वास्तविक संपीड़न करना होगा, जबकि LZ को ऑनलाइन लागू किया जा सकता है।

अधिक जानकारी मानक सूचना सिद्धांत ग्रंथों, उदाहरण के लिए, कवर और थॉमस द्वारा सूचना सिद्धांत के तत्व में पाई जा सकती है।

Comments

मुझे लगता है कि स्थिर एर्गोडिक स्रोत सिर्फ एक धारणा है जो एलजेड का विश्लेषण करना आसान बनाता है। आखिरकार, संपीड़न इनपुट के दहनशील गुणों पर आधारित है, जो सिर्फ कई मामलों में सांख्यिकीय गुणों के साथ अच्छी तरह से मेल खाने के लिए होता है। उदाहरण के लिए, सादे पाठ प्रारूप में अंग्रेजी भाषा के ग्रंथों का एक संग्रह, HTML प्रारूप में समान पाठों के बाद विचार करें। LZ इस संग्रह को काफी अच्छी तरह से संपीड़ित करता है, भले ही यह एक स्थिर एर्गोडिक स्रोत द्वारा उत्पन्न कुछ की तरह नहीं दिखता है।

— जौनी सायरन

@ जौनी: मैं इस टिप्पणी से असहमत हूं; मुझे लगता है कि कुछ अर्थों में, सादा पाठ अंग्रेजी भाषा एक स्थिर एर्गोडिक स्रोत की तरह दिखता है, और यह समानता वास्तव में वही है जो एलजेड का लाभ ले रही है।

— पीटर शोर

@Peter: लेकिन इस मामले में, स्रोत पहले सादा पाठ प्रारूप में कुछ पाठ उत्पन्न करता है, और फिर HTML प्रारूप में बिल्कुल वैसा ही पाठ। सादे पाठ से HTML में कुछ मनमाने बिंदु पर यह परिवर्तन एर्गोडिक स्थिर संपत्ति को तोड़ने के लिए लगता है। दूसरी ओर, सादे पाठों और HTML पाठों को अलग-अलग संपीड़ित करते समय संपीड़न परिणाम बहुत बेहतर होते हैं, क्योंकि सादे पाठ प्रारूप में एक पाठ और HTML प्रारूप में एक ही पाठ के बीच बहुत सारी पारस्परिक जानकारी होती है।

— जौनी सायरन