Lapsus: anatomía de un corrector ortográfico VII

Hay otros métodos de corrección ortográfica, de los cuales me gustaría hablar. Uno de ellos es en base a las posibles sílabas legales que se presentan en el español. La idea es muy simple: se toma una palabra, se analiza y se descompone en sílabas y se busca si hay alguna sílaba que no sea legal, que no corresponda al español. El problema aquí es saber ¿cuáles son las sílabas legales del español? ¿Dónde podré hallar semejante lista?

Hurgando en la red (otros dicen "navegando"), hallé este sitio, el cual asegura haber hallado todas las sílabas legales del idioma castellano. Hasta donde entiendo, quien desarrolló este trabajo, lo que hicieron fue un programa para hacer la división silábica correcta de todas las palabras en español. Como las reglas de división silábica son muy específicas, es posible escribir un programa de esta naturaleza, asunto no muy complicado.

Una vez hecho esto, el o los investigadores hicieron una lista de todas las sílabas que hallaron utilizando para ello 36,070 textos de la enciclopedia Encarta (en español, evidentemente). Sin duda el trabajo empezó realmente después, pues hubo que depurar y además, hallar posibles errores. Hubo pues que hacer una buena labor de programación para automatizar este pesado trabajo de clasificación y no me cabe duda que el autor, Jerónimo Armario Toro, con Diplomado en Magisterio y Licenciado en Psicopedagogía, hizo un fuerte trabajo que sin duda vale la pena.

En el documento que presenta en la red, hallamos lo siguiente: "El objetivo principal de este artículo es el de hacer público el resultado de una investigación que nos ha llevado a realizar un listado, esperamos que totalmente completo, de todas las sílabas del español. En efecto, este listado de sílabas será lo que presentemos en subsiguientes entregas, ordenadas convenientemente en una tabla en la que, debido a consideraciones de espacio, sólo aparecerán estas últimas sílabas, sin las palabras que las ejemplifican".

El autor presenta una tabla de las sílabas válidas del español, pero ¡ay! es una imagen y no un archivo de texto (o mejor aún, una tabla en Excel) que contenga esta información. ¿Por qué no dejó el enlace como un simple archivo .txt? En vista de esto, decidí tomar la tabla mencionada y transcribir todas las sílabas válidas del español. Cabe decir que cuando estaba pasando las sílabas a un archivo de texto, en muchas no hallé ninguna palabra que contuviera esa sílaba. Sin embargo, debido al tamaño de la empresa que realizó en investigador, no hubo lugar para ejemplos de muchísimas de las sílabas. En principio, le creo que su trabajo es correcto, aunque habrá que contrastarlo más adelante con los documentos a corregir. A todo esto, el archivo de texto, con todas las sílabas de la tabla mencionada, se puede descargar de aquí.

Así entonces, el procedimiento de revisión de palabras, en una primera instancia es revisar si cada palabra del texto a corregir tiene sílabas válidas. Si no es así, ya no tenemos que buscar en diccionario alguno porque podemos asegurar que la palabra en cuestión está mal escrita. En caso de que la palabra a revisar esté correctamente en términos de sílabas válidas, tendremos que pasar a buscar en un diccionario o usar alguna otra técnica de corrección.

Cabe señalar que Andrés Aldana, mi ayudante en la UNAM, me mandó una serie de sílabas válidas en el español, que halló en este sitio. Este archivo puede bajarse de aquí. Nótese lo que dice el autor de esa página:

Para evitar duplicidades, hemos clasificado las sílabas por fonética, de manera que hemos sustituido algunas sílabas por otras:

•     "ce" por "ze".
•     "ci" por "zi".
•     "ve" por "be".
•     "h" por "(cádena vacia)".
•     "gue" (de guerra) por "ge".
•     "ge" (de geranio" por "je"
•     "ca" (de casa) por "ka".
•     No se tienen en cuenta los acentos.
•     Sílabas como "rio" (imperio) y "rrio" (me rio de algo gracioso) se consideran diferentes.
•     Etc etc etc...

Debe entenderse que un corrector ortográfico es tan bueno como su capacidad de corrección. Un corrector que se le vayan algunas palabras desmerece en su desempeño y entonces ¿cómo podríamos garantizar que los documentos que revisamos están correctos? El asunto es que un verdadero corrector no puede pasar nada por alto.

Lapsus: anatomía de un corrector ortográfico VI

Un corrector ortográfico tiene otras dificultades a resolver. Una de ellas es si el programa será implementado como una aplicación independiente o si bien, interactuará con algún otro sistema. En la primera versión de Lapsus, la cual se escribió en Turbo Prolog 2.0, de Borland, el sistema contenía su propio editor de textos, es decir, quien usara el software estaba obligado a escribir sus documentos en el editor que yo proveía. Sin embargo, es claro que este enfoque tiene una oposición importante: es difícil que la gente cambie el editor de palabras que use por utilizar la herramienta de corrección ortográfica, aunque ésta suene muy poderosa.

Debido a esto, decidí entonces hacer que Lapsus corriera como una aplicación que se pegaba de alguna manera a MsWord, que es el procesador de palabras que la mayoría usa, pues la suite informática de Microsoft es muy popular. Entonces, habría que ver cómo enlazar ambas aplicaciones, por una parte MsWord y por otra Lapsus, para que ambas de platicaran y se intercambiaran información.

La idea básica era simple: Úsese Word y Lapsus -ya ejecutándose- estará al pendiente de cada palabra que se escriba, la cual será enviada al corrector para evaluar si está bien o mal escrita y si se encuentra algún error, mándese algún mensaje de error (desde Lapsus), que permita al usuario hacer la corrección correspondiente.

La idea es simple pero la implementación de la idea no lo fue. Por una parte, había que ver qué mecanismos permitían entablar un proceso de comunicación entre ambos programas. Hallé que Windows tiene un mecanismo llamado DDE - Data Dynamic Exchange, el cual permite intercambiar datos entre aplicaciones.

De acuerdo a la Wikipedia: Dynamic Data Exchange(DDE) es una tecnología de comunicación entre varias aplicaciones bajo Microsoft Windows y en OS/2. Aunque es apto para las últimas versiones de Windows, ha sido reemplazado por su mucho más poderoso sucesor Object Linking and Embedding, COM y OLE Automation. Sin embargo, todavía se usa en varios sitios dentro de Windows, por ejemplo en la asociación de archivos. En particular, DDE permite que una aplicación abra una sesión con otra, enviar comandos al servidor de aplicaciones y recibir respuestas. Sin embargo, este no permite incorporar una interfaz del servidor dentro de la aplicación cliente, tampoco soporta la incorporación de un servidor de datos dentro del archivo cliente (por ejemplo: almacenamiento estructurado); y para usar DDE se tienen que conocer los comandos de DDE que el servidor soporta, lo cual no ha sido generalmente estandarizado (si bien existieron algunos estándares, como la especificación spyglass para navegadores web), Así, para emplear toda la funcionalidad del DDE, se debe agregar código especial en cada aplicación cliente para cada servidor que este quiera controlar, o la aplicación cliente debe facilitar un lenguaje de script o macro. Un uso común de DDE fue para desarrollar aplicaciones personalizadas para controlar software disponible, ejemplo: un aplicación escrita en C o algún otro lenguaje debía usar DDE para abrir una hoja de cálculo Microsoft Excel y llenarla con datos, por medio de una conversación con Excel y el envío de comandos DDE. Sin embargo, hoy se usa el modelo de objeto de Excel con OLE Automation (automatización OLE) (esto es una parte de COM). Windows tiene la habilidad de llamar NetDDE, el cual posibilita que los mensajes DDE sean enviados entre aplicaciones que corren en máquinas diferentes. Su uso es raramente utilizado, pero todavía tiene soporte. El cuaderno de Microsoft (Microsoft Clipbook) y el juego de cartas Corazones (Microsoft Hearts) son algunas de las aplicaciones que usan NetDDE.

Cabe señalar que DDE además, resulta un monstruo difícil de enfrentar. La documentación: unos 60 megabytes, es oscura e impenetrable. Cuando hice mis primeras pruebas de Lapsus con DDE hallé que una vez no funcionaba bien y otra vez tampoco. Aparte de oscuro resultó francamente inestable. Así que después de unos meses de padecer a DDE me declaré incompetente (o lo declaré más bien incompetente) y decidí buscar otra opción.

Por suerte hallé que OLE automation es la solución a muchas de las dificultades. El protocolo de comunicación entre procesos es mucho más claro y además, para Office ya está implementado en muchísimas plataformas, inclusive Delphi. Curiosamente los ejemplos que hallé sobre cómo pasar una palabra desde Word a Lapsus y regresarla corregida son inexistentes. Hay muchos ejemplos de cómo hacer para que Word, a través de una aplicación en Delphi, abra el menú para leer un archivo, o para guardarlo, pero nada de la manipulación de las palabras.

Buscando en la red hallé que la revista Delphi Informant (septiembre y octubre del 2000), traía probablemente esa información. Y aunque la revista había desaparecido, estaba a la venta el CD con todos los artículos en PDF. Tuve dificultades con los que venden el CD (ya lo mencioné en algún artículo pasado), pero finalmente me hice de esos artículos y entonces Lapsus podía entonces cobrar vida, pues la parte medular había sido resuelta.

Ya hablaremos más adelante de los detalles al respecto.

Lapsus: anatomía de un corrector ortográfico V

La búsqueda binaria

Una de las cosas que hacen inevitablemente los correctores ortográficos es buscar en un diccionario si la palabra que buscan existe. Es claro que hay diferentes técnicas para hacer estas búsquedas, pero sin duda la más eficiente es la llamada "búsqueda binaria".

Por ejemplo, supongamos que tenemos 1000 palabras. Asumamos que la lista está desordenada. ¿Cuántas búsquedas tengo que hacer? A lo más 1000, porque la palabra que buscamos pudiese ser la última de la lista. Ahora bien, supongamos que la misma lista está ordenada alfabéticamente, de la A a la Z. ¿Cuántas búsquedas tengo que hacer? 10, porque lo que hacemos es dividir y conquistar, algo así como el procedimiento común que usamos cuando queremos hallar una palabra en un diccionario físico, real: Lo abrimos a la mitad y vemos si ya nos pasamos (es decir, la palabra que buscamos tiene que estar antes), o bien, nos quedamos cortos. Si nos pasamos, tomamos la primera mitad y volvemos a dividir en dos. Vemos de nuevo si nos pasamos o no. Hacemos este procedimiento hasta ver si  está la palabra que buscamos. (La ilustración al inicio de este artículo muestra este procedimiento al tratar de ver si el número 3 está en una lista ordenada de números).

Tratar de encontrar una palabra usando una búsqueda binaria es lo más eficiente, pues a cada paso se van eliminando la mitad de los elementos por  analizar. Por ejemplo, para el caso de un diccionario con 50 millones de palabras, hay que hacer solamente 26 búsquedas. El orden del algoritmo de la búsqueda binaria es logarítmico, es decir, el numero máximo de elementos que consultas es 2 elevado a la n, donde n es el numero de elementos en total.

En una búsqueda elemento por elemento, el orden es N, porque en el peor de los casos, hay que recorrer todo el arreglo para encontrar el elemento (o para verificar que el elemento no existe). En cambio en la busqueda binaria, si se tienen N elementos, en la primera consulta se selecciona N/(2^1) elementos, en la segunda N/(2^2) elementos (queda entonces un cuarto del arreglo por buscar), en la tercera N/(2^3)... así hasta que N/(2^x) sea cero. En otras palabras 2^x > N. donde x es el numero de búsquedas que se realizaron, y vale aproximadamente log2(N+1), que es de orden logaritmico.

Para ilustrar el asunto, muchas veces le pregunto a mis alumnos ¿cuántas búsquedas tienen que hacer si el diccionario tiene 1000 palabras? Alguno responde bien: unas 10. ¿Y si tienen 2000 palabras? Ya algunos se confunden, pero la respuesta correcta son 11 búsquedas. ¿Y si tengo 4000 palabras? 12 búsquedas serán suficientes. Cada vez que duplico la cifra, tengo que aumentar una búsqueda. No creo que exista en este rubro algoritmo más eficiente, amén que encaja perfectamente para el problema de la corrección ortográfica.

Funciones de Hash

Otra alternativa son las funciones de hash. En este caso hablamos d eun  algoritmo o subrutina que mapea un conjunto grande de datos a uno más pequeño, llamado llaves. En el caso de un diccionario, podríamos tomar cada palabra y aplicarle una función que nos regresara un número entero. Así, podríamos usar ese número como un índice en un arreglo para ver si la palabra que está ahí es la que buscamos.

Veamos cómo funciona esto. Asumamos que nuestra función de hash es la suma de los caracteres de la palabra. Para hacerlo más fácil, asumamos que la A es 1, la B es 2, la C es 3, y así sucesivamente. Tomemos por ejemplo, la palabra ROMA. Aplicando la función de hash obtendremos:

R(18) + O(15) + M(13) + A(1) = 47

Ponemos entonces la palabra ROMA en el casillero 47. Así, si busco esa palabra, le aplico la función de hash y me voy al casillero 47 y listo, solamente hice un acceso al diccionario. 

El problema es cuando tenemos otra palabra como AMOR, anagrama de ROMA. En este caso, la función de hash de AMOR será:

A(1) + M(13)+ O(15) + R(18) = 47

 

de nuevo 47. Aquí tenemos lo que se llama una colisión (dos palabras quieren ocupar el mismo casillero). Cuando esto pasa con demasiada frecuencia, es decir, cuando hay muchas colisiones, es momento de buscar una mejor función de hash, aunque hasta donde entiendo, no hay una función que no tenga colisiones. El asunto es minimizar esto y manipular el problema de las colisiones con una lista ligada, por ejemplo. Modos de tratar las colisiones hay muchos, algunos más eficientes que otros, pero finalmente para resolver esto requerimos de tiempo de procesamiento.

Por ejemplo, para evitar las colisiones con nuestra función de hash original, podríamos agregarle peso a la posición de las letras, así multiplicamos por 1 al valor de la primera letra, 2 al valor de la segunda letra, etc. Y con ello resolveríamos el problema de los anagramas, que siempre dan la misma función de hash. En el caso de ROMA y AMOR tendríamos:

Para ROMA:

R(18)(1)+ O(15)(2) + M(13)(3) + A(1)(4) = 

 

R(18) + O(30) + M(39) + A(4) = 91

para AMOR:

A(1)(1) + M(13)(2)+ O(15)(3) + R(18)(4) = 

 

A(1) + M(26)+ O(45) + R(72) = 144

Así evitamos la colisión de ambos anagramas, pero es probable que nuestra función sea muy elemental igualmente y conlleve colisiones con otras palabras. Por ello mismo me inclino a no usar funciones de hash en este problema y mejor aplicar la búsqueda binaria.

Lapsus: anatomía de un corrector ortográfico IV

 Una de las ideas ya bosquejadas aquí, para crear un corrector ortográfico que saque ventaja de todas las posibilidades que ofrece el español, es el usar un diccionario que contenga los verbos conjugados. Sabemos que cualquier diccionario contiene los verbos, pero en infinitivo. Así, si en un texto un verbo está conjugado (cosa que fácilmente suele suceder), entonces no podremos checarlo usando el diccionario principal de palabras. Por ende, hay que crear un diccionario con cada verbo conjugado.

El español, de acuerdo al pequeño manual Larousse de la conjugación, contiene unos 10,000 verbos, pero muchos no son regulares, es decir, tienen excepciones en sus maneras de conjugarse. El manualito en cuestión pone todas las posibles conjugaciones para cada verbo regular e irregular. En total -según recuerdo- hay unas 101 diferentes formas de conjugar verbos, lo cual implica que los verbos regulares terminados en ar, er e ir y además 98 otras conjugaciones para los verbos irregulares.

 Dar click en la imagen para ampliarla

Hacer un diccionario con todos los verbos implica por el momento un trabajo manual de mucho tiempo, el cual no tengo. Así que decidí entrar a Internet y ver si había una lista de verbos regulares al menos. Hallé en http://es.wiktionary.org/wiki/Categor%C3%ADa:ES:Verbos_regulares una buena lista de verbos regulares, cuya cuenta es de 2159. Si cada verbo puede generar unas 51 conjugaciones diferentes, tendremos 110,109 nuevas palabras que son simplemente los verbos conjugados. Podemos añadir esto a las diferentes técnicas de búsqueda. Evidentemente, en el caso de tener todos los verbos, regulares e irregulares, alimentados en el diccionario, estaríamos hablando de 510,000 palabras extras para buscar.

Escribí un programa que precisamente genera las palabras conjugadas y permite guardar el diccionario ya ordenado. Cabe señalar que antes de guardar la información al diccionario de verbos conjugados, éste se ordena alfabéticamente para después hacer una búsqueda binaria sobre éste. Hablaremos de eso en la siguiente entrega.

Lapsus: anatomía de un corrector ortográfico III

Escribir un corrector ortográfico es algo más que hacer una tabla de look up entre las palabras a analizar y un diccionario de las mismas. Los lenguajes humanos son muy sofisticados, con reglas, con excepciones, con un sinfín de recovecos que hacen de escribir un programa de esta naturaleza un interesante reto.

Consideremos a los usuarios que procesan textos con Windows. Suelen usar la mayoría la suite informática de Microsoft, Office, en muchas de sus versiones. Particularmente -desde luego- editan sus documentos usando Word para Windows.

Escribir un corrector ortográfico que contenga todo incluido, incluso un editor de textos no suena como la mejor idea, a menos de que funcionase y tuviese el mismo look & feel que Word para Windows. Escribir el procesador de palabras que funcione más o menos similar al de Microsoft puede ser una tarea muy ingrata. Mejor sacar ventaja de su uso incorporando el corrector ortográfico -Lapsus- como una aplicación que se liga a Word y que se comunica con éste, en donde Word manda las palabras a analizar a Lapsus y este último le responde precisamente con los mensajes de corrección ortográfica o bien, con una lista de palabras probables para la corrección.

Para que esto se pueda hacer, es necesario meterse en las entrañas de OLE, Object Linking and Embedded, que es el mecanismo de comunicación entre dos procesos que corren bajo Windows. Originalmente, cuado trabajé con la primera versión para Windows de Lapsus, usé la tecnología DDE (Data Dynamic Exchange), la cual tenía un manual de referencia por demás oscuro, nulos ejemplos, y que funcionaba una vez mal y otra también. Por ello, hasta que Microsoft no sacó OLE, el corrector Lapsus tenía muchísimas dificultades para correr ligado a Word y de hecho, se congelaba inesperadamente o bien, terminaba sin avisar, etc. Gracias a OLE, esos problemas desaparecieron.

Muchas herramientas de programación ya tienen incluido en sus bibliotecas de Windows, la que corresponde a OLE y Delphi no es la excepción. Como siempre pasa en estos casos, la referencia de Microsoft o es muy general o bien, muy específica a Visual BASIC o Visual C. Así, ejemplos de cómo echar a andar la biblioteca de funciones de OLE para Delphi parecía una labor complicada.

Hallé vía Google que en una revista que ya desapareció, Delphi Informant, tenía escritos un par de artículos de cómo ligar precisamente Delphi con otras aplicación a través de OLE. La única opción disponible era comprar el CD, con seis años de la revista en PDF (y una carpeta con todo el código fuente), por unos 40 dólares. El envío eran otros 20 dólares. Me animé pues el proyecto pensaba y sigo pensando, valía la pena. El susodicho CD no llegaba después de tres meses. Escribí a la revista y me dijeron que si no llegaba en esa semana me mandarían otro. Finalmente llegó, pero lo habían mandado por vía terrestre desde Sonora. ¿El costo del envío? Unos 3 pesos. Reclamé a la empresa que me vendió el disco indicándoles que el costo del envío era un robo, porque lo mandaban por vía terrestre y ya desde territorio mexicano. Me contestaron que ellos mandan los paquetes a su distribuidor en México y que se desentienden. Pedí el reembolso pero se negaron dármelo. Entonces les dije que repartiría el CD a todo aquel que lo quisiese (la oferta sigue en pie). Me dijeron que eso era ilegal. Les dije que el robo de lo que pagué por el envío era igual de ilegal. No me contestaron más. Así terminó esta fea historia, no sin antes aclarar que los artículos escritos en dicha revista sobre la conexión Delphi-OLE son magníficos y que valen la pena. Al término de estos artículos pondré disponible todo el material para quien se interese.

Pues bien, hallé que la comunicación de mi aplicación, Lapsus, con Word de Microsoft era muy simple usando OLE. A todo esto, muchos sitios en la red explican esto, pero en Delphi omiten partes por demás fundamentales que los artículos de Delphi Informant indican con precisión. Pienso que si se trabaja con Delphi, esta revista, lamentablemente ya desaparecida, tenía un buen caudal de información.

Con ello en mente, y ya habiendo probado que podía hacer "platicar"a Lapsus con Word, me di a la tarea de crear un primer menú con las opciones que el sistema debería tener. He aquí lo que esquematicé:

Dar click para ver en tamaño completo

En el siguiente artículo hablaremos de las opciones que el sistema tiene y ya nos adentraremos a analizar algunas partes del sistema que merecen más atención.

Lapsus: anatomía de un corrector ortográfico II

Las palabras con acento diacrítico

En el artículo anterior, hablamos de las características más importantes que un programa como Lapsus debe tener, que son -en principio- las diferentes estrategias para buscar palabras mal escritas. Sin embargo, hay que analizar otras cuestiones. Por ejemplo, las palabras que pueden tener un significado diferente y escribirse idénticamente, o bien, aquellas que de acuerdo al contexto tienen o no acento ortográfico.

Por ejemplo, "tú", como en la siguiente frase: "tú eres programador"; o bien "tu", como en "tu casa me gusta". Aquí, el acento ortográfico se pone si se habla del pronombre. Lo mismo pasa con "él" y "el". También tenemos el caso de "sólo" y "solo". Y aunque sé que la Real Academia de la Lengua Española ya parece haber relajado algunas reglas, el caso tradicional es que "sólo" lleva tilde en la primera "o" si se puede sustituir por el adverbio "solamente". En caso de hablar de "solo", como en la frase: "me siento solo", no se acentúa.

¿Cómo tratar con este problema. Para que el corrector ortográfico pueda corregir estos casos, requeriría de entender contextos y esto no parece ser algo que pueda hacerse fácilmente. Hay técnicas, que incluyen "tokenizar", es decir, poner cada palabra como un token, como una partícula y ver la siguiente partícula a ver si se da que es un token conocido. Por ejemplo, si escribimos: "¿Por qué la vida tiene que ser así de injusta?", habría que considerar el token que represente al signo de interrogación que abre, seguido de dos tokenes, valga la palabreja, que serían únicos: por y qué. En este caso podríamos decir que así está bien escrito, pero si ponemos: "¿Porqué la vida tiene que ser así de injusta?", ya en este caso tendríamos no tres tokenes, sino dos: el signo de interrogación que abre y el token porqué. Esto debería ser marcado como incorrecto.

Debido a que habría que definir estos tokenes y los casos de estas palabras en particular, el sistema tendría mucho más que analizar para poder decidir si está correcta o incorrectamente escrito. Una posible solución es simplificar el problema y mandar un mensaje de alerta cuando encontremos alguna palabra en este caso. Y sí, sé que ésta no es la solución perfecta, pero en muchos casos puede ser funcional en el sentido que la mayoría de las palabras en un documento no caen en esta situación.

En los siguientes artículos nos referiremos a algunas otras técnicas, como la de los bigramas, las búsquedas binarias, entre otras cosas.

Lapsus: anatomía de un corrector ortográfico I

Cuando me fui a hacer la maestría al Reino Unido, ya tenía un proyecto en mente, el cual era hacer un corrector ortográfico inteligente. La idea era usar reglas ortográficas, entre otras cuestiones, para discenir si las palabras de un texto estaban bien escritas. Supuse que tenía que prepararme en algún lenguaje ad hoc para esta tarea y es así como decidí entrarle a la maestría, cuyo pomposo nombre era el de "Inteligencia artificial y bases de datos inteligentes".

Pues bien, después de los correspondientes cursos, poco a poco fui adquiriendo experiencia en Prolog y realmente me fascinó el asunto de programar en este paradigma, particularmente cuando se trata de hablar de paradojas lógicas, de lo que ya escribí antes aquí.

Cuando regresé a México, decidí entonces desarrollar el proyecto que me había llevado a hacer la maestría, el cual le llamé "Lapsus, un corrector ortográfico inteligente". Lo escribí completo en Turbo Prolog 2.0, incluyendo un editor de textos. Sin embargo, me di cuenta que un programa de esta naturaleza debería corer como una aplicación dentro de los programas populares de procesdamiento de palabras, por ejemplo MS Word, y por ende, había que entender cómo hacer para que mi programa y Word actuaran concurrentemente. Así pues, la versión actual de Lapsus corre concurrentemente con MS Word a través de la interfaz OLE (Object Linking and Embedded), pero ya hablaremos de este tema.

Ahora bien, en las decisiones de diseño de Lapsus, tomé las siguientes decisiones:

1. Ser capaz de usar reglas ortográficas.
2. Ser capaz de usar un diccionario con unos 500,000 términos (cortesía de una de las aplicaciones en Linux).
3. Ser capaz de usar diccionarios personalizados.
4. Ser capaz de usar otras tecnologías para buscar errores, como patrones equivocados de letras.
5. Ser capaz de usar de un diccionario de verbos ya conjugados.

Estoy de hecho convencido que un corrector ortográfico poderoso debe incluir una serie diferente de técnicas para hallar las palabras mal escritas. Un sistema híbrido sin duda es mejor que un sistema que sólo sigue una técnica en particular.

Pasemos a describir y justificar este diseño:

1. Reglas ortográficas

El español, como todo lenguaje humano es cambiante. Palabras, expresiones y reglas que se usaban en el pasado son obsoletas ahora y en vista de esta situación, se decidió mantener las reglas ortográficas en un archivo especial, el cual es consultado cada vez que el sistema se ejecuta.

Este archivo se denomina Reglas.DB, y contiene alrededor de 260 reglas ortográficas de uso común en el castellano. Las reglas pueden ser editadas con cualquier procesador de palabras (o editor de textos) que utilice el formato ASCII sin caracteres de control o símbolos especiales. Por ejemplo, el block de notas..

Cada una de las reglas ocupa un renglón en el archivo Reglas.Db. Así entonces, escribir una regla nueva significa finalmente, agregar una línea más al archivo ya mencionado. Las reglas ortográficas, para que puedan ser entendidas por el programa, requieren de estar en un formato específico para poder ser leídas por el sistema. Así entonces, puede ser que en un principio, el archivo Reglas.DB le parezca al usuario final difícil de entender. No obstante la aparente complejidad del mismo, sus elementos esenciales son muy fáciles de comprender y usar.

Por ejemplo, he aquí una parte del conjunto de reglas ortográficas (sacadas del pequeño Larousse de la gramática española):

• v enb p
• v mob sb mobiliario
• v prib sb
• v ebo s sebo cebo efebo mancebo

Hay unas 260 reglas en total. Como éstas residen en un archivo en particular, pueden añadirse más reglas en caso de que se me haya pasado alguna.

A continuación se describe el formato completo de las reglas, indicando la sintaxis que las reglas necesitan y que -en rigor- deben ser escritas correctamente para que Lapsus pueda trabajar con las mismas:

Las reglas ortográficas tienen tres posibles alternativas, las cuales pueden aplicar a:

• prefijo (p) de la palabra analizada (parte inicial de la palabra en cuestión)
• sufijo (s) de la palabra analizada (parte final de la palabra en cuestión)
• subcadena (sb) de la palabra analizada (en cualquier subparte de la palabra en cuestión)

Las letras "p", "s", y "sb" corresponden respectivamente a prefijo, sufijo y subcadena, y estas letras serán usadas para informarle a Lapsus en qué parte de la palabra se aplica la regla ortográfica.

La regla entonces sigue el siguiente formato:

letra palabra clave lista

Pasemos al análisis de esta estructura. En primer término aparece la palabra seguido de paréntesis que abre. Esto debe aparecer en minúscula estrictamente. Acto seguido, pueden verse cuatro parámetros, a saber:

•  letra    Indica la letra a la cual se aplica la regla. Por ejemplo, si la regla ortográfica es sobre el uso de la v, éste es el parámetro que se utiliza. (Véanse los ejemplos más adelante).
•  palabra    Indica la palabra que no cumple precisamente con la regla que está siendo definida, es decir, muestra el ejemplo de la contraposición a la regla ortográfica misma.  
• clave    es exactamente lo que indica el alcance de aplicación de la regla (prefijo, sufijo o subcadena). Utilícese solamente las siguientes palabras claves (entre doble comillas: p, s, sb).
• lista        Se refiere a la lista de palabras que son la excepción a la regla en cuestión. Tales palabras deben aparecer separadas por espacios entre sí.

Algunos ejemplos pueden ser realmente ilustrativos. Considérese la siguiente regla:

Las palabras que empiezan con env se escriben siempre con v.

La regla en el archivo Reglas.DB se escribirá entonces así:

v enb p

Lapsus reconoce la regla de la siguiente manera: Las excepciones a las palabras que empiezan con env nada más pueden ser aquellas que comienzan con enb, que en este caso no hay tales excepciones a la regla y el rango de aplicación de la misma es con todos los prefijos de las palabras.

La regla descrita se refiere a palabras en donde el rango de aplicación corresponde al prefijo de las misma. Ahora considérese la siguiente regla:

Todas las palabras que terminan con ave se escriben con v.

Esta regla puede expresarse en el lenguaje descrito de la siguiente forma:

v abe s árabe jarabe

La cual puede ser descrita de la siguiente manera: Las excepciones a las palabras que terminan en ave nada más pueden ser aquellas que terminan con abe, las cuales son, árabe y jarabe (y nada más), y el rango de aplicación de la regla son los sufijos de las palabras.

Por último, un ejemplo de una regla que se refiera a subcadenas puede ser la siguiente:

Las palabras que tienen dentro de ellas (en cualquier parte de la misma) las letras ilv se escriben siempre con v.

La cual se traduce en el archivo de reglas de la siguiente forma:

v ilb sb bilbao

Y se interpreta de la siguiente manera: Las excepciones a las palabras que tienen como subpalabra ilv se escriben siempre con v, excepto la palabra bilbao.

Lapsus contiene un editor de reglas para hacer la vida más fácil al usuario (ver siguiente imagen).

 

2. Diccionario principal

Todo programa de corrección ortográfica requiere de un diccionario, que mientras más grande sea, mejor. Actualmente el diccionario de Lapsus contiene unos 500,000 términos. Originalmente tenía un diccionario de unos 250,000 términos, pero el Gemelo, Jesús Ortega, campeón de Scrabble, me dio el diccionario que hoy uso.

Obviamente para poder buscar en un diccionario con tantos términos, se necesita alguna técnica que sea eficiente. Cuando se trata de datos ordenados alfabéticamente, no hay mejor técnica que la búsqueda binaria. Por ejemplo, para ver si una palabra se encuentra en el diccionario necesitamos solamente 19 búsquedas. ¡Eso es eficiencia! Por supuesto que hay otras técnicas, como las funciones de hash, las cuales podrían hallar el término en una sola búsqueda, pero aquí hay que lidiar con hallar una función de hash adecuada (cosa nada fácil) y además, pelearse con las inevitables colisiones (cuando dos palabras ocupan el mismo sitio). Por ello, la decisión fue usar una búsqueda binaria, la cual es extremadamente rápida, más si se toma en cuenta la velocidad actual de las computadoras.


3. Diccionarios especializados

Los diccionarios tradicionales traen las palabras que normalmente se usan en un lenguaje. Sin embargo, puede pasar que no contemple palabras de algún nicho particular. Por ejemplo, pensemos en el lenguaje específico que usan los doctores. Probablemente algunos términos no aparezcan en el diccionario principal, por lo que aquí se pueden alimentar esos términos muy específicos.

Otro caso: cuando una empresa usa, por ejemplo, un nombre mal escrito. Hay en México una compañía que hace bolsas de polietileno, cuya razón social es "Volzas S.A.". Obviamente si dicha empresa escribe cartas a sus clientes y escribe la palabra "volzas", el corrector brincará anunciándonos que esa palabra está mal escrita (y tendrá razón normalmente, pero no en el contexto mencionado). Así, se pueden poner estos términos, incluso mal escritos, para evitar que Lapsus se dedique a señalarlos cuando no queremos. Un caso similar es el de la palabra "clabe", que significa en el mundo de los bancos "clave bancaria estandarizada", o algo así. Algún ingenioso le puso "clabe", lo cual es mala idea, porque nos acordamos de cómo se escriben las palabras, normalmente, porque las leemos de una manera. Por ello, cuando tenemos dudas sobre cómo se escribe un término, muchas veces la escribimos en un papel a ver cuál es la que vemos como escrita correctamente.

4. Patrones equivocados de letras

Las palabras en español no admiten ciertas combinaciones de letras. Por ejemplo, hasta donde me acuerdo, la combinación TH no existe en español. Así, si leemos un texto y partimos en bigramas ("palabras" de dos letras), podemos ver si una palabra está mal escrita sin siquiera revisar con reglas o diccionarios. Ya una implementación de esta técnica la escribí antes y se puede ver esto aquí.

5. Verbos


El español tiene alrededor de 10,000 verbos. Cada verbo tiene unas 50 conjugaciones. Por ende, esto da unos 500,000 términos que podrían ser añadidos a un diccionario de verbos conjugados. Cabe decir que se puede escribir un programa que haga esto automáticamente, pero solamente será útil para la mayoría de verbos que resulten ser regulares. En cualquier caso, la idea de un diccionario de verbos conjugados (cosa que no se verá normalmente en los diccionarios normales), puede ayudar a que la corrección sea más poderosa.

Seguiremos hablando de esto próximamente.