fonction de hashage, Aie ! - Programmation
Marsh Posté le 12-10-2001 à 10:14:48
MD5 n'irait pas ?
Le code source original en C est dispo sur le net... tu trouveras aussi de nombreuses implémentations dans d'autres langages.
Marsh Posté le 12-10-2001 à 10:31:52
si quelqu'un avait une adresse directe pour l'algo du MD5 (sous forme athématique de pref) ça serait sympa, parceque des site qui citent le M5 il y en a une tonne, mais des qui donne l'algo pas de bcp apparement.
requin : merci pour le conseil
Marsh Posté le 12-10-2001 à 10:43:07
requin,
bon apparement le prob avec le MD5 est qu'il retourne une valeur sur 128 bits. je me vois mal faire un tableau de de 2^128 elem
enfin ça c'est pour sa verison cryptographique, il existerait apparrment une version pour le hashage (a vérifier).
des idées MD5 ou autre.
[edtdd]--Message édité par Barbarella--[/edtdd]
Marsh Posté le 12-10-2001 à 10:47:29
MD5 fait l'opbjet du RFC 1321 dont voici le contenu et aux dernières nouvelles c'est une focntion de hashage qui est sûre :
Code :
|
Marsh Posté le 13-10-2001 à 01:46:15
utilises cperf ou gperf, disponibles chez gnu:
Citation : GNU gperf is a perfect hash function generator. For a given list of strings, it produces a hash function and hash table in the form of C or C++ code, for looking up a value depending on the input string. The hash function is 'perfect,' which means that the hash table has no collisions, and the hash table lookup needs a single string comparison only. |
A+,
[edtdd]--Message édité par gilou--[/edtdd]
Marsh Posté le 13-10-2001 à 13:45:56
slt,
d'abord je tiens a vous remercier de l'aide que vous m'avez apporté pour mon petit problème
Mais je vais rester dans l'immédiat avec ma petite procedure dichotomique. Effectivement la taille de ma liste de mot n'est pas dramatique de plus mon algo dicho est très performant d'autant plus que j'ai pu segmenter le tableau pour diminuer le nombre de comparaisons.
Marsh Posté le 13-10-2001 à 13:46:59
autrement , la table de hachage est imposée ?
sinon un AVL c'est pas mal non plus les perfs st en log(n) pour la recherche l'ajout et la suppression d'element pour une taille totalement dynamique
en plus avec une petite pile , tu derecursive tout et tu as des perfs impressionnante ( je l'ai un C et en java , et meme en java ca va vite )
Marsh Posté le 13-10-2001 à 14:04:20
attendez,
je vais vous donner des p'tites stast pour vous montrer que ma situation n'est pas desespérée et que j'ai encore un peu le choix des algo. je reviens le temps de refaire une stat rapide.
flo850:
je suis deja en log(N), mais j'ai jamais pu comparer mon algo un autre performants . si tu pouvais le mettre ici
Marsh Posté le 13-10-2001 à 14:26:21
ok,
en 1 seconde j'arrive a faire plus de 4000000 (4 millions) de
ret = find(mot); avec une comparaison moyenne 7,6 mots (7,6 strcmp(); par appel de find(mot) )sur une liste de mot de 6142 (taille des mots allant de 2 a 24). sur P3-933 NT4.
si la liste est non segmenter la comparaison moyenne monte a 11,8 strcmp par ret = find(mot).
Marsh Posté le 13-10-2001 à 15:09:57
c'est clair que tu es en log(n )
pour l'avl ( ou arbre bicolore , c'est le meme principe ) je n'ai pas de donneés aussi precise mais sur le serveur de la fac , le fait de passer d'une liste triée non segmentée a un avl , j'ai divisé par 3 le tps de traitement .
en plus pour segmenter il faut savoir la taille de laliste non ? c'est du statique ? l'avantage de l'avl c'est que c'est totalement dynamique .
la structure de données est pas super violente
en C je crois que le fichier .h doit faire 50 ligne et le .c dans les 300, donc ca reste raisonnable .
Marsh Posté le 13-10-2001 à 18:35:55
la journée a bogue aujourdhui , bon on reprends après cette petite interruption
J'ai aussi des fonctions de gestion de chaine : insertion//recherche en dynamique. dans ce cas t'es obligé d'utliser un mécanisme d'indexage. J'ai utilisé un algo maison, car je n'apprécie pas la gestion en liste chaine avant/arrière, trop lourd pour l'indexation de chaine de mot. Il te faut 3 long soit 12 octets pour indexer un mot . J'utilise une autre méthode plus performante en recherche, moins performante en insertion. Mais dans mon cas la recherche est toujours plus importante.
Pour les segmentation d'une liste de mot de type chaine de cractère. Son efficacité est max quand elle est prédéfinie. maintenant il est possible de faire une variante dynamique.
le truc c'est de voir si le tps gagné en diminuant le nombre de comparaison est sup au temps nécessire pour gérer le tableau d'entier qui donne la position de chaque segment dans la liste trié de chaine de caract.
par contre le nombre d'élément joue dans l'efficacité. effectivement le rapport X/Y tend vers zéro (X = nb comparaison moyenne sur l'ensemble du tableau Y = nb comparaison moyenne sur les segments) il faut dans ce cas re-segmenter, mais vu la répartition non-uniforme des mots (en général) il faut dans cas faire de la segmentation partielle. En dynamique ça devient ininteressant, en statique peut-être, faut voir.
Marsh Posté le 12-10-2001 à 10:00:09
salut la foule,
bon je teste actuellement des fonctions hashages pour tenter de remplacer ma fonc de recherche dicho (sur liste de 7000 mots environ). C'est pas terrible terrible, 30 a 40% d'echec
Vous avez des idées de truc qui marche bien. J'ai pas trop de prob avec la théorie des nombres donc même complexe je prends.
merci