Histogramas

Uso análisis de frecuencia muy seguido. Una especie de

SELECT COUNT(*), campo FROM cosa GROUP BY campo

se logra en shell scripts con

sort | uniq -c

(siempre que consideremos que 'campo' es toda la línea)

El comando uniq toma el input y lo repite en el output, removiendo duplicados. La opción -c indica la cantidad de repeticiones. Como no ordena, tenemos que hacerlo previamente.

Si hiciéramos simplemente uniq -c, nos podrían quedar varios bloques para el mismo valor.

Pero si nuestro input tiene grandes bloques de valores repetidos, un sort de todos contra todos los valores gastaría tiempo en ordenar internamente esos bloques, cuando uniq -c los reduciría rápidamente.

Hoy me soprendí una vez más de la potencia de awk. Mi idea fue hacer un uniq -c inicial, sin sort, y resolver la duplicación de bloques con awk, así:

uniq -c | awk '{h[$2]+=$1} END {for (i in h) print h[i],i}'

O si queremos emular EXACTA y coquetamente el resultado del uniq:

uniq -c | awk '{h[$2]+=$1} END {for (i in h) printf "%7d %d\n", h[i],i}'

Explico:

Para cada línea del uniq -c que es de forma:

Metemos en un array asociativo indexado por "valor" la frecuencia (sumando al valor que ya tenemos).

Cuando llegamos al final (END), mostramos el array.

Hice cuentas con un archivo de 7.9Gb con grandes bloques, y para mi asombro sort no la pasó taaan mal. Sospecho que sort está usando alguna clase de mergeSort para ordenamiento en memoria secundaria.

Comparo los tiempos de hacer un simple uniq -c (que no resuelve nuestro porblema), un sort | uniq -c y mi sugerencia. Asombrosamente, el mío anda más rápido que el uniq -c a solas. Creo que eso está dentro de la tolerancia de la medición, o hubieron factores externos en el server.

uniq.time

real    5m40.97s

user    6m25.65s

sys     0m2.47s

sort.time

real    7m4.77s

user    7m26.90s

sys     0m4.57s

mio.time

real    5m37.56s

user    6m20.91s

sys     0m2.35s