Backtesting vs. Realtime results

Discussion in 'Automated Trading' started by jonnyman, Oct 19, 2005.

  1. kotika

    kotika

    That very well may be true, but doesnt make it right or meaningful. What if anything is the number produced according to this recipe supposed to tell me?

    Here we are talking about performance of an automated trading system, and i stand by my comments. I suggest using the per trade ratio which is sometimes called "Information Ratio". I thought the original poster was referring to that.

    once again:
    per trade average return: m
    per trade standard deviation : s
    Sharpe ratio S: S = m/s

    Then according to Kelly you use leverage L:
    L = m/s^2
    which will grow your money exponentially in the "long run":
    ln(W_N/W_0) = m^2 / s^2 / 2 * N = S^2/2 * N

    I hate piling up all this high math, but without it there is no meaningful way to use sharpe ratios.
    If someone needs an example with numbers i will be happy to come up with one.

    K
     
    #21     Oct 21, 2005
  2. kotika

    kotika

    That looks closer to what i intended, but still not quite right. If indeed optimization of leverage was done, you might write
    S = sqrt[2*ln[W]/N] = sqrt[2*ln[1.3]/40] = 0.11

    All this tells you that if you had a strategy which produced 40 signals a year with sharpe ratio 0.11 per trade you could grow your money by 30% a year, but only if you optimize leverage.

    Why not find out directly from your data what was the average and standard deviation, Excel can compute standard deviation of a list of numbers using STDEV()
     
    #22     Oct 21, 2005
  3. kut2k2

    So are you saying the sharpe ratio is really 4.5?
    My software doesnt tell me the STD DEV of my trades.
    Can I still use your formula?

    Thanks

    Statistics
    All trades Long trades Short trades
    Initial capital 10000000.00 10000000.00 10000000.00
    Ending capital 8106492309.63 8106492309.63 13665437.20
    Net Profit 8096492309.63 8096492309.63 3665437.20
    Net Profit % 80964.92 % 80964.92 % 36.65 %
    Exposure % 87.58 % 87.58 % 0.00 %
    Net Risk Adjusted Return % 92451.71 % 92451.71 % N/A
    Annual Return % 52.92 % 52.92 % 2.00 %
    Risk Adjusted Return % 60.42 % 60.42 % N/A

    --------------------------------------------------------------------------------

    All trades 2982 2982 (100.00 %) 0 (0.00 %)
    Avg. Profit/Loss 2661083.05 2661083.05 N/A
    Avg. Profit/Loss % 18.94 % 18.94 % N/A
    Avg. Bars Held 77.65 77.65 N/A

    --------------------------------------------------------------------------------

    Winners 656 (22.00 %) 656 (22.00 %) 0 (0.00 %)
    Total Profit 9845720316.47 9845720316.47 0.00
    Avg. Profit 15008719.99 15008719.99 N/A
    Avg. Profit % 101.28 % 101.28 % N/A
    Avg. Bars Held 294.03 294.03 N/A
    Max. Consecutive 87 87 0
    Largest win 901166109.14 901166109.14 0.00
    # bars in largest win 612 612 0

    --------------------------------------------------------------------------------

    Losers 2326 (78.00 %) 2326 (78.00 %) 0 (0.00 %)
    Total Loss -1910370658.42 -1910370658.42 0.00
    Avg. Loss -821311.55 -821311.55 N/A
    Avg. Loss % -4.28 % -4.28 % N/A
    Avg. Bars Held 16.62 16.62 N/A
    Max. Consecutive 98 98 0
    Largest loss -27956303.87 -27956303.87 0.00
    # bars in largest loss 6 6 0

    --------------------------------------------------------------------------------

    Max. trade drawdown -465607310.89 -465607310.89 0.00
    Max. trade % drawdown -69.82 % -69.82 % 0.00 %
    Max. system drawdown -850518786.40 -850518786.40 0.00
    Max. system % drawdown -41.91 % -41.91 % 0.00 %
    Recovery Factor 9.52 9.52 N/A
    CAR/MaxDD 1.26 1.26 N/A
    RAR/MaxDD 1.44 1.44 N/A
    Profit Factor 5.15 5.15 N/A
    Payoff Ratio 18.27 18.27 N/A
    Standard Error 1200551094.41 1200551094.41 44406.90
    Risk-Reward Ratio 0.37 0.37 5.23
    Ulcer Index 9.88 9.88 0.00
    Ulcer Performance Index 4.81 4.81 N/A
    Sharpe Ratio of trades 0.25 0.25 0.00
    K-Ratio 0.03 0.03 0.38
     
    #23     Oct 21, 2005
  4. Isn't Kelly approximation L = m/(m^2+s^2) ?
     
    #24     Oct 21, 2005
  5. To answer your question, MY experience is that I normally beat my hypothetical results.

    However, My hypothetical results always include commissions and a realistic ammount of slippage. I calculate slippage based on volume for the contract I am trading as well as which order types I will be using.

     
    #25     Oct 21, 2005
  6. Okay, I will bite. I run an automated system that trades mostly futures and options, so I have no idea what equities is like. Furthermore, I use the alternative investment community definition of Sharpe ratio (annualized daily returns divided by annualized stdev).

    I wrote a fully scale simulator that the slippage, fill rate, can all be adjusted (fitted). So I compute the correlation between my simulator and the real market on weekly regression (basically running the entire week of tick data back through the simulator, with the correlation between simulated fills and real fills). Naturally, since the slippage parameter can be adjusted, I can get my simulator to consistently 80% correlation (or higher), which is sufficient for me to backtest pretty much any strategy against.

    My strategy development is actually backwards, I wrote the simulator first, tuned it to have strong correlation to the real market (through a few intentially money losing sessions), then implemented the strategies. Since I find optimization against a bad backtesting environment to be the most useless exercise in the world. So I have been joking that the simulator is actually the core of my system, not my strategies, which would change over time.
     
    #26     Oct 21, 2005
  7. This may not be too helpful but it does give you some values.

    Over time I have observed a range of backtesters who have had a common focus. Backtesters come in a lot of sizes it turns out.

    There are two modes over the range. One mode does have a greater # of contributors it turns out.

    One group misses by a factor of 2 to 4 and the other group is usually off by an order of magnitude all are to one side of the real results.

    The opposite side to which you are biased in your thinking. One other poster here who both trades and backtests has the same bias as above which is the oppositie of yours.

    You can see that there are two streams of results and one stream has two modes that are isolated from oneanother.

    If an electrical engineer were to look at back testing in the same kind of context as considering the use of energy to produce fidelity in music, then he would mostly reject any results from backtesting trading models or approaches.

    Kelly is an example from the hallowed halls of BTL and who did not have an interest in music. He made part of the trip across the bridge from real trading to assessing the models.

    What are the causal factors of how backtesting misses o both sides of reality and how an order of magnitude difference occurs when simultaneous efforts are made by differing classes of backtesters?

    It is actually analagous to the differences between markets and the commercial or custom software sold to operate in markets. There is a convergence of skills sets for programming and trading, rarely. In this thread, so far, you see but one person so far.

    So why do the great traders not use computer sciences, commonly. Why is computer science not a necessary componet of trading well and with expertise.

    Who among those with high money velocity wealth building need things like sharpe ratios and even Kelly stuff?

    When the applications of magnetron and klystrons were made at first, they had short lives. Analysis of the variables lengthened their lives by factors between 10 and 100. The new series of related patents (contributed to BTL) were specifically related to, of all things, power supplies.

    So why don't most people in the profession of improving trading results have a set of tools for doing trading analysis? Is there any reason to believe analyzing the markets is a possible pragmatic method for determining the efficacy and effectiveness of a trader (even though he is using a black box)?

    Is there anything more off the mark as in looking at a given set of market data from varying sets of assortments of rules?

    When I look at any profferred set of analysis tools and their results, the first thing I examine is the volume component and specifically how it is tied to the price component and then how sophisticated the multivarient analysis proceeds from there.

    I find that generally the volume component of backtesting is weak. Secondly, the interrelationship of volume and price is often poorly articulated. Finally, the relationship of the near past and near future is not weighted in a manner that varies in correspondence to any frequency of occurrance in these time bound pre and post relationships.
     
    #27     Oct 21, 2005
  8. jonnyman

    jonnyman

    Good replies so far, but perhaps I should be more specific.

    I was refering to automated trading backtesting using actual data.

    For example wealth lab and esignal both have languages that allow you to set up an algorithm and backtest it over past data and execute trades to give you a final monetary profit (or loss) among other data.

    Basically it takes the algorithm and aggregates it over a series of historical data while simulating trigger execution as if it happened in real time. You get a profit or loss based on the executions of the algorithm.

    Has anyone used these systems and compared it to real-time results? I'm just wondering about the accuracy of the programs and what percentage of slippage might be expected.
     
    #28     Oct 21, 2005
  9. What sort of data sets are you backtesting with? With full depth from all markets you should have very reliable results.

     
    #29     Oct 21, 2005
  10. maxpi

    maxpi

    You can write your backtest to evaluate the entry price after the fact and the exit as well, that way you can know if your limit order had a good chance of going through, expecially if you look at the volume at your price. That does not require any special software add ons either, you just have to code it like that. My experience is that you are not going to want to put the coding and test time in required to test things to the finest detail, if you can test with good approxamations you will find that the results in real time are similar to the results in the backtest. Here is one good way to go: 1)backtest 2)test the system on data that was not in the backtest 3)run your system in realtime but set it up so the brokerage API will reject the orders, ie: price =0, and record all your trades for awhile to see how it compares to your tests. [That is a shakedown cruise more than a system test] 4)run the system realtime with real money but $500 positions, with IB this is the ideal small order size, commission caps and minimums converge in a nice way at that level. 5)if all systems are go run the system with larger position size, use your kelly criteria or whatver you use to determine position size, who cares, if a system works it is all gravy anyhow.

    Max
     
    #30     Oct 21, 2005