[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [escepticos] Ackermann



Alfonso A. C. wrote:

>         Uff... si bueno, no te niego que sea memoria, pero no memoria convencional,
> sino que es tratada de forma aparte... la de codigo recursivo que he tenido
> que rehacer en iterativo tras el archiconocido "stack overflow"


Te recuerdo que un:

	MOV BP,SP
	
	Te permite acceder al stack como memoria normal y corriente que es, lo
unico que sucede es que PUSH y POP actuan amontonando en la memoria de
arriba a abajo y desamontonando al reves.

El stack overflow es porque rebosas el tamaño del stack. Es como si
rebosases la memoria reservada a n array cualquiera pero este tiene
control porque se desborda al reves, es decir, por 0 y el control de
desbordamiento de stack es simple basta con que internamente si SP es 0
no pueda hacerse un PUSH (que es lo que sucede).

Para evitarlo basta con aumentar el tamaño de stack lo necesario.


>         No creo que se puedan hacer la comparacion en recursos que haces amigo, ya
> que la gestion de esta es totalmente distinta... es como comparar una cache de
> disco con el disco duro en su totalidad. La logica empleada en su codificacion
> y uso es distinta.


No, no es muy distinta, es mas, en microcodigo de chip es identica.

 
>         Ademas, recuerda que la pila es gestionada por la propia maquina (si piensas
> en ensamblador se ve mas claro).

No, no es gestionada por la maquina, es memoria normal perfectamente
accesible para la que existen instrucciones especificas que en
microcodigo son identicas a las de cualquier acceso a memoria
convencional.
 

> > Tambien esta el tiempo debido a que es una llamada a funcion que debe
> > de realizar al menos una (o dos, dependiendo de los sistemas)
> > actuaciones en pila y un cambio de direccion de ejecucion. En muchos
> > casos, el tiempo perdido y la cqantidad de memoria utilizada en
> > exceso compensan frente a la claridad y simplicidad otras veces lo
> > que importa es la velocidad. Ya se sabe que ambas cosas normalmente
> > se oponen.
> 
>         En ocasiones estare de acuerdo contigo, no lo dudes (Fibonacci el ejemplo
> basico de recursividad), pero me remito a lo anterior y a que el tiempo
> perdido suele ser muy alto, nada deleznable.

Si se utiliza una tabla de ya calculados con indicador de calculado, la
recursividad se limita a llegar hasta el ultimo calculado. Para un
programa que utilice mucho estas funciones es lo mas sencillo y
probablemente lo mas eficaz.


>         A su vez, un nuevo argumento. La claridad y simplicidad del codigo tambien se
> obtienen documentanto este bien, y a fin de cuentas, al usuario final mas bien
> le importa poco que sea claro o no, pues no lo ve :-)


No. Salvo que indiques en la documentacion que es la implementacion no
recursiva de la definicion recursiva que se indica.
 

> > Por ejemplo. Si tu tienes que hacer una tarea 10 veces y siempre 10
> > veces es mejor que la copies diez veces seguidas que hacer un bucle,
> > es mas rapido.
 
>         Uf, y suspendo ;-)

Depende, si se me indica el motivo puede incluso subir nota. En
ensamblador es muy tipico cuando se tiene una interrupcion enganchada a
un IRQ y microsegundos pueden ser transcendentales.
 

> > Depende. Actualmente los recursos son baratos y la velocidad de los
> > ordenadores tan alta que tal vez sea mejor la claridad.
 
>         Y con el incremento de la velocidad y recursos cada vez se pide mas a los
> programas, lo cual hace que... nada, lo de siempre, la pescadilla que se
> muerde la cola.


Eso si.
 


>         Amigo, una cosa que me quedo clara hace tiempo a la hora de los
> calculos fue que ningun programa, por potente que sea, calcula senos y cosenos
> en tiempo de ejecucion, sino que los tiene en un array en memoria.

No es recursivo, es una serie y muy lento respecto a tabla en memoria.
Sin embargo, se pueden implementar como una pequeña serie en torno al
valor de tabla mas cercano. Eso disminuye drasticamente el tamaño de la
tabla y aumenta poco el tiempo de ejecucion. Y lo de siempre, depende de
en que estemos interesados, sino en velocidad, simplicidad, economia de
memoria ...


>         No es que tenga directamente que ver con la recursividad, pero si que aclara
> algo lo que quiero decir, y es que la simplicidad del codigo puede redundar en
> un incremento desproporcionado del tiempo de ejecucion.

Y si no tengo casi nada de memoria disponible ???
 

> > Depende. Si esta tardanza no es apreciable desde el punto de vista
> > humano (minimo el tiempo entre dos pulsaciones de tecla) entonces
> > carece de sentido lo de la velocidad.

> > Por supuesto. Pero en casos como este en los que la productividad no
> > es importante es mejor la claridad.

 
>         Si... creo que hablamos "parecido" pero posiblemente yo este tomando un punto
> de vista enfocado hacia el codigo en base al resultado, es decir, que codifico
> segun lo que deseo obtener, olividando algo los patrones logicos o
> algoritmicos.

 
 

>         Bueno, me voy a estudiar.

Venga, que te quedan pocos dias.


/-----------------------------------\
|  Eloy Anguiano Rey                |
|  Dpto. Ing. Informatica           |
|  U.A.M.                           |
\-----------------------------------/