Representation of an object in programming. - page 17

New comment
 
transcendreamer #:

72 cases, 24 new special-purpose cases, non-linear writing system, matrix grammar, morphosyntax, boustrophedon, and special phonetics - just what the coolest trading sects need (so the Chekists and Freemasons can't steal the Grail).

Yes, we should definitely translate the phrase "crossing two moving averages" into Ifkuil)

 

Due to the fact that the topic of this topic is largely philosophical and does not fit not only into the boundaries of algotrading, but also (in some places) programming in general, I decided to complete the series of parts of the concept with one final theory of "complication algorithm", outlining its understanding and answering the question - can such an algorithm exist in principle?

As planned, we will considerthe "complication mechanism" on the example of a simple rectangular marker on the pixel screen, drawn by calling one graphical function consisting of two nested loops (height and width) and using 5 basic parameters - x, y, width, height, color.

We will call the drawing function the "constructor" and its parameter set the Object. It should be noted that, as far as most people think,an Object is a "subset" of pixels separated by colour and geometrically combined into a common pixel set of the screen, but for the programmer, an Object is not only an external form, perceived by eye, but also creating the mechanism itself. A label, as we know, is "built" in two cycles by the drawing function, which means the function with its parameters is also a "label". Not a coloured rectangle, but the algorithm with parameters which draws it. This point is difficult to realize, as the person is used to visual perception of a shell of object and considers the code which is behind it as something far-fetched and secondary, however - it is the Object itself, after all in case of any changes of implementation of initial function or values of its parameters the external change of a shell inevitably follows.

I find it easier to separate the parameter set of a function from its internal implementation and treat it as the main Object, although of course this is not true, because the internal implementation of the constructor function and its parameter set are inextricably linked. However, the internal implementation changes much less frequently and these changes are more fundamental than, say, changes in the values of the parametric set, which are easy to work with and experiment with. If the implementation method of the constructor function changes, then a new parametric set arises, and this entails changes to all the "proto-blocks" built on the basis of the old parametric set of the constructor function. I.e. if we have initially built an alternate state of the Label with 5 parameters:x, y, width, height, color with different values and then "enable" it at some event, then an unexpected change of implementation method of the function-constructor, that reduces the number of parameters, say, to 3, will change the structure of the primary parametric set (from which other states, events or processes have probably already been created) and the previous construction of the alternate state of the Label will "collapse", becoming useless for the new version of the function-constructor. Here we face the first major obstacle of implementation of the complication algorithm: The method of implementation of the function-constructor sets bounds on the complication potential of the Object. Transcending these boundaries without human involvement according to some algorithm is automated complication.

Let's consider an experimental "straightforward" complication of a Label without changing the original method of its function-constructor implementation and without going into the complication sense - we will only change the values of its parameter set and "derive" new states on its basis and see what we come to:

  • We choose a set of parameters for a new state from the initial set of the function-constructor parameters, invent new values for them and write them into the allocated block of memory.
  • Given just one additional state of a Label, we automatically encounter the need to build an Event Model, because if a Label has at least ONE other state, it must at some point switch to it, and therefore we need to describe an event associated with the environment or another object that will cause the Label to enter an alternate state. I.e., one newly added state logically requires at least one event description to switch to an alternate state, and (optionally) a second event description to switch back to the initial state or some other state.
  • Hence a simple thesis: Each new state addition to the Object entails the addition of at least one, and preferably two new events, the description of which must be placed in the conditions of the Event Model, which, as we know, is a kind of a "communication mechanism" of the Object and the Environment and describes their interaction by its logic. A priori, only the presence of SM can switch the Object between states. Conclusion:+ 1 Object State = +2 Object or Environment Events + 2 SM conditions.
  • Adding Object States entails adding Object State Change Events and it becomes necessary to prioritise the new Events, and the hierarchy structure is best suited for this. Simultaneously with the appearance of new Events and States, the condition tree grows. The behaviour of the Object is enriched by a variety of reactions to external interactions with the "involved" things in its life and it must be said that the further the complexity goes, the wider the external contact. It turns out that we cannot consider the complication of the Label in isolation from its Environment and we need the environment of interaction, otherwise the new states will become "dead weight" in memory and the only possible event of their change will be the internal timer.
  • We have found out that it makes no sense to create the new Object's states without events inseparably linking them with the objects in the environment, just as it makes no sense to add events outside the Event Model linking them with the Object's states and processes.In the process of complicating the Object, it is necessary to add everything at once - States, Events, Event Model conditions (organizing it in hierarchical order simultaneously) and to create the relationship Event->Sate or... Event->Process etc.
  • Adding an Object Process is not fundamentally different from adding a State and the only difference is the amount of memory to be allocated. The new process, as well as state, requires definition of basic events for itself, such as: start-events, switch-events, stop-events...


Conclusion:

Certainly, disclosing this topic would require more than one book and one post is obviously not enough, but it is already obvious that if we define the goal of complicating some program, so that it creates Object models with different States, Events, reactions to environment, even without changing the implementation of a constructor function and relying on a fixed parameter set, probably, it could create a label performing some simple task through nth quantity of trial and error, but such program should "be able" to build "protoblocks" - states, events, I am optimistic, although I can imagine the complexity of such a task.

 
Hello all, I have an Expert Advisor, I am testing about $100 a day on eurusd and usdchf
 
Ruslan #:
Hello all i have an expert advisor i need more details if anyone is good at it now i test about 100$ a day on eurusd and usdchf

will...

the objects in it are incorrectly represented :-)

PS/ guaranteed to fail, regardless of objects

 
Hi guys, can you please fix this ;expressions are not allowed on a global scope strategy("DailyCandleCross", shorttitle="DCC", overlay=true, calc_on_order_fills= true, calc_on_every_tick=true, default_qty_type=strategy.percent_of_equity, default_qty_value=75, pyramiding=0)
 
I want to reveal my own and other people's illusions (if I contributed to their appearance unwittingly) concerning the so-called "algorithm of complication" and return the keen readers to the harsh reality, where the universe itself denies any forms and"grail" variations and show that my reasoning is a product of a mind inflamed with love to philosophy and sleepless nights inventing "perpetuum mobile" or "time machine", suffering from the belief in its own genius.
The complication algorithm cannot be implemented, or more accurately, its "silly" version can be implemented, where some program randomly stamps parametric states, events, processes and conditions of some object, then, in the same randomness, compounds them with each other and... erases them and starts again. This strange action may last forever and it's absolutely unclear what's its aim? What is the result? A random result? And remember the problem with the constructor function? How to change its implementation? It's not clear at all... The problem is that the slightest change in implementation method completely destroys the "legitimacy" of all proto-block structures, making them unusable by the modified function. All in all, it's a task that will take years, assuming that it will be solved by Research Institute or Academy of Sciences, and not the fact that in the end something will work out.
The atmosphere of this forum is saturated with grail inspiration and casts an appropriate frame of mind, from which the latter generates amazing, science-like parables, which, unfortunately, never lead to anything practical, though... ...though it's energizing. :)
Don't judge too harshly, I was just on a "philosophical kick")))
 
Shit, is it escalating again? It's just gone quiet.
 
Реter Konow "grail" variations, and to show that my reasoning is a product of the mind inflamed with love to philosophy, that sleepless nights inventing "perpetuum mobile" or "time machine", suffering faith in own genius.
The complication algorithm cannot be implemented, or more accurately, its "silly" version can be implemented, where some program randomly stamps parametric states, events, processes and conditions of some object, then, in the same randomness, compounds them with each other and... erases them and starts again. This strange action may last forever and it's absolutely unclear what's its aim? What is the result? A random result? And remember the problem with the constructor function? How to change its implementation? It's not clear at all... The problem is that the slightest change in implementation method completely destroys the "legitimacy" of all proto-block structures, making them unusable by the modified function. All in all, it's a task that will take years, assuming that it will be solved by Research Institute or Academy of Sciences, and not the fact that in the end something will work out.
The atmosphere of this forum is saturated with grail inspiration and casts an appropriate frame of mind, from which the latter generates amazing, science-like parables, which, unfortunately, never lead to anything practical, though... ...though it's energizing. :)
Don't judge too harshly, I was just in a "philosophical punch")))

If you suddenly find yourself in a cognitive mood of mind, read about genetic programming (spoiler: you cannot do without Bacus-Naurus).

1...1011121314151617
New comment