To write real life, you do not need anything other than to defeat yourself completely and completely. I continue to create it and later I will write a huge article on this topic, but, my, what is this thing in itself and how difficult it is to measure 7 times, cut off one, then measure it another 77 times and eventually not cut off. Measure, measure again! - This is the motto of someone who wants to create something truly unusual. Coding is much easier than thinking. But to think is painful and unusual in general.But today I want to dwell on one "problem" that surfaced here campaign. Imagine the chaotic movement of particles or chemical elements — they move in a conditionally finite volume, only collide with each other, or repel — chaos in its purest form. If such a system is launched, then even in this seemingly useless anthill, structured movements will be observed from time to time: random collisions at a certain moment can occur in such a way that the direction of impacts (impulse) will turn out more or less in one direction, and then collided particles will move in one direction, forming a wave. In the future, this wave from third-party collisions will begin to decay and we will again see a chaotic picture.Those. randomly in its essence involuntarily forms a structure, but structure is only a temporary form of this random. Flowing in this way, chaos takes various forms, which we perceive as something reasonable, i.e. ordered. By and large, the rational is that which is repeated so that such a repetition to a person can be noticed. However, we will not delve into this now, but think a little more in breadth.Recall that most likely the so-called “Life” on Earth arose as a result of the chaotic interaction of chemical elements. Such a life would never have happened if one molecule had not been able to pull electrons from another, or vice versa, parted with its own. This OPPORTUNITY itselfit was only due to the fact that compounds appeared from the elements, and from the compounds the first replicants and organisms as well. Therefore, if we want to create a digital life, we must GIVE THE OPPORTUNITY of interaction.If we were Great Architects of the Universe and knew exactly all its laws, starting from the primary, then the problems of digitizing them would not constitute serious problems. But, because since we are not (unfortunately), we can only rely on the fact that we can guess and create the same conditions that were with the advent of biological life, thereby making digital life possible.It is for this that I am trying to describe the principles of free code. The maximum possible free code. Free from our own understanding of how life should be arranged - for such an understanding is most likely erroneous or so incomplete that it makes too little sense. We small creatures are trying so hard to study and describe everything around us that we can’t even do it. But no one forbade trying.When you write a chaotic code, you inevitably come across a fork. Random experience. Those. either move chaotically further, or enable the formation of experience. Those. enable not only particles to collide, but also interact. We are looking for an analogue of biological life, which is unthinkable without the transfer and regeneration of experience. RNA / DNA is a recorded experience that is transmitted.On the other hand, it cannot be determined in any case, because we do not really know how it developed and develops. If this temptation is not removed, mistakes are inevitable. In other words, we cannot tell the program how the experience should look and how it should be formed. But we can give her the tools with which he can in principle be formed.I struggled with myself for a very long time, because it seemed to me that the structure of the storage of experience could be described quite simply. To think that simplicity, which seems simple to us based on our own ideas about simplicity, is a sure way to deceive ourselves. I suspect true simplicity is truly complex. But I propose not to go into demagogy here.Suppose we randomly generated an executable line of code in response to a random input numerical set. It can be assumed that response generation, or reaction, is experience. If something reacts stably the same to the same incoming signals, we can say that it uses experience. Therefore, I would like to remember the generated string. But this cannot be done directly! You can’t just take this line and shove it somewhere into the array variable of the class instance and begin to create a kind of reaction library in this way, writing out something like IF [input.set in memory_ array] THEN [memory.-> reaction]. It is impossible! Because it’s not a fact that this is how “biological memory systems” work. And not the fact that their construction was originally the same as we see it now.At the same time, you can’t just take and randomly generate a string of at least 256 bytes and try to execute it, because on modern computers it will take a huge amount of time and does not suit us. It is possible that such a method is ideal, but alas, it is impossible to verify this with current undeveloped technologies.Plus, we still have a programming language and, whatever one may say, our own idea of ​​at least something. You cannot build something out of nothing at all. Therefore, we need a subjective look. For example, I cannot help but see how one form passes into another and vice versa, how chaos easily takes on a form and also parted with it just as a ball lifted from a floor and released falls onto that floor and leaves a mark. As a result, I don’t want to determine anything exactly, but I also can’t randomize everything.In order to understand the problem, imagine that we have 2 possible actions in the code. You cannot directly indicate which one to choose, for this will be a determination. And if you randomize everything, then you need to use probabilities. Only what? 50/50? 30/70? 80/20? Suppose, other things being equal, 50/50 is indeed the most indefinite relation. Then the code will look something like this:if random.random() >= 0.5:
1
else:
2
What is wrong with this code? And the fact that at each iteration of the loop, this code will ALWAYS randomly choose either the first action or the second. In other words, such chaos is never structured, because it does not even have such a theoretical possibility. By and large, here we are dealing with the same determination. There is a way out of this situation. It consists in the fact that action1 and action2 themselves must change the conditions under which they are applied. There are, I think, different options, but I would like to offer the following.As you know, operating systems balance threads in the execution queue using prioritization. An executing thread at runtime gradually loses priority, while a thread idle in a queue increases this priority. At a certain beat, the priority of the latter becomes higher than the first, the flows change places, and then the situation repeats. Thus, the flows rather quickly alternate one after another and we see the illusion that they are executed almost simultaneously.In our case, the priority principle will allow us to change not the threads for execution on the kernel, but parts of the code where control will be transferred. And if we make one part of the code as “random”, and the second as “experienced”, then their alternate change will be the very solution that we are looking for.In other words, the code, applying experience, will each time increase the likelihood that the next time the action will be random, and acting randomly, will increase the likelihood of applying experience at subsequent iterations of the cycle. Thus, we get the desired flow of chaos into experience and vice versa - exactly what we need.An incredible advantage of this design is that there is completely no problem with the ossification of the system, which is known, for example, in the same neural networks. On the other hand, we sacrifice stability, but we do not need it here.I wish here especially to stressthat ordinary classical programmers need code stability as manna from heaven: recognition must stably recognize, and not once every time, the server must respond with a prescribed answer to the corresponding client request from time to time, and not so that once for the same answer , and then another, etc. etc. In regular programming, code instability is a clear bug that is caught in testing. In our case, this stability is not needed from the word at all, because we do not have a clear code task. More precisely, it is not at all. But we can put it another way: we need the stability of the change of control transfer code, and we get it. It can also be said that the pendulum is stable, although it manages to get from one point to the opposite in one cycle.In order not to be unfounded, I suggest looking at the following elementary code in Python, which I sketched today, guided by all the above considerations.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
I urge you to try running this script on your own and look at how it works. This is a self-balancing code. As action 1 standsprint(random.random())
- i.e. just a random number output, and actions 2 -print(deter_numb)
- output of a determinate number. In the code, there will be actions in their place, I made the prints here just to demonstrate the principle.When the control passes to the first condition (the random part of the code), the code itself reduces the likelihood of repetition (p_random- = 0.01 - decrements itself) and at the same time increases the probability of execution of the part of the code where the experience is applied (p_deter + = 0.01 - increment of another's probability). The same thing happens when transferring control to the second condition. Thus, both of these pieces of code, when executed, themselves “slow down” and at the same time “accelerate” the other “competing” part of the code.Please note that the initial probability that control will be transferred to the random part of the code is 99%, and to the experimental one - 1%. This is to show that the system is balanced even with such radically different probabilities. When executing the code, it will be seen how this ratio will come to 50/50 in just a hundred iterations, forming a normal distribution with an explicit peak of 0.5 and a working neighborhood of about 6% (in the next 3-5 hundred iterations).When executing the code, it is clear that the probabilities come into equilibrium and settle around 0.5, balancing past this point just like a pendulum balancing in the vicinity of its lower point.One more feature is visible here: either a random number or a determinate one is displayed (69), or both of them at once, which means that the system can either apply experience and then act randomly, or vice versa, or just apply experience, or just act randomly. In other words, the execution of the code itself remains random, but we have enabled the system to apply experience, i.e. we got rid of determination when deciding on the action, which was exactly what we needed.In the next article, we will consider the formation of random actions and experience. Well, or something separately, let's see how it goes.