Simple_RSI+PA+DCA StrategyThis strategy is a result of a study to understand better the workings of functions, for loops and the use of lines to visualize price levels. The strategy is a complete rewrite of the older RSI+PA+DCA Strategy with the goal to make it dynamic and to simplify the strategy settings to the bare minimum.
In case you are not familiar with the older RSI+PA+DCA Strategy, here is a short explanation of the idea behind the strategy:
The idea behind the strategy based on an RSI strategy of buying low. A position is entered when the RSI and moving average conditions are met. The position is closed when it reaches a specified take profit percentage. As soon as the first the position is opened multiple PA (price average) layers are setup based on a specified percentage of price drop. When the price hits the layer another position with the same position size is is opened. This causes the average cost price (the white line) to decrease. If the price drops more, another position is opened with another price average decrease as result. When the price starts rising again the different positions are separately closed when each reaches the specified take profit. The positions can be re-opened when the price drops again. And so on. When the price rises more and crosses over the average price and reached the specified Stop level (the red line) on top of it, it closes all the positions at once and cancels all orders. From that moment on it waits for another price dip before it opens a new position.
This is the old RSI+PA+DCA Strategy:
The reason to completely rewrite the code for this strategy is to create a more automated, adaptable and dynamic system. The old version is static and because of the linear use of code the amount of DCA levels were fixed to max 6 layers. If you want to add more DCA layers you manually need to change the script and add extra code. The big difference in the new version is that you can specify the amount of DCA layers in the strategy settings. The use of 'for loops' in the code gives the possibility to make this very dynamic and adaptable.
The RSI code is adapted, just like the old version, from the RSI Strategy - Buy The Dips by Coinrule and is used for study purpose. Any other low/dip finding indicator can be used as well
The distance between the DCA layers are calculated exponentially in a function. In the settings you can define the exponential scale to create the distance between the layers. The bigger the scale the bigger the distance. This calculation is not working perfectly yet and needs way more experimentation. Feel free to leave a comment if you have a better idea about this.
The idea behind generating DCA layers with a 'for loop' is inspired by the Backtesting 3commas DCA Bot v2 by rouxam .
The ideas for creating a dynamic position count and for opening and closing different positions separately based on a specified take profit are taken from the Simple_Pyramiding strategy I wrote previously.
This code is a result of a study and not intended for use as a full functioning strategy. To make the code understandable for users that are not so much introduced into pine script (like myself), every step in the code is commented to explain what it does. Hopefully it helps.
Enjoy!
Cari dalam skrip untuk "backtesting"
Drip's 11am rule breakout/breakdown (OG)This indicator is based on Drippy2hard's 11:30 am (EST) rule.
In simple terms the rule states that:
If a trending stock makes a new high after 11:15-11:30am EST, there is a 75% chance of closing within 1% of High of day (HOD). Same applies for downtrend.
Please note:
Not all stocks will abide by this, this is backtested on stocks with avg daily volume > 2M and mostly mega cap stocks which have liquid option chains. The backtesting results show very promising results on $SPY/ $SPX so it is advised to trade $SPY/ $SPX using this indicator over any other stocks.
Although the name suggests 11 AM rule, the backtesting shows higher win rate for 11:30 AM so please select that option in the settings.
As always, no indicator is perfect and please follow your risk management and understand that indicators are tools to aid your trading and by no means they are supposed to work as intended in all scenarios
How the script works
1. A HOD/LOD zone is identified based on regular session (9:30am-11:30am) EST. Users can select cut off time to 11AM in the settings. These will be indicated on chart after 11/11:30pm depending on what user selected
2. If the stock breaks above the HOD and the ADX is showing strong momentum to upside then the candlesticks will start showing neon color, if the trend based on moving averages and candle closing is also bullish then the indicator will show trend arrows under the candle indicating to stay in the trade. Same applies for break below LOD, only the colors will change to represent downtrend.
3. An optional cloud is also shown if the trend is developed. The cloud can be used as trail stop or re entry point as long as it is displayed on chart
How to use the indicator in trading
In general, there are three scenarios which are trade worthy
1. If the stocks breaks out above the HOD zone and up trend develops or the stocks breaks below the LOD zone and downtrend develops. See images below
2. You can also use the LOD/HOD zone as demand/ supply if the Price action is range bound like this example below
Thanks for reading, please give thumbs up if you like using it! Please post comments on how to use it.
Pure Mark Minervini 10%TP 5%CLBacktesting Mark Miniverni Template
By Donnie Lee
Overall, a good basic guideline from Mark Miniverni to choose which stock to buy. His selection are said to be stocks in stage 2 uptrend phase which could see price surge soon.
This script enable backtesting of Mark template (Investor's Business Ranking Excluded) on equity like stocks
Further fine tuning with additional filters are needed to find good entry with desired cut loss level and position sizing.
There is no holy grail strategy. Choose one with an edge that you are comfortable with and stick to it.
Losing is part and parcel of trading. Hesitation to cut loss can lead to big loss. And if you can avoid losing big, you might stand a chance to profit in the end.
Mark Miniverni Template
1. The current stock price is above both the 150-day (30-week) and the 200-day (40-week) moving average price lines.
2. The 150-day moving average is above the 200-day moving average.
3. The 200-day moving average line is trending up for at least 1 month (preferably 4–5 months minimum in most cases).
4. The 50-day (10-week) moving average is above both the 150-day and 200-day moving averages.
5. The current stock price is trading above the 50-day moving average.
6. The current stock price is at least 25% above its 52-week low (30% as per his book 'Trade Like a Stock Market Wizard').
7. The current stock price is within at least 25% of its 52-week high (the closer to a new high the better).
Heikin Ashi SupertrendAbout this Strategy
This supertrend strategy uses the Heikin Ashi candles to generate the supertrend but enters and exits trades using normal candle close prices. If you use the standard built in Supertrend indicator on Heikin Ashi candles, it will produce very unrealistic backtesting results because it uses the Heikin Ashi prices instead of the real prices. However, by signaling the supertrend reversals using Heikin Ashi while using standard candle close prices for the entries and exits, it corrects the backtesting errors and gives you a more realistic equity curve. You should set the chart to use standard candles and then hide them (the strategy creates the candles).
This strategy includes:
Plotting of Heikin Ashi candles
Heikin Ashi Supertrend
Long and Short Entry Signals
Move stop loss after trade is X% in profit
Profit Target
Stop Loss
Built in Alertatron automation
Alertatron Trade Automation Integration
For Alertatron integration, be sure to configure the strategy settings and "Enable Webhook Messages" before creating an alert with {{strategy.order.alert_message}} in the body of your alert message. Be sure to enable webhooks and point it to your Incoming Alertatron webhook URL.
Notes
While this strategy does pretty well during trending markets, It's worth noting that the Buy and Hold ROI is much better during peak times of the bull market
Not financial advice. Do not risk more than you can afford to lose.
Strategy BackTest Display Statistics - TraderHalaiThis script was born out of my quest to be able to display strategy back test statistics on charts to allow for easier backtesting on devices that do not natively support backtest engine (such as mobile phones, when I am backtesting from away from my computer). There are already a few good ones on TradingView, but most / many are too complicated for my needs.
Found an excellent display backtest engine by 'The Art of Trading'. This script is a snippet of his hard work, with some very minor tweaks and changes. Much respect to the original author.
Full credit to the original author of this script. It can be found here: www.tradingview.com
I decided to modify the script by simplifying it down and make it easier to integrate into existing strategies, using simple copy and paste, by relying on existing tradingview strategy backtester inputs. I have also added 3 additional performance metrics:
- Max Run Up
- Average Win per trade
- Average Loss per trade
As this is a work in progress, I will look to add in more performance metrics in future, as I further develop this script.
Feel free to use this display panel in your scripts and strategies.
Thanks and enjoy :)
Short Swing Bearish MACD Cross (By Coinrule)This strategy is oriented towards shorting during downside moves, whilst ensuring the asset is trading in a higher timeframe downtrend, and exiting after further downside.
This script can work well on coins you are planning to hodl for long-term and works especially well whilst using an automated bot that can execute your trades for you. It allows you to hedge your investment by allocating a % of your coins to trade with, whilst not risking your entire holding. This mitigates unrealised losses from hodling as it provides additional cash from the profits made. You can then choose to hodl this cash, or use it to reinvest when the market reaches attractive buying levels. Alternatively, you can use this when trading contracts on futures markets where there is no need to already own the underlying asset prior to shorting it.
ENTRY
This script utilises the MACD indicator accompanied by the Exponential Moving Average (EMA) 450 to enter trades. The MACD is a trend following momentum indicator and provides identification of short-term trend direction. In this variation it utilises the 11-period as the fast and 26-period as the slow length EMAs, with signal smoothing set at 9.
The EMA 450 is used as additional confirmation to prevent the script from shorting when price is above this long-term moving average. Once price is above the EMA 450 the script will not open any shorts - preventing the rule from attempting to short uptrends. Due to this, this strategy is ideal for setting and forgetting.
The script will enter trades based on two conditions:
1) When the MACD signals a bearish cross. This occurs when the EMA 11 crosses below the EMA 26 within the MACD signalling the start of a potential downtrend.
2) Price has closed below the EMA 450. Price closing below this long-term EMA signals that the asset is in a sustained downtrend. Price breaking above this could indicate a bullish strength in which shorting would not be profitable.
EXIT
This script utilises a set take-profit and stop-loss from the entry of the trade. The take profit is set at 8% and the stop loss of 4%, providing a risk reward ratio of 2. This indicates the script will be profitable if it has a win ratio greater than 33%.
Take-Profit Exit: -8% price decrease from entry price.
OR
Stop-Loss Exit: +4% price increase from entry price.
Based on backtesting results across a selection of assets, the 45-minute and 1-hour timeframes are the best for this strategy.
The strategy assumes each order is using 30% of the available coins to make the results more realistic and to simulate you only ran this strategy on 30% of your holdings. A trading fee of 0.1% is also taken into account and is aligned to the base fee applied on Binance.
The backtesting data was recorded from December 1st 2021, just as the market was beginning its downtrend. We therefore recommend analysing the market conditions prior to utilising this strategy as it operates best on weak coins during downtrends and bearish conditions, however the EMA 450 condition should mitigate entries during bullish market conditions.
Oversold RSI with tight SL Strategy (by Coinrule)This is one of the best strategies that can be used to get familiar with technical indicators and start to include them in your trading bot rules.
ENTRY
1. This trading system uses the RSI ( Relative Strength Index ) to anticipate good points to enter positions. RSI is a technical indicator frequently used in trading. It works by measuring the speed and change of price movements to determine whether a coin is oversold (indicating a good entry point) or overbought (indicating a point of exit/entry for a short position). The RSI oscillates between 0 and 100 and is traditionally considered overbought when over 70 and oversold when below 30.
2. To pick the right moment to buy, the strategy enters a trade when the RSI falls below 30 indicating the coin is oversold and primed for a trend reversal.
EXIT
The strategy then exits the position when the price appreciates 7% from the point of entry. The position also maintains a tight stop-loss and closes the position if the price depreciates 1% from the entry price. The idea behind this is to cut your losing trades fast and let your winners ride.
The best time frame for this strategy based on our backtesting data is the daily. Shorter time frames can also work well on certain coins, however in our experience, the daily works best. Feel free to experiment with this script and test it on a variety of your coins! With our backtesting data a trading fee of 0.1% is taken into account. The fee is aligned to the base fee applied on Binance, which is the largest cryptocurrency exchange by volume. In the example shown, this strategy made a handsome net profit of 39.31% on Chainlink with 61.54% of trades being profitable.
EMA bands + leledc + bollinger bands trend following strategy v2The basics:
In its simplest form, this strategy is a positional trend following strategy which enters long when price breaks out above "middle" EMA bands and closes or flips short when price breaks down below "middle" EMA bands. The top and bottom of the middle EMA bands are calculated from the EMA of candle highs and lows, respectively.
The idea is that entering trades on breakouts of the high EMAs and low EMAs rather than the typical EMA based on candle closes gives a bit more confirmation of trend strength and minimizes getting chopped up. To further reduce getting chopped up, the strategy defaults to close on crossing the opposite EMA band (ie. long on break above high EMA middle band and close below low EMA middle band).
This strategy works on all markets on all timeframes, but as a trend following strategy it works best on markets prone to trending such as crypto and tech stocks. On lower timeframes, longer EMAs tend to work best (I've found good results on EMA lengths even has high up to 1000), while 4H charts and above tend to work better with EMA lengths 21 and below.
As an added filter to confirm the trend, a second EMA can be used. Inputting a slower EMA filter can ensure trades are entered in accordance with longer term trends, inputting a faster EMA filter can act as confirmation of breakout strength.
Bar coloring can be enabled to quickly visually identify a trend's direction for confluence with other indicators or strategies.
The goods:
Waiting for the trend to flip before closing a trade (especially when a longer base EMA is used) often leaves money on the table. This script combines a number of ways to identify when a trend is exhausted for backtesting the best early exits.
"Delayed bars inside middle bands" - When a number of candle's in a row open and close between the middle EMA bands, it could be a sign the trend is weak, or that the breakout was not the start of a new trend. Selecting this will close out positions after a number of bars has passed
"Leledc bars" - Originally introduced by glaz, this is a price action indicator that highlights a candle after a number of bars in a row close the same direction and result in greatest high/low over a period. It often triggers when a strong trend has paused before further continuation, or it marks the end of a trend. To mitigate closing on false Leledc signals, this strategy has two options: 1. Introducing requirement for increased volume on the Leledc bars can help filter out Leledc signals that happen mid trend. 2. Closing after a number of Leledc bars appear after position opens. These two options work great in isolation but don't perform well together in my testing.
"Bollinger Bands exhaustion bars" - These bars are highlighted when price closes back inside the Bollinger Bands and RSI is within specified overbought/sold zones. The idea is that a trend is overextended when price trades beyond the Bollinger Bands. When price closes back inside the bands it's likely due for mean reversion back to the base EMA in which this strategy will ideally re-enter a position. Since the added RSI requirements often make this indicator too strict to trigger a large enough sample size to backtest, I've found it best to use "non-standard" settings for both the bands and the RSI as seen in the default settings.
"Buy/Sell zones" - Similar to the idea behind using Bollinger Bands exhaustion bars as a closing signal. Instead of calculating off of standard deviations, the Buy/Sell zones are calculated off multiples of the middle EMA bands. When trading beyond these zones and subsequently failing back inside, price may be due for mean reversion back to the base EMA. No RSI filter is used for Buy/Sell zones.
If any early close conditions are selected, it's often worth enabling trade re-entry on "middle EMA band bounce". Instead of waiting for a candle to close back inside the middle EMA bands, this feature will re-enter position on only a wick back into the middle bands as will sometimes happen when the trend is strong.
Any and all of the early close conditions can be combined. Experimenting with these, I've found can result in less net profit but higher win-rates and sharpe ratios as less time is spent in trades.
The deadly:
The trend is your friend. But wouldn't it be nice to catch the trends early? In ranging markets (or when using slower base EMAs in this strategy), waiting for confirmation of a breakout of the EMA bands at best will cause you to miss half the move, at worst will result in getting consistently chopped up. Enabling "counter-trend" trades on this strategy will allow the strategy to enter positions on the opposite side of the EMA bands on either a Leledc bar or Bollinger Bands exhaustion bar. There is a filter requiring either a high/low (for Leledc) or open (for BB bars) outside the selected inner or outer Buy/Sell zone. There are also a number of different close conditions for the counter-trend trades to experiment with and backtest.
There are two ways I've found best to use counter-trend trades
1. Mean reverting scalp trades when a trend is clearly overextended. Selecting from the first 5 counter-trend closing conditions on the dropdown list will usually close the trades out quickly, with less profit but less risk.
2. Trying to catch trends early. Selecting any of the close conditions below the first 5 can cause the strategy to behave as if it's entering into a new trend (from the wrong side).
This feature can be deadly effective in profiting from every move price makes, or deadly to the strategy's PnL if not set correctly. Since counter-trend trades open opposite the middle bands, a stop-loss is recommended to reduce risk. If stop-losses for counter-trend trades are disabled, the strategy will hold a position open often until liquidation in a trending market if th trade is offsides. Note that using a slower base EMA makes counter-trend stop-losses even more necessary as it can reduce the effectiveness of the Buy/Sell zone filter for opening the trades as price can spend a long time trending outside the zones. If faster EMAs (34 and below) are used with "Inner" Buy/Zone filter selected, the first few closing conditions will often trigger almost immediately closing the trade at a loss.
The niche:
I've added a feature to default into longs or shorts. Enabling these with other features (aside from the basic long/short on EMA middle band breakout) tends to break the strategy one way or another. Enabling default long works to simulate trying to acquire more of the asset rather than the base currency. Enabling default short can have positive results for those high FDV, high inflation coins that go down-only for months at a time. Otherwise, I use default short as a hedge for coins that I hold and stake spot. I gain the utility and APR of staking while reducing the risk of holding the underlying asset by maintaining a net neutral position *most* of the time.
Disclaimer:
This script is intended for experimenting and backtesting different strategies around EMA bands. Use this script for your live trading at your own risk. I am a rookie coder, as such there may be errors in the code that cause the strategy to behave not as intended. As far as I can tell it doesn't repaint, but I cannot guarantee that it does not. That being said if there's any question, improvements, or errors you've found, drop a comment below!
GRID SPOT TRADING ALGORITHM - GRID BOT TRADING STRATEGYGRID SPOT TRADING ALGORITHM : LONG ONLY STRATEGY OPEN SOURCE
This is a long only strategy for spot assets.
HOW IT WORKS
Grid trading is a trading strategy where an investor creates a so-called "price grid". The basic idea of the strategy is to repeatedly buy at the pre-specified price and then wait for the price to rise above that level and then sell the position (and vice versa with shorting or hedging).
FEATURES
Grids: This algorithm has a total of 10 grids.
Take profit: The trader can increase or decrease the distance between the grids from the User Interface panel, the distance between one grid and another represents the take profit.
Management: The algorithm buys 10% of the capital every time the price breaks down a grid and sells during a rise to the next higher grid. The initial capital is invested in 10 sizes which represent 10% of the capital per trade.
Stop Loss: The algorithm knows no stop loss as long as it is not activated from the User Interface panel. By activating the stop loss from the User Interface panel the algorithm will insert a close condition on all trades which will be calculated from the last lower grid.
Trades: Trades are opened only if the price is within the grid. If the market leaves the grid the algorithm will not buy new positions or sell new positions.
Optimal market conditions: The favorable market for this algorithm is the sideways market.
LIMITATIONS OF THE MODEL
The trader must take into account that this is a static model. It only works perfectly well if the market is in a sideways phase and incurs heavy losses if the market takes a downward trend. The model is unusable for an uptrend. The trader must therefore carefully analyze the market where he intends to use this strategy, making sure that the price is in a sideways phase.
USES
Indispensable research and backtesting tool for those using bots for their investments. The algorithm produces a backtesting of the strategy for past history. It is used by professional traders to understand if this strategy has been profitable on a market and what parameters to use for bots using this strategy (Kucoin, Binance etc.).
If you would like to develop your own algorithm with customized conditions based on a grid strategy, please contact us.
If you need help in using this tool, please contact us without hesitation.
[astropark] Moon Phases [strategy]Dear Followers,
today I'm glad to present you an indicator which calculates Moon Phases and let's you backtest the simplest strategy over it: buy/sell on full moon and do the opposite on new moon.
This is a public free indicator based on the public one by @paaax:
I added my usual backtesting logic, plus some more customization inputs for easy coloring.
The lower the timeframe you backtest on, the more backtesting data are effective.
Enjoy!
-- astropark
MACD Long StratFirst script I've written, but the concept is pretty simple. This uses the MACD with settings fast_SMA = 6 and slow SMA=16 and uses the distance between the 2 (histogram) to look for potential trend reversals to flag potential entries for Long trades. It waits for the confirmation looking backward 2 x timeframes (to reduce false calls slightly). You can adjust it to open / close quicker (1 timeframe instread of 2) but backtesting shows 2 timeframe delay is best to avoid false signals.
The script suggests Long entry points based on this criteria and uses the converse (reducing histogram / SMA difference delayed by 2 timeframes) to suggest exit or trade close points for downward reversal. It was originally written looking at 1m scalps but backtesting shows this is even more effective on higher timeframes (1D).
Delta-RSI Strategy (with filters)Delta-RSI Strategy (with filters):
This is a version of the Delta-RSI Oscillator strategy with several criteria available to filter entry and exit signals. This script is also suitable for backtesting over a user-defined period and offers several risk management options (take profit and stop loss).
Since the publication of the Delta-RSI Oscillator script, I have been asked many times to make it compatible with the Strategy Tester and add filtering criteria to minimize "false" signals. This version covers many of these requests. Feel free to insert your favorite D-RSI parameters and play around!
ABOUT DELTA-RSI
Delta-RSI represents a smoothed time derivative of the RSI designed as a momentum indicator (see links below):
INPUT DESCTIPTION
MODEL PARAMETERS
Polynomial Order : The order of local polynomial used to interpolate the relative strength index (RSI).
Length : The length of the lookback frame where local regression is applied.
RSI Length : The timeframe of RSI used as input.
Signal Length : The signal line is a EMA of the D-RSI time series. This input parameter defines the EMA length.
ALLOWED ENTRIES
The strategy can include long entries, short entries or both.
ENTRY AND EXIT CONDITIONS
Zero-crossing : bullish trade signal triggered when D-RSI crosses zero from negative to positive values (bearish otherwise)
Signal Line Crossing : bullish trade signal triggered when D-RSI crosses from below to above the signal line (bearish otherwise)
Direction Change : bullish trade signal triggered when D-RSI was negative and starts ascending (bearish otherwise)
APPLY FILTERS TO
The filters (described below) can be applied to long entry, short entry and exit signals.
RELATIVE VOLUME FILTER
When activated, the D-RSI-driven entries and exits will be triggered only if the current volume is greater than N times the average over the last M bars.
VOLATILITY FILTER
When activated, the D-RSI-driven entries and exits will be triggered only if the N-period average true range, ATR, is greater than the M-period ATR. If N < M, this condition implies increasing volatility.
OVERBOUGHT/OVERSOLD FILTER
When activated, the D-RSI-driven entries and exits will be triggered only if the value of 14-period RSI is in the range between N and M.
STOP LOSS/TAKE PROFIT
Fixed and trailing stop loss as well as take profit options are available.
FIXED BACKTESTING START/END DATES
If the checkboxes are not checked, the strategy will backtest all available price bars.
`security()` revisited [PineCoders]NOTE
The non-repainting technique in this publication that relies on bar states is now deprecated, as we have identified inconsistencies that undermine its credibility as a universal solution. The outputs that use the technique are still available for reference in this publication. However, we do not endorse its usage. See this publication for more information about the current best practices for requesting HTF data and why they work.
█ OVERVIEW
This script presents a new function to help coders use security() in both repainting and non-repainting modes. We revisit this often misunderstood and misused function, and explain its behavior in different contexts, in the hope of dispelling some of the coder lure surrounding it. The function is incredibly powerful, yet misused, it can become a dangerous WMD and an instrument of deception, for both coders and traders.
We will discuss:
• How to use our new `f_security()` function.
• The behavior of Pine code and security() on the three very different types of bars that make up any chart.
• Why what you see on a chart is a simulation, and should be taken with a grain of salt.
• Why we are presenting a new version of a function handling security() calls.
• Other topics of interest to coders using higher timeframe (HTF) data.
█ WARNING
We have tried to deliver a function that is simple to use and will, in non-repainting mode, produce reliable results for both experienced and novice coders. If you are a novice coder, stick to our recommendations to avoid getting into trouble, and DO NOT change our `f_security()` function when using it. Use `false` as the function's last argument and refrain from using your script at smaller timeframes than the chart's. To call our function to fetch a non-repainting value of close from the 1D timeframe, use:
f_security(_sym, _res, _src, _rep) => security(_sym, _res, _src )
previousDayClose = f_security(syminfo.tickerid, "D", close, false)
If that's all you're interested in, you are done.
If you choose to ignore our recommendation and use the function in repainting mode by changing the `false` in there for `true`, we sincerely hope you read the rest of our ramblings before you do so, to understand the consequences of your choice.
Let's now have a look at what security() is showing you. There is a lot to cover, so buckle up! But before we dig in, one last thing.
What is a chart?
A chart is a graphic representation of events that occur in markets. As any representation, it is not reality, but rather a model of reality. As Scott Page eloquently states in The Model Thinker : "All models are wrong; many are useful". Having in mind that both chart bars and plots on our charts are imperfect and incomplete renderings of what actually occurred in realtime markets puts us coders in a place from where we can better understand the nature of, and the causes underlying the inevitable compromises necessary to build the data series our code uses, and print chart bars.
Traders or coders complaining that charts do not reflect reality act like someone who would complain that the word "dog" is not a real dog. Let's recognize that we are dealing with models here, and try to understand them the best we can. Sure, models can be improved; TradingView is constantly improving the quality of the information displayed on charts, but charts nevertheless remain mere translations. Plots of data fetched through security() being modelized renderings of what occurs at higher timeframes, coders will build more useful and reliable tools for both themselves and traders if they endeavor to perfect their understanding of the abstractions they are working with. We hope this publication helps you in this pursuit.
█ FEATURES
This script's "Inputs" tab has four settings:
• Repaint : Determines whether the functions will use their repainting or non-repainting mode.
Note that the setting will not affect the behavior of the yellow plot, as it always repaints.
• Source : The source fetched by the security() calls.
• Timeframe : The timeframe used for the security() calls. If it is lower than the chart's timeframe, a warning appears.
• Show timeframe reminder : Displays a reminder of the timeframe after the last bar.
█ THE CHART
The chart shows two different pieces of information and we want to discuss other topics in this section, so we will be covering:
A — The type of chart bars we are looking at, indicated by the colored band at the top.
B — The plots resulting of calling security() with the close price in different ways.
C — Points of interest on the chart.
A — Chart bars
The colored band at the top shows the three types of bars that any chart on a live market will print. It is critical for coders to understand the important distinctions between each type of bar:
1 — Gray : Historical bars, which are bars that were already closed when the script was run on them.
2 — Red : Elapsed realtime bars, i.e., realtime bars that have run their course and closed.
The state of script calculations showing on those bars is that of the last time they were made, when the realtime bar closed.
3 — Green : The realtime bar. Only the rightmost bar on the chart can be the realtime bar at any given time, and only when the chart's market is active.
Refer to the Pine User Manual's Execution model page for a more detailed explanation of these types of bars.
B — Plots
The chart shows the result of letting our 5sec chart run for a few minutes with the following settings: "Repaint" = "On" (the default is "Off"), "Source" = `close` and "Timeframe" = 1min. The five lines plotted are the following. They have progressively thinner widths:
1 — Yellow : A normal, repainting security() call.
2 — Silver : Our recommended security() function.
3 — Fuchsia : Our recommended way of achieving the same result as our security() function, for cases when the source used is a function returning a tuple.
4 — White : The method we previously recommended in our MTF Selection Framework , which uses two distinct security() calls.
5 — Black : A lame attempt at fooling traders that MUST be avoided.
All lines except the first one in yellow will vary depending on the "Repaint" setting in the script's inputs. The first plot does not change because, contrary to all other plots, it contains no conditional code to adapt to repainting/no-repainting modes; it is a simple security() call showing its default behavior.
C — Points of interest on the chart
Historical bars do not show actual repainting behavior
To appreciate what a repainting security() call will plot in realtime, one must look at the realtime bar and at elapsed realtime bars, the bars where the top line is green or red on the chart at the top of this page. There you can see how the plots go up and down, following the close value of each successive chart bar making up a single bar of the higher timeframe. You would see the same behavior in "Replay" mode. In the realtime bar, the movement of repainting plots will vary with the source you are fetching: open will not move after a new timeframe opens, low and high will change when a new low or high are found, close will follow the last feed update. If you are fetching a value calculated by a function, it may also change on each update.
Now notice how different the plots are on historical bars. There, the plot shows the close of the previously completed timeframe for the whole duration of the current timeframe, until on its last bar the price updates to the current timeframe's close when it is confirmed (if the timeframe's last bar is missing, the plot will only update on the next timeframe's first bar). That last bar is the only one showing where the plot would end if that timeframe's bars had elapsed in realtime. If one doesn't understand this, one cannot properly visualize how his script will calculate in realtime when using repainting. Additionally, as published scripts typically show charts where the script has only run on historical bars, they are, in fact, misleading traders who will naturally assume the script will behave the same way on realtime bars.
Non-repainting plots are more accurate on historical bars
Now consider this chart, where we are using the same settings as on the chart used to publish this script, except that we have turned "Repainting" off this time:
The yellow line here is our reference, repainting line, so although repainting is turned off, it is still repainting, as expected. Because repainting is now off, however, plots on historical bars show the previous timeframe's close until the first bar of a new timeframe, at which point the plot updates. This correctly reflects the behavior of the script in the realtime bar, where because we are offsetting the series by one, we are always showing the previously calculated—and thus confirmed—higher timeframe value. This means that in realtime, we will only get the previous timeframe's values one bar after the timeframe's last bar has elapsed, at the open of the first bar of a new timeframe. Historical and elapsed realtime bars will not actually show this nuance because they reflect the state of calculations made on their close , but we can see the plot update on that bar nonetheless.
► This more accurate representation on historical bars of what will happen in the realtime bar is one of the two key reasons why using non-repainting data is preferable.
The other is that in realtime, your script will be using more reliable data and behave more consistently.
Misleading plots
Valiant attempts by coders to show non-repainting, higher timeframe data updating earlier than on our chart are futile. If updates occur one bar earlier because coders use the repainting version of the function, then so be it, but they must then also accept that their historical bars are not displaying information that is as accurate. Not informing script users of this is to mislead them. Coders should also be aware that if they choose to use repainting data in realtime, they are sacrificing reliability to speed and may be running a strategy that behaves very differently from the one they backtested, thus invalidating their tests.
When, however, coders make what are supposed to be non-repainting plots plot artificially early on historical bars, as in examples "c4" and "c5" of our script, they would want us to believe they have achieved the miracle of time travel. Our understanding of the current state of science dictates that for now, this is impossible. Using such techniques in scripts is plainly misleading, and public scripts using them will be moderated. We are coding trading tools here—not video games. Elementary ethics prescribe that we should not mislead traders, even if it means not being able to show sexy plots. As the great Feynman said: You should not fool the layman when you're talking as a scientist.
You can readily appreciate the fantasy plot of "c4", the thinnest line in black, by comparing its supposedly non-repainting behavior between historical bars and realtime bars. After updating—by miracle—as early as the wide yellow line that is repainting, it suddenly moves in a more realistic place when the script is running in realtime, in synch with our non-repainting lines. The "c5" version does not plot on the chart, but it displays in the Data Window. It is even worse than "c4" in that it also updates magically early on historical bars, but goes on to evaluate like the repainting yellow line in realtime, except one bar late.
Data Window
The Data Window shows the values of the chart's plots, then the values of both the inside and outside offsets used in our calculations, so you can see them change bar by bar. Notice their differences between historical and elapsed realtime bars, and the realtime bar itself. If you do not know about the Data Window, have a look at this essential tool for Pine coders in the Pine User Manual's page on Debugging . The conditional expressions used to calculate the offsets may seem tortuous but their objective is quite simple. When repainting is on, we use this form, so with no offset on all bars:
security(ticker, i_timeframe, i_source )
// which is equivalent to:
security(ticker, i_timeframe, i_source)
When repainting is off, we use two different and inverted offsets on historical bars and the realtime bar:
// Historical bars:
security(ticker, i_timeframe, i_source )
// Realtime bar (and thus, elapsed realtime bars):
security(ticker, i_timeframe, i_source )
The offsets in the first line show how we prevent repainting on historical bars without the need for the `lookahead` parameter. We use the value of the function call on the chart's previous bar. Since values between the repainting and non-repainting versions only differ on the timeframe's last bar, we can use the previous value so that the update only occurs on the timeframe's first bar, as it will in realtime when not repainting.
In the realtime bar, we use the second call, where the offsets are inverted. This is because if we used the first call in realtime, we would be fetching the value of the repainting function on the previous bar, so the close of the last bar. What we want, instead, is the data from the previous, higher timeframe bar , which has elapsed and is confirmed, and thus will not change throughout realtime bars, except on the first constituent chart bar belonging to a new higher timeframe.
After the offsets, the Data Window shows values for the `barstate.*` variables we use in our calculations.
█ NOTES
Why are we revisiting security() ?
For four reasons:
1 — We were seeing coders misuse our `f_secureSecurity()` function presented in How to avoid repainting when using security() .
Some novice coders were modifying the offset used with the history-referencing operator in the function, making it zero instead of one,
which to our horror, caused look-ahead bias when used with `lookahead = barmerge.lookahead_on`.
We wanted to present a safer function which avoids introducing the dreaded "lookahead" in the scripts of unsuspecting coders.
2 — The popularity of security() in screener-type scripts where coders need to use the full 40 calls allowed per script made us want to propose
a solid method of allowing coders to offer a repainting/no-repainting choice to their script users with only one security() call.
3 — We wanted to explain why some alternatives we see circulating are inadequate and produce misleading behavior.
4 — Our previous publication on security() focused on how to avoid repainting, yet many other considerations worthy of attention are not related to repainting.
Handling tuples
When sending function calls that return tuples with security() , our `f_security()` function will not work because Pine does not allow us to use the history-referencing operator with tuple return values. The solution is to integrate the inside offset to your function's arguments, use it to offset the results the function is returning, and then add the outside offset in a reassignment of the tuple variables, after security() returns its values to the script, as we do in our "c2" example.
Does it repaint?
We're pretty sure Wilder was not asked very often if RSI repainted. Why? Because it wasn't in fashion—and largely unnecessary—to ask that sort of question in the 80's. Many traders back then used daily charts only, and indicator values were calculated at the day's close, so everybody knew what they were getting. Additionally, indicator values were calculated by generally reputable outfits or traders themselves, so data was pretty reliable. Today, almost anybody can write a simple indicator, and the programming languages used to write them are complex enough for some coders lacking the caution, know-how or ethics of the best professional coders, to get in over their heads and produce code that does not work the way they think it does.
As we hope to have clearly demonstrated, traders do have legitimate cause to ask if MTF scripts repaint or not when authors do not specify it in their script's description.
► We recommend that authors always use our `f_security()` with `false` as the last argument to avoid repainting when fetching data dependent on OHLCV information. This is the only way to obtain reliable HTF data. If you want to offer users a choice, make non-repainting mode the default, so that if users choose repainting, it will be their responsibility. Non-repainting security() calls are also the only way for scripts to show historical behavior that matches the script's realtime behavior, so you are not misleading traders. Additionally, non-repainting HTF data is the only way that non-repainting alerts can be configured on MTF scripts, as users of MTF scripts cannot prevent their alerts from repainting by simply configuring them to trigger on the bar's close.
Data feeds
A chart at one timeframe is made up of multiple feeds that mesh seamlessly to form one chart. Historical bars can use one feed, and the realtime bar another, which brokers/exchanges can sometimes update retroactively so that elapsed realtime bars will reappear with very slight modifications when the browser's tab is refreshed. Intraday and daily chart prices also very often originate from different feeds supplied by brokers/exchanges. That is why security() calls at higher timeframes may be using a completely different feed than the chart, and explains why the daily high value, for example, can vary between timeframes. Volume information can also vary considerably between intraday and daily feeds in markets like stocks, because more volume information becomes available at the end of day. It is thus expected behavior—and not a bug—to see data variations between timeframes.
Another point to keep in mind concerning feeds it that when you are using a repainting security() plot in realtime, you will sometimes see discrepancies between its plot and the realtime bars. An artefact revealing these inconsistencies can be seen when security() plots sometimes skip a realtime chart bar during periods of high market activity. This occurs because of races between the chart and the security() feeds, which are being monitored by independent, concurrent processes. A blue arrow on the chart indicates such an occurrence. This is another cause of repainting, where realtime bar-building logic can produce different outcomes on one closing price. It is also another argument supporting our recommendation to use non-repainting data.
Alternatives
There is an alternative to using security() in some conditions. If all you need are OHLC prices of a higher timeframe, you can use a technique like the one Duyck demonstrates in his security free MTF example - JD script. It has the great advantage of displaying actual repainting values on historical bars, which mimic the code's behavior in the realtime bar—or at least on elapsed realtime bars, contrary to a repainting security() plot. It has the disadvantage of using the current chart's TF data feed prices, whereas higher timeframe data feeds may contain different and more reliable prices when they are compiled at the end of the day. In its current state, it also does not allow for a repainting/no-repainting choice.
When `lookahead` is useful
When retrieving non-price data, or in special cases, for experiments, it can be useful to use `lookahead`. One example is our Backtesting on Non-Standard Charts: Caution! script where we are fetching prices of standard chart bars from non-standard charts.
Warning users
Normal use of security() dictates that it only be used at timeframes equal to or higher than the chart's. To prevent users from inadvertently using your script in contexts where it will not produce expected behavior, it is good practice to warn them when their chart is on a higher timeframe than the one in the script's "Timeframe" field. Our `f_tfReminderAndErrorCheck()` function in this script does that. It can also print a reminder of the higher timeframe. It uses one security() call.
Intrabar timeframes
security() is not supported by TradingView when used with timeframes lower than the chart's. While it is still possible to use security() at intrabar timeframes, it then behaves differently. If no care is taken to send a function specifically written to handle the successive intrabars, security() will return the value of the last intrabar in the chart's timeframe, so the last 1H bar in the current 1D bar, if called at "60" from a "D" chart timeframe. If you are an advanced coder, see our FAQ entry on the techniques involved in processing intrabar timeframes. Using intrabar timeframes comes with important limitations, which you must understand and explain to traders if you choose to make scripts using the technique available to others. Special care should also be taken to thoroughly test this type of script. Novice coders should refrain from getting involved in this.
█ TERMINOLOGY
Timeframe
Timeframe , interval and resolution are all being used to name the concept of timeframe. We have, in the past, used "timeframe" and "resolution" more or less interchangeably. Recently, members from the Pine and PineCoders team have decided to settle on "timeframe", so from hereon we will be sticking to that term.
Multi-timeframe (MTF)
Some coders use "multi-timeframe" or "MTF" to name what are in fact "multi-period" calculations, as when they use MAs of progressively longer periods. We consider that a misleading use of "multi-timeframe", which should be reserved for code using calculations actually made from another timeframe's context and using security() , safe for scripts like Duyck's one mentioned earlier, or TradingView's Relative Volume at Time , which use a user-selected timeframe as an anchor to reset calculations. Calculations made at the chart's timeframe by varying the period of MAs or other rolling window calculations should be called "multi-period", and "MTF-anchored" could be used for scripts that reset calculations on timeframe boundaries.
Colophon
Our script was written using the PineCoders Coding Conventions for Pine .
The description was formatted using the techniques explained in the How We Write and Format Script Descriptions PineCoders publication.
Snippets were lifted from our MTF Selection Framework , then massaged to create the `f_tfReminderAndErrorCheck()` function.
█ THANKS
Thanks to apozdnyakov for his help with the innards of security() .
Thanks to bmistiaen for proofreading our description.
Look first. Then leap.
ProjectionGreetings Traders! I have decided to release a few scripts as open-source as I'm sure others can benefit from them and perhaps make them better.(Be sure to check my Profile for the other scripts as well: www.tradingview.com).
This one is called Projection.
Projection is based off the same Principle as some of my other scripts, such as Trade Manager() and Price Predictor(). I use a simple concept using line.new() to define some potential Price Projections. From the Settings of the Indicator, you can access a couple different Pre-Set options.
Wide Parabola:
Skinny Parabola:
Straight Triangle:
ZigZag1:
ZigZag2:
I wanted to give a Special Thanks to @Pinecoders for the custom RoundToTick Function from Backtesting/Trading Engine --> ()
If you like Projection, be sure to Like, Follow, and if you have any questions, don't be afraid to drop a comment below.
User-Inputed Time Range & FibsGreetings Traders! I have decided to release a few scripts as open-source as I'm sure others can benefit from them and perhaps make them better.(Be sure to check my Profile for the other scripts as well: www.tradingview.com).
This one is called User-Inputed Time Range & Fibs.
The idea behind this script is to record the Range Highs and Lows of a User Defined Period, and plot potential Targets based on either Fibonacci Extensions or a Multiple of the Range Size. I created this originally for use with the US Session Initial Balance(From 9:30-10:30AM EST), however it can be set to any time period.
What is Initial Balance? In simple words, Initial Balance (IB) is the price data, which are formed during the first hour of a trading session. Activity of traders forms the so-called Initial Balance at this time. This concept was introduced for the first time by Peter Steidlmayer when he presented the market profile to traders(atas.net).
The IB is monitored as a break-out area for Range Extension traders. The IB High is also seen as an area of resistance and the IB Low as an area of support until it is broken(www.mypivots.com).
As a note, depending on the Time Zone you are in, you may need to manually add or subtract from the Timed Range to match the desired Time. For example in NY Eastern Time, I have to use 8:30-9:30AM to Capture the 9:30-10-30AM IB for ES and NQ. Similarly, I must use 14:30-15:30PM to Capture the 9:30-10-30AM IB for BTC. You will need to make adjustments based on the Time Zone you are located in.
I wanted to give a Special Thanks to @PineCoders for the Custom Rounding Function from Backtesting/Trading Engine--> (), Pinecoders.com for help with Tracking the Highs/Lows--> (www.pinecoders.com), and @TradeChartist for allowing me to use some of the code for the Fibonacci Extensions from his script here--> ().
If you like User-Inputed Time Range & Fibs, be sure to Like, Follow, and if you have any questions, don't be afraid to drop a comment below.
Price PredictorGreetings Traders! I have decided to release a few scripts as open-source as I'm sure others can benefit from them and perhaps make them better.(Be sure to check my Profile for the other scripts as well: www.tradingview.com).
This one is called Price Predictor.
How To Use Price Predictor
Price Predictor acquires potential targets by measuring the Average Change of Price from a user-defined resolution, from Open to Open. By default, the Resolution is set to 1 Day, however you can play around with Weekly, Monthly, etc. When a new resolution period begins, Price Predictor will automatically adjust based on the new Average Change of Price.
Due to the avoidance of Security() in this script, you may have to play around with the Timeframe that you use it in to ensure that you have enough bars on your chart to process the User-Defined Resolution.
The first Target Zone represents Target 5 of my other script, Trade Manager()(Given that you set the Target Multiple and Default Threshold Inputs as the same in each script), and is the most likely to be hit before the end of the resolution period.
In addition to a User-Defined Resolution, you also have the option of using a Custom Price to define Target Zones, however I'd recommend using my other script, Trade Manager(), if the volatility of the Instrument isn't too high.
I wanted to give a Special Thanks to @Pinecoders for the Custom RoundToTick Function from The Backtesting/Trading Engine --> (
If you like Price Predictor, be sure to Like, Follow, and if you have any questions, don't be afraid to drop a comment below.
Trade ManagerGreetings Traders! I have decided to release a few scripts as open-source as I'm sure others can benefit from them and perhaps make them better.(Be sure to check my Profile for the other scripts as well: www.tradingview.com).
This one is called Trade Manager.
How To Use Trade Manager
Trade Manager acquires potential targets by measuring the Average Change of Price from a user-defined resolution, from Open to Open. By default, the Resolution is set to 1 Day, however you can play around with Weekly, Monthly, etc. When a new resolution period begins, Trade Manager will automatically adjust its Targets based on the new Average Change of Price.
Due to the avoidance of Security() in this script, you may have to play around with the Timeframe that you use it in to ensure that you have enough bars on your chart to process the User-Defined Resolution.
The idea behind Trade Manager is quite simple yet can be quite powerful at the same time. Consider a Daily Candle for example. You can clearly see how a vast amount of price movement can be encapsulated within it, sometimes in both directions. By measuring the Average Change of Price per day(From Open to Open), we can use this Average to build targets off of. Defining a small Threshold above and below the Open Price of the Daily Candle allows you to set Limit Orders at these levels with predefined Targets. Then, the use of the custom Trailing Stop and Break Even helps to secure profits without giving too much back to the market, all while managing your risk.
Within the Settings of Trade Manager, you have the option to alter the logic of whether Break-Even is set after the first Target or second Target is hit.
In addition to using a User-Defined Resolution Period, you can also input a Custom Price into the settings of Trade Manager and allow the Targets, Trailing Stop, and Break Even to be calculated from the Custom Price.
I wanted to give a Special Thanks to @PineCoders for the Custom RoundToTick Function from The Backtesting/Trading Engine --> ()
As a note, there are times where price will break out very strongly from the Limit Price, sometimes crossing the Stop and Limit Price on the same bar. When this happens, it is difficult for Pine to determine which occurred first intra-bar, and as a result, it does not record a new position. In these instances, I'd recommend adjusting the Default Stop Multiple so it is below the bar.
If you like Trade Manager, be sure to Like, Follow, and if you have any questions, don't be afraid to drop a comment below.
Ichimoku systemThis script is to get backtesting results of ichimoku Cloud system .
>> tick buying only to watch backtesting results of buying trades ony other wise untick to see both buy and sell trade results (for intraday timeframe)
Tell me if you have any suggestions u i will try to include them in coming updates
Pivot Point SuperTrend [Backtest]Hello All,
This is backtesting result of following indicator/strategy. I didn't work on adding other indicators. maybe in the future I can try to combine this with other indicators.
You can visit following link to see "Pivot Point SuperTrend" . by using this backtesting tool, you can test&find better options
There is option "Use Center Line to Close Entry for 50%" . by default it's not enabled. if you enable this option, pivot point center line may push you to close your entry for 50% (can be used as early stoploss/take profit line if you think it's risky)
Enjoy!
Stochastic Pop and Drop by Jake Bernstein v1 [Bitduke]I found a simple strategy by Jake Bernstein, modified it a little and created a strategy with Risk Management System (SL+TP); After that I test it on the different cryptocurrency pairs.
About the Indicator
Basically it's the strategy of 2 indicators: Stochastic Oscillator to define the bias and Average Directional Index to confirm it.
One again, It uses Stochastic Oscillator to define the trading bias. In particular, the trading bias was deemed bullish when the weekly 14-period Stochastic Oscillator was above some default value (in him paper - 50) and rising and vice versa.
Once the trading bias is established, Steckler used the Average Directional Index (ADX) to define a slowdown in the trend. ADX measures the strength of the trend and a move below 20 signals a weak trend.
Modifications
I didn't implement Average Directional Index (ADX) and test just different sources for data, oscillator periods and different levels in relation to the crypto market.
So, it shows good results with two tight thresholds at 55 and 45 level.
The bar chart below the defining the bullish and bearish periods (green and red) and gives a signal to enter the trade (purple bars).
Backtesting
Backtested on XBTUSD , BTCPERP (FTX) pairs. You may notice it shows good results on 3h timeframe.
Relatively low drawdown
~ 10% (from 2019 to date) FTX
~ 22% (4 years from 2016) Bitmex
I backtested on the different altcoin pairs as well, but the results were just not good.
Relatively good results were shown by some index pairs from the FTX exchange ( FTX:SHITPERP ), but I think there is a few data for backtesting to be asure in them.
Bitmex 3h (2017 - 2020) :
i.imgur.com
FTX 3h (2019 - 2020):
i.imgur.com
Possible Improvements
- Regarding trading algorithm it would be good to check with strategy with ADX somehow. Maybe for the better entries
- As for Risk Management system, it can be improved by adding trailing stop to the strategy.
Link: school.stockcharts.com
NoNonsense Forex - high timeframe trading absurd NON-REPAINTINGSome time ago I bumped into NoNonsense Forex - pretty good-looking course with well-designed videos, reasonable rules, etc. Nice explanatory videos, not selling anything, building indicators-only strategy. But there was one thing that really annoyed me - it was supposed to work only on Daily timeframe. What is the point in trading such high timeframe, if decisions changing market direction are playing out within 1 minute? What is the point in evaluating trades from 1994 if we are 25 years later?
Anyway, I have developed this strategy, which is:
- non-repainting
- not using trailing-stop
- not using any other known TradingView backtest bugs
And I'm showing it as an example of OVERFITTING. Backtesting results look absurd: 100% profitable. But if you change any of the many parameters in the Settings popup, they will turn into disaster. It means, the rules of this strategy are very fragile. Don't trade this! Remember about backtesting rule #1: past results do not guarantee success in the future.
I'm giving this strategy out with the source code. Feel free to do anything you want with it. But if you find parameters or modifications on, which allow profitable trading on lower timeframes, don't be shy, let me know :)
*********
Forex / Indices / Commodities traders who want to start AUTO-TRADING might want to take a look at "TradingConnector", which allows no-latency trades execution from TradingView to MT4/MT5.
Visual RSI [LucF]Visual RSI offers a different way of looking at RSI by providing a composite representation of 9 different RSI-generated components. Instead of focusing on one line only, this approach blends multiple sources to provide the viewer with a larger context RSI-based picture.
For those who don’t want to read
• Green in bullish (>50) zone is the most bullish.
• Red in bullish zone doesn’t necessarily mean bearish—it just means bullish strength is weakening. It may be just a pause before a reprise or exhaustion signalling a reversal—impossible to tell.
• The same in inverse applies to the bearish zone (<50).
For those who want to understand
The nine components making up Visual RSI are:
• a current timeframe RSI
• a higher timeframe RSI
• the delta between these two RSI lines
• for each of these three basic components, two independent Bollinger band: one calculated for the bullish section of the scale (>50) and a separate one calculated for the lower bearish region.
Dual BBs
In my view, RSI’s position with regards to the centerline is much more important than its position in extreme areas. Why? Because the building block of RSI is the ratio of the averages of up/down moves during the RSI period. When the average of ups is greater, RSI is > 50. So while a rising signal starting from 20 let’s say, indicates that the rate of change is increasing, only when it crosses 50 can we say that sentiment balance has truly become bullish, and this information is more reliable than the signal being at a level corresponding to whatever estimate we make of what constitutes an extreme value. In my landscape, the general balance of a ratio provides more valuable information than the ratio’s exact value.
The idea behind the dual BBs is to provide independent tracking information for both halves of the indicator’s space, which I find more useful than the normal method of simply adding a multiple of the standard deviation on both sides of the mean. With dual BBs, the upper BB will never go lower than the indicator’s centerline, and the lower BB will never go higher. The upper BB focuses on upper-bound volatility when the signal is bearish, and the lower BB focuses on downside volatility when the signal is bearish.
The functions used to calculate the independent BBs are reusable on other signals if a centerline can be defined for them. A clamping percentage is implemented, so that when a BB line is hugging the centerline it clamps to it. This helps in providing earlier signals when they use the BB line states.
Providing context to RSI
What RSI measures indirectly is the balance in the rate of change—or the speed of price movement, but not its instant value, otherwise RSI would be even noisier. More precisely, RSI represents the relative strength of the up/down movement in the last n bars of RSI’s length, with 14 often used because that’s what Wilder proposed (Visual RSI’s defaults are 20 for the current timeframe and 40 for the higher timeframe). At every bar, a new value is added to the equation and an old value carrying equal weight is dropped, so a large dropped off value will have more impact on RSI’s value if the new bar’s move is small. This accounts for some of RSI’s speed in identifying exhaustion after important moves, but almost for some of its noise.
Visual RSI is the result of trying to drown RSI’s noise in the context of other informational streams, while simultaneously providing even faster information than RSI alone, by giving more visual weight to the delta between the current and higher timeframe RSI’s.
How to read Visual RSI
The default settings show all 9 basic components as green/red areas of intensities varying with their importance. The most intense colors are reserved for the delta RSI and the BBs have the lightest intensities. The individual lines of components are intentionally difficult to distinguish so that focus is first on the general picture, including the all-important six-state background, and then on the delta RSI.
One entry setup could be reversals in a larger trend context, so low pivots of the delta in a fully bullish context (a green background in the upper section of the indicator), and inversely, high pivots in a fully bearish context (a red background in the lower section of the indicator).
Please resist the common misconception, when interpreting RSI, that a reversal in the signal will necessarily lead to a reversal in price. Each trend has its rhythm. Only machine-generated price action can progress regularly. It’s normal for trends to take a breather for some time before they continue or reverse, as traders driving the trend experience emotional fatigue and gradual fear. RSI reversals merely signify that such a breather has occurred—nothing more. Only the larger context can provide information that can situate that pause and put more meaningful odds on it having more probability of continuing in one direction or the other. This is the reasoning behind the setup just described.
Features
• All components can be hidden, displayed as a simple line, a uniformly colored fill, or a green/red fill (the default).
• The background can be colored using 9 different methods, including 3 six-state methods using the rising/falling BB lines of the 3 basic components. These six states allow for bullish/bearish/neutral sentiment in both the upper and lower regions of the indicator. A bearish (dark red) background in the bullish (>50) section of the indicator represents decreasing bullishness. A bearish (slightly brighter red) in the bearish (<50) section of the indicator means incresingly bearish sentiment. The six-state backgrounds allow for neutral (no color) sentiment when no compelling signs can be found to conclude anything with meaningful odds. The default background uses the six-state method on the higher timeframe RSI’s BBs because I find it the most useful, as it represents the largest—and slowest—context sentiment among all the indicator’s components.
• A thin status bar in the top part of the indicator also allows selection of the same 9 methods to color it. The default is a triple-state system using the rising/falling characteristics of the current timeframe RSI’s BBs to provide a short-term counterbalance to the long-term background.
• Three different markers can be configured using approximately 70 permutations each, each filtered by 20 different filter permutations. When modification of the relevant parameters in the script’s Settings/Settings/Parameters section is added, possibilities are almost endless. If the generated signals are then fed into the PineCoders Engine and combined with the Engine’s own options, the permutations go up another order of magnitude, and changes to any setting can be instantly evaluated using the Engine’s backtesting results.
• Five simple filters can be combined. They are additive. They include volume-related conditions and a chandelier, which I find useful because both volume and volatility (the chandelier using highs/lows and ATR) are sensible complementary sources to RSI’s momentum information. The filter’s state can be shown as a thin line at the bottom of the indicator.
• Alerts can be configured using any of the marker/filter combinations mentioned. As usual, once your markers/filters are set up the way you want, create your alert from the chart/timeframe you want the alert to run on and be sure to use the “Once Per Bar Close” triggering condition. Use an alert message that will remind you of which combination of markers were used when creating the alert.
• A plot providing entry signals for the PineCoders Backtesting & Trading Engine is supplied. It will use whichever marker/filter configuration is active to generate signals.
• All higher timeframe information is non-repainting. Higher timeframe lines can be smoothed (the default). The selection of the higher timeframe can be made using 3 different methods:
1. By steps (if current timeframe <= 1 minute: 60 min, <= 60 min: 1D, <= 6H: 3D, <= 1D: 1W, <=1W: 1M, >1W: 12M)
2. By a user-defined multiple of the current timeframe
3. Using a fixed timeframe
Thanks to:
• Alex Orekhov aka @everget for the chandelier code.
• @RicardoSantos who through a small remark early on, unknowingly put me on the track of eliminating noise through visual crowding.
• The brilliant guys in the PineCoders Pro room for your knowledge, limitless creativity and constant companionship.
WOW no repainting and no security() call! 100% real results!If you couldn't tell by the title, this is a joke lmao.
TV has an awful backtesting engine and I just wanted to prove this with a super simple script.
We buy when close > open
and sell when close < open.
That's it.
There is also some risk management and trade closing when we reach a certain drawdown, but wait!
TradingView doesn't know what equity drawdown is because they don't use tick data or any lower timeframe data! Wowow!
Ps - all tickdata for Forex & CFD historical data is free from Dukascopy if you want to perform your own backtesting ;)
Dukascopy Data
Enjoy
-DasanC
