Thông thường, hàm băm đơn giản hoạt động bằng cách lấy "các bộ phận thành phần" của đầu vào (các ký tự trong trường hợp của chuỗi) và nhân chúng với các lũy thừa của một số hằng và cộng chúng lại với nhau trong một số kiểu nguyên. Vì vậy, ví dụ, hàm băm điển hình (mặc dù không đặc biệt tốt) có thể là:
(first char) + k * (second char) + k^2 * (third char) + ...
Sau đó, nếu một chuỗi các chuỗi có cùng char đầu tiên được đưa vào, thì tất cả các kết quả sẽ là cùng một modulo k, ít nhất là cho đến khi kiểu số nguyên tràn ra.
[Ví dụ, chuỗi hashCode của Java tương tự như thế này - nó thực hiện đảo ngược các ký tự, với k = 31. Vì vậy, bạn có được các mối quan hệ nổi bật modulo 31 giữa các chuỗi kết thúc theo cùng một cách và các mối quan hệ nổi bật modulo 2 ^ 32 giữa các chuỗi giống nhau ngoại trừ gần cuối. Điều này không gây rối nghiêm trọng cho hành vi hashtable.]
Một hashtable hoạt động bằng cách lấy mô-đun của hàm băm qua số lượng xô.
Điều quan trọng trong một hashtable là không tạo ra va chạm cho các trường hợp có khả năng, vì các va chạm làm giảm hiệu quả của hashtable.
Bây giờ, giả sử ai đó đặt cả đống giá trị vào một hashtable có mối quan hệ nào đó giữa các mục, giống như tất cả đều có cùng một ký tự đầu tiên. Đây là một mô hình sử dụng khá dễ đoán, tôi muốn nói, vì vậy chúng tôi không muốn nó tạo ra quá nhiều va chạm.
Nó chỉ ra rằng "vì bản chất của toán học", nếu hằng số được sử dụng trong hàm băm và số lượng xô là đồng thời , thì các va chạm được giảm thiểu trong một số trường hợp phổ biến. Nếu họ không phải là nguyên tố cùng nhau, sau đó có một số mối quan hệ khá đơn giản giữa các đầu vào mà các va chạm không được giảm thiểu. Tất cả các giá trị băm đều xuất hiện modulo bằng nhau, yếu tố chung, có nghĩa là tất cả chúng sẽ rơi vào 1 / n của các thùng có giá trị modulo đó là yếu tố chung. Bạn nhận được gấp n lần số lần va chạm, trong đó n là yếu tố phổ biến. Vì n ít nhất là 2, nên tôi không thể chấp nhận trường hợp sử dụng khá đơn giản để tạo ra ít nhất gấp đôi số lần va chạm so với bình thường. Nếu một số người dùng sẽ phá vỡ phân phối của chúng tôi thành các thùng, chúng tôi muốn đó là một tai nạn kỳ quặc, không phải là một cách sử dụng đơn giản có thể dự đoán được.
Bây giờ, việc triển khai hashtable rõ ràng không có quyền kiểm soát đối với các mục được đưa vào chúng. Họ không thể ngăn họ liên quan. Vì vậy, điều cần làm là đảm bảo rằng hằng số và số lượng xô là nguyên tố cùng nhau. Bằng cách đó, bạn không chỉ dựa vào thành phần "cuối cùng" để xác định mô đun của thùng đối với một số yếu tố chung nhỏ. Theo như tôi biết thì họ không cần phải thành thạo để đạt được điều này, chỉ là đồng thời.
Nhưng nếu hàm băm và hàm băm được viết độc lập, thì hàm băm không biết hàm băm hoạt động như thế nào. Nó có thể được sử dụng một hằng số với các yếu tố nhỏ. Nếu bạn may mắn, nó có thể hoạt động hoàn toàn khác và là phi tuyến. Nếu băm là đủ tốt, thì bất kỳ số lượng xô là tốt. Nhưng một hashtable hoang tưởng không thể đảm nhận chức năng băm tốt, vì vậy nên sử dụng số nguyên tố lớn nhất. Tương tự, hàm băm hoang tưởng nên sử dụng hằng số nguyên tố lớn, để giảm khả năng ai đó sử dụng một số nhóm xảy ra có một yếu tố chung với hằng số.
Trong thực tế, tôi nghĩ việc sử dụng sức mạnh bằng 2 là số lượng xô là khá bình thường. Điều này là thuận tiện và tiết kiệm phải tìm kiếm xung quanh hoặc chọn trước một số nguyên tố có độ lớn phù hợp. Vì vậy, bạn dựa vào hàm băm không sử dụng nhiều số nhân, mà nói chung là một giả định an toàn. Nhưng bạn vẫn có thể có các hành vi băm không thường xuyên dựa trên các hàm băm như ở trên và số lượng nguyên tố có thể giúp thêm.
Đặt ra nguyên tắc rằng "mọi thứ phải là chính" theo như tôi biết là một điều kiện đủ nhưng không phải là điều kiện cần thiết để phân phối tốt trên các hashtag. Nó cho phép mọi người tương tác với nhau mà không cần phải cho rằng những người khác đã tuân theo quy tắc tương tự.
[Chỉnh sửa: có một lý do khác, chuyên biệt hơn để sử dụng số lượng lớn các nhóm, đó là nếu bạn xử lý các va chạm với thăm dò tuyến tính. Sau đó, bạn tính toán một bước tiến từ mã băm và nếu bước tiến đó là một yếu tố của số lượng xô thì bạn chỉ có thể thực hiện (buck_count / stride) trước khi bạn quay lại nơi bạn bắt đầu. Trường hợp bạn muốn tránh nhất là stride = 0, tất nhiên, phải là trường hợp đặc biệt, nhưng để tránh trường hợp đặc biệt xô_count / stride bằng một số nguyên nhỏ, bạn chỉ có thể tạo số nguyên tố xô_count và không quan tâm điều gì sải chân được cung cấp không phải là 0.]