Representation of an object in programming. - page 13

New comment
 
Aliaksandr Hryshyn #:
May I give an example?

An example will be given a little later, when the concept is set out more fully and more clearly to the reader.

 

Part 3.

To formalise the Event Model it is necessary to expand on the nature of Events. In the previous parts it was assumed that all objects consist of so-called "proto-blocks" - some specific entities with a parametric basis that are used by handler functions to reproduce the "life" of objects-systems. It was said that each "proto-block" has a parametric "body" which, like a "matryoshka", includes "bodies" of smaller proto-blocks and is itself included in bodies of larger ones. We have supposed that the proto-blocks can be arranged by level of complexity into a "hierarchy", where a Parameter is the smallest "particle", a set of Parameters is the parametrical "body" of the Object, sets of parameters "unbundled" from this body are the protoblocks of next levels of complexity, among which the first is Condition - the parametrical formation giving important "breakpoints" in the Object Being, then, on the basis of the set of related Condition is Process... Let us pause our gaze for a moment on the parametric structure of the mentioned proto-blocks in order to pass on to the Event and understand how it is formed. At this point it can be stated:

  • A State is a derived construction from the parametric set of the Object i.e. a "cast" of the selected parameters.
  • The State stores important instances of the values of its Object.
  • Structurally, parametric bodies of States are part of Processes as "lego-tools".
  • A Process is a sequence of States linked by the "life" of the Object in a chain.
  • Process contains States as "cine-film" frames and is disassembled into them.

Next, we proceed to the genesis of the Event and the disclosure of its parametric structure. We have to find out how the Event is formed, see the parametric "portrait" and its place in the proto-block hierarchy. After this, let's move on to "linking" the proto-blocks into a functional system and trace the "birth" of the Event Model. It should be immediately noted that the parametric structure of an Event has multiple variations of combinations of permanent attributes. Let's get acquainted with them:

  • Event Background - a set of parameters and their values taken from the Object or its environment (other objects in the Environment) represented as the initial State preceding or accompanying a meaningful change considered as an Event.
  • Target value- a set of values from a selected set of parameters of an Object or its environment, represented as a target State of that Object or its environment and treated as an Event.
  • Target difference- the difference sought between the past and current values of a selected set of parameters of theObject or its environment,represented as asignificant Eventin the Object or its environment.
  • Target Ratio - the ratio of the values of the selected set of parameters of the Object or its environment which is regarded asan Event.
  • Target 'signature' - the sought character of the changebetween the past and current values ofthe selected set of parameters of theObject or its environment, treated as anEvent .

We have listed the five key attributes of an Event included in its parametric body in various combinations and making up the structure. The Event, like other proto-blocks, is constructed from parametric bodies of Objects in their dynamic life and is formed by"capturing" key parameters and their values from the current moment for further calculation and recording of desired targets - background, values, difference, ratio or signature as a template in the event module (for further use in the system). When an Event is generated, derived parameters are added to its body to store the results of difference or signature calculations. I should add that you can create an Event with a dedicated handler-collector with the functionality you need to calculate targets and for parametric layout and recording. Of course, Event is more complex than State and unlike the latter has a "derived" part, i.e. it is not a direct descendant of Object(s) parameters but is supplemented with parameters for results of calculation of differences or nature of changes of initial parameters, but structurally it is the same proto-block as State or Process - i.e. a set of parameters with instances of values.

Linking proto-blocks into a System.

We now have the notion that proto-blocks are formed by special handlers-collectors in at least three methods:

  1. The method of "chipping away " from the Object's parametric body when constructinga State or Process.
  2. A method ofcapturing parameters and their values from the current moment of the Object or Environment - to fix a "background", target value or target ratio, when constructing an Event.
  3. A method of adding and calculating special derived parameters fora target difference or target change signature, also, when building an Event.

And now, let's move on to the questions"how to build a "live" System from theproto-blocks available in the concept and what role does the "Event Model" play in this?

The two key "Meta-processesof life" of any System (Object) are:

  • Independent execution of the program laid down.
  • Interaction with the Environment.

These two Meta-processes are interwoven into one, when external influences interfere with independent execution process and in response, the System changes its parameters to regain the lost equilibrium and continue with independent execution process. Overall, this dynamic is the life ofthe System in its Environment. In order to understand how the relationship between "externalaction and internal reaction" is realised, we need to add another component to the concept, Conditionality.

  • Condition is a proto-block that connects Cause and Effect with other proto-blocks of the System. Unlike parameter linkage handler discussed in the previous part, which changes values of linked parameters according to rules or formulas set inside it, Condition does NOT have formulated rules and formulas of dependence - Condition connects proto-blocks inside itself in cause-and-effect chains without formulas and algorithms. For example: some Event is placed in the "body" of Cause, and some Condition is placed in the "body" of Effect. Thus, by checking and detecting some Event, we include some State inside the Object. Without formulas and calculations. Simply, by making a direct transition from one proto-block to another.
  • A condition, like any proto-block, has a handler. In this case, the operator"if()" works best, along with"then" and"else". Note that in the body of "Cause" (which is put in"if()") there is always a comparison betweenthe pattern and the instance. If we check Event, we take its template and put it into Condition and then, the Condition handler itself collects an instance from the template parameters and compares its values to the original and chooses one of two Consequences ("then" or "else") depending on the result of comparison.
That's all for now. We now have a complete set of concepts to consider the Event Model and we'll get to that (if interested) next.


 
Реter Konow #:

Part 3.

Will the lib (library) be intuitive?

 
Реter Konow #:

Absolutely, but we are very bad at handling it and often have to put up with very low performance, against which computers easily overpower us).

We (consciousness) are only a small part of the brain's functionality, and not even a necessary one... But other aspects of higher nervous activity the brain performs well and can beat any computer... poetry, paintings, stories, science and so on, I'm not even talking about it... it's closer to a shovel than a brain in terms of intelligence...

 
transcendreamer #:

Will the (library) be intuitive?

I don't know how much experience you have in programming, so I can't imagine how much you understand what I'm writing about. For a complete humanist the concept will be little clear, but for someone with coding skills a lot is quite obvious. Try to formulate questions and I'll try to answer them).

Added: you have a lot of codes in your codebase, which means you have experience. Then, much of the concept should be clear to you.

 
Nikolay Ivanov #:

We (consciousness) are only a small part of the brain's functionality, and it is not even necessary... But other aspects of higher nervous activity the brain performs well and can beat any computer... I'm not even talking about poems, paintings, stories, science and so on, the computer has nothing to do with it... in terms of intelligence it is closer to a shovel than to the brain...

I agree.

 
Реter Konow #:

I don't know how much experience you have in programming, so I can't imagine how much you understand what I'm writing about. For a complete humanitarian, the concept will not be very clear, but for someone with coding skills a lot is quite obvious. Try to formulate questions and I'll try to answer them).

Added: you have a lot of codes in your codebase, which means you have experience. Then, a lot of the concept should be clear to you.

Well, there is a standard library in mql5, there are other libraries that bring some kind of relief for work with complex entities (sometimes, however, the opposite is the case of unnecessary complication) - so the question is: Is there a library, which would be convenient to use?

 
transcendreamer #:

Well, there is a standard library in mql5, and there are other libraries that make it easier to work with complex entities (sometimes, however, the opposite is the case) - so the question is: is there a library that would be convenient to use?

It's hard to say. I think that realization of such a non-standard approach would require to do everything by low-level programming, without using standard OOP. But perhaps I'm wrong.

 
Реter Konow #:

It's hard to say. I think implementing such a non-standard approach would require doing everything in low-level programming, without using standard OOP. But perhaps I'm wrong.

Everything is done

 
Реter Konow #:

It's hard to say. I think implementing such a non-standard approach would require doing everything in low-level programming, without using standard OOP. But maybe I'm wrong.

The main thing is that for the user it is a simplification, not a complication.

1...67891011121314151617
New comment
Reason: