Gathering a team to develop an IO (decision tree/forest) in relation to trend strategies - page 18

 
Aleksey Panfilov:

So the team is cancelled. )

And there will be an administered group. )

Administering even an already established team has a 95% chance of killing the result.

And to administer something that doesn't already exist, you have to have a very powerful trump card. ))

It's time to show some trumps.

Methods matter too.

There is a supply, but no expression of demand in any form.

If at this stage potential team members are not willing to be proactive, then I am not sure of their motivation.

It's very unfortunate.

Without administration you cannot move forward - I have proposed a scheme where the participants themselves choose the direction of travel, it is hard to imagine the most comfortable conditions.

 
Roffild:

Of that list, not even the repubs on GitLab registered...

The team should have been built under the Apache 2.0 license right away, and you wanted to force strangers to comply with cooperative ethics.

Well, the boss knows nothing about software development at all.

Registration is a matter of minutes, it's just a formality.

The team should work for the benefit of itself and all team members, not pick their nose at the mood.

Developing ideas and coding them are different things.

 
Aleksey Vyazmikin:

Registration is a matter of minutes; it is just a formality.

The team should work for the benefit of itself and all team members, not pick its nose when it feels like it.

Developing ideas and coding them are different things.

If it is a 'minute job', why isn't it done? There is no workspace because there is no team. There is no team because there is no workspace...

And in this area, the idea should be implemented immediately, at least in pseudo-code.

 
Roffild:

If "minute business", why isn't it done? There is no workspace because there is no team. There is no team because there is no workspace...

And in this area, the idea has to be implemented immediately, at least in pseudo-code.

The team doesn't exist because people don't want to work together; everyone (most of them) is interested in hearing the ideas of others, and the format proposed by Maxim - the chat room - is just right for that.

Maybe at the current stage of mistrust and fear of revealing their own ideas is a variant of communication of interest.

Before you do something, you need to understand what it will look like in the end - there should be a blueprint; I suggested that people express their opinions on the organisation of the work process - how they want it, how they see it, and then organise the workspace with these wishes in mind.

 

Citizens - everything is in our hands!

The market is not a place for solving personal psychological problems, but a field for generating income!

You can't move this thing on your own.

 
Aleksey Vyazmikin:

So, it's all mixed up - is the forum engine multifunctional? I've read about REST, but it's a naked architecture, should I look for forum source code for it?

What do you mean you can play other scripts, where can you play them? Imagine you want to sell the product to an ordinary user and explain in human terms what it gives and what it goes with, please. I think it's necessary and important, but I don't see why, thank you.

What's there to explain, above I showed you an example how to access from MQL script to Python installed on local computer, train neural network model, save it to a file, load it and work with it by calling Predict method.
https://www.mql5.com/ru/forum/261479/page16#comment_8011085

You can use the same pattern to create any of the hundreds of available IO models in the python libraries and train it on your data. Using the same sample you can create a client part in an EA or indicator, which will load the model file during initialization and then poll it by calling Predict method with your own, current data.

Support of NamedPipes and REST protocols allows the specified scripts, Expert Advisors or indicators to work without DLLs with the MO models, both on the local computer and remotely on the network.
Unlike NamedPipes when using REST script text from MQL should not be sent through FileWriteString, but through WebRequest to a public URL, for example on VPS where the engine is running, otherwise it is the same.

Собираю команду для развития МО (Дерева решения/леса) применительно к трендовым стратегиям
Собираю команду для развития МО (Дерева решения/леса) применительно к трендовым стратегиям
  • 2018.07.07
  • www.mql5.com
Предлагаю сплотиться для решения задачи МО применительно к трендам, т.е...
 
Ivan Negreshniy:

What's there to explain, above I showed you an example how to call from MQL script to Python installed on local computer, train neural network model, save it to a file, load it and work with it by calling Predict method.
https://www.mql5.com/ru/forum/261479/page16#comment_8011085

Using the same pattern you can create any of hundreds of available in Python libraries MO models and train it on your data. Using the same pattern you can create a client part in an Expert Advisor or indicator, which will load the model file during initialization, and then poll it by calling the Predict method with its own, current data.

Support of NamedPipes and REST protocols allows the specified scripts, Expert Advisors or indicators to work without DLLs with the MO models, both on the local computer and remotely on the network.
Unlike NamedPipes when using REST script text from MQL should not be sent through FileWriteString, but through WebRequest to a public URL, for example on VPS where the engine is running, otherwise it is the same.

In general it's clear, a tool to activate a calculated model.

But I still don't understand how to deal with strategy optimizer...

 

I will leave my thoughts on trees, in case they come in handy.

Forum on trading, automated trading systems and testing trading strategies

Machine Learning in Trading: Theory and Practice (Trading and Beyond)

Aleksey Vyazmikin, 2018.07.10 14:18

Yesterday a thought occurred to me, why do we look for decision trees, i.e. a model describing an entity? I.e. why do we need to describe the whole entity at all, maybe we should just look for the pieces of that entity that are most understandable and predictable? I thought that since I'm collecting leaves from trees, maybe I should use a method to find such leaves without constructing a complete decision tree, which should, as I understand it, give an increase in quality for the same amount of computational time spent.

I searched the Internet and do not see such method anywhere. Maybe someone knows about such developments?

While I'm working out algorithm, I think first of all I need to select predictors, which shows predictive ability of one of the classes, at that predictors must be made binary (for that I have to form my own sample for each predictor or to form exclusion margins from general sample (what is more reasonable?)). Then already use selected predictors (and their combinations) to build stubs for a particular class (in my case 3 classes), and then use these stubs to build the remaining predictors. At the same time we can also check them for preference of a certain class. Then, according to the idea, we will find the areas that are the most amenable to classification for the specific target classes. And the remaining area will be just a field of inactivity/expectation.

Of course, we can then see where leaves are layered on top of each other and make an average result in these cases. And we can build a tree like that, but with voting elements because of density in different areas of different targets.

What do you think of this idea?


 
Aleksey Vyazmikin:

I'll leave my thoughts on the trees in case they come in handy.


Many here express thoughts - ideas, some offer mechanisms - algorithms and even sometimes come to realization - ready programs, but unfortunately there is no progress, no practical results, basically all ends with flooding and unfounded declarations.

Perhaps this is because we don't have a unified presentation of trading IO tools - the format of data, models and objective assessment of results, which doesn't allow us to communicate with each other constructively, share results of experiments and make reasonable conclusions.

And what is the point in such a situation if we don't have methods of objective evaluation of even an individual performer - a developer?)

Maybe we should start by creating and agreeing on such methods; there was an attempt to raise this issue in the MoD thread, but so far there has been no mutual understanding; perhaps you, as an enthusiast of this topic, can do something?

 
Ivan Negreshniy:

Many people here express their thoughts - ideas, some offer mechanisms - algorithms and sometimes even come to the implementation - ready-made programmes, but unfortunately there is no progress, no practical results, mostly everything ends with flooding and unfounded declarations.

Perhaps this is because we don't have a unified presentation of trading IO tools - the format of data, models and objective assessment of results, which doesn't allow us to communicate with each other constructively, share results of experiments and make reasonable conclusions.

And what is the point in such a situation if we don't have methods of objective evaluation of even an individual performer - a developer?)

Maybe we should start by creating and agreeing on such methods. There was an attempt to raise this issue in the MoD thread, but so far there has been no mutual understanding; perhaps you, as an enthusiast of this topic, can do something?

I agree that standard valuations are not suitable, I have written about this before. This is especially obvious if we are talking about a trend strategy. It is better to look for optimal evaluation criteria on a basic strategy, and then port it to other strategies. As I see it, the MO branch is mainly trying to predict how the bar will close at its opening. And the guess/no-guess metric may still be appropriate there, but even there, not to mention trend strategies, points should also be taken into account in estimation.

Here in the picture below, entry points in square 1 will be much better (bring more profit) than in square 2 where there will be profit, while in square 3 we will close with loss when the asset is sold, but it will not bring profit when the asset is bought until the minimum price is formed.


So you can see that the percentage guess of entry can be large, but if this large value is more concentrated in the second square than in the first, the smaller value of errors can overlap the entire profit.

That's why I now want to take into account the concentration of signals in which area they give more profit or loss in my model estimation and take this into account when building the decision tree.

Reason: