RickieES
commented
1 year ago He hecho la prueba que comentaba arriba con Firefox y con LibreOffice Writer. He seguido los pasos (con una pequeña diferencia: en Firefox he usado el diccionario es-ES y en LibreOffice la variante global es). El párrafo que sigue es el texto de prueba.
Este es el texto, repetido 10 veces en un mismo párrafo y con faltas de hortografia a proposito, que he husado para probar en las haplicaciones. El ovjetivo de la prueva es verificar que el corrector ortográfico funciona y que deba generar estructuras de datos en memoria para hacer su función.
Como pone el propio texto, lo he copiado 10 veces (insertando un espacio, no un salto de línea) entre cada pegado. En mi caso, el sistema ha sido Linux Mint 21.1 MATE Edition, con Intel Core i5-8250U, 15,1 GB de RAM, Firefox 116.0.2 64-bit y LibreOffice 7.3.7.2. El texto lo tenía en un documento de texto abierto con xed (el "Notepad" de MATE) más otro documento para apuntas las cifras tal cual las pego aquí:
Firefox sin corrector ortográfico: memoria 361340, 2,2% - cpu 0,2 LibreOffice sin corrector ortográfico: memoria 277628, 1,7% - cpu 2,7
Firefox con corrector ortográfico: memoria 382852, 2,4% - cpu 0,3 LibreOffice con corrector ortográfico: memoria 278420, 1,7% - cpu 3,3 286444, 1,8%
Las cifras en Firefox se acercan a lo que preveía yo (unos 20-25 MBytes). Las de LO parecen sorprendentemente menores, pero cuando haces clic con el botón secundario sobre alguno de los errores (en concreto, sobre todos los del primer bloque de texto pegado), el uso se hace un poco más real, pasando a 286444, 1,8%.
Estas son mis cifras. Estaría bien comparar con las de algunas personas más, pero si todas fueran en la misma línea, yo respondería así a las preguntas que hacía en la apertura del issue:
- ¿Incluir todos los lemas admitidos por la RAE? --> Sí
- Si no, ¿qué criterio se usaría para incluir lemas admitidos por la RAE? Si nos basamos en la frecuencia normalizada (apariciones por millón) reportada por CORPES XXI, el criterio sería numérico y probablemente tendría que estar en un valor entre 0 y 1. --> no aplicable
- ¿Incluir todos los lemas NO admitidos por la RAE? --> No
- Si no, ¿qué criterio se usaría para incluir lemas admitidos por la RAE? Si nos basamos en la frecuencia normalizada (apariciones por millón) reportada por CORPES XXI, el criterio sería numérico y probablemente tendría que estar en un valor entre 0 y 1. --> mantendría el valor de 0,2 por el momento
Pompilos
jorgesumle
En la página del wiki Cómo colaborar con RLA ES y con el corrector ortográfico se indica que "No todas las palabras pueden incluirse en el corrector ortográfico, como es lógico" pero, a continuación, se dice que "En general, se añaden todas las palabras admitidas por el Diccionario de la Lengua Española de la RAE".
También se dice en la misma página que, para ciertos términos derivativos que no figuran como tal en el DLE de la RAE pero que están bien formadas a partir de lemas que sí se recogen en el DLE, "Aún no hemos determinado un valor umbral de frecuencia normalizada para decidir si se añade o no una palabra; recientemente, hemos descartado palabras con frecuencias normalizadas en el CORPES XXI de 0,20 apariciones por millón."
Tradicionalmente ha sido criterio del fundador de este proyecto, Santiago Bosio, no pretender que el corrector ortográfico deba contener absolutamente todos los términos, sino lo más usuales. Además del esfuerzo necesario para lograr tal meta, un argumento que se esgrimía es que un diccionario completo no sería manejable para los recursos disponibles en el sistema que hace uso del diccionario.
Ha pasado mucho tiempo desde que se plantearon los criterios de inclusión arriba expuestos y las limitaciones de recursos en los dispositivos pueden haber desaparecido... o quizá no, dependiendo de la potencia de los sistemas en los que pensemos. Si no nos limitamos solo a los PC, ahora puede haber móviles, tabletas y pequeños sistemas como Raspberry que ejecuten este software. Quizá la memoria en esos equipos sigue siendo más que suficiente, pero hay que considerar también la potencia de los procesadores, que suele estar más limitada por tratarse de equipos pensados para ejecutarse con baterías y que, aunque mejoran la potencia por vatio, tienen reducida la potencia bruta de proceso en relación a los PC.
En mi caso, no sé si las aplicaciones que ejecutan los móviles Android usan nuestro diccionario; si no lo hacen, los únicos dispositivos en los que yo uso nuestro diccionario son PC.
En cuanto al tamaño del diccionario, he descomprimido la variante "es" que publicamos en LibreOffice, he ejecutado unmunch en ella (que con el archivo .dic y el archivo .aff genera todos los lemas, incluyendo variantes de género y número, conjugaciones, enclíticos, diminutivos, aumentativos, etc.) y el resultado son estas cifras:
Hay que suponer que los 16 MBytes ocuparán bastante más en memoria porque, por cada palabra, habrá una entrada en un array y se sumará al menos un byte de fin de línea. Pero tal cosa sería una lista plana que habría que recorrer linealmente, por lo que lo lógico es que haya algún árbol binario, lo que incrementará bastante el espacio en memoria ocupado por la estructura de datos. Con todo, supongo que no hablamos de más de unos 20-25 MBytes. Para calcular esto mejor deberíamos hacer pruebas de consumo de memoria. La forma de hacer esto se me ocurre que podría ser:
Si hacemos algunas pruebas y publicamos aquí los resultados, tendremos seguramente las cifras suficientes para ir tomando decisiones.
¿Y cuáles serían las decisiones? Supongo que serían estas: