J'ai vu des gens dire que les setobjets en python ont une vérification d'appartenance O (1). Comment sont-ils mis en œuvre en interne pour permettre cela? Quel type de structure de données utilise-t-il? Quelles autres implications cette mise en œuvre a-t-elle?
Chaque réponse ici était vraiment éclairante, mais je ne peux en accepter qu'une, donc je vais aller avec la réponse la plus proche de ma question initiale. Merci à tous pour l'info!
Réponses:
Selon ce fil :
En effet, les ensembles de CPython sont implémentés comme quelque chose comme des dictionnaires avec des valeurs factices (les clés étant les membres de l'ensemble), avec quelques optimisations qui exploitent ce manque de valeurs
Donc, fondamentalement, a setutilise une table de hachage comme structure de données sous-jacente. Cela explique la vérification de l'appartenance à O (1), car la recherche d'un élément dans une table de hachage est une opération O (1), en moyenne.
Si vous êtes si enclin, vous pouvez même parcourir le code source de CPython pour l'ensemble qui, selon Achim Domma , est principalement un copier-coller de l' dictimplémentation.
Quand les gens disent que les ensembles ont une vérification d'appartenance O (1), ils parlent du cas moyen . Dans le pire des cas (lorsque toutes les valeurs hachées entrent en collision), la vérification d'appartenance est O (n). Voir le wiki Python sur la complexité du temps .
L' article de Wikipédia indique que la meilleure complexité temporelle pour une table de hachage qui ne se redimensionne pas est O(1 + k/n). Ce résultat ne s'applique pas directement aux ensembles Python car les ensembles Python utilisent une table de hachage qui se redimensionne.
Un peu plus loin, l'article de Wikipedia dit que pour le cas moyen , et en supposant une simple fonction de hachage uniforme, la complexité temporelle est O(1/(1-k/n)), où k/npeut être délimitée par une constante c<1.
Big-O se réfère uniquement au comportement asymptotique comme n → ∞. Puisque k / n peut être borné par une constante, c <1, indépendante de n ,
O(1/(1-k/n))n'est pas plus grand que O(1/(1-c))ce qui équivaut à O(constant)= O(1).
Donc, en supposant un hachage simple et uniforme, en moyenne , la vérification d'appartenance pour les ensembles Python est O(1).
Je pense que c'est une erreur courante, la setrecherche (ou la table de hachage d'ailleurs) ne sont pas O (1).
sur Wikipédia
Dans le modèle le plus simple, la fonction de hachage est totalement non spécifiée et la table ne se redimensionne pas. Pour le meilleur choix possible de la fonction de hachage, une table de taille n avec adressage ouvert n'a pas de collisions et contient jusqu'à n éléments, avec une seule comparaison pour une recherche réussie, et une table de taille n avec chaînage et k clés a le minimum max. (0, kn) collisions et O (1 + k / n) comparaisons pour la recherche. Pour le pire choix de fonction de hachage, chaque insertion provoque une collision et les tables de hachage dégénèrent en recherche linéaire, avec Ω (k) comparaisons amorties par insertion et jusqu'à k comparaisons pour une recherche réussie.
Connexes: Un hashmap Java est-il vraiment O (1)?
Nous avons tous un accès facile à la source , où le commentaire précédent set_lookkey()dit:
/* set object implementation
Written and maintained by Raymond D. Hettinger <python@rcn.com>
Derived from Lib/sets.py and Objects/dictobject.c.
The basic lookup function used by all operations.
This is based on Algorithm D from Knuth Vol. 3, Sec. 6.4.
The initial probe index is computed as hash mod the table size.
Subsequent probe indices are computed as explained in Objects/dictobject.c.
To improve cache locality, each probe inspects a series of consecutive
nearby entries before moving on to probes elsewhere in memory. This leaves
us with a hybrid of linear probing and open addressing. The linear probing
reduces the cost of hash collisions because consecutive memory accesses
tend to be much cheaper than scattered probes. After LINEAR_PROBES steps,
we then use open addressing with the upper bits from the hash value. This
helps break-up long chains of collisions.
All arithmetic on hash should ignore overflow.
Unlike the dictionary implementation, the lookkey function can return
NULL if the rich comparison returns an error.
*/
...
#ifndef LINEAR_PROBES
#define LINEAR_PROBES 9
#endif
/* This must be >= 1 */
#define PERTURB_SHIFT 5
static setentry *
set_lookkey(PySetObject *so, PyObject *key, Py_hash_t hash)
{
...Pour souligner un peu plus la différence entre set'set dict's, voici un extrait des setobject.csections de commentaires, qui clarifie la principale différence entre les sets et les dictionnaires.
Les cas d'utilisation des ensembles diffèrent considérablement des dictionnaires où les clés recherchées sont plus susceptibles d'être présentes. En revanche, les ensembles concernent principalement les tests d'appartenance où la présence d'un élément n'est pas connue à l'avance. En conséquence, l'implémentation d'ensemble doit être optimisée pour le cas trouvé et non trouvé.
source sur github
setimplémentation d' origine était en faitdictavec des valeurs factices, et elle a été optimisée plus tard.