บางคนพูดว่าต่อไปนี้:
ใครก็ตามที่พยายามสร้างตัวเลขสุ่มด้วยวิธีการที่กำหนดขึ้นมาแน่นอนว่าอยู่ในสภาพบาป
นั่นหมายความว่าคุณไม่สามารถสร้างตัวเลขสุ่มจริงด้วยคอมพิวเตอร์ได้ และเขาบอกว่าเมื่อคอมพิวเตอร์มีขนาดเท่ากับไมโครโปรเซสเซอร์ Intel 8080 (ประมาณ 6,000 วาล์ว) คอมพิวเตอร์มีความซับซ้อนมากขึ้นและฉันเชื่อว่าคำสั่งของ von Von Neumann อาจไม่เป็นจริงอีกต่อไป พิจารณาว่าอัลกอริทึมที่ใช้งานซอฟต์แวร์เท่านั้นเป็นไปไม่ได้ พวกเขาทำงานบนฮาร์ดแวร์ทางกายภาพ เครื่องกำเนิดเลขสุ่มที่แท้จริงและแหล่งข้อมูลเอนโทรปีของพวกเขายังทำจากฮาร์ดแวร์
ส่วนของ Java นี้ใส่ลงในลูป:
file.writeByte((byte) (System.nanoTime() & 0xff));
สามารถสร้างไฟล์ข้อมูลที่ฉันแสดงเป็นภาพ:
คุณสามารถเห็นโครงสร้าง แต่มีการสุ่มมากมายเช่นกัน สิ่งที่น่าสนใจคือไฟล์ PNG นี้มีขนาด 232KB แต่มีพิกเซลสีเทาขนาด 250,000 พิกเซล ระดับการบีบอัด PNG สูงสุด นั่นเป็นเพียงอัตราส่วนการอัด 7% คือ ไม่สามารถบีบอัดได้ สิ่งที่น่าสนใจก็คือไฟล์นั้นมีเอกลักษณ์ ทุกรุ่นของไฟล์นี้มีรูปแบบที่แตกต่างกันเล็กน้อยและมีความสามารถในการบีบอัดประมาณ 7% ฉันเน้นสิ่งนี้ตามที่สำคัญต่อการโต้แย้งของฉัน นั่นคือเอนโทรปี ~ 7bits / byte ที่จะลดลงแน่นอนเมื่อใช้อัลกอริทึมการบีบอัดที่แข็งแกร่ง แต่ไม่ลดสิ่งที่อยู่ใกล้ 0 bits / byte ความประทับใจที่ดีขึ้นสามารถทำได้โดยการใช้ภาพด้านบนและแทนที่แผนที่สีสำหรับการสุ่ม: -
โครงสร้างส่วนใหญ่ (ในครึ่งบน) หายไปเนื่องจากเป็นเพียงลำดับของค่าที่คล้ายกัน แต่แตกต่างกันเล็กน้อย นี่เป็นแหล่งข้อมูลเอนโทรปีที่แท้จริงที่สร้างขึ้นโดยเพียงแค่รันโปรแกรม Java บนระบบปฏิบัติการหลายตัวหรือไม่? ไม่ใช่ตัวสร้างตัวเลขสุ่มแบบกระจาย แต่แหล่งเอนโทรปีสำหรับเครื่องหนึ่ง? แหล่งข้อมูลเอนโทรปีที่สร้างขึ้นของซอฟต์แวร์ที่ทำงานบนฮาร์ดแวร์ทางกายภาพที่เพิ่งเกิดขึ้นเป็นพีซี
เพิ่มเติม
เพื่อยืนยันว่าทุกภาพสร้างเอนโทรปีที่สดใหม่โดยไม่มีรูปแบบคงที่เหมือนกันกับภาพทั้งหมด 10 ภาพที่ถูกสร้างขึ้น เหล่านี้ถูกต่อกันและบีบอัดด้วยผู้จัดเก็บที่แข็งแกร่งที่สุดที่ฉันสามารถรวบรวมได้ (paq8px) กระบวนการนี้จะกำจัดข้อมูลทั่วไปทั้งหมดรวมถึงความสัมพันธ์อัตโนมัติเหลือไว้เฉพาะการเปลี่ยนแปลง / เอนโทรปี
เสริม 2
มีความคิดเห็นเชิงลบที่ว่าเอนโทรปีของฉันโดยวิธีการทดสอบการบีบอัดนั้นมีข้อบกพร่อง ดังนั้นผมจึงได้ตอนนี้เรียกใช้แฟ้มตัดแบ่งแม้ว่าการทดสอบการประเมิน NIST อย่างเป็นทางการของการเข้ารหัสลับเอนโทรปีSP800-90B_EntropyAssessment สิ่งนี้ดีพอสำหรับการวัดเอนโทรปีของ IID ที่ไม่ได้รับ นี่คือรายงาน (ขออภัยคำถามนี้ยาวขึ้น แต่ปัญหาซับซ้อน): -
Running non-IID tests...
Entropic statistic estimates:
Most Common Value Estimate = 7.88411
Collision Test Estimate = 6.44961
Markov Test Estimate = 5.61735
Compression Test Estimate = 6.65691
t-Tuple Test Estimate = 7.40114
Longest Reapeated Substring Test Estimate = 8.00305
Predictor estimates:
Multi Most Common in Window (MultiMCW) Test: 100% complete
Correct: 3816
P_avg (global): 0.00397508
P_run (local): 0.00216675
Multi Most Common in Window (Multi MCW) Test = 7.9748
Lag
Test: 100% complete
Correct: 3974
P_avg (global): 0.00413607
P_run (local): 0.00216675
Lag Prediction Test = 7.91752
MultiMMC Test: 100% complete
Correct: 3913
P_avg (global): 0.00407383
P_run (local): 0.00216675
Multi Markov Model with Counting (MultiMMC) Prediction Test = 7.9394
LZ78Y Test: 99% complete
Correct: 3866
P_avg (global): 0.00402593
P_run (local): 0.00216675
LZ78Y Prediction Test = 7.95646
Min Entropy: 5.61735
ผลก็คือ NIST เชื่อว่าฉันได้สร้างเอนโทรปี 5.6 บิต / ไบต์ การประมาณการบีบอัด DIY ของฉันทำให้ค่านี้อยู่ที่ 5.3 บิต / ไบต์
-> หลักฐานดูเหมือนสนับสนุนแนวคิดที่ว่าคอมพิวเตอร์ที่เพิ่งใช้ซอฟต์แวร์สามารถสร้างเอนโทรปีของจริงได้ และฟอนนอยมันน์นั้นผิด (แต่อาจถูกต้องสำหรับเวลาของเขา)
ฉันเสนอข้อมูลอ้างอิงต่อไปนี้ที่อาจสนับสนุนข้อเรียกร้องของฉัน: -
มีแบบจำลองสโตแคสติกใดที่ไม่ใช่ระดับที่กำหนดในอัตราการดำเนินการของโปรแกรมหรือไม่?
การวิเคราะห์ WCET ของระบบฮาร์ดเรียลไทม์ที่น่าจะเป็น
มีอัลกอริธึมซอฟต์แวร์ที่สามารถสร้างรูปแบบความโกลาหลที่ไม่สามารถกำหนดได้หรือไม่? และความเกี่ยวข้องของผลกระทบที่วุ่นวาย
สอดคล้องกับหลักการความไม่แน่นอนเชิงปริมาณของควอนตัม
รายการบล็อกของ Aleksey Shipilёv เกี่ยวกับพฤติกรรมที่วุ่นวายของ nanoTime () แผนการกระจายของเขาไม่ได้แตกต่างไปจากของฉัน
System.nanoTime()
จะไม่รวมอัลกอริทึมที่โทร