Multicurrency expert test results - page 5
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
What reality are you talking about? Real time testing? If so, then I agree of course. If you hang two EAs on your symbols, everything will be correct. But I am testing the multi-currency mode. And an identical result is shown only using OnTimer() (10 seconds).
I'm talking about a real run in multicurrency mode (trading on N symbols in EAs (in each EA) set to each of the symbols) - that gives a real estimate, and in the case of the tester you are primarily comparing test modes, not the correctness of each of the multicurrency tick processing methods. What is the point of comparing different modes if they are all based on the tester's artificial environment? The identity of the results of the runs is not a reason to claim that it gives the most correct results in terms of trading, it is the optimum in terms of the tester's inner workings.
Let's start with the correct wording. In the original example you would have wanted "trading in Eurodollar". In fact, custom events were coming from two symbols and in the event handler TradeSignalCounter()+TradePerformer() were called when events from any of these two symbols were received. We can assume that the event queue was always full.
Now you have removed one of the signal sources but entered the check"if(sparam == Symbol_01)" in the event handler for some reason. But the next question is different. Judging by the code, Lizar's scheme is used in "All ticks" mode and functions TradeSignalCounter()+TradePerformer() are called at every tick from the signal source (EURUSD). Interesting has already hinted on possible overflow of the event queue. But I want to know what instrument is used as Symbol_01 parameter of these two functions, and whether you've tried to change periodicity of events in Lizar's scheme.
Yes, that's what I wanted to do. After all, every action we take is triggered by our desire. In this case, I got exactly what I wanted. That is, we traded only on EURUSD, because the TradePerformer() function checks if it is allowed to trade for each symbol in the array of symbols. This option is located in external variables and at that time trading usingGBPUSD symbol was prohibited. User events came from two symbols, but in the event handler, again, the TradePerformer() function only allowed trading on the EURUSD symbol. TheTradePerformer() function also contains a function that determines whether a new bar has occurred on a particular symbol, in this case EURUSD. Your assumption that the event queue has always been full is correct, but in this case everything has been processed separately and a one tick late is not significant when testing on daily bars.
Removing one signal source, the one that should not be involved in the testing, only confirmed that everything had been done correctly before. The check"if(sparam == Symbol_01)" remained from when I checked the results without deleting the signal source on which testing should not take place, but from which it should. This check turned out to be actually even superfluous. The results did not change. EURUSD symbol is used as Symbol_01 parameter. I tried to change the frequency of events but it didn't change anything. More accurately, I can say that the all ticks mode is the most accurate.
I'm talking about a real run in multicurrency mode (trading on N symbols in EAs (in each EA) set to each of the symbols) - that gives a real estimate, and in the case of the tester you are primarily comparing test modes, not the correctness of each of the multicurrency tick processing methods. What is the point of comparing different modes if they are all based on the tester's artificial environment? The identical results of the runs do not allow us to state that it gives the most correct results from the trading point of view, it is the optimum from the point of view of the tester's internal mechanisms.
Now I understand. But the discussion was originally focused on testing in the tester. Before you start trading, you need to test the system. The more accurate the test is, the more confident you will feel in real trading. The test results presented here show that testing can be done right and wrong. Now everyone has a choice and can decide for himself what is right or wrong. A trader has rightly said (if I am not mistaken, it is Van Tharp): "We trade with our perceptions". I can add to that. We do not only trade our ideas. We even live by our perceptions. ))
If we attach an Expert Advisor separately to each symbol in real trading or testing, it will be the most accurate. Of course, I agree with that. But there is no need in bar synchronization for that. Accuracy will be accompanied by duration. You can estimate long historical periods in the tester. And I personally prefer to see the correct test results.
I also want to emphasize one more point: I never exclude the possibility that I may be wrong somewhere and I always check everything. But even after the toughest tests, when at first glance everything looks correct, I still don't rule out the possibility that there might be an error somewhere. At this point, if anyone disagrees with the assessment of the results of those test methods that are presented, you need to provide your own test results in comparison. After all, the purpose of this thread is to find out how to do the right thing or, to be more precise, how to test multicurrency Expert Advisors correctly, not who is right or wrong only in words. The facts, only the facts and nothing but the facts! )))
What is the point of comparing different modes if they are all based on an artificial tester environment?
The point is to make the right decision based on the results. And I certainly don't see any point in analyzing distorted data. After all, you reap what you sow).
Removing one signal source, the one that should not be involved in the test, only confirmed that everything had been done right before.
"...it was done right before" is from the category of complacency. It was wrong in the first place. You don't seem to attach importance to such a phenomenon as "event queue overcrowding". Particularly when it comes to post-itic transmission of events. Have a look at the reference materials and forum on the subject. The key word is "queue".
... I traded only on EURUSD because the TradePerformer() function checks if it is allowed to trade for each symbol in the symbol array. This option is located in external variables, and at that time trading onGBPUSD symbol was prohibited. User events came from two symbols, but in the event handler, again, the TradePerformer() function only allowed trading on the EURUSD symbol. The TradePerformer() function also contains a function that determines whether a new bar has occurred on a particular symbol, in this case EURUSD. Your assumption that the event queue has always been full is correct, but in this case everything has been processed separately and a one tick late is not significant when testing on daily bars.
Since TradeSignalCounter()+TradePerformer() have processed events from only one signal source, the queue state and its possible overflow didn't change at all. In other words, the "prohibition of processing events by GBRUSD symbol" did not remove the appropriate events from the queue at all. For the third time, I'm drawing attention to the problem: "A possible overflow in the queue of events was already hinted at by Interesting" :) If you believe that it is just about "one tick late", what is the basis for such conclusions?
"...In this case everything was handled separately". The problem is that in the original version, the event handler called functions when events were received from both signal sources, and then those functions already filtered out the signal from the "unnecessary" source. But the functions were called every (!) time.
A delay of one tick is not significant when tested on daily bars.
It doesn't matter on what period the event handler is tested. If Lizar's scheme generates signals tick-by-tick, then they're scoring the event queue tick-by-tick too, not once a day.
"I tried changing the periodicity of the events, but it didn't make any difference. More accurately, I can say that the all ticks mode is the most accurate." Could you please provide comparative screenshots on Lizar's non-tick modes?
If you put an EA on each symbol separately in real trading or testing, that would be the most accurate option. Of course, I agree with that. But there is no need to synchronize the bars. Accuracy will be accompanied by duration. You can estimate long historical periods in the tester. And I personally prefer to see the correct test results.
The point is to make a correct decision based on the results. But I definitely don't see the point in analyzing corrupted data. After all, you reap what you sow).
What I'm trying to point out is that the category of "correctness" has now been replaced by the identity of tester runs, but that doesn't mean that such data is less distorted. In particular, you have now chosen a 10-second interval, which is undoubtedly more distorting than, for example, a 5-second or 1-second interval. That is, you are exploiting some feature in the tester's operating conditions which gives you the preferred method with the 10-second timer. What you are really trying to do with timer events is to "catch" the arrival of the ticks of new bars on all instruments, and it is quite obvious that the best way to do this is the OnTick event.
Don't waste your time. You will never get a perfect match on ticks. Closing time of a bar is different for different instruments.
For one instrument the current time is the time of bar closing, for another bar has not yet been formed, and for the third one it has been formed several ticks ago.
Look at the tick history, the volume of ticks differs many times from instrument to instrument.
Yedelkin 2011.08.25 08:16 #
"...everything has been done right before" is from the category of complacency.
---
Good morning! ))
Apart from this separately torn out phrase, I also wrote: ".I never rule out that I'm wrong somewhere and I always check everything. But even after the toughest checks, when at first glance everything looks right, I still can't rule out the possibility that there could be a mistake somewhere". I should add that I'm not the type of person who thinks they're always right about everything. )))
---
Yedelkin:
It was originally wrong. Apparently, you do not attach importance to such a phenomenon as "event queue overcrowding". Particularly when it comes to post-itic transmission of events. Have a look at the reference materials and forum on the subject. The key word is "queue".
---
Had a look at the Timer topic. The key points I highlighted are:
1. While one event is being processed, the others may not be processed.
2. If the event stack overflows, old events are removed from the queue without being processed.
Let's take it in order. There is an enumeration of events:
When initialising, specify from which symbol we will accept the event and which event we will accept:
That is, we will accept the CHARTEVENT_TICK event only from the EURUSD symbol. There are no other symbols.
The test has started. When any event occurs, the program enters the OnChartEvent() function, declares arrays of variables for trading signals and checks for the event. If this is a custom event, the program determines the signal in TradeSignalCounter(), then it checks whether a new bar has occurred in TradePerformer() function and then decides on other conditions depending on this. The function has stopped working and will start working only when an event has occurred on the EURUSD chart. In other words, a tick in this case.
Yedelkin:
From the fact that TradeSignalCounter()+TradePerformer() handled events from only one signal source, the state of the event queue and its possible overflow did not change in any way. In other words, the "prohibition of processing events by GBRUSD symbol" didn't remove the appropriate events from the queue at all. For the third time, I'm pointing out the problem: "A possible overflow in the queue of events was already hinted at" :) If you believe that it is only about "one tick late", what is the basis for such conclusions?
---
The execution of the listed functions is very fast. No event queue overflows and no significant events are missed. And if the queue even overflows and events are missed, what will we miss? A tick, two ticks, three? So what of it? It's insignificant on the daytime bars.
---
Yedelkin:
The problem is that in the original version, the event handler called functions when events came from both signal sources, and then those functions already filtered out the signal from the "unnecessary" source. But the functions were called every (!) time.
---
Why are you clinging to this second source?)) There is no second source anymore. There is one - EURUSD, but the Expert Advisor trades from the GBPUSD chart to EURUSD. And the results are identically wrong. A copy. That is, they are the same as if the second source is present. )))
-----------
Better do the test yourself, show the test results and write down (briefly) what you did to get the correct test results, if of course you manage to do so. The simplest expert will do for this test. Entry by any condition, Stop Loss, Take Profit. Let it be the daily bars of the last 10 years. And you will see for yourself. Some periods will coincide, and some will not. Open the results chart to see where the mismatch is.
How is it that you don't need to do bar synchronisation online!
Because you wrote before that:
marketeer:
I'm talking about a real run in multicurrency mode (trading on N symbols in EAs (in each EA) set to each of the symbols) - this gives a real estimate...
From this I understand that by real run you mean an online test, when several EAs are running and each is hovering on its own symbol directly. If that's what you meant, then a question. Why do we need synchronization of bars in this case, if each Expert Advisor is located on its own symbol? Perhaps, the synchronization of bars in this case is necessary if the trading system is organized in such a way that a decision is made on several symbols at once, so bars on these several symbols must be formed. I mean to trade independently on several symbols while being on one symbol (on any symbol).
Marketeer:
All these experiments in the tester are necessary for estimating online trading, and the question of this topic is not about the tester (which emulates online), but online, and above all online bar synchronization is needed (for appropriate Expert Advisors).
For me, the tester experiments are necessary to evaluate the results of trading on the history. And my choice of online trading depends on this assessment. Therefore, the issue of this topic is the tester issue, not the online issue, which is why we need synchronization of bars in the tester too (for corresponding Expert Advisors). Some mirror images))))
Marketeer:
What I'm trying to point out is that the "correctness" category has now been replaced by the identity of tester runs, but that doesn't mean that such data is less skewed. In particular, you have now chosen a 10-second interval, which is undoubtedly more distorting than, for example, a 5-second or 1-second interval. That is, you are exploiting some feature in the tester's operating conditions which gives you the preferred method with the 10-second timer.
Yes, the smaller the interval, the more accurate the result. But, actually it is necessary, at least for me, for the last test. And for the preliminary one, I would still agree with Vladimir(MetaDriver) that the one-minute interval is enough.
Marketeer:
Actually, with timer events you try to "catch" the arrival of ticks of new bars on all symbols, and it is obvious that the best way to do it is OnTick event.
And here you can see that you didn't read the first post of the thread carefully. Not with timer events, but with OnChartEvent(). Or is it a misprint?
From this I understand that by real run you mean an online test, where several EAs are running and each one is hanging on to its own symbol directly. If that is what you mean, then a question. Why do we need synchronization of bars in this case, if each Expert Advisor is located on its own symbol? Perhaps, the synchronization of bars in this case is necessary when the trading system is designed in such a way that a decision is made based on several symbols at once, so the bars on these several symbols should be formed.
It is approximately like this.
And here you can see that you haven't read the first post of the thread carefully. Not with timer events, but with OnChartEvent(). Or is it a misprint?
Why should it be? You have OnTimer there as the third number. You've already been quoted on this subject: You just need to implement a method that will correctly perform the test. You have it. This is the OnTimer () function with a minimum interval. So you must have something else in mind.
There is one - EURUSD, but the Expert Advisor trades on EURUSD from GBPUSD chart. And the results are identically wrong.
If it's important for you, I'd still recommend to ask the developers what the analogue of fxt-file in 5 is. I already wrote that most likely different tick bases are generated for different tests.