Tại sao XOR là cách mặc định để kết hợp băm?

Giả sử bạn có hai băm H(A)và H(B)và bạn muốn kết hợp chúng. Tôi đã đọc rằng một cách tốt để kết hợp hai băm là với XORchúng, ví dụ XOR( H(A), H(B) ).

Giải thích tốt nhất mà tôi tìm thấy được đề cập ngắn gọn ở đây về các nguyên tắc hàm băm này :

XOR hai số có kết quả phân phối ngẫu nhiên gần đúng trong một số khác vẫn có phân phối gần như ngẫu nhiên *, nhưng hiện tại phụ thuộc vào hai giá trị.
...
* Tại mỗi bit của hai số kết hợp, 0 là đầu ra nếu hai bit bằng nhau, khác a 1. Nói cách khác, trong 50% kết hợp, 1 sẽ là đầu ra. Vì vậy, nếu hai bit đầu vào, mỗi bit có khoảng 50-50 cơ hội là 0 hoặc 1, thì bit đầu ra cũng vậy.

Bạn có thể giải thích trực giác và / hoặc toán học đằng sau lý do tại sao XOR nên là hoạt động mặc định để kết hợp các hàm băm (chứ không phải OR hoặc AND, v.v.) không?

Giả sử các đầu vào ngẫu nhiên (1 bit) thống nhất, phân phối xác suất đầu ra của hàm AND là 75% 0và 25% 1. Ngược lại, OR là 25% 0và 75% 1.

Hàm XOR là 50% 0và 50% 1, do đó, rất tốt để kết hợp các phân phối xác suất thống nhất.

Điều này có thể được nhìn thấy bằng cách viết ra các bảng sự thật:

 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

Bài tập: Có bao nhiêu hàm logic của hai đầu vào 1 bit avà bcó phân phối đầu ra thống nhất này? Tại sao XOR phù hợp nhất cho mục đích được nêu trong câu hỏi của bạn?

xorlà một chức năng mặc định nguy hiểm để sử dụng khi băm. Nó là tốt hơn andvà or, nhưng điều đó không nói nhiều.

xorlà đối xứng, do đó thứ tự của các phần tử bị mất. Vì vậy, "bad"băm sẽ kết hợp giống như "dab".

xor ánh xạ các giá trị giống hệt nhau thành 0 và bạn nên tránh ánh xạ các giá trị "chung" thành 0:

Vì vậy, (a,a)được ánh xạ về 0 và (b,b)cũng được ánh xạ tới 0. Vì các cặp như vậy hầu như luôn luôn phổ biến hơn so với ngẫu nhiên có thể ngụ ý, bạn kết thúc với nhiều va chạm ở mức 0 so với bình thường.

Với hai vấn đề này, xorcuối cùng trở thành một công cụ băm có vẻ ngoài một nửa trên bề mặt, nhưng không phải sau khi kiểm tra thêm.

Trên phần cứng hiện đại, việc bổ sung thường nhanh như vậy xor(có thể sử dụng nhiều năng lượng hơn để thực hiện việc này, phải thừa nhận). Thêm bảng chân lý tương tự như xortrên bit trong câu hỏi, nhưng nó cũng gửi một bit đến bit tiếp theo khi cả hai giá trị là 1. Điều này có nghĩa là nó xóa ít thông tin hơn.

Vì vậy, hash(a) + hash(b)tốt hơn là hash(a) xor hash(b)trong đó nếu a==b, kết quả là hash(a)<<1thay vì 0.

Điều này vẫn đối xứng; Vì vậy, "bad"và "dab"nhận được kết quả tương tự vẫn là một vấn đề. Chúng ta có thể phá vỡ tính đối xứng này với chi phí khiêm tốn:

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

aka hash(a)*3 + hash(b). (tính toán hash(a)một lần và lưu trữ được khuyến nghị nếu bạn sử dụng giải pháp thay đổi). Bất kỳ hằng số lẻ nào thay vì 3sẽ ánh xạ một ksố nguyên không dấu "-bit" cho chính nó, vì ánh xạ trên các số nguyên không dấu là modulo toán học 2^kcho một số k, và bất kỳ hằng số lẻ nào cũng tương đối nguyên tố 2^k.

Đối với một phiên bản thậm chí fancier, chúng tôi có thể kiểm tra boost::hash_combine, đó là hiệu quả:

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

ở đây chúng ta thêm vào một số phiên bản thay đổi của seedvới một hằng số (về cơ bản 0là s và s ngẫu nhiên 1- đặc biệt nó là tỷ lệ nghịch của tỷ lệ vàng dưới dạng phân số điểm cố định 32 bit) với một số bổ sung và xor. Phá vỡ đối xứng này, và giới thiệu một số "tiếng ồn" nếu các giá trị băm đến nghèo (ví dụ, hãy tưởng tượng mỗi băm thành phần tỉ số 0 - tay cầm ở trên nó tốt, tạo ra một bôi nhọ của 1và 0. S sau mỗi lần kết hợp của tôi ngây thơ 3*hash(a)+hash(b)đơn giản là kết quả đầu ra một 0trong trường hợp).

(Đối với những người không quen thuộc với C / C ++, a size_tlà một giá trị nguyên không dấu, đủ lớn để mô tả kích thước của bất kỳ đối tượng nào trong bộ nhớ. Trên hệ thống 64 bit, thường là số nguyên không dấu 64 bit. Trên hệ thống 32 bit , số nguyên không dấu 32 bit.)

Mặc dù có các đặc tính trộn bit tiện dụng, XOR không phải là một cách tốt để kết hợp các giá trị băm do tính giao hoán của nó. Hãy xem xét điều gì sẽ xảy ra nếu bạn lưu trữ các hoán vị của {1, 2, Nhận, 10} trong bảng băm gồm 10 bộ.

Một lựa chọn tốt hơn nhiều là m * H(A) + H(B), trong đó m là một số lẻ lớn.

Tín dụng: Bộ kết hợp trên là một mẹo từ Bob Jenkins.

Xor có thể là cách "mặc định" để kết hợp băm nhưng câu trả lời của Greg Hewgill cũng cho thấy lý do tại sao nó có những cạm bẫy của nó: Xor của hai giá trị băm giống hệt nhau bằng không. Trong cuộc sống thực, có những băm giống hệt nhau là phổ biến hơn người ta có thể mong đợi. Sau đó, bạn có thể thấy rằng trong các trường hợp góc này (không thường xuyên), các giá trị băm kết hợp luôn luôn giống nhau (không). Va chạm băm sẽ nhiều, thường xuyên hơn nhiều so với bạn mong đợi.

Trong một ví dụ giả định, bạn có thể kết hợp mật khẩu băm của người dùng từ các trang web khác nhau mà bạn quản lý. Thật không may, một số lượng lớn người dùng sử dụng lại mật khẩu của họ và một tỷ lệ đáng ngạc nhiên trong số băm kết quả là bằng không!

Có một cái gì đó tôi muốn chỉ ra rõ ràng cho những người khác tìm thấy trang này. AND và OR hạn chế đầu ra như BlueRaja - Danny Pflughoe đang cố gắng chỉ ra, nhưng có thể được xác định rõ hơn:

Đầu tiên tôi muốn xác định hai hàm đơn giản tôi sẽ sử dụng để giải thích điều này: Min () và Max ().

Min (A, B) sẽ trả về giá trị nhỏ hơn giữa A và B, ví dụ: Min (1, 5) trả về 1.

Max (A, B) sẽ trả về giá trị lớn hơn giữa A và B, ví dụ: Max (1, 5) trả về 5.

Nếu bạn được cho: C = A AND B

Sau đó, bạn có thể tìm thấy rằng C <= Min(A, B) Chúng tôi biết điều này bởi vì không có gì bạn có thể VÀ với 0 bit của A hoặc B để biến chúng thành 1s. Vì vậy, mỗi bit 0 giữ một bit 0 và mỗi bit có cơ hội trở thành bit 0 (và do đó giá trị nhỏ hơn).

Với: C = A OR B

Điều ngược lại là đúng: C >= Max(A, B)Với điều này, chúng ta thấy hệ quả của hàm AND. Bất kỳ bit nào đã là một số không thể được OR thành số 0, vì vậy nó giữ nguyên một, nhưng mọi bit 0 đều có cơ hội trở thành số một, và do đó số lớn hơn.

Điều này ngụ ý rằng trạng thái của đầu vào áp dụng các hạn chế đối với đầu ra. Nếu bạn VÀ bất cứ điều gì với 90, bạn biết đầu ra sẽ bằng hoặc nhỏ hơn 90 bất kể giá trị khác là gì.

Đối với XOR, không có hạn chế ngụ ý dựa trên các đầu vào. Có những trường hợp đặc biệt mà bạn có thể thấy rằng nếu bạn XOR một byte với 255 hơn bạn nhận được nghịch đảo nhưng bất kỳ byte nào có thể có thể được xuất ra từ đó. Mỗi bit có cơ hội thay đổi trạng thái tùy thuộc vào cùng một bit trong toán hạng khác.

Nếu bạn XORnhập ngẫu nhiên với đầu vào sai lệch, đầu ra là ngẫu nhiên. Điều tương tự không đúng với ANDhoặc OR. Thí dụ:

00101001 XOR 00000000 = 00101001
00101001 VÀ 00000000 = 00000000
00101001 HOẶC 11111111 = 11111111

Như @Greg Hewgill đề cập, ngay cả khi cả hai yếu tố đầu vào là ngẫu nhiên, sử dụng ANDhoặc ORsẽ dẫn đến đầu ra sai lệch.

Lý do chúng tôi sử dụng XORcho một thứ phức tạp hơn là, không, không cần: XORhoạt động hoàn hảo, và nó cực kỳ ngu ngốc - nhanh chóng.

Che 2 cột bên trái và cố gắng tìm ra những gì đầu vào đang sử dụng chỉ là đầu ra.

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

Khi bạn thấy 1 bit, bạn nên biết rằng cả hai đầu vào là 1.

Bây giờ làm tương tự cho XOR

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

XOR không cho đi gì về đầu vào.

Các mã nguồn cho các phiên bản khác nhau của hashCode()trong java.util.Arrays là một tài liệu tham khảo tuyệt vời cho, sử dụng chung các thuật toán băm rắn. Chúng dễ dàng được hiểu và dịch sang các ngôn ngữ lập trình khác.

Nói một cách đơn giản, hầu hết các hashCode()triển khai đa thuộc tính đều theo mô hình này:

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;
}

Bạn có thể tìm kiếm Hỏi & Đáp về StackOverflow khác để biết thêm thông tin về phép thuật đằng sau 31và tại sao mã Java sử dụng nó thường xuyên như vậy. Nó là không hoàn hảo, nhưng có đặc điểm hiệu suất chung rất tốt.

XOR không bỏ qua một số đầu vào đôi khi như OR và AND .

Nếu bạn lấy AND (X, Y) chẳng hạn và cung cấp đầu vào X sai, thì đầu vào Y không thành vấn đề ... và người ta có thể muốn đầu vào có vấn đề khi kết hợp băm.

Nếu bạn lấy XOR (X, Y) thì CẢ HAI đầu vào LUÔN LUÔN . Sẽ không có giá trị của X khi Y không quan trọng. Nếu X hoặc Y bị thay đổi thì đầu ra sẽ phản ánh điều đó.