Stepping into the equity curve

Top 

 

Implications for OM of saving risk or equity values in GBL files

If your code saves values relating to risk or total equity in GBL slots and later references these saved values, then you will undoubtedly need to use keyword RATIOGBL in your batch.sig file. Here is the reason:

When Mechanica does an account setup it starts out by doing a historical run up to and including the Date you choose on the calendar as day one of account setup. In order to minimize rounding error when calculating position sizes, the account is initialized with a beginning equity value of $1 Billion. At the end of the historical run of account setup phase 1, the final equity could easily be huge. Several hundred $billion wouldn't be unusual at all.

Some values are ratioed to Trade Level during account setup

At the end of the first phase of account setup all internal values for equity, risks, position sizes, etc. are reduced (ratioed) back down to reflect the Beginning equity value that you chose, i.e. the dollar value that you placed in the 'Trade Level' input box. By doing this, your trading account 'steps into' it's own existing equity curve for your system, reflecting the values as they were at the end of the historical run. So, the intended result is for position sizes to reflect what your system is currently experiencing even in cases where currently open positions may have been resized any number of times throughout the history of the open trades.

OM equity tracks future historical runs

Granted it would be far easier to simply access your Initial size code on the day you wish to start trading. But that would not be good as it would immediately create an equity curve going forward in your OM account that did not track with your system's historical equity curve going forward. Then after, say, a few months of actually trading the system you notice that the last 2 months of a new historical run do not compare to your OM results. Something has gone badly wrong! To prevent this problem we feel strongly that having your OM account's equity curve, to the greatest extent possible, parallel your system's historical equity curve going forward is a vital part of making the transition from backtesting a system to actually trading it.

Effect on GBL values of ratioing during account creating

Now what does that have to do with saved GBL values? Let's say your system trades it's own equity curve. Your batch.sig calls for a .Siz file pass that saves daily total equity and maybe some risk values in GBL slots. Then a subsequent Sig pass reads the saved GBL values and does some technical analysis on that data. One example would be applying a moving average crossover to make subsequent entry or exit decisions. That approach works fine as long as we are only doing historical runs. But once we move to OM and setup a trading account there is a problem. The daily equity values which you are saving in GBL slots suddenly take a major cliff dive. Remember at the end of day 1 of account setup TOTALEQUITY, etc. was ratioed down from many billions to a level that matches your initial account balance. But the values saved in GBL slots day-by-day (the ones we apply the moving average to) are not ratioed the same way that other values are. Why? Because Mechanica cannot know that it is supposed to do that.

RATIOGBL

Enter keyword RATIOGBL. Now your code can tell Mechanica that it must apply the same ratio value to all previously saved (user specified) GBL values so that going forward beyond initial account setup there isn't what appears to your technical analysis code to be a huge gap down in GBL values which would certainly wreck the arithmetic in any calculations involving your saved GBL values.