Machine learning in trading: theory, models, practice and algo-trading - page 2654
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
Have you made a tester on rcpp by any chance? I need it very much
No. I try to do without ticks and bars in R - only zigzag tops, and testing by them usually lies.
No. I try to do without ticks and bars in R - only zigzag tops, and testing on them usually lies.
Why does it lie?
The tops "look" into the future - at the moment of its tick arrival it is still unknown that it will be a top.
Information about gaps and spread widening between tops is missing (you cannot enter-exit at any price between tops).
But for initial rough analysis, where there are a lot of nested cycles, zigzag tops are more or less suitable. But it is better to test something similar to the TS in MT.
Apexes "look" into the future - at the moment its tick arrives, it is not yet known that it will be an apex.
Information about gaps and spread widening between tops is missing (you cannot enter-exit at any price between tops).
But for initial rough analysis, where there are a lot of nested cycles, zigzag tops are more or less suitable. And it is better to test something similar to TC in MT.
Apexes "look" into the future - at the moment its tick arrives, it is not yet known that it will be an apex.
Information about gaps and spread widening between tops is missing (you cannot enter-exit at any price between tops).
But for initial rough analysis, where there are a lot of nested cycles, zigzag tops are more or less suitable. But it is better to test something similar to the TS in MT.
I kind of remade it from this one. https://www.mql5.com/ru/code/15970
Although you can remake any of them.
Rewrite ZZ so that it does not look into the future. I.e. so that at each moment of time in the history, the values are saved as at 0 bar in real life. For example, the last extremum is lower, and the price is slightly higher. Keep the delta from the price to the extremum. And so on for each bar. After a few bars, either the previous extremum/knee will increase or a new one will be created.
I've remade some of these. https://www.mql5.com/ru/code/15970
Although you can remake any of them.
I purposefully sacrifice accuracy in favour of speed. When only vertices (price and time) are stored, the history is very compact - several tens or hundreds of thousands of records for the whole history of the tool. This helps a lot, because the initial verification of an idea is often reduced to searching the history in cycles (often highly nested).
is often reduced to poring over history in loops (often heavily nested).
It's surprising to hear that.
I purposefully sacrifice accuracy in favour of speed. When only vertices (price and time) are stored, the history is very compact - a few tens or hundreds of thousands of records for the entire history of the tool. This helps a lot, because the initial verification of an idea is often reduced to searching the history in cycles (often highly nested).
and vertex times in minutes or seconds (milliseconds are better)?
I'm surprised to hear that.
A cycle by history, in which a cycle by pattern length, etc. is nested - a cycle by pattern type or by breakpoints, for example. If something seems to be there, then a more detailed study.
Artifacts of the history of quotes are found very well)