ok, el último punto importante tiene que ver con los componentes de los MBA
quiero hablarles de lo que se llama agendamiento
el agendamiento es la descripción del orden de los eventos en el que opera el
modelo, qué eventos ocurren y cuando
un aspecto estándar del agendamiento tiene que ver con los botones de SETUP y GO
el SETUP le dice a NetLogo cuando debe iniciar el modelo, mientras que GO le dice
que tiene que correr
no es esta la única manera en que se puede realizar el agendamiento, aunque es una
forma estándar, que denominamos como un patrón del software y que funciona para
muchos programas
pero hay algunos aspectos del agendamiento que pueden ser un poco más confusos
una de las cosas que a veces discutimos es si la actualización debe ser sincronizada
o no sincronizada
y lo que esto significa es que, si un agente cambia uno de sus estados
le tiene que decir a los otros agentes que cambien sus estados en forma inmediata?
o tiene que esperar hasta que el "tick" termine?
la forma en que uno lo hace puede ser muy diferente y puede llevar a resultados
diferentes
la regla no sincronizada puede verse en los modelos de tráfico, lobo - cordero,
hormigas y segregación
en segregación, por ejemplo, un ejemplo clásico, no esperamos hasta que todos
los agentes tienen la posibilidad de mudarse antes de que decidamos a donde
querrán ir, el agente se mueve en forma separada de los otros agentes y eso afecta
los resultados
la reglas sincronizadas pueden verse en los autómatas celulares, o en un modelo
del que no hemos hablado aún que se llama etnocentrismo, que fue originalmente
creado por Robert Axelrod
que básicamente explora la conducta etnocéntrica y como evoluciona
ambos modelos operan en forma sincronizada
y lo que queremos decir con eso es que cada agente mira alrededor, decide qué
acción va a tomar y luego espera a que todos los otros agentes tomen sus propias
decisiones y entonces realiza una acción en conjunto con los otros agentes
y eso se llama regla de sincronización y los autómatas celulares de los que vimos
un ejemplo no funcionan si usamos reglas no sincronizadas
voy a mostrarles un ejemplo
aquí tenemos el "juego de la vida" hecho en NetLogo, este un modelo de autómata
celuar, un autómata celular está relacionado en algún sentido con los MBA
generales, excepto que los agentes de los MBA se pueden mover, no se quedan fijos en
un solo lugar y el "juego de la vida" el estado de los agentes puede ser vivo o
muerto y en este caso el color magenta significa vivo y el turqueza significa
muerto
les voy a contar como las reglas determinan la vida o la muerte
y mostrarles algunos patrones estándar del juego de la vida que son interesantes y
que se llaman colisionadores y lo que hacen es lo que estamos viendo,
básicamente
recrean el mismo patrón abajo y hacia la derecha
las reglas de la vida y la muerte son muy similares en el juego de la vida
si un parche, en este caso un agente estacionario, tiene exactamente 3 vecinos
entonces nace,
si tiene 3 vecinos, si no tiene exactamente 3 vecinos
no tiene 2 vecinos entonces muere, en otras palabras, si tiene 1 vecino muere
si tiene más de 3 vecinos muere de super población
pero todo eso se hace en una forma sincronizada, en otras palabras
al comienzo de cada tick, no podemos saber cuántos vecinos hay
no queremos que uno de los agentes decida
pero podemos modificar este código para que haga esto
si en vez de estar usando este "live-neighbors" que determina el
comienzo del paso,
podemos simplemente decir
cuente los vecinos con la propiedad living
ahora vamos desde un modelo sincronizado a uno no sincronizado
y lo que les quiero mostrar es que al hacerlo
de repente, nuestros resultados no se mantienen más, el modelo que teníamos
antes no funciona más
probémoslo en una escala más amplia, aquí tenemos un patrón al azar, en vez del que
les mostré antes, déjenme cambiar
esto a la forma en que estaba antes
ahora está en modo sincronizado
y si lo dejamos correr para siempre, podemos tener estos patrones interesantes
de conducta que se suceden, pero ahora
modificando, vuelvo a los valores iniciales, vuelvo atrás
al modo no sincronizado
y ahora que lo corremos para siempre vemos patrones muy diferentes de conducta
entonces sea tu modelo o no uno sincronizado o uno no sincronizado
puede afectar enormemente los resultados de tu modelo y eso es algo que
se debe considerar cuando construimos nuestro modelo
además de la sincronización y de la no sincronización, otra cosa en la que
tenemos que pensar es cuando las acciones que hacen los agentes son secuenciales o
en forma paralela
la mayor parte de los modelos de los que hablamos son secuenciales, y lo que
queremos decir con eso es que los agentes esperan hasta que el otro agente hace lo
suyo, antes de realizar su propia acción
no operan al mismo tiempo, en la forma paralela, los agentes operan en forma
simultánea, en el modelo de termitas vemos un ejemplo de ello y les voy a
mostrar porqué funciona
en la arquitectura de las computadoras modernas, es prácticamente imposible bajo
un solo procesador, tener agentes que de verdad operen en forma simultánea, debido
a que no podemos simularlo
en vez de eso, sintéticamente podemos hacer un truco para estos sistemas
en el modelo de termitas
lo que sucede es que cada agente es asignado al azar al lugar donde realizará
su acción y luego opera hasta que cambia el estado del mundo y entonces otro agente
es elegido al azar, podemos decir que es casi paralelo, pero no del todo, no hay
acciones paralelas, de hecho es el modo
en el que el comando original de NetLogo, "ask" trabajaba
el problema con eso, era que para la gente era difícil escribir el código para eso
de ahí que el nuevo "ask" es más parecido a un bucle tradicional, donde leemos a
cada agente y recorremos todo y pasamos al próximo
en el viejo, teníamos que ir por cada agente, parar, ver otro agente, empezar
un agente va y viene, se hacía mucho más paralelo
pero era más dificil para programarlo, era difícil pensarlo, cómo hacerlo
uno puede seguir teniendo esa conducta si se prefiere, existe un comando que se
llama "ask-concurrent" en NetLogo, que hace esta suerte de paralelismo sintético
por qué deberíamos pensar en esto? bueno debido a que
en la realidad, muchas acciones son tomadas en paralelo
por ejemplo, si le estoy hablando a un amigo acerca de
un producto nuevo
alguien que está hablando en la otra punta de la habitación
no tiene porqué esperar que termine, antes de que pueda hablarle a su amigo acerca de
un nuevo producto o idea, como en el caso del modelo de la difusión
estas acciones están pasando en paralelo
pero en muchos entornos tradicionales para modelizar, no hay un buen modo de escribir
reglas para hacer eso
hay algunas cosas que denominamos "unidades generales de procesamiento de
gráficos" y estos son sistemas que tienen miles de chips funcionando para poder
simular a muchos agentes operando en forma simultánea
estos son nuevos tipos de desarrollo
es interesante, volvemos a uno de los primeros programas para MBA
de hecho NetLogo es un lenguaje que es descendiente de un lenguaje llamado
StarLogo y StarLogo fue escrito para lo que se llamaba "máquina de conexiones"
que eran 256 procesadores, que nos hubieran permitido procesar en paralelo
nuestra programación
en muchos sentidos, volvimos a donde todo comenzó, que al fin y al cabo parece ser
lo que ocurre con la ciencia