((a + (b & 255)) & 255) เหมือนกับ ((a + b) & 255) หรือไม่

Question 1

ฉันกำลังเรียกดูรหัส C ++ และพบสิ่งนี้:

(a + (b & 255)) & 255

สองครั้งและทำให้ฉันรำคาญดังนั้นฉันจึงนึกถึง:

(a + b) & 255

( aและbเป็นจำนวนเต็ม 32 บิตที่ไม่ได้ลงชื่อ)

ฉันเขียนสคริปต์ทดสอบ (JS) อย่างรวดเร็วเพื่อยืนยันทฤษฎีของฉัน:

for (var i = 0; i < 100; i++) {
    var a = Math.ceil(Math.random() * 0xFFFF),
        b = Math.ceil(Math.random() * 0xFFFF);

    var expr1 = (a + (b & 255)) & 255,
        expr2 = (a + b) & 255;

    if (expr1 != expr2) {
        console.log("Numbers " + a + " and " + b + " mismatch!");
        break;
    }
}

ขยายข้อมูลโค้ด

แม้ว่าสคริปต์จะยืนยันสมมติฐานของฉัน (การดำเนินการทั้งสองเท่ากัน) แต่ฉันก็ยังไม่เชื่อเพราะ 1) สุ่มและ 2) ฉันไม่ใช่นักคณิตศาสตร์ฉันไม่รู้ว่าฉันกำลังทำอะไรอยู่

นอกจากนี้ขออภัยสำหรับชื่อ Lisp-y อย่าลังเลที่จะแก้ไข

Question 2

พวกเขาก็เหมือน ๆ กัน. นี่คือหลักฐาน:

ก่อนอื่นให้สังเกตตัวตน (A + B) mod C = (A mod C + B mod C) mod C

ขอย้ำปัญหาโดยการเกี่ยวกับการเป็นยืนอยู่ในa & 255 a % 256นี่เป็นความจริงเนื่องจากaไม่มีการลงนาม

ดังนั้น(a + (b & 255)) & 255เป็น(a + (b % 256)) % 256

สิ่งนี้เหมือนกับ(a % 256 + b % 256 % 256) % 256(ฉันได้ใช้ข้อมูลประจำตัวที่ระบุไว้ข้างต้นโปรดทราบว่าmodและ%เทียบเท่ากับประเภทที่ไม่ได้ลงชื่อ)

สิ่งนี้ทำให้(a % 256 + b % 256) % 256กลายเป็นเรื่องง่าย(a + b) % 256(การนำข้อมูลประจำตัวไปใช้ใหม่) จากนั้นคุณสามารถใส่ตัวดำเนินการระดับบิตกลับเพื่อให้

(a + b) & 255

เสร็จสิ้นการพิสูจน์

Question 3

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

อย่างไรก็ตามเราต้องระมัดระวังในการใช้กฎจากเลขคณิตไบนารีและนำไปใช้กับ C (ฉันเชื่อ C ++ มีกฎเดียวกันกับ C ในสิ่งนี้ แต่ฉันไม่แน่ใจ 100%) เนื่องจากเลขคณิต C มีกฎอาร์เคนบางอย่างที่สามารถเดินทางเราได้ ขึ้น. เลขคณิตที่ไม่ได้ลงนามใน C เป็นไปตามกฎการตัดกันแบบไบนารีอย่างง่าย แต่การล้นเลขคณิตที่ลงนามเป็นพฤติกรรมที่ไม่ได้กำหนด แย่กว่านั้นในบางสถานการณ์ C จะ "เลื่อนระดับ" ประเภทที่ไม่ได้ลงนามเป็น (ลงชื่อ) int โดยอัตโนมัติ

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

ดังนั้นการกลับไปที่สูตรในคำถามความเท่าเทียมกันขึ้นอยู่กับชนิดตัวถูกดำเนินการ

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

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

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

OTOH ถ้าaและbได้รับการลงนามจำนวนเต็มซึ่งมีขนาดมากกว่าหรือเท่ากับขนาดของ int แล้วแม้แต่ในการใช้งานเสริมสองครั้งก็มีบางกรณีที่คำสั่งหนึ่งจะได้รับการกำหนดไว้อย่างดีในขณะที่อีกคำสั่งหนึ่งจะเป็นพฤติกรรมที่ไม่ได้กำหนด

Question 4

แทรก: สำหรับการได้รับการรับรองa & 255 == a % 256a

ไม่ได้ลงนามaสามารถเขียนใหม่เป็นm * 0x100 + bบางส่วนที่ไม่มีการลงชื่อm, b, ,0 <= b < 0xff มันดังมาจากทั้งสองคำจำกัดความว่า0 <= m <= 0xffffffa & 255 == b == a % 256

นอกจากนี้เราต้องการ:

คุณสมบัติการกระจาย: (a + b) mod n = [(a mod n) + (b mod n)] mod n
ความหมายของการเพิ่มที่ไม่ได้ลงนามทางคณิตศาสตร์: (a + b) ==> (a + b) % (2 ^ 32)

ดังนั้น:

(a + (b & 255)) & 255 = ((a + (b & 255)) % (2^32)) & 255      // def'n of addition
                      = ((a + (b % 256)) % (2^32)) % 256      // lemma
                      = (a + (b % 256)) % 256                 // because 256 divides (2^32)
                      = ((a % 256) + (b % 256 % 256)) % 256   // Distributive
                      = ((a % 256) + (b % 256)) % 256         // a mod n mod n = a mod n
                      = (a + b) % 256                         // Distributive again
                      = (a + b) & 255                         // lemma

ใช่มันเป็นความจริง สำหรับจำนวนเต็ม 32 บิตที่ไม่ได้ลงชื่อ

จำนวนเต็มประเภทอื่น ๆ ล่ะ?

สำหรับจำนวนเต็มไม่ได้ลงนาม 64 บิตทั้งหมดข้างต้นมีผลบังคับใช้ก็เช่นกันเพียงแค่ทำหน้าที่แทนสำหรับ2^642^32
สำหรับจำนวนเต็ม 8 และ 16 บิตที่ไม่ได้ลงชื่อการเพิ่มนั้นเกี่ยวข้องกับการเลื่อนintระดับ สิ่งนี้intจะไม่ล้นหรือเป็นลบในการดำเนินการใด ๆ ดังนั้นการดำเนินการทั้งหมดยังคงใช้ได้
สำหรับจำนวนเต็มที่เซ็นชื่อถ้าอย่างใดอย่างหนึ่งa+bหรือa+(b&255)มากเกินไปจะเป็นพฤติกรรมที่ไม่ได้กำหนดไว้ ดังนั้นความเท่าเทียมกันจึงไม่สามารถระงับได้ - มีบางกรณีที่(a+b)&255เป็นพฤติกรรมที่ไม่ได้กำหนด แต่(a+(b&255))&255ไม่ใช่

Question 5

ใช่(a + b) & 255สบายดี

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

ข้างต้นไม่เป็นความจริงเสมอไปมาตรฐาน C ++ อนุญาตให้มีการใช้งานที่จะทำลายสิ่งนี้

Deathstation 9000 ดังกล่าว: - )จะต้องใช้ 33 บิตintหาก OP หมายถึงunsigned short"จำนวนเต็ม 32 บิตที่ไม่ได้ลงชื่อ" หากunsigned intมีความหมาย DS9K จะต้องใช้ 32 บิตintและ 32 บิตที่unsigned intมีช่องว่างภายใน (จำนวนเต็มที่ไม่ได้ลงนามจะต้องมีขนาดเดียวกับคู่ที่ลงนามตาม§3.9.1 / 3 และอนุญาตให้ใช้บิตรองใน§3.9.1 / 1) การผสมขนาดและบิตช่องว่างอื่น ๆ ก็ใช้ได้เช่นกัน

เท่าที่ฉันสามารถบอกได้นี่เป็นวิธีเดียวที่จะทำลายมันเพราะ:

การแทนค่าจำนวนเต็มต้องใช้รูปแบบการเข้ารหัส "ไบนารีล้วนๆ" (§3.9.1 / 7 และเชิงอรรถ) บิตทั้งหมดยกเว้นบิตช่องว่างและบิตเครื่องหมายต้องมีค่า 2 ⁿ
การส่งเสริม int จะได้รับอนุญาตก็ต่อเมื่อintสามารถแทนค่าทั้งหมดของประเภทแหล่งที่มา (§4.5 / 1) ดังนั้นintต้องมีอย่างน้อย 32 บิตที่มีส่วนในค่าบวกบิตเครื่องหมาย
intไม่สามารถมีบิตค่ามากขึ้น (ไม่นับบิตเครื่องหมาย) มากกว่า 32 เพราะที่อื่นนอกจากนี้ไม่สามารถล้น

Question 6

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

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

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

#include <iostream>
#include <limits>

int main() {
    std::uint64_t const MAX = std::uint64_t(1) << 32;
    for (std::uint64_t i = 0; i < MAX; ++i) {
        for (std::uint64_t j = 0; j < MAX; ++j) {
            std::uint32_t const a = static_cast<std::uint32_t>(i);
            std::uint32_t const b = static_cast<std::uint32_t>(j);

            auto const champion = (a + (b & 255)) & 255;
            auto const challenger = (a + b) & 255;

            if (champion == challenger) { continue; }

            std::cout << "a: " << a << ", b: " << b << ", champion: " << champion << ", challenger: " << challenger << "\n";
            return 1;
        }
    }

    std::cout << "Equality holds\n";
    return 0;
}

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

และตามเสียงดังกราว : ความเท่าเทียมกันถือ

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

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

ตอนแรกฉันพิสูจน์แล้วสำหรับจำนวนเต็ม 16 บิตที่ไม่ได้ลงชื่อ น่าเสียดายที่ C ++ เป็นภาษาที่บ้าจำนวนเต็มขนาดเล็ก (bitwidths ขนาดเล็กกว่าint) intจะถูกแปลงแรกที่จะ

#include <iostream>

int main() {
    unsigned const MAX = 65536;
    for (unsigned i = 0; i < MAX; ++i) {
        for (unsigned j = 0; j < MAX; ++j) {
            std::uint16_t const a = static_cast<std::uint16_t>(i);
            std::uint16_t const b = static_cast<std::uint16_t>(j);

            auto const champion = (a + (b & 255)) & 255;
            auto const challenger = (a + b) & 255;

            if (champion == challenger) { continue; }

            std::cout << "a: " << a << ", b: " << b << ", champion: "
                      << champion << ", challenger: " << challenger << "\n";
            return 1;
        }
    }

    std::cout << "Equality holds\n";
    return 0;
}

และอีกครั้งตามเสียงดังกราว : ความเท่าเทียมกันถือ

เอาล่ะ :)

¹ แน่นอนว่าหากโปรแกรมมีการกระตุ้นพฤติกรรมที่ไม่ได้กำหนดโดยไม่ได้ตั้งใจก็จะไม่สามารถพิสูจน์ได้มากนัก

Question 7

คำตอบด่วนคือนิพจน์ทั้งสองเทียบเท่ากัน

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

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

ถ้าชนิดของaและb(ไม่ได้ลงนาม 32 จำนวนเต็มบิต) มีอันดับสูงกว่าintการคำนวณที่มีการดำเนินการตามที่ได้รับการรับรอง, โมดูโล 2 ³²และอัตราผลตอบแทนผลที่กำหนดไว้เหมือนกันสำหรับการแสดงออกทั้งค่าทั้งหมดของและab
ในทางกลับกันถ้าประเภทของaและbมีขนาดเล็กกว่าintทั้งสองจะได้รับการเลื่อนระดับintและการคำนวณจะดำเนินการโดยใช้เลขคณิตที่มีลายเซ็นซึ่งส่วนเกินจะเรียกใช้พฤติกรรมที่ไม่ได้กำหนด
- หากintมีบิตค่าอย่างน้อย 33 นิพจน์ทั้งสองนิพจน์ข้างต้นไม่สามารถล้นดังนั้นผลลัพธ์จึงถูกกำหนดอย่างสมบูรณ์และมีค่าเดียวกันสำหรับทั้งสองนิพจน์
- หากintมีบิตค่า 32 บิตการคำนวณอาจล้นสำหรับทั้งสองนิพจน์ตัวอย่างเช่นค่าa=0xFFFFFFFFและb=1อาจทำให้เกิดการล้นในทั้งสองนิพจน์ ((a & 255) + (b & 255)) & 255เพื่อหลีกเลี่ยงการนี้คุณจะต้องเขียน
ข่าวดีก็คือไม่มีแพลตฟอร์มดังกล่าว¹ .

¹อย่างแม่นยำยิ่งกว่านั้นไม่มีแพลตฟอร์มจริงดังกล่าว แต่เราสามารถกำหนดค่าDS9Kเพื่อแสดงพฤติกรรมดังกล่าวและยังคงเป็นไปตามมาตรฐาน C

Question 8

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

Question 9

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

เมื่อเพิ่มทุกบิตจะมีอิทธิพลมากกว่าตัวมันเอง ไม่สำคัญน้อยกว่า

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

Question 10

หลักฐานเป็นเรื่องเล็กน้อยและปล่อยให้เป็นแบบฝึกหัดสำหรับผู้อ่าน

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

บรรทัดที่สองระบุว่า add aand band take 8 bits last โดยบิตที่สูงกว่าทั้งหมดเป็นศูนย์

เฉพาะ 8 บิตสุดท้ายเท่านั้นที่มีความสำคัญในผลลัพธ์ ดังนั้นเฉพาะ 8 บิตสุดท้ายเท่านั้นที่มีนัยสำคัญในอินพุต

** 8 บิตสุดท้าย = 8 LSB

นอกจากนี้ยังเป็นที่น่าสนใจที่จะทราบว่าผลลัพธ์จะเทียบเท่ากับ

char a = something;
char b = something;
return (unsigned int)(a + b);

ดังที่กล่าวมามีเพียง 8 LSB เท่านั้นที่มีความสำคัญ แต่ผลลัพธ์ที่ได้คือunsigned intกับบิตอื่น ๆ ทั้งหมดเป็นศูนย์ a + bจะล้นผลิตผลที่คาดหวัง