-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revisar y clarificar los criterios de inclusión de términos en el diccionario #292
Comments
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 Firefox con corrector ortográfico: memoria 382852, 2,4% - cpu 0,3 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:
|
Rickie, gracias por hacer las comprobaciones. Llevo poco tiempo usando mi sistema (Elementary OS) y no sé cómo podría medir el consumo de recursos en mi caso, así que confío en tus métricas. Otra prueba que se podría hacer es comparar el tamaño del diccionario ES con el tamaño de otros muy usados como EN o FR. Si son mayores, y damos por hecho que no hay quejas sobre su rendimiento, será que el tamaño de ES se puede incrementar sin miedo. Coincido con tus propuestas: 1) Incluir cualquier lema que figure en el DRAE, y 2) Incluir los lemas no incluidos en el DRAE cuya frecuencia según el CORPES XXI sea igual o superior a 0,2 por millón. Un saludo. |
Bueno, a falta de más comentarios, voy a ir revisando y aprobando los PR que quedan para sacar la versión 2.8. |
He probado yo también en Debian 12 con la versión 7.5.2.2 de LibreOffice Writer. He ejecutado lo siguiente para comprobar los cambios que ocurrían cada segundo:
Efectivamente, apenas se nota en LibreOffice la diferencia. Cuando abres el programa y haces clic derecho en una palabra incorrecta hay un aumento en el uso de memoria cuando está activada la corrección automática. Con corrector
Creo que se me olvidó grabar el uso que se hacía de memoria antes de abrir el programa. Sin corrector
Yo también pienso que tenemos que incluir todas las palabras de la RAE. |
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:
The text was updated successfully, but these errors were encountered: