ทำไม XOR ถึงเป็นวิธีเริ่มต้นในการรวมแฮช

สมมติว่าคุณมีสอง hashes H(A)และH(B)และคุณต้องการที่จะรวมพวกเขา ผมเคยอ่านว่าเป็นวิธีที่ดีที่จะรวมทั้งสอง hashes คือการให้พวกเขาเช่นXORXOR( H(A), H(B) )

คำอธิบายที่ดีที่สุดที่ฉันพบถูกสัมผัสสั้น ๆ ที่นี่ในแนวทางฟังก์ชั่นแฮช :

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

คุณสามารถอธิบายสัญชาตญาณและ / หรือคณิตศาสตร์ได้ไหมว่าทำไมแฮคเกอร์ถึงควรเป็นปฏิบัติการเริ่มต้นสำหรับการรวมฟังก์ชั่นแฮช (แทนที่จะเป็น OR หรือ AND เป็นต้น)

สมมติว่าสุ่มสม่ำเสมอ (1 บิต) ปัจจัยการผลิตและการทำงานการกระจายการส่งออกเป็น 75% 0และ 125% ตรงกันข้ามหรือเป็น 25% 0และ 175%

ฟังก์ชัน XOR คือ 50% 0และ 50% 1ดังนั้นจึงเป็นการดีสำหรับการรวมการแจกแจงความน่าจะเป็นแบบเดียวกัน

สิ่งนี้สามารถเห็นได้โดยการเขียนตารางความจริง:

 a | b | a AND b
---+---+--------
 0 | 0 |    0
 0 | 1 |    0
 1 | 0 |    0
 1 | 1 |    1

 a | b | a OR b
---+---+--------
 0 | 0 |    0
 0 | 1 |    1
 1 | 0 |    1
 1 | 1 |    1

 a | b | a XOR b
---+---+--------
 0 | 0 |    0
 0 | 1 |    1
 1 | 0 |    1
 1 | 1 |    0

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

xorเป็นฟังก์ชั่นเริ่มต้นที่เป็นอันตรายที่จะใช้เมื่อทำการแฮช มันดีกว่าandและorแต่ก็ไม่ได้พูดอะไรมาก

xorมีความสมมาตรดังนั้นลำดับขององค์ประกอบจึงหายไป ดังนั้นพระทัยกัญชารวมเช่นเดียวกับ"bad""dab"

xor จับคู่ค่าที่เหมือนกันของคู่กับศูนย์และคุณควรหลีกเลี่ยงการจับคู่ค่า "ทั่วไป" กับศูนย์:

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

ด้วยปัญหาทั้งสองนี้xorกลายเป็น combiner แฮชที่ดูดีครึ่งบนพื้นผิว แต่ไม่ใช่หลังจากการตรวจสอบเพิ่มเติม

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

ดังนั้นhash(a) + hash(b)จะดีกว่าhash(a) xor hash(b)ถ้าa==bผลลัพธ์ออกมาเป็นhash(a)<<10

เรื่องนี้ยังคงสมมาตร ดังนั้น"bad"และ"dab"ได้รับผลลัพธ์เดียวกันยังคงมีปัญหา เราสามารถแบ่งสมมาตรนี้ด้วยราคาที่ไม่แพง:

hash(a)<<1 + hash(a) + hash(b)

hash(a)*3 + hash(b)อาคา (คำนวณhash(a)หนึ่งครั้งและแนะนำให้เก็บถ้าคุณใช้วิธีเปลี่ยนกะ) ใด ๆ คงแปลกแทนที่จะ3bijectively แผนที่จะเป็น " kบิต" จำนวนเต็มไม่ได้ลงนามกับตัวเองเป็นแผนที่ในจำนวนเต็มไม่ได้ลงนามเป็นแบบโมดูโลคณิตศาสตร์2^kสำหรับบางคนkและคงแปลก ๆ 2^kค่อนข้างสำคัญในการ

สำหรับรุ่นที่ยิ่งกว่านั้นเราสามารถตรวจสอบboost::hash_combineได้ซึ่งมีประสิทธิภาพ:

size_t hash_combine( size_t lhs, size_t rhs ) {
  lhs ^= rhs + 0x9e3779b9 + (lhs << 6) + (lhs >> 2);
  return lhs;
}

ที่นี่เราเพิ่มบางเวอร์ชั่นที่seedมีการเปลี่ยนแปลงด้วยค่าคงที่ (ซึ่งโดยทั่วไปจะเป็นแบบสุ่ม0และ1s - โดยเฉพาะอย่างยิ่งมันเป็นสิ่งที่ตรงกันข้ามกับอัตราส่วนทองคำเป็นเศษส่วนจุดคงที่ 32 บิต) ด้วยการเพิ่มและ xor แบ่งนี้สมมาตรและแนะนำบางคน "เสียง" ถ้าค่าแฮชที่เข้ามาไม่ดี (เช่นจินตนาการทุก hashes ส่วนประกอบ 0 - จับดังกล่าวข้างต้นได้ดีสร้าง smear ของ1และ0. s หลังจากแต่ละรวมของฉันไร้เดียงสา3*hash(a)+hash(b)เพียง outputs 0ใน กรณีนั้น)

(สำหรับผู้ที่ไม่คุ้นเคยกับ C / C ++ a size_tคือค่าจำนวนเต็มที่ไม่ได้ลงนามซึ่งใหญ่พอที่จะอธิบายขนาดของวัตถุใด ๆ ในหน่วยความจำบนระบบ 64 บิตโดยปกติจะเป็นจำนวนเต็ม 64 บิตที่ไม่ได้ลงชื่อบนระบบ 32 บิต เป็นจำนวนเต็ม 32 บิตที่ไม่ได้ลงชื่อ)

ทั้งๆที่มีคุณสมบัติการผสมบิตที่มีประโยชน์ XOR ไม่ใช่วิธีที่ดีในการรวมแฮชเนื่องจากการสับเปลี่ยน พิจารณาสิ่งที่จะเกิดขึ้นหากคุณเก็บพีชคณิตของ {1, 2, …, 10} ไว้ในตารางแฮชของ tuples 10 อัน

ทางเลือกที่ดีกว่าคือm * H(A) + H(B)ที่mคือเลขคี่ขนาดใหญ่

เครดิต: combiner ด้านบนเป็นเคล็ดลับจาก Bob Jenkins

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

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

มีบางสิ่งที่ฉันต้องการชี้ให้เห็นอย่างชัดเจนสำหรับคนอื่นที่พบหน้านี้ และและหรือ จำกัด เอาต์พุตเช่น BlueRaja - Danny Pflughoe พยายามที่จะชี้ให้เห็น แต่สามารถกำหนดได้ดีกว่า:

ก่อนอื่นฉันต้องการนิยามฟังก์ชั่นง่าย ๆ สองอย่างที่ฉันจะใช้อธิบาย: Min () และ Max ()

ต่ำสุด (A, B) จะคืนค่าที่เล็กกว่าระหว่าง A และ B ตัวอย่างเช่น: Min (1, 5) ส่งคืน 1

Max (A, B) จะคืนค่าที่ใหญ่กว่าระหว่าง A และ B ตัวอย่างเช่น: Max (1, 5) ส่งคืน 5

หากคุณได้รับ: C = A AND B

จากนั้นคุณจะพบว่าC <= Min(A, B)เรารู้สิ่งนี้เพราะไม่มีสิ่งใดที่คุณสามารถทำได้และด้วย 0 บิตของ A หรือ B เพื่อทำให้เป็น 1s ดังนั้นทุก ๆ ศูนย์บิตจะมีค่าเป็นศูนย์บิตและทุก ๆ หนึ่งบิตมีโอกาสที่จะกลายเป็นศูนย์บิต (และทำให้มีค่าน้อยกว่า)

ด้วย: C = A OR B

ตรงกันข้ามคือจริง: C >= Max(A, B)ด้วยสิ่งนี้เราจะเห็นข้อพิสูจน์ของฟังก์ชัน AND บิตใดก็ตามที่มีอยู่แล้วหนึ่งอันไม่สามารถถูก ORed ให้เป็นศูนย์ได้ดังนั้นจึงยังคงอยู่หนึ่งบิต แต่ทุก ๆ บิตศูนย์มีโอกาสที่จะกลายเป็นหนึ่งและทำให้มีจำนวนมากขึ้น

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

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

หากคุณXORอินพุตแบบสุ่มที่มีอินพุตแบบเอนเอียงเอาต์พุตจะเป็นแบบสุ่ม เช่นเดียวกับที่ไม่เป็นความจริงสำหรับหรือAND ORตัวอย่าง:

00101001 XOR 00000000 = 00101001
00101001 และ 00000000 = 00000000
00101001 หรือ 11111111 = 11111111

ดังที่ @Greg Hewgill กล่าวถึงแม้ว่าทั้งสองอินพุตจะสุ่มใช้ANDหรือORส่งผลให้เอาต์พุตแบบเอนเอียง

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

ครอบคลุม 2 คอลัมน์ด้านซ้ายและพยายามหาว่าอินพุตใช้เพียงแค่เอาต์พุต

 a | b | a AND b
---+---+--------
 0 | 0 |    0
 0 | 1 |    0
 1 | 0 |    0
 1 | 1 |    1

เมื่อคุณเห็น 1 บิตคุณควรหาว่าทั้งสองอินพุตเป็น 1

ตอนนี้ทำเช่นเดียวกันสำหรับ XOR

 a | b | a XOR b
---+---+--------
 0 | 0 |    0
 0 | 1 |    1
 1 | 0 |    1
 1 | 1 |    0

แฮคเกอร์ไม่ได้ให้อะไรกับอินพุตเลย

รหัสที่มาสำหรับรุ่นต่างๆของhashCode()ในjava.util.Arraysคือการอ้างอิงที่ดีสำหรับของแข็งขั้นตอนวิธีการใช้งานทั่วไปคร่ำเครียด พวกเขาเข้าใจและแปลเป็นภาษาโปรแกรมอื่น ๆ ได้ง่าย

การใช้งานแบบหลายแอตทริบิวต์ส่วนใหญ่เป็นhashCode()ไปตามรูปแบบนี้:

public static int hashCode(Object a[]) {
    if (a == null)
        return 0;

    int result = 1;

    for (Object element : a)
        result = 31 * result + (element == null ? 0 : element.hashCode());

    return result;
}

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

แฮคเกอร์ไม่ละเว้นบางส่วนของปัจจัยการผลิตบางครั้งเหมือนหรือและและ

หากคุณใช้AND (X, Y)เช่นและป้อนฟีดXด้วย false ดังนั้นอินพุตYไม่สำคัญ ... และอาจต้องการอินพุตสำหรับเรื่องเมื่อรวมแฮช

หากคุณใช้XOR (X, Y)ดังนั้นทั้งสองอินพุตนั้นสำคัญเสมอ จะไม่มีค่า X ที่ Y ไม่สำคัญ หากมีการเปลี่ยนแปลง X หรือ Y เอาต์พุตจะสะท้อนให้เห็น