
We don't need no thought control. [?]
¡Añademe a tus favoritos!
Contacto
Post al azar
RSS
BUSCAR
Mapa de la web
This is the code from one of the clients used in the post "Statistics on getting a random row from a table" to check for the quickest way to access a random row.
It does nothing but reading a thousand random rows, I hope it's enough for you to learn how to access MySQL databases using Perl and use it as a quickstart for your own scripts.
#!/usr/bin/perl
use DBI;
use DBD::mysql;
$platform = "mysql";
$database = "database";
$host = "server_ip";
$port = "3306";
$user = "user";
$pw = "12345";
$dsn = "dbi:$platform:$database:$host:$port";
$connect = DBI->connect($dsn, $user, $pw);
for ($i=0; $i<1000; $i++)
{
$query = "SELECT COUNT(1) AS total FROM bench_myisam";
$query_handle = $connect->prepare($query);
$query_handle->execute();
$query_handle->bind_columns(\$total);
if ($query_handle->fetch())
{
$rand = int(rand($total));
$query = "SELECT id FROM bench_myisam LIMIT 1 OFFSET $rand";
$query_handle = $connect->prepare($query);
$query_handle->execute();
$query_handle->bind_columns(\$id);
$query_handle->fetch();
}
}
Esta es mi entrada para el reto de encontrar el punto fijo de MD5 que mencionaron el otro dia en programming.reddit. No es un código muy limpio, sino más bien una prueba de concepto para ver que tal se portaba Java... y se porta tres ordenes de magnitud más lento que las implementaciones en C tirando de OpenSSL que usa el ganador (amén de una granja de P4).
En mi maquina de casa, este código me saca unas 44.000 sumas por segundo por nucleo, muy lejos de los millones por segundo de las versiones en código nativo.
package com.saiyine.experimentos.md5;Via Mundogeek descubro que desde hace unos añitos, parece ser que desde la especificación Java 1.5, se puede pasar un número variable de parámetros a cualquier método.
En realidad se convierte en un array en tiempo de compilación, pero que se le va a hacer, algo es algo. Además, puntos extra por utilizar un foreach para la demostración.
public class Conjunto { public Conjunto(String... cadenas) { for (String cadena : cadenas) System.out.println(cadena); } public static void main(String... args) { Conjunto saludos = new Conjunto("Hola", "Ciao", "Hello"); Conjunto mascotas = new Conjunto("Pulpo"); } }
Como lo prometido es algo que debe cumplirse, aqui llevais mi primera obra maestra en Processing.
Aunque la primera impresión es que el entorno de programación es una porqueria, y a los 10 minutos ya estaba revisando si se le puede echar mano al código fuente y hacer que el cortar y pegar funcione como dios manda, tengo que admitir que la idea en si es bastante buena: una abstracción basada en la maquina virtual de Java para trabajar con gráficos.
Todo funciona al pelete, aunque igual la ayuda es un poco petarda y el entorno es una mierda. Es sopar unos cuantos ejemplos y ya lo tienes todo para concentrarte en trabajar con imagenes directamente con los valores RGB de cada punto. A ver si encuentro mis viejos programas en Pascal de cuando programar en VGA con 256 colores era tirar un puntero y a jugar, y los vuelvo a la vida con este programazo.
¡Además punto extra porque uno de los dos tipos que han montado esto se apellida Fry! ¡Jugón!
/**

¡Que ven mis ojos, si Mayo ya está aquí! Y además en menudas fechas caen el 1 y el 2, martes y miercoles, fiesta nacional el primero y madrileña el segundo, lo que unidas a una más que generosa política de puentes de mis empleadores, hacen que me vaya a pegar cinco dias sin pegar un palo al agua, y por el módico precio de aguantar los tremendos problemas de tráfico de la autovia que me separa de mi tierra.
Bueno, en realidad eso de estar sin dar ni golpe tampoco es que vaya mucho conmigo, así que voy a aprovechar para desfacer todos los entuertos que pueda en la página, empezando por una antiquisima petición de Yhandros que ha resultado la mar de simple: el enlace de comentar ya va directo a los comentarios. En realidad a mi me da igual, o incluso prefiero tener delante el texto que voy a mejorar con mis comentarios de calidad, pero si el vulgo lo demanda, que así sea.
Otra mejora que tenia en mente desde tiempos antediluvianos era añadir la capacidad de hacer pings XMLRPC...
Ya, ya sé que todos sabeis de sobra de que hablo, pero por si acaso alguien ha llegado tarde o no tiene en la mesilla de noche mi último bestseller "En la cama con Saiyine" debo contar que, resumiendo infinitamente, hacer ping es hacerse notar.
No sé de donde viene la equivalencia, aunque apostaria a un origen basado en los sonares activos: los típicos sonidos de las pelis de submarinos ¡PING! ¡PONG!, que no son más que una versión burra de la ecolocalización de los morciguillos. De verdad que no me quiero liar, aunque ya me conoceis y podria llenar hojas y hojas con los problemas que los sonares activos les causan a los cetaceos, los jueguecitos americanos y sovieticos en la guerra fria con los sonares, las otras aplicaciones informaticas que utilizan el concepto, la equivalencia física con otros sistemas similares como el radar o el lidar, o las ventajas de los sonares pasivos arrastrados, entiendo que todo eso os da igual y prefiero no espesar mucho la entrada.
Me limitaré a decir que hacer ping en el contexto de las páginas web es mandar una señal a otras webs diciendo, hey, que tengo un rollo nuevo, y esperar recibir el lógico pong de esas webs confirmando que han actualizado sus enlaces con la nueva información.
Los que useis Wordpress o basuras similares supongo que solo tendreis que bajaros el plujin adecuado y tan contentos, pero los que, como yo, prefieren que su página siga siendo suya al ciento por ciento, no estar a la merced de errores ajenos, o simplemente que les guste programar, estabamos abonados a usar librerias extrañas para hacer algo que en realidad se me antojaba sencillísimo: enviar una petición web con una pizca de XML.
¿Solo para esa chorrada tengo que liarme con obtusas librerias experimentales??? Eso no va conmigo.
Así que en cuanto he tenido un rato, me he puesto al tema y lo he conseguido en unas poquisimas lineas. Ni siquiera he tenido que montarme historias de sockets como pensaba en un principio, los simples manejadores del PHP, que permiten acceder a una url como si fuera un fichero local me lo han dado todo practicamente hecho:
<?phpSencillisimo, ¿verdad?
Este PHP avisa a la conocida página technorati de que deberia echarle un vistazo a nuestra página. Lo suyo seria ejecutarlo cada vez que escribais un rollo en vuestras páginas, una vez actualizada la base de datos, y dejar que las visitas lleguen a trillones en busca de novedades.
Naturalmente, hay montones de páginas que se dedican simplemente a ser listas de las actualizaciones de otras como las nuestras, lamentablemente, tengo los enlaces en mi maquina portable, en cuanto la monte mando otro rollo con listas de direcicones a las que hacer ping para que vuestros blogs sean ultrafamosos y estén supervitaminados e hipermineralizados.
Los códigos de Huffman son posiblemente la variante más conocida de los compresores estadísticos, que aprovechan las características estadísticas de los datos de entrada asignando códigos más cortos a los datos que mas se repiten, logrando así un efecto compresor.
Para lograrlo, el compresor debe recorrer una vez el vector con la información entrante para crear una tabla con la frecuencia de cada carácter, y luego otra vez para traducir la fuente en los códigos adecuados. Esta doble pasada no siempre es posible, y aquí es donde entran las variantes adaptativas, que son capaces de generar la compresión en una sola pasada, al ir modificando los códigos de salida conforme van llegando nuevos códigos a la entrada.
El algoritmo
Como ya mencioné anteriormente, la compresión Huffman adaptativa se diferencia de la normal en que los datos estadísticos se generan en la misma pasada que se envían los códigos de salida, y esto tiene un problema evidente: ¿cómo se envía un dato que aún no ha sido registrado en la tabla de símbolos? ¡Reconstruir la tabla con cada carácter nuevo requeriría muchísimo tiempo de CPU!
Por ello, lo que se hace es modificar el árbol binario del algoritmo Huffman añadiendo un valor especial llamado NYT, not yet transmitted, que servirá como marcador de nuevo carácter, es decir, si tenemos la entrada “arañar”, la salida seria “NYT a NYT r CODIGO(a) NYT ñ CODIGO(a) CODIGO(r)”.
Otro problema que surge es el de la optimalidad de los códigos, ya que si simplemente vamos añadiendo caracteres al árbol estadístico conforme aparecen en la entrada, se perderían las ventajas de la compresión Huffman. Por ello, cada vez que se lee un carácter hay que actualizar el árbol, que pasa a ser bastante mas complejo que el algoritmo no adaptativo, de una manera determinada, dependiendo de si es un nuevo carácter o si ya estaba en el árbol.

Fig.
1. Árbol de ejemplo, conteniendo la palabra “abra”
Los nuevos elementos que podemos advertir en el árbol binario del algoritmo adaptativo frente al clásico son la presencia del código NYT, la numeración de los nodos y un contador de cada carácter. Con este contador llevamos la cuenta de cuantas veces ha aparecido el valor, y es lo que definirá en que posición del árbol pondremos al carácter en caso de reorganización, mientras que la numeración nos servirá para decidir que nodos deben intercambiar su posición.
Un ejemplo paso a paso
Veamos con un ejemplo como funciona el algoritmo, usando la palabra “abracadabra”.

Fig.
2. Árbol vacío
Comenzamos con un árbol vacío, al que le llega el primer carácter, “a”.

Fig.
3. Árbol para “a”
Con la llegada del primer dato, el algoritmo envía el dato tal cual, “a” y después genera los primeros nodos del árbol, es decir, el nodo para el NYT, con el contador a cero, y el del propio dato, con el contador a uno, y el nodo padre, el raíz en este caso, con la suma de los contadores de sus hijos.

Fig.
4. Árbol para “ab”
Tenemos un nuevo dato, así que enviamos el NYT para comunicárselo al destino, seguido del propio dato, por lo que el mensaje enviado completo por el momento es “a 0b”. Este mensaje realmente se compone de los ocho bits del símbolo “a”, seguido del bit 0 y de los ocho de “b”, por lo que es importante que tanto compresor como receptor estén de acuerdo en el tamaño del dato base, que en el programa que nos ocupa es de ocho bits.
Una vez enviados los nuevos códigos, se reestructura el árbol añadiendo el nuevo carácter “b” como hijo derecho del NYT, y creando un nuevo NYT como hijo izquierdo, y actualizando los contadores en cascada hacia la raíz, efectivamente creando un árbol balanceado.

Fig. 5a. Árbol para “abr” no actualizado
Con el nuevo carácter “r” llegamos a un punto crucial del algoritmo: la actualización del árbol. Primero, se manda el NYT y el dato r, con lo que el mensaje comprimido es ahora “a 0b 00r” (recordemos que siempre se mandan los NYT de antes de meter el nuevo carácter en el árbol). Lo introducimos en el lugar del NYT y llegamos a una posición en la que no se cumple la posición de balanceo del árbol, ya que el nodo 49 tiene el valor 2, suma de los valores de sus dos hijos, mientras que su hermano 50 tiene el valor 1, ya que el carácter “a” solo ha aparecido una vez hasta ahora. Por lo tanto, los intercambiamos, en un ajuste de balanceo que en este algoritmo es llamado simplemente proceso de ajuste del árbol.

Fig.
5b. Árbol para “abr” actualizado
Otro carácter “a”, que como ya está en el árbol es enviado comprimido, con lo que tenemos “a 0b 00r 0”.

Fig.
6. Árbol para “abra”
Ahora es el turno del dato “c”, que como no está en el árbol, mandamos el NYT y el dato en claro: “a 0b 00r 0 100c”. Después lo añadimos al árbol.

Fig. 7a. Árbol para “abrac” no actualizado
De nuevo el árbol necesita ser actualizado, ya que los nodos 47 y 48 han dejado de cumplir la condición de balanceo.

Fig.
7b. Árbol para “abrac” actualizado
Otra “a”, con lo que el mensaje completo es ahora “a 0b 00r 0 100c 0”.

Fig.
8. Árbol para “abraca”
El dato “d” es nuevo, así que lo enviamos (“ a 0b 00r 0 100c 0 1100d ”)y expandimos el nodo de NYT para acomodarlo. Además, va a desequilibrar el árbol, que necesitará un ajuste.

Fig.
9a. Árbol para “abracad” antes de actualizar

Fig.
9b. Árbol para “abracad” balanceado
La tercera “a”, con lo que el mensaje comprimido es ahora “a 0b 00r 0 100c 0 1100d 0”.

Fig.
10. Árbol para “abracada”
El siguiente carácter “b”, aunque ya está en el árbol y podría parecer que simplemente bastaría con aumentar su contador y enviar su código, en realidad va a generar un proceso interesante que podría cambiar el árbol casi por completo: una actualización en cascada.

Fig.
11a. Árbol para “abracadab” sin actualizar
Primero, los nodos 45 y 46 deben ser intercambiados, ya al aumentar el contador de b, su nodo tiene mas “peso” que su hermano derecho.

Fig.
11b. Árbol para “abracadab” actualizándose
Intercambiados los nodos, aumentamos el valor de “b” y de los padres hasta la raíz, verificando en cada nodo si es necesaria una nueva actualización, aunque en este ejemplo no se da el caso.

Fig. 11c. Árbol para “abracadab” actualizado
Los dos caracteres que faltan, “r” y “a”, no tienen mucha historia, simplemente enviamos el código y actualizamos los contadores correspondientes, con lo que el código final es “a 0b 00r 0 100c 0 1100d 0 110 110 0”, es decir, 60 bits, frente a los 88 que harían falta para mandar el mensaje sin comprimir.

Fig.
12. Árbol para “abracadabr”

Fig.
13. Árbol para “abracadabra”
La descompresión
Ahora veamos un ejemplo de descompresión. Tenemos la cadena “a 0b 00r 0 100c 0 1100d 0 110 110 0” (de nuevo, imaginemos que en vez de los caracteres tenemos grupos de 8 bits con la representación ascii de dichos caracteres). Leemos los primeros ocho bits, ya que forzosamente el primer carácter debe estar sin codificar, con lo que ya tenemos la “a”, y la introducimos en el árbol. El siguiente dato, o bien es un uno si es otra vez la “a”, o es un cero para indicar el valor NYT. En nuestro caso, es un cero, así que lo leemos y los siguientes ocho bits, con lo que ya tenemos “ab”.
Ahora el descompresor tendría en su memoria un árbol análogo al de la figura 4, por lo que al leer un cero sabemos que debemos leer al menos un bit más. Efectivamente, nos llega otro cero, con lo que tenemos un NYT. Leemos otros ocho bits y ya tenemos “abr”. Actualizamos el árbol, igual que hacíamos en la compresión, y leemos un cero, lo que nos indica que tenemos otra “a”.
Leemos un bit y tenemos un uno, que no es ningún código conocido, leemos otro y tenemos uno-cero, que sigue siendo desconocido. Volvemos a leer y tenemos uno-cero-cero, que en la disposición actual del árbol ( fig 6 ) es un NYT. Leemos ocho bits más, tenemos “abrac”. Sacamos un cero de la cadena, y como sabemos por el árbol que es una “a”, tenemos “abraca”.
Se lee bit a bit hasta que tenemos una combinación con significado, y en este caso, se trata de nuevo de un NYT, acompañado de los ocho bits de la “d”, con lo que el código hasta ahora es “abracad”. Hasta el final, tenemos caracteres sueltos que completan el mensaje, que es, claro esta, “abracadabra”.