TRADINGVIEW BACKTEST SCRIPT by Lionshare (c) 2015 THS IS A REAL ALTERNATIVE FOR LONG AWAITED TV NATIVE BACKTEST ENGINE. READY FOR USE JUST RIGHT NOW.
For user provided trading strategy, executes the trades on pricedata history and continues to make it over live datafeed. Calculates and (plots on premise) the next performance statistics:
profit - i.e. gross profit/loss.
profit_max - maximum value of gross profit/loss.
profit_per_trade - each trade's profit/loss.
profit_per_stop_trade - profit/loss per "stop order" trade.
profit_stop - gross profit/loss caused by stop orders.
profit_stop_p - percentage of "stop orders" profit/loss in gross profit/loss.
security_if_bought_back - size of security portfolio if bought back.
trades_count_conseq_profit - consecutive gain from profitable series.
trades_count_conseq_profit_max - maxmimum gain from consecutive profitable series achieved.
trades_count_conseq_loss - same as for profit, but for loss.
trades_count_conseq_loss_max - same as for profit, but for loss.
trades_count_conseq_won - number of trades, that were won consecutively.
trades_count_conseq_won_max - maximum number of trades, won consecutively.
trades_count_conseq_lost - same as for won trades, but for lost.
trades_count_conseq_lost_max - same as for won trades, but for lost.
drawdown - difference between local equity highs and lows.
expected_value - median gain value of all wins and loss.
zscore - shows how much your seriality of consecutive wins/loss diverges from the one of normal distributed process. valued in sigmas. zscore of +3 or -3 sigmas means nonrandom realitonship of wins series-to-loss series.
confidence_limit - the limit of confidence in zscore result. values under 0.95 are considered inconclusive.
sharpe - sharpe ratio - shows the level of strategy stability. basically it is how the profit/loss is deviated around the expected value.
sortino - the same as sharpe, but is calculated over the negative gains.
k - Kelly criterion value, means the percentage of your portfolio, you can trade the scripted strategy for optimal risk management.
k_margin - Kelly criterion recalculated to be meant as optimal margin value.
DISCLAIMER :
The SCRIPT is in ALPHA stage. So there could be some hidden bugs. Though the basic functionality seems to work fine. Initial documentation is not detailed. There could be english grammar mistakes also.
NOW Working hard on optimizing the script. Seems, some heavier strategies (especially those using the multiple SECURITY functions) call TV processing power limitation errors.
Appreciate it. You personally inspired me for pinescripting :)
LazyBear
⋅
Glad to hear that :)
chrysopoetics
⋅
Oh my f***ing God, I have been looking for something like this for a long, long time. Thank you so, so much
Kilgore
⋅
One of the most elaborated scripts in TV ever o0!
One question: is there the possibility for evaluation of a signal (e.g. EMA crossing, RSI OS/OB crossings) at intra-candle? I mean, can the script recognise the signals per ticker or it is at the bar-closing?
Thanks for the outstanding work, Lionshare
lionshare
⋅
Thanks! :)
If you are asking about whether one can use intra-candle data for your rules, then "yes, sure" you can emulate this kind of behavior with the help of SECURITY function.
The order itself can also be executed at the price inside the bar - there is a "Limit" type order for that. It works good for some kind of signals you need (like bands touch).
In this case a price value (not boolean one) should be stated as the rule expression. E.g.: sell_limit_rule_1 = bollinger_upper_band. This will be EXECUTED as SELL order at the price of current bollinger upper band, when it's touched by the priceaction. Note: to do that in realtime trading you will need to reassign limit order each tick the bollinger upper band changes it's value - but that's an realtime trading execution issue only, not the problem backtesting have to solve.
I have also managed to make, but reserved for the later times, an additional order type (5001) "Market at Lastprice", which was aimed to emulate what you are asking for. But... per-ticker price (and thus - lastprice) are "bottlenecked" by the character the SECURITY function work in pinescript. Cause if you are working on, let's say, 4 hour timeframe and want to have the close price of 1 min bars updated each tick - it will not work - it will show first close of the first 1m candle of the new 4h candle, when it starts. So, there is no way to use that right now, unless to work on the noisy 1m timeframe... but that is not a good way how the system should be tested on the history...