Cubetas de tabla hash
Prevea 1.000 claves con un factor de carga de 0,75 y necesitará al menos 1.334 cubetas, que se redondean a 2.048 como potencia de dos. También verá la carga real, cuántas claves caben y el margen que queda. Gratis en su navegador.
- Gratis
- Funciona en su navegador
- Sin registro
- Sus datos no salen de su equipo
Ejecutar — gratis
Ejemplo resuelto
- Elementos
- 1 000
- Factor de carga
- 0,75
- Redondeo
- Power of two
- Mínimo de cubetas
- 1 334
- Cubetas
- 2 048
- Factor de carga real
- 0,48828125
- Capacidad
- 1 536
Una tabla hash solo es rápida si el arreglo que hay detrás tiene el tamaño adecuado. Si usted guarda n claves en m cubetas, el factor de carga α = n / m decide cuánto crecen las cadenas, cuándo se agrupa el direccionamiento abierto y con qué frecuencia se dispara un redimensionado. Si elige un m demasiado pequeño, cada consulta recorre un montón de colisiones. Si elige un m excesivo, paga RAM por huecos vacíos que no mejoran la latencia. Esta calculadora de cubetas de tabla hash toma el recuento previsto de elementos, un factor de carga objetivo como el valor por defecto 0.75 de Java HashMap y una estrategia de redondeo, y devuelve la tabla asignable más pequeña que mantiene la ocupación en o por debajo de esa meta. Primero calcula el techo bruto ceil(n / α) y luego redondea ese piso hacia la siguiente potencia de dos o el siguiente primo: los dos tamaños que los mapas de producción asignan de verdad. Los tamaños potencia de dos encajan con los mapas basados en máscara que indexan con el AND bit a bit del hash y (m menos uno). Los tamaños primos encajan con los mapas basados en módulo que indexan con hash mod m.
Por qué el factor de carga, y no un número redondo, debe elegir las cubetas
El factor de carga es el único número de ocupación que viaja entre lenguajes. Java HashMap usa 0.75 por defecto y se redimensiona cuando el tamaño supera la capacidad por ese factor. Rust hashbrown y muchos portados de Swiss-table se acercan a 0.875 antes de crecer.
El código clásico de enseñanza con encadenamiento separado suele apuntar a 0.5 o 1.0. En todos los casos la identidad de planificación es la misma: hacen falta al menos ceil(n / α) huecos si n claves deben quedar en o por debajo de la meta α. Ese techo bruto casi nunca es el número que se asigna.
Las implementaciones basadas en máscara exigen que m sea potencia de dos para que el índice sea un solo AND bit a bit, y por eso 1 000 claves a 0.75 se convierten en 2 048 cubetas y no en 1 334. Las implementaciones basadas en módulo prefieren un primo para que un hash débil siga repartiendo entre clases de residuos, y por eso las mismas 1 000 claves se convierten en el siguiente primo en o por encima de 1 334. Use esas cinco cifras juntas.
Una tabla que subió mucho hasta la siguiente potencia de dos tiene una carga efectiva holgada y un headroom amplio; una que cayó en un primo cercano queda más justa y más cerca de un redimensionado. Adivinar 1 024 o 4 096 porque esos números parecen de informática es cómo un servicio malgasta una página de RAM o dispara un redimensionado en el primer minuto de tráfico.
Cuándo dimensionar así una tabla y sus límites
Use la herramienta del navegador cuando elija la capacidad inicial de un HashMap, redacte un comentario que deba defender por qué el arreglo es 2 048 y no 1 334, o recorra con una revisión la diferencia entre una tabla de máscara y una de módulo. Recorra el factor de carga hasta que el headroom cubra el próximo pico de crecimiento y conserve el m redondeado.
Contraste el resultado con una calculadora de colisiones esperadas una vez conocido m: esa hermana responde cuántas claves comparten cubeta, mientras que esta página responde cuántas cubetas asignar en primer lugar. Las dos búsquedas son tickets distintos y no deben canibalizarse. Los resultados son plenamente deterministas: los mismos items, factor de carga y redondeo producen siempre el mismo vector, de modo que puede fijar ejemplos en pruebas y materiales didácticos.
No hay modelo de lenguaje, ni servicio externo de estadística, ni aleatoriedad.
Qué puede hacer con ella
Capacidad inicial de HashMap y diccionario
Indique el tamaño previsto del conjunto de trabajo y 0.75 (o el valor por defecto de su entorno) para obtener el arreglo potencia de dos que Java, Rust y la mayoría de los mapas de máscara deben asignar.
Tablas de módulo de tamaño primo
Dimensione mapas clásicos de encadenamiento separado o al estilo Hashtable que indexan con hash módulo m redondeando el piso de ocupación al siguiente primo.
Generadores, revisiones y oráculos de CI
Los generadores de código y las plataformas de entrevistas invocan un oráculo de dimensionado determinista que rechaza un recuento de elementos ausente y devuelve el mismo campo buckets para los mismos n y α.
Preguntas frecuentes
¿Conviene redondear el recuento de cubetas a una potencia de dos o a un primo?
Use prime para mapas basados en módulo como el Hashtable clásico de Java, de modo que un hash débil siga repartiendo entre clases de residuos.
¿Es gratuita la calculadora de cubetas de tabla hash?
La herramienta del navegador se ejecuta gratis en su dispositivo.
¿Qué factor de carga conviene elegir?
Depende de la tabla que vaya a usar. El HashMap de Java usa 0,75 por defecto, muchos diseños tipo Swiss table, como hashbrown de Rust, rondan 0,875, y el código didáctico suele apuntar a 0,5 o 1,0. Ajuste el objetivo a la tabla que guardará los datos.
¿Qué significan la capacidad y el margen?
La capacidad es cuántas claves admite la tabla redondeada antes de superar la carga objetivo; el margen es la capacidad menos sus claves. Con 1.000 claves a 0,75 en 2.048 cubetas, la capacidad es 1.536 y el margen 536.
¿Por qué la carga real queda por debajo de mi objetivo?
Porque el número de cubetas se redondea hacia arriba hasta un tamaño que las tablas asignan de verdad. Pasar de 1.334 a 2.048 deja una carga real de 0,48828125, muy por debajo de 0,75, y aleja el próximo redimensionado.
Herramientas relacionadas
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, por email y desde Telegram — y pronto también desde nuestra app.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/dev/hash-table-capacity \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"items":1000,"load_factor":0.75}'const res = await fetch("https://api.kit.forhosting.com/dev/hash-table-capacity", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"items": 1000,
"load_factor": 0.75
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/hash-table-capacity",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"items": 1000,
"load_factor": 0.75
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/hash-table-capacity", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"items":1000,"load_factor":0.75}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"items":1000,"load_factor":0.75}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/hash-table-capacity", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Ejemplo de solicitud
{
"items": 1000,
"load_factor": 0.75
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.hash_table_capacity",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Límites
max_items | 1000000000 |
min_load_factor | 0.05 |
max_load_factor | 1 |
max_buckets | 34359738368 |
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |
Notas técnicas
Por qué el factor de carga, y no un número redondo, debe elegir las cubetas
Esta calculadora hace explícita esa decisión en dos pasos: informa min_buckets (el piso de ocupación), buckets (la asignación redondeada), actual_load_factor (n / m, siempre en o por debajo de la meta tras el redondeo), capacity (cuántas claves caben antes de cruzar la meta) y headroom (capacity menos n).
Contrato de entrada, modos de redondeo, fórmulas y errores
Las potencias de dos se hallan duplicando, no con trucos de 32 bits, de modo que los tamaños por encima de dos elevado a treinta y uno siguen siendo enteros seguros exactos. Los primos se hallan por división de prueba sobre candidatos impares. Envíe por POST un cuerpo JSON con dos campos obligatorios y uno opcional. items es el recuento previsto de claves, un entero de uno a mil millones; se aceptan los alias n, count, expected y keys. load_factor es la α objetivo, un número finito de 0.05 a 1 inclusive; se aceptan los alias load y alpha. 0.75 es el ejemplo y el valor por defecto de Java; 1.0 es una tabla llena; los valores por debajo de 0.05 se rechazan porque describen un arreglo casi vacío y no un mapa de trabajo. rounding es un enum, power_of_two o prime, y por omisión vale power_of_two; se aceptan los alias mode y strategy. Un dominio finito pertenece al enum para que el formulario pinte un selector y la API rechace grafías inventadas. Tras la validación el motor calcula min_buckets = ceil(items / load_factor), corrige un solo paso de coma flotante si el producto aún quedara por debajo de n, y fija buckets en la siguiente potencia de dos o el siguiente primo en o por encima de ese piso. El JSON reitera items, load_factor y rounding, y luego devuelve min_buckets, buckets, actual_load_factor, capacity, headroom, is_power_of_two, is_prime, un campo bits solo en la ruta potencia de dos (logaritmo en base dos de m) y una cadena formula. Si falta items, el factor de carga queda fuera del rango publicado, el recuento no es entero o el redondeo es desconocido, la tarea falla con invalid_input nombrando el campo y no se factura. Esto es un oráculo de dimensionado, no un recuento de colisiones esperadas: combínelo con una herramienta de ocupación de bolas en urnas si también necesita cuántas claves compartirán hueco después de haber elegido m.
Dónde rinde una API de recuento de cubetas, límites y precio
Use la API cuando un generador de código, un entorno de entrevistas, un planificador de fragmentos de caché o una comprobación de integración continua necesite JSON estable para muchos pares (n, α) bajo un mismo contrato. Cada solicitud correcta es un artículo facturable a $0.002; la validación fallida no consume saldo. Los rangos publicados mantienen cada recuento devuelto dentro de enteros seguros IEEE-754 ordinarios y cubren todo mapa en memoria que usted dimensionaría a mano, desde un ejemplo de aula de ocho claves hasta una tabla de internado de mil millones de entradas. Conecte el endpoint a tutoriales de tablas hash, backends de compilador que emiten una tabla estática y plantillas de servicio que deben elegir una capacidad antes de la primera inserción.
Preguntas técnicas
¿Cómo se elige el número de cubetas de una tabla hash a partir de n elementos y un factor de carga?
Envíe items (o n) y load_factor (por ejemplo 0.75). La calculadora devuelve min_buckets = ceil(n/α) y buckets redondeado a la siguiente potencia de dos o al siguiente primo, más la carga efectiva, capacity y headroom.
¿Cuál es la diferencia entre min_buckets y buckets?
min_buckets es el piso de ocupación ceil(items / load_factor). buckets es ese piso redondeado a un tamaño asignable. Por tanto actual_load_factor = items / buckets queda en o por debajo de la meta.
¿Qué ocurre si falta items o el factor de carga queda fuera de rango?
La solicitud falla con invalid_input nombrando el campo. items debe ser un entero de 1 a 1 000 000 000; load_factor debe ser un número finito de 0.05 a 1. Los fallos de validación no se facturan.