สิ่งที่เรารู้ก็คือπนั้นไม่มีที่สิ้นสุดและมีแนวโน้มว่ามันจะมีสตริงจำนวน จำกัด ทุกตัวที่เป็นไปได้ ( ลำดับที่แยกออก )

ฉันได้เห็นต้นแบบของπfsซึ่งสมมติว่าทุกไฟล์ที่คุณสร้าง (หรือใคร ๆ ) หรือคุณจะสร้างมันมีอยู่แล้วดังนั้นมันจึงเป็นเรื่องของการแตกไฟล์ นอกจากนี้ยังมีpiFileซึ่งสามารถแปลงไฟล์ของคุณเป็น pi metadata

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

จากคำถามข้างต้นคำถามหลักของฉันคือ:

• มีอัลกอริธึมการบีบอัดใด ๆ ที่อิงกับ PI หรือไม่

ถ้าไม่มันทำให้รู้สึก? หรือมีงานวิจัยในบริเวณนั้นบ้าง?

หรือบางทีπไม่ใช่สิ่งที่ถูกต้องดังนั้นค่าคงที่ของออยเลอร์หรือTau (τ) ล่ะ? มันจะสร้างความแตกต่างหรือไม่?

^{เครดิตภาพ: ไดโนเสาร์การ์ตูน}

ดูสิ่งนี้ด้วย:

• สตริงบิต จำกัด ใด ๆ สามารถพบได้ใน pi ภายในระยะเวลาที่เหมาะสมหรือไม่? ที่ดังนั้น
• จะไม่จัดเก็บดัชนีไว้ในπจะใหญ่ (หรือใหญ่กว่า) กว่าข้อมูลดั้งเดิมหรือไม่ ที่ GitHub

ข้อเสนอแนะของคุณไม่สมเหตุสมผลนักด้วยเหตุผลหลายประการ ก่อนอื่นเมื่อพยายามบีบอัดไฟล์ขนาดใหญ่ให้พูดไฟล์ขนาดไบต์คุณจะต้องค้นหาสถานที่ในการขยายแบบไบนารีของที่เห็นด้วยกับไฟล์ของคุณ เนื่องจากไฟล์มีความยาวบิตเราจึงคาดว่าสถานที่แห่งนี้จะมีขนาดประมาณบิต ดังนั้นจึงค่อนข้างหายาก สิ่งนี้ไม่เพียงเพราะเราต้องขยายไปมาก แต่เนื่องจากเราคาดว่าจะลองสถานที่ต่างกันก่อนที่จะพบการโจมตีπ 128 2 128 2 $16$$\pi$$128$$2^{128}$$2^{128}$

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

การเปลี่ยนด้วยหมายเลขอื่นจะไม่เปลี่ยนรูปภาพ อัลกอริทึมนั้นเจาะจงเกินไปบีบอัดเฉพาะสตริงที่เราไม่สนใจจริงๆ และไม่มีประสิทธิภาพในขั้นตอนการบีบอัด$\pi$

ขึ้นอยู่กับคำตอบของ Yuval พร้อมคำอธิบายที่แตกต่างกันเล็กน้อยและตัวอย่างเพื่อช่วยส่องสว่างปัญหา

ทฤษฎี

ใช้ไฟล์ขนาดไบต์ (บิต) อัลกอริทึมการบีบอัดมีดังนี้:$16$$128$

1. กำหนดว่าส่วนขยายแบบไบนารีของตรงกับเนื้อหาใด$\pi$
2. เก็บออฟเซ็ตและจำนวนบิตที่มีลำดับ ( )$128$

ชดเชยสำหรับเนื้อหาของแฟ้มที่ควรจะเป็นรอบ ^THบิต อย่างไรก็ตามต้องใช้เวลานานในการค้นหาออฟเซ็ตเนื่องจากต้องการ:$2^{128}$

• การค้นหารูปแบบบิตอย่างละเอียด และ
• ดูที่สถานที่ต่างกัน (โดยเฉลี่ย)$2^{128}$

การจับคู่ที่เกิดขึ้นเร็วพอในเพื่อให้ได้การบีบอัดที่สำคัญจะไม่แปรผัน นั่นคือมันเป็นไปไม่ได้ที่จะใช้เพื่อบีบอัดข้อมูลที่น่าสนใจและในโลกแห่งความจริงเพราะสตริงคำจริงไม่น่าจะเกิดขึ้นเร็ว$\pi$$\pi$

ดูยังเอนโทรปีของข้อมูล

ตัวอย่าง

Let 's ลูกประคบหมายเลขประกันสังคม (SSN): 938-933-556 คำนวณจำนวนบิตเพื่อเข้ารหัสค่านั้นโดยใช้ซึ่งเป็น ~และต้องปัดเศษเป็น (เป็นบิตแยกไม่ออก)29.8 $log_2(938933556)$$29.8$$30$

ในที่ SSN เริ่มต้นที่ชดเชยที่ต้องการบิตหรือ ~และยังต้องมีการปัดเศษ30อาจมีออฟเซ็ตก่อนหน้า แต่ไม่น่าจะต้องการบิตที่น้อยลงอย่างมีนัยสำคัญ597 , 507 , 393 l o g 2 ( 597507393 ) 29.2 $\pi$$597,507,393$$log_2(597507393)$$29.2$$30$

บางทีเราอาจจะรู้จำนวน

• 938 , ชดเชย , 11 บิต$1,124$
• 933ชดเชย , 11 บิต$1,216$
• 556 , offset , 14 bits$11,727$

นั่นคือบิตผลลัพธ์ที่แย่ยิ่งกว่าเดิม อาจจะแตกต่างกันอย่างไร$36$

• 9,389,335ชดเชย , 24 บิต$15,312,393$
• 6 , ชดเชย , 3 บิต$8$

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

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

มีอัลกอริธึมการบีบอัดใด ๆ ที่อิงกับ PI หรือไม่

ใช่https://github.com/divinity76/pi_compression

มันสมเหตุสมผลไหม

ไม่, การจัดเก็บ offsets โดยทั่วไปจะใช้พื้นที่ดิสก์มากกว่าที่คุณบันทึก, อย่างน้อยด้วยการใช้งานด้านบน (3 สิ่งที่น่าสังเกตเกี่ยวกับมันที่สามารถปรับปรุงได้, แต่มันจะพิจารณาเฉพาะ 2 ^ 32 ไบต์แรกของการแทนเลขฐานสองของ pi, และ ใช้จำนวนบิตที่มากเกินไปเพื่อเก็บจำนวนการจับคู่ไบต์ต่อออฟเซ็ตคือ 8 บิตในขณะที่การทดสอบแสดงให้เห็นว่า 3 บิตจะเหมาะสมที่สุดและพิจารณาเฉพาะการจับคู่แบบเต็มไบต์เท่านั้นดังนั้นหากมี 15 บิตที่ตรง ให้ถือว่าเป็นการจับคู่แบบ 8 บิตเท่านั้น .. และหากบิตสุดท้ายของการแข่งขันไบต์ แต่ไม่ใช่บิต # 3 และบิตแรกของการแข่งขันไบต์ถัดไป 4 บิตแรก แต่ไม่ใช่บิต # 5 จะไม่ถือว่าเป็นการจับคู่ที่ ทั้งหมด)

หรือมีงานวิจัยในบริเวณนั้นบ้าง?

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

แม้ว่าการบีบอัดจะเร็วมาก

มีอัลกอริธึมการบีบอัดใด ๆ ที่อิงกับ PI หรือไม่

$\pi$$\pi$

$X$$\pi$$X$

$\pi$$\pi$

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

ดูเพิ่มเติม / คอนทราสต์ / พยายามที่จะกระทบยอดกับคำถามที่ลงคะแนนสูงที่คล้ายกันว่าจะสามารถตัดสินใจได้อย่างไรว่า pi มีลำดับของตัวเลขบางส่วนหรือไม่ (cs.se) (คำใบ้: ชื่อนั้นถือได้ว่าเป็นการทำให้เข้าใจผิดบ้าง)