La setmana passada volia publicar un article sobre la reforma de les beques que vol dur endavant el ministre Wert. És un tema del que ja he parlat moltes vegades amb els amics, i fins i tot vam tenir una discussió que va durar fins altes hores de la nit este estiu. Al final no vaig acabar d’escriure la nota perquè m’estava quedant un post massa llarg i no aconseguia dir exactament el que volia. Però vaig a fer-vos un resum: Ojito, que tots no partim de les mateixa base per a obtenir uns determinats resultats. No és el mateix el fill d’una família de professors que el fill d’una família de camells.

El títol de l’entrada és “Update”, però poca cosa tinc que contar. Vaig estar cinc dies a París fa dos setmanes, visitant a Anna, i des de que he tornat el meu dia es resumeix en fer les pràctiques de classe i mirar les quatre sèries setmanals que seguisc (Californication, The Walking Dead, Modern Family i The Big Bang Theory).

El més destacable és que ja he rebut tots els papers que necessitava per a demanar el visat J-1 a l’ambaixada dels Estats Units a Madrid. La putada és que m’hauré de traslladar fins allà per fer l’entrevista amb els d’immigració i que em donen el visat. I damunt, per demanar la cita haig de cridar per telèfon i des de fora d’Espanya et cobren el mòdic preu de 10 euros per la cridada! En fi, quan estiga frikejant en Mountain View, haurà valgut la pena.

Poca cosa més, ara vaig a seguir pegant-li canya al Paxos. En dues setmanes estic d’exàmens. Ja us contaré més quan passen.

Ha sigut un Nadal relaxat. Això de no tenir (pràcticament) exàmens després de les vacances és una passada! Ara bé, no he fet quasi res del que volia fer durant les vacances.

Abans de venir cap a Espanya us vaig dir des de Suècia que acabaria de contar-vos les últimes idees sobre correcció automàtica en l’Oracle. Zero. Res.

Esperava rebre part dels papelorios de Google i cridar a l’ambaixada dels EUA per preguntar algunes coses, però no els he rebut encara i tampoc he pogut avançar en aquest tema.

El que sí que he fet aquests Nadals ha sigut enganxar-me a una sèrie més (Modern Family) i jugar a un videojoc (Half-Life 2). Feia un parell d’anys que no jugava a cap joc!

En fi, que dilluns comencem les classes del tercer període a la KTH amb Artificial Neural Networks and Other Learning Systems, Search Engines and Information Retrieval i Distributed Systems: Advanced Course. Ja tinc ganes!

Abans que res, perdoneu-me per no escriure res la setmana passada sobre l’Oracle i la correcció automàtica, però no he pogut acabar encara el que volia contar-vos així que haurem d’esperar un poc més.

En un sol adjectiu, aquest any ha sigut genial. Va acabar prou bé el meu últim any de classes a la UPV com a estudiant d’Enginyeria Informàtica, han anat prou bé també en la primera meitat de la meva estada a Estocolm i espere que vagen almenys igual de bé en la segona meitat, ara que les assignatures tenen pinta d’agradar-me més.

He pogut fer un bon grapat de viatges aprofitant que he tingut un quadrimestre més relaxat (viatge a Tallin, a Londres i diverses escapades per Suècia i un parell de voltes que he tornat a casa a passar uns dies). Espere poder fer-ne també uns quants el segon quadrimestre, encara que el tindré prou més carregat que el primer.

I professionalment, que dir: Ha sigut l’any que els de Mountain View m’han convidat a col·laborar amb ells. Estic segur que aquest tema centrarà moltes entrades el pròxim any.

Alguna cosa em fa pensar que el 2012 serà millor encara, espere no enganyar-me i que el vostre us vaja també de meravella.

En fi, si voleu veure un vídeo resum més global, doneu-li un cop d’ull al meravellós, fantàstic, espectacular i emotiu vídeo de Google (sí, m’he posat en mode spammer).

Val, val. M’han fixat com a Software Engineer Intern a Google. Però què vaig a fer allà?

Treballaré amb l’equip OCR (Optical Character Recognition), integrat dins de Google Research, que és l’equip de recerca de la companyia. La missió de Google és:

Organitzar la informació mundial i fer-la útil i accessible universalment.

I això òbviament passa per organitzar la informació escrita en llibres. L’equip d’OCR és un dels que treballa, per exemple, en el Google Books i el seu treball dins d’aquest producte és fer que els ordinadors puguen reconèixer el que hi ha escrit en els llibres. Una vegada sabem el que diu en una imatge escanejada d’una pàgina d’un llibre, podem fer que quan l’usuari cerque informació, no sols li apareguen dades que provinguen de pàgines web, sinó també de llibres. La meva tasca en concret serà millorar una part d’aquest procés.

Els escànners domèstics i aplicacions com l’Adobe Reader o el Google Docs tenen funcions de reconeixement de text des de fa molt de temps. No és l’OCR un problema resolt? En el següent vídeo, Remco Teunen explica quin és el treball que ha fet l’equip de OCR i què és el que li queda per fer. Remco és qui em va fer l’entrevista i qui serà el meu host (Google mai utilitza paraules com boss, supervisor, director, etc). La seva part dura 8 minuts, però si us interessa saber en què treballa l’equip de recerca de Google (Reconeixement de Veu, Traducció Automàtica, Machine Hearing i Machine Perception), us recomane que el veieu complet.

Doncs sí, com ho llegiu! Si res canvia i el govern dels EUA em dóna el visat J-1 que necessite per a treballar allà, el pròxim estiu (del 10 de Juliol al 12 d’Octubre) estaré treballant en la seu central de Google, a Mountain View!

El passat dilluns 12 vaig fer una entrevista amb un investigador de Google Research, a les 19.30h de la nit. Va durar un poc més de mitja hora, més culpa de les meves preguntes que no pas de les seves. Jo vaig eixir amb molt bona sensació de l’entrevista: tenia experiència relacionada amb el projecte, m’agradaven molt els dos projectes que em proposava i vaig saber demostrar-li que tenia els coneixements i la il·lusió per a fer el treball, que és del que es tractava. Unes hores més tard, rebia un correu de RH informant-me de que volien comptar amb mi aquest estiu i que els diguera les dates de començament i acabament de les pràctiques.

Avui, m’han cridat de matí des de Facebook i els he hagut de dir que no podia seguir fent entrevistes amb ells i per la vesprada m’han cridat els de Google per a donar-me tots els detalls sobre el contracte i demanar-me la meva pre-acceptació (encara no he firmat cap contracte, me l’enviaran per correu).

Com podreu comprendre, estic que me’n puge per les parets!  Per a qualsevol informàtic, treballar a Google és com treballar a la NASA o al CERN per a un físic, per a Ferrari per a un enginyer en mecànica, o que sé jo!

No obstant això, l’important no és estar ací o allà, és el que fas en el lloc. La grandesa de treballar a Google no és el propi fet de treballar allà i que tingues menjar i massatges gratis, sinó de tot el que pots fer i el que pots aprendre amb la enorme quantitat de dades i del personal humà que tenen. Quan tens la oportunitat de treballar i aprendre amb la gent que ha escrit els llibres i publicacions que has estat estudiant, amb la gent que marca les tendències en allò que t’apassiona: no pots negar-te, no vols fer-ho.

Fa mig any us descrivia el més prop que havia estat mai d’aquests genis, ara ja estic més prop. Moltes gràcies a tots els que m’han ajudat a assolir-lo i han confiat en mi: als meus pares i la meua germana, a Anna, als amics del poble i la universitat, professors d’institut amb els que he aprés un muntó, professors d’universitat amb els que he aprés més encara (especial agraïment a Moisés per confiar en mi oferint-me una beca quan encara no havia començat ni el 3r curs, i que ha sigut un factor clau) i moltes gràcies també a Ivan que en el seu moment m’ajudà a preparar el CV i em dona un bon grapat de consells.

Ho haig de reconèixer: sóc una persona amb sort, molta sort.

PS: Amb este subidón d’adrenalina, qui estudia ara?!

Vaig participar un any més a la SWERC, una de les fases del Campionat Internacional de Programació organitzat per la ACM i que enguany es cel·lebrava de nou en la Complutense de Madrid (vaig poder viure sobre el terreny la victòria del PP, quina “alegria”). Ja que estava allí, vaig aprofitar per passar uns quants dies en Egpaña, que feia temps que no la xafava.

En tornar a Suècia vam fer un viatget, Fernando, Adrià i jo, a Kiruna: una ciutat situada al nord de Suècia, en la regió de Lapònia i ben al nord que està! Literalment, al pol nord.

Vam veure la neu que encara no havíem vist en Suècia (mira que trobar-nos amb l’any més càlid des de fa molt de temps ací, per un any que venim!) i vam passejar amb trineu guiat per huskies (una pasta que ens va costar, per cert). El que no vam poder veure van ser les aurores boreals. En fi, hi haurà que tornar per allà dalt per veure-les.

I les últimes setmanes han sigut per a acabar un projecte de la “meravellosa” assignatura que estic fent ara: Distributed Artificial Intelligence and Intelligent Agents. Un nom molt bonico i res més: decepció absoluta que m’he endut amb eixa assignatura.

Tot això, mesclat amb una bona dosi de frikisme per la meva part programant una nova forma de fer la correcció automàtica en l’oracle utilitzant HMMs. Però això ja tindrà el seu post més endavant. Ara toca una setmana d’estudi per a l’esmentada assignatura i preparar-se per a la tornada a casa, el dia 22 de desembre. Promet que en tornar a casa us escriuré més detalladament les últimes novetats.

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.

La dona soltera, d’uns seixanta anys, cansada dels infortunis que havia sofert en matèria amorosa, s’havia decantat per suplir les seves necessitats amb una bona dosi diària de gelat de fresa i la companyia d’animals exòtics. I aquell dia no era diferent: menjava un cucurutxo amb la mà esquerra i sobre la seva mà dreta l’acompanyava aquell animalot blanc que va captar la meva atenció: una cacatua.

Era de l’espècie Cacatua galerita. Tota blanca a excepció de la cresta groga i el bec i les potes de gris obscur. S’agafava amb l’ajuda de les urpes de la seva cuidadora amb cura per a no fer-li mal, però suficientment fort per a no caure davant dels imprevisibles i bruscs moviments de l’autobús ple de gent.

Des del seu particular observatori, creuant el Västerbroplan, parava atenció a tot el que esdevenia pel seu voltant: el jove amb ulleres de pasta que jugava amb el mòbil al davant, la parella que es besava afectuosament junt a la porta d’eixida o la dotzena de persones que anaven de peu i miraven al sostre amb cara d’impaciència, desitjant arribar d’una vegada al seu destí i cansats d’aguantar, ves tu a saber quina impertinència del seu veí. La gent sempre es mostra especialment irritable quan torna a casa acabada la jornada laboral.

Ella semblava ser un d’aquells observadors que està ben atent però es mostra indiferent a tot el que veu. Com si tot al seu voltant, no tingués la més mínima importància i simplement fos divertit observar-ho com a pur entreteniment. No s’immutava davant de cap estímul extern i ni tan sols va tastar el gelat de fresa que la seva ama li va donar a provar.

Però sobretot, i amb aquella mirada de superioritat, aquell pardal em mirava a mi mentre escoltava “How it Ends”, de DeVotchKa. Bé, tenia el bec apuntant-me però potser jo era qui menys li importava. Les cacatues tenen els ulls als laterals del cap, així que resulta complicat imaginar que és el que una d’aquestes aus està veient quant té el cap dirigit a tu. Fos com fos, jo si que la mirava a ella i pensava amb l’estampa més graciosa que protagonitzàvem tots els d’aquell autobús: persones i cacatua.

L’animal i la dona van baixar a Högalidsgatan i allí els vaig perdre de vista. Jo vaig seguir fins a Hornstull, la següent parada, i en quant vaig baixar del bus per a entrar al tunnelbana ja tenia clar que aquella història havia de quedar immortalitzada.

Van emetre un pilot que tractava sobre l’allunatge i si aquests es va dur realment a la pràctica el 1969 i tots els misteris i conspiracions que giren al voltant d’aquest.

Aquell primer episodi el vaig trobar molt interessant, entretingut i didàctic però m’ha agradat més encara aquest últim: “¿A ti te funciona?“, es titula.

En aquest episodi aprofiten la tan usada frase “A mi em funciona” per a parlar sobre les anomenades “medicines alternatives” i entrevisten tant a defensors com a detractors per a que exposen els seus arguments. En el programa no tracten l’Homeopatia, que tindrà el seu propi episodi.

La veritat és que se’ls veu un poc el plumero als realitzadors del programa, perquè clar està, estan de part dels detractors. Però és que tampoc poc entendre’s que una persona amb una mínima noció del mètode científic i sobre medicina no puga ser detractora d’aquestes bajanades.

No té preu, per exemple, veure a una d’estes bruixes parlant d’un “flotari” on “no hi ha gravetat perquè estàs gitat i flotant en l’aigua”, de que “el càncer està produït pels desequilibris de l’energia de la persona” i que el naixement o enamorament és el “Misteri de la Vida”. Priceless.

Us recomane que invertiu 37 minuts veient aquest vídeo perquè, com diu un dels entrevistats, totes aquestes bajanades són perilloses per dues raons:

1. Poden arribar a endarrerir o anular el diagnòstic d’una malaltia important, amb totes les conseqüències que això té per al malalt.
2. En el fons el que aquestes “teràpies” alimenten és la desraó i això, per a la societat en conjunt, és més perillós que el primer punt.

M’haguera agradat que tractaren més amb els arguments dels defensors d’aquestes medicines, que no són arguments que defenen les seves tècniques, sinó que es basen en dir que la medicina tradicional és roina perquè està controlada per les farmacèutiques que volen fer negoci. Una altra mostra de que aquestes persones no tenen la mínima idea o interès de construir un raonament lògic.

En definitiva, un programa al que haurem de seguir-li la pista.