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

Re: [escepticos] Ackermann



Hola Eloy.

Eloy Anguiano wrote:
> 
> Pero la pila es al fin y al cabo memoria. Normalmente, la cantidad de
> memoria necesaria para hacer dichos procesos sin recursividad es muy
> similar y la desventaja es minima.

	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"

	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.

	Ademas, recuerda que la pila es gestionada por la propia maquina (si piensas
en ensamblador se ve mas claro).
 
> 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.

	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 :-)
 
> 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. 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.
 
> Depende del uso. Evidentemente si va a ser intensivo lo mejor que 
> puedes hacer es tabularlo, pero basta hacer la funcion interactiva 
> con acceso a la tabla y a una tabla de marcas.

	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 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.

> 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.

 
> Por cierto, me puedes poner la formula de recursividad de nuevo?
> Es que la he borrado y queria hacer el programita.

	A(m,n) =  n+1              m=0
                  A(m-1,1)         n=0
		  A(m-1,A(m,n-1))  resto


	Bueno, me voy a estudiar. 

	Un saludo.

-- 
Alfonso A.C. (Fonso en el irc)
email: aafonso en mx3.redestb.es
www: http://personal.redestb.es/aafonso