He visto a gente decir que los setobjetos en python tienen O (1) verificación de membresía. ¿Cómo se implementan internamente para permitir esto? ¿Qué tipo de estructura de datos utiliza? ¿Qué otras implicaciones tiene esa implementación?
Cada respuesta aquí fue realmente esclarecedora, pero solo puedo aceptar una, así que iré con la respuesta más cercana a mi pregunta original. ¡Gracias a todos por la información!
Respuestas:
De acuerdo con este hilo :
De hecho, los conjuntos de CPython se implementan como algo así como diccionarios con valores ficticios (las claves son los miembros del conjunto), con algunas optimizaciones que aprovechan esta falta de valores.
Entonces, básicamente, setusa una tabla hash como su estructura de datos subyacente. Esto explica la verificación de membresía O (1), ya que buscar un elemento en una tabla hash es una operación O (1), en promedio.
Si está tan inclinado, incluso puede navegar por el código fuente de CPython para el conjunto que, según Achim Domma , es principalmente cortar y pegar desde la dictimplementación.
Cuando las personas dicen que los conjuntos tienen O (1) verificación de membresía, están hablando del caso promedio . En el peor de los casos (cuando todos los valores hash colisionan) la verificación de membresía es O (n). Vea el wiki de Python sobre la complejidad del tiempo .
El artículo de Wikipedia dice que la mejor complejidad de tiempo de caso para una tabla hash que no cambia de tamaño es O(1 + k/n). Este resultado no se aplica directamente a los conjuntos de Python ya que los conjuntos de Python usan una tabla hash que cambia el tamaño.
Un poco más adelante en el artículo de Wikipedia dice que para el caso promedio , y suponiendo una función de hashing uniforme simple, la complejidad del tiempo es O(1/(1-k/n)), donde k/npuede estar limitada por una constante c<1.
Big-O se refiere solo al comportamiento asintótico como n → ∞. Como k / n puede estar limitado por una constante, c <1, independiente de n ,
O(1/(1-k/n))no es más grande que lo O(1/(1-c))que equivale a O(constant)= O(1).
Entonces, suponiendo un hashing simple y uniforme, en promedio , la verificación de membresía para conjuntos de Python es O(1).
Creo que es un error común, la setbúsqueda (o tabla hash) no son O (1).
de la Wikipedia
En el modelo más simple, la función hash está completamente sin especificar y la tabla no cambia de tamaño. Para la mejor elección posible de la función hash, una tabla de tamaño n con direccionamiento abierto no tiene colisiones y contiene hasta n elementos, con una sola comparación para una búsqueda exitosa, y una tabla de tamaño n con encadenamiento y teclas k tiene el mínimo máximo (0, kn) colisiones y O (1 + k / n) comparaciones para la búsqueda. Para la peor elección de la función hash, cada inserción provoca una colisión, y las tablas hash degeneran en búsqueda lineal, con Ω (k) comparaciones amortizadas por inserción y hasta k comparaciones para una búsqueda exitosa.
Relacionado: ¿Es un hashmap de Java realmente O (1)?
Todos tenemos acceso fácil a la fuente , donde el comentario anterior 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)
{
...Para enfatizar un poco más la diferencia entre set'sy dict's, aquí hay un extracto de las setobject.csecciones de comentarios, que aclara la principal diferencia de los conjuntos contra los dictados.
Los casos de uso para conjuntos difieren considerablemente de los diccionarios donde es más probable que las claves buscadas estén presentes. En contraste, los conjuntos son principalmente sobre pruebas de membresía donde la presencia de un elemento no se conoce de antemano. En consecuencia, la implementación del conjunto debe optimizarse tanto para el caso encontrado como para el no encontrado.
fuente en github
setimplementación original en realidad eradictcon valores ficticios, y se optimizó más tarde.