Discussion:
Sistema texto predictivo
(demasiado antiguo para responder)
daniel_arv
2007-08-31 04:43:51 UTC
Permalink
Hola necesito hacer en C un sistema de texto predictivo, es el sistema
que utilizan los celulares para escribir mensajes de texto.
Tengo un diccionario con 85200 palabras mas o menos y lo que
necesitaria es poder realizar el sistema pero sin levantar el
diccionario a memoria, ni leer secuencialmente mas de una vez, pero si
puedo crear varios archivos auxiliares ya que puede que alguna palabra
que escriba no este en el diccionario,
todavia no se me ocurre, si alguno tiene alguna idea sera
bienvenida...

Muchas Gracias.
Y perdon por las molestias.....
Pedro Maicas
2007-08-31 18:28:01 UTC
Permalink
Post by daniel_arv
Hola necesito hacer en C un sistema de texto predictivo, es el sistema
que utilizan los celulares para escribir mensajes de texto.
Tengo un diccionario con 85200 palabras mas o menos y lo que
necesitaria es poder realizar el sistema pero sin levantar el
diccionario a memoria, ni leer secuencialmente mas de una vez, pero si
puedo crear varios archivos auxiliares ya que puede que alguna palabra
que escriba no este en el diccionario,
todavia no se me ocurre, si alguno tiene alguna idea sera
bienvenida...
A mi "me se" ha ocurrido una idea porque no es
la primera vez que respondo esta pregunta, aunque yo
nunca lo he hecho.

Puedes generar una lista ordenada en un fichero aparte,
de modo que para buscar una palabra tengas que acceder
pocas veces al fichero, haciendo una busqueda dicotómica
o binaria (como se diga), en 17 accesos tienes que encontrar
cualquier palabra (para menos de 128000 palabras)

Entonces cada vez que el usuario pulsa una tecla buscas
la primera palabra y la ultima que comienzan por
las letras que ya tienes y con eso rellenas una lista.



Saludos :-) -Pedro-

http://www.maicas.net/

e-mail en www.maicas.net
Oscar Garcia
2007-09-01 13:24:45 UTC
Permalink
Post by Pedro Maicas
Post by daniel_arv
Hola necesito hacer en C un sistema de texto predictivo, es el sistema
que utilizan los celulares para escribir mensajes de texto.
Tengo un diccionario con 85200 palabras mas o menos y lo que
necesitaria es poder realizar el sistema pero sin levantar el
diccionario a memoria, ni leer secuencialmente mas de una vez, pero si
puedo crear varios archivos auxiliares ya que puede que alguna palabra
que escriba no este en el diccionario,
todavia no se me ocurre, si alguno tiene alguna idea sera
bienvenida...
A mi "me se" ha ocurrido una idea porque no es
la primera vez que respondo esta pregunta, aunque yo
nunca lo he hecho.
Puedes generar una lista ordenada en un fichero aparte,
de modo que para buscar una palabra tengas que acceder
pocas veces al fichero, haciendo una busqueda dicotómica
o binaria (como se diga), en 17 accesos tienes que encontrar
cualquier palabra (para menos de 128000 palabras)
Entonces cada vez que el usuario pulsa una tecla buscas
la primera palabra y la ultima que comienzan por
las letras que ya tienes y con eso rellenas una lista.
A mí "se me" ha ocurrido otra idea mejor.

Teniendo en cuenta que has dicho que puedes generar archivos auxiliares
yo te propondría el siguiente esquema:

1.- Convertir el texto tecleado a "teclado numérico". Por ejemplo "casa"
se convertiría en "2272" y "emprendedor" en "36773633367".
2.- Acceder al directorio o archivo en el que se almacenan las palabras
que empiezan por la raiz tecleada. Por ejemplo, si hemos tecleado
"emprend" (3677363) accedemos al archivo ./3/6/7/7/3/6/3/palabras.txt o
./36/77/36/3.palabras.txt o simplemente ./3677363.palabras.txt. En él
habremos almacenado las palabras que comienzan por dicha combinación.
3.- Cuando agreguemos una palabra nueva al diccionario deberemos
agregarlo al archivo de cada una de sus raices. Ejemplos con "emprendedor":
* Usando directorios de un nivel:
./3/palabras.txt
./3/6/palabras.txt
./3/6/7/palabras.txt
./3/6/7/7/palabras.txt
./3/6/7/7/3/palabras.txt
./3/6/7/7/3/6/palabras.txt
./3/6/7/7/3/6/3/palabras.txt
etc...
* Usando directorios de dos niveles:
./3.palabras.txt
./36/palabras.txt
./36/7.palabras.txt
./36/77/palabras.txt
./36/77/3.palabras.txt
./36/77/36/palabras.txt
./36/77/36/3.palabras.txt
etc...
* Archivos en un mismo directorio:
./3.palabras.txt
./36.palabras.txt
./367.palabras.txt
./3677.palabras.txt
./36773.palabras.txt
./367736.palabras.txt
./3677363.palabras.txt
etc...

Con este sistema cada vez que teclees algo tendrás acceso inmediato al
archivo que contiene las palabras exactas, ni más ni menos.

Espero que te sea de utilidad la idea. Un saludo.
--
Óscar Javier García Baudet
LinaresDigital
Pedro Maicas
2007-09-02 08:49:20 UTC
Permalink
On Sat, 01 Sep 2007 15:24:45 +0200, Oscar Garcia
Post by Oscar Garcia
Con este sistema cada vez que teclees algo tendrás acceso inmediato al
archivo que contiene las palabras exactas, ni más ni menos.
Mmmmmmmmmmm no estoy de acerdo en casi nada de lo dices
en este mensaje.

No veo el "acceso inmediato", lo que tu no hagas lo tendrá
que hacer el sistema operativo y nadie te garantiza que
sea mas eficiente que si implementas la busqueda tu mismo,
y raro sería que el sistema operativo implemente un sistema
de busqueda que no se pueda mejorar, si fuera una base
de datos probablemente si, pero el sistema operativo no
creo.

Lo de los numeros no le veo la necesidad, con poner a cada directorio
el nombre de la primera palabra almacenada en esa rama sería lo mismo,
y te permitiría balancear el tamaño de los ficheros, aunque insisto en
que un solo fichero es más eficiente.

Si piensas que las primeras busquedas van a ser muy repetitivas y que
por eso ahorras tiempo haciendolo así, ten en cuenta que un programa
buscando sobre un solo fichero tambien puede mantener una cache del arbol
de índices.

Además haciendolo tu todo en tu programa, puedes hacer una búsqueda
anticipada, para cada pulsacion buscas las palabras en los dos extremos
, presentas los resultados, y hasta la proxima pulsacion puedes ir
explorando las ramas que cuelgan de esta parte y cargandolas en memoria.
(me refiero a los índices, no a las palabras)

Por otro lado, al final vas a tener que buscar en un fichero
con muchas palabras (no creo que propongas llegar a un fichero
por palabra), por lo que tendrás que indexar ese ultimo fichero
igualmente.

Y si quieres disminuir el numero de busquedas puedes recurrir
a un arbol con más ramas en cada nodo, aunque con dos ramas
todo es más facil.

Saludos :-) -Pedro-

http://www.maicas.net/

e-mail en www.maicas.net
Oscar Garcia
2007-09-02 21:44:14 UTC
Permalink
Post by Pedro Maicas
On Sat, 01 Sep 2007 15:24:45 +0200, Oscar Garcia
Post by Oscar Garcia
Con este sistema cada vez que teclees algo tendrás acceso inmediato al
archivo que contiene las palabras exactas, ni más ni menos.
No veo el "acceso inmediato", lo que tu no hagas lo tendrá
que hacer el sistema operativo y nadie te garantiza que
sea mas eficiente que si implementas la busqueda tu mismo,
y raro sería que el sistema operativo implemente un sistema
de busqueda que no se pueda mejorar, si fuera una base
de datos probablemente si, pero el sistema operativo no
creo.
Es sencillo.. no hay que mantener NADA en memoria para realizar las
búsquedas y no es necesario hacer la búsqueda porque la apertura del
archivo contiene en sí la búsqueda realizada previamente.

Según había entendido en el mensaje el sistema es para un dispositivo
móvil que carece de recursos RAM pero que puede tener recursos de
almacenamiento masivo mayores. Quizá lo haya entendido mal.. por el tema
que habló del sistema predictivo de los móviles.
Post by Pedro Maicas
Lo de los numeros no le veo la necesidad, con poner a cada directorio
el nombre de la primera palabra almacenada en esa rama sería lo mismo,
y te permitiría balancear el tamaño de los ficheros, aunque insisto en
que un solo fichero es más eficiente.
¿De qué orden es tu algoritmo? El mío es O(1), ¿y el tuyo? preveo que
O(n), O(n/i), O(n^1/2), etc... nunca son más eficientes que un O(1).

Mi algoritmo de búsqueda es de orden 1 debido a que el tiempo lo
invierte en la introducción de nuevos términos (cosa que ocurre con muy
poca frecuencia comparado con la frecuencia de búsqueda de términos).
Post by Pedro Maicas
Si piensas que las primeras busquedas van a ser muy repetitivas y que
por eso ahorras tiempo haciendolo así, ten en cuenta que un programa
buscando sobre un solo fichero tambien puede mantener una cache del arbol
de índices.
Ya tienes que tener un índice que será el que cargues, analices y en el
que deberías usar un algoritmo de búsqueda que seguirá teniendo un orden
mayor de 1.
Post by Pedro Maicas
Además haciendolo tu todo en tu programa, puedes hacer una búsqueda
anticipada, para cada pulsacion buscas las palabras en los dos extremos
, presentas los resultados, y hasta la proxima pulsacion puedes ir
explorando las ramas que cuelgan de esta parte y cargandolas en memoria.
(me refiero a los índices, no a las palabras)
¿Para qué usar CPU de manera tan ineficiente? En dispositivos portátiles
la CPU es un recurso valiosísimo. Si una raíz tiene 20 caracteres
posibles para el siguiente carácter... ¿harás 20 búsquedas y almacenarás
temporalmente el resultado?

Quizá sigo presuponiendo mal que estamos hablando de un sistema con
recursos limitados... pero sigo pensando que usar la CPU de esa manera
es un desperdicio.
Post by Pedro Maicas
Por otro lado, al final vas a tener que buscar en un fichero
con muchas palabras (no creo que propongas llegar a un fichero
por palabra), por lo que tendrás que indexar ese ultimo fichero
igualmente.
Si se implementa con orden 1 habría un archivo por cada componente de la
raíz teniendo en cuenta que la raíz puede ser compartida por otras
palabras. En media serán entre el doble y el triple de archivos que
palabras.

El algoritmo que he planteado, vuelvo a repetir, lo he planteado
suponiendo un escenario en el que el tamaño de la memoria principal es
muy escaso y el de almacenamiento masivo es muy superior.

Estando sobrados de espacio y recursos por supuesto que usaría búsquedas
hash o binarias como tú has planteado.
Post by Pedro Maicas
Saludos :-) -Pedro-
Saludos.
--
Óscar Javier García Baudet
LinaresDigital
http://redstar.linaresdigital.com/
Alex Estevez
2007-09-05 14:49:19 UTC
Permalink
Oscar Garcia escribió:

Si no me equivoco lo que pedro dice es que tu acabas consumiendo mas
recursos en todos los sentidos. Porque lo que para ti es "facil" en
realidad es porque no ves el trabajo que hace detras el SO, gastando la
CPU y memoria que tu no usas.

Si cada vez que se presiona una tecla se tiene que cerrar un archivo y
abrir otro y leerlo e idem cada vez que se borra el ultimo caracter
introducido...

Por mi parte, sin haber pensado mucho en ello. creo que la clave estara
en tener el archivo correctamente ordenado y uno auxiliar indice.

La mejor manera para ese indice no la conozco. Las palabras deberian ser
guardas en el orden "numerico de teclado"

es decir

"adios" y "bebe" que empezarian con raiz 11 y 11 ambas deberian estar
mas cerca que "adios" y "ahi" de raiz 11 y 14.

Imagino que el indice seria por esas raices numericas.

Saludos algo difusos :)
Oscar Garcia
2007-09-05 20:44:02 UTC
Permalink
Post by Alex Estevez
Si no me equivoco lo que pedro dice es que tu acabas consumiendo mas
recursos en todos los sentidos. Porque lo que para ti es "facil" en
realidad es porque no ves el trabajo que hace detras el SO, gastando la
CPU y memoria que tu no usas.
La memoria no, porque no almaceno ningún índice en memoria ni tengo que
gastar CPU recorriendo un índice con ningún algoritmo constantemente.
Post by Alex Estevez
Si cada vez que se presiona una tecla se tiene que cerrar un archivo y
abrir otro y leerlo e idem cada vez que se borra el ultimo caracter
introducido...
No. Cada vez que pulsas una tecla se abre un archivo, se lee y se
cierra. El resultado es el contenido del archivo, no hay que gastar CPU
adicional en hacer ningún tipo de búsqueda. Dime que eres capaz de
teclear lo suficientemente rápido para colapsar al sistema operativo
abriendo un archivo, leyendo unas pocas líneas dentro de él y luego
cerrarlo.

No hay que mantenerlo abierto ni mantener nada en memoria que no sea
realmente útil. En el caso de tener que hacer búsquedas hay que mantener
el array completo, o al menos el índice completo, para que funcione el
algoritmo de búsqueda.
Post by Alex Estevez
Por mi parte, sin haber pensado mucho en ello. creo que la clave estara
en tener el archivo correctamente ordenado y uno auxiliar indice.
Claro que es una buena solución y sería la ideal para un PC normal.
Otras veces suelo hacer pruebas de rendimiento a los programas que
propongo, pero debido a los exámenes de septiembre no puedo disponer de
demsiado tiempo para esas cosas. De todas formas sigo diciendo que un
algoritmo de orden 1 (independiente de n) es mucho más efectivo que uno
de orden n/i.

Un saludo.
--
Óscar Javier García Baudet
LinaresDigital
Pedro Maicas
2007-09-06 09:10:45 UTC
Permalink
On Wed, 05 Sep 2007 22:44:02 +0200, Oscar Garcia
Post by Oscar Garcia
La memoria no, porque no almaceno ningún índice en memoria ni tengo que
gastar CPU recorriendo un índice con ningún algoritmo constantemente.
.......................................................................
No. Cada vez que pulsas una tecla se abre un archivo, se lee y se
cierra. El resultado es el contenido del archivo, no hay que gastar CPU
Sinceramente creo que no entiendes los que sucede en realidad en
el ordenador (obviamente porque no te has parado a pensarlo, ni
porque sea dificil de entender, ni porque te falte capacidad para
entenderlo)


Saludos :-) -Pedro-

http://www.maicas.net/

e-mail en www.maicas.net
Alex Estevez
2007-09-06 10:09:48 UTC
Permalink
Post by Pedro Maicas
On Wed, 05 Sep 2007 22:44:02 +0200, Oscar Garcia
Post by Oscar Garcia
La memoria no, porque no almaceno ningún índice en memoria ni tengo que
gastar CPU recorriendo un índice con ningún algoritmo constantemente.
.......................................................................
No. Cada vez que pulsas una tecla se abre un archivo, se lee y se
cierra. El resultado es el contenido del archivo, no hay que gastar CPU
Sinceramente creo que no entiendes los que sucede en realidad en
el ordenador (obviamente porque no te has parado a pensarlo, ni
porque sea dificil de entender, ni porque te falte capacidad para
entenderlo)
A ver si podemos aclarselo :)

Veras Oscar. Si te miras el codigo fuente que se encarga de abrir un
archivo, leerlo y cerrarlo, veras que contiene un algoritmo mucho mas
grande y complejo que el que tu puedas hacer para gestionar la informacion.

El SO tiene unos servicios de entrada salida genericos por tanto grandes
y consumidores.

Si tu lees uno o dos archivos, y los guardas en memoria enteros o parte
de ellos, y usas un algoritmo para trabajar en ellos. Es muy muy muy
probable que gastes menos recursos de memoria y CPU que si dejas todo
ese trabajo al SO, con sus algoritmos genericos. Si cada vez que pulsas
una tecla, ha de trabajar el SO abriendo y cerrando archivos cualquier
pc medio puede quedarse saturado. Ya no quiero pensar en un mobil.

Ademas, las IO suelen ser lentas por eso se evitan al maximo, sobre todo
tambien en sistemas como moviles. La RAM esta para usarla si o si es muy
poco conveniente utilizar el disco (en movil ni eso) para hacer
funciones de ram. Toda busqueda que pretenda ser rapida ha de hacerse en
ram.

Ya no quiero ni pensar en los sistemas de archivos y IO con caches, que
te van a generar un quebradero de cabeza si empiezas a abrir y cerrar
archivos a lo loco.

Pero en definitiva, tu algoritmo no es mejor, ni mucho menos, solo que
tu no lo ves. Tu algoritmo es mas complejo solo que lo que tu no
programas (y no ves) es todo lo que el SO hace por ti.

Saludos
Pedro Maicas
2007-09-06 16:37:48 UTC
Permalink
On Thu, 06 Sep 2007 12:09:48 +0200, Alex Estevez
Post by Alex Estevez
Si tu lees uno o dos archivos, y los guardas en memoria enteros o parte
de ellos, y usas un algoritmo para trabajar en ellos. Es muy muy muy
Y sin guardarlos, puedes tener los archivos
"escondidos" en lo más profundo de un arbol de directorios
tal que así

/a/b/c/d/e/archivo.xxx
/a/b/c/d/f/archivo.xxx
/a/b/c/d/g/archivo.xxx

Lo mismo que si tienes un directorio con un montón
de archivos todos en el mismo directorio:

abcde_archivo.xxx
abcdf_archivo.xxx
abcdf_archivo.xxx
....

En cualquier caso, el sistema operativo tiene que "buscar" el archivo
para abrirlo. Eso es equivalente a cuando un programa de usuario tiene un
archivo ya abierto y "busca" dentro de ese archivo, se necesita un
algoritmo de búsqueda (mejor o peor) y hay que "ejecutar" ese algoritmo.

La diferencia es que el sistema operativo optimiza la
arquitectura del sistema de ficheros hasta cierto punto, optimizar
el tiempo de búsquda no es su única prioridad.

Al contrario, por ejemplo, una base de datos suele guardar
los indices (al menos *cada* indice) en un solo fichero, y
es la propia base de datos la que gestiona la busqueda, no delega
en el sistema operativo, porque el ínidice en una base de datos si
que tiene como principal objetivo acelerar la busqueda.

Es decir que de buscar no te libras, o lo haces tu, o
lo hace el sistema operativo o lo hace una base de datos o
... alguien tendrá que buscar, y puestos a buscar siempre
será más rápido hacerlo uno mismo.

Saludos :-) -Pedro-

http://www.maicas.net/

e-mail en www.maicas.net
Oscar Garcia
2007-09-08 11:43:26 UTC
Permalink
Post by Alex Estevez
Post by Pedro Maicas
On Wed, 05 Sep 2007 22:44:02 +0200, Oscar Garcia
Post by Oscar Garcia
La memoria no, porque no almaceno ningún índice en memoria ni tengo
que gastar CPU recorriendo un índice con ningún algoritmo
constantemente.
.......................................................................
No. Cada vez que pulsas una tecla se abre un archivo, se lee y se
cierra. El resultado es el contenido del archivo, no hay que gastar CPU
Sinceramente creo que no entiendes los que sucede en realidad en
el ordenador (obviamente porque no te has parado a pensarlo, ni
porque sea dificil de entender, ni porque te falte capacidad para
entenderlo)
A ver si podemos aclarselo :)
[..] Tocho que entiendo perfectamente.
Pero en definitiva, tu algoritmo no es mejor, ni mucho menos, solo que
tu no lo ves. Tu algoritmo es mas complejo solo que lo que tu no
programas (y no ves) es todo lo que el SO hace por ti.
A ver... imagínate un índique que por sí mismo no cabe en la memoria
principal de un dispositivo móvil. La mayoría de ellos no llegan a 1 MB
de RAM. Las PDAs, por suerte, suelen tener 64MB a compartir con los
datos del sistema de archivos volátil.

Imaginemos que no puedes cargar el archivo de índice en la memoria,
entonces cuéntame qué algoritmo usarías que busque en el índice sin
poder alojarlo completamente en la memoria. Dejando el archivo abierto
te ahorras el tiempo de apertura y los recursos de CPU asociados con él.
En este escenario mi algoritmo es claramente superior debido a la
cantidad de saltos y entradas/salidas asociadas con el algoritmo de
búsqueda que debería usarse.

Imaginemos que el archivo de índice sí cabe en la memoria pero el de
datos no. En ese caso la búsqueda seguirá siendo una búsqueda de orden
O(n/i) o similar (siempre superior a O(1) que tiene mi algoritmo) que se
suple con la ventaja de tener cargado en RAM los índices. Una vez
encontrados los resultados hay que hacer una búsqueda en el archivo de
datos haciendo saltos (con sus entradas/salidas asociadas) para buscar
la información a la que apunta los índices. En este caso es más difuso
saber si mi algoritmo llega a ser ventajoso o no ya que hay que
comprobar si la sobrecarga del sistema operativo (y lenguaje de
programación) a la hora de buscar y abrir el archivo es superior al
tiempo ahorrado en la búsqueda directa de orden 1.

Imaginemos que el archivo de datos y el de índice cabe en la memoria
RAM. Entonces hemos acabado porque claramente es mucho más rápido
acceder a la memoria sin hacer accesos a disco que hacerlos. En este
caso no he pensado ninguna vez y ya lo he repetido varias veces a lo
largo de mis comentarios. Sólo en casos en los que n sea elevado e i sea
pequeño mi algoritmo podría seguir teniendo superioridad siempre y
cuando al ser n tan grande el requerimiento de disco no haga inviable (o
demasido costosa en cuando a recursos) mi solución.

Lo propuse como idea, y me alegra que se haya debatido sobre ella, pero
lo que no soporto es el comentario de Pedro Maicas al que responderé muy
Post by Alex Estevez
Sinceramente creo que no entiendes los que sucede en realidad en
el ordenador (obviamente porque no te has parado a pensarlo, ni
porque sea dificil de entender, ni porque te falte capacidad para
entenderlo)
En mi carrera (I.T. de telecomunicaciones, especialidad en Telemática)
he sacado matrícula de honor en la asignatura "Sistemas Operativos" (de
tercer curso) y sobresaliente en "Fundamentos de Computadores II" (de
segundo curso). No te voy a enumerar los contenidos de esas asignaturas
pero te puedo decir que conozco mejor de lo que piensas el
funcionamiento interno de un sistema operativo.
Post by Alex Estevez
Saludos
Tal y como dije ahora estoy de exámenes y no puedo hacer pruebas reales,
pero en cuanto pueda lo implementaré en java y lo probaré con mi nokia.
Lo que más me suele gustar de las cosas que propongo es hacer
demostraciones de que llevo la razón o de que estaba en un error. Por
supuesto no siempre llevo la razón, pero me gusta hacer la prueba al
menos y comprobar en qué escenarios podría llevar ventaja (si existe
alguno).

Un saludos y gracias por la crítica constructiva (y con explicaciones) a
la solución que planteé.
--
Óscar Javier García Baudet
LinaresDigital
Eduardo
2007-09-08 12:39:32 UTC
Permalink
................
En mi carrera (I.T. de telecomunicaciones, especialidad en Telemática)
he sacado matrícula de honor en la asignatura "Sistemas Operativos" (de
tercer curso) y sobresaliente en "Fundamentos de Computadores II" (de
segundo curso). No te voy a enumerar los contenidos de esas asignaturas
pero te puedo decir que conozco mejor de lo que piensas el
funcionamiento interno de un sistema operativo.
Disculpen mi intromision en el flame, pero me surge una pregunta...
Oscar, cuales son a tu entender, los pasos que hace el SO para
encontrar fisicamente un archivo en el disco partiendo de un string
con el nombre y el camino?

Eduardo.
Pedro Maicas
2007-09-08 14:53:11 UTC
Permalink
Post by Eduardo
Disculpen mi intromision en el flame, pero me surge una pregunta...
¿ flame ?

No hay tal flame, simplemente no nos ponemos de acuerdo en
qué es lo más rápido para buscar en una lista de palabras.


Saludos :-) -Pedro-

http://www.maicas.net/

e-mail en www.maicas.net
Pedro Maicas
2007-09-08 15:51:22 UTC
Permalink
Post by Eduardo
Oscar, cuales son a tu entender, los pasos que hace el SO para
encontrar fisicamente un archivo en el disco partiendo de un string
con el nombre y el camino?
Daré yo mi opinión, por si voy muy desencaminado, para que
alguien me corrija.

Yo creo que el sistema operativo ve el HD de manera similar
a cuando nosotros vemos un fichero. Es decir que sabiendo
la posicion de "algo" dentro del HD, es capaz de leer o grabar
en esa posición.

Entonces por ejemplo si quieres abrir un fichero /a/b/c/d/xxx
el SO tiene que leer el raiz (cuya posicion sabe siempre) y buscar 'a'
una vaz sabe donde esta 'a' lee 'a' y busca 'b', idem
con el siguiente nivel.

Es decir que el HD es un arbol con un numero variable de ramas
en cada nodo.

El problema *en mi opinión* es que muy probablemente dentro
de cada directorio se almacenan los nombres de los ficheros y los
otros directorios sin ordenar y sin indexar, es decir que la busqueda
dentro de un directorio será probablemente secuencial. Por eso
muchas veces cuando hay muchos archivos en un mismo directorio
resulta mejor crear varios subdirectorios y ponerlos repartidos.


Saludos :-) -Pedro-

http://www.maicas.net/

e-mail en www.maicas.net
Eduardo
2007-09-08 20:16:02 UTC
Permalink
Post by Pedro Maicas
Post by Eduardo
Oscar, cuales son a tu entender, los pasos que hace el SO para
encontrar fisicamente un archivo en el disco partiendo de un string
con el nombre y el camino?
Daré yo mi opinión, por si voy muy desencaminado, para que
alguien me corrija.
Yo creo que el sistema operativo ve el HD de manera similar
a cuando nosotros vemos un fichero. Es decir que sabiendo
la posicion de "algo" dentro del HD, es capaz de leer o grabar
en esa posición.
Entonces por ejemplo si quieres abrir un fichero /a/b/c/d/xxx
el SO tiene que leer el raiz (cuya posicion sabe siempre) y buscar 'a'
una vaz sabe donde esta 'a' lee 'a' y busca 'b', idem
con el siguiente nivel.
Es decir que el HD es un arbol con un numero variable de ramas
en cada nodo.
El problema *en mi opinión* es que muy probablemente dentro
de cada directorio se almacenan los nombres de los ficheros y los
otros directorios sin ordenar y sin indexar, es decir que la busqueda
dentro de un directorio será probablemente secuencial. Por eso
muchas veces cuando hay muchos archivos en un mismo directorio
resulta mejor crear varios subdirectorios y ponerlos repartidos.
Saludos :-) -Pedro-
http://www.maicas.net/
e-mail enwww.maicas.net
Mis disculpas por el termino 'flame', efectivamente no corresponde.

Respecto a la manera en que el SO lee un archivo, tengo nocion de
como, pero mi duda era en realidad como piensa Oscar que lo hace,
porque parece estar convencido que entre el llamado al SO y la
obtencion de la palabra hay muy pocas instrucciones.


Los pasos que hace son basicamente los que dices y las entradas sin
ordenar, pero prefiero detallarlos mas.

Esto es mas o menos la secuencia tipica de un acceso a un disco bajo
DOS, cuando se le agregan optimizaciones (u otro sistema de archivos)
siempre se apunta a disminuir los accesos al disco por ser lejos lo
mas lento, pero los pasos son similares y el tiempo de CPU
necesariamente aumenta.

Partiendo del nombre y el camino del archivo al hacer una secuencia
del tipo fopen-fgets-fclose, el SO+BIOS deben:

- Extraer del string el drive si lo hubiere, si no hay, entonces la
ubicacion del directorio y la FAT ya la tiene guardada , si no, debe
leer la tabla de particion del disco para saber donde esta el
bootsector del nuevo drive para leerlo y saber donde esta el
directorio raiz,la FAT mas tamaño de cluster etc.

- Luego debe leer la tabla del directorio donde estan los nombres de
los archivos/directorios con los atributos correspondientes y la
direccion del primer cluster.

- Luego debe separar del string el nombre del directorio e ir
comparando string por string hasta encontrarlo.

- Ahora debe repetir los dos pasos anteriores hasta llegar al
directorio donde esta el archivo.

- Encontrado el archivo perdido en subdirectorios y verificado el
acceso el SO crea una estructura donde guarda entre otras cosas la
direccion del primer cluster y devuelve un Handle.

- Ahora se puede leer el archivo, nuevamente se llama al SO
especificando un buffer de lectura mas el handle.
El SO calcula los valores de Cyl/Head/Sector correspondientes a ese
cluster y llama al BIOS que realizara la programacion y posterior
lectura de la tarjeta controladora (bah, como en TODOS los accesos)

En este caso los archivo a leer son cortos (menos de 1 cluster), si no
fuera asi, esto se descompondria en en una sucesion de llamadas al
BIOS, pero si la memoria es poca y el disco grande tendra que leer de
nuevo del disco parte de la FAT para saber la direccion del siguiente
cluster.

- Luego se cierra el archivo liberando el handle, la unica tarea
liviana.


Para que el SO haga esto en version optimizada necesitara administrar
tablas e indices, que por ser generales, nunca consumira menos
recursos que escribir para este caso particular rutinas que
administren tablas e indices.


Saludos.
Eduardo.
Oscar Garcia
2007-09-08 19:32:33 UTC
Permalink
Post by Eduardo
................
En mi carrera (I.T. de telecomunicaciones, especialidad en Telemática)
he sacado matrícula de honor en la asignatura "Sistemas Operativos" (de
tercer curso) y sobresaliente en "Fundamentos de Computadores II" (de
segundo curso). No te voy a enumerar los contenidos de esas asignaturas
pero te puedo decir que conozco mejor de lo que piensas el
funcionamiento interno de un sistema operativo.
Disculpen mi intromision en el flame, pero me surge una pregunta...
Oscar, cuales son a tu entender, los pasos que hace el SO para
encontrar fisicamente un archivo en el disco partiendo de un string
con el nombre y el camino?
Es demasiado largo y complejo para explicarlo aquí. Depende de muchas
cosas, entre otras el sistema de archivos usado.

Como he dicho carezco de tiempo para extenderme en el tema por ahora.

A mi vuelta tras los exámenes, si ha aparecido el autor de este hilo,
procuraré hacer unas pruebecillas.

Por cierto, las haré en java con su correspondiente sobrecarga (muy
superior a la que usa fopen de C que, a su vez, es superior a la de
open). No tengo ningún dispositivo móvil (excepto la PDA) en el que se
pueda programar en C.

Saludos.
--
Óscar Javier García Baudet
LinaresDigital
daniel_arv
2007-09-10 04:53:23 UTC
Permalink
Bueno luego de un tiempo volv�, primero quiero agradecer a las
personas que tuvieron el tiempo para darme sus consejos, en especial a
Oscar Garcia y Pedro Maicas como a si tambien a Eduardo y Alex
Estevez.
Como ustedes quer�an saber mas acerca del sistema (perd�n si no fui
claro), aca lo resumo:

-Realizar un programa que SIMULE el comportamiento de textopreictivo
de los celulares. Se dispone de un diccionario ordenado.

-El diccionario original es inalterable toda palabra nueva a agregar
se lo debe de hacer en otro archivo.
-No se podr� cargar todo el diccionario en memoria
-No se permite b�squedas secuenciales de elementos en el archivo. Solo
se permite hacer accesos secuenciales de pocos elementos en el
diccionario, no m�s de 200.

-La estructura de datos a utilizar debe tener un BALANCE entre memoria
y cantidad de accesos.
-Esta permitido utilizar archivos auxiliares.


El diccionario lo sub� a rapidshare el link es: Pesa 245 Kb.
http://rapidshare.com/files/54605058/dicc.zip


Y nada mas... espero haber sido claro. Muchas Gracias.

Ahhh, Por lo que lei al igual que yo, todos estudian y estan
preparando los ex�menes de Septiembre, no se en que fecha en
particular los dar�n pero SUERTE!!! a cada uno.. y muchas gracias
nuevamente....


Lei ademas que muchos quieren hacer el programa en otros lenguajes, si
alguno lo hace estaria bueno que lo compartiera por ah� solucionamos
mas adelante el problema a otro, por mi parte si termino de hacer el
programa lo subiere a algun servidor....
Pedro Maicas
2007-09-08 15:01:19 UTC
Permalink
On Sat, 08 Sep 2007 13:43:26 +0200, Oscar Garcia
Post by Oscar Garcia
Post by Pedro Maicas
Sinceramente creo que no entiendes los que sucede en realidad en
el ordenador (obviamente porque no te has parado a pensarlo, ni
porque sea dificil de entender, ni porque te falte capacidad para
entenderlo)
En mi carrera (I.T. de telecomunicaciones, especialidad en Telemática)
he sacado matrícula de honor en la asignatura "Sistemas Operativos" (de
Siento que te haya molestado, no era mi intencion, pero realmente *creo*
que no lo estás entendiendo. Y como me extrañaba mucho, por eso añadí
la coletilla de que simplemente no te has parado a pensarlo, porque estoy
seguro leyendo tus otros mensajes que sabes más informática que yo y
que desde luego no eres más tonto que yo (aunque esto ultimo es facil).

A mi -que no tengo estudios- me sucede muchas veces que tengo
algo delante de las narices y "no lo veo", pensé que a ti te podría
estar sucediendo lo mismo.


Saludos :-) -Pedro-

http://www.maicas.net/

e-mail en www.maicas.net
Pedro Maicas
2007-09-08 15:15:52 UTC
Permalink
On Sat, 08 Sep 2007 13:43:26 +0200, Oscar Garcia
Post by Oscar Garcia
Imaginemos que no puedes cargar el archivo de índice en la memoria,
entonces cuéntame qué algoritmo usarías que busque en el índice sin
El primer algoritmo que yo expliqué, el del arbol binario con 17 busquedas
para buscar en "hasta 2^17 palabras", en ningún momento lo imaginé
en memoria, funciona perfectamente teniendo los indices en un fichero
y sigue siendo rápido y facil de programar, aunque evidentemente
un arbol de más ramas en cada nodo es más rápido (y mas dificil de programar)

Es decir, si tienes abierto el archivo de índices, puedes
leer un indice cada vez y borrar el indice que habías
leído antes, no necesitas más de cuatro bytes de memoria
( 8 en realidad, porque tienes siempre dos indices en memoria,
para hacer la comparacion de cual es mayor o menor)
Post by Oscar Garcia
Tal y como dije ahora estoy de exámenes y no puedo hacer pruebas reales,
pero en cuanto pueda lo implementaré en java y lo probaré con mi nokia.
Si encuentro un hueco, yo haré lo propio, estaría bien disponer
del archivo famoso, ese que tiene propecientas mil palabras, aunque
imagino que el autor del primer mensaje ni siquiera ha vuelto a
leer las respuestas.


Saludos :-) -Pedro-

http://www.maicas.net/

e-mail en www.maicas.net
Oscar Garcia
2007-09-08 19:12:09 UTC
Permalink
Post by Pedro Maicas
On Sat, 08 Sep 2007 13:43:26 +0200, Oscar Garcia
Post by Oscar Garcia
Tal y como dije ahora estoy de exámenes y no puedo hacer pruebas reales,
pero en cuanto pueda lo implementaré en java y lo probaré con mi nokia.
Si encuentro un hueco, yo haré lo propio, estaría bien disponer
del archivo famoso, ese que tiene propecientas mil palabras, aunque
imagino que el autor del primer mensaje ni siquiera ha vuelto a
leer las respuestas.
Estoy de acuerdo contigo.

De todas formas he releido el mensaje original y creo que desde el
principio nos estamos equivocando (sobre todo yo).

Creo entender que simplemente quiere implementar un sistema de texto
predictivo, pero no para un dispositivo móvil. Simplemente puso el
ejemplo del móvil, en el que tras pulsar una tecla aparece una palabra
propuesta (y pulsando cierta tecla rota entre las siguientes palabras
propuestas).

En este caso en particular creo que, simplemente, trata de encontrar un
sistema predictivo como usa microsoft word u openoffice.org writer.

Pensando en eso todo lo que he dicho sobra.

En cuanto esté disponible el autor original y nos aclare un poco qué es
lo que realmente quiere hacer (la verdad es que inicialmente es algo
confuso) podremos llevar a mejor puerto estas discusiones que ahora
mismo no llegan a ningún sitio.

Un saludo y hasta pronto.
--
Óscar Javier García Baudet
LinaresDigital
Oscar Garcia
2007-09-08 19:28:28 UTC
Permalink
Post by Pedro Maicas
On Sat, 08 Sep 2007 13:43:26 +0200, Oscar Garcia
Post by Oscar Garcia
Tal y como dije ahora estoy de exámenes y no puedo hacer pruebas reales,
pero en cuanto pueda lo implementaré en java y lo probaré con mi nokia.
Si encuentro un hueco, yo haré lo propio, estaría bien disponer
del archivo famoso, ese que tiene propecientas mil palabras, aunque
imagino que el autor del primer mensaje ni siquiera ha vuelto a
leer las respuestas.
Hace tiempo tuve uno de esos que se usaban para ataques de diccionario
:) aunque lo ideal es usar, por ejemplo, el diccionario que usa mozilla
en su corrector ortográfico u openoffice.org. Son más completos y están
más actualizados.

El es-ES.dic de mozilla firefox contiene 71.936 palabras.

Hay que buscarlo (en windows) en:
C:\Documents and Settings\RedStar\Datos de programa\
Mozilla\Firefox\Profiles\xxxxxx.default\extensions\
es-***@dictionaries.addons.mozilla.org\dictionaries

Lo malo de estas cosas es que al final me pico y termino haciendo
pruebas cuando no debo ;( al final me veo haciéndolo para salir de dudas
y saber hasta qué punto la sobrecarga de e/s haría bajar el rendimiento
de mi solución x)

Un saludo y hasta pronto.
--
Óscar Javier García Baudet
LinaresDigital
daniel_arv
2007-09-10 04:56:26 UTC
Permalink
Post by Pedro Maicas
On Sat, 08 Sep 2007 13:43:26 +0200, Oscar Garcia
Post by Oscar Garcia
Imaginemos que no puedes cargar el archivo de índice en la memoria,
entonces cuéntame qué algoritmo usarías que busque en el índice sin
El primer algoritmo que yo expliqué, el del arbol binario con 17 busquedas
para buscar en "hasta 2^17 palabras", en ningún momento lo imaginé
en memoria, funciona perfectamente teniendo los indices en un fichero
y sigue siendo rápido y facil de programar, aunque evidentemente
un arbol de más ramas en cada nodo es más rápido (y mas dificil de programar)
Es decir, si tienes abierto el archivo de índices, puedes
leer un indice cada vez y borrar el indice que habías
leído antes, no necesitas más de cuatro bytes de memoria
( 8 en realidad, porque tienes siempre dos indices en memoria,
para hacer la comparacion de cual es mayor o menor)
No entiendo mucho tu estrategia y no es porque este mal pero todavía
no lo relaciono con el textopedictivo, me gustaría que fueras mas
detallado(si pudiera ser?), perdóname pero me doy cuenta de que sabes
mucho y me gustaría aprender....

Por ejemplo simulemos una escritura usando el celular

Instante ------ Tecla ------Combinaciones
1--- 2 --- á, a, b, c
2--- 2, 2 --- ac, cc, aa, ab, cb, ba, bá,cá, ác, bb, áb, ca
3--- 2, 2, 7 --- car, vap, bbs, ccp, cas, bas, abs, abr, bás, acr,
bár, cár, cáp, cás, aar, baq, caq, bar.
4--- 2, 2, 7, 7 -- barr, carp, capr, cass, barq, basq, cáps, básq,
cars, carr
5-- 2, 2, 7, 7, 6 --- barro, carso, carro.

Obviamente pensemos en que las combinaciones en los instantes 2,3,4 se
encuentren en el diccionario.
Como entraría en juego tu estrategia, y
¿tener un archivo de indices no influye en los accesos.???

Gracias.... Y si alguien mas quiere aportar, agradeceria su colaboración...
daniel_arv
2007-09-10 04:58:24 UTC
Permalink
Oscar Garcia::
en muchos de tus mensajes nombrabas al orden de los algoritmos, la
pregunta es
�como sabes de que orden es un algoritmo?�Y que significa que sea de
un orden?,�Cu�l es el mejor orden?
la verdad esto no lo vi y tambi�n estar�a bueno aprenderlo..

Muchas Gracias...
Oscar Garcia
2007-09-10 12:41:15 UTC
Permalink
Post by daniel_arv
en muchos de tus mensajes nombrabas al orden de los algoritmos, la
pregunta es
¿como sabes de que orden es un algoritmo?¿Y que significa que sea de
un orden?,¿Cuál es el mejor orden?
la verdad esto no lo vi y también estaría bueno aprenderlo..
Muchas Gracias...
Es una de las medidas de complejidad de un algoritmo. El orden (O) del
que hablo describe cómo se comportará en el peor de los casos un algoritmo.

Puedes buscar en google. Yo he encontrado las siguientes páginas que
parecen explicarlo bastante bien:
http://www.lab.dit.upm.es/~lprg/material/apuntes/o/index.html
http://docencia.udea.edu.co/regionalizacion/teoriaderedes/grafosyalgoritmos.html
http://www.monografias.com/trabajos15/ingenieria-software/ingenieria-software.shtml


Un saludo.
--
Óscar Javier García Baudet
LinaresDigital
Pedro Maicas
2007-09-11 14:01:18 UTC
Permalink
Post by daniel_arv
No entiendo mucho tu estrategia y no es porque este mal pero todavía
no lo relaciono con el textopedictivo, me gustaría que fueras mas
detallado(si pudiera ser?), perdóname pero me doy cuenta de que sabes
Ok, me he bajado tu archivo, aunque ya había bajado este:
http://www.obout.com/editor_new/site_dictionaries/es-ES.zip
que es más compacto porque agrupa las terminaciones de las palabras, pero
entiendo que tu problema es un problema que te han puesto en tus
estudios, entonces mejor lo haces como te dijeron.

La primera solucion que di, o quise dar, usando un archivo
auxiliar de índices y busqueda binaria, que requiere 17 accesos
para esa cantidad de palabras, te lo puedo describir con más detalle,
aunque hay otros más rápidos organizando los índices en un arbol
con más ramas colgando de cada nodo (una solucion complicada
pero muy rápida sería "tantas ramas como letras en el alfabeto")

El arbol binario:

Primeramente tienes que generar el fichero de índices,
es decir recorres secuencialmente el fichero de palabras
y almacenas el offset donde comienza cada palabra en el fichero,
para cada palabra obtienes un entero de 32 bits. Cuando
termines ordenas este array por ejemplo empleando qsort
y lo grabas en un fichero. Esto es un trabajo previo y que
solo se hace una vez (hay que recorrer el fichero
de palabras secuencialemnte para obtener los índices pero
es de suponer que esto no cuenta, es solo una vez y se
puede ejecutar en un PC, no en la máquina destino de
la aplicacion final)

Entonces tienes ya un fichero de indices ordenado.
Para buscar una palabra lees primero en el fichero de indices
y luego en el de palabras. Ejemplo:

FILE *indices; //fichero ya abierto modo "rb"
FILE *palabras; //fichero ya abierto modo "rb"
char encontrada[64]; //ultima palabra leída

void busca_una(unsigned idx)
{
unsigned offset;
//lee el indice que está en la posicion idx
fseek(indices, idx << 2, SEEK_SET);
fread(&offset, sizeof(offset), 1, indices);
//lee la pabra correspondiente a ese indice
fseek(palabras, offset, , SEEK_SET);
fread(encontrada, 1, sizeof(encontrada), palabras);
*strchr(encontrada, 13) = 0; //esto corta la palabra en \r
}

Para buscar una palabras en todo el fichero aplicas el sistema de "partir
por la mitad" cada busqueda, a mi me gusta hacerlo aprovechando que
los numeros se almacenan en binario ;-)

#define MAXIMO_ALGORIMO 0x80000 //nunca más de medio millon de palabras
unsigned total_palabras; //previamente inicializada, palabras en el fichero

unsigned busca_esto(char *palabra)
{
int b = 0;
unsigned indice = 0;
unsigned mascara = MAXIMO_ALGORIMO;

for(; mascara; mascara >>= 1){
if(indice + mascara >= total_palabras) continue;
busca_una(indice + mascara);
b = strcmp(palabra, encontrada);
if(b >= 0) indice += mascara;
if(b == 0) return indice;
}
return indice + 1;
}


Con esto tienes solucionada la búsqueda de cualquier palabra,
la respuesta de busca_esto es el indice de la primera palabra
igual o mayor, y con busca_una puedes leer secuencialmente
las siguientes palabras mayores, todo ello a partir
del ínidce devuelto por busca_esto. (aunque hay un caso especial
si se busca una palabra menor que la primera que se puede
solucionar añadiendo un índice ficticio como primero en
la lista de índices)


Ahora tienes que ver el modo de operar cada vez que se pulse una
tecla

- lees la palabra tecleada por el usuario
- la buscas usando: busca_esto
- rellenas una lista con N palabras a partir de esa,
para lo cual puedes:
- lees secuencialmente N palabras usando busca_una
empezando con el índice obtenido antes.
- para cada palabra comprueba que es coíncidente,
puedes usar para eso strncmp (por si no hubiera N
palabras coincidentes)
- La vas metiendo a la lista de palabras posibles


Supongo que todo esto realmente deberías haberlo pensado tu solo,
ya que te lo exigen en tus estudios (no será para que lo
preguntes, será para que lo resuelvas).

Por otro lado cuando alguien "está de exámenes", no es forzosamente
que está examinandose, a lo mejor está corrigiendo exámenes:-)
Esperemos que tu profesor no esté por aquí leyendo. Había
un chiste sobre eso, pero es un poco largo para contarlo aqui.


Saludos :-) -Pedro-

http://www.maicas.net/

e-mail en www.maicas.net
daniel_arv
2007-09-12 03:00:26 UTC
Permalink
Post by Pedro Maicas
Saludos :-) -Pedro-
Bueno, muchas gracias por tu ayuda....

Chau....

Loading...