Para escribir en la vida real, no necesitas nada más que vencerte por completo. Continúo creándolo y luego escribiré un gran artículo sobre este tema, pero, qué es esto en sí mismo y qué tan difícil es medir 7 veces, cortar uno, luego medir otro 77 veces y eventualmente no cortar. Medir, medir de nuevo! - Este es el lema de alguien que quiere crear algo realmente inusual. La codificación es mucho más fácil que pensar. Pero pensar es doloroso e inusual en general.Pero hoy quiero detenerme en un "problema" que surgió aquí campaña. Imagine el movimiento caótico de partículas o elementos químicos: se mueven en un volumen condicionalmente finito, solo chocan entre sí o repelen el caos en su forma más pura. Si se lanza un sistema de este tipo, incluso en este hormiguero aparentemente inútil, se observarán movimientos estructurados de vez en cuando: pueden producirse colisiones aleatorias en un momento determinado de tal manera que la dirección de los impactos (impulso) resulte más o menos en una dirección, y luego colisionen Las partículas se moverán en una dirección, formando una onda. En el futuro, esta ola de colisiones de terceros comenzará a decaer y nuevamente veremos una imagen caótica.Aquellos. aleatoriamente en su esencia, involuntariamente forma una estructura, pero la estructura es solo una forma temporal de este azar. Fluyendo de esta manera, el caos toma varias formas, que percibimos como algo razonable, es decir. ordenado. En general, lo racional es lo que se repite para que tal repetición a una persona pueda notarse. Sin embargo, no profundizaremos en esto ahora, sino que pensaremos un poco más en amplitud.Recordemos que muy probablemente el llamado La "vida" en la Tierra surgió como resultado de la interacción caótica de elementos químicos. Tal vida nunca habría sucedido si una molécula no hubiera sido capaz de extraer electrones de otra, o viceversa, se separó de la suya. Esta OPORTUNIDAD en sí mismasolo se debió al hecho de que los compuestos aparecieron de los elementos, y de los compuestos también los primeros replicantes y organismos. Por lo tanto, si queremos crear una vida digital, debemos DAR LA OPORTUNIDAD de interacción.Si fuéramos Grandes Arquitectos del Universo y supiéramos exactamente todas sus leyes, comenzando desde la primaria, entonces los problemas de digitalizarlos no constituirían problemas serios. Pero porque como no lo somos (desafortunadamente), solo podemos confiar en el hecho de que podemos adivinar y crear las mismas condiciones que existieron con el advenimiento de la vida biológica, haciendo posible la vida digital.Es por esto que estoy tratando de describir los principios del código libre. El máximo código libre posible. Libre de nuestra propia comprensión de cómo debe organizarse la vida, ya que tal comprensión es probablemente errónea o tan incompleta que tiene muy poco sentido. Las pequeñas criaturas estamos tratando tanto de estudiar y describir todo lo que nos rodea que ni siquiera podemos hacerlo. Pero nadie prohibió intentarlo.Cuando escribes un código caótico, inevitablemente te encuentras con un tenedor. Experiencia al azar. Aquellos. ya sea avanzar caóticamente más o permitir la formación de la experiencia. Aquellos. permite no solo que las partículas choquen, sino que también interactúan. Estamos buscando un análogo de la vida biológica, que es impensable sin la transferencia y la regeneración de la experiencia. El ARN / ADN es una experiencia registrada que se transmite.Por otro lado, no se puede determinar en ningún caso, porque realmente no sabemos cómo se desarrolló y se desarrolla. Si no se elimina esta tentación, los errores son inevitables. En otras palabras, no podemos decirle al programa cómo debería verse la experiencia y cómo debería formarse. Pero podemos darle las herramientas con las que, en principio, se puede formar.Luché conmigo mismo durante mucho tiempo, porque me pareció que la estructura del almacenamiento de la experiencia podía describirse de manera bastante simple. Pensar que la simplicidad, que nos parece simple en base a nuestras propias ideas sobre la simplicidad, es una forma segura de engañarnos a nosotros mismos. Sospecho que la verdadera simplicidad es realmente compleja. Pero propongo no entrar en la demagogia aquí.Supongamos que generamos aleatoriamente una línea de código ejecutable en respuesta a un conjunto numérico de entrada aleatorio. Se puede suponer que la generación de respuesta, o reacción, es experiencia. Si algo reacciona de manera estable a las mismas señales entrantes, podemos decir que usa la experiencia. Por lo tanto, me gustaría recordar la cadena generada. ¡Pero esto no se puede hacer directamente! No puede simplemente tomar esta línea y meterla en algún lugar dentro de la variable de matriz de la instancia de clase y comenzar a crear una especie de biblioteca de reacciones de esta manera, escribiendo algo como IF [input.set in memory_ array] THEN [memoria .-> reacción]. ¡Es imposible! Porque no es un hecho que así es como funcionan los "sistemas de memoria biológica". Y no el hecho de que su construcción fuera originalmente la misma que la vemos ahora.Al mismo tiempo, no puede simplemente tomar y generar aleatoriamente una cadena de al menos 256 bytes e intentar ejecutarla, porque en las computadoras modernas tomará una gran cantidad de tiempo y no nos conviene. Es posible que dicho método sea ideal, pero, por desgracia, es imposible verificarlo con las tecnologías actuales no desarrolladas.Además, todavía tenemos un lenguaje de programación y, lo que sea que uno diga, nuestra propia idea de al menos algo. No puedes construir algo de la nada en absoluto. Por lo tanto, necesitamos una mirada subjetiva. Por ejemplo, no puedo evitar ver cómo una forma pasa a otra y viceversa, cómo el caos adquiere fácilmente una forma y también se separa de ella justo cuando una bola se levanta de un piso y se suelta cae sobre ese piso y deja una marca. Como resultado, no quiero determinar nada exactamente, pero tampoco puedo aleatorizar todo.Para entender el problema, imagine que tenemos 2 acciones posibles en el código. No puede indicar directamente cuál elegir, ya que esto será una determinación. Y si aleatoriza todo, entonces necesita usar probabilidades. ¿Solo que? 50/50? 30/70? 80/20? Supongamos que, en igualdad de condiciones, 50/50 es de hecho la relación más indefinida. Entonces el código se verá así:if random.random() >= 0.5:
1
else:
2
¿Qué está mal con este código? Y el hecho de que en cada iteración del bucle, este código SIEMPRE elegirá aleatoriamente la primera acción o la segunda. En otras palabras, ese caos nunca está estructurado, porque ni siquiera tiene una posibilidad tan teórica. En general, aquí estamos tratando con la misma determinación. Hay una salida a esta situación. Consiste en el hecho de que action1 y action2 deben cambiar las condiciones bajo las cuales se aplican. Creo que hay diferentes opciones, pero me gustaría ofrecer lo siguiente.Como sabe, los sistemas operativos equilibran los subprocesos en la cola de ejecución mediante la priorización. Un subproceso en ejecución en tiempo de ejecución pierde gradualmente prioridad, mientras que un subproceso inactivo en una cola aumenta esta prioridad. A cierto ritmo, la prioridad de este último se vuelve más alta que la primera, los flujos cambian de lugar y luego la situación se repite. Por lo tanto, los flujos se alternan rápidamente uno tras otro y vemos la ilusión de que se ejecutan casi simultáneamente.En nuestro caso, el principio de prioridad nos permitirá cambiar no los subprocesos para su ejecución en el núcleo, sino partes del código donde se transferirá el control. Y si hacemos que una parte del código sea "aleatoria" y la segunda como "experimental", entonces su cambio alternativo será la solución que estamos buscando.En otras palabras, el código, aplicando experiencia, aumentará cada vez más la probabilidad de que la próxima vez que la acción sea aleatoria, y actuando aleatoriamente, aumentará la probabilidad de aplicar experiencia en iteraciones posteriores del ciclo. Por lo tanto, obtenemos el flujo deseado de caos en la experiencia y viceversa, exactamente lo que necesitamos.Una ventaja increíble de este diseño es que no hay ningún problema con la osificación del sistema, que se conoce, por ejemplo, en las mismas redes neuronales. Por otro lado, sacrificamos la estabilidad, pero no la necesitamos aquí.Deseo especialmente enfatizar aquíque los programadores clásicos comunes necesitan la estabilidad del código como maná del cielo: el reconocimiento debe reconocer de manera estable, y no una vez cada vez, el servidor debe responder con una respuesta prescrita a la solicitud del cliente correspondiente de vez en cuando, y no de una vez por la misma respuesta , y luego otro, etc. etc. En la programación regular, la inestabilidad del código es un error claro que se detecta en las pruebas. En nuestro caso, esta estabilidad no es necesaria de la palabra en absoluto, porque no tenemos una tarea de código clara. Más precisamente, no lo es en absoluto. Pero podemos decirlo de otra manera: necesitamos la estabilidad del cambio del código de transferencia de control, y lo conseguimos. También se puede decir que el péndulo es estable, aunque logra ir de un punto al opuesto en un ciclo.Para no ser infundado, sugiero mirar el siguiente código elemental en Python, que bosquejé hoy, guiado por todas las consideraciones anteriores.import random
deter_numb = 69
p_deter = 0.01
p_random = 0.99
iteration = 1
while True:
print('iter = ',iteration)
print('p_rand = ', p_random)
print('p_deter = ', p_deter)
input()
if p_random > random.random():
p_random-=0.01
p_deter+=0.01
print(random.random())
if p_deter > random.random():
p_deter-=0.01
p_random+=0.01
print(deter_numb)
iteration+=1
Le insto a que intente ejecutar este script por su cuenta y vea cómo funciona. Este es un código de equilibrio automático. Tal como está la acción 1print(random.random())
- es decir solo una salida de número aleatorio y acciones 2 -print(deter_numb)
- salida de un número determinado. En el código, habrá acciones en su lugar, hice las impresiones aquí solo para demostrar el principio.Cuando el control pasa a la primera condición (la parte aleatoria del código), el código en sí mismo reduce la probabilidad de repetición (p_random- = 0.01 - se decrementa) y al mismo tiempo aumenta la probabilidad de ejecución de la parte del código donde se aplica la experiencia (p_deter + = 0.01 - incremento de la probabilidad de otro). Lo mismo sucede al transferir el control a la segunda condición. Por lo tanto, ambas piezas de código, cuando se ejecutan, se "ralentizan" y al mismo tiempo "aceleran" la otra parte "competidora" del código.Tenga en cuenta que la probabilidad inicial de que el control se transfiera a la parte aleatoria del código es del 99%, y a la parte experimental: 1%. Esto es para mostrar que el sistema está equilibrado incluso con probabilidades radicalmente diferentes. Al ejecutar el código, se verá cómo esta relación llegará a 50/50 en solo cien iteraciones, formando una distribución normal con un pico explícito de 0.5 y una vecindad de trabajo de aproximadamente 6% (en las próximas 3-5 iteraciones).Al ejecutar el código, está claro que las probabilidades se equilibran y se asientan alrededor de 0.5, balanceándose más allá de este punto al igual que un péndulo balanceándose en la vecindad de su punto más bajo.Aquí se ve una característica más: se muestra un número aleatorio o uno determinado (69), o ambos a la vez, lo que significa que el sistema puede aplicar la experiencia y luego actuar al azar, o viceversa, o simplemente aplicar la experiencia, o simplemente actuar Al azar En otras palabras, la ejecución del código en sí sigue siendo aleatoria, pero hemos permitido que el sistema aplique la experiencia, es decir. nos deshicimos de la determinación al decidir la acción, que era exactamente lo que necesitábamos.En el próximo artículo, consideraremos la formación de acciones y experiencias aleatorias. Bueno, o algo por separado, veamos cómo va.