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.

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.