Machine learning in trading: theory, models, practice and algo-trading - page 2587

 
elibrarius #:

Today I added this predictor of the distance from the current bar. You can use the number or just the time. I took the time.

Everything is more or less clear with cyclic time. I do not understand much about linear time - will it be different for tray and forward? Or is the "current bar" taken independently for each sample?

I had an idea to just take a regular linear logistic regression and look at the significance of the difference from zero coefficient at time (or at some function of time) or compare that significance to the significance for other predictors.

 
Aleksey Nikolayev #:

Everything is more or less clear with cyclic time. It is not very clear with the linear time - will it be in different intervals for tray and forward? Or is the "current bar" taken independently for each sample?

I had an idea to just take an ordinary linear logistic regression and look at the significance of a difference from zero coefficient at time (or at some function of time) or compare this significance to the significance for other predictors.

Generally speaking the idea to feed linear time is a bad one. By the way, yes: on tray it's different in each line, and on forward we analyze only 1 line at a time, so time will always be current (which wasn't in tray), and number always = 0 (and in tray from 0 to 5000). I.e. neither time nor line number can be fed. This is what the test showed.
 
So a sine wave to the input
 

Sinusoid is for cyclic time like time of day or day of week. And there originally (in Aleksey Vyazmikin) it was about ordinary linear time, to try to catch the effect of non-stationarity in the form of disintegration of patterns. In my opinion, simple, easily interpretable models should be used to solve such problems. Complex models are for practical purposes, simple ones are for preliminary analysis.

However, there are doubts about the practical usefulness of such fiddling in this particular case. Most likely, our patterns change over time not uniformly, but cyclically (but without periodicity).

 
Aleksey Nikolayev #:

Sinusoid is for cyclic time like time of day or day of week. And there originally (in Aleksey Vyazmikin) it was about ordinary linear time, to try to catch the effect of non-stationarity in the form of disintegration of patterns. In my opinion, simple, easily interpretable models should be used to solve such problems. Complex models are for practical purposes, simple ones are for preliminary analysis.

However, there are doubts about the practical usefulness of such fiddling in this particular case. Most likely our regularities change over time not uniformly, but cyclically (but without periodicity).

It's like in fractals. They are cyclic, but not periodic. That's right.
 
elibrarius #:
In general, the idea to feed linear time is a bad one. By the way, yes: on tray it is different in each line and on forward we analyze only 1 line at a time, i.e. time will always be current (which was not in tray), and number always = 0 (and in tray from 0 to 5000). I.e. neither time nor line number can be fed. That's what the test showed.

Although I'll still try to use the number... Because zero number will be included into that part of the tree, which < some split (for example <5000) I.e. will be used part of the tree for forward. And not all of it. Something I decided to take the time for the test, by mistake.

But how to make a split by number be at the optimal distance for forward?

 

Tried it. The model with 5000 bars of history for training, after adding the line number as a feature, for Buy has improved, for Sell in some ways worse, in some ways better.
At the same time, if we teach on 10000 bars, both models become loss-making. Thus, the main objective of adding the line number for automatic determination of the necessary history length has not been reached.

So far, the only thing left to do is to manually optimize/select the history length for training.

 

Apparently, the main idea of using custom trader metrics is that they are used at the model selection stage. At the training stage, the standard metrics are used. Perhaps this is something similar to what Maxim Dmitrievsky wrote earlier on this subject.

A small article as an illustration of the approach.

The training dilemma: loss vs profit function?
The training dilemma: loss vs profit function?
  • Haris (Chariton) Chalvatzis
  • medium.com
In the world of machine learning, models are trained by minimizing some variation of a loss function. For example, when we try to predict the median house value of a specific zip code, we are dealing with a regression type problem and prime suspects for the loss function, to be used to train our model, are the Mean Squared Error (MSE), Mean...
 
Aleksey Nikolayev #:

Apparently, the main idea of using custom trader's metrics comes down to the fact that they are used at the stage of model selection.

Although, there are some ideas of using custom metrics already at the training stage. At the same time, they are not quite similar to traders' ones, but rather they are modified versions of standard ones for MO.

Perhaps, trader metrics lead to bad conditionality. This is reminiscent, for example, of using cross-entropy instead of the original error rate of interest (they say the latter is poorly sensitive).

It is necessary to somehow reduce theoretical and practical gaps between training in MO and optimization in the tester.

 
Aleksey Nikolayev #:

Although, there are ideas to use custom metrics already at the training stage. However, they are not exactly like traders' metrics, but rather tweaked variants of standard ones for MO.

Perhaps, trader metrics lead to bad conditionality. It reminds us, for example, of using cross-entropy instead of the original error frequency of interest(they say about poor sensitivity of the latter).

Trust, but verify.
Aleksey Nikolayev #:
It is necessary to somehow reduce theoretical and practical gaps between training in MO and optimization in the tester.

When I was making models with TP/SL the accuracy was absolute. In the model and in the tester trades were opened on the same bars and closed with the same TP/SL. Only the profitability was about 0.
I tested it on open prices. But there is a problem with them... The minimum spread is used in the bar.

So part of the orders and TP/SL in the tester will trigger at

ASK HIGH = BID HIGH + minimum spread.

Those that would be triggered in real trading will not work

ASK HIGH (real) = BID HIGH + Spread calculated by the maximum ASK

I've suggested the developers a couple of times to save in bars not the minimum spread, but the

Spread = ASK HIGH - BID HIGH.

With such a spread, testing by open prices would be closer to testing by real ticks.

For example, min spread on a bar = 0.00002, and Spread = ASK HIGH - BID HIGH = 0.00020. I.e. in reality the ASK price was higher than the tester one by 0.00018. Where the trade openings/closings could have occurred.

But there is no reaction from MetaQuotes (in Russian).

PS: To be more accurate, you also need a spread to calculate the Low Ask.