A question for OOP experts. - page 54

 
Реter Konow:

In that case, I have "planted" new prisms on the Object for you. Object-state is not described by a class, but has a physical entity in memory. A class is a description of an Object. There can be different things there. It is rather a complex of Objects. But the Object itself is a named entity.

A molecule is an object. The universe is an object. Both consist of a set of objects. Therefore, a class is a description of an object.
You yourself have started to produce unnecessary entities :)
 
Artyom Trishkin:
...
I am not a philosopher. It's hard for me to grasp your perceptions. For me, everything is much simpler.

It's okay, it's evolving.

Just look at the chain of Events. It's an assembly of important system parameters, and in them are values of significance to the system.

The state chain is identical. Only there, the frozen values whose immutability is SIGNIFICANT to the system.

And of course, the Event has a handler. An Object must have a handler. You are absolutely right about that.

 
Artyom Trishkin:
A molecule is an object. The universe is an object. Both consist of a set of objects. Therefore, a class is a description of an object.

A parameter, is a discrete phenomenon of a predefined sample of values. It is also an Object.

The value selection is stored in the Object-Parameter properties as a range or set of variants. Its value type and handler are also stored there.

 
Реter Konow:

An entity is not necessarily indivisible. It can be made up of other entities, and be a single Object. For example - an Object-system. It has many entities and each entity is an Object.

Another interesting thing is that structurally an Object-State is similar to an Object-Event.

What is a state? It is a set of meaningful parameters of a system in a fixed meaningful invariance. THE MEANINGFUL INVARIANCE OF THE SYSTEM'S PARAMETERS IS A STATE. And an Event is a meaningful change in the parameters of the system. They are structurally similar.

1. Condition - alive.
2. An event is a brick of a head.
3. State - dead body.
 
Artyom Trishkin:
1. Condition - alive.
2. The event is a head brick.
3. Condition - dead body.
It happens...)
 
Реter Konow:

That's okay, it's evolving.

Just look at the Events chain. It contains an assembly of important system parameters, and in them are the values that are significant to the system.

The state chain is identical. Only there, the frozen values whose immutability is SIGNIFICANT to the system.

And of course, the Event has a handler. An Object must have a handler. You are absolutely right about that.

An object must have a neuron - a way of transmitting its parameters to the external environment. But there does not have to be a parameter change handler. It can be in another object.
 

By the way, why do you think an object-parameter needs a handler? To preserve its conceptual integrity and purpose.

Let me explain: a parameter is connected to the world in two ways:

1. accepts the value.

2. Passes the value on.

The handler ensures that the parameter performs its function according to its intended purpose, as specified in the properties. The handler stores the value within a predefined selection and thus protects the system.

 
Artyom Trishkin:
An object must have a neuron - a way to pass its parameters to the external environment. But the parameter change handler need not be. It can be in another object.

The parameter object is connected by two actuators to the system. By the first it receives a value from outside, by the second it transmits. The properties of the parameter are stored in the parameter chain, and the handler can indeed be located externally. But it must be referenced in the object-parameter chain.

 

No system can be seen in and of itself, for each is inextricably linked to the 'Environment'.

A System, is an isolated set of interacting parameters, conceptually isolated by the Mind's view from the Environment and placed in the Object. By looking at an alienated group of parameters as an independent System, one can see the maintenance of effective symbiosis with its environment.

The Environment has 3 states:

1. Chaos, - Parameters 'seek and strive' to form a system (as in the proto-universe), while being in disharmony with each other.

2. Order - a set of parameters organised into a System and separated from chaos. This implies changing the surrounding chaos by the System and subjecting it to its order. The System "imposes" its order on the chaos, expanding within it

by self-copying and "winning".

3. eco-system - a complex of Systems which have achieved effective symbiosis and which maintain their integrity by showing resistance to external changes.


The market, an external environment.

Advisor is a system trying to reach an efficient symbiosis with the Market. The effectiveness of the symbiosis is possible in the search of the regularities in the chaos that is what the advisor hopes for.

Expert Advisor seeks to "connect" to the market patterns by optimizing its parameters and changing the tactics of action. He "expects" to take a part of market resources, building a model of behavior, but in the vast majority of cases, his own resources turn out to be at the Market, and the model of behavior is broken. This is not surprising, taking into account that behavior model is built on generalized derived parameters of vast Medium, in which there are many other systems with their own behavior models.



The market as an Environment,

  1. is either completely chaotic, and it is impossible to find a key to it. (if it is based on a random number generator).
  2. or it is a complex system that generalizes the behavioral patterns of advisors and redistributes its resources between them.
  3. or - a system "feeding" resources of advisors and imitating redistribution.

Consider the popular 95/5 statistic. Where it comes from and what stages of the Market we have passed.

  1. Stage zero - the Market is chaotic and forming. The statistics of sudden enrichment and total loss of resources shows the instability and immaturity of the concept of market trading. Rules are uncertain and patterns of behaviour are often "animalistic".
  2. First stage - The market begins to generalise the behavioural patterns of systems and reallocate their resources. Given the desire for resonance - the redistribution was in the region of 70/30% or even 60/40%. Systems have quickly found patterns of behaviour that unify them with other systems and cause powerful market movements in a common direction. After all, it is much easier to create a simple consolidation model than a complex and contradictory algorithm. And consolidation is about pooling resources and 'pushing' the Market to get a return from the opposing, unconsolidated party. This stage has been passed in the last century.
  3. The second stage is the Market, spontaneously but legitimately "generates" huge concentrations of resources from certain systems, and they develop specific patterns of behaviour and draw resources regardless of what patterns others choose. Because of the huge number of counterparties these systems have, their market visibility and ability to move it is orders of magnitude greater. As a consequence of their interest, they inevitably exhaust the resources of the others. This is the current stage of the Market.
  4. The third stage is that the Systems that control huge concentrations of resources in the Market mindlessly absorb the resources of all the small systems, breaking them down time after time, narrowing their behaviour patterns, and eventually, they stop seeking resources in the Market for self-preservation. This is the last stage of the Market.
P.S. The question is "what's next...?".


P.S.S.

The Magic Grail is an ideal model of system behaviour that draws resources from all other systems, leaving them always at a loss. An abstraction born of fantasy.

Документация по MQL5: Математические функции / MathSrand
Документация по MQL5: Математические функции / MathSrand
  • www.mql5.com
Функция MathRand() предназначена для генерации последовательности псевдослучайных чисел. Вызов MathSrand() с определенным инициализирующим числом позволяет получать всегда одну и ту же последовательность псевдослучайных чисел. Для гарантированного получения неповторяющейся последовательности используйте вызов MathSrand(GetTickCount()), так как...
 

In OOP, multiple objects, bounded by an iron class, can have a different number of properties.

A single object can have a different number of properties as the program is running.

Relationships between objects can be established and broken.

In OOP, memory is allocated to objects as needed, and released when the object is no longer needed.


Your array is always fixed. If there are fewer objects than specified in the array, the memory for the missing objects is wasted. And there simply can't be more of them.

You are somehow ignoring this question, although it's the first thing you should have taken care of.