มีเหตุผลหรือไม่ที่จะสมมติว่าปริมาณทางกายภาพใด ๆ ที่สามารถแทนด้วยจำนวนเต็ม 64- บิตโดยไม่ล้นหรือต่ำกว่า?

อัลกอริทึมการค้นหาแบบไบนารีดั้งเดิมใน JDK ใช้จำนวนเต็ม 32 บิตและมีข้อบกพร่องมากเกินไปหาก(low + high) > INT_MAX( http://googleresearch.blogspot.com/2006/06/extra-extra-extra-read-all-about-it-nearly.html ) .

หากเราเขียนอัลกอริทึมการค้นหาแบบไบนารี่เดียวกันโดยใช้ (ลงนาม) 64- บิตเราสามารถสันนิษฐานได้ว่าlow + highจะไม่เกิน INT64_MAX เพราะเป็นไปไม่ได้ที่ร่างกายจะมีหน่วยความจำ 10 ^ 18 ไบท์หรือไม่

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

คำตอบสั้น ๆ คือไม่ อย่างไรก็ตามสำหรับบางแอปพลิเคชันการสันนิษฐานของคุณอาจถูกต้อง

สมมติว่า int ที่ถูกลงชื่อ 2 ^ 63 โดยเพิ่มเครื่องหมายจุลภาคเพื่อความชัดเจน = 9,223,372,036,854,775,808 มันประมาณ 9 * 10 ^ 18 10 ^ 18 คือ "Exa"

Wikipedia กล่าวว่า "ในปี 2013 เวิลด์ไวด์เว็บคาดว่าจะถึง 4 zettabytes [12]" ซึ่งเป็น 4000 Exabytes ดังนั้น WWW มีขนาดใหญ่กว่า400 ^ 2 ไบต์ประมาณ400 เท่า

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

สำหรับตัวอย่างอื่นพิจารณากาแลคซีที่อยู่ห่างไกล อันที่จริงแล้ว Galaxy Andromeda เป็นหนึ่งในสิ่งที่ใกล้เคียงที่สุดและอยู่ห่างออกไป 2.5 * 10 ^ 6 ปีแสง หากหน่วยของคุณเป็นไมล์นั่นจะเป็น 14.5 * 10 ^ 18 มากกว่าจำนวนเต็ม 64 บิตที่เซ็นชื่อ ตอนนี้เห็นได้ชัดว่ามันขึ้นอยู่กับหน่วยที่คุณใช้สำหรับการวัดของคุณ แต่กาแลคซีบางแห่งอยู่ห่างจากแอนโดรเมด้ามาก ( อันที่รู้จักมากที่สุดคือ 13 * 10 ^ 9 LY ) ขึ้นอยู่กับความแม่นยำที่คุณต้องการสำหรับการวัดของคุณมันอาจล้นจำนวนเต็ม 64 บิต

( เพิ่มเติม ) ใช่ไมล์เป็นหน่วยหมัดสำหรับระยะทางดาราศาสตร์ หน่วยปกติมากขึ้นอาจเป็นหน่วยดาราศาสตร์ซึ่งมีระยะทาง 93 ล้านไมล์ ด้วยการใช้หน่วยการวัดนั้นกาแลคซีที่รู้จักไกลที่สุดนั้นอยู่ที่ประมาณ 10 ^ 15 AU (ถ้าคณิตศาสตร์ของฉันถูกต้อง) ซึ่งจะพอดีกับ int 64 บิต อย่างไรก็ตามหากคุณต้องการวัดระยะทางไปยังดวงจันทร์ถึงวงโคจรที่อยู่ใกล้เคียงหน่วยนั้นก็ใหญ่เกินไป

ตัวอย่างหนึ่งที่เพิ่มเติมจากเครื่องใช้ไฟฟ้า: Farad (F) หน่วยของความจุ ตัวเก็บประจุขนาดใหญ่มีค่ามากถึง 5kF และจำนวนนี้จะเพิ่มขึ้นเมื่อเวลาผ่านไปเช่นรถยนต์ไฮบริด "สมาร์ทกริด" ฯลฯ ปรับปรุง เมื่อสามารถวัดความจุได้เพียง 10 ^ -18 F. ดังนั้นช่วงโดยรวมของความจุแบบ "ของจริง" ที่เราสามารถวัดได้ในวันนี้คือ 5 * 10 ^ 21 ซึ่งมีขนาดใหญ่กว่าจำนวนเต็ม 64 บิต

คุณไม่จำเป็นต้องไปที่เกี่ยวกับจักรวาลเมื่อ combinatorics มีส่วนเกี่ยวข้อง มีข้อเสนอที่เป็นไปได้ 2 ^ 95 ในเกมบริดจ์และนั่นคือความซับซ้อนเล็ก ๆ

ปริมาณทางกายภาพที่เกี่ยวข้องมากที่สุดสำหรับคำถามของคุณเป็นแรมคอมพิวเตอร์

Windows Server 2012 รองรับหน่วยความจำกายภาพสูงสุดถึง 4 TB นั่นคือ 2 ⁴²ไบต์ หากความจุ RAM เพิ่มขึ้นเป็นสองเท่าทุก ๆ ปีในเวลาเพียง 17 ปีต่อจากนี้ "Windows Server 2032" จะรองรับหน่วยความจำกายภาพ2 ⁶²ไบต์ซึ่งคุณlow + highจะได้รับ 2 ⁶³ - 2 และจูบจำนวนเต็ม 64 บิตสูงสุดที่เซ็นชื่อ

ฉันหวังว่าระบบความปลอดภัยที่สำคัญจะล้มเหลวเนื่องจากการสันนิษฐานว่า 64 บิตจะเพียงพอเสมอ

สำหรับการใช้งานเล็กน้อยทั่วไปมากขึ้นปริมาณทางกายภาพที่เกี่ยวข้องมากที่สุดคือพื้นที่ที่อยู่ในหน่วยความจำ (มันมีประโยชน์ที่จะมีพื้นที่ที่อยู่ที่ใหญ่กว่าหน่วยความจำกายภาพเช่นใส่หน่วยความจำจำนวนมากทุกห้องพร้อมที่จะเติบโต) การใช้งานx86-64ปัจจุบันรองรับที่อยู่เสมือน 48 บิตดังนั้นเรามีเวลาเพียง 14 ปีก่อนที่ CPU เหล่านี้จะถึงขีด จำกัด พื้นที่แอดเดรส2 ⁶²ไบต์

และจากนั้นก็มีหน่วยความจำที่ใช้ร่วมกันแบบกระจาย "ซึ่งสามารถแยกแยะความทรงจำ (แยกทางร่างกาย) เป็นพื้นที่ที่อยู่หนึ่งแห่ง

มีเหตุผลหรือไม่ที่จะสมมติว่าปริมาณทางกายภาพใด ๆ ที่สามารถแทนด้วยจำนวนเต็ม 64- บิตโดยไม่ล้นหรือต่ำกว่า?

ไม่แน่นอน มีตัวเลขมากมายที่ทั้งใหญ่และเล็กกว่านั่นคือเหตุผลที่เรามีเลขทศนิยม ตัวเลขแต้มลอยแลกกับความแม่นยำที่น้อยลง

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

สมมติฐานของคุณจะไม่จัดการกับปริมาณทางกายภาพที่สามารถแสดงด้วยตัวเลขจุดลอยตัวเท่านั้น และแม้ว่าคุณตัดสินใจที่จะปรับตัวเลขทั้งหมดให้พูดโดยคูณตัวเลขทั้งหมดด้วย 10,000 (ดังนั้นค่ายังคงเป็นจำนวนเต็ม แต่สามารถแสดงในสิบหลัก) รูปแบบนี้ยังคงล้มเหลวสำหรับตัวเลขที่ใกล้เคียงกับศูนย์มากเช่นมวลอิเล็กตรอน (9.1094 * 10⎻³¹กิโลกรัม)

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

10 kg (obviously physical quantity)
1 kg (same)
10⎻² kg (1/100 kg, or about 1/3 ounce) (also quite real)

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

แน่นอนคุณอาจมีเขตข้อมูลพิเศษภายในจำนวนเพื่อปรับสัดส่วนจำนวนเต็มขึ้นหรือลงโดยตัวคูณตัวแปร gee ตอนนี้คุณเพิ่งประดิษฐ์จุดลอย

ก่อนอื่นฉันจะตอบคำถามว่าค่าทางกายภาพใดที่สามารถ / ควรแทนด้วยจำนวนเต็ม?

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

ดังนั้นสิ่งที่เป็นค่าทางกายภาพที่เป็นจำนวนธรรมชาติและพวกเขาสามารถล้นจำนวนเต็ม 64 บิต?

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

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

นอกเหนือจากคำตอบของ Jerry101 ฉันขอเสนอแบบทดสอบที่ง่ายและใช้งานได้จริงเพื่อความถูกต้อง:

สมมติว่าคุณจัดสรรหน่วยความจำบางส่วนผ่านmallocระบบปฏิบัติการ 64 บิต สมมติว่าตัวจัดสรรหน่วยความจำตัดสินใจกลับไปยังบล็อกหน่วยความจำที่ถูกต้องของคุณตามขนาดที่คุณร้องขอ แต่มีการตั้งค่าบิตที่ 63

ในคำอื่น ๆ สมมติมีอยู่ environements บางโปรแกรมที่มีหน่วยความจำช่วงที่ถูกต้องตามกฎหมายที่อาจจะกลับมาจากการเรียกร้องให้0xFFFFFFFFxxxxxxxxmalloc

คำถามคือรหัสของคุณจะยังคงทำงานตามที่ตั้งใจหรือไม่

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

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

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

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

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

มีบางกรณีที่เหมาะสมที่จะเขียนโค้ดที่ขึ้นอยู่กับการไม่ล้นของตัวเลข 64- บิต ตัวอย่างหลักที่ฉันรู้คือตัวนับโดยที่ตัวนับเพิ่มขึ้นทุกครั้งที่ใช้ แม้ในอัตราเพิ่มขึ้นหนึ่งครั้งต่อนาโนวินาที (ไม่ใช่ภาคปฏิบัติ) แต่ก็ต้องใช้เวลามากกว่าหนึ่งศตวรรษในการล้น

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

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

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

มันไม่มีเหตุผลที่จะถือว่าเป็นจำนวนเต็ม 64 บิตสามารถเก็บตัวเลขทั้งหมด หลายเหตุผล:

1. จำนวนเต็มสูงสุดและต่ำสุด 64 บิตเป็นตัวเลข จำกัด สำหรับทุกจำนวน จำกัด จะมีจำนวน จำกัด มากขึ้นและเล็กลง

2. ปัจจุบันการคำนวณด้วยตัวเลข 128 บิตและ 256 บิตนั้นใช้ในสถานที่ต่าง ๆ โปรเซสเซอร์หลายตัวมีคำแนะนำเฉพาะที่ทำงานกับจำนวนเต็ม 128 บิต

3. 20 ปีที่แล้วดิสก์ 1 GB ถูกพิจารณาว่า "ใหญ่" วันนี้ดิสก์ 1 TB ถือว่ามีขนาดเล็ก 20 ปีที่แล้วเดสก์ท็อปเฉลี่ยมี RAM ประมาณ 16 MB เดสก์ท็อปปัจจุบันของฉันมี RAM มากกว่า 16 GB พื้นที่ฮาร์ดดิสก์และ RAM เติบโตขึ้นอย่างมากในอดีตและคาดการณ์ว่าจะเพิ่มขึ้นอย่างมากในอนาคต หากไม่มีใครสามารถคิดหาเหตุผลที่ดีว่าทำไมมันควรหยุดเติบโต