After studying several other scripts, I believe I have found the Holy Grail! (Or perhaps I've just found a bug with Tradingview's Pinescript v4 language) Anyhow, I'm publishing this script in the hope that someone smarter than myself could shed some light on the fact that adding a trailing stop to any strategy seems to make it miraculously...no that's an understatement...incredulously, stupendously, mind-bendingly profitable. I'm talking about INSANE profit factors, higher than 200x, with drawdowns of <10%. Sounds too good to be true? Maybe it is...or you could hook it up to your LIVE broker, and pray it doesn't explode. This is an upgraded version of my original Pin Bar Strategy.
Recommended Chart Settings:
Asset Class: Forex Time Frame: H1
Long Entry Conditions:
a) Exponential Moving Average Fan up trend b) Presence of a Bullish Pin Bar c) Pin Bar pierces the Exponential Moving Average Fan
Short Entry Conditions:
a) Exponential Moving Average down trend b) Presence of a Bearish Pin Bar c) Pin Bar pierces the Exponential Moving Average Fan
Exit Conditions: a) Trailing stop is hit b) Moving Averages cross-back (optional) c) It's the weekend
Default Robot Settings:
Equity Risk (%): 3 //how much account balance to risk per trade Stop Loss (x*ATR, Float): 0.5 //stoploss = x * ATR, you can change x Stop Loss Trail Points (Pips): 1 //the magic sauce, not sure how this works Stop Loss Trail Offset (Pips): 1 //the magic sauce, not sure how this works Slow SMA (Period): 50 //slow moving average period Medium EMA (Period): 18 //medium exponential moving average period Fast EMA (Period): 6 //fast exponential moving average period ATR (Period): 14 // average true range period Cancel Entry After X Bars (Period): 3 //cancel the order after x bars not triggered, you can change x
Backtest Results (2019 to 2020, H1, Default Settings):
As you can clearly see above, this forex robot is projected by the Tradingview backtester to be INSANELY profitable for all common forex pairs. So what was the difference between this strategy and my previous strategies? Check my code and look for "trail_points" and "trail_offset"; you can even look them up in the PineScript v4 documentation. They specify a trailing stop as the exit condition, which automatically closes the trade if price reverses against you.
I however suspect that the backtester is not properly calculating intra-bar price movement, and is using a simplified model. With this simplfied approach, the trailing stop code becomes some sort of "holy grail" generator, making every trade entered profitable.
Risk Warning:
This is a forex trading strategy that involves high risk of equity loss, and backtest performance will not equal future results. You agree to use this script at your own risk.
Hint:
To get more realistic results, and *maybe* overcome the intrabar simulation error, change the settings to: "Stop Loss Trail Points (pips)": 100 I am not sure if this eradicates the bug, but the entries and exits look more proper, and the profit factors are more believable.
As @RafaelZioni points out. You are only in a given trade for one bar. So, if you can identify a high probability opportunity for a bull bar to follow the current bar and then you buy its open and sell its close, that is a profitable strategy. On that 1h chart, you would be in a trade for 1 hour or less. Nothing wrong with that at all. But you don't really have a trailing stop here in a conventional sense. I think what's happening is your function is forcing a entry and exit on the same bar.
Try to add commissions to this strategy and watch how the results change.
TsangYouJun
⋅
@kurtsmock, still I think its rather strange that my script can be so "prescient". It seems all the trades (a very large majority), are in the correct direction; which is unusual.
ritvikraj313
⋅
@kurtsmock, still profitable after adding comission and i think its good for retail traders
kh_thetrader
⋅
Read this article and you may understand why. If the entry price, trail point and trail offset are all within a single bar, your profit will be overstated. This is not a system bug, it's just a limitation in backtesting using minute/hour/day bar, because a single bar will only stores 4 prices. Unless you backtest with tick data.
@kh_thetrader, yes you summarise the issue succinctly. Because we only have the OHLC of each bar, and we lack the intrabar (tick) price movement, the simulator has to assume too much.