2012-06-06 14 views
5

Aquí está el código de ejemplo del artículo 9:necesitan de explicación, por ejemplo, código hash en el libro de texto Effective Java

public final class PhoneNumber { 
    private final short areaCode; 
    private final short prefix; 
    private final short lineNumber; 

    @Override 
    public int hashCode() { 
    int result = 17; 
    result = 31 * result + areaCode; 
    result = 31 * result + prefix; 
    result = 31 * result + lineNumber; 
    return result; 
    } 
} 

Pg 48 estados: "el valor 31 fue elegido porque es un extraña primer Si se tratara. incluso y la multiplicación se desbordó, la información se perdería, ya que la muiltiplicación por 2 es equivalente a un cambio ".

Entiendo que el concepto de multiplicación por 2 es equivalente al cambio de bit. También sé que todavía obtendremos un desbordamiento (por lo tanto, pérdida de información) cuando multiplicamos un número grande por un número primo impar grande. Lo que no entiendo es por qué la pérdida de información que surge de la multiplicación por primos impares grandes es preferible a la pérdida de información que surge de la multiplicación por grandes números pares.

+1

distinto de 2, ningún otro número par es primo –

+0

omg! No puedo creer que olvidé esto. Creo que acabo de tener un momento tonto hoy. Gracias :) – Kes115

+3

Esto puede ser un duplicado de http://stackoverflow.com/questions/299304/why-does-javas-hashcode-in-string-use-31-as-a-multiplier. –

Respuesta

6

Con un multiplicador par el bit menos significativo, después de la multiplicación, siempre es cero. Con un multiplicador impar, el bit menos significativo es uno o cero dependiendo de cuál fue el valor anterior de result. Por lo tanto, el multiplicador par está perdiendo incertidumbre sobre el bit bajo, mientras que el multiplicador impar lo está preservando.

1

No hay tal cosa como un gran primo par - el único primo par es 2.

Aparte de eso - la idea general de usar una de tamaño mediano primer # en lugar de uno pequeño como 3 ó 5 es para minimizar la posibilidad de que dos objetos terminen con el mismo valor hash, desbordamiento o no.

El riesgo de desbordamiento no es el problema per se; el verdadero problema es cómo se distribuirán los valores de hashcode para el conjunto de objetos que se procesan. Debido a que los códigos hash se usan en estructuras de datos como HashSet, HashMap, etc., desea minimizar el número de objetos que podrían compartir el mismo código hash para optimizar los tiempos de búsqueda en esas colecciones.

Cuestiones relacionadas