I’d like to run a few sims using trailing stops for sell stops. Looked in price vol category but coudn’t see any thing that would help. Any suggestions
Thank you
I’d like to run a few sims using trailing stops for sell stops. Looked in price vol category but coudn’t see any thing that would help. Any suggestions
Thank you
PctFromHi < -20 This is a very basic trailing stop. Generally, it is saying to sell the stock after it has dropped 20% from the high it has hit while you have owned it.
you can change the -20 to whatever you are comfortable with.
Wayne
Hi,
Note that the condition PctFromHi < -20 is evaluated only when the sim or port is rebalanced. So for a weekly rebalance, if the stock drops so your net gain is -30% during the week but back to -19% at the time of rebalance, the position is not sold.
To better emulate a real life trailing stop you can test with a daily rebalance, then the situation above would cause the stock to be sold, assuming it was below -20% at end of day.
Don
Thanks Don, I didn’t know that. I often wondered why that line sometimes didn’t seem to work!
Wayne
Just now got back to my post. Thanks to Don and Wayne. EXactly what I was looking for
Todd
There has been a feature request on this subject languishing for 3.5 years.
Even daily rebalancing isn’t quite right as a workaround, because that just looks at the closing price, and distorts the whole rebalance process.
Handling it the right way would require some careful programming to look at the lowest low and highest high since the last rebalance, but the sequence – even intraday – would come into play for a perfect simulation.
I was pondering this topic a while ago. How can you simulate a daily test of a stop loss for a weekly rebalanced sim?
As Don pointed out, a stock may decline 30% within a week but you are only going to trigger a sell with a PctFromHI < -20 at the end of the week at rebalance.
If you run a daily rebalance it will get sold on the day it crosses -20%, but the sim will relpace it with a new stock. You then have a daily rebalanced sim that does not reflect the weekly rebalance that I want.
Is there a way to not replace the stock during the week? Kind of like a No Wash Sell (LastSellDaysLT(30)=FALSE) for the buy side. I can’t think of any way to prevent the buy. Any ideas?
Glenn Fagerlin
I remember a discussion dealing with something like this a couple of years ago. Marco came up with the idea of giving each day of the week a number designator. e.g. Monday would be 1, Tuesday would be 2, etc.
Then if you wanted to buy only on Mondays, one of your buy rules would be WeekDay = 1. This way you could rebalance daily but only buy on Mondays.
Marco, do you remember this? Is this something that could be done fairly easily?
You hit the nail on the head, Jerrod. I’ve been working on a system in which the main sell rule is a trailing stop rule. I don’t have a problem with the daily rebalancing. My problem is that I have found that intraday movements, both up and down, have a significant effect on the trading of almost every stock. If a stock moves up 5 points in a day, but finishes the day even, that certainly makes a big difference in where your stop moves to in real life, whereas it makes no difference at all in simulated backtesting. So it isn’t just intraday lows, which would have stopped out a stock in real life, that effect the validity of a backtest, but intraday highs, as well.
This may, in fact, make the use of trailing stops in P123 sims, not only useless, but, dangerously misleading. It is possible that there might be a white noise effect of mistakes canceling each other out, but it is very difficult to determine to what extent that might be the case… Since the system I designed and tested resulted in a 75% per annum return in each of the last two years, to date,with daily rebalancing, I am attempting to figure out if there is any validity to the results.
Actually, after backtesting for the most recent two years, I then decided to backtest the system for the past 12 yrs, and, it was in the process of doing so, that I picked up what seemed to be computer errors. I then determined the errors were the result of the failure to take into account intraday highs and lows in executing the trailing stops. Consequently, I began using a database which shows the open, close, high and low info for each day, and I manually correct for any errors, taking that info into account. As you may imagine, this makes the testing somewhat grueling and time-consuming. Even then, there is margin for error, as in the case of a stock that is up $1.00 for the day, so I assume it did not stop out that day, and don’t check the daily info for the stock on that day, but later find out that the stock dipped a dollar to its’ low, thereby stopping out, before rallying to a gain on the day.Then I have to go back to that day to stop out the stock, and undo all the trades that have been made in the interim period. I am pressing on with the testing, despite the difficulty, but it is taking a long time.
You may think i am crazy to go to all this trouble(and you may be right!). But the simplicity of the trailing stop appeals to me. And the reward of the system I am working on is the “reward vs. risk”(%gain vs. %drawdown) ratio, because, so far, in the 8 years I have tested it for, the largest drawdown has been 11.5%, which happened only once. Every other drawdown has reversed itself at 8%(which sometimes involves going to cash temporarily).
So to Tarabia, and others who are using trailing stops, I have to say that I question the validity of doing so. If it doesn’t work that way in real life, then what is the point of creating a system that will only work in virtual backtesting?
If anyone has had a live Port, which featured trailing stops, and worked live as well as it performed in backtesting, then I would really like to hear from them.