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