Anuncio

Colapsar
No hay ningún anuncio todavía.

Simulando movimiento aleatorio

Colapsar
X
 
  • Filtro
  • Hora
  • Mostrar
Borrar todo
nuevos mensajes

  • Simulando movimiento aleatorio

    Hace un tiempo intenté hacer un programa en Pascal que simulara el movimiento aleatorio de una figura. En Pascal hay una función que te permite generar números enteros al azar (Randomize y Random(x), la "x" para establecer un límite), y en función de estos obtener coordenadas aleatorias.

    El movimiento tenía que ser continuo, así que por cada nueva coordenada tenía 8 posibilidades (4 píxeles arriba-abajo-iziquiera-derecha y 4 píxeles para cada esquina). Si del Random(8) me salía un 1 la nueva coordenada era CordX = CordX - 1 y CordY = CordY + 1, si salía un 2 la nueva coordenada era CordX = CordX y CordY = CordY + 1, etc..

    El caso es que observando el movimiento de la figura (un comecocos cutre ) me di cuenta de que tarde o temprano siempre acaba en el mismo lugar, aunque no siguiera la misma trayectoria para llegar o no tardara lo mismo.

    A veces se quedaba "oscilando" en el centro un buen rato, pero una vez empezaba a salirse de él lo hacía siempre en la misma dirección, y acababa en el borde de la pantalla de arriba tirando a la derecha (pero sin llegar a la esquina).

    Repasé el programa de arriba a abajo para ver si repetí alguna coordenada, pero todas eran distintas y cada una de ellas representaba un píxel distinto, y como lo máximo que les sumaba o restaba era un "1" no se podía producir ningún salto en ninguna dirección (de hecho, no se producían, sólo que siguiendo una trayectoria continua llegaba siempre a ese borde).

    No sé muy bien cómo se generan esos números aleatorios, creo que tiene que ver con algo del reloj del microprocesador pero no sé si esa es la razón de que me saliera así, o es un error de programación o de algo que no estoy teniendo en cuenta.

    No es urgente (ná, lo hice para pasar el rato ), pero si a alguien se le ocurre alguna idea..

    Saludos.

  • #2
    Re: Simulando movimiento aleatorio

    Escrito por u_maligno Ver mensaje
    Hace un tiempo intenté hacer un programa en Pascal que simulara el movimiento aleatorio de una figura. En Pascal hay una función que te permite generar números enteros al azar (Randomize y Random(x), la "x" para establecer un límite), y en función de estos obtener coordenadas aleatorias.
    Hola... yo no he dado PASCAL, pero conozco las funciones que comentas.
    ¿ Estás seguro de que x es el límite?
    Tal y como yo lo recuerdo x era la semilla que te permite inicializar
    la rutina de generación de números aleatorios... por lo cual tendrías
    que variarla.
    Si es lo que yo digo...
    ¿ se te presenta siempre el mismo problema ya uses valores distintos para
    la semilla ?

    Escrito por u_maligno Ver mensaje
    No es urgente (ná, lo hice para pasar el rato ), pero si a alguien se le ocurre alguna idea..

    Saludos.
    Tengo un programa parecido en una revista de informática.
    Es una hormiga que se mueve al azar... y en clase ( Física Estadística )
    se estudia la trayectoria del caso del borracho que camina... te lo puedes
    encontrar en cualquier libro... yo no me acuerdo de mucho ahora mismo.
    Si me acuerdo en casa lo miro y te digo algo.

    Un saludo.

    Comentario


    • #3
      Re: Simulando movimiento aleatorio

      Escrito por aLFRe
      Hola... yo no he dado PASCAL, pero conozco las funciones que comentas.
      ¿ Estás seguro de que x es el límite?
      Tal y como yo lo recuerdo x era la semilla que te permite inicializar
      la rutina de generación de números aleatorios... por lo cual tendrías
      que variarla.
      Si es lo que yo digo...
      ¿ se te presenta siempre el mismo problema ya uses valores distintos para
      la semilla ?
      Es que en Pascal se inicia con "Randomize", y el Random(x) sirve para poner un límite y almacenar el número que salga en una variable. Te pego un trozo del programa y así lo ves mejor:

      Randomize; (se inicia la rutina de generación de números aleatorios)
      Begin
      Random(8) := CoordXY; (se elige un número aleatorio entre el 1 y el 8 y se almacena en una variable)
      If CoordXY = 1 Then Begin
      CoordX = CoordX - 1 ;
      CoordY = CoordY + 1;
      End;
      If CoordXY = 2 ... etc..
      (Si el número que se almacena en CoordXY es 1 las variables CoordX y CoordY adquieren un valor concreto, si el número es 2 adquieren otro, y así hasta completar la 8 posibilidades).

      Es decir, que el "Randomize" sólo sirve para que se empiecen a generar números aleatorios, pero es en el Random (x) donde pones el límite y donde el programa elige un número concreto (entre los posibles) y donde puedes hacer la igualdad para almacenar el resultado en una variable. Luego a partir de ese resultado creas una condición para cada una de las 8 posibilidades (vaya, o las que sean), y ya obtienes los resultados de las dos coordenadas para mostrarlos en la pantalla (con PutPixel (CoordX, CoordY, Blue) por ejemplo, pintaría un pixel de color azul en la posición CoordX-CoordY).

      Esto sé que funciona bien, hice un programa que simulaba los resultados de una jornada de liga, bueno, después lo hice con una temporada entera, y al final siempre salían resultados distintos (una vez creo que hasta la ganó el Numancia ). Ahí podía ver directamente los números que salían al azar ya que se supone que eran los "goles" que metía cada equipo, y nunca pasaban de 7 (que es el límite que puse en el Random (x)), y no solía repetirse un número más que los demás.

      Pero con esto del movimiento no sé muy bien que pasa, el objeto en principio si parece que se mueve al azar, pero poco a poco "tiende" a acabar siempre en el mismo lugar. No sé, me da que si viera exactamente que números salen no me parecería que dejan de hacerlo (al azar, digo), pero por alguna razón llega un punto en el que se sigue una especie de "tendencia" a pesar de que sigan saliento números de forma aleatoria. O eso o es que realmente no son al azar, y como tb es el micro el que genera los delays (los retardos entre una posición y la siguiente) al final igual no es un movimiento "aleatorio" sino "caótico" (no entiendo mucho de física estadística, así que igual estoy diciendo una tontería. ).

      Aunque tb puede ser que lo programara mal.

      Escrito por aLFRe
      Tengo un programa parecido en una revista de informática.
      Es una hormiga que se mueve al azar... y en clase ( Física Estadística )
      se estudia la trayectoria del caso del borracho que camina... te lo puedes
      encontrar en cualquier libro... yo no me acuerdo de mucho ahora mismo.
      Si me acuerdo en casa lo miro y te digo algo.

      Un saludo.
      Pues te lo agradecería. Eso de la hormiga me suena, es aquello de que avanza en una dirección si sale "cara" y retrocede si sale "cruz"??..

      Saludos!
      Última edición por u_maligno; 09/10/2008, 18:54:20.

      Comentario


      • #4
        Re: Simulando movimiento aleatorio

        Escrito por u_maligno Ver mensaje
        Te pego un trozo del programa y así lo ves mejor:
        Hola.

        Pues gracias por el listado pero yo soy de la generación del FORTRAN IV
        y del BASIC del ZX-Spectrum y algo de C/C++ y JAVA
        He visto algo de PASCAL leyendo un libro de Borland Delphi...
        pero poco más....
        A simple vista todo parece bién... supongo que habrás declarado las variables,
        inicializado, etc...
        Efectivamente ahora que lo mencionas recuerdo que había que iniciar la rutina
        al principio del programa
        y luego llamar a la función cada vez que quieres generar un número aleatorio
        como tu bién has explicado... no obstante también recuerdo lo de la semilla...
        de todas formas tu programa de simulación de la Liga apunta a que todo va
        bién en la parte de los números aleatorios.

        No te puedo explicar el comportamiento que describes
        de tu programa ahora mismo.
        En mi post previo, yo te hablaba de dos cosas:

        La primera se ilustra con un borracho que pasea por una calle,
        como está ebrio pues puede dar un paso adelante
        o un paso hacia atras con una cierta probabilidad ( dos sucesos )
        digamos que sea 0,5 para suceso.
        Esto es un ejemplo de distribución binomia.
        Se pueden calcular muchas cosas si tienes las probabilidades iniciales.

        La segunda es la hormiga que se sitúa inicialmente en un punto de una superficie
        y en un paso puede acceder a cualquiera de los 8 cuadrados adyacentes
        o quedarse en el central y me parece que tu programa busca explorar esto.
        Tengo un artículo al respecto, del que creo recordar algo relacionado con
        lo que me dices.
        En cuanto lo pille ya veo si lo puedo escanear
        ( poco probable porque es de una revista posiblemente PCWORLD o PCMAGAZINE
        y eso tiene (c) )
        o te lo resumo.

        Un saludo.

        Comentario


        • #5
          Re: Simulando movimiento aleatorio

          Pues por lo que dices sería igual que el de la hormiga, sólo que sin la posibilidad de quedarse en el mismo punto (bueno, y con un comecocos cutre en vez de una hormiga ).

          Nada, era sólo una curiosidad, a mí me hizo pensar si realmente se pueden generar números aleatorios con un ordenador, o es sólo que se "eligen" tan rápido que no sabemos que número toca (pasado cierto tiempo).

          No sé, lo veo un poco lioso.

          Saludos!

          Comentario


          • #6
            Re: Simulando movimiento aleatorio

            Escrito por u_maligno Ver mensaje
            Nada, era sólo una curiosidad, a mí me hizo pensar si realmente se pueden generar números aleatorios con un ordenador, o es sólo que se "eligen" tan rápido que no sabemos que número toca (pasado cierto tiempo).
            No sé mucho de programación, y lo poco que sé es de C/C++,no de Pascal, pero a ver si puedo servirte de ayuda. Si no he entendido mal, tu problema es que los números aleatorios que te da el programa no son tan "aleatorios" como parece ser. En C existe la función rand(), que genera números aleatorios; sin embargo, cada vez que abres el programa, los números son los mismos. Para evitar esto, se utiliza la función srand(), que crea una seed o "semilla" para rand(), es decir, un lugar del que coger esos números aleatorios. Como comentabas, se elige como semilla el reloj del ordenador, las milésimas de segundos me parece, y así por lo general suelen ser números bastante más "aleatorios".

            (...)

            He buscado un poco por internet y randomize hace exactamente eso, crear la semilla para la función random del reloj del sistema. Por tanto, el problema debe proceder de ahí. Me explico: en un inicio el programa genera un movimiento aparentemente aleatorio, pero a la larga siempre acaba realizando el mismo patrón. Tal vez esto sea porque lo que en un inicio parecen números aleatorios acaban llevando también un patrón, lo cual es evidente porque se obtienen los números de un reloj. Esto es útil cuando necesitamos que los números sean distintos entre dos aperturas del programa, pero al parecer no lo es cuando las variables aleatorias no son "estáticas" sino "dinámicas", como aquí (por decirlo de alguna manera xD).

            Mmm...no sé si estoy en lo correcto o no, pero, resumiendo, tal vez el problema radique en eso, en que la trayectoria no es totalmente aleatoria porque depende de un ciclo que siempre es igual (la hora). Se me ocurre algo: en este caso puede que te interese no usar randomize, sino directamente la función random (si es que se puede), para que los números sean producidos aleatoriamente (no sé cómo xD) sin depender del reloj del microprocesador. No estoy seguro de esto en absoluto y dudo que funciones, pero...prueba a quitar la función randomize. Esto hará que siempre lleve la misma trayectoria siempre que abras el programa, pero me pregunto si de este modo no se "atascará" en una determinada.

            (Perdona el tochopost y para colmo sin decir mucho, es que he ido pensando cosas conforme lo escribía y...xD)

            K.

            Comentario


            • #7
              Re: Simulando movimiento aleatorio

              Bueno, supongo que no quieres crearte tu propio generador de números aleatorios (que no es tan difícil), pero podemos intentar mejorar el que ya tienes un poco. Para empezar, analicemos si sus datos son buenos. Haz lo siguiente:

              - Crea un programa que (usando el mismo método para generar los números), te genere una tira larguísima (empieza por unos miles, para acabar con miles de millones, dependiendo de la velocidad del programa). Cuenta cuantas veces sale cada resultado. Esto puedes hacerlo muy fácilmente con una matriz de dimensión 8 (una entrada para cada valor). Compara la frecuencia de cada valor con la esperada (1/8); comprueba que el error entre la frecuencia obtenida se reduce según ; es decir, si con un millón de datos tienes un error relativo del 0.02% (por decir algo), con cuatro millones deberías tener un 0.01%.

              - Haz otro programa para buscar la correlación entre un valor y el siguiente. Es decir, en cara iteración, guarda el valor aleatorio anterior, junto con el nuevo, crea una variable estadística , y haz los sumatorios que definen la correlación,


              el 4.5 viene por que es el promedio esperado, (1+8)/2.

              Algunas cosas a considerar de tu programa:

              - Asegúrate que random(8) te da un número del 1 al 8 y no del 0 al 7 (o del 0 al 8), que es lo más normal.

              - Estás siendo un poco injusto al incluir movimientos en diagonal; estos recorren un factor mayor, por lo que acabar en una esquina es normal. Lo más sencillo sería simplemente permitir sólo movimientos en los ejes cartesianos.

              - El hecho de que tengas límites te restringe un poco la cantidad de pasos que puedes hacer (el resultado de este experimento es que la distancia recorrida crece como , por lo que te conviene tener cuantos más pasos posibles, y cuanto más espacio posible para medirlo correctamente). Una posibilidad que tienes es hacer el universo períodico (es decir, que al salir por arriba aparezca por abajo). No te olvides de tener esto en cuenta al calcular la distancia recorrida.
              Última edición por pod; 11/10/2008, 00:31:39.
              La única alternativo a ser Físico era ser etéreo.
              @lwdFisica

              Comentario


              • #8
                Re: Simulando movimiento aleatorio

                Escrito por KyAlOx Ver mensaje
                No sé mucho de programación, y lo poco que sé es de C/C++,no de Pascal, pero a ver si puedo servirte de ayuda. Si no he entendido mal, tu problema es que los números aleatorios que te da el programa no son tan "aleatorios" como parece ser. En C existe la función rand(), que genera números aleatorios; sin embargo, cada vez que abres el programa, los números son los mismos. Para evitar esto, se utiliza la función srand(), que crea una seed o "semilla" para rand(), es decir, un lugar del que coger esos números aleatorios. Como comentabas, se elige como semilla el reloj del ordenador, las milésimas de segundos me parece, y así por lo general suelen ser números bastante más "aleatorios".

                (...)

                He buscado un poco por internet y randomize hace exactamente eso, crear la semilla para la función random del reloj del sistema. Por tanto, el problema debe proceder de ahí. Me explico: en un inicio el programa genera un movimiento aparentemente aleatorio, pero a la larga siempre acaba realizando el mismo patrón. Tal vez esto sea porque lo que en un inicio parecen números aleatorios acaban llevando también un patrón, lo cual es evidente porque se obtienen los números de un reloj. Esto es útil cuando necesitamos que los números sean distintos entre dos aperturas del programa, pero al parecer no lo es cuando las variables aleatorias no son "estáticas" sino "dinámicas", como aquí (por decirlo de alguna manera xD).

                Mmm...no sé si estoy en lo correcto o no, pero, resumiendo, tal vez el problema radique en eso, en que la trayectoria no es totalmente aleatoria porque depende de un ciclo que siempre es igual (la hora). Se me ocurre algo: en este caso puede que te interese no usar randomize, sino directamente la función random (si es que se puede), para que los números sean producidos aleatoriamente (no sé cómo xD) sin depender del reloj del microprocesador. No estoy seguro de esto en absoluto y dudo que funciones, pero...prueba a quitar la función randomize. Esto hará que siempre lleve la misma trayectoria siempre que abras el programa, pero me pregunto si de este modo no se "atascará" en una determinada.

                (Perdona el tochopost y para colmo sin decir mucho, es que he ido pensando cosas conforme lo escribía y...xD)

                K.
                Pues gracias por el tochopost .

                Yo también creo que tiene que ver con eso que llamas "variables dinámicas" . En el programa que hice de la liga no me pasaba porque era yo quien elegía cuando se iban a generar los números "aleatorios", y como yo no seguía ningún patrón pues a efectos prácticos obtenía resultados aleatorios (y creo que lo realmente "aleatorio" era eso, cuando iba a apretar el enter y que número asociaría el ordenador a ese "milisegundo").

                En cambio con esto del movimiento es el ordenador quien tiene que hacerlo todo, y como el delay es siempre el mismo tarde o temprano acaba siguiendo el mismo patrón. Aunque ahora que lo pienso podría hacer que el delay fuera variable, sólo que entonces el movimiento sería un poco cutre (vaya, que igual tardaría un milisegundo en cambiar de posición y luego 100 en cambiar a otra) y no sé si al final sería más de lo mismo..

                Lo de quitar el Randomize creo que no se puede hacer, aunque ahora mismo no puedo probarlo porque no me funciona bien el Pascal en XP (no me deja compilar ). Pero creo recordar que era necesario para poder utilizar el Random(x), vaya, si no tampoco le vería mucha utilidad a esa función.

                En fin, al menos ya me voy haciendo una idea de por qué ocurre con unos programas y con otros no, no sé si me servirá para encontrar una solución, aunque para mi es lo de menos (que tampoco me hace mucha ilusión conseguir que un comecocos se mueva aleatoriamente ).. Pero bueno, igual para hacer otros programas sí vendría bien saberlo.

                Saludos!

                Escrito por pod
                Bueno, supongo que no quieres crearte tu propio generador de números aleatorios (que no es tan difícil), pero podemos intentar mejorar el que ya tienes un poco. Para empezar, analicemos si sus datos son buenos. Haz lo siguiente:

                - Crea un programa que (usando el mismo método para generar los números), te genere una tira larguísima (empieza por unos miles, para acabar con miles de millones, dependiendo de la velocidad del programa). Cuenta cuantas veces sale cada resultado. Esto puedes hacerlo muy fácilmente con una matriz de dimensión 8 (una entrada para cada valor). Compara la frecuencia de cada valor con la esperada (1/8); comprueba que el error entre la frecuencia obtenida se reduce según ; es decir, si con un millón de datos tienes un error relativo del 0.02% (por decir algo), con cuatro millones deberías tener un 0.01%.

                - Haz otro programa para buscar la correlación entre un valor y el siguiente. Es decir, en cara iteración, guarda el valor aleatorio anterior, junto con el nuevo, crea una variable estadística , y haz los sumatorios que definen la correlación,



                el 4.5 viene por que es el promedio esperado, (1+8)/2.

                Algunas cosas a considerar de tu programa:

                - Asegúrate que random(8) te da un número del 1 al 8 y no del 0 al 7 (o del 0 al 8), que es lo más normal.

                - Estás siendo un poco injusto al incluir movimientos en diagonal; estos recorren un factor mayor, por lo que acabar en una esquina es normal. Lo más sencillo sería simplemente permitir sólo movimientos en los ejes cartesianos.

                - El hecho de que tengas límites te restringe un poco la cantidad de pasos que puedes hacer (el resultado de este experimento es que la distancia recorrida crece como , por lo que te conviene tener cuantos más pasos posibles, y cuanto más espacio posible para medirlo correctamente). Una posibilidad que tienes es hacer el universo períodico (es decir, que al salir por arriba aparezca por abajo). No te olvides de tener esto en cuenta al calcular la distancia recorrida.
                Gracias pod. En cuanto pueda utilizar el programa probaré todo lo que comentas (ya quise hacer algo parecido pero creo que me lié un poco ). Lo de los movimientos en diagonal ya lo había pensado, se me ocurrió dar un valor proporcional a en las probabilidades para que salieran una media de 10 diagonales por cada 14 (ya, no sería muy exacto) horizontales-verticales pero al final no supe como hacerlo. De todos modos no es que acabara en las diagonales, es que acaba siempre en la parte de arriba tirando un poco a la derecha (que si fuera por eso podría acabar igual en la de abajo o tirando a la izquierda) pero sin llegar a la esquina.

                Lo del random(8) si lo dejas tal cual creo que cuenta de 0 a 7, aunque si luego pones bien los números da igual, esto si recuerdo que lo miré bien porque ya había cometido errores de ese tipo con otros programas.

                Lo de los límites.. joer, esto no se me ocurrió!! .. Pues no tengo ni idea de qué pasaría pero si pudiera lo probaría ahora mismo. Voy a mirar por internete a ver si encuentro alguna versión de Pascal que me funcione bien en XP, si eso ya os contaré.

                Saludos!
                Última edición por u_maligno; 11/10/2008, 02:31:17.

                Comentario


                • #9
                  Re: Simulando movimiento aleatorio

                  Escrito por u_maligno Ver mensaje
                  Lo de quitar el Randomize [...]
                  No quites nada, tu programa es correcto.
                  El artículo que yo recordaba es "Orden Emergente del Caos"
                  firmado por Eloy Anguiano y se publicó en PC WORLD 118 páginas 102 y 103
                  en Febrero de 1996. No sé si puedo fotocopiarte el artículo... porque tiene copyright.

                  Lo que tu has programado es una variante de la hormiga de Langton
                  que hizo un estudio sobre este sistema en el
                  Instituto de Santa Fé ( California- EE.UU.)
                  El partía de una superficie cuadriculada con dos colores, similar
                  a un tablero de ajedrez
                  ( pero con la diferencia de que el color del cuadro se genera al azar )
                  y una hormiga empieza a moverse.
                  Voy a describierte el movimiento N:
                  La hormiga alcanza un cuadro nuevo,
                  mira el color del cuadro al que ha accedido
                  y si es blanco se mueve para un lado
                  y si es negro se mueve para el otro
                  y cambia el color del cuadro al abandonarlo
                  y así una y otra vez.

                  Para pocas iteraciones la hormiga describe una serie de motivos, esto es son curvas ( pshé... llamarle a esto curvas... ),
                  cuando aumenta el número de iteraciones eso desaparece y se ve una nube de puntos
                  y finalmente en torno a las 10,000 iteraciones la hormiga solo pasa por un estrecho corredor
                  de pocos pixeles de ancho y la dirección es fija.

                  En la licenciatura de Física me han presentado un estudio de los sistemas dinámicos en dos asignaturas
                  y este tipo de comportamiento ya se comentaba en clase.
                  Bién... yo considero que cuando entendemos algo físico podemos usar las matemáticas
                  para que yo te lo cuente a ti sin ambiguedad... pero en estos temas se recurre
                  a una cháchara inconsistente y hay poca sistemática por lo cual te voy a resumir la idea
                  ( si tienes algo mejor que hacer no leas el párrafo siguiente, el otro si por favor... y las referencias )

                  Al principio ( pocas iteraciones ) la hormiga se mueve en un territorio reducido por lo cual
                  aparentemente su movimiento parece estar inscrito en una cierta trayectoria.
                  Cuando el número de cuadros aumenta... esto se pierde y no se puede reconocer nada salvo una nube de puntos
                  Cuando el número de iteraciones es muy muy grande de alguna forma se pierde ese tipo de posibles posiciones
                  y el sistema recupera un movimiento "ordenado".

                  Bueno... felicidades porque ya ves que te has metido en un tema que ha sido materia de investigación en una Universidad.
                  Es lógico porque la potencia y la accesibilidad de equipos, software y documentación no es la misma ahora que en el 96...
                  pero bueno... yo te propondría que intentases observar a partir de que número de iteración se produce esa transición
                  e intentar representar por ejemplo "área accesible a la hormiga" frente a número de iteraciones...
                  leer un poco... abajo meto un par de referencias... dime aquello que no puedas conseguir y te lo intento buscar
                  y acuerdate de mí cuando te den el Nobel

                  Un saludo.

                  Referencias:
                  La entrada en wikipedia.
                  Un applet sobre la hormiga.
                  "Studying artificial life with cellular automata", un artículo de C. Langton,
                  publicado en Physica D número 22 páginas 120–149 (1986).

                  Esas anécdotas que nos complican la vida:
                  En el artículo que yo cito el nombre figura como Laugton.
                  Mis revistas no están indexadas de forma correcta... malo para cuando busco algo
                  y necesito una librería pero ya.
                  Última edición por aLFRe; 11/10/2008, 13:19:06.

                  Comentario


                  • #10
                    Re: Simulando movimiento aleatorio

                    Gracias aLFRe, si es que me meto en cada berenjenal.

                    Miraré en la biblioteca en la zona de revistas, creo que hay bastantes de informática así que igual la encuentro (y si no se la pido a la bibliotecaria que ya me conoce ).

                    Por lo que cuentas ahora creo que es un poco distinto, ahí en función de la casilla por la que se pasa se altera el resultado, en el mío todas las casillas son iguales y no importa por cuales pasó antes (de hecho podría volver a la anterior con la misma probabilidad (1/8) que a las demás).

                    Pero parece más interesante hacerlo como lo plantea Langton, he echado un vistazo al enlace que pusiste aunque en inglés me pierdo un poco, pero he encontrado esto La hormiga de Langton: Vida y obra en el google y ya me he aclarado un poco (bueno, dentro de lo que cabe ).

                    Lo sorprendente es que empiece a volverse loca después de 500 iteraciones, y que luego a las 10000 vuelva a seguir otro patrón. Aunque esto me parece un poco distinto a lo que intentaba hacer con mi comecocos , ni siquiera necesitaría generar números aleatorios ¿no?..

                    Pd: Ah, lo del Nobel me temo que sólo me lo van a "dar" en el estanco , pero me acordaré de ti la próxima vez que me compre uno.

                    Saludos!
                    Última edición por u_maligno; 11/10/2008, 16:47:44.

                    Comentario


                    • #11
                      Re: Simulando movimiento aleatorio

                      Escrito por u_maligno Ver mensaje
                      Miraré en la biblioteca en la zona de revistas, creo que hay bastantes de informática así que igual la encuentro (y si no se la pido a la bibliotecaria que ya me conoce ).
                      La revista es un poco antigua.
                      Pero el artículo es poco interesante, puesto que es descriptivo tiene ilustraciones
                      pero no contiene código.
                      Las demás referencias que te dí y el libro que te has bajado seguramente es más apropiado.

                      Escrito por u_maligno Ver mensaje
                      Por lo que cuentas ahora creo que es un poco distinto, ahí en función de la casilla por la que se pasa se altera el resultado, en el mío todas las casillas son iguales y no importa por cuales pasó antes (de hecho podría volver a la anterior con la misma probabilidad (1/8) que a las demás).
                      Tienes toda la razón.
                      Además tu sólo ploteas el pixel y no cambias el estado de la casilla,
                      por lo cual ambos móviles, la hormiga y el tuyo deben de generar gráficos diferentes.
                      Pero observa que el efecto final es el mismo.
                      Quizás sería interesante ver las diferencias entre la hormiga de Langton
                      y el movil de u_maligno

                      Escrito por u_maligno Ver mensaje
                      Pero parece más interesante hacerlo como lo plantea Langton, he echado un vistazo al enlace que pusiste aunque en inglés me pierdo un poco, pero he encontrado esto La hormiga de Langton: Vida y obra en el google y ya me he aclarado un poco (bueno, dentro de lo que cabe ).
                      El trabajo de Langton ha dado lugar a muchos artículos posteriores
                      y su propio trabajo ha derivado hacia lo que se llamaba hace años inteligencia artificial.
                      El mundo vegetal y animal ofrece a nuestra vista una serie de "pautas"
                      que en un primer analisis podríamos pensar que obedecen a una cierta racionalidad
                      en tu caso observa que hay una decisión y una regla clara... pero todo lo demás
                      carece de ellas por lo cual no se podría esperar ese tipo de comportamiento final.

                      Escrito por u_maligno Ver mensaje
                      Lo sorprendente es que empiece a volverse loca después de 500 iteraciones, y que luego a las 10000 vuelva a seguir otro patrón. Aunque esto me parece un poco distinto a lo que intentaba hacer con mi comecocos , ni siquiera necesitaría generar números aleatorios ¿no?..
                      Considera un sistema con una cierta "dinámica",
                      esto es dada la posición inicial tiene una regla para obtener la posición siguiente.
                      Cuando tu representas, creo recordar posiciones accesibles frente a número
                      de iteraciones, para algunos de estos aparece un comportamiento curioso.
                      Para un número de iteraciones el número de posibles sitios donde puede estar el sistema
                      ha aumentado muchísimo... por lo cual resulta imposible predecir la evolución
                      partiendo de la posición inicial...
                      pero si incrementas el número de iteraciones... de repente esto cambia
                      y el número de posiciones se reduce.
                      Este fenómeno tiene un nombre que ahora mismo no recuerdo...
                      y no lo presentan todos los sistemas.


                      Escrito por u_maligno Ver mensaje
                      Pd: Ah, lo del Nobel me temo que sólo me lo van a "dar" en el estanco ,
                      pero me acordaré de ti la próxima vez que me compre uno.
                      A todo se llega en esta vida colega
                      Pero ya que lo comentas
                      este tipo de estudio que tu has realizado puedes aplicarlo a como se forma un tumor
                      espero que cuando vayas al estanco te acuerdes de mi
                      y salgas sin comprar tabaco

                      Suerte y un saludo.

                      Comentario

                      Contenido relacionado

                      Colapsar

                      Trabajando...
                      X