[Grey-Walter] Re: [lect] bottom-up. (era: empezamos ya?)

[xabier at sindominio.net]

>
>>> en el articulo creo que se utiliza la caracteristica bottom-up en
>>> forma algo confusa. ¿por qué es necesario el bottom-up para un
>>> proceso de "autoorganización simulada"?
>>
>> Qué te hace pensar que el concepto "autoorganización" es menos
>> confuso que el de "bottom-up"?
>
> ah... no!  para mi es todo lo contrario.  mis amplios conocimientos
> sobre a-life se resumen en: dos charlas de xabier y la lecura del
> capitulo sobre emmeche.  hice mi carrera en sistemas.
>

Hostias qué interesante! Pues esa formación te permitirá digerir los
artículos mas "duros" matemáticamente. Y eso sí que me da envidia ;P



>>> si bien es muy común que un sistema diseñado y construido usando una
>>> filosofia top-down termine en un producto final monolitico y que uno
>>> construido bottom-up de un resultado con una estructura basada en
>>> componentes independientes y flexibles, eso no es necesariamente
>>> siempre así.
>>
>> algún ejemplo en que no sea así?
>
> la metodologia top-down pura (hay hibridos) es la que se usa en los
> desarrollos por prototipos.  se empieza por la cascara y se va haciendo
> el contenido por capas de afuera hacia dentro.
>
> si quisiera hacer un programa que muestre una secuencia de numeros
> impares, en un pseudo pseudo-lenguaje ;)
> --entiendo que no será un buen ejemplo, porque solo contiene un solo
> componente pero creo que es suficiente para aclarar mi punto de vista--
>
> == top-down ==
> 1ra. version:
>
>     def muestro_impares():
>         print [1, 3, 5, 7, 9]
>
>     muestro_impares()
>
> en top-down la 1ra version ya "hace" lo que necesito.
>
> 2da. version:
>
>     def muestro_impares():
>         print genero_impares(10)
>
>     def genero_impares(n):
>         return [1, 3, 5, 7, 9]      # devuelvo una lista
>
>     muestro_impares()
>
> en la 2da version praticamente tengo hecho todos los componentes
> del programa aunque la gran mayoria de los del menor nivel
> (caso genero_impares) son tontos.
>
> la ultima version es la final y es la solucion al problema dado.
>
> == bottom-up ==
> usando una metodología bottom-up lo primero que haria sería el
> generador de numeros impares, desentendiendome del "uso" final
> de dichos numeros en el problema propuesto.
>
>      def genero_impares(n):
>          impares = []               # [] == lista vacia
>          for i = 1 to n:            # bucle de i igual a 1 hasta n
>              if i % 2 == 1:         # si i no es divisible por 2
>                 impares.append(i)   # agrego i a la lista
>          return impares             # devuelvo la lista
>
> una vez construido los componentes basicos los ensamblo para
> obtener la solucion buscada.
>

Creo que esto no puede considerarse bottom-up. Yo creo que es top-down por
la siguiente razón:
- sabemos que la propiedad de números pares es "i % 2 == 1"
- hacemos una búsqueda exhaustiva de 1 a n para los números que cumplan la
definición "i % 2 == 1" (osea para los números pares)
- y luego la imprimimos.

En definitiva la función que define los números pares se aplica sobre el
conjunto de los números enteros. Osea Top (definición "i % 2 ==1") Down
(conjunto de números enteros).

Un ejemplo de metodología bottom-up seria aquella en la que la definición
"i % 2 == 1" no es explicita sino que emerge de la interacción de
componentes locales pre-funcionales (osea: en los que no se incluye la
definición, y cuyas reglas locales tampoco incluyen la definición). Es muy
dificil poner un ejemplo computacional en el que se "vea", leyendo el
programa, que el resultado da lugar a los números pares, precisamente
porque al pensamiento humano se le resiste esa capacidad (y por eso
necesitamos los ordenadores ;). En un ejemplo menos trivial que el de los
números pares LLuis nos mostró en el hm un autómata celular que
"calculaba" los números primos. LLuis nos puedes pasar esa imagen? Ahí es
donde la capacidad de computación paralela y distribuida del juego de la
vida (bottom) era capaz de mostrar una funcionalidad global (up) de
generar números primos.

> en este ejemplo las dos soluciones seran muy similares en cualquiera de
> las dos metolodogias (top-down o bottom-up) utilizadas para
> encarar el problema.  si el diseño top-down fue bueno con muchas
> versiones intermedias cada una completando un nivel de abstraccion
> preciso, el resultado será una solucion elegante, modular, con
> componentes muy bien definidos que, razonablemente, interactuarán
> con sus pares.
>
> pero la emergencia marca la diferencia.  si quisiera crear un
> programa de vida-a usando top-down, debería preveer el resultado
> antes de empezar!  eso invalida el uso de esta metodologia.
>

efectivamente, eso creo yo.

>
>>> por eso, ¿no habría que distinguir entre la construcción de los
>>> procesos de simulación donde la emergencia sea posible (bottom-up) de
>>> la estructura final donde diversos procesos se organizan por sí
>>> mismos (componentes)?
>>
>> Es aquí donde no entiendo muy bien tu diferencia entre
>> autoorganización y bottom-up. ¿Cual puede ser la diferencia? ¿qué
>> quieres decir con "diversos procesos se organizan a sí mismos"? Lo
>> digo porque creo que para que diversos procesos se organicen a sí
>> mismos es necesario que ese nivel de organización (al que se refiere
>> el "auto" en autoorganización) sea emergente, es decir surja de las
>> interacciones locales entre los componentes, es decir bottom-up.
>
> mmm... veamos... me parece que estoy hilando demasiado fino y todavia no
> tengo las herramientas para eso...
>
> quería establecer que decir SOLO "interacciones locales entre
> los componentes" no implica necesariamente bottom-up, ni mucho menos
> emergencia.  ¿o sí?  uf.  ahora me entró la duda.
>

Ahí creo que tienes razón: efectivamente puedo diseñar interacciones
locales entre componentes que no den lugar a nada, en cuyo caso no sería
bottom-up. Lo que creo que clarifica el termino bottom-up es lo siguiente:

Bottom: interacciones locales entre componentes
Up: patron global de comportamiento.

En el caso de interacciones locales (por ejemplo lanzar un montón de
piedras de goma en una habitación cerrada) que no dan lugar a ningún
patrón global solo tenemos "bottom" y nada de "up". Por eso ni hay
emergencia de organización a un nivel superior, ni "auto-organización".

> nooo... no propongo nada! a estas alturas solo trato de digerir
> conceptos.

Pues nada en eso estamos tod*s que lo mismo se aprende preguntando que
respondiendo ;) ---> en definitiva: interactuando y comunicando.

Xabier