การบีบอัดข้อมูลโดยใช้ตัวเลขเฉพาะ

22

ฉันเพิ่งพบบทความที่น่าสนใจต่อไปนี้ซึ่งอ้างว่าบีบอัดชุดข้อมูลแบบสุ่มได้อย่างมีประสิทธิภาพมากกว่า 50% เสมอโดยไม่คำนึงถึงประเภทและรูปแบบของข้อมูล

โดยทั่วไปจะใช้หมายเลขเฉพาะเพื่อสร้างการแทนค่าของ data data ขนาด 4 ไบต์ซึ่งง่ายต่อการแตกไฟล์เนื่องจากทุกหมายเลขเป็นผลิตภัณฑ์เฉพาะของ primes เพื่อเชื่อมโยงลำดับเหล่านี้กับช่วงเวลาที่มันใช้พจนานุกรม

คำถามของฉันคือ:

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

information-theory data-compression primes

— Klangen
แหล่งที่มา

5

ตามที่คุณสังเกตเห็นกระดาษกำลังทำการเรียกร้องที่แข็งแกร่งจริง ๆ โดยเฉพาะอย่างยิ่งหากกระดาษถูกตีพิมพ์ในสถานที่แปลก ๆ (เอกสารที่น่าทึ่ง "ปฏิวัติการคำนวณ" ควรปรากฏในสถานที่ที่รู้จักกันดีใช่ไหม?)

— Juho

2

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

— vzn

6

"สิ่งนี้ไม่สามารถใช้ในการบีบอัดข้อมูลที่ถูกบีบอัดซ้ำโดยใช้อัลกอริทึมเดียวกันได้หรือไม่" - ใช่ อัลกอริทึมใด ๆที่อ้างว่าสามารถบีบอัดข้อมูลโดยพลการทั้งหมดสามารถนำไปใช้ซ้ำกับเอาต์พุตของตัวเองเพื่อให้ข้อมูลใด ๆ ถูกบีบอัดเป็น 0 บิต ดังนั้นการอ้างสิทธิ์นี้จึงเป็นไปไม่ได้

— Jörg W Mittag

1

@ JörgWMittagฉันมีอัลกอริทึมที่ช่วยให้คุณบีบอัดไฟล์ซ้ำ ๆ เป็นบิตขนาดเล็ก แต่ก็ไม่สามารถทำได้ ใช้งานได้กับไฟล์ที่เริ่มต้นด้วย 1 บิตเท่านั้น: ถือว่าไฟล์ทั้งหมดเป็นเลขฐานสองขนาดใหญ่ลดลงจากนั้นทิ้ง 0 ที่นำหน้า หากต้องการขยายขนาดให้เพิ่มค่านำหน้า 1 หากจำเป็น

— 253751

3

หมายเหตุถึงตนเอง: อย่ากังวลที่จะส่งเอกสารใด ๆ ไปยังวารสาร Elsevier ใด ๆ เลยทีเดียว

— 500 - ข้อผิดพลาดเซิร์ฟเวอร์ภายใน

34

บีบอัดชุดข้อมูลแบบสุ่มมากกว่า 50% เสมอ

นั่นเป็นไปไม่ได้ คุณไม่สามารถบีบอัดข้อมูลแบบสุ่มคุณต้องการโครงสร้างบางอย่างเพื่อใช้ประโยชน์จาก การบีบอัดจะต้องพลิกกลับเพื่อให้คุณไม่อาจบีบอัดทุกอย่างโดย 50% เพราะมีสายไกลน้อยของความยาวกว่าที่มีความยาวn $n/2$ $n$

มีปัญหาสำคัญกับกระดาษ:

พวกเขาใช้ไฟล์ทดสอบ 10 ไฟล์โดยไม่มีการระบุเนื้อหาใด ๆ ข้อมูลสุ่มจริงๆหรือ พวกเขาเป็นอย่างไร
พวกเขาอ้างว่าได้อัตราส่วนการอัดอย่างน้อย 50% ในขณะที่ข้อมูลการทดสอบแสดงให้เห็นว่าพวกเขาบรรลุผลมากที่สุด 50%

อัลกอริทึมนี้กำหนดกลยุทธ์แบบไม่สูญเสียซึ่งใช้ประโยชน์จากตัวเลขเฉพาะในระบบเลขฐานสิบ

อะไร? หมายเลขเฉพาะเป็นหมายเลขเฉพาะโดยไม่คำนึงถึงฐาน
ปัญหา # 1 ที่มีการคลายการบีบอัด: การแยกตัวประกอบเฉพาะเป็นปัญหาที่ยากพวกมันจะมีประสิทธิภาพได้อย่างไร?
$2\cdot 5 = 10 = 5\cdot 2$

ฉันไม่คิดว่าบทความนี้ดีมาก

— Tom van der Zanden
แหล่งที่มา

จากสิ่งที่ฉันเข้าใจพวกเขาเก็บคำสั่งของสตริงที่มีหลายหลากเท่ากันในพจนานุกรม แต่ในชุดข้อมูลแบบสุ่มสิ่งนี้ไม่ควรสร้างพจนานุกรมขนาดใหญ่เนื่องจากมีสตริง 4 ไบต์จำนวนมากที่มีหลายหลาก 1 (หรือหลายหลากเท่ากัน)

— Klangen

@Pickle ในตัวอย่างของพวกเขาสตริง "@THE" มีหลายหลาก 2 ฉันไม่เห็นว่าพวกเขาสามารถสร้างใหม่ได้อย่างไรในที่ที่สองคำว่า "ควร" ไป

— Tom van der Zanden

1

อ่าฉันเข้าใจแล้ว การสังเกตที่ดี แน่นอนว่าเป็นปัญหาสำคัญ กระดาษนี้ได้รับการยอมรับให้ปรากฏในวารสารอย่างไร ไม่ควรมีการตรวจสอบเพื่อนอย่างเข้มงวดยิ่งขึ้น?

— Klangen

4

@Pickle ใช่ควรมีการตรวจสอบที่เข้มงวดยิ่งขึ้น แม้ว่าจะไม่ได้เป็นเช่นนั้นทุกครั้ง แต่บางครั้งผู้จัดประชุมที่ไม่มีประสบการณ์ / ขี้เกียจ / ไร้ความสามารถก็ไม่สามารถหาผู้ตรวจทานผู้ตรวจสอบได้ทันเวลา มีหลายเหตุการณ์ที่เกิดขึ้นของเอกสารที่มีพูดพล่อยๆที่สร้างแบบสุ่มได้รับการยอมรับและหนึ่งวารสารแม้ตีพิมพ์บทความชื่อ"Get ฉันออกรายการทางร่วมเพศของคุณ"

— Tom van der Zanden

ฮ่าฮ่าฮ่าช่างวิเศษเหลือเกิน แต่น่าเศร้าในเวลาเดียวกัน

— Klangen

15

ฉันจะเลื่อนเวลาไปที่ Tom van der Zanden ที่ดูเหมือนจะอ่านบทความและค้นพบจุดอ่อนในวิธีการ ในขณะที่ฉันไม่ได้อ่านบทความอย่างละเอียด แต่มาจากนามธรรมและตารางผลลัพธ์ดูเหมือนว่าการอ้างสิทธิ์ที่เชื่อถือได้ในวงกว้าง

สิ่งที่พวกเขาอ้างว่าเป็นอัตราการบีบอัด 50% ที่สอดคล้องกันในไฟล์ข้อความ (ไม่ใช่ "ไฟล์ทั้งหมด") ซึ่งพวกเขาทราบว่าอยู่ในระดับเดียวกันกับ LZW และแย่กว่าประมาณ 10% (การเข้ารหัสแบบ Huffman) การบีบอัดไฟล์ข้อความ 50% นั้นทำได้ยากโดยใช้วิธีการที่เรียบง่ายพอสมควร เป็นการเรียนระดับปริญญาตรีในหลักสูตรวิทยาศาสตร์คอมพิวเตอร์หลายหลักสูตร

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

เว็บไซต์การประชุมอ้างถึงอัตราส่วนการยอมรับ 1: 4 ซึ่งทำให้คุณสงสัยว่าพวกเขาปฏิเสธอะไร

— นามแฝง
แหล่งที่มา

12

คุณถาม:

เป็นไปได้จริง ๆ ตามที่ผู้เขียนแนะนำหรือไม่ จากรายงานระบุว่าผลลัพธ์มีประสิทธิภาพมากและบีบอัดข้อมูลให้มีขนาดเล็กลงเสมอ ขนาดพจนานุกรมจะใหญ่หรือไม่

ใช่แน่นอน แม้กระทั่งตัวอย่างที่หยิบมาด้วยมือของพวกเขา ("THE QUICK SILVER FOX JUMPS เหนือกว่า LAZY DOG") พวกเขาไม่สามารถทำการบีบอัดได้เนื่องจากพจนานุกรมมีสตริงย่อย 4 ไบต์ทุกข้อความ (ลบ 4 ไบต์สำหรับการซ้ำหนึ่งครั้ง " ") ... และข้อความ" บีบอัด "เวอร์ชันจะต้องมีทั้งพจนานุกรมรวมทั้งอึตัวเลขที่สำคัญทั้งหมดนี้

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

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

หากต้องการบีบอัดไฟล์ให้เป็นอีกวิธีหนึ่ง: เมื่อคุณบีบอัดไฟล์. wav ทั้งหมดเป็น. mp3 คุณจะไม่ได้รับการปรับปรุงขนาดไฟล์โดยการซิปไฟล์เหล่านั้น หากไฟล์บีบอัด MP3 ของคุณทำงานเรียบร้อยแล้วจะไม่มีรูปแบบใดที่เหลืออยู่สำหรับให้บีบไฟล์ ZIP เพื่อใช้ประโยชน์

(เช่นเดียวกับการเข้ารหัส: ถ้าฉันนำไฟล์เป็นศูนย์และเข้ารหัสตามอัลกอริทึมการเข้ารหัสที่ฉันเลือกไฟล์ที่ได้จะไม่สามารถบีบอัดได้ดีกว่ามิฉะนั้นอัลกอริธึมการเข้ารหัสของฉันรั่ว "รูปแบบ" ลงในเอาต์พุต!)

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

การอ้างสิทธิ์และผลการทดลองเหล่านี้ไม่เป็นความจริง

ดังที่ Tom van der Zanden ได้กล่าวไว้แล้ว "อัลกอริธึมการบีบอัด" ของ Chakraborty, Kar และ Guchait นั้นมีข้อบกพร่องที่ไม่เพียง แต่จะไม่สามารถบรรลุอัตราส่วนการบีบอัดใด ๆ เท่านั้น แต่ยังไม่สามารถย้อนกลับได้ มีข้อความมากมายที่ "บีบอัด" ให้เป็นภาพเดียวกันเพราะอัลกอริธึมของพวกเขาคือการคูณและการคูณเป็นการสลับ

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

ไดเรกทอรีไฟล์หนึ่งระดับเหนือ URL ที่คุณโพสต์มี 139 "เอกสาร" ที่มีคุณภาพเดียวกันทั้งหมดเห็นได้ชัดว่าได้รับการยอมรับใน "การดำเนินการประชุมระหว่างประเทศว่าด้วยการวิจัยที่เกิดขึ้นใหม่ในด้านคอมพิวเตอร์ข้อมูลการสื่อสารและแอปพลิเคชัน" สิ่งนี้ดูเหมือนจะเป็นการประชุมแบบเสแสร้งประเภทปกติ วัตถุประสงค์ของการประชุมดังกล่าวคือเพื่ออนุญาตให้นักวิชาการหลอกลวงเรียกร้อง "ตีพิมพ์ในวารสาร" ในขณะที่ยังอนุญาตให้ผู้จัดงานไร้ยางอายสามารถทำเงินได้มากมาย (สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการประชุมปลอมให้ตรวจสอบเธรด reddit นี้หรือโพสต์ StackExchange ต่างๆในหัวข้อ ) มีการประชุมเสแสร้งในทุกสาขา เพียงแค่เรียนรู้ที่จะเชื่อสัญชาตญาณของคุณและไม่เชื่อทุกสิ่งที่คุณอ่านใน "การประชุมดำเนินการ" และคุณจะทำได้ดี

— Quuxplusone
แหล่งที่มา

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

— vaab

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

— Klangen

ฉันได้เรียนรู้ในวันนี้ว่ามีสิทธิบัตรของสหรัฐอเมริกาอย่างน้อยสองรายการเกี่ยวกับ ดูgailly.net/05533051.html

— Quuxplusone

5

เอนโทรปีได้อย่างมีประสิทธิภาพขอบเขตของการบีบอัด lossless ที่แข็งแกร่งที่สุดที่เป็นไปได้ ดังนั้นจึงไม่มีอัลกอริทึมที่สามารถบีบอัดชุดข้อมูลแบบสุ่มได้มากกว่า 50% เสมอ

— J.-E. หมุด
แหล่งที่มา

8

ไม่มีแม้แต่อัลกอริทึมที่สามารถบีบอัดชุดข้อมูลแบบสุ่มได้มากกว่า 0.0000001% เสมอ

— David Richerby

1

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

— SkipBerne
แหล่งที่มา

2

s

$s$

s

$s$

s

$s$

1

@DavidRicherby จากนั้นการบีบอัดสตริงว่างของคุณจะสร้างชุดข้อมูลที่ใหญ่กว่าตามที่อ้างสิทธิ์โดย SkipBerne แต่ถึงกระนั้นผมคิดว่าคำตอบของเขาควรชี้แจงว่าเขาหมายเกี่ยวกับการส่งออก recompressing ก่อนหน้านี้โดยใช้วิธีเดียวกัน

— Ángel

2

@ Ángelการอ้างสิทธิ์ของ SkipBerne คือมีสตริงที่ไม่สามารถบีบอัดโดยอัลกอริทึมใด ๆ (" ความพยายามใด ๆในการบีบอัดจากจุดนั้นไปข้างหน้า" ผมขอเน้น) นั่นไม่ถูกต้องสำหรับเหตุผลที่ฉันให้: สำหรับทุก ๆ สตริงมีอัลกอริทึมที่บีบอัดสตริงนั้น

— David Richerby

วิธีที่ฉันตีความมัน SkipBerne อ้างว่าสำหรับอัลกอริทึมการบีบอัดทุกครั้งจะมีสตริงที่ไม่สามารถ compresed ได้ อันไหนจริง. สตริงที่ไม่สามารถบีบอัดนั้นจะแตกต่างกันไปสำหรับอัลกอริธึมที่แตกต่างกันแน่นอน

— Jose Antonio Reinstate Monica

@DavidRicherby คุณใส่จำนวนตัวระบุผิด - มันชัดเจนพอสมควรที่ SkipBerne เขียนว่า (สำหรับวิธีการบีบอัดใด ๆ มีจุดหลังจากที่ไม่มีการบีบอัด) ไม่ใช่ว่า (มีจุดหลังจากที่วิธีการบีบอัดใด ๆ มี ไม่มีการบีบอัด) คำตอบนี้ถูกต้องตามข้อเท็จจริง แต่ไม่ได้เพิ่มคำตอบเก่า ๆ ที่ดีกว่า

— Gilles 'หยุดความชั่วร้าย' ใน