การอ้างความผิดบาปของ von Neumann ไม่สามารถใช้ได้อีกต่อไป?


25

บางคนพูดว่าต่อไปนี้:

ใครก็ตามที่พยายามสร้างตัวเลขสุ่มด้วยวิธีการที่กำหนดขึ้นมาแน่นอนว่าอยู่ในสภาพบาป

นั่นหมายความว่าคุณไม่สามารถสร้างตัวเลขสุ่มจริงด้วยคอมพิวเตอร์ได้ และเขาบอกว่าเมื่อคอมพิวเตอร์มีขนาดเท่ากับไมโครโปรเซสเซอร์ Intel 8080 (ประมาณ 6,000 วาล์ว) คอมพิวเตอร์มีความซับซ้อนมากขึ้นและฉันเชื่อว่าคำสั่งของ von Von Neumann อาจไม่เป็นจริงอีกต่อไป พิจารณาว่าอัลกอริทึมที่ใช้งานซอฟต์แวร์เท่านั้นเป็นไปไม่ได้ พวกเขาทำงานบนฮาร์ดแวร์ทางกายภาพ เครื่องกำเนิดเลขสุ่มที่แท้จริงและแหล่งข้อมูลเอนโทรปีของพวกเขายังทำจากฮาร์ดแวร์

ส่วนของ Java นี้ใส่ลงในลูป:

      file.writeByte((byte) (System.nanoTime() & 0xff));

สามารถสร้างไฟล์ข้อมูลที่ฉันแสดงเป็นภาพ:

nanoimage

คุณสามารถเห็นโครงสร้าง แต่มีการสุ่มมากมายเช่นกัน สิ่งที่น่าสนใจคือไฟล์ PNG นี้มีขนาด 232KB แต่มีพิกเซลสีเทาขนาด 250,000 พิกเซล ระดับการบีบอัด PNG สูงสุด นั่นเป็นเพียงอัตราส่วนการอัด 7% คือ ไม่สามารถบีบอัดได้ สิ่งที่น่าสนใจก็คือไฟล์นั้นมีเอกลักษณ์ ทุกรุ่นของไฟล์นี้มีรูปแบบที่แตกต่างกันเล็กน้อยและมีความสามารถในการบีบอัดประมาณ 7% ฉันเน้นสิ่งนี้ตามที่สำคัญต่อการโต้แย้งของฉัน นั่นคือเอนโทรปี ~ 7bits / byte ที่จะลดลงแน่นอนเมื่อใช้อัลกอริทึมการบีบอัดที่แข็งแกร่ง แต่ไม่ลดสิ่งที่อยู่ใกล้ 0 bits / byte ความประทับใจที่ดีขึ้นสามารถทำได้โดยการใช้ภาพด้านบนและแทนที่แผนที่สีสำหรับการสุ่ม: -

nanoimage แบบสุ่ม

โครงสร้างส่วนใหญ่ (ในครึ่งบน) หายไปเนื่องจากเป็นเพียงลำดับของค่าที่คล้ายกัน แต่แตกต่างกันเล็กน้อย นี่เป็นแหล่งข้อมูลเอนโทรปีที่แท้จริงที่สร้างขึ้นโดยเพียงแค่รันโปรแกรม 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 () แผนการกระจายของเขาไม่ได้แตกต่างไปจากของฉัน


47
ฉันคิดว่าคุณเข้าใจผิดว่า "ฉันไม่เห็นรูปแบบ" / การสุ่มทุกวันด้วยการสุ่มทางคณิตศาสตร์ / การสุ่มสุ่ม
Raphael

3
@ ราฟาเอลฉันทำไม่ได้ อัลกอริทึมการบีบอัดทางคณิตศาสตร์ทำ และระบบปฏิบัติการแบบเรียลไทม์คืออะไรหากซอฟต์แวร์ทั้งหมดถูกกำหนดไว้เสมอ ฉันแค่ถามเกี่ยวกับการกำหนดในแง่ของบิต
พอล Uszak

16
คุณกำลังทำให้ "ในคอมพิวเตอร์" และ "ด้วยวิธีการกำหนด"
user253751

24
ปัญหาพื้นฐานของคุณคือคุณเริ่มต้นจาก“ ฉันไม่เข้าใจว่ารูปแบบนี้ถูกสร้างขึ้นมาอย่างไร” และสรุป“ ไม่มีใครสามารถเข้าใจว่ารูปแบบนี้ถูกสร้างขึ้นมาได้อย่างไร” สิ่งนี้ไม่ถูกต้องและทำให้โปรไฟล์ SE ของคุณคุณคุ้นเคยกับการเข้ารหัสเพื่อรู้ว่ามันไม่ได้ติดตาม มันง่ายที่จะสร้างระบบที่คุณไม่สามารถทำลายได้ แต่ความท้าทายที่แท้จริงคือการสร้างระบบที่คนอื่นไม่สามารถทำลายได้เช่นกัน
Gilles 'ดังนั้นหยุดความชั่วร้าย'

4
ผมคิดว่าคำจำกัดความมากที่สุดของ "กำหนด" System.nanoTime()จะไม่รวมอัลกอริทึมที่โทร
bmm6o

คำตอบ:


75

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

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

มีมีเหตุผลที่จะคิดว่าเราอาจจะได้รับปริมาณของการสุ่มบางโดยการใช้ประโยชน์กระวนกระวายใจนาฬิกาและดริฟท์ระหว่างสองนาฬิกาฮาร์ดแวร์แต่มันเป็นเรื่องที่ละเอียดอ่อนและยุ่งยากดังนั้นคุณจะต้องระมัดระวัง ฉันจะไม่แนะนำให้พยายามใช้ของคุณเอง แต่ฉันขอแนะนำให้คุณใช้แหล่งข้อมูลเอนโทรปีคุณภาพสูง (โดยปกติจะใช้ในระบบปฏิบัติการที่ทันสมัยที่สุด) สำหรับรายละเอียดเพิ่มเติมโปรดดูWikipedia , hasgedและ/crypto//q/48302/351 (ซึ่งดูเหมือนว่าคุณรู้อยู่แล้ว)

สุดท้ายความคิดเห็นที่ที่เปิดของคุณ:

"ทุกคนที่พยายามสร้างตัวเลขสุ่มโดยวิธีการกำหนดแน่นอนคือการใช้ชีวิตอยู่ในสภาพบาป"

นั่นหมายความว่าคุณไม่สามารถสร้างตัวเลขสุ่มจริงด้วยคอมพิวเตอร์ได้

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


6
หากต้องการขยายจุดบีบอัดอัลกอริธึม PNG เช่นเดียวกับอัลกอริธึมการบีบอัดส่วนใหญ่จะค้นหารูปแบบในข้อมูล อัลกอริทึมที่มองหา patters ในการเปลี่ยนแปลงข้อมูลมีแนวโน้มที่จะบีบอัดภาพตัวอย่างค่อนข้างดี
มาร์ค

1
@ Mark - จริง, PNG ไม่วิเคราะห์รูปแบบการเปลี่ยนแปลง (มันใช้การบีบอัดยุบนำไปใช้กับความแตกต่างระหว่างค่าพิกเซลจริงและการส่งออกของหนึ่งในจำนวนของการวิเคราะห์พฤติกรรมการคาดการณ์ว่าจะขึ้นอยู่กับประเภทของการเปลี่ยนแปลงที่เห็นอยู่ในภาพนี้) อย่างไรก็ตามการวิเคราะห์นั้นค่อนข้างเรียบง่ายเพราะมันถูกออกแบบมาเพื่อให้สามารถทำงานได้อย่างมีประสิทธิภาพบนอุปกรณ์ฝังตัวในช่วง 90s คำถามที่น่าสนใจมากขึ้นก็คือความแม่นยำของอัลกอริธึมการบีบอัดแบบ lossy เช่นความผิดพลาด RMS ของ JPEG หรือการบีบอัดเศษส่วนบางชนิดที่นำไปใช้กับภาพคืออะไร
Jules

3
@Jules: สิ่งที่สำคัญไม่ใช่ PNG นั้นง่าย แต่มันถูกออกแบบมาเพื่อบีบอัดรูปแบบที่น่าจะปรากฏในรูปภาพหลายรูปแบบ หากมีการถ่ายภาพทั่วไปเช่น 123x234 พิกเซลและเปลี่ยนเป็น 234x123 ในขณะที่รักษาพิกเซลในลำดับเดียวกัน (ดังนั้นแถวแรกของรูปภาพใหม่มี 123 พิกเซลจากแถวบนสุดของเก่าบวก 111 พิกเซลของ แถวที่สองแถวถัดไปของรูปภาพใหม่ประกอบด้วย 12 พิกเซลสุดท้ายของแถวที่สองเดิมแถวที่สามที่เป็นต้นฉบับทั้งหมดและ 99 แห่งที่สี่เป็นต้น PNG จะ ...
supercat

1
... น่าจะไม่บีบอัดภาพที่ได้เกือบเหมือนภาพต้นฉบับเนื่องจากจะไม่มีความสัมพันธ์พิเศษระหว่างแถวอีกต่อไปแม้ว่าข้อเท็จจริงที่ว่าภาพที่สองจะมีพิกเซลที่แน่นอนเหมือนกันในลำดับเดียวกันอย่างแน่นอน เป็นครั้งแรก
supercat

100

หากคุณกำลังใช้แหล่งฮาร์ดแวร์ของเอนโทรปี / การสุ่มคุณไม่ได้ "พยายามสร้างการสุ่มโดยวิธีที่กำหนด " (ความสำคัญของฉัน) หากคุณไม่ได้ใช้แหล่งฮาร์ดแวร์ใด ๆ ของเอนโทรปี / การสุ่มคอมพิวเตอร์ที่ทรงพลังยิ่งกว่านั้นก็หมายความว่าคุณสามารถทำบาปได้มากขึ้นต่อวินาที


ความคิดเห็นไม่ได้มีไว้สำหรับการอภิปรายเพิ่มเติม การสนทนานี้ได้รับการย้ายไปแชท
DW

20

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

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

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


เมื่อไตร่ตรอง (ไม่ใช่ประเภท Java) ฉันไม่แน่ใจว่าจำเป็นต้องใช้ nanoTime () นี่เป็นเพียงนาฬิกาจับเวลา ersatz เพื่อติดตามความคืบหน้าของวงรอบตัวมัน หากลบ nanoTime () ออกไปฉันเชื่อว่าอัตราการดำเนินการของลูปเอง (โดยไม่ต้องเรียกใช้ฮาร์ดแวร์โดยตรง) ก็จะไม่ถูกกำหนดว่าเป็นซอฟต์แวร์ที่ยังคงโต้ตอบกับสภาพแวดล้อมของคอมพิวเตอร์ นี่คือพื้นฐานของการเขียนโปรแกรมแบบเรียลไทม์บนชุดอุปกรณ์ฝังตัว ฉันค่อนข้างมั่นใจว่าคำพูดของ von Neumann ไม่สามารถใช้กับคอมพิวเตอร์สมัยใหม่ได้อีกต่อไป
พอล Uszak

1
@PaulUszak ฉันต้องพูดเรื่องนี้กี่ครั้ง? Von Neumann กล่าวว่าคุณไม่สามารถสร้างตัวเลขสุ่มได้อย่างแน่นอน คุณพูดอยู่เสมอว่า Von Neumann ผิดเพราะคุณสามารถใช้ลัทธิ nondeterminism มันเหมือนกับว่าคุณอ้างสิทธิ์ซ้ำ ๆ ว่าคำแถลง“ ใช้เวลานานมากในการเดินจากปารีสไปเบอร์ลิน” ไม่ได้ใช้ในโลกสมัยใหม่เพราะคุณสามารถบินระหว่างสองเมืองเหล่านี้ได้ แล้วอะไรล่ะ คำพูดเกี่ยวกับการเดินและยังคงใช้เวลานาน คำกล่าวของ Von Neumann เป็นเรื่องเกี่ยวกับระบบที่กำหนดขึ้นและพวกเขาก็ยังไม่สามารถทำงานแบบสุ่มได้
David Richerby

1
@PaulUszak มันเป็นไปไม่ได้จริงๆ หากคุณคิดว่าคุณมีอัลกอริธึมที่กำหนดขึ้นซึ่งพฤติกรรมไม่ได้ถูกกำหนดโดยอินพุตมันเป็นเพียงเรื่องของการระบุว่ามีการแนะนำเอนโทรปีอย่างไร
bmm6o

18

ใครก็ตามที่พยายามสร้างตัวเลขสุ่มด้วยวิธีการที่กำหนดขึ้นมาแน่นอนว่าอยู่ในสภาพบาป

เมื่อคุณตีความว่า "การมีชีวิตอยู่ในสภาพบาป" เป็นการ "ทำเรื่องไร้สาระ" มากกว่าที่คิดไว้อย่างสมบูรณ์

สิ่งที่คุณทำคือการใช้วิธีการที่ค่อนข้างช้าในการSystem.nanoTime()สร้างแบบแผนที่ค่อนข้างอ่อนแอ คุณวัดบางส่วน

... อัตราเอนโทรปี ~ 5.3 บิต / ไบต์ ...

แต่นี่เป็นแค่ขอบเขตบน สิ่งที่คุณจะได้รับก็คือขอบเขตบน เอนโทรปีที่แท้จริงอาจมีขนาดเล็กกว่า

ลองแทนการเติมอาร์เรย์โดยใช้แฮชการเข้ารหัสลับเช่น MD5 คำนวณลำดับเช่นmd5(0), md5(1), ...(จากแต่ละค่าใช้เวลาหนึ่งไบต์ขึ้นไปสิ่งนี้ไม่สำคัญ) คุณจะไม่ได้รับการบีบอัดเลย (ใช่ MD5 นั้นใช้งานไม่ได้ แต่ก็ยังดีพอที่จะสร้างข้อมูลที่ไม่สามารถบีบอัดได้)

เราสามารถพูดได้ว่าไม่มีเอนโทรปี แต่คุณต้องวัด 8 บิต / ไบต์

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

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

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


4
@PaulUszak แน่นอนว่า PRNG ที่กำหนดขึ้นไม่สามารถใช้เป็น OTP ได้ แต่ OTP เป็นกรณีพิเศษมากเนื่องจากนิยามต้องใช้คีย์สุ่มอย่างแท้จริง AFAIK สำหรับสิ่งอื่นใดพอเพียง PRNG ที่ปลอดภัยแบบสุ่มที่ได้รับการหว่านเมล็ด (เมล็ดต้องมีเอนโทรปี 128 หรือ 256 บิตขึ้นอยู่กับระดับความปลอดภัยที่ต้องการ)
maaartinus

3
"เมื่อคุณต้องการบางสิ่งบางอย่างสุ่ม" →โดยทั่วไปคุณไม่จำเป็นต้องมีการสุ่มอย่างแท้จริง แต่คุณต้องการขาดความสัมพันธ์ การสุ่มตัวอย่างที่แท้จริงคือการรับประกันที่แข็งแกร่ง แต่โดยทั่วไปทุกกรณีก็พอใจเช่นกันโดย CSPRNG ที่ทันสมัยและเมล็ดที่ไม่สามารถคาดเดาได้
Veedrac

3
@ maaartinus คุณไม่ได้รับฉัน ฉันกำลังบอกว่าคุณไม่จำเป็นต้องมีเมล็ดพันธุ์สุ่มจริง ๆ คุณแค่ต้องการเมล็ดที่ไม่เกี่ยวข้องที่ไม่สามารถคาดเดาได้
Veedrac

6
ตัวอย่างเช่นฉันสร้างไฟล์ข้อความที่มีตัวเลขเรียงต่อกัน 1 ล้าน gzipสามารถบีบอัดได้ 63% เท่านั้นแม้ว่าจะไม่มีเอนโทรปี มันสามารถตรวจจับการทำซ้ำเช่นเดียวกับ999919999299993...
Barmar

6
@PaulUszak นั่นคือประเด็นของฉัน - อัตราส่วนการบีบอัดไม่ได้เป็นตัวบ่งชี้ที่ดีของเอนโทรปีมันแสดงให้เห็นว่าอัลกอริทึมการบีบอัดเฉพาะสามารถตรวจจับชนิดของรูปแบบข้อมูลของคุณได้หรือไม่
Barmar

14

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

ปัญหาหนึ่งที่เกิดจากผลลัพธ์ของกระบวนการสุ่มคือพวกมันยากที่จะแยกแยะความแตกต่างจากผลลัพธ์ของกระบวนการที่กำหนดขึ้นมา: พวกเขาไม่มี "บันทึก" ของการสุ่มของแหล่งที่มา ตัวอย่างสุดขั้วของเรื่องนี้คือการ์ตูน XKCD ที่โด่งดังที่ตัวสร้างตัวเลขสุ่มส่งกลับมาเสมอ4พร้อมด้วยรหัสความคิดเห็นที่อ้างว่าเป็นแบบสุ่มเพราะมันมาจากเกมทอยลูกเต๋า

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

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

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

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

ตอนนี้เราสามารถตอบคำถามของคุณจากมุมมองของความซับซ้อนของ Kolmogorov และเราพบว่าคำพูดนั้นถูกต้อง: เราไม่สามารถสร้างตัวเลขสุ่ม (ความซับซ้อนของ Kolmogorov สูง) โดยวิธีกำหนดขึ้น

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

  • เราสร้างผลผลิตจำนวนมหาศาล อย่างไรก็ตามเนื่องจากเรารู้ว่าผลลัพธ์นี้สร้างขึ้นโดยโปรแกรมขนาดเล็กเอาต์พุต (โดยคำจำกัดความ) มีความซับซ้อนของ Kolmogorov ต่ำดังนั้นจึงไม่ใช่ "สุ่ม" ในแง่นี้
  • เราสร้างตัวเลขจำนวนน้อยที่เขียนลงทั้งหมดจะใช้เวลาประมาณเดียวกันหรือน้อยกว่าบิตกว่าการเขียนโปรแกรมสร้างสั้นของเรา ในกรณีนี้ตัวเลขค่อนข้างไม่สามารถบีบอัดได้ซึ่งบ่งชี้ว่าพวกมันค่อนข้างสุ่มในแง่ Kolmogorov อย่างไรก็ตามเนื่องจากจำนวนเอาต์พุตนั้นเทียบได้กับสิ่งที่เราใส่ (ซอร์สโค้ดสำหรับโปรแกรม) มันยุติธรรมที่จะบอกว่าโปรแกรมไม่ได้ "สร้าง" การสุ่มเราจึงเลือกโปรแกรมนั้น print([...])ท้ายที่สุดแล้วในกรณีนี้โปรแกรมสร้างของเราก็อาจเป็นเพียงรายการของตัวเลขที่แน่นอนเหล่านี้ (เช่น)

ไม่ว่าในกรณีใดเราจะไม่ "สร้าง" การสุ่มมากกว่าที่เราใส่ ("การสุ่ม" ของซอร์สโค้ดของโปรแกรมสร้างของเรา) เราอาจพยายามหลีกเลี่ยงปัญหานี้โดยใช้โปรแกรมที่สร้างนานขึ้นเพื่อหลีกเลี่ยงเอาต์พุตที่มีตัวสร้างสั้น แต่มีเพียงสองวิธีในการทำเช่นนั้น:

  • เป็นระบบ "ขยายตัว" รหัสในบางวิธี อย่างไรก็ตามความซับซ้อนของ Kolmogorov ไม่ได้สนใจโปรแกรมเฉพาะที่เราใช้ในการสร้างข้อมูล: มันให้ความสำคัญกับโปรแกรมสร้างใดก็ตามที่มีขนาดเล็กที่สุด การขยายระบบไม่ได้เพิ่มความซับซ้อนของ Kolmogorov เพราะรูปแบบดังกล่าวในโค้ดสามารถสร้างได้ด้วยรหัสจำนวนน้อยมาก ตัวอย่างเช่นถ้าเราใช้เวลาrun(shortGenerator)และเพิ่มโหลดทั้งระบบขยายตัวที่จะได้รับเครื่องกำเนิดไฟฟ้าในระยะสั้นยังคงมีอยู่ในรูปแบบrun(bloatedGenerator)run(addBloat(shortGenerator))
  • เพิ่มการขยายแบบไม่เป็นระบบคือไม่มีรูปแบบใด ๆ ดังนั้นaddBloatฟังก์ชันจะต้องจบลงด้วยการป่องเหมือนโค้ด อย่างไรก็ตามการไร้รูปแบบเป็นสิ่งที่ทำให้บางสิ่งบางอย่างสุ่ม (ความซับซ้อนสูง Kolmogorov) ดังนั้น bloating โปรแกรมสร้างด้วยวิธีนี้จะเพิ่มการสุ่ม (ความซับซ้อน Kolmogorov) ของการส่งออก แต่ก็ยังเพิ่มจำนวนของการสุ่ม (ความซับซ้อน Kolmogorov) ที่เราต้องให้ในรูปแบบของรหัสที่มา ดังนั้นเรายังคงเป็นผู้ที่ให้บริการ "แบบแผน" และไม่ใช่โปรแกรม ในตัวอย่างด้านบนของการเขียนเพียงอย่างเดียวการprint([...])เพิ่มจำนวน bloat ที่ไม่เป็นระบบนั้นเทียบเท่ากับการเขียนตัวเลข "สุ่ม" จำนวนมากขึ้นในรายการรหัสที่ยาก

"ค้นหาโปรแกรมกำหนดค่าที่สั้นที่สุดซึ่งส่งผลให้ลำดับไบต์เดียวกัน" - นี่คือจุดทั้งหมดของอาร์กิวเมนต์เครื่องหมายอัศเจรีย์ คุณไม่สามารถทำซ้ำภาพนี้ เป็นเอกลักษณ์ทุกครั้ง รูปแบบเป็นผลมาจากการทำงานร่วมกันของ Java, JVM, ระบบปฏิบัติการ, CPU + แคช, ฮาร์ดไดรฟ์, เพลง Trance ฉันถูกสตรีมมิ่งที่ใช้รอบ CPU / RAM และทุกสิ่งในระหว่าง รูปแบบเกิดขึ้นจากโค้ด Java หนึ่งบรรทัดภายในวงวนสำหรับ / ถัดไป ส่วนสำคัญของเอนโทรปีมาจากวงจรฮาร์ดแวร์พื้นฐาน มันไม่สามารถเขียนโค้ดได้
พอล Uszak

@PaulUszak Kolmogorov ความซับซ้อนวัด "แบบสุ่ม" ของค่าเฉพาะเช่นภาพแรกที่คุณโพสต์; หรือภาพที่สองที่คุณโพสต์ หรือสแนปชอตของหน้า HTML นี้; เป็นต้นถ้าคุณสนใจเกี่ยวกับกระบวนการที่สร้างภาพ (กำหนดขึ้นหรือไม่ก็ตาม) มาตรการอื่น ๆ เช่นข้อมูลแชนนอนจะเหมาะสมกว่า ฉันเพิ่งเห็นว่าไม่มีคำตอบอื่น ๆ ที่กล่าวถึงความซับซ้อนของ Kolmogorov ทั้งสองเป็นวิธีที่มีประโยชน์เนื่องจากพวกเขาบอกเราในสิ่งที่แตกต่าง
Warbo

@PaulUszak พิจารณาการทดสอบที่คุณทำโดยการบีบอัดภาพเหล่านี้เป็นไฟล์ PNG และเปรียบเทียบขนาดไฟล์ เมื่อคุณคลายบีบอัด PNG คุณจะได้รับภาพที่เหมือนกันเริ่มต้นด้วย มันกำหนดไว้ คุณจะไม่ได้ภาพที่แตกต่างและสุ่ม นั่นทำให้การทดสอบการบีบอัดของคุณไร้ประโยชน์หรือไม่? ไม่ใช่เลย! ความซับซ้อนของ Kolmogorov นั้นเหมือนกับการทดสอบ PNG ของคุณในเวอร์ชันที่รุนแรง: แทนที่จะบีบอัดลงในไฟล์ PNG เราจะบีบอัดลงในโปรแกรมคอมพิวเตอร์ (กำหนดขึ้น) ผู้ที่จะได้รับจริงๆขนาดเล็กในขณะที่ยังคงความสามารถในการทำซ้ำข้อมูลทั้งหมดของเดิม
Warbo

6
@PaulUszak จากความคิดเห็นของคุณดูเหมือนว่าคุณได้ตระหนักถึงทุกสิ่งที่จำเป็นในการพิสูจน์คำพูดแล้ว: คุณไม่ได้ใช้วิธีการกำหนดรูปแบบเพื่อกำหนดรูปแบบเพราะคุณพึ่งพาเอนโทรปีที่คุณหรือโลกภายนอก (ฮาร์ดแวร์เครือข่ายและเซิร์ฟเวอร์ คุณสตรีมจากเนื้อหาของสตรีม ฯลฯ )ได้แนะนำเข้าสู่ระบบของคุณแล้ว ไม่ว่าการตรวจสอบการวัดเวลาแปดบิตสุดท้ายในหน่วยนาโนวินาทีที่ถ่ายในลูปเป็นวิธีที่ดีในการเก็บเกี่ยวเอนโทรปีเป็นคำถามที่แยกต่างหากซึ่งมีคำตอบมากมายที่จะวางสาย แต่เป็นหัวข้อแยกต่างหาก
mtraceur

7

การบีบอัดไม่ใช่การทดสอบความถูกต้องของการสุ่มและไม่มีการดูภาพและพูดว่า "ดูสุ่ม"

Randomness มีการทดสอบโดยวิธีเชิงประจักษ์ ที่มีอยู่ในห้องสวีทที่ความเป็นจริงของซอฟต์แวร์ที่ออกแบบมาเป็นพิเศษ / อัลกอริทึมสำหรับการทดสอบแบบแผนเช่นTestU01และทดสอบมิจฉาทิฐิ

นอกจากนี้ในความเป็นจริงแล้วภาพของคุณคือสตริงจำนวน 1D ที่แมปลงในช่องว่างดังนั้นจึงไม่ใช่รูปแบบที่แน่นอนที่สามารถปรากฏได้

หากคุณต้องตรวจสอบพิกเซลภาพของคุณเป็นไปได้ว่าคุณจะพบกับรูปแบบสั้น ๆ ของการเพิ่มมูลค่าก่อนที่จะลดลงอย่างกะทันหัน หากคุณต้องสร้างกราฟโดยที่ค่า x เป็นหมายเลขตัวอย่างและค่า y เป็นค่าที่ได้จากฟังก์ชัน 'สุ่ม' คุณมักจะพบว่าข้อมูลของคุณในความเป็นจริงดูเหมือนคลื่นฟันเลื่อย:

ฟันเลื่อยเวฟ

นี่คือรูปแบบที่สร้างขึ้นโดยค่าที่เพิ่มขึ้นภายใต้การคำนวณแบบแยกส่วน (ซึ่งการคำนวณของคุณเป็นตัวอย่างของ: การเพิ่มเวลาในอัตราคงที่ใกล้และการ& 0xFFทำหน้าที่เป็นmod 256)


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

2
@ PaulUszak การวัดนั้นสมเหตุสมผลหรือไม่หากขึ้นอยู่กับอัลกอริธึมการบีบอัด
kutschkem

@kutschkem เราจะเป็นหนึ่งในมาตรการเอนโทรปีมาตรฐานใน NIST SP 800-90B นอกจากนี้ยังง่ายต่อการทำ คุณสามารถวัดเอนโทรปีที่ไม่ใช่ของ IID ได้อย่างไร? และการบีบอัดอัลกอสนั้นเป็นแบบซีมโทติคจนถึงขอบเขตล่างดังนั้นการหารด้วย 2 สูตรแชนนอนไม่ทำงานที่นี่
Paul Uszak

3
@PaulUszak - เพื่อจุดประสงค์ในการเข้ารหัสเราควรสันนิษฐานว่าผู้โจมตีรู้จักวิธีการสร้าง การรู้วิธีการที่ข้อมูลนี้ถูกสร้างขึ้นเกือบจะแน่นอนช่วยให้การเขียนอัลกอริทึมการบีบอัดสำหรับมันที่ดีกว่า PNG หรือวิธีการทดสอบ NIST ใด ๆ ซึ่งทั้งสองไม่คิดอะไรเลย (หรือในกรณีของ PNG ไม่มีอะไรถูกต้องจริง) เกี่ยวกับแหล่งที่มาของข้อมูล
Jules

5

คุณกำลังสับสนแนวคิดของตัวเลขสุ่มจาก "หมายเลขที่ดูเหมือนจะสุ่ม"

เพื่อให้เข้าใจคำพูดของ von Neumann เราต้องเข้าใจความหมายของการ "สร้างตัวเลขสุ่ม" คำตอบของ Warboเชื่อมโยงXKCD ที่ยอดเยี่ยมกับส่วนนี้: การ์ตูน XKCD

เมื่อเราพูดถึงตัวเลขสุ่มเราไม่ได้พูดถึงคุณค่าเหล่านั้น เห็นได้ชัดว่า 4 ไม่สุ่มมากกว่า 3 เรากำลังพูดถึงความสามารถของบุคคลที่สามในการทำนายค่านี้ดีกว่าโอกาสสุ่ม ตัวเลขสุ่มคือตัวเลขที่ไม่สามารถคาดเดาได้ บางครั้งเราจะเพิ่มเงื่อนไขให้กับสิ่งนี้ Cryptographically-secure หลอกตัวเลขสุ่ม (CSPRNG) สร้างตัวเลขที่ไม่สามารถทำนายได้ bettr กว่าสุ่มโอกาสหากผู้โจมตีไม่รู้จักเมล็ด / คีย์ แต่ถ้าเราพูดถึงตัวเลขสุ่มจริง ๆ (ไม่หลอกสุ่ม) มันมักจะกำหนดให้เป็นตัวเลขที่ไม่สามารถคาดเดาได้แม้จะมีความรู้ที่สมบูรณ์ของระบบรวมถึงปุ่มใด ๆ

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

อย่างไรก็ตามคุณจะทราบว่าฉันบอกว่ามันอาจจะเป็น nondeterministic ระวังที่System.nanoTime()ไม่ได้ออกแบบมาเพื่อให้ค่าสำหรับวัตถุประสงค์นี้ มันอาจหรืออาจไม่เพียงพอ nondeterministic แอปพลิเคชันอาจปรับนาฬิการะบบเพื่อให้การโทรSystem.nanoTime()เกิดขึ้นได้หลายครั้งใน 256 วินาที (หรือปิด) หรือคุณอาจทำงานใน Javascript ซึ่งการหาประโยชน์ล่าสุดของSpecterได้นำเบราว์เซอร์หลัก ๆ เพื่อลดความละเอียดของตัวนับ ในกรณีเหล่านี้ "ตัวเลขสุ่ม" ของคุณอาจคาดการณ์ได้สูงในสภาพแวดล้อมที่คุณไม่ได้วางแผน

  • ดังนั้นการสร้างตัวเลขสุ่มด้วยกระบวนการที่กำหนดขึ้น ... บาป
  • การสร้างตัวเลขสุ่มด้วยฮาร์ดแวร์แบบสุ่มโดยเฉพาะ ... ไม่ใช่บาป
  • การสร้างตัวเลขสุ่มด้วยแง่มุมที่ไม่ต่อเนื่องของคอมพิวเตอร์ ... อาจจะเป็นบาป

ทุกอย่างขึ้นอยู่กับสิ่งที่คุณตั้งใจ หากคุณกำลังเข้ารหัสจดหมายรักให้กับฟองน้ำบ๊อบเพื่อให้น้องสาวของคุณไม่สามารถอ่านได้ความต้องการที่อยู่ในหมายเลขสุ่มที่เรียกว่าของคุณนั้นค่อนข้างต่ำ System.nanoTime()ใช้เท่าที่คุณทำอาจจะดีพอ หากคุณกำลังปกป้องความลับทางนิวเคลียร์จากรัฐต่างประเทศขั้นสูงที่กำลังมองหาพวกเขาอย่างแข็งขันคุณอาจต้องการพิจารณาการใช้ฮาร์ดแวร์ที่ออกแบบมาเพื่อรองรับความท้าทาย


4

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

ดังนั้นจึงมีวิธีการกำหนดค่าอยู่เสมอเพื่อทำนายจำนวนเต็มถัดไป นี่คือสิ่งที่เราไม่คาดหวังว่าจะเกิดขึ้นหากเราสุ่มเลือก!

การกำหนดค่าที่ซับซ้อนอย่างเพียงพอใด ๆ นั้นแยกไม่ออกจากการสุ่ม

- จากหน้าผู้ใช้ของ Wrzlprmft

ดังนั้นแม้ว่าบางสิ่งจะดูสุ่มทำไมบนโลกเราถึงทำตัวเป็นแบบ 'สุ่ม' ถ้าเรามีกระบวนการกำหนดขึ้นเพื่อสร้างมันขึ้นมา?

ฉันคิดว่านี่เป็นปัญหาสำคัญ คุณแสดงให้เห็นเพียงบางรูปแบบของความแตกต่างของ PRNG และ 'การสุ่มที่แท้จริง'

อย่างไรก็ตามแนวคิดเหล่านี้จึงไม่เท่ากัน โดยเฉพาะอย่างยิ่งการสุ่มเป็นแนวคิดทางคณิตศาสตร์และทฤษฎี เราได้แสดงให้เห็นแล้วว่าในทางทฤษฎีแล้วการพิจารณาว่า PRNG เป็น 'การสุ่มที่แท้จริง' นำไปสู่ความขัดแย้ง ดังนั้นพวกเขาไม่สามารถเท่าเทียมกัน


1
เอ่อคุณแน่ใจหรือว่าคุณเข้าใจคำพูดนั้น? คุณดูเหมือนจะขัดแย้งกับตัวคุณเอง .. ?
Paul Uszak

ฉัน คุณช่วยอธิบายได้ไหม ฉันตั้งใจจะบอกว่าถ้าคุณต้องการที่จะปฏิบัติต่อสิ่งที่สุ่มสร้างมันอย่างไม่มีจุดหมายแม้ว่าคนอื่นจะไม่เห็นความแตกต่างก็ตาม
จิ้งจกไม่ต่อเนื่อง

2
@ PaulUszak คุณอ้างว่าเพราะมีบางสิ่งที่สุ่มให้กับคุณมันเป็นการสุ่ม แต่ในความเป็นจริงเพียงเพราะสิ่งที่ดูสุ่มไม่ได้หมายความว่ามันสุ่ม - มันอาจเป็นกระบวนการกำหนดที่ซับซ้อนพอสมควร
Gilles 'หยุดความชั่วร้าย'

O(n2)

3

ฉันคิดว่าคนอื่น ๆ ชี้ไปแล้ว แต่มันก็ไม่ได้เน้นไปที่สิ่งนั้นดังนั้นให้ฉันเพิ่มการอภิปรายด้วย

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

นอกจากนี้คุณค่อนข้างเข้าใจผิดความหมายของวลี "บนคอมพิวเตอร์" และ "ไม่แน่นอน" แน่นอนคุณสามารถทำการดำเนินการ nondeterministicบนคอมพิวเตอร์

ยิ่งกว่านั้นในความเป็นจริงคุณเพิ่งทำไปแต่มันก็ไม่ปรากฏชัดเจนในการมองครั้งแรก

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

ตอนนี้ดูอัลกอริทึมของคุณ มันมีพื้นฐานมาจากอะไร? คุณมีสถานะเท่าไหร่ มันกำหนดได้หรือไม่?

  file.writeByte((byte) (System.nanoTime() & 0xff));

ลองเพิกเฉยfile.writeและมีปัญหาของการฟลัชบัฟเฟอร์กำลังรอ I / O (คุณลองเพิ่มสัญญาณรบกวนหนัก ๆ บนสายเคเบิลฮาร์ดไดรฟสักครู่หรือไม่ไม่เฮ้คุณทำได้แล้วเฮ้มันเป็น nondeterministic แล้ว :)) และ มาเน้นแหล่งที่มามันสำคัญกว่ากัน

เวลาเป็นชนิดของรัฐบางส่วน มันแตกต่างกันไป แต่ส่วนใหญ่จะเหมือนกัน นั่นเป็นเหตุผลที่คุณพยายามที่จะหลีกเลี่ยงมันและเอา & 0xFF จะลดลงมากที่สุดของรัฐ แต่คุณยังไม่ได้ลดลงทั้งหมดสถานะการอ่านก่อนหน้านี้บางส่วนอาจรั่วไหลไปยังหน้าถัดไปดังนั้นจึงไม่แน่นอนอย่างเต็มที่ *

แต่เราไม่สนใจเรื่องนั้น หากต้องการ "พิสูจน์" ว่าคำพูดผิด:

ใครก็ตามที่พยายามสร้างตัวเลขสุ่มด้วยวิธีการที่กำหนดขึ้นมาแน่นอนว่าอยู่ในสภาพบาป

คุณต้องพิสูจน์ด้วยวิธีที่กำหนดขึ้นมา
สิ่งที่เราสนใจคือ: อัลโลของคุณเป็นคนกำหนดอย่างแน่นอนหรือไม่?

.. และมันชัดเจนว่ามันไม่ใช่

  System.nanoTime() & 0xff

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

ฉันเห็นด้วยอย่างยิ่งว่าฉันทำให้หนักใจที่นี่ การดริฟท์จะไม่ใหญ่พอที่จะสร้างผลกระทบnanotimeได้มาก ที่สำคัญกว่าnanotimeนั้นหมายถึงความรวดเร็ว มันไม่ได้อ่านจากแหล่งเวลาจริง มันขึ้นอยู่กับการเรียนการสอนภายใน / นับวงจรของโปรเซสเซอร์ หากคุณมั่นใจว่าไม่มีการสลับบริบท

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

*) น่าสนใจคุณอาจเพิ่มการสุ่มที่เกิดขึ้นจริงถ้าคุณไปไม่ยอมใครง่ายๆ ทำ & 0x01 ทีละบิตและรอเธรดเวลาที่สังเกตได้ก่อนที่จะอ่านแต่ละบิต การสร้างข้อมูลด้วยวิธีนั้นจะนานน่าหัวเราะ แต่จริง ๆ แล้วฉันก็เถียงว่ามันอาจจะเป็นการพิจารณาแบบสุ่มจริง ๆ IIF ที่คุณกำลังทำงานบนที่ไม่ใช่ RTOS และ IFF ในแต่ละ 'เวลาที่สังเกตเห็นได้' นั้นสูงพอที่จะมั่นใจได้ว่าพื้นฐาน ระบบปฏิบัติการไปสู่โหมดสลีปหรือเปลี่ยนบริบทเป็นงานอื่น


2
NAS

บางอย่างเช่นนั้นคือจุดของฉันที่อยู่เบื้องหลัง "[คุณ] สามารถสร้างอัลกอริทึม [การบีบอัด] ที่ดีกว่า" ได้มากขึ้น
quetzalcoatl

อย่าได้รับการแก้ไขในค่า 5.3 ที่แน่นอน ไม่ว่าคุณจะสามารถสร้างอัลโกการบีบอัดได้ดีแค่ไหน (คุณไม่สามารถใช้หนึ่งในดีที่สุดในโลก - paq8px) สิ่งที่ยังคงบีบอัดคือเอนโทรปีที่บริสุทธิ์ นั่นเป็นหนึ่งในคำจำกัดความหลักการของการสุ่ม หรือคุณแนะนำว่ามีสิ่งใดที่สามารถบีบอัดเป็นศูนย์ไบต์ได้ คนรักนกพิราบจะไม่เห็นด้วย
Paul Uszak

0xff อยู่ที่นั่นเพราะคุณไม่สามารถสร้าง piccy ที่ดีโดยใช้จำนวนเต็ม 64 บิต และถ้าคุณใช้ 0x01 คุณจะต้องยุ่งกับการจัดการบิตที่ฉันไม่สามารถใส่ใจได้ นั่นคือทั้งหมดที่ เอนโทรปีของ NIST และการวัดของฉันเองแนะนำให้ใช้เอนโทรปีในบิตที่สูงกว่าอยู่ดี (ประมาณ 5 อัน)
Paul Uszak

1
+1, และนี่คือคำตอบที่ดีที่สุดสำหรับฉัน: แหล่งเดียวของเอนโทรปีในสถานการณ์ที่ถูกถามคือความไม่สอดคล้องกันอย่างแม่นยำในเวลาที่ผ่านไประหว่างการอ่านนาฬิกาแต่ละครั้ง ! และมาจากการผสมผสานรายละเอียดต่างๆเช่นวิธีการทำงานของตัวกำหนดเวลาระบบปฏิบัติการและการทำงานของฮาร์ดแวร์และรายละเอียดเช่นสิ่งที่ผู้ใช้ทำกับระบบนั้นจนถึงช่วงเวลานั้นซึ่งจะส่งผลทางอ้อมต่อสิ่งต่างๆเช่นสิ่งที่ต้องการกำหนดเวลา การเข้าถึงเกิดขึ้นเนื่องจากการแตกแฟรกเมนต์เมื่อเวลาผ่านไปหรือสิ่งที่อยู่ใน swap / memory / cache หรือกิจกรรม network / etc ใดที่กำลังดำเนินการอยู่
mtraceur

2

ฉันคิดว่าคำตอบที่คุณต้องการเริ่มต้นด้วยความคิดเห็นนี้ด้วยตัวคุณเองในการตอบคำตอบอื่น:

รูปแบบเป็นผลมาจากการทำงานร่วมกันของ Java, JVM, ระบบปฏิบัติการ, CPU + แคช, ฮาร์ดไดรฟ์, เพลง Trance ฉันถูกสตรีมมิ่งที่ใช้รอบ CPU / RAM และทุกสิ่งในระหว่าง รูปแบบเกิดขึ้นจากโค้ด Java หนึ่งบรรทัดภายในวงวนสำหรับ / ถัดไป ส่วนสำคัญของเอนโทรปีมาจากวงจรฮาร์ดแวร์พื้นฐาน

คุณรู้แล้วฉันคิดว่าคุณไม่ได้ใช้วิธีการที่กำหนดขึ้นเพื่อสร้างรูปแบบ

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

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

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

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


0

หากต้องการเพิ่มคำตอบก่อนหน้านี่เป็นวิธีง่ายๆในการคิดเกี่ยวกับคำถามนี้

มันเป็นเรื่องของความแตกต่างระหว่างการสุ่มและกำหนด เราจะมาที่ฟอนนอยมันน์และสิ่งที่เขาพูดหลังจากนั้น

ตัวเลขสุ่ม

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

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

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

  • เมื่อรวมเข้ากับสิ่งนี้เรายังสามารถเพิ่มบางอย่างที่เราพิจารณาว่า "ไม่เลว" ซึ่งช่วยได้เนื่องจากไม่มีการเชื่อมต่อกับสิ่งเหล่านี้: กำลังรอ mouseclick ถัดไปหรือแพ็คเก็ตเครือข่าย microtime บิตสุดท้ายในการเขียนไฟล์ถัดไป เอาต์พุตของฟังก์ชันตัวสร้างหมายเลขแบบเทียมที่รู้จักกัน แต่น่ารักทางคณิตศาสตร์ เอนโทรปีก่อนหน้านี้จากการใช้ตัวเลขสุ่ม

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

ตัวเลขที่กำหนด

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

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

เราเรียกมันว่า "pseudorandom" เพราะมันดูแล้วดูเหมือนว่าจะสุ่มเป็นหลักแม้ว่ามันจะไม่ใช่ก็ตาม

นี่เป็นตัวอย่างที่ดี คิดเกี่ยวกับลำดับของตัวเลขสุ่ม 3 หลักนี้: 983, 367, 336, 244, 065, 664, 308, 602, 139, 494, 639, 522, 473, 719, 070, 217 สมมติว่าฉันบอกคุณ ฉันสามารถสร้างตัวเลขได้ล้านตัวด้วยวิธีเดียวกัน คุณสามารถส่งต่อไปยังนักสถิติที่จะยืนยัน (พูด) ว่าพวกเขามีการกระจายอย่างเท่าเทียมกันหรือสิ่งที่มันอาจจะเป็น ไม่มี patternb ที่คาดเดาได้ชัดเจน พวกเขาดูสุ่มสวยใช่มั้ย แต่ตอนนี้ฉันบอกคุณว่าพวกเขาเป็นจริง

ตัวเลข 500 หลัก + ของ Pi จัดกลุ่มเป็น 3 วินาที

ทันใดนั้นสุ่มอย่างไรก็ตาม

ตัวเลขของ Pi

อาจเป็นได้ว่าคุณสามารถทำนายได้ทันทีว่าตัวเลข 2 ตัวถัดไปจะเป็น 986 และ 094

เพื่อความชัดเจนฉันไม่รู้ว่าจะสุ่มมันอย่างไร

ตัวเลขของ Pi

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

ในระหว่าง

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

กลับไปที่ฟอนนอยมันน์และคำถามของคุณ

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

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

ตอนนี้เราสามารถเรียบเรียงคำถามของคุณใหม่เช่นนี้: "ผลลัพธ์ของคอมพิวเตอร์ (หรือทันสมัย) ของฉันสามารถดูและทำงานแบบสุ่มโดยสิ้นเชิงนั่นหมายความว่าคำพูดของ von Neumann ล้าสมัยและไม่ถูกต้องหรือไม่"

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

ถ้าคุณบอกว่าวิธีการของคุณจะรวมตัวสร้างการสุ่มฮาร์ดแวร์จริงเพื่อแก้ไข (เช่นตัวเลขสุ่มที่เกิดจากการสลายตัวของกัมมันตภาพรังสีหรือเสียงรบกวนในเซมิคอนดักเตอร์) ตอนนี้คำตอบของคุณอาจจะสุ่ม - แต่วิธีการของคุณ , ได้อย่างแม่นยำเพราะคุณไม่สามารถคาดการณ์เอาท์พุท (หรือผลกระทบ) ได้รับปัจจัยการผลิต / ข้อมูลเบื้องต้น (สาเหตุ) ใด ๆ เพิ่มเติม

Von Neumann ชนะทั้งสองทางเกือบตามคำนิยาม!

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.