I wanted to test the MMDI as a follow-up to Moving Median: a better indicator than Moving Average?. This also provided a good opportunity to test Trading Blox (which I am thinking of buying).

MMDI: What is it?

In short, this is an indicator very similar to the MACD, except that the short moving average of the MACD is replaced by a moving median.

Portfolio Filter: Trade with the trend

One concept often used to improve the edge of a trading system is to look at 2 or more timeframes. The main timeframe (shorter one) is used for triggering trading signals (eg Donchian Channel breakouts), and the longer timeframe is used to determine the direction of the main trend. The filter rules prevent any trade signal to be taken if it goes against the main trend.

Trading Blox: a componentized testing framework

A great feature of Trading Blox is that it provides you with a skeleton workflow that forms the framework for the backtesting process. What this means is that Trading Blox implements and runs its logical workflow in the simulation loop (ie read data, update indicators, check entry signals, check exit signals, post-simulation scripts, etc.) but provides you with hooks at every step (about 35 hooks per simulation loop) where you can write your own code for customisation (with access to Trading Blox internal objects).

Next is the concept of blocks, which represent the different components of a trading systems (Entry signals, Money Management, Risk Management, Portfolio Filter, etc.). These blocks are easily reusable in any system and implement the functionality required via the code contained in their scripts.

One such block we are interested in for today is the MACD Portfolio Filter:

MACD Portfolio Filter Blox

This block stops the system from opening new trades in the opposite direction to the trend (the direction of the trend is derived from the MACD value).

MMDI Portfolio Filter

It was easy to use the standard Donchian channel system that ships with Trading Blox and replace its MACD Portfolio filter block by an implementation of the MMDI Portfolio filter. All it took was a copy of that block and an update of some of the scripts to implement the MMDI indicator and the filtering based on its value.

Indicator calculation:

mmdiIndicator=Median(ohlcDiv4,mmdiShort)-emaIndicator

Filtering code (long side):

[...]
' If positive, then allow long trades
IF ( mmdiIndicator > 0 ) THEN
	instrument.AllowLongTrades
ENDIF
[...]

And applying the new block (MMDI Portfolio Filter) to the system in the system editor screen:

System Editor

Test Scenario

The test is a comparison of the standard Donchian Channel breakout Tend Following system with MACD Portfolio Filter against its variation using the MMDI Portfolio Filter.

In order to get more data points (and to test Trading Blox parameter stepping), the comparison was run over a combination of system parameters:
- Long MMDI Moving Average: 200, 250 and 300
- Short MMDI Moving Median: 50, 62 and 74
- Donchian Channel Length (Entry): 20, 30 and 40
- Donchian Channel Length (Exit): 15
- Stop level: 2 x ATR(40)
- Slippage: 15% of ATR (+3% at rollover)
- Commissions: $12.50 per contract
- Dates: 01/01/2001 to 09/30/2010
- Instruments: 28 liquid futures (currencies, commodities, financials)

Test Results

Here are the two results tables produced by Trading Blox, showing a few stats for each system tested:

MACD Portfolio Filter Results - click to expand

MMDI Portfolio Filter results - click to expand

Looking at the CAGR and Sharpe ratio on aggregate, here is the how the systems compare:

Conclusions

First on Trading Blox: it was fairly straight-forward to code up this new indicator and system. The stepped parameter tests were also really quick to run (<1 min). Still pretty pleased and feeling at ease with it.

The test results show a small improvement in the MMDI favour. A possible explanation might be that the more volatile nature of the moving median (as illustrated in the moving median indicator post) allows it to pick up changes in trend faster (and get in them at an earlier, better price).

The whipsawing produced in the Moving Median crossover run would normally take place during range-bound markets, where few Donchain breakouts would happen, therefore cancelling the extra noise and losses associated with them.

Might be worth investigating further…
 
 
PS: David’s code for MMDI on TradeStation is available for free on his dvindicators.com website

PS2: As a comparison, and to illustrate the impact of a portfolio filter, here are the results for the same system without any Portfolio Filter:

Only 3 sets of results as the MACD/MMDI stepped parameters have been removed - click to expand

Without the trend filter applied to the portfolio, the Donchian channel breakout system now exhibits a negative performance (-2.68% on average across the 3 backtests). The trend is definitely your friend!

Regular readers might think that I suffer from backtesting-software-indecision-itis. Having first settled for TradersStudio, I then evaluated (and purchased) AmiBroker and found that it was 25 times faster than TradersStudio (at least for the calculation of the e-ratio). However, AmiBroker is not really geared towards true portfolio allocation testing with Futures and could not just replace TradersStudio – so I purchased it as a (cheap: $199) complement to it.

Why TradersStudio in the first place?

During my first round of evaluation, I did hesitate between TradersStudio and Trading Blox. At the time, it appeared that there was not a huge difference in functionality but a substantial price difference ($499 for TradersStudio, $3,000 for the full version of Trading Blox Builder). And this is how the choice was made.

However, I never really got past my TraderStudio’s first (not so good) impressions. Ultimately, I find the platform awkward to work with, documentation rather poor and the user community is very small.

So I decided to give Trading Blox another go and test their latest trial version (v3.3), and give you a teaser review of it.

Trading Blox: friendly, efficient, fast, professional

Trading Blox is vastly superior in terms of user interface “friendliness” and efficiency (love that script management/edit screen!). This makes the documentation lookup less necessary (and in any case, it is rather better).

The simulation runs are also very fast (300 stepped parameter tests under 7 minutes) and the software comes pre-packed with about a dozen ready-coded systems including the famous Turtle Trading system.

Finally, the numerous backtest options (slippage, commission, rollover slippage, volume, interest, etc.) should simulate trading reality much more closely.

Overall, it feels that the difference between Trading Blox and TradersStudio can be summed up by Pro vs. Amateur: both good at what they do, but playing in different leagues.

User community

Trading Blox forum is very good, with top-notch contributors. I joined it a few months ago and the discussion there is top-level, be it on all aspects of trading in general, backtesting, Data problems, Trading Blox questions, etc. It also has a marketplace where users can exchange code/systems, etc. This forum played a big part in my decision to re-consider Trading Blox (TradersStudio’s own forum and yahoo user group are barely ticking…).

In closing: screenshots

I feel I am about to give in and “cut my losses short” with TradersStudio and redeploy my resources towards Trading Blox. In the end, it is a “time vs dollar trade” and I feel that the initial outlay will give a great payback (in time savings and progress made). After all, automated trading is a business and one should not shy away from the essential investments.

Tomorrow, I should post a detailed system test using Trading Blox; but for now please find below some screenshots of the software (click to zoom in):

Result Reports

rich choice in general options

System Editor

Blox Editor

Heat map for stepped parameter

I wanted to start this year with an idea I left off last year, when investigating robustness: Using the median as a more robust tool than the ubiquitous mean (or average). This will be covered in the next post via a TradersStudio simulation results. To do that, I had to re-import some data from CSI Unfair Advantage to TradersStudio. I thought a “how-to” post on this would be useful – if only as an aide-memoire for next time (note-taking and documentation are important after all…)

Extract CSI Data

The first step is to extract the data from the CSI database into text files
(by the way, CSI have a 20% discount running until the end of January – just check their homepage).
This can be done with code using the Unfair Advantage API.

Pick all the instruments to be extracted and create a “contracts.param” file containing the CSI number for those instruments in the first column (comma-separated file with other columns being ignored). The CSI numbers can be found on their website (like here for the CME Futures) or in their Unfair Advantage software UI. Running the EXE code will generate one file for each instrument (proportionally back-adjusted contract) in the following format:

19900403,199006,0,240,110,918,503,2,0,1.59,1.655,1.58,1.635,1.635,1.635,1.635
19900404,199006,0,84,127,656,721,3,0,1.6,1.65,1.599,1.62,1.62,1.62,1.62
19900405,199006,0,57,112,554,885,4,0,1.615,1.635,1.61,1.615,1.615,1.615,1.615
19900406,199006,0,62,136,436,1092,5,0,1.615,1.635,1.61,1.625,1.625,1.625,1.625

Load in TradersStudio

The second step is to load the files in TradersStudio. Copy all generated text files in a dedicated data directory (you might have to rename them as TradersStudio allowed filename length is fairly short, i.e. 10-15 characters).
Create the relevant mapping file (txtinfo.txt) in the data directory. The mapping file should read:

delimit=,
skip=0
dt=1
ti=0
op=10
hi=11
lo=12
cl=13
vol=6
oi=7
dtformat=CCYYMMDD
tiformat=

In TradersStudio, menu Data Manager/Add Data Links, point to the relevant data directory with the following options:

If all goes well, this will load the data in the system (errors I encountered were due to file names being too long).

Data Universe: Contract meta-data

The third step is to populate the meta-data (margin, min tick move, etc.) for each instrument in TradersStudio. This is done via the menu Data Manager/Data Universe.

Once done, the instruments can be used just by adding them to any session.

As mentioned earlier the next post will be a test comparing moving average and moving median indicators.

Note: You can receive a 10% discount on CSI data subscriptions (use coupon code LIBERTY)

Software and manuals

You can download a fully-functioning Amibroker demo (you cannot with TraderStudio and even when you buy it you have to wait for CDs by post!) which contains some limitations (i.e no more than 5 markets back-tested at a time, etc.).
The manuals are all online and very thorough, complemented with additional articles, presentations and other materials. This makes it very handy (again compared to TradersStudio printed 300 page manual – yet incomplete) as you can search them electronically to look for exactly what you need.

Large Community

The Amibroker community seems much wider and as a result there is loads of available scripts for re-use. There is actually a whole library hosted on amibroker website.
There is also much, much more information available on the internet. As a sample test I googled “Amibroker Donchian” vs. “TradersStudio Donchian”: 23,200 results vs. 17 (including this blog!).
Finally the yahoo group is much more active. There are about 10 times more daily messages (although the TradersStudio one can go days without getting a single message). As an example I posted a question related to the custom backtester and got a useful answer the next day.

The platform

It takes a bit of time to get used to the concept and principles of Amibroker. It is quite different from TradersStudio. For example, all afl files are self-contained and might implement indicator, system, back-test procedure, scan and exploration code all at once (although only one part really runs at once – alightly confusing at first). In TradersStudio you can also define functions to be called in other code files; this does not appear possible in Amibroker (you would have to copy/paste the code over and over again). Both platforms allow you to build COM dlls to code up your functions.

The GUI is different but I would not say better or worse than TradersStudio.The charting forms a more central part of the Amibroker platform and just firing up a chart with several indicators is pretty quick. At first glance the money management/portfolio allocation does not appear very rich in Amibroker (in terms of functionality) but I would have to do more testing to confirm this.

AmiBroker screenshot

The language to create your own indicators, systems, etc. (AFL: Amibroker Formula Language) is based on C and not very hard to pick up especially with the very useful in-line help – it does help to read the tutorials first (!) to get a grasp of the main keywords/built-in functions.

Data loading

Loading the data extracted from CSI Unfair Advantage was fairly straight-forward and there seems to be a bunch of ready-made interfaces with other data vendors in addition to the Amiquote utility – which allows you import quotes in Amibroker. It seems that there is more flexibility in the type of data fields that can be loaded.

Conclusion

Overall I was pretty pleased at what I was able to achieve in a short amount of time. For some reason I found it very hard to get into TradersStudio whereas Amibroker was easier to tackle (once you understand its working concept).
Obviously I have not explored all the functionalities of either software and this is definitely not an exhaustive review. As a result of all this I will be buying a copy of Amibroker to complement (or replace?) TradersStudio. I am sure both platforms each have their pros and cons so having both is probably a good idea (and not a very costly one since Amibroker costs only $200!).

In the last few posts I have been exploring the e-ratio and wrote the code in TradersStudio. I also tried to implement it in AmiBroker AFL language mostly to check how it performed speed-wise – as I found TradersStudio quite slow.

While testing AmiBorker, it actually felt so fast that I decided to perform a more formal speed comparison test.

Conditions of the test

I exported the CSI data via the API for a proportionally back-adjusted Corn contract going back to 1949. The data was imported in both AmiBroker and TradersStudio via their ASCII Import.

The system tested is a simple 20-day Donchian Channel Breakout (Buy-only) and the ATR used to normalise the MAE/MFE is 20-day also.
The optimiser in both systems were used to generate the e-ratio for 50 51 different trade durations (from 10 to 50 days).

One of the condition to validate the results of the test was that the trades generated by both systems are similar (to double-check I did not make a coding mistake resulting in simpler/faster process for one of the platforms).

The computer I was running the test on is a quad-core CPU (2.4 GHz) with 3.25 GB of addressable RAM. Only one platform was running at the time it was tested.

Results are in!

And they look astoninglishly good for AmiBroker:

• The TradersStudio test was run first and took 4 mins 15 sec to complete and produce the custom report (which needs to be manipulated in Excel to calculate the e-ratio). Furthermore, it appeared that every incremental run in the optimisation process took slightly longer than the previous one.
• The AmiBroker test ran in (…drumrolls…) 10 sec! And the e-ratio was readily available from the results grid:
  
  

  AmiBroker optimisation results showing the e-ratio. Click to expand

Both apps maxed out their allocated CPU (i.e. overall CPU usage of 25% = a quarter of the quad-core CPU available).

I then decided to run the AmiBroker code over 5 markets to get a feel of how long it would take. I added Crude Oil (going back to 1985), Cotton (1968), Gold (1975) and Yen (1972).
AmiBroker ran the same code + optimisation in 2 mins 20 sec, twice as fast as one market in TradersStudio!

Applying a simple proportional calculation to derive the time it would take in TradersStudio for the same dataset would give us a completion time of 1 hour (59 min 30 sec exactly…). Since the performance seems to degrade over the course of the optimisation in TradersStudio (i.e. the first back-test is quicker than the last one of the optimisation run) we could assume that it would actually take longer, which is what I experienced when I was testing on similar data in the last few weeks.

So here you have it: AmiBroker is 25 times faster than TradersStudio and it gives you the results in a much more friendly format.

Trade Reconciliation

As mentioned earlier, to ensure that the test was valid, the set of trades generated by both systems should be compared. I ran one back-test of the system over the Corn data for a single optimisation step (e-ratio for 20 days duration) in both systems.

I could find that 296 trades out of 340 presented a very good match (some matches had one day difference on the Entry date and rounding differences on the prices). But overall the trade comparison was good enough to give assurance that the same systems and results were being tested.

I’ll keep investigating for myself where these errors are coming from (and post a further code update if warranted) but we can assume that the differences are trivial with regards to performance comparison.

Did I mention that AmiBroker is 3 times as cheap with a much wider following (many more code samples, better docs, more forums, etc.)?…

Getting started with the API

Fire up your favourite IDE/language that supports COM Interoperability (I am using Visual C# 2008 Express Edition), start Console Application project and add a reference to the Unfair Advantage API. For this you just need to “Add reference” and browse to the Unfair Advantage installation folder and select the main EXE (uad.exe). This gives access to the CSI UA API.

Add UA into your project and "Bob's your Uncle!"

Simple extraction code

The rest is fairly simple as long as you understand the RetrieveBackAdjustedContract2 parameters.
The code below takes 2 parameters: an input file name containing the list of markets to extract and a folder name to extract each continuous contract to. It sets specific UA session parameters and calls the RetrieveBackAdjustedContract2 with specific variables to obtain the concatenation desired. Each continuous contract is output to a folder in a .txt file.
The file containing the list of markets is of the following format (CSI number, Symbol, Market name):
…
8,CT,Cotton
…

The code

Please find the code there (very nicely formatted thanks to this great tool by manoli). You can also download the Program.cs file:

Note: You can receive a 10% discount on CSI data subscriptions (use coupon code LIBERTY)

Continuous contracts allow you to chart Futures contract prices in one long time-series (here Copper ranging from 1965 to 2009)

Let’s look at the different possibilities:

Non-adjusted contracts

Take the front-month contract (nearest expiration date) and roll it over into the next one at expiration date. This generates a series of actual traded prices. But as we discussed in our previous post, it does have negative impacts when used for back-testing because of the potential big gaps at roll-over times.

Standard Back-Adjusted contracts

A solution to this “big gap” problem is to move each contract up or down by a certain amount (the gap value) so that the rollover junction is continuous. This is point-based adjustment and is usualy performed “backwards”. You would start from the current contract, move the previous contract by a set amount, then subsequently move each of the anterior contracts to eliminate each gap you come across until the first contract of the timeseries.

Proportionally Back-Adjusted contracts

But as we saw in the last post, this point-based adjustment is not ideal either, as it loses the relative price differences and can even make past prices become negative. This is where ratio-based adjustment comes to the rescue.
By applying a relative or proportional adjustment for each contract you will be able to maintain the historical price ratios and rid remove the gaps. This is equivalent to stock split adjustments in the Equities world. This is also done backwards – starting from the most recent contract going back, one by one, to the first contract in the series.
Again, please check the last post for more details on the issues discussed above.

Forward-Adjusted contracts

Both point-based adjustment and ratio-based adjustment are usually worked out backwards – this allows to keep reference of the real/actual traded price in the current contract. However the same logic can be applied forward (start from the first contract and adjust your way up to the last contract). This will result in different contract values to back-adjusted contracts (but ratios would stay identical in case of proportional adjustments).

Nth Nearest contracts

This is a slight variation to all cases discussed above. Instead of always considering the nearest contract (ie front-month), you can decide to look at the nth nearest contract instead. For example, in Copper, the 3rd nearest contract is currently March 2010: HGH10. Once the current front-month contract expires (October 2009: HGV09), you would roll into the next available 3rd nearest contract which is May 2010: HGK10.
This process should insulate you from possible more volatile price changes in the front-month contract around expiration time.

Gann contract

Gann contracts use a specific contract month and roll over only to the same contract in the next year. A March Gann contract, for example, consists of the nearest March contract for each day.

Perpetual Contracts™

This is an algorithm trademarked by CSI. To avoid the “gap” problem around rollover time, CSI have decided to smooth the transition phase out. The shift from one contract to the next one(s) spreads over time. The algorithm uses a time-weighted average of different expiration date contracts to gradually shift from the front-month to the further month as expiration date approaches. You can find more details in the UA manual.

Other parameters: when to roll-over?

You can roll-over right at expiration time. However this does not reflect actual trading activity, where physical roll-over (ie money flowing from one contract to the next) takes place earlier.
You can decide to always roll-over n days before expiration but you can also decide to track actual market activity to trigger the roll-over. You would observe Open interest or Volume and roll-over when one of them shifts from one contract to another. This is a much more realistic approach.

Here is a screenshot of the settings I have used in Unfair Advantage to extract and concatenate the data, it is proportionally forward-adjusted with a roll-over triggered by a 2 consecutive shifts in Open Interest, but less than 5 days prior to expiration:

Unfair Advantage settings to generate a Proportionally Forward-Adjusted Contract

To be continued…

There are many more options which will all be addressed in a further post detailing how to use the Unfair Advantage API to extract data directly from your own code (Exciting!).

Note: You can receive a 10% discount on CSI data subscriptions (use coupon code LIBERTY)

No long-term continuity

Futures are specific in the way they trade in series of short-lived contracts that are only active for a few months (the most active contract for Silver at the moment is SIZ09 i.e. Dec 09 Silver 5,000 oz – see this post for Futures Symbology. Around mid-December most activity will roll-over to the March contract SIH10).
This is different to stocks which offer a continuous stream of prices (generally since start of trading). In order to back-test a system on historical futures data, you need to “stitch” the futures contract prices to generate a similar continuous stream of prices.

The $64,000 Question: How do you stitch the data?

Easy, you might say: just chain all the contracts one after the other. But there are always multiple contracts trading concurrently with different expiration dates (for Silver currently December 09, March 10, May 10, etc.). One accepted rule (in testing, but also in trading) is to always consider the front-month contract (nearest expiration date contract) and roll the price series into the next front-month contract around expiration time. That selection process determines the actual contract to consider for any given date. Now, it is “just” a matter of stitching them up together.

But…

As you might know, contango, backwardation and other factors (crop seasons, etc.) generate a difference in the price of different expiration date contracts. In effect, when comes the time to move from one contract to the next, there will most likely be a gap between the old contract price and the new contract price. These gaps can be substantial and make your data appear disjointed.

Cocoa March 2005 (yellow) and June 2005 (Green) contracts - a big price gap exists at the time of transition between the 2 contracts

The distorting “Panama canal” method

One of the workarounds (described by Ed Seykota in his Panama article) is to raise or lower each of the series one after the other so that each contract joins without a gap (similar to the boats going through the Panama canal). There are several problems with this “primitive” method:

• You introduce a trend bias (by always lowering or raising prices at rollover time, the impact over time will introduce a large drift. Far past data could even become negative)
• You are losing relative price difference (shifting all prices by an absolute amount has that effect: 10 to 11 is +10% but add 100 to both for an extreme case and 110 to 111 becomes less than +1%).

The March contract (in yellow) has been lowered to eliminate the gap with the the June contract. This distorts the relative price difference: the 25% move from 1480 to 1850 becomes a 27% move from 1380 to 1750.

Taking a leaf from the Equities book

The right approach seems to consider each contract roll-over in a similar fashion to a classic “stock-split” on Equities. When a stock splits, you effectively get X shares for every Y shares that you hold and the price is adjusted accordingly to reflect market capitalization. If a company performs a 10-for-1 split (meaning you get 10 new shares for every share that you hold), the price will effectively be divided by 10 after the split is effected – and historical data will normally be divided by 10 to represent the prices in the same “terms” as today (and therefore avoid showing a big price gap during the split). The historical data is “back-adjusted” by applying a proportional ratio related to the stock split (ratio=1/10 here).

Proportional back-adjustment splicing for Futures contracts

For Futures contract we can apply the same process of proportional back-adjustment at every contract roll-over. You would determine the adjustment ratio by dividing the price of the new contract by the price of the old contract. This ensures a constant relative (percentage-wise) relationship between any prices across the trading history.

The March contract has been lowered to join the newer contract with no gap. This has been done by multiplying the whole price series for that contract by 6% = 1850/1750 (prices before/after roll-over). This keeps the relative price difference: The 25% move highlighted stays a 25% move. You can see that the junction price is identical to the previous chart but the intermediate low circled in red has been raised (along with the whole series) to maintain the existing price ratio.

There might still be some concerns related to actual tick size vs. calculated tick size compared to the minimum tick size (a parameter you should probably take into account in your strategy) but proportional adjustments seems to be the best compromise because of the points highlighted above

There are many other ways to aggregate historical Futures data as well as other parameters to consider (nothing is ever so simple!) which I will address in a later post.

Credits: This issue first came to my attention and described in detail by Thomas Stridsman in his two interesting Trading Systems books:
Trading Systems that work and Trading Systems and Money Management
  

Note: You can receive a 10% discount on CSI data subscriptions (use coupon code LIBERTY)

Well, I have just purchased End Of Day historical futures data from Commodity Systems Inc. and this is how they call their Software/Database!

Admittedly it is supposed to be a very good data feed that Google and Yahoo use for their respective Finance portal. They are also recommended by back-testing software companies (Trading Blox, Amibroker, etc.). Futures magazine also ran a piece listing them as the “cleanest” data around (back in 99).

Futures article - CSI historical data

Why CSI?

I chose them because they appear to have credibility, good quality data, compatibility with Trading Blox and TradersStudio and I was interested in their Futures contracts splicing/concatenation algorithm choice. I am not really interested in all the “bells and whistles” that come with the software (charting, analysis, etc.) but they might become useful. My primary interest is to feed the data to a back-testing software.

Getting up and running: in a breeze

After downloading the install (500MB!) the software installs itself very quickly and starts downloading the latest database updates. You are supposed to run updates every so often to keep the database current. Once it is done you can start playing with the data within Unfair Advantage. The docs (both online and printed) are pretty good too.

Wide choice of markets and contract types

There are about 900 futures in the database and you can pretty much splice them as you want – to recreate different TimeSeries. I’ll explore futures contract concatenation in a later post but to give you a taster of the Unfair Advantage “menu” you can “order” a CBT Corn (Floor + Electronic trading) in a March Gann Series format as a “starter” followed by CME Lean Hogs (Floor Trading only) proportionally back-adjusted with roll-overs triggered by Open Interest shifts as your “main”; and finally a Perpetual Contract of Robusta Coffee on EuroNext. Of course these are just examples (I’ll explain all these type of contracts in a follow-up post). Full functionality can be found here, all Futures coverage can be found there and finally pricing options.

Export functionality

For each of these contracts that you add to the Unfair Advantage portfolio, you can define several export formats that will generate specific files ready to be imported to your favourite back-testing tool. There is also an API that allows you to access the data to allow for some automation – this will definitely prove handy further down the line.

The User Interface – screenshots

Here is what the software looks like:

Main window – the portfolio on the left-hand side contains all contracts you would want to follow while the right-hand side displays the current contract as a chart.

Contract selection screen: a myriad of options to splice the data.

In closing

I feel pretty satisfied with what I got and eager to dig more into the software/data and play with it. The application seems intuitive enough and if CSI are as good as their reputation implies, this should increase back-test results quality. Promising…

Note: You can receive a 10% discount on CSI data subscriptions (use coupon code LIBERTY)