Interesting topic for many: what's new in MetaTrader 4 and MQL4 - big changes on the way - page 68
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
Yeah. Exactly.
And also about fabulous earnings. And their fabulous absence, in places where the tester shows presence (and vice versa).
In order to build something real, you need to know the limits of what is possible. So a description of a fairy tale system is also a useful thing.
Not always.
canteens) slipped, but less
But that fabulous system isn't perfect. More precisely, it's perfect only in relation to the volume that has passed the limits on ZZ tops and the condition that you're always first in line at all price levels)). What makes you think your limits will be executed there? Limit orders are queued in order of when they come in. I.e. someone sold/bought limits on the tops of the ZZ some volume, but it's not a fact that you could have done it (be first in the queue). Whether and how much you would have been poured is a mystery. It's all spherical horses in a glass)))
I understand that the real trading will always be different from the test one, in terms of execution. But the trader-programmer keeps some ideas-oriented in his head one way or another when developing his TS. "Naturally, he or she understands (if not a fool) that in reality his or her system will encounter all sorts of factors that weaken the design performance. And, if again, if not a fool, he or she must foresee which of his or her initial considerations (ideals) are vulnerable to the reality and to what degree. In particular, anticipate how stable the system can be outside the optimization range. Many systems built on poorly chosen initial assumptions ("ideals") fail exactly this test - they mercilessly leak on OutOfSample, showing excellent earnings inside the optimization range...
I didn't want to use "leftist" (from Ivan's point of view) arguments, but hrenfix's stats convincingly show that his choice of "spherical horses" is quite successful....
Not always
maybe in some markets, under some conditions, it is possible to get ahead in the queue. The point is that this ideal-fairytale system crashes against reality)
An example may be. I cannot understand a situation when it may be more profitable to open/close/correct a position using market orders. The only thing that comes to mind is the arbitrage situation - to be in time. But where is the relation between the trend and market orders?
The example is simple, you simply will not be filled with a limit on a trend market in the right place and you will be without a position. And when you go against your limit position, you will get the full price.
I understand that the real trading will always be different from the test one, in terms of execution. But when developing TS, the trader-programmer keeps some ideas and reference points in his mind one way or another. "Naturally, he or she understands (if not a fool) that in reality his or her system will encounter all sorts of factors that weaken the design performance. And, if again, if not a fool, he or she must foresee which of his or her initial considerations (ideals) are vulnerable to the reality and to what degree. In particular, anticipate how stable the system can be outside the optimization range. Many systems built on poorly chosen initial assumptions ("ideals") fail this very test - they mercilessly leak on OutOfSample, showing excellent earnings inside the optimization range...
I didn't want to use "leftist" (from Ivan's point of view) arguments, but hrenfix's statements convincingly show that his choice of "spherical horses" is quite good....
i do not know how reliable his results may be... No one knows how reliable your own past results are... All the more so if you take someone else's.
I don't understand the rest - how this fabulous system on the tops of ZZ gives you something useful? Well, as an indicator of ZZ's knees sums we can understand it, but to make any conclusions on how one should or should not trade, I don't know))
You need to trust your own past results with caution (because they do not give you any guarantees for the future), let alone someone else's, with who knows how reliable they are.
The rest I did not understand - how this fabulous system on the tops of ZZ gives you something useful? Well, as an indicator of sums of knees ZZ is understandable, but to make on its basis any conclusions about how one should or should not trade it, I do not know))
Have you ever parsed hrenfx's(getch in former life) codes? I highly recommend looking through all his works in 4th forum kodobase and carefully parsing a couple or three of them to fully understand the algorithms. And all your high-contrast brigade of "people of the highest level of professionalism" I strongly suggest doing the same. Maybe you should be less delusional about Ivan's intellectual capabilities and start improving your own skills.
You didn't show shit in numbers, you have three ticks in bars, while he has one tick in each - only LoAsk and HiBid - which he propagandized here for a very long time. So if you take out two unnecessary comparisons from loop and turn off range checks in compiler (RangeCheck), then declared figure looks quite realistic, even with useful (minimal) calculations inside loop.Some of the hrenfx codes I have actually come across - the code is very high quality, I can't say anything. I still use some of them. But don't mix flies with cutlets. You, like gerica, are writing without even understanding the test I'm offering. Either from lack of deep C knowledge, or for some other reason you are emphasizing that one bar for hrenfx is only two integer longs. In reality, we pass a pointer to the structure describing the bar; the structure itself isn't passed by value, which means that turning on and off the number of items in the bar won't affect performance in any way. Note, I'm talking about performance time of the stratum itself, I'm ignoring time of array filling.
Here's the performance result if you leave only one value in the structure itself:
I.e. indeed, the time to deploy a lightweight structure, consisting of a single long value decreased many times, from 9 seconds to 2.35, but the execution time itself remained almost the same (even slightly increased, because I started to call rand() in the if check). If the engine delegates execution to the strategist, which in reality is happening, the execution time becomes even longer and the size of structure describing bar has absolutely nothing to do with it.
So, if you're going to say something again, study C first - then we'll have something to talk about.