Je suis très perplexe pendant quelques jours ... N'hésitez pas à abattre les hypothèses.
Nous utilisons un dictionnaire avec des clés entier. Je suppose que la valeur de la clé dans ce cas est utilisée directement comme hachage. Cela signifie-t-il (si les touches sont regroupées sur une petite plage) que la distribution du hachage de clé (même que la clé elle-même, n'est-ce pas?) Sera dans une petite gamme similaire, et donc un mauvais choix pour une hache de hashtable?
serait-il préférable de fournir un iéquitycomparateur qui a fait quelque chose d'intelligent avec les premiers et les mathématiques modulo pour calculer un meilleur hachage distribué?
3 Réponses :
Il n'est pas utilisé directement dans ce que le dictionnaire posera toujours la clé de son hachage - mais la valeur hachage d'un Je crois que la façon dont le dictionnaire .NET fonctionne ne s'appuie pas sur les valeurs de hachage étant distribuées uniformément. Il faut Vous pouvez toujours vous retrouver avec un ensemble de clés inefficaces bien sûr, s'ils devaient être espacés par le nombre de seau. Ce sera toujours le cas si - une table de hachage ne serait jamais véritablement o (1) pour toutes les clés s'ils avaient des valeurs de hasch uniques et la table a maintenu un ensemble de seaux pour chaque hachage possible :) En réalité, il a tendance à ne pas être un problème. Si vous savez que cela sera un problème, alors oui, un int32 est juste La valeur, de sorte que la poussée de votre question est pertinente, oui.
Hash% BucketCount où BucketCount est toujours prime. (C'est de la mémoire mais je pourrais avoir tort.)
iéqualitycomparer
Il suffit de vérifier avec un réflecteur ... vous avez raison avec le colde de hachage. Sachant que tout tombe en place. Merci Jon.
En supposant que vous utilisiez une implémentation de la table de hachage de bibliothèque standard, il est probable que la clé est pas le hachage, même si la clé est un entier, car exactement la raison que vous signalez.
Donc, alors que votre logique concernant les distributions de hachage est correcte, votre hypothèse initiale que les clés entier signifieraient que les hachages = clés ne sont probablement pas.
Si je me trompe Re: .NET, puis oh bien; C'est plus d'une réponse généralisée. :)
Je pense qu'il est assez courant que le hachage d'un type numérique soit juste la valeur, en supposant qu'il convient à la gamme de hachages.
Un problème potentiel que vous rencontrez cependant, c'est avec des motifs de nombres de nombres - si vous obtenez malchanceux avec la largeur de modèle étant un multiple de votre encombrement, vous rencontrez des problèmes.
Exactement comme mon post mentionne ... mais n'importe quel algorithme de hachage peut se retrouver avec ce problème si vous êtes malchanceux.
Sûr. Cependant, simplement en raison de la nature des modèles de données, il a tendance à se produire beaucoup plus dans l'entrée standard que dans la sortie d'une fonction de hachage spécialement conçue pour mélanger un peu les choses.
Avant de faire quelque chose d'intelligent, je testerais la vitesse de celui-ci, et voir si cela vous convient. Si ce n'est pas le cas, essayez la chose intelligente. Mais je m'attendrais à ce qu'il est préférable de le laisser seul; Il est plus important que les hacanes ne se heurtent pas et aussi longtemps que cela se produise, la vie ira bien.
Cela dépend de la distribution de vos clés entier. Les clés sont déjà modulotées par un prime lors du calcul du godet de hachage ..
Pourquoi supposer que le code de hachage est identique à la valeur entière? Essaye-le!
Le code de hachage est identique à la valeur entière.