Machine learning in trading: theory, models, practice and algo-trading - page 468
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
How many times I'm convinced, and it's all the same, the language is always quick.
I always tell my customers, there are no quick advisors, it's hard work:
1 you need to formalize the TS and create the requirements specification.
2 translate it into code understandable to the machine
3 check for errors in the execution of logic
4 check for execution errors in trading
5 to make additional changes according to the identified errors in logic and execution
6 to test it in the tester and on the real data
7 to add functions to the Expert Advisor, which it needs to work in the real trade
etc.
The programmer's function is only (2,5) to translate your terms of reference into the language of the machine and, if you find any inconsistencies in its work with your terms of reference, correct the errors; this is the end of the programmer's work, your Expert Advisor is working according to your terms of reference.
All the rest is your work on the creation, testing and improvement (upgrading) of your EA.
Best regards.
P.S. the creation of a normal profitable EA could take you up to half a year, or even more if you really need it.
What you really need is a reliable opener and closer, would it really take you half a year to do that????? Then you're no good for us...
In reality it will be a red n...)))
Sorry, Teacher))))
That's debatable... Trickster. Because there is no real data input and it is essentially the work of the polynomial coefficients themselves..... And I think the presence of input data will only improve equity. Well it's so.... IMHO!!!!
What you really need is a reliable opener and closer, would it really take you half a year to do that????? Then you are not suitable for us...
I have no doubts about the programmer's success, but I am sure he will come back.
He's been writing this nonsense for 14 years)))
Respectfully.
Idiots, everything has been done for a long time, just need a reliable opener with server error handling..... I'm hilarious.... :-)
Idiots, everything has been done long ago, we just need a reliable opener with server error handling..... I'm hilarious.... :-)
Best regards.
P.S. do not forget to specify a runtime of 2 hours, according to your work there for 5 minutes, so if the programmer will be a thumb left to write and that will have time.
If you compare the predictions in the article and these, you can see that the predicted trends coincide perfectly in both models, but in the article the model is much better at catching sharp jumps. And the arima - with price spikes as luck would have it, and those "bad luck" will cause the biggest drawdowns. Plus in the properties of the model it is clear that seasonality is not used. For now the article wins :(
It still takes a lot of Arima intuition to correctly set search limits for ar,i,ma coefficients and make the model look for seasonal parameters.
Discussing arima without analyzing the residuals on ARCH is a completely empty exercise. There are some series that have a stationary residual after an arima simulation. But discussing prediction error on the assumption that it is stationary is not serious. That residual is extremely faceted.
I also tweaked the Arima example a little bithttps://www.mql5.com/ru/forum/86386/page467#comment_5649703.
Seasonality did not work because the data period was defined as 1, and because of that auto.arima automatically disabled seasonality. I have put period 48 in the code (day on current timeframe H12), like in the article.
You may also use function findfrequency() from forecast package to determine period automatically, for this data this function returns 24.
That has turned out better, the model hits spikes in values and predicts increases in values much better.
arima train r^2: 0.516988
arima test r^2: 0.5346457
arima test diff r^2: 0.8407468
arima test diff accuracy: 0.8288288
But that's far from ideal, the predictions in the article are much more accurate. It looks like the reason is that the data has several periods prevailing (24, 48, 336 - half a day, a day, a week), while arima even with seasonality can't get into three periods at once.
I searched if it is possible to train R Arima with several seasonalities, it seems that it is not, so there is no way to make better predictions. Now I understand why the article has such difficulties, with each model the author is trying to catch different periods of fluctuations in values.
OOO And here comes our all-time favorite Trickster!!!! Got your hands full of poo???? Here's a reason for you to throw them around....
On the subject of whether Reshetova's optimizer is retrained or not. This is the screenshot I posted yesterday in one of the forex groups..... Blue shows the optimization period, green - futures contracts. But there is no possibility to submit the data and it turns out that since the beginning of the year it worked fine.... And you say overtraining, you just need to be able to train....
Now what are you going to say about retraining????
In the market any classifier is retrained because the market is not stationary. If we want not to overtrain, it is necessary to teach the NS for all history. Otherwise the market cycle will always change and the model will be corrupted. That's why the only correct approach is retraining or re-training in the process of trading :) We don't believe in hauls that will stably give 1000% monthly on a 15-year history without any intervention.
In general I still do not see the line - what overtrained NS means in forex. Is it when it doesn't make money on a test sample? nope... no no no... it's about non-stationarity. There's no point in it... it's not unsteady, it's not realistic.
I also tweaked the Arima example a little bithttps://www.mql5.com/ru/forum/86386/page467#comment_5649703.
Seasonality did not work because the data period was defined as 1, and because of that auto.arima automatically disabled seasonality. I have put period 48 in the code (day on current timeframe H12), like in the article.
Also, you can use function findfrequency() from forecast package to determine the period automatically, for this data the function returns 24.
It worked better that way, the model gets into sharp jumps in values, and predicts increases in values much better.
arima train r^2: 0.516988
arima test r^2: 0.5346457
arima test diff r^2: 0.8407468
arima test diff accuracy: 0.8288288
But that's far from ideal, the predictions in the article are much more accurate. It looks like the reason is that the data has several periods prevailing (24, 48, 336 - half a day, a day, a week), while arima even with seasonality can't get into three periods at once.
I searched if it is possible to train R Arima with several seasonalities, it seems that it is not, so there is no way to make better predictions. Now I understand why the article has such difficulties, with each model the author is trying to catch different oscillation periods of values.
Could you please post the report on fitting with parameters?