Ho visto persone dire che gli setoggetti in Python hanno il controllo dell'appartenenza O (1). Come vengono implementati internamente per consentire ciò? Che tipo di struttura dati utilizza? Quali altre implicazioni ha questa implementazione?
Ogni risposta qui è stata davvero illuminante, ma posso accettarne solo una, quindi andrò con la risposta più vicina alla mia domanda originale. Grazie a tutti per le informazioni!
Risposte:
Secondo questa discussione :
In effetti, i set di CPython sono implementati come qualcosa di simile ai dizionari con valori fittizi (le chiavi sono i membri del set), con alcune ottimizzazioni che sfruttano questa mancanza di valori
Quindi fondamentalmente a setusa un hashtable come struttura di dati sottostante. Questo spiega il controllo dell'iscrizione O (1), poiché la ricerca di un elemento in una tabella hash è un'operazione O (1), in media.
Se sei così incline, puoi anche sfogliare il codice sorgente di CPython per un set che, secondo Achim Domma , è per lo più un taglia e incolla dall'implementazione dict.
Quando le persone dicono che i set hanno un controllo dell'iscrizione O (1), stanno parlando del caso medio . Nel caso peggiore (quando tutti i valori con hash si scontrano) il controllo dell'appartenenza è O (n). Guarda la wiki di Python sulla complessità temporale .
L' articolo di Wikipedia afferma che la migliore complessità temporale per una tabella hash che non viene ridimensionata è O(1 + k/n). Questo risultato non si applica direttamente ai set Python poiché i set Python utilizzano una tabella hash che si ridimensiona.
Un po 'più avanti sull'articolo di Wikipedia afferma che per il caso medio , e assumendo una semplice funzione di hashing uniforme, la complessità del tempo è O(1/(1-k/n)), dove k/npuò essere delimitata da una costante c<1.
Big-O si riferisce solo al comportamento asintotico come n → ∞. Poiché k / n può essere limitato da una costante, c <1, indipendente da n ,
O(1/(1-k/n))non è più grande di quello O(1/(1-c))che equivale a O(constant)= O(1).
Quindi, supponendo un hashing semplice uniforme, in media , il controllo dell'appartenenza per i set Python lo è O(1).
Penso che sia un errore comune, la setricerca (o hashtable per quella materia) non sono O (1).
da Wikipedia
Nel modello più semplice, la funzione hash è completamente non specificata e la tabella non viene ridimensionata. Per la migliore scelta possibile della funzione hash, una tabella di dimensione n con indirizzamento aperto non ha collisioni e contiene fino a n elementi, con un solo confronto per una ricerca riuscita, e una tabella di dimensione n con concatenamento e tasti k ha il massimo minimo (0, kn) collisioni e confronti di O (1 + k / n) per la ricerca. Per la peggiore scelta della funzione hash, ogni inserimento provoca una collisione e le tabelle hash degenerano in ricerca lineare, con confronti ammortizzati Ω (k) per inserimento e fino a k confronti per una ricerca riuscita.
Correlati: un hashmap Java è davvero O (1)?
Tutti abbiamo un facile accesso alla fonte , dove il commento precedente set_lookkey()dice:
/* 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)
{
...
Per enfatizzare un po 'di più la differenza tra set'se dict's, ecco un estratto dalle setobject.csezioni dei commenti, che chiarisce la principale differenza tra set e dicts.
I casi d'uso per gli insiemi differiscono notevolmente dai dizionari in cui è più probabile che siano presenti chiavi di ricerca. Al contrario, i set riguardano principalmente i test di appartenenza in cui la presenza di un elemento non è nota in anticipo. Di conseguenza, l'implementazione impostata deve essere ottimizzata sia per il caso trovato che per quello non trovato.
fonte su github
setimplementazione originale era in realtàdictcon valori fittizi e in seguito è stata ottimizzata.