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

[Hernan Martinez Foffani]

[xavier]
>>> te invito a que desarrolles un poco mas a que te refieres
>>> exactamente, y si puede poner algun ejemplo mucho mejor.
>>
>
> Yo también creo que con ejemplos trabajaríamos mejor. Es dificil
> encontrarlos pero hacen la discusión mucho más concreta... y se
> pueden implementar en un programa ;P

me lo ponen dificil, eh? jejejeje...
intentaré encontrar un ejemplo de lo que digo.


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


>> cuando dice "en la base se definen muchas pequeñas unidades y unas
>> pocas reglas sencillas de interaccion local" mas que programación
>> bottom-up, parece estar describiendo un sistema basado en
>> componentes.
>>
>
> como bien dices más adelante (respecto a la emergencia) la metodología
> bottom-up no es "simplemente" que se definan componentes con
> interacciones locales (ej: una red neuronal, un sistema multiagente,
> una colonia de hormigas, un autómata celular, etc.) sino que de estas
> interacciones surge un patrón o comportamiento global que no se
> deduce del análisis aislado de esas interacciones locales.

entendido pues!
lo que sigue entonces es para aclarar un poquitin lo conversado.


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

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.


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



> Creo que o bien definimos autoorganización en relación a dos niveles de
> observación (uno local y otro global), y por tanto la organización es
> el resultado de un proceso bottom-up (autoorganización globlal en
> base a interacciones locales) o bien nos quedamos con una noción
> ambigua y oscura de autoorganización.

ah. bien. ahora está clarisimo.


> .... O quizás estés proponiendo una
> noción de autoorganización diferente que se me escapa.

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

-Hernan