Ja us vaig comentar en l’anterior entrada els problemes que presenta la cerca dicotòmica amb cadenes ordenades per ordre lexicogràfic per a buscar alternatives a una cerca que conté algun error. Semblava doncs que l’ordre lexicogràfic no era suficient per a establir la relació que jo necessitava entre els noms de les persones, així que la segona idea que vaig tenir és la d’utilitzar la famosa distància de Levenshtein.

Sols comentar que quan estava escrivint aquest post em vaig adonar que tenia un greu error en el meu algorisme, de fet vaig haver de canviar-lo. Això em va servir per a entendre bé aquest nou algorisme que explique ací i millorar alguns aspectes en la implementació del meu programa. Eixe és el motiu pel qual m’ha dut quasi una setmana publicar aquesta entrada.

Avisar-vos també que aquest post és molt més llarg i pesat que l’anterior, això sí, molt més interessant també. Els algorismes que ací descric no són cosa meua i poden haver errors en la descripció de l’algorisme o la seva complexitat. Evidentment, aquest blog no tracta de ser una font de referència i no deuríeu de confiar excessivament en els detalls que s’expliquen ja que poden ser imprecisos o inclús erronis. Si us interessa el tema i voleu informació en la que pugueu confiar més, sols heu de cercar els termes en articles de la Wikipedia o els algorismes en publicacions de Google Scholar.

Fet aquest avís, comencem.

Distància de Damerau-Levenshtein

La distància de Levenshtein mesura la distància d’edició entre dues cadenes de text en termes d’insercions, esborrats i substitucions. Això és, el nombre mínim d’aquestes operacions que són necessàries per transformar una cadena A en una altra cadena B. Si volem comptar també les transposicions com a operacions, la mètrica s’anomena distància de Damerau-Levenshtein. L’algorisme utilitzat per a computar aquesta mètrica és un clàssic de qualsevol curs de programació dinàmica.

Intentaré explicar l’algorisme de manera breu. Imaginem que volem calcular la distància d’una cadena X a una cadena Y. Llavors és construeix una matriu D de |X|+1 files i |Y|+1 columnes. L’element indica quina és la distància de la subcadena a la subcadena . La fila 0 i la columna 0 representen les distàncies de la cadena a i de la cadena a respectivament ( és la cadena buida, aquella que no conté cap símbol).

Doncs bé, la fórmula per a calcular cada element de la taula és la següent.

Ací teniu un exemple de com quedaria matriu per a les cadenes hola i poal.

Si mirem l’element de la taula, veiem que la distància de Damerau-Levenshtein entre les dues cadenes és 2 (transformacion: hola->pola->poal). Fixeu-vos que és menor que la distància de Levenshtein (que no admet transposicions) i que seria 3.

La gràcia d’aquest algorisme és que pot anar construint-se fila a fila i columna a columna, de manera que el cost temporal de l’algorisme per a dues cadenes de longituds m i n és , a l’igual que el cost espacial.

El problema d’aquesta mètrica és el cost: no és lineal. No era una alternativa adequada simplement computar per a cada cerca la seva distància de Damerau-Levenshtein amb els noms de les persones i quedar-me amb aquelles amb un mínim error. Suposant que tenim n persones i la longitud dels seus noms és aproximadament l, el cost temporal d’aquesta cerca seria , un cost massa alt si el comparem amb el de la cerca dicotòmica ().

Millora d’Ukkonen

El primer que hem de tenir clar és que no necessitem saber la distància exacta entre dues paraules. Imaginem que un usuari s’equivoca escrivint la paraula que busca i escriu ocel. Què serà més probable, que l’usuari estigués buscant una paraula que està a una distància 1 (p.ex: ocell) o que estigués buscant una paraula a una distància 5 (p.ex: tomaca)? Realment, sols estem interessats en saber si la distància entre dues cadenes X i Y és menor o igual que un cert llindar k.

Si estem calculant la distància entre dues cadenes i tenim una fila per a la qual, cap element és menor o igual que k, llavors cap element de les següents files serà menor o igual que k.

A més, siga , l’última columna j per a la fila i tal que , llavors quan construïm la fila i sols haurem de fer-ho fins la columna , ja que els elements de les columnes posteriors tindran un valor .

Ací teniu un exemple de com quedaria la matriu per a les cadenes hola i poal, amb un valor de k igual a 1.

Si consultem el valor de l’element aquest sols és vàlid si . Si no és així, sabem que .

Doncs bé, tenint en compte aquesta millora, el cost temporal de l’algorisme es redueix a , segons diu la publicació d’on vaig treure l’algorisme.

Així i tot, no resulta interessant aplicar aquest algorisme sobre tots els noms ja que el cost estaria en . Per a k xicotetes és molt menor que de la idea original, però que encara es pot millorar.

Necessitava tenir els noms de les persones representats d’alguna manera per a estalviar-me treball reduir aquest cost. I ací és on entren en joc els tries.

Trie

Un trie no és més que un arbre de prefixes. El node arrel representa el prefixe de la cadena buida (o ). Cada aresta de l’arbre s’etiqueta amb un símbol de l’alfabet , de manera que el node representa el prefix format per la concatenació de tots els símbols en les arestes des de l’arrel fins a l’esmentat node.

Vegem-ho més clar en un exemple. Suposem que tenim els noms de Alan, Andrew, Leslie, Johan i John. El trie que representaria tots aquests noms és el següent.

Com vegeu, les fulles de l’arbre corresponen al nom complet d’alguna de les persones: allan, john, johan, andrew i leslie (recorreguent l’arbre en amplada).

Un dels avantatges d’utilitzar un arbre de prefixes és que el cost de buscar una persona no depèn del nombre de persones. Amb una cadena de longitud l, el cost de la cerca és . Simplement hem de descendir de nivell en nivell en l’arbre per a cada lletra del nom.

Compressió de camins

El problema dels tries, com ja podreu deduir de la imatge anterior és l’espai que ocupen en memòria. Suposant de nou que totes les cadenes tenen la mateixa longitud l, en el pitjor dels casos, cap de les n cadenes codificades en l’arbre tindrà un prefixe comú i en aquest cas el nombre de nodes és (encara que això sols passar quan ).

A primera vista sembla que no és gran cosa, ja que té el mateix cost temporal que mantenir els noms en un vector. El problema és que necessitem emmagatzemar per a cada node quins són els seus descendents.

Si volem mantenir el cost de cerca , necessitem determinar en cost per quina branca em de descendir quan busquem una cadena. La resposta en aquest cas és evident: Mantenir un vector de punters amb tants elements com símbols té l’alfabet amb el que treballem. Si hi ha algun descendent en el node per al símbol i, el punter apuntarà a aquest descendent. Mentre que si és nul, sabem que no hi ha cap descendent del node actual per al símbol i. D’aquesta manera, el cost espacial de mantenir l’arbre de prefixos és .

El cost ja no és tan atractiu com semblava. Suposem que el nostre alfabet té 26 caràcters (de la a a la z), que tenim 3 milions de persones i la longitud mitjana dels noms és de 30 caràcters. Suposant que els punters són de 4 bytes, com serien en un processador de 32 bits, mantenir aquesta estructura podria necessitar al voltant de 9GB!

Evidentment, en la realitat el nombre de nodes és molt menor ja que els noms sí que tenen prefixos en comú així i tot en la realitat no només tenim 26 caràcters en l’alfabet: els noms de les persones de IMDB inclouen també números, espais, símbols d’exclamació, caràcters accentuats i caràcters d’altres alfabets que no són el llatí (ciríl·lic o grec, per exemple).

Com solucionem aquest problema? En primer lloc, tractant de reduir el nombre de nodes i això pot fer-se fàcilment utilitzant compressió de camins en l’arbre. Què és la compressió de camins? Fixeu-se en el primer arbre que us he presentat. Veureu que molts dels nodes sols tenen un descendent. No seria possible unir en un únic node tots els nodes que tenen un únic descendent? Això és la compressió de camins i aquest trie s’anomena Radix Tree. Veieu com quedaria l’arbre anterior amb els camins comprimits.

Reduint l’espai dels nodes

Una altra millora que pot fer-se per a reduir l’espai és intentar reduir el nombre de punters que s’emmagatzemen en cada node. Havíem dit que si volem mantenir el cost de cerca en necessitem un vector de punters. Però no podem reduir aquest nombre? La resposta és sí, però a costa d’incrementar el cost de cerca.

Una possible millora és emmagatzemar els punters en un arbre de cerca (en el meu cas he utilitzat el map de la STL de C++). Així, en cada node sols s’emmagatzema un punter per a cada descendent i no per a cada símbol de l’alfabet (per tant, no tenim punters nuls que ocupen memòria). Si en un node no hi ha cap punter per al símbol que busquem, llavors no hi ha descendent per a aquest símbol. D’aquesta manera el nombre de punters en cada node es redueix considerablement, especialment a mesura que es descendeix en l’arbre, que és també quan més nodes hi ha. Penseu que és probable que tinguem noms començant en totes les lletres (el node arrel tindrà tants descendents com símbols té l’alfabet), en canvi és poc probable que tinguem molts noms amb el mateix prefix i amb l’última lletra diferent (els nodes de nivells inferiors tindran pocs descendents).

El problema és que ara el cost de cercar una cadena en el trie és , on p és el nombre de punters en els nodes (, normalment prou menor).

Amb totes aquestes millores, el meu programa ocupa ara mateixa 3686MB en memòria, que és bastant menys dels 9GB que comentàvem al començament. Hi ha que tenir en compte a més, que aquests 3686MB no són només del trie sinó també de mantenir els títols de les pel·lícules, el graf que relaciona pel·lícules i actors i tota la informació corresponent a cada persona i pel·lícula.

Comentaré també que em vaig endur una desagradable sorpresa al passar el programa d’una màquina de 32 bits a una de 64 bits: els punters van passar d’ocupar 4 bytes a ocupar-ne 8 i clar, emmagatzemar el mateix arbre necessitava el doble de memòria!

Cerca aproximada

Hem parlat molt de com emmagatzemar eficientment el trie, però encara no hem solucionat el problema que havíem plantejat: fer una cerca aproximada donada una cadena X. Ací és on unim l’algorisme de Damerau-Levenshtein explicat abans i els tries.

Hi ha dos coses importants a tenir en compte a l’hora de calcular la distància de Damerau-Levenshtein sobre distintes cadenes:

1. Al calcular la distància entre la cadena X i la cadena YZ, les |Y|+1 primeres files de la matriu de Damerau-Levenshtein seran iguals a les del càlcul de la distància entre la cadena X i la cadena Y.
2. Si per al càlcul de la distància entre una cadena X i una cadena Y, totes les columnes de la fila |Y| tenen un valor major que k, cap cadena amb el prefix Y estarà a una distància menor que k de X.

El trie permet estalviar temps ja què la matriu de Damerau-Levenshtein va calculant-se iterativament quan descendim en l’arbre, pel que havíem comentat en la propietat (1). A més, tenint en compte la propietat (2), si per a un node la distància a la cadena buscada és major que un cert llindar k llavors sabem que cap dels descendents d’aquest node tindrà un llindar menor, de manera que no hem d’explorar els descendents.

Algunes consideracions sobre les operacions que apareixen en el pseudocodi. L’operació el que fa és actualitzar la matriu D afegint |x| files i computant el valor dels nous elements i el vector C com he explicat en la millora de Ukkonen.

L’operació el que fa es tornar el valor de l’element tenint en compte que potser aquest element no ha arribat a calcular-se en l’operació update. Aquest valor és la distància que hi ha entre les cadenes v i w si aquesta distància és menor o igual que k, o k+1 en cas contrari.

La gràcia d’aquest algorisme és que té una complexitat temporal de , segons l’article que us citava abans. Això suposant que l’arbre de prefixos és complet i que cada node emmagatzema un vector de punters als possibles descendents (és a dir, sense tenir en compte les millores per a reduir espai).

Fixeu-vos que l’algorisme no depèn del nombre de cadenes en el trie! Això significa que podem trobar els noms que més s’aproximen a una cerca feta per l’usuari sense importar quants noms tenim emmagatzemats. Una considerable millora front al cost , això sí, sempre que k siga menuda, perquè el cost creix de manera exponencial amb k!

El gràfic que es mostra ací baix és el temps mitjà de resposta per part de l’oracle quan es busca el nom d’un actor que no existeix en la base de dades. El valor de k que utilitze és . Si usés un valor fixe per a k hi hauria molts suggeriments per a noms curts que realment no tenen massa sentit. Anem al cas extrem: imaginem que un usuari busca el nom a, té sentit suggerir-li els noms b, c, d, etc? La distància a tots ells és 1, però és que la longitud de la cadena era 1! Això significaria que l’usuari ha errat en el 100% de la cadena! Jo permet a l’usuari que s’equivoqui fins a un 25% de la longitud de la cadena. Però si la cadena cercada fos molt llarga el valor k seria molt gran, per això pose un límit al número d’errors a 3.

Dir que l’interval de confiança que es mostra és per a un valor crític del 95%. Crec que el gràfic no mereix més explicacions. El temps de resposta mitjà és de 0.208 segons amb totes les millores comentades. També apareix el temps de resposta utilitzant el càlcul de la distància de Damerau-Levenshtein sense la millora de Ukkonen (0.301 segons).

Encara millor?

Des del primer moment vaig tenir com a referència a Google i el seu “Did you mean…?“. I tenia ben clar que els de Google no podien utilitzar un trie gegantí perquè el vocabulari amb el que treballen és enorme: imagineu totes les paraules diferents que poden haver en la WWW i el que suposaria construir un trie com el descrit!

Google utilitza un enfocament basat en aprenentatge automàtic i processament del llenguatge natural. I aquesta va ser la ruta que em vaig proposar seguir i que us explicaré en el pròxim post.

Mentrestant els tries han funcionat prou bé: són ràpids i sobretot obtenen els resultats que l’usuari espera. I poden ser una alternativa senzilla en situacions amb un vocabulari i un alfabet més reduït. Per exemple, per a construir un corrector automàtic en un editor de textos.

Recordeu l’Oracle de Woody Allen? Ja us he parlat d’aquest xicotet projecte en altres posts, però us refrescaré la memòria. Es tracta d’una senzilla pàgina web que et permet trobar quina connexió uneix a dos persones del món del cinema (actors, directors, guionistes i productors). La idea és que si dos persones han treballat juntes en una pel·lícula, hi ha una distància de separació de 1. De la mateixa manera, Si la persona A ha treballat amb la persona B, i aquesta amb la pesona C, les persones A i C estan a una distància de 2. I així successivament.

No em centraré amb els detalls de com es calcula aquesta distància i la connexió (camí, en terminologia de grafs) perquè no és del que va aquest article, simplement dir que s’utilitza l’algorisme de cerca per amplada.

Des de les primeres versions, volia que el meu programa fora capaç de “tolerar” errades humanes. Per exemple, si un usuari escriu “Wody Allen” en lloc de “Woody Allen”, el meu programa fora capaç de suggerir-li una correcció automàtica. En els següents tres articles comentaré dues alternatives que ha utilitzat el programa per a solucionar el problema i finalment una tercera que encara no he implementat, però que us plantejaré ja que encara queden alguns detalls per polir i amb un poc de sort algú es decideix a aportar alguna idea.

Avise que el contingut de les pròximes entrades és molt tècnic. Per als dos primers articles necessitareu coneixements bàsics d’algorísmica i complexitat computacional, res que un alumne de primer o segon d’Enginyeria Informàtica no puga entendre. Per al tercer, a més, necessitareu coneixements bàsics d’aprenentatge automàtic, que inclou estadística bàsica (bàsicament, teorema de Bayes).

Cerca dicotòmica

La primera tècnica que vaig utilitzar per a proveir de correccions a l’usuari era l’algorisme de cerca dicotòmica o binària.

La idea és mantenir els noms de les persones en ordre lexicogràfic. No vaig a explicar l’algorisme de la cerca dicotòmica, perquè entenc que si heu arribat fins ací el coneixeu.

El que fa l’algorisme és suggerir com a correccions els noms més pròxims (en ordre lexicogràfic) al nom introduït per l’usuari. Per a veure com funciona l’algorisme, suposarem que els noms de les persones són nombres enters. Imaginem que tenim el següent conjunt de nombres en un vector ordenat ( indica l’índex de l’element i el nom de la persona):

Suposem que busquem la persona amb nom 6, llavors l’algorisme s’executaria de la següent forma:

Com que l’últim element considerat () és menor que el cercat, es proposarien com a correccions els elements 5 (posició ) i 7 (posició ). En el cas de que l’últim element considerat fora major que el cercat, es proposarien com a correccions els elements en les posicions i .

Fixeu-se que en cas de no trobar un element, sempre proposarem un element menor i un major. I a més, sempre seran els dos que més s’aproximen a l’element cercat.

El problema és que els noms no són enters i l’ordre lexicogràfic té un xicotet problema: Dos noms als que sols els hem canviat una lletra poden estar molt separats en ordre lexicogràfic. Ací un exemple que il·lustra el problema:

Suposem que en l’anterior situació, un usuari s’equivoca escrivint el nom de Jaume i escriu Jeume:

Llavors, les correccions proposades serien Javi i Toni i cap dels dos és el que l’usuari buscava.

Una possible millora és no sols considerar els dos noms al voltant del cercat, sinó considerar k noms més pròxims en ordre lexicogràfic (per exemple, amb k igual a 3, l’algorisme consideraria Jaume, Javi i Toni). Però aquesta solució no funciona massa bé quan el nombre d’elements en el vector és de més de dos milions i l’usuari s’equivoca en una de les primeres lletres del nom.

No obstant això, l’algorisme és molt eficient en quant a temps i memòria i sobre tot, és molt senzill. Suposant que tots els noms tenen aproximadament la mateixa longitud l, podem expressar la complexitat espacial i temporal (de cerca) en funció del nombre de persones n i aquesta longitud l (la suposició de la longitud l és sols per a simplificar les expressions de la complexitat).

La primera expressió es deriva del fet que tenim n noms i cada nom té una longitud de l caràcters. La segona expressió es deriva del fet que la cerca dicotòmica fa comparacions de cadenes, i per comparar dues cadenes de longitud l necessitem fins a l comparacions de caràcters.

Aquesta senzilla idea fou reemplaçada per una que donava millors resultats cara a l’usuari, però que té un fort inconvenient: l’ús de memòria. L’alternativa que presentaré en la pròxima entrada, és la que està implementada ara mateixa en l’Oracle.

Aquests darrers dies he estat documentant el codi font, corregint algunes coses, preparant els fitxers de l’Automake, etc. És a dir, feina que no mola però que s’ha de fer si vols que algú més a part de tu siga capaç de llegir i entendre el que fas.

Doncs bé, fruit d’aquest treball he obert un projecte al Google Code que a partir d’ara serà la pàgina oficial del projecte, d’aquesta manera acabe de trencar completament amb l’antic “Número de Bacon“. En aquesta pàgina web podreu trobar les últimes novetats pel que fa al desenvolupament del projecte.

També he penjat a Internet la documentació HTML de l’Oracle i també una versió en PDF.

He intentat escriure-ho tot en anglès el menys macarroni possible, però si en valencià ja se me’n passen de burrades, en anglès de segur que també. Els suggeriments i correccions són benvinguts/des.

I ara el que us havia d’explicar al principi. Per què no està en funcionament l’Oracle tot el dia? Resposta ràpida: No tinc un ordinador amb prou memòria RAM disponible per a tenir-lo connectat 24h.

En casa tinc un ordinador (clarke) que està connectat les 24h realitzant càlcul científic en la xarxa BOINC, l’utilitze de servidor web i servidor ftp, etc. Però aquest ordinador té 2GB de memòria RAM i el client BOINC i els càlculs científics ocupen entre 500 i 600MB.

Com que la base de dades de l’Oracle es carrega en memòria i es prou gran (el programa ocupa 1,4GB) no en cap tot en la memòria de clarke (peu de nota, els meus ordinadors tenen noms de científics i escriptors de ciència ficció). Quan us connectàreu a l’Oracle, aquest s’estava executant en un altre ordinador que tinc amb 4GB de RAM.

Què pense fer? En primer lloc, he començat a mirar-me la documentació d’un gestor de bases de dades anomenat EyeDB. Aquest gestor no utilitza el típic paradigma relacional, sinó que utilitza el paradigma Orientat a Objectes. En poques paraules i per al cas, això significa que és molt més ràpid que MySQL, per exemple. Possiblement adapte l’Oracle per a treballar amb aquesta base de dades. El funcionament serà un poc més lent, però consumirà menys memòria RAM.

En segon lloc, si algú té una placa base amb Socket 775 per a un Pentium 4 de 64 bits i que suporte almenys 4GB de memòria RAM, estic interessat en adquirir-la. Si no, una placa base nova d’aquestes característiques costa uns 50 euros. S’accepten donacions.

I així ha passat amb l’Oracle. Ja us vaig parlar sobre el Número de Bacon i l’Oracle que havia fet quan feia Programació en primer. Us vaig comentar que havia reescrit el codi que havia fet en Programació per fer-lo més ràpid, que consumís menys memòria i amb més funcionalitats. Volia construir un servidor que rebés peticions i les atenguera, a l’estil de la web The Oracle of Bacon.

Doncs bé, aquest estiu (les dues últimes setmanes) m’he posat de nou a la feina i li he afegit algunes millores i he rematat la part del servidor, que no estava acabada. Ahir, aprofitant l’estrena a Espanya de l’última pel·lícula de Woody Allen (Coneixeràs a l’home dels teus somnis) vaig llançar la pàgina web titulada, en un moment de màxima inspiració, The Oracle of Woody Allen.

El llançament ha estat un poc precipitat per fer-lo coincidir amb l’estrena de la pel·lícula (que encara no he vist), però ha estat una estratègia de “màrqueting”. Durant els propers dies estaré fent proves al servidor i a la pàgina web, així que és molt probable que quan la proveu el servidor no estiga funcionant (jo diria que es troba en fase pre-pre-Alpha).

Haig de solucionar encara un parell de Segmentation Faults que apareixen en certes peticions i dels quals no he pogut descobrir el perquè i implementar en la web dues funcionalitats més a banda de la que apareix ara mateixa. Una vegada acabada la web, les funcionalitats seran:

• Calcular la distància entre dues persones en la base de dades.
• Obtenir totes les persones a una distància N d’una determinada persona.
• Calcular la distància mitjana d’una persona

Les dues primeres funcionalitats també es troben disponibles en www.oracleofbacon.org però no la tercera (degut al seu cost computacional, imagine) i en aquesta web tampoc hi ha la possibilitat d’explorar directors, productors i guionistes, sols actors. Jo, per diferenciar-me un poc de la pàgina web original, he decidit que les cerques es facen entre directors, productors i guionistes per defecte (ja que a Woody Allen se’l coneix principalment com a director i guionista).

En una altra ocasió (quan estiga 100% funcional) ja us contaré més detalls sobre el funcionament. Els més geeks podeu trobar el codi font en el servidor Subversion (llicència GPL v3).

En fi, stay tunned i com diu en la pàgina web: molt prompte estarà completament funcional (o no tan prompte).

Jo, digueu-me despreocupat, mai he tingut síndrome post-vacacional. No sé ni definir-lo. Perdoneu-me els qui patiu d’aquest mal, però com segur que diria el meu avi en els seus bons temps: això són mariconaes (ell ha sigut llaurador i obrer tota la vida, així que vacances poquetes).

També serà perquè per a mi les vacances no són sinònim de passar-me el dia estirat a la platja torrant-me com les serps (de fet sols he anat una vegada a la platja aquest estiu). Si foren així, segur que seria més difícil. A mi m’agrada fer coses. Ja us vaig fer al principi de l’estiu una llista de totes les coses que volia fer. Quantes n’he fet? Si excloem a les referents al viatge, cap ni una.

El viatge ha segut la cosa més pareguda a unes vacances normals que he tingut, això si acceptem que cinc imbècils (un parlant amb les vaques traient el cap de la finestra mentre condueix per l’autopista francesa, l’altre invocant al dimoni mentre imita a un cantant de rock satànic, un altre passejant una bandera de la URSS per terres holandeses, i la parella restant a punt de cremar una casa després de fer-se els matxots i intentar beure’s un xupito de Sambuca encès) poden fer alguna cosa normal.

Volia escriure-vos un resum de tot el trajecte, de fet tenia ja bona part escrita quan Blai publica la seva bitàcola del viatge. No m’agrada massa aquesta forma de contar les nostres aventures, però vaja, no anava a contar una altra vegada el mateix, tenint en compte que compartim gran quantitat de visitants, així que ho vaig deixar estar.

Pel que fa a la resta de coses de la llista, o no he tingut temps, o no he tingut ganes. Però n’he fet d’altres.

El primer que vaig fer en tornar del viatge va ser posar-me a pintar el portàtil. Aquesta vegada l’he pintat de negre i ha quedat bastant bé (almenys queda més net que pintat de blanc…). Després de quasi carregar-me’l a l’hora de tornar-lo a muntar (no s’encenia per culpa de no estar ben posada la memòria RAM i m’he carregat una de les dues antenes WiFi), ja està operatiu de nou. Ara amb Debian instal·lat (abans utilitzava ArchLinux que em va agradar molt, però tenia ganes de provar Debian) i sense el problemes de sobreescalfament que tenia abans (vaig netejar el ventilador conscienciosament). D’entorn d’escriptori utilitze el XFCE, que es molt lleuger (no tant com l’OpenBox) i és quasi tan complet com el GNOME.

Després m’he dedicat a fer frikades vàries: he fet alguns problemes de Google Code Jam de l’any passat. El dia 2 de setembre comença la fase de classificació. L’any passat la vaig superar (sols havies de fer un problema), però no em vaig ni presentar a la primera ronda. Enguany ja veurem; he intentat seguir on havia deixat el Wodax, però m’he adonat que tenia algunes errades, així que he tingut que replantejar-me algunes coses; i m’he posat a refer el programa que vaig presentar per al Concurs d’Algorísmica de l’assignatura d’Estructures de Dades i Algorismes. El guanyador em va passar el seu codi i la seva memòria, vaig llegir la memòria i m’he posat a desenvolupar l’algorisme que utilitzava. I deixant les frikades, aquests dies he estat recollint ametles dels arbres que envolten ma casa.

Total, que ja ha passat un estiu mes i d’ací no res comença el nou curs. Jo demà ja me n’aniré cap a València per començar a arreglar-me l’habitació, fer el papeleo corresponent a la facultat, començar amb reunions i prepara-me per al començament del nou curs: tercer (collons tu, això ja és l’equador de la titulació!). Ja tinc ganes de començar el curs. Ho admet, m’il·lusione com un xiquet. Però de les expectatives d’aquest nou curs ja parlarem un altre dia, que avui el post ja se m’ha quedat prou llarg.

Gràcies a aquest repte vaig poder aprendre un colló i part de l’altre l’any passat i amb aquest mateix objectiu he anat polint-lo i afegint-li característiques. Amb quines millores i característiques compta aquesta versió respecte l’anterior?

Optimització del graf.

Els vèrtex del graf són tant les pel·lícules com els actors i no únicament els actors com passava en la versió anterior. D’aquesta manera, el número d’arestes que apareixen al inserir un actor nou en una pel·lícula creix linealment i no de forma quadràtica com passava abans. Em vaig treure de la barret una implementació per a un graf no dirigit que millorava en un 20% la implementació clàssica mitjançant llistes d’adjacència, però així i tot, el fet que el número d’arestes cresquera de forma quadràtica era una bomba de rellotgeria. Ara, l’espai ocupat pel graf en memòria és molt menor (els que enteneu d’açò ja sabeu quina és la diferència entre un creixement quadràtic i un altre lineal…).

Per a que ens fem una idea, en la versió anterior havia de filtrar les pel·lícules i els actors quan es creava el graf per a que aquest no ocupara més memòria de la disponible en la computadora. Filtrant les pel·lícules per a adults, sèries de televisió, telenotícies, entregues de premis (Oscar, Grammy, etc) i moltes més coses, el graf ocupava vora 1,5GB de memòria principal. Ara, sense cap tipus de filtre ocupa uns 950MB!

Dues connotacions que té la millora de la representació del graf és el temps que tarda en generar-se i en carregar-se aquest. Abans havia de dedicar HORES a generar-lo en un fitxer i després MINUTS per carregar-lo en memòria cada vegada que s’executava el programa. Ara en uns 40 SEGONS (sense cap tipus d’optimització del nostre amic el GCC) el programa està carregat en memòria i llest per funcionar. Tornem de nou a la diferència entre un cost O(n) i un cost O(n^2).

Optimització de les taules hash.

Ara s’utilitzen funcions hash que ofereixen una millor dispersió i per tant el temps de recerca en la taula és menor. A més no s’utilitzen una, sinó dues funcions de dispersió. La primera serveix per dispersar l’element entre les cubetes de la taula i la segona per comparar els elements dins la cubeta, de forma que el element que s’està buscant es compara amb la resta de la seva cubeta amb un enter (cost constant) evitant així tenir que fer comparacions de strings (amb un pitjor cas amb cost lineal).

De totes formes, la idea és substituir les taules de dispersió en un futur per unes altres que oferisquen major tolerància a fallades d’escriptura (Fuzzy string searching) en detriment de l’eficiència. Per aquest cas, ens dóna igual un cost O(1) que un cost O(log n) i el segon ens ofereix algunes avantatges.

La idea és aconseguir el que fa Google quan t’equivoques escrivint però has escrit una cosa semblant a algun índex que tenen en la seva memòria cau. Per exemple, si busqueu al Google “el vol de lhome ocell” us apareixerà: “Did you mean? el vol de l’home ocell“. El mateix vull fer jo per si algú s’equivoca i busca “Kevin Bakon” o “Qevin Vacon“, que li aparega “Volies dir Kevin Bacon?“.

Lamentablement per fer tot això ens clavem en el meravellós món de la programació dinàmica i altres tècniques i estructures de dades avançades de les quals jo no tinc ni punyetera idea, així que això haurà de ser en paciència.

Optimització del càlcul del camí de menor pes entre dos vèrtex del graf.

Quan vaig fer el programa per primera vegada vaig utilitzar l’algorisme de Dijkstra. Havia sentit parlar d’ell en EMI1, així que quan vaig veure que els actors eren vèrtex d’un graf i “El Número Bacon” era el camí de menor pes entre l’actor indicat i Kevin Bacon, em vaig tirar de cap. Greu error. Perquè si hagués investigat un poc més abans de pegar-me la gran currada hauria descobert que l’algorisme de Recerca per Amplada (o Breadth-First Search en anglès, que queda més cool) també permet calcular el camí de menor pes en un graf no ponderat (o amb tots els pesos igual a 1), que era el que jo tenia, i en un temps molt menor.

La implementació habitual de l’algorisme de Dijkstra té un cost en el pitjor cas d’ordre quadràtic (O(V^2)), inacceptable per a la dimensió del graf del meu problema. Per això vaig trobar una implementació que utilitzava monticles de mínims (MinHeaps) per elegir el pròxim vèrtex a visitar i reduïa el cost a O((V+E)*Log(V)). Tenint en compte que el número d’arestes (E) era bastant major que V (però no arribava a V^2), llavors el cost era O(E*Log(V)), que no estava malament. Però la Recerca per Amplada, per a aquest cas, li pega cent voltes al de Dijkstra, ja que calcula el camí de menor pes en un temps O(E+V), en el nostre cas O(E) (ja que E >> V)!

Oracle.

Aquesta és la millor característica de cara a l’usuari. He construït un servidor utilitzant Sockets i Threads (mai havia utilitzat cap dels dos en C o C++, únicament en Python i Delphi) al qual se li poden enviar consultes de l’estil “link?n1=Bacon, Kevin&n2=Connery, Sean” i el servidor torna al client la distància entre els dos actors i el camí que hi ha que recórrer. A més se li poden passar filtres per buscar el camí únicament entre les pel·lícules que corresponen a un cert gènere, o que estiguen dintre d’un rang temporal, etc.

Què és pretén amb això? Doncs executar aquest servidor des del meu servidor casolà (s’anomena asimov) i fer una xicoteta pàgina web des de la qual poder enviar consultes (més o menys el que fa la web http://www.oracleofbacon.org), però també podria implementar-se en qualsevol plataforma connectada a la xarxa (una versió mòbil?). Ja especificaré millor com funciona el servidor en la documentació del programa, em queda corregir unes cosetes.

En definitiva, per a que veieu que no us mentisc, ací us deixe amb una xicoteta captura de pantalla del servidor amb tres clients connectats i els recursos que està consumint.

Vista prèvia del servidor amb tres clients connectats

En fi, ja us contaré més coses!

PS: Els qui m’heu vist cansat avui, per culpa de la frikada aquesta anit em vaig gitar mooolt tard…

PS2: Jo NO he fet la web http://www.oracleofbacon.org. He fet un servidor que és el primer pas per poder fer una web com aquesta.

No sóc un master en C, ni molt menys en Python. Els conec, he fet les meves virgueries amb ells, però poc més. El C és el que tinc més mastegat, he treballat amb ell durant tot l’any passat i aquest any faig les meves cosetes en C++, però realment, pel que utilitze de C++ (les classes i els streams) és com si hagués treballat amb el C també.

El GNU/Linux (perdoneu que insistisca amb la primera part del nom) duc utilitzant-lo contínuament des de fa quasi dos anys, més el temps que el vaig tenir com a sistema secundari, encara que l’utilitzava ben poc. Sé algunes cosetes del sistema en general i d’algunes distribucions en específic. Sóc el talibà de classe del GNU/Linux (ja que no està Stallman, algú ha de fer el paper).

Ara bé, els que escriuen els requisits de les beques són un poc cabronets, perquè això de “Requisits: coneixements i experiència en …” és bastant ambigu. Què s’entén per coneixement i per experiència? Imagine que tinc més coneixement i experiència que molta gent respecte els requisits, al igual que molta altra en té més que jo, però és suficient el coneixement i la meva experiència? Com ho demostre? I ací entra la segona part de la reflexió.

Per demostrar els teus coneixements i experiència se suposa que està el Currículum Vitae eixe, no? Ho pregunte perquè tampoc tinc massa clar quin és l’objectiu d’un Currículum Vitae, si dir el que saps fer o fantasmejar amb els cursets de Word de l’Acadèmia Paquirri de baix de casa o amb Màsters de la Universitat Traumhaft de Poltergeist (això està a Alemanya, incultes!) , que és el que fan molts.

Què collons haig de posar per demostrar els meus coneixements i experiència en alguna cosa (sense mentir)? Perquè no he treballat, ni he fet cap Màster Avançat Xiripitiflàutic en Aplicacions del Llenguatge C de Programació de Computadors (els Màsters millors amb noms llargs!). Què, pose un enllaç al Wodax i al repte de l’any passat?

En fi, si algú sap què collons s’ha de posar a un Curriculum Vitae d’aquests que avise, així ja el tindré preparat per a la pròxima vegada.

Aquesta és la part del present, la part del futur seguirà un altre dia. Ara vaig a seguir amb EC, que les memòries cau em porten loco…

Avui he enviat un post al fòrum de Kriptópolis i quina ha segut la sorpresa que m’he endut quan l’administrador ha penjat el post com un article en la portada de la web! Però ací no acaben les sorpreses perquè resulta que algú a enviat l’article de Kriptópolis a Menéame.

Ara sols falta que el programa i el PDF estiguen plens d’errors i quede com el cul xD.

PS: Menegeu la notícia al Menéame, vinga.

PS2: He dit que he corregit el document PDF, però sols ha sigut en la versió castellana. A veure si demà tinc una estona i corregisc la versió en català, però no promet res: haig d’estudiar!

En primera instància, Wodax és més que rés, una frikada de les grosses i l’única finalitat és el pur entreteniment i aprenentatge (a no ser que sigueu uns paranoics perduts, llavors us serà ben útil!). Una vegada aclarit aquest xicotet detall, procedim amb l’explicació més formal. Traduisc del primer paràgraf del README (tota la documentació, excepte el paper del que us parlaré tot seguit, està en… diguem-li “anglès”).

Wodax és un programa d’esteganografia que us permet ocultar un arxiu de text pla en una imatge PNG i, per suposat, us permet obtenir un text ocult a partir d’una imatge PNG escrivint la contrasenya correcta.

Mola, eh? No explicaré res sobre el funcionament del programa. Està tot explicat en aquest article titulat “Wodax: Text entre les ombres” (que m’ha costat dues setmanes de treball).

L’article està dividit en tres seccions. Comença amb una xicoteta introducció i història de l’esteganografia i la representació d’imatges en el computador; la segona secció és la més extensa i densa, explica el funcionament del programa, possibles “atacs” per fer-lo ineficaç, defenses front eixos “atacs”, algunes restriccions i manques que té (de moment); i la tercera secció inclou un xicotet text on conte com apareix Wodax i la gran xorrada que se m’ocorregué per nombrar les versions (em passat de la 0.1 a la 1.1 directament!), com instal·lar-lo i usar-lo, etc.

Dir que de moment sols el podreu compilar en un sistema GNU/Linux de 32 o 64 bits. Jo de fet l’he provat amb tres distribucions i en les dues arquitectures i funciona perfectament en les quatre combinacions. Podeu descarregar-vos un paquet amb el codi font, un binari precompilat per a l’arquitectura x86 i amd64 que inclou les llibreries (així no les haureu d’instal·lar) i una carpeta anomenada test que inclou tres textos amagats dins de tres imatges (fotos meves del Flickr). Els textos són les obres “El ingenioso hidalgo Don Quijote de La Mancha“, de Cervantes; “Tirant Lo Blanc”, de Martorell; i “Hamlet“, de Shakespeare. Totes tres en anglès gràcies al projecte Gutenberg.

El codi font de tot el projecte el podeu trobar en aquest servidor de codi Subversion. El programa està publicat sota els termes de la llicència GNU GPL v3. L’article, per la seva part està publicada sota la llicència FDL.

Actualització: Meresc dos dies de càstig a pa i aigua. Com bé m’ha apuntat Adrià això de “sombres” és una burrada com una catedral i més encara per estar en el títol d’un document! Ombres, ombres! El document ja està actualitzat, podeu tornar a descarregar-lo i com si no hagués passat res. Per la meva part us promet que ho copiaré 100 vegades…

De moment podeu únicament ocultar un arxiu de text en una imatge i obtenir un text ocult. No vaig a explicar com funciona per ara, simplement us deixaré una prova. Aquest text (extret de la Viquipèdia) es troba ocult en la imatge de la dreta de la Mona Lisa (una obra d’art plena de misteris), la de l’esquerre és l’original. Noteu alguna diferència (feu clic per ampliar les imatges al 100%)?

L’esteganografia és l’art i la ciència d’escriure missatges ocults de tal manera que només en conegui l’existència el destinatari previst; a diferència de la criptografia, en que l’existència del missatge per ell mateix no s’oculta, però el contingut és amagat.

La paraula “steganografia” té origen grec i vol dir “escrit ocult o tapat”. Els seus orígens es remunten a l’any 440 aC. L’historiador Heròdot va mencionar dos exemples d’esteganografia a les seves Històries. Demeratus va escriure un missatge per alertar d’un possible atac a Grècia, escrivint-lo en una tauleta de fusta i la va cobrir de cera. Les tauletes de cera s’utilitzaven com a superfície d’escriptura reusable. Un altre exemple de l’ús de l’esteganografia el trobem en Histiaeus, que rapava el cap dels seus esclaus més fidels i els tatuava un missatge. Quan el cabell els creixia, el missatge quedava ocult. El propòsit d’aquests missatges fou instigar una revolta contra els perses. Més tard, Johannes Trithemius va escriure Steganographia, un tractat de criptografia i esteganografia disfressat de llibre de màgia negra.

Està bé, fem les coses més fàcils… El mateix text està ocult en la imatge de la dreta. Feu clic i veureu les imatges al 500% i notareu xicotetes diferències en el color d’alguns píxels.

Ara falta fer que a banda d’ocultar text en les imatges, aquest text estiga xifrat per evitar així possibles atacs per força bruta (que són fins i tot prou complicats com ja us explicaré). Us deixe un enllaç al servidor Subversion on tinc penjat l’última versió del codi per si algú vol pegar-li una miradeta al codi (necessitareu la llibreria png++).