Page 1 sur 1

Map ... Hashing table sans linked list ? :?:

Publié : lun. 01/févr./2010 11:17
par Fig
Bonjour à tous, :D
J'ai besoin de quelques confirmations concernant les maps pb.

Il me semble à la lecture de la doc PB que les maps sont des tables de hashage avec remplacement de l'élément en cas de collision...
Ca ne fait pas mes affaires si tel est bien le cas... :cry:
Et entre nous soit dit, je ne vois pas l'intérêt de remplacer les éléments en collision (!!)

Evidemment je peux incorporer une structure du type array[] mais je bouffe de la mémoire, je risque de réserver soit trop de place, soit pas assez dans chacun des slots.
L'idéal eut été d'intégrer directement une liste dynamique à chacun des slots... Pourquoi cela n'a pas été fait nativement ?

Je suis donc obligé de créer moi-même une table de hashage et des élements dynamiques avec "allocatememory" ou y a t il une autre solution ? :?:

Si tel est le cas, je voudrais savoir si cela prend beaucoup de temps à l'os d'affecter une nouvelle zone mémoire avec allocatememory afin de savoir si je dois assigner de la mémoire à chaque élément de la liste dynamique ou si je réserve, par exemple, de la mémoire pour 10 élements à chaque fois que c'est nécessaire.

J'ai besoin en effet que la table soit particulièrement rapide. J'y stocke les éléments de ma carte avec une clé élaborée avec 3 coordonnées dont une temporelle (x,y,t) modulo du nombre de slots.

Re: Map ... Hashing table sans linked list ? :?:

Publié : lun. 01/févr./2010 11:42
par Fred
La map replace l'element si la clef existe deja, pas en cas de collision du hash. Si t'as plusieurs elements avec la meme clef dans la meme map, tu pourras pas y acceder.

Re: Map ... Hashing table sans linked list ? :?:

Publié : mar. 02/févr./2010 18:41
par GeBonet
Fred a écrit :La map replace l'élément si la clef existe déjà, pas en cas de collision du hash. Si t'as plusieurs éléments avec la même clef dans la même map, tu pourras pas y accéder.
@Fred !
Pourquoi ne pas avoir adopté un "ISAM" au lieu d'un "Hascode" :?:
AVANTAGE :
ISAM= Clef principal unique possible
OU/ET
ISAM = Clef secondaire multiple
ISAM = Pas de collision...
ISAM = Fichier organisé et trié... Sur la clef principale ou secondaire !
Soit pas mal d'avantage.
ISAM = Permet de se passer de "SQLxxx"
DESAVANTAGE : Un peu plus lent... Mais lorsqu'il s'agit de donnée style fichiers de gestion générale alors pas trop d'incidence.
Je crois que la raison est a mon avis : Un algorithme permet de créer un emplacement pour une clef, donc très rapide. Quoique il est possible d'avoir un Hascode avec gestion des collisions qui permet d'avoir deux clef identique... Il y a aussi peut-être d'autres raison qui m'échappent ?
Tandis que cela se complique un peu plus pour l' ISAM.. ("Indexed Sequential Access Method"), mais une fois fait permet d'avoir un système de gestion de fichier très complet et complétement indépendant. :wink:
Bon, cela ne reste qu'un avis... :lol: