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).

Però resulta que de joc mil·lenari i japonès en té ben poc, ja que va ser l’arquitecte nord-americà Howard Garns, qui l’inventà… en 1979! Quina decepció.

Els sudokus es feren populars a Japó en la dècada dels vuitanta quan una companyia de puzzles comença a comercialitzar-los en el país de l’orient, però s’estengueren mundialment l’any 2004 quan el periòdic britànic The Times començà a incloure’ls entre les seves pàgines junt a sopes de lletres, encreuats i demés passatemps.

El joc

El joc consisteix senzillament en omplir un tauler de costats 9×9 amb nombres de l’1 al 9 de manera que no hi haja dos nombre iguals en cap fila, ni cap columna, ni cap bloc de 3×3. Els taulers de sudoku tenen la següent forma.

Un exemple de Sudoku (punxa per veure la solució)

Depenent del nombre de quadres plens que ens donen i la posició dels nombres amb els que comencem el joc resulta més difícil o menys.

El principi

Jo fins fa dos anys no havia jugat en ma vida al joc aquest. N’havia vist, sí, però no havia jugat mai. Fou a juny de 2007, de camí a València per comprar els bitllets del (fallit) Interrail quan vaig jugar per primera vegada amb Marina i Blai. Marina i jo ens vàrem picar a veure qui podia completar-ne més ràpidament així que em vaig comprar un llibre d’aquests que estan tot plens de sudokus per anar fent-lo durant el viatge, però circumstàncies de la vida que ja coneixeu feren que el llibre l’emplenés en l’hospital.

I a què ve tot açò? Doncs l’altre dia estàvem en classe d’Estructures de Dades i Algorismes (a.k.a EDA) aprenent sobre Backtracking i sorgí l’exemple del sudoku, així que el professor va fer un programa que resolia sudokus fent servir aquest esquema algorísmic. Quan va acabar el programa va dir: “Podríem fer que ens imprimira tots els sudokus possibles…” i va llançar el programa per a que fera això, però com que ja era hora d’acabar la classe ací va quedar la cosa.

Jo, ahir que no sabia que fer (ara que ja s’ha acabat el concurs de l’assignatura) i com que no havia practicat encara res de Backtraking per compte propi em vaig dir: “Xe, anem a fer el programeta per resoldre sudokus“. I em vaig posar en això. Quan vaig acabar-lo em vaig preguntar per què no acabar la tasca que el professor havia començat però havia abandonat per falta de temps i vaig llançar el meu programa per a que em mostrara tots els sudokus que es podien formar en un tauler de 9×9.

Ignorant de mi. Com veia que tardava me’n vaig anar a berenar esperant que quan tornes tindria ja tots els sudokus possibles. Però com ja imaginareu, quan vaig tornar el portàtil estava a 74ºC  (i això que havia limitat la freqüència a 996MHz) i el fitxer de solucions ja ocupava centenars de MB. Va ser ací quan em vaig adonar que segurament serien MOLTS sudokus…

Concretament, hi han 6,670,903,752,021,072,936,960 taulers de sudoku possibles (o deixe expressat així i no en notació científica per a que s’aprecie millor la magnitud d’aquest nombre). I ací és on comença el friquisme.

Parlant matemàticament…

Hi ha un extens article en la Wikipedia anglesa dedicat a les matemàtiques relacionades amb aquest joc, la seva llista de referències no es queda curta i són moltes les investigacions sobre Combinatòria i també Complexitat Computacional que es centren en aquest joc.

El problema general del sudoku entès com un tauler de caselles agrupades en blocs de (9×9 caselles agrupades en blocs de 3×3, en el nostre cas), es pot expressar com un problema de colorejat d’un graf, on cada casella seria un vèrtex del graf enumerat de la forma (on )¹ i on dos vèrtex estarien units per una aresta si:

• (dues caselles d’una mateixa columna).
• (dues caselles d’una mateixa fila).
• (dues caselles en un mateix bloc).

Llavors, la solució seria assignar un color entre els possibles a cada vèrtex (un nombre de l’1 al 9 vaja) de manera que qualsevol aresta no tinga el mateix color en el seus dos extrems.

Doncs veges tu per on, aquest problema és un problema del tipus NP-Complet. Jo havia sentit parlar d’aquesta classe de problemes (per tot allò de P = NP?, un dels set problemes del mil·leni, la solució dels quals és premiada amb un milió de dòlars), però fins aquesta vesprada no sabia concretament que era un problema NP-Complet i tampoc estic segur de saber-ho ara, així que abans de contar-vos alguna bajanada us referencie a l’article de la Wikipedia.

El que sí us sé dir és que, en poques a paraules, no es coneix un algorisme “eficient”, on eficient significa polinòmic () per solucionar el problema. El que fa l’algorisme basat en Backtracking és explorar tot l’arbre de possibles solucions descartant aquelles que no complisquen les condicions del joc (descrites anteriorment).

Haurem de renunciar doncs, de moment, a trobar tots els possibles sudokus… Podríem seguir parlant de com, almenys, comptar quantes són aquestes solucions, però per això necessitaríem un apunt encara més llar i ja s’està fent tard i tampoc era eixe l’objectiu del post. Si us he despertat un poc l’interès i us ha picat el cuquet friqui, podeu visitar aquesta pàgina web de Bertram Felgenhauer i Frazer Jarvis que dugueren endavant els càlculs.

—

¹ Pregue que disculpeu el formalisme d’algunes expressions, però aprofite l’apunt per provar que dóna de sí el plugin WP-Latex.

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++).

El problema que es plantejava era un simple canvi de base entre dos sistemes de numeració, tradueixo la descripció del problema:

El sistema numèric decimal està composat per deu dígits, els quals representem com “0123456789″ (els dígits en un sistema estan escrits del menor al major). Imagina que has descobert un sistema numèric extraterrestres compost per uns quants dígits numèrics, els quals poden ser o no els mateixos del sistema decimal. Per exemple, si el sistema numèric extraterrestres es representa com “oF8″, els nombres de l’1 al 10 serien (F, 8, Fo, FF, F8, 8o, 8F, 88, Foo, FoF). Voldríem poder treballar amb nombres d’un sistema extraterrestres arbitrari. Més generalment, volem ser capaços de convertir un nombre qualsevol que està escrit en un sistema extraterrestres, a un altre sistema extraterrestres.

El que se me va ocòrrer a mi va ser generalitzar els canvis de base binari-decimal i decimal-binari i xim-pum. Tant senzill com això. En la meva solució faig un canvi de base del sistema extraterrestre d’entrada a decimal i després de decimal al sistema extraterrestre de sortida. Per què? Doncs no sé, perquè se me va ocórrer de fer així i és el que estic acostumat a fer per passar d’hexadecimal a decimal o a binari. Però en principi no hi ha cap problema per fer una conversió directa entre els dos sistemes, sols has de saber fer-ho i jo no m’he aturat a pensar-ho.

Per programar la solució vaig utilitzar el llenguatge C++, que tenia ganes de provar-lo i el qual segurament utilitzaré aquest estiu per a un xicotet projecte pendent que tinc (ja us parlaré d’ell, però està relacionat amb el Número de Bacon) i que és el llenguatge utilitzat en Estructures de Dades i Algorismes (EDA), una assignatura que tindré l’any que ve i que, no vaig a enganyar-vos, tinc ganes de cursar (disculpeu la meva  els que us heu tingut que enfrontar a ella…). Una de les estructures implementades en la llibreria STL de C++ que he utilitzat és el map (mapa, per als qui necessiteu traducció ¬¬), que no sé quina diferència presenta respecte d’una taula Hash. L’he utilitzada per relacionar un símbol del sistema extraterrestre d’entrada amb un valor i poder així operar amb ells.

En fi, ací teniu la solució (que és correcta) i uns exemples de canvi de base:

• Nombre: 9; Sistema d’entrada: 0123456789; Sistema de sortida: oF8; Solució: Foo
• Nombre: Foo; Sistema d’entrada: oF8; Sistema de sortida: 0123456789; Solució: 9
• Nombre: 13; Sistema d’entrada: 0123456789abcdef; Sistema de sortida: 01; Solució: 10011
• Nombre: CODE; Sistema d’entrada: O!CDE?; Sistema de sortida: A?JM!.; Solució: JAM!
• Nombre: eEEeeeEEeeeEeE…E; Sistema d’entrada: E.e; Sistema de sortida: !0TtKXJ]hZi_|Q8sg[>~DNAnWx$Gf%,k"2L&ydYB; Solució: T$|gB~
• Nombre: <-"i4g; Sistema d'entrada: m<zqSI#F2]$`”9+~4>kQxoGV{?T;7yvR_l3B-ti/ag6.%ews[8; Sistema de sortida: u%v; Solució: %%u%%vu%u%vvu%%u%vv

La primera fase de la competició, la de qualificació, és el pròxim 16 de Juliol de les 23:00 UTC fins el 17 de Juliol a la mateixa hora (la fase dura 24h). Tinc curiositat per veure els problemes que plantegen, però no crec que sàpiga resoldre’n cap. No sé prou d’algorísmica. Per a que us feu una idea, el quart problema de la fase d’entrenament d’on he tret el problema anterior, és el següent:

Teniu una llista d’objectes a comprar avui, i sabeu els llocs (representats per punts en uns eixos cartesians) d’unes poques tendes en l’àrea. Sabeu també quines coses de la vostra llista ven cada tenda i a quin preu ho venen. Donat el preu de la gasolina, quina és la mínima quantitat de diners que necessiteu per comprar tots els objectes i tornar a casa? Comences i acabes a la teva casa, que està en la posició (0,0) dels eixos cartesià.

Per fer les coses més interessants, alguns dels objectes en la llista es poden fer malbé. Quan compreu un o més d’aquests productes, no podeu conduir fins una altra tenda sense abans passar per casa. Tots els objectes de la vostra llista es troben en alguna tenda, per tant el viatge sempre és possible.

Aquest problema ja és xunguet, almenys per als coneixements que tinc jo. Em recorda al problema del carter xinès o algun paregut, un famós problema del qual he sentit parlar per la xarxa mare i no tinc ni idea de com es resol. S’agrairia als visitants que han fet Algorísmica (que sé que hi han) que ens contaren alguna cosa a través dels comentaris…

La lletra de la cançó la podeu trobar en aquest enllaç, però ja us avise que està en anglès i necessites saber alguna coseta del llenguatge de programació C (i ser un poc friqui) per entendre-la. L’heu de cantar amb la melodia de “Let it be” dels (The) Beatles [Kit-Kat: Per què mai ningú posa el The al nom d'aquest grup?]. Buscant pel Youtube algun altre paio que s’atrevís a cantar-la m’he trobat amb aquest vídeo on la podeu escoltar amb algun que altre refilet.

El que m’ha fet gràcia del vídeo ha sigut el fons: una imatge fixa amb la fotografia de Denis Ritchie (un dels creadors del C) i el següent text a l’aire Bruce Lee i el seu Be water my friend.

Empty your memory, // Buida la teva memòria,
with a free()… // amb un free()…
like a pointer! //com un punter!

If you cast a pointer to an integer, // Si moldeges un punter a un enter,
it becomes the integer. // es convertirà en l’enter.
If you cast a pointer to a struct,  // Si moldeges un punter a una estructura,
it becomes the struct… // es convertirà en l’estructura…

The pointer can crash… // El punter pot fallar…
and can overflow… //i pot desbordar-se…

Be a pointer my friend… // Sigues un punter amic meu…

M’ha fet gràcia, què voleu que us diga? Vaig a escoltar-la de nou…

Qualsevol altra persona amb bona salut mental s’hauria encès la televisió i hauria mirat algun programa de debats d’aquests que fan pels matins, que segur que deuen d’estar d’allò més “interessants” després de les eleccions. Però jo no he fet això!

Com que m’estava pelant la classe de FCO m’han entrat remordiments i m’he dit: “anem a fer exercicis” i m’he posat a fer exercicis d’assemblador. Doncs bé, farà una estoneta, quan ja estava cansat de fer exercicis (després de quasi dues hores) m’ha vingut al cap de provar de fer algun programeta en assemblador i açò és el que he fet (imagine que dels que llegiu el bloc ningú entendreu que collons fa, però és igual, és una cosa MOLT friki).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

.data
itera:    .byte 0x0A       #numero de iteracions (sense comptar a[1] i a[2])
.data 0x10010010
vector:    .byte 0x00, 0x01 #vector que representa la successio.
#els primers valors corresponen a[1] = 0 i a[2] = 1.
 
.text
.globl __start
 
__start:
la $4, itera
la $7, vector
lb $3, 1($7)    # a[n-1]. a[2] = 1
lb $2, 0($7)    # a[n-2]. a[1] = 0
addi $7, $7, 2  # comencem a afegir a partir de la tercena pos.
lb $4, 0($4)    # iteracions
addi $6, $0, 0  # contador
 
bucle:
add $5, $2, $3  # a[n] = a[n-1] + a[n-2]
add $2, $0, $3
add $3, $0, $5
addi $6, $6, 1  #incrementa comptador
sb $5, 0($7)
addi $7, $7, 1
bne $6, $4, bucle  #si encara no hem fet totes les iter. repetim...
 
.end

I què és el què fa la cosa aquesta? Doncs va omplint un vector en memòria on cada element és un terme de la successió de Fibonacci (0,1,1,2,3,5,8,13, …). Ni més ni menys.

La idea era fer una cosa semblant a aquesta feta en C:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

#include <stdio .h>
#define MAX_ITER 10
 
int main(){
int vector[MAX_ITER+2], i;
vector[0] = 0;
vector[1] = 1;
printf("%d %d ", vector[0], vector[1]);
i = 2;
while(i != MAX_ITER+2){
vector[i] = vector[i-1] + vector[i-2];
printf("%d ", vector[i]);
i++;
}
putchar('n');
return 0;
}
</stdio>

Ací tenim el resultat de l’execució del programa en assemblador:

Descarrega’t el codi font i juga una poc amb ell (fixa’t en que el vector és de bytes!). El llenguatge assemblador és per al processador MIPS R2000 així que necessitaràs un simulador. Jo utilitze el Spim, està disponible tant per a Windows com per a Linux (encara que jo utilitze la versió de Windows sobre el Wine).

• fibonacci.c
• fibonacci.asm

La idea inicial era fer una espècie de daemon que estigués sempre executant-se i que cada cert temps canviés automàticament el fons d’escriptori. Però com que els meus coneixements sobre Python (que és el llenguatge que he utilitzat per programar la utilitat) no són massa extensos, de moment em conforme amb aquesta versió 0.1 del Canvpan.

Com funciona per dins?
Canvpan es connecta a socwall.com i fa una recerca en busca de fonts d’escriptori que complisquen un requisits (especificats en l’arxiu config, bàsicament grandària i categoria). Com que la gent de socwall.com no té disponible cap API per connectar-se a la seva base de dades, com si tenen els de Flickr, el meu programeta ha de filtrar TOT el contingut de l’arxiu HTML generat en el servidor de socwall.com (cosa que el fa lent). Per això utilitze una llibreria que em presenta l’arxiu HTML en un DOM, cosa que facilita enormement la recerca d’enllaços a les imatges que m’interessen.

Les imatges que es troben en la recerca es guarden en una llista i es fa un random entre els elements d’aquesta. L’element elegit es descarregat (amb la funció urlretrieve de la llibreria urllib) i es col·locat com a fons d’escriptori fent ús d’una fantàstica llibreria que incorpora Python per entendre’s amb el GNOME (la llibreria gconf).

I cara a l’usuari?

• Per canviar de fons d’escriptori:

$python canvpan.py change

• Per canviar el directori de descàrrega:

$python canvpan.py dir /nou/directori

• Per canviar la grandària del fons:

$python canvpan.py size [Standard, Widescreen, Dual%20Monitor, All]

• Per canviar la categoria del fons:

$python canvpan.py cat [Everything, Abstract, Anime, Art, Buildings, Computer%20Related, Creatures, Fantasy, Games, Music, Nature, People, Products, Sci-Fi, Seasonal, Space, Sports, Transportation, TV%20and%20Movies]

La configuració per defecte
Arxiu conf:

/home/usuari
Default
Everything

Evidentment hauràs de canviar el directori al teu home o a qualsevol altre lloc on tingues permisos d’escriptura. Allí es crearà l’arxiu .temp_wallpaper.jpg (recordeu que el punt de davant significa que és un arxiu ocult) que contindrà la imatge descarregada de socwall.com.

Per configurar el programeta, utilitzeu els comandaments que he mencionat abans. El programa és molt sensible als salts de línia, espais en blanc i demés, així que si no us voleu arriscar a fer malbé quelcom, utilitzeu els comandaments dir, size i cat. I apunteu a un directori, a una grandària i a una categoria vàlides. Confie en vosaltres .

Pròximes millores
El pròxim que faré (i ja estic fent alguna cosa), quant tinga més temps, és fer-lo més ràpid. Com? Doncs he pensat en guardar en un arxiu la llista amb els enllaços a les imatges de socwall.com i fer un random dels elements d’aquesta llista i eliminar el seleccionat, fins que la llista quede buida i aleshores es torne a carregar de la mateixa forma. Així no hauríem de descarregar la llista d’imatges cada vegada.

Se vos n’acudeix alguna més?

Pegueu-li una miradeta al codi font i perfeccioneu-lo, això si… compartiu-lo amb nosaltres!

Arxius
limxml2dom-0.4.4.tar.gz (Llibreria necessària per llegir l’HTML en DOM).
canvpan.tgz (El meu programeta).