Let's imagine two backtests. In backtest 1, we have no stops on the system - let's say it uses an indicator cross-up to exit a trade. We end up with, say, 100 trades on a portfolio of stocks.
In backtest 2, we have an 8% fixed stop. As this system is tested, it exits trades that hit the 8% fixed stop, and then enters more trades as a result of having available capital and valid signals. This system now has 250 trades. Now imagine we took backtest 1, and then brought it into Excel and simply said "cut off trades at 8%". And, at the same time, do not add any additional trades. So you have a system that has the same number of trades as backtest 1, but with an 8% stop on the positions. In contrast, backtest 2 has more trades, and maybe it did better or worse because of those extra trades. Just a concept I'm playing around with.... --- In [email protected], "Mike" <sfclimb...@...> wrote: > > I'm sorry. But, I do not understand what you are trying to say. > > You have described a system that took trades, got stopped out on some subset, > then took additional trades. If backtesting for the same time period over > which that system was run, then the backtester should show the same results > as what would have taken place when live trading the system. > > I still don't understand what you mean by applying the stop after the > backtest has completed. What are you referring to as a "backtest"? Are we > talking about the same thing? I'm referring to clicking on the Backtest > button from the AA window. Are you perhaps referring to calling the Equity() > function from within code before an ApplyStop() function call? > > Running a backtest is for a pre-determined period; start to finish. If you > want the backtest to reflect some additional actions taken beyond the > original finish date, then extend the finish date. Trying to compare trading > results for one (longer) period to the backtest results of a second (shorter) > period is comparing apples to oranges. > > I fail to see why you would ever need to export trades and manually alter > them. > > If it's not imporant to you, feel free to let the thread die. Otherwise, it > might help if you provided a detailed scenario that captures exactly what > you're trying to express. > > Mike > > --- In [email protected], "droskill" <droskill@> wrote: > > > > Applystop works within the system - so you might have 10 trades and, say, 5 > > trades stopped out. Because you had 5 trades stopped out, the system > > reentered 5 more times. So you now have 15 trades. > > > > Now imagine that you applied the stop after the simulation/backtest was > > completed. You'd have the same number of trades but with a stop applied. > > > > --- In [email protected], "Mike" <sfclimbers@> wrote: > > > > > > Hi, > > > > > > Could you be a little more specific in what you think the problem is? > > > What exactly do you mean by applying stops after the fact? > > > > > > Handling of stops is built in to the backtester. Any call you make to > > > ApplyStop in your formula will be respected by the backtester. > > > > > > Mike > > > > > > --- In [email protected], "droskill" <droskill@> wrote: > > > > > > > > Was having a conversation with someone who brought up an interesting > > > > point about using stops. When you use stops in AB, and you get stopped > > > > out, you obviously can reenter a trade. But if you performed a > > > > backtest, and then applied stops after the fact, you would have the > > > > same number of trades but then have the stops - the performance could > > > > be quite different, and the number of trades will logically go up when > > > > you're using stops in AB. Now one way around this is to export the > > > > trades to, say, Excel and then manually apply the stops, but I'm > > > > wondering if there is anything in AB to deal with this issue. > > > > > > > > Anyone have any thoughts on the issue? > > > > > > > > > >
