Thank you MUCH! MultiCharts has a brilliant platform and I want to keep using it if I can get it to work properly for the code I've written. I believe there is much promise here, both with MC and with my program. But so far ...
When in mc there will be the id tick capability we are at a good step to have a more realistick backtesting results.
Second point all data in the database chould be upload, in this case i see that only iqfeed is right for this purpose, the proble in that only 180 tick day are avaible, so we need to ask at iqfeed to give us more historical tickdata. These will be difficxult now but that will be normal in the next years have 10 years of historical data collected by id protocol.
Change the way how built strategy in your code the easiest point
buy at close of data2
sell shor at close of data1
so in backtest propriety chise data1 ask, data2=bid.
using stp and limit order to have less slippage or book pressure.
It's a really good idea to built a database from iqfeed or other feed like zenfire where collect data and start to share.
People that check the quality of data. Remember that at institutional trading form any engeneer all day works on myswl or sql database to check the integrity of data. Good data it's really important if you don't want have surprise from backtesting to real.
The following 3 users say Thank You to bomberone1 for this post:
It appears that TickID will be added to MC 7. They say "TickID – events (ticks) are processed by MultiCharts upon their arrival are now sequence-stamped with a unique number, which allows MultiCharts to track ticks in the exact order they arrived."
See here for details: MULTICHARTS 7 BETA 1 RELEASE MultiCharts Blog
But it only works for real-time data, not back-fill data. See above link. However, it may be a step towards solving Bob's problem.
The following user says Thank You to JackR for this post:
Reag again my post please, without back-fill or database costruction, no way to have realistick backtesting.
Another point to implement is the order generating.....it's really slow... http://www.youtube.com/watch?v=cH5ri_finsk&feature=related.
The point is that the engine order generating accumulate too many orders.
It's seems FIFO type mode for execution, but I don't know. In this it's easy built a long queue of order...
Last edited by bomberone1; July 9th, 2011 at 06:33 AM.
Thanks a lot Bob, this is very informative. Currently I'm testing your example code, and came across some things where I don't have a good grip on what you're trying to do.
So, if I understand that correctly, in effect this part of the code get read by EasyLanguage as follows:
Is that also what you mean with that code?
In the code there’s also:
I don’t understand what you mean with ‘in same time’, since I don’t see any time related code below that statement. Perhaps I’m focusing too much on the ‘time’ word in your comment, but I can’t see how that comment relates to the code below it.
Edit: Perhaps I've missed it in this thread, but is this a 24 hours, 5 days, strategy? The way I read the strategy (and I'm no expert, so don't take it for granted ) is the following:
Enter trades before 15:00;
Exit open positions after 15:10;
Reset variables between 15:12 and 15:59.
Shouldn't these variables be reset after a trade is closed, so the following trade can use the right values?
Btw, I'm not criticizing you (or you're strategy) Bob, nor do I want to sound as an 'smartass' (if that's the right English word for it).
Correct me if I'm wrong , but isn't this something that the data provider needs to do? For example, if the data provider only provides seconds time stamps, I assume that MultiCharts can't achieve higher precision and that MC has to assume that the data downloaded from the data feed is already in the correct order? Off course, if the data feed provides milliseconds time stamping (which MultiCharts simulates with TickID), then MC also needs to apply TickID to the downloaded data from the data feed. What's your opinion about this Bomberone1? (I'd also love to hear MultiCharts take on this, after they've released their RC off course ).
Anyway, before going further off topic, what kind of data do you use Bob, Rithmic right? I guess you've also backtested on that data?
Last edited by Jura; July 9th, 2011 at 08:31 AM.
The following user says Thank You to Jura for this post:
No problem, don't feel pressured to respond immediately. I hope I said something useful.
Btw, if you want to reset the variables after exiting a position, it might be worth trying to save the MarketPosition into a variable, so you can reference the MarketPosition value from previous bars (I don't know if you want to do that). Something like this perhaps:
Which gives the following output:
Just a thought.
--------------- Edit: I was trying to simply your 'Safeguard' code piece, and I've noticed something off.
This is your 'Safeguard' code piece from the example strategy:
Al these MarketPosition > ... statements can be nested with the other if statements, for example:
..can be rewritten as:
If you do that for the whole 'Safeguard' code section, you get the following result:
See the comments in the example above - there is one error in there, and one potential error (in my opinion), both for the long and for the short position (though I haven't highlighted it for the short code).
Note: rewritten with the assumption that with ...
Otherwise these 4 variables:
Need to be added at the very end of the rewritten code example, since they "fall" outside of MarketPosition = 1 and MarketPosition = -1 and get triggered everytime (regardless of the MarketPosition value). But in that case, they still would trigger the highlighted condition above in which the Close of Data2 would be greater than 'Max'. At least, that's how I understand it.
I hope this example is somewhat helpful in showing what your code (in my opinion!) does.
Last edited by Jura; July 9th, 2011 at 12:34 PM.
The following user says Thank You to Jura for this post:
I'm finally back. Yes, Jura, you did find a mistake and it was the one I thought you had found.
My intent was to have the following (wrong) code:
Changing that, the results for the last 20 to 22 trading days are as follows:
Before the Change:
ES (.25 Range Bars): + 40,064 Net on 324 R.T.'s; 86.1% Success Ratio; -1158 Longest Losing Streak.
CL (.02 Range Bars): + 174,817 Net on 4491 R.T.'s; 55.8% S.R.; -1920 L.L.S.
CL (40-sec. Bars): + 253,007 Net on 3025 R.T.'s; 73.1% S.R.; -4510 L.L.S.
CL (12-Tick Bars): + 31,068 Net on 3312 R.T.'s; 41.3% S.R.; -4048 L.L.S.
Keeping the mistake in, but Re-Loading MultiCharts:
ES (.25 Range Bars): + 42,058 Net on 317 R.T.'s; 86.1% Success Ratio; -1158 Longest Losing Streak.
CL (.02 Range Bars): + 181,391 Net on 4722 R.T.'s; 55.9% S.R.; -2039 L.L.S.
CL (40-sec. Bars): + 296,901 Net on 3036 R.T.'s; 80.3% S.R.; -610 L.L.S.
CL (12-Tick Bars): + 31,703 Net on 3243 R.T.'s; 41.3% S.R.; -4078 L.L.S.
Fixing the Code:
ES (.25 Range Bars): + 41,469 Net on 351 R.T.'s; 81.5% Success Ratio; -1486 Longest Losing Streak.
CL (.02 Range Bars): + 195,792 Net on 5398 R.T.'s; 55.6% S.R.; -2059 L.L.S.
CL (40-sec. Bars): + 296,853 Net on 3038 R.T.'s; 80.3% S.R.; -611 L.L.S.
CL (12-Tick Bars): + 30,876 Net on 3298 R.T.'s; 41.1% S.R.; -3798 L.L.S.
So, the repair of that error did change the results of the 4 test cases slightly.
** However, that 'Safeguard' section should not even be in the code (You also implied that). Why would it be needed if all the above rules are obeyed? And also, I should have said "If a bar has NO VOLUME", instead of 'If 2 bars have the SAME TIME'. The No Volume thing occurs frequently in Range Bars. **
No. It is supposed to begin at Midnight (Mountain time) and end at the next bar > 1410 (Mountain time). That way I'm only daytrading and can take advantage of far cheaper Margin.
I've only commented on a couple of the points you bring up. But it's late now for me and I'm going to bed. I'll answer the rest of your Q's hopefully tomorow.
Thanks for your help.
The following user says Thank You to bobbakerr for this post: