Automating the search for strategies. - page 3

New comment
 
Aliaksandr Hryshyn:

There are indeed a lot of little things.

I am trying to make a universal system, so that with minimal effort it is possible to add different possibilities to analyse indicators, candlesticks, etc. Each function has information about what data it can work with and what data will be output. Indicators will also be described, what kind of data they provide. Data are divided into types, both simple and complex, for example {double} and {int,double}. They are divided into categories, for the same example "price" and "positions on the chart", another example: "straight line" (can be used to define channels), etc. They are divided by "scale type". Categorised by "scale type", for example "constant" (strategy parameter), "index" (there is a minimum and maximum), "ratio" (there is only one reference point, e.g. price, volume), etc. It is necessary to modify the strategy in a consistent way, there is such a nuance, modification in one place can affect the conditions of modification in another place.

That's right... To reduce the number of combinations of the search and used the above restrictions (type, scale, category), for now it will be enough and point changes (adding/removing one/few functions).

"recombination is also spontaneous, but of whole ready-made solutions" - this thought came to mind), it is difficult to imagine how it can be realised. A group of combined functions will most likely have more connections with the "outside world" than a single function, so there will be fewer opportunities to wedge it all in. The algorithm becomes very complicated, let's leave it till better times)).

Let me clarify the thought. To reduce the number of variants and modification in one does not affect the other blocks should be even more universal. The trick is that the same tasks can be achieved by different methods and often it is not clear in advance which one is better. For example, we have defined a certain universal task called TRANSFORMATION. There are about a dozen oscillators that each define this oversoldness in its own way. Let's assume that in the oscillator script we have set the task to try ALL indicators or all methods. Then we must standardise the interaction of these blocks with the rest of the code. Let's say we've chosen the interaction standard to be percentages of the top. The generator sequentially just inserts into the code a block-piece called Oversold1, finds the variables to be tested in this particular block, runs a volkin-forward and remembers the test results. Then he prepares a new version of the Expert Advisor, already with the block Oversold 2, which also gives out percentages, despite the fact that the original indicator shows integers, and even with a different sign from zero, etc. At the end of testing, he leaves the most successful block and moves on to another task.

At the same time, it is not necessary to prepare so many blocks to begin with, 2 or 3 blocks will be enough. The main thing is to establish interaction.

It is the same with dependencies. There are A, B, C. First, if A is greater than B, then C is true. Then if B is greater than A, and so on.

Then we can move on to more complex interactions.

 

"In order to reduce the number of options and modification in one doesn't affect the other blocks should be WAY more versatile." => "Let's say we chose the interaction standard - percentages of the top." - I get your point)). It involves bringing the indicators to a single view, i.e. preprocessing. In my system everything is too formalised, I would like to keep it all, I'm already working on implementing such things as scale, category, I've already figured out how to do it, there is really a connection of some blocks affects the connection of blocks in other places. Standardisation of indicators goes through the description of the indicator itself and depending on it, certain blocks will be automatically connected. One of the blocks can easily be the calculation of the percentage of one value from another, only these values must have a connection between them, which will be controlled, for example:

  1. Percent( Open[0] , Open[3] )
  2. Percent(Open[0], Alligator[3])
  3. Percent(Volume[0], Alligator[3])

The 1st and 3rd options are good, logical, but 3 doesn't make sense.

Indices will be calculated too, for example Open[ Max_on_position(iAC,0,30) ] ]

 
Youri Tarshecki:

At the same time, it is not necessary to prepare so many blocks to begin with, 2 or 3 blocks will be enough. The main thing is to establish interaction.

It's the same with dependencies. There are A, B, C. We check first if A is greater than B, then C is true, then if B is greater than A, and so on.

Then we can move on to more complex interactions.

It's already there.

It's implemented as follows:

  1. there are basic types int,double,bool
  2. complex types are created from basic types (you can add them), for example (int,double) - coordinate on the chart, (x,b) - coefficients of the line equation, (a,b,c,d) - support for up to 4 values.
  3. indicators are represented as a set of complex types with one element
  4. constants are represented as complex types, these are the strategy parameters that are optimised
  5. functions receive certain complex types of variables as input, their number is not limited, the output is also complex types.
  6. functions do not care where this data came from, the main thing is that there is a correspondence of types
  7. all orders that are available in mql4 are supported (6 pieces)
  8. strategy defines only one type of order (buy or sell or buy_stop or...)
  9. for non-pending orders there are 4 nodes on the top of the graph: market entry condition, exit condition, tp and sl.
  10. blocks (functions/nodes of the graph) can take input parameters from indicators, constants, other nodes, it is allowed that many other nodes can take data as input parameters from the result of one node, there are no restrictions, except for the fact that it is impossible to allow cycles in the graph.
  11. Then the graph is translated into a sequential code, and this code will be sent to the Expert Advisor for execution, nothing needs to be compiled in MQL.
Here is a sample code:

#define
 symbol          GBPUSD;
period          60;
repeat_signal_skip      True;
stop_level              60;
trade           op_buy;
max_shift               13;
stack           4;
const           9;
cache           1;
#data
{True},{-1.26761795},{4.67108999},
{2.08088665},{-0.33782435},{22},
{1.63150050},{-11},{-0.22006371};
#program
 push    [0];
push    [1];
push    [2];
call    F_plus_d;
push    [3];
push    [4];
call    F_plus_d;
push    [5];
get     .Ichimoku_2;
call    F_plus_d;
push    [6];
call    F_minus_d;
save    [0];
push    [7];
get     .Open;
call    F_plus_d;
call    F_less;
load    [0];
push    [8];
#end

Not everything is done yet, not all the necessary information is in the code, the code is executed correctly from the point of view of type control, meaningless expressions are not taken into account yet.

Only simple types are used in the code.

 

I assume that strategies can be transmitted via HTTP protocol, MQL has a possibility to receive strategies in this way.

I want to make everything fully automated, search for strategies, make portfolios of strategies, transfer to the Expert Advisor, etc.

Part of the system in MQL is 90% ready, working with a lot of strategies (position control, risks, error handling, etc.).

There is still a lot of work to be done.

 
Yuriy Asaulenko:
If you're looking for a strategy, it's not easier. I don't know about the rest, I haven't thought about it. Although, any modelling is easier in special environments, not in MT. MT is a final product, it is not created for research and is not very suitable for it
I agree, I initially modelled the idea in matlab myself. Still, the MT tester is a black box.
 
Aliaksandr Hryshyn:
Here is another example of a meaningless expression: =High>(Open-Close), it won't slip through either.

Explain why it is meaningless. Really, I would write it like this

=High>MathAbs(Open-Close)

ю

 

Aliaksandr Hryshyn:

then the graph is translated into a serial code, and this code will be sent to the Expert Advisor for execution, nothing needs to be compiled in MQL.


How, please explain?
 

It will always return true)).

(Open-Close) will always be less than (High)

 
Alexey Volchanskiy:

Explain how, please?
Which is it, broadcast or performed?
 
Aliaksandr Hryshyn:

It will always return true)).

(Open-Close) will always be less than (High)

Braking ))))))))))
123456
New comment