unordered map

Version imprimable

18/01/2010, 07h53
guillaume07

unordered map

Bonjour,

j'utilise unordered map fournit dans le TR1 avec visual 2008

Mes clefs sont de type std::string et mes donn�es stock�es sont des structure contenant des std::string, des std::vector un int et un QTime

Puis-je utiliser la hash et fonction equal fournit par d�faut ?

J'ai d�j� fait ainsi, mais au final , �a s'av�re plus lent qu'avec une std::map classique..

LA fonction find doit �tre en th�orie plus rapide avec la hash map , vrai ou faux ?

une id�e du probl�me ?
Merci !
18/01/2010, 09h51
Lavock
La complexit� d'une table de hachage est inf�rieur � celle d'une map. Toutefois, dans le cas des string par exemple, la fonction de hachage est assez lourde.

En cos�quence, pour n donn�es, tu aura par exemple :
- 10 + log (5n) op�ration pour une map
- 200 Pour une table de hachage.
Donc il va falloir que tu es une grande table pour compensez le coefficient constant.
18/01/2010, 09h57
camboui

Il me semble qu'il existe des fonctions hash pour string plus efficaces que d'autres.
Cherche apr�s djb2 par exemple.

EDIT: la fonction ci-dessous de Guillaume est justement djb2.

j'utilise celle ci :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
struct Hash : std::unary_function<std::string, std::size_t>
{ 
    std::size_t operator()(const std::string & s) const
    {
        int nb = s.length();
        unsigned char *str = new unsigned char [ s.length()+1 ];
        std::stringstream ss;
        ss >> *str;
        str[s.length()]='\0';
 
        std::size_t hash = 5381;
        while(*str!='\0') 
        {
                int c = *str;
                    /* hash = hash*33 + c */
                    hash = ((hash << 5) + hash) + c;
                    str++;
        }
        return hash;
    }
};

18/01/2010, 10h22
JolyLoic

Une hash map n'est d�j� g�n�ralement plus rapide que pour de grandes quantit�s de donn�es.

Ensuite, elle n'est plus rapide que si la fonction de hash est bonne. Il n'est pas possible de concevoir une fonction bonne pour toutes les cha�nes, si tes cha�nes ont une forme sp�cifique, une fonction de hash sp�cifique est peut-�tre souhaitable. Il serait int�ressant de connaitre le nombre de collisions que tu as dans ta structure.
18/01/2010, 10h26
guillaume07
Citation:
Envoy� par Lavock

La complexit� d'une table de hachage est inf�rieur � celle d'une map. Toutefois, dans le cas des string par exemple, la fonction de hachage est assez lourde.

En cos�quence, pour n donn�es, tu aura par exemple :

10 + log (5n) op�ration pour une map
200 Pour une table de hachage.

Donc il va falloir que tu es une grande table pour compensez le coefficient constant.
� partir du moment o� 10 + log (5n) > 200 Hash map est plus performante donc?
c'est bien log et pas ln ?

log(5*100000) par exemple me donne un petit chiffre
18/01/2010, 10h31
camboui

J'ai le souvenir d'avoir lu quelque part que les URL �taient un type de string souvent difficile � hasher car elles sont souvent longues avec peu de caract�res changeant d'une page � l'autre pour un m�me site.
Il me semble qu'il y a une fonction pour ce cas de figure mais je ne la retrouve pas.
18/01/2010, 10h32
guillaume07

Citation:

Envoy� par JolyLoic

Une hash map n'est d�j� g�n�ralement plus rapide que pour de grandes quantit�s de donn�es.

Ensuite, elle n'est plus rapide que si la fonction de hash est bonne. Il n'est pas possible de concevoir une fonction bonne pour toutes les cha�nes, si tes cha�nes ont une forme sp�cifique, une fonction de hash sp�cifique est peut-�tre souhaitable. Il serait int�ressant de connaitre le nombre de collisions que tu as dans ta structure.

toutes mes chaines ont cette allure : "B0221800N05CF1C"
Pour les collisions, je n'ai pas le chiffre
18/01/2010, 10h35
Lavock

Citation:

Envoy� par guillaume07

� partir du moment o� 10 + log (5n) > 200 Hash map est plus performante donc?

Oui, mais

Citation:

Envoy� par guillaume07

c'est bien log et pas ln ?

log(5*100000) par exemple me donne un petit chiffre

C'�tait qu'un exemple. Ne prend pas ces chiffres comme mod�le.

[hs] Log ou ln, c'est pareil. Je sais pas pourquoi les calculatrices semble avoir adopt� une norme pour log = log base 10 et ln = log base e >< !
Quoi qu'il en soit, selon tes notations, log = ln / ln 10.

Citation:

Envoy� par guillaume07

j'utilise celle ci :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
struct Hash : std::unary_function<std::string, std::size_t>
{ 
    std::size_t operator()(const std::string & s) const
    {
        int nb = s.length();
        unsigned char *str = new unsigned char [ s.length()+1 ];
        std::stringstream ss;
        ss >> *str;
        str[s.length()]='\0';
 
        std::size_t hash = 5381;
        while(*str!='\0') 
        {
                int c = *str;
                    /* hash = hash*33 + c */
                    hash = ((hash << 5) + hash) + c;
                    str++;
        }
        return hash;
    }
};

Je viens de voir qu'il y a un new et un stringstream l�-dedans 8O
L� je ne m'�tonne plus si on me dis que ce n'est pas performant !
Ceci est tellement plus simple (et intuitif)

Code:

const unsigned char *str = s.c_str();

18/01/2010, 12h03
Goten

Au del� de �a (et oui t'as raison), le stringstream est... vide l�.. donc euh, il va rien ce passer.
�a serait plut�t :
std::stringstream ss(s);
ss >> str;

edit : const char vers const unsigned char, le compilo va pas aimer :).
18/01/2010, 12h07
guillaume07

oui d�sol�, erreur dans le C+c C+v du bout de code,
initialement je faisais bien �a

const unsigned char *str = static_cast<const unsigned char *>(s.c_str());

j'avais juste un doute concernant le casting en unsigned, donc j'ai test� avec un stringstream( que j'initialis� bien) voir si �a changer quelquechose
18/01/2010, 12h08
Goten

Et accessoirement un delete[] serait pas superflu...
18/01/2010, 12h21
guillaume07

:oops:
18/01/2010, 15h30
Lightness1024
Citation:
Envoy� par Lavock

La complexit� d'une table de hachage est inf�rieur � celle d'une map. Toutefois, dans le cas des string par exemple, la fonction de hachage est assez lourde.

En cos�quence, pour n donn�es, tu aura par exemple :

10 + log (5n) op�ration pour une map
200 Pour une table de hachage.

Donc il va falloir que tu es une grande table pour compensez le coefficient constant.
:) pr�cise les choses:

pour les cha�nes il faut raisonner en terme de nombre de caracteres.
les operations pour les map sont: log(inf_comparaison)
et pour les hash_map sont: 1xMakeHash + amortized O1(equality_compare)

faire une comparaison d'inf�riorit� peut �tre interrompu rapidement si les premiers caracteres des chaines diff�rent.
pour faire un hash il faut forc�ment lire tous les caracteres, mais UNE fois.

qui sera plus rapide ? :)
18/01/2010, 16h12
Lavock

Citation:

Envoy� par Lightness1024

pour faire un hash il faut forc�ment lire tous les caracteres, mais UNE fois.

Qu'est-ce qui m'emp�che de faire une fonction de hachage en ne regardant que N caract�res ?

De mani�re g�n�rale, ont peu remarquer que les map de string "paniquent" un peu lorsqu'on on les soumet � des chaines de caract�re longue est semblable... Modulo le fait qu'on puisse aussi passer un comparateur, et que le dit comparateur peut �tre personnalis� !*

De mani�re g�n�ral, on retiens que � m�me complexit� de chaine, utilis� une table de hachage plut�t qu'une map est d'autant plus avantageux qu'il y a d'�l�ment; mais qu'en dessous d'un certain nombre cela ne vaut pas le coup.

* Par exemple, pour des num�ros de s�ries, on peut g�n�ralement d�gager des "groupes" qui on souvent une valeur identique. On pourra, au lieu de comparer tout, sauter ais�ment certain caract�re, ~~s'il n'est pas n�cessaire de pouvoir parcourir une liste class� de la map.~~

Edit : A y r�fl�chir, le dernier "si" n'as pas lieu d'�tre. Je crois pas qu'une map n�cessite de pouvoir �tre parcourue par ordre de grandeur de ces clefs (j'ai mis les balise S pour le jours ou le fofo g�rera la balise strike :P ).