ChikouLibrary "Chikou"
This library contains Chikou Filter function to enhances functionality of Chikou-Span from Ichimoku Cloud using a simple trend filter.
Chikou is basically close value of ticker offset to close and it is a good for indicating if close value has crossed potential Support/Resistance zone from past. Chikou is usually used with 26 period.
Chikou filter uses a lookback length calculated from provided lookback percentage and checks if trend was bullish or bearish within that lookback period.
Bullish : Trend is bullish if Chikou span is above high values of all candles within defined lookback period. Bull color shows bullish trend .
Bearish : Trend is bearish if Chikou span is below low values of all candles within defined lookback period. This is indicated by Bearish color.
Reversal / Choppiness : Reversal color indicates that Chikou are swinging around candles within defined lookback period which is an indication of consolidation or trend reversal.
chikou(src, len, perc, _high, _low, bull_col, bear_col, r_col) Chikou Filter for Ichimoku Cloud with Color and Signal Output
Parameters:
src : Price Source (better to use (OHLC4+high+low/3 instead of default close value)
len : Chikou Legth (displaced source value)
perc : Percentage lookback period for Chikou Filter with defined how much candels of total length should be considered for backward filteration
_high : Ticker High Value
_low : Ticker Low Value
bull_col : Color to be returned if source value is greater than all candels within provided lookback percentage.
bear_col : Color to be returned if source value is lower than all candels within provided lookback percentage.
r_col : Color to be returned if source value is swinging around candles within defined lookback period which is an indication of consolidation or trend reversal.
Returns: Color based on trend. 'bull_col' if trend is bullish, 'bear_col' if trend is bearish. 'r_col' if no prominent trend. Integer Signal is also returned as 1 for Bullish, -1 for Bearish and 0 for no prominent trend.
"文华财经tick价格"に関するスクリプトを検索
TS_FFALibrary "TS_FFA"
Splits the ticker and generates best configs for FP and PP
splitter(x) Splits the ticker and found the configuration regarding to name.
Parameters:
_x: ticker
Returns: Fib and Profit percent values
- Splitter had been added.
- USDTPERP coins on Binance had been added
- timeFrameMultiplier() timeframe multiplier had been added to the library
- timeframe period value fixed
- Changed timezone multiplier
- Changed VWMA Percent values
Relative Strength Screener V2 - Top 100 volume leadersNew and improved strength heatmap for the top 100 volume leaders in the S&P. Coded in a workaround to the 40 request.security limitation that currently exists in Pine. Added the ability to input the number of columns (time frames) you wish to display.
For 3 time frame analysis, add the indicator to your chart 3 times. Change the number of columns to 3 for each of these indicators. Specify the column and time frame for each one (example, 5 minute for column 1, 1 hour for column 2 and Daily chart for column 3). It will automatically resize the columns/tables to properly display the output. This provides a sort of "Strength Heatmap" for the top 100 stocks in the S&P. To achieve this, make a copy of the indicator and substitute lines 68-105 with the following premade watchlists :
Make a copy 1 - FIrst 38 volume leaders in the S&P
s01 = input.symbol('AAPL', group = 'Symbols', inline = 's01')
s02 = input.symbol('ABBV', group = 'Symbols', inline = 's02')
s03 = input.symbol('ABT', group = 'Symbols', inline = 's03')
s04 = input.symbol('ACN', group = 'Symbols', inline = 's04')
s05 = input.symbol('AEP', group = 'Symbols', inline = 's05')
s06 = input.symbol('AIG', group = 'Symbols', inline = 's06')
s07 = input.symbol('AMAT', group = 'Symbols', inline = 's07')
s08 = input.symbol('AMD', group = 'Symbols', inline = 's08')
s09 = input.symbol('APA', group = 'Symbols', inline = 's09')
s10 = input.symbol('ATVI', group = 'Symbols', inline = 's10')
s11 = input.symbol('AXP', group = 'Symbols', inline = 's11')
s12 = input.symbol('BA', group = 'Symbols', inline = 's12')
s13 = input.symbol('BBWI', group = 'Symbols', inline = 's13')
s14 = input.symbol('BBY', group = 'Symbols', inline = 's14')
s15 = input.symbol('BK', group = 'Symbols', inline = 's15')
s16 = input.symbol('BMY', group = 'Symbols', inline = 's16')
s17 = input.symbol('BRK.B', group = 'Symbols', inline = 's17')
s18 = input.symbol('C', group = 'Symbols', inline = 's18')
s19 = input.symbol('CAT', group = 'Symbols', inline = 's19')
s20 = input.symbol('CCL', group = 'Symbols', inline = 's20')
s21 = input.symbol('CFG', group = 'Symbols', inline = 's21')
s22 = input.symbol('CL', group = 'Symbols', inline = 's22')
s23 = input.symbol('CNC', group = 'Symbols', inline = 's23')
s24 = input.symbol('COF', group = 'Symbols', inline = 's24')
s25 = input.symbol('COP', group = 'Symbols', inline = 's25')
s26 = input.symbol('COST', group = 'Symbols', inline = 's26')
s27 = input.symbol('CRM', group = 'Symbols', inline = 's27')
s28 = input.symbol('CVS', group = 'Symbols', inline = 's28')
s29 = input.symbol('CVX', group = 'Symbols', inline = 's29')
s30 = input.symbol('DAL', group = 'Symbols', inline = 's30')
s31 = input.symbol('DIS', group = 'Symbols', inline = 's31')
s32 = input.symbol('DISCA', group = 'Symbols', inline = 's32')
s33 = input.symbol('DISCK', group = 'Symbols', inline = 's33')
s34 = input.symbol('DISH', group = 'Symbols', inline = 's34')
s35 = input.symbol('DLTR', group = 'Symbols', inline = 's35')
s36 = input.symbol('DOW', group = 'Symbols', inline = 's36')
s37 = input.symbol('DVN', group = 'Symbols', inline = 's37')
s38 = input.symbol('EBAY', group = 'Symbols', inline = 's38')
Make a copy 2 - Tickers 39 to 76
s01 = input.symbol('EOG', group = 'Symbols', inline = 's01')
s02 = input.symbol('F', group = 'Symbols', inline = 's02')
s03 = input.symbol('FB', group = 'Symbols', inline = 's03')
s04 = input.symbol('FCX', group = 'Symbols', inline = 's04')
s05 = input.symbol('FIS', group = 'Symbols', inline = 's05')
s06 = input.symbol('GE', group = 'Symbols', inline = 's06')
s07 = input.symbol('GIS', group = 'Symbols', inline = 's07')
s08 = input.symbol('GM', group = 'Symbols', inline = 's08')
s09 = input.symbol('GS', group = 'Symbols', inline = 's09')
s10 = input.symbol('HD', group = 'Symbols', inline = 's10')
s11 = input.symbol('IBM', group = 'Symbols', inline = 's11')
s12 = input.symbol('INTC', group = 'Symbols', inline = 's12')
s13 = input.symbol('JNJ', group = 'Symbols', inline = 's13')
s14 = input.symbol('JPM', group = 'Symbols', inline = 's14')
s15 = input.symbol('KR', group = 'Symbols', inline = 's15')
s16 = input.symbol('LUV', group = 'Symbols', inline = 's16')
s17 = input.symbol('LVS', group = 'Symbols', inline = 's17')
s18 = input.symbol('MA', group = 'Symbols', inline = 's18')
s19 = input.symbol('MCD', group = 'Symbols', inline = 's19')
s20 = input.symbol('MCHP', group = 'Symbols', inline = 's20')
s21 = input.symbol('MDT', group = 'Symbols', inline = 's21')
s22 = input.symbol('MET', group = 'Symbols', inline = 's22')
s23 = input.symbol('MGM', group = 'Symbols', inline = 's23')
s24 = input.symbol('MOS', group = 'Symbols', inline = 's24')
s25 = input.symbol('MPC', group = 'Symbols', inline = 's25')
s26 = input.symbol('MRK', group = 'Symbols', inline = 's26')
s27 = input.symbol('MRNA', group = 'Symbols', inline = 's27')
s28 = input.symbol('MS', group = 'Symbols', inline = 's28')
s29 = input.symbol('MSFT', group = 'Symbols', inline = 's29')
s30 = input.symbol('MU', group = 'Symbols', inline = 's30')
s31 = input.symbol('NCLH', group = 'Symbols', inline = 's31')
s32 = input.symbol('NEE', group = 'Symbols', inline = 's32')
s33 = input.symbol('NEM', group = 'Symbols', inline = 's33')
s34 = input.symbol('NFLX', group = 'Symbols', inline = 's34')
s35 = input.symbol('NKE', group = 'Symbols', inline = 's35')
s36 = input.symbol('NVDA', group = 'Symbols', inline = 's36')
s37 = input.symbol('ORCL', group = 'Symbols', inline = 's37')
s38 = input.symbol('OXY', group = 'Symbols', inline = 's38')
Make a copy 3 - tickers 77 to 114
s01 = input.symbol('PENN', group = 'Symbols', inline = 's01')
s02 = input.symbol('PEP', group = 'Symbols', inline = 's02')
s03 = input.symbol('PFE', group = 'Symbols', inline = 's03')
s04 = input.symbol('PG', group = 'Symbols', inline = 's04')
s05 = input.symbol('PM', group = 'Symbols', inline = 's05')
s06 = input.symbol('PYPL', group = 'Symbols', inline = 's06')
s07 = input.symbol('QCOM', group = 'Symbols', inline = 's07')
s08 = input.symbol('RTX', group = 'Symbols', inline = 's08')
s09 = input.symbol('SBUX', group = 'Symbols', inline = 's09')
s10 = input.symbol('SCHW', group = 'Symbols', inline = 's10')
s11 = input.symbol('SLB', group = 'Symbols', inline = 's11')
s12 = input.symbol('SYF', group = 'Symbols', inline = 's12')
s13 = input.symbol('T', group = 'Symbols', inline = 's13')
s14 = input.symbol('TFC', group = 'Symbols', inline = 's14')
s15 = input.symbol('TGT', group = 'Symbols', inline = 's15')
s16 = input.symbol('TJX', group = 'Symbols', inline = 's16')
s17 = input.symbol('TMUS', group = 'Symbols', inline = 's17')
s18 = input.symbol('TSLA', group = 'Symbols', inline = 's18')
s19 = input.symbol('TWTR', group = 'Symbols', inline = 's19')
s20 = input.symbol('TXN', group = 'Symbols', inline = 's20')
s21 = input.symbol('UAL', group = 'Symbols', inline = 's21')
s22 = input.symbol('UNH', group = 'Symbols', inline = 's22')
s23 = input.symbol('V', group = 'Symbols', inline = 's23')
s24 = input.symbol('VIAC', group = 'Symbols', inline = 's24')
s25 = input.symbol('WBA', group = 'Symbols', inline = 's25')
s26 = input.symbol('WFC', group = 'Symbols', inline = 's26')
s27 = input.symbol('WMT', group = 'Symbols', inline = 's27')
s28 = input.symbol('WYNN', group = 'Symbols', inline = 's28')
s29 = input.symbol('XOM', group = 'Symbols', inline = 's29')
s30 = input.symbol('SPY', group = 'Symbols', inline = 's30')
s31 = input.symbol('SPY', group = 'Symbols', inline = 's31')
s32 = input.symbol('SPY', group = 'Symbols', inline = 's32')
s33 = input.symbol('SPY', group = 'Symbols', inline = 's33')
s34 = input.symbol('SPY', group = 'Symbols', inline = 's34')
s35 = input.symbol('SPY', group = 'Symbols', inline = 's35')
s36 = input.symbol('SPY', group = 'Symbols', inline = 's36')
s37 = input.symbol('SPY', group = 'Symbols', inline = 's37')
s38 = input.symbol('SPY', group = 'Symbols', inline = 's38')
Supertraders ATR-RangeThis script calculates the ATR 5 periods daily of previous day and various percentages (5%, 7,5% and 10%) of it that we use to evaluate a possibility to try a break-in of a level. This percentages are expressed in points, ticks and a value in dollars for every contract.
Questo script calcola l'ATR daily 5 periodi del giorno precedente. Calcola anche varie percentuali di esso, in particolare 5%, 7,5% e 10%, utily per verificare lo sforamento in caso di break-in di un livello. Questi valori sono espressi in punti, ticks e valore in dollaro per contratto.
VixFix RVol + EMAThis indicator plots Realised Volatility (measured using VixFix method) against its long-term exponential moving average.
RVol breaking above its EMA = Sell signal
RVol breaking below its EMA = Buy signal
60-day VixFix look back period and 900 day EMA work well for lower volatility tickers (equity ETFs, megacap stocks). Higher volatility tickers could benefit from shorter look back period and EMA.
cacheLibrary "cache"
A simple cache library to store key value pairs.
Fed up of injecting and returning so many values all the time?
Want to separate your code and keep it clean?
Need to make an expensive calculation and use the results in numerous places?
Want to throttle calculations or persist random values across bars or ticks?
Then you've come to the right place. Or not! Up to you, I don't mind either way... ;)
Check the helpers and unit tests in the script for further detail.
Detailed Interface
init(persistant) Initialises the syncronised cache key and value arrays
Parameters:
persistant : bool, toggles data persistance between bars and ticks
Returns: [string , float ], a tuple of both arrays
set(keys, values, key, value) Sets a value into the cache
Parameters:
keys : string , the array of cache keys
values : float , the array of cache values
key : string, the cache key to create or update
value : float, the value to set
has(keys, values, key) Checks if the cache has a key
Parameters:
keys : string , the array of cache keys
values : float , the array of cache values
key : string, the cache key to check
Returns: bool, true only if the key is found
get(keys, values, key) Gets a keys value from the cache
Parameters:
keys : string , the array of cache keys
values : float , the array of cache values
key : string, the cache key to get
Returns: float, the stored value
remove(keys, values, key) Removes a key and value from the cache
Parameters:
keys : string , the array of cache keys
values : float , the array of cache values
key : string, the cache key to remove
count() Counts how many key value pairs in the cache
Returns: int, the total number of pairs
loop(keys, values) Returns true for each value in the cache (use as the while loop expression)
Parameters:
keys : string , the array of cache keys
values : float , the array of cache values
next(keys, values) Returns each key value pair on successive calls (use in the while loop)
Parameters:
keys : string , the array of cache keys
values : float , the array of cache values
Returns: , tuple of each key value pair
clear(keys, values) Clears all key value pairs from the cache
Parameters:
keys : string , the array of cache keys
values : float , the array of cache values
unittest_cache(case) Cache module unit tests, for inclusion in parent script test suite. Usage: log.unittest_cache(__ASSERTS)
Parameters:
case : string , the current test case and array of previous unit tests (__ASSERTS)
unittest(verbose) Run the cache module unit tests as a stand alone. Usage: cache.unittest()
Parameters:
verbose : bool, optionally disable the full report to only display failures
bursamalaysianonshariahLibrary "bursamalaysianonshariah"
List of non-Shariah stock for Bursa Malaysia as of Oct 2021
No parameter required
status() will return 1 if ticker in the list, 0 if ticker not in the list and 2 if ticker not from Bursa Malaysia
Example usage :
//@version=5
indicator("My Script", overlay = true)
import BURSATRENDBANDCHART/bursamalaysianonshariah/1 as b
bgcolor(status() == 1 ? color.new(color.red, 90) : status() == 0 ? color.new(color.green, 90) : color.new(color.blue, 90))
Special thanks to
wmsafwan
RozaniGhani-RG
Elder Impulse System + ATR BandsDisregard the above chart, I am not sure why it isn't showing the one I want, which is linked below:
This is as far as I can tell the closest representation to Dr. Alexander Elder's updated "Elder Impulse System" that has added ATR-volatility bands up to 3x deviations from price. I got the idea from watching this recent video (www.youtube.com) of Dr. Elder reviewing some recent trades and noticed he had updated his system from his original books. The Impulse System colour coding was inspired by AstralLoverFlow and LazyBear. ATR Bands are pre-programmed Keltner Channels with some modifications such as filing in the ATR Zones with user-selected colour bands and modifying the ATR value to better suit the volatility of the market being traded.
The script has several components, which I will detail below:
Exponential Moving Averages:
1) A 13-period EMA that is used as a staple in all of Dr. Elder's technical analysis. He uses this EMA as the basis for all of his indicators and why it is included here.
2) A 26-period EMA which can be used as a base-line of sorts to filter when to go long or when to go short. For instance, price over the 26-EMA, price is strong and the rally upwards is likely to continue, underneath it, price is weak and likely to continue downwards for a time.
Volatility Bands:
By definition these are nothing more than 3 separate Keltner Channels of a 13-period EMA each set to one additional multiplier from the moving average. This gives us a 1x, 2x, and 3x multiplier of average volatility from the 13-period EMA based on a 14-period Average True Range (ATR) reading. The ATR was chosen as it accommodates price gaps and also is the standard formula calculation in TradingView. The values of the bands cannot be adjusted but the colour coding of them can be.
Elder Impulse System:
These colour-coded bars show you the strength and direction of the current chart resolution, calculated by the slope of a 13-period EMA and the slope of a MACD histogram. These are used not as a buying or selling recommendation alone but as trend filters, as per Dr. Elder's own description of them.
Green Bars = The 13-period EMA is sloping positively and the MACD histogram is rising compared to previous bars. The trader should only consider buying/long opportunities when a green bar is most recent.
Red Bars = The 13-period EMA is sloping negatively and the MACD histogram is falling compared to previous bars. The trader should only consider selling/short opportunities when a red bar is most recent.
Blue Bars = The 13-period EMA and the MACD histogram are not aligned. One of the indicators is sloping opposite to the other indicator. These are known as indecision bars and are typically seen near the end of a previously established trend. The trader can choose to wait for either a green or red bar to shape their trading bias if they are more risk-averse while a counter-trend trader may decide to try opening a position against the currently-established trend.
How To Trade the System:
This system is unique in that it is so versatile and will fit the styles of many traders, be it trend following traders (generally the original Elder Impulse System design) or mean-reversion/counter-trend trading (the original Keltner Channel design). None of the examples below or in the chart above are financial advice and are just there for demonstration purposes only.
1) The most basic signal given would be the moving average cross up or down. A cross of the 13-EMA over the 26-EMA signals upward trend strength and the trader could look for buying opportunities. Conversely, the 13-EMA under the 26-EMA shows downward trend strength and the trader could look for selling opportunities.
2) Following the Elder Impulse system in conjunction with the EMAs. Look for long opportunities when a green bar is printed and price is over both of the 13- and 26-period EMAs. Look for short opportunities when a red bar is printed and price is below both of the 13- and 26-period EMAs. Keep in mind this does not necessarily need a moving average cross to be viable, a green or red bar over both EMAs is a valid signal in this system, usually. Examine price more closely for better entry signals when a blue bar is printed and price is either above or below both EMAs if you are a trend trader. This is how Dr. Elder originally intended the system to be used in conjunction with his famous Triple Screen Trading System. I am not going into detail here as it is a deep subject but I would suggest an interested trader to examine this Triple Screen System further as it is widely accepted as a strong strategy.
3) Mean Reversion and Counter-Trend Trading. Dr. Elder mentions that the zone between the two EMAs is called the Value Zone. A mean reversion trader could look for buying opportunities if price has generally been in an uptrend and falls back to value, conversely, they could look for shorting opportunities if price has generally been in a downtrend and rises back to value. These are your very basic pull backs found in trends that create your higher lows in an uptrend or your lower highs in a downtrend. A mean reversion/scalper trader may also look to use the upper and lower most ATR bands as an indication of price being overbought or oversold and could look to enter a counter-trend trade here once a blue indecision bar is printed and to ride that move back down to the Value Zone.
Taking Profits and Risk Management
This system again is very versatile and will fit a wide range of trading styles. It has built in take profit levels and risk management depending on your style of trading.
1a) In original Triple Screen Trading (and the original Elder Impulse system), a trader was to place a buy order one tick above a newly printed green bar with a stop loss one tick below the most recent 2-day low, and vice-versa for red bars on short selling. as long as other criteria were met, that I will not go into. It is all over YouTube and in his books and on Investopedia if you want more information. The general idea is to continue the trend in the direction if price is strong and you are bought into that move with a close stop, or if price falls back a little bit, you can get in at a better price. This would be a system typically better suited to a scalper.
1b) The updated risk management according to the above video is to place a stop loss at least 2ATR away from price. These bands already have calculated these values so a trader can place a stop one tick below the 2 or even 3ATR zones depending on their risk appetite. This is assuming you have already received a strong buy signal based on the system you follow. This would be a system typically better suited to a trend-trader.
2a) Taking profits if you are a trend trader has several possibilities. The first, as Dr. Elder suggests, is to place a price target 2ATR values away from your entry giving you approximately a 1:1 risk-reward ratio.
2b) The second possibility if the trade is successful is to ride the trend upwards until a blue bar is printed, suggesting indecision in the market. A modified version of this that could let a winning trade run longer is to wait for the price to close under the 13-EMA in fast markets, or close under the 26-EMA in slightly slower markets to maximize potential winnings.
2c) A scalper trader may wish to have a target at either the value zone if they are playing an extended buy/short back to the mean, or if they are being at the mean, to sell or cover when price extends back out to the 2x or 3x zone.
3) Trend traders can additionally use the ATR zones as a sort of safety guidelines for entering a trade. Anything within the 1ATR zone is typically a safer entry as the market is less volatile at this time. Entering when price has gone into the 2ATR zone is signaled as a strong momentum move and can signal a stronger move in the direction of the current closing bar. While not always the case, it is suggested by Dr. Elder to not enter trend trades at the 3ATR zone as this is where you will be likely looking for a counter-trend retracement back to value and a trader entering here in the direction of the trade has a higher chance of being stopped out or not getting in at the best possible price.
Yield Curve Inversion IndicatorIntroduction
The last time (as of this publishing) that this indicator detected an inverted interest rate yield curve was on February 20th, 2020 at 12:30pm EST, the afternoon before the S&P500 began one of its largest crashes in US history. The vast majority of major economic recessions since the 1950's have been preceded by an interest rate yield curve inversion. I created this indicator originally as an input to study the impacts of more conservative risk management on quantitative trading strategies following a yield curve inversion event. It is being shared with the community as a quick indicator to check to see the comparative status of short term and long term interest rates, and as an indicator where you can easily check to see if we are experiencing an inverted yield curve in real-time.
Background of the significance of an inverted yield curve:
"What an inverted yield curve really means is that most investors believe that short-term interest rates are going to fall sharply at some point in the future. As a practical matter, recessions usually cause interest rates to fall. Historically, inversions of the yield curve have preceded recessions in the U.S. Due to this historical correlation, the yield curve is often seen as a way to predict the turning points of the business cycle. When the yield curve inverts, short-term interest rates become higher than long-term rates. This type of yield curve is the rarest of the three main curve types and is considered to be a predictor of economic recession. Because of the rarity of yield curve inversions, they typically draw attention from all parts of the financial world." (www.investopedia.com)
Settings and Usage
This indicator pulls in pricing data from tickers that represent short term and long term interest rates, and compares them. The red line represents short term interest rates, and the green line represents long term interest rates. When the red line is above the green line, it indicates that we are experiencing a yield curve inversion. Small blue crosses also appear on the bottom of the indicator during an inversion to further highlight the event visually. This indicator pulls in the same information on the same two interest rate tickers regardless of what chart it is applied to.
Other Thoughts
This script uses the f_secureSecurity function as a best practice. For those that are versed in PineScript, code from this indicator could be adapted to be applied to an interest rate chart that allows custom alerts to be created the moment that there is an inverted interest rate yield curve.
[BCT] Can BTC be predicted or is it purely random?Variance Ratio**This indicator can be applied to the ticker of your choice (not just BTC)**
Markets are said to be "efficient". An efficient market is by definition unpredictable - no matter the amount of ML, computation, or indicators thrown at it. In particular, in an efficient market, TA will not be of help.
An illustration of efficient markets is the WSJ's longstanding monkey vs. human contest:Blindfolded Monkey Beats Humans With Stock Picks, granted there are several flaws to it.
BTC is a relatively new market. New markets are typically highly inefficient (easier to make money) and become more and more efficient over time (harder to make money). How much more efficient is BTC becoming?
We apply the Variance Ratio method and apply it to BTC.
BACKGROUND ON THE VARIANCE RATIO METHOD
Based on 1988 MacKinlay's seminal paper "Stock Market Prices do not Follow a Random Walk", the idea is to exploit a phenomenon called "variance scaling".
For those keen on looking into the math, the short version of it is under the assumption of iid (random walk) we have the following:
H0: Var(Sum(returns over K bars))=Sum(Var(returns over 1 bar))=k*Var(return over 1 bar)
We look to reject or not H0 depending on the observations.
In this script, we compare the variance of the (log) returns for the chart selected between:
(1) The (average) variance over k bars (call this Vk)
(2) The (average) variance over 1 bar (call this V1)
H0 simply says that Vk=k*V1 if the stock follows a random walk.
We compute the Variance Ratio VR(k)=Variance(returns over k bar)/(Sum(Var(returns over 1 bar)))-1
We then compute the associated Z-score which we chart out for a configurable k number of bars.
HOW TO INTERPRET THE CHART
The line drawn is the Z-Score for VR(k). It represents the number of standard deviations of VR(k) from 0 - the further out, the less random.
- If the line is close / hovers around 0, the ticker appears to follow a random walk (i.e. may not be predictable)
- If the line is consistently > 2 or <-2, the ticker likely does not follow a random walk (i.e. may have predictable features)
- If the line is positive, it means that the Variance on the k bars is larger than the variance on 1 bar (more variance on longer timeframes)
- If the line is negative, it means that the Variance on the k bars is smaller than the variance on 1 bar (more variance on smaller timeframes)
USE CASES
- Identify timeframes where you won't be able to make money
- Identify whether a stock cannot be predicted (forget about TA, indicators etc. -- a random walk is not predictable)
- Identify whether a stock is becoming less and less predictable (Z-score amplitude will decrease over time)
FEATURES
- select the number of K bar to compare vs. 1 bar (default = 16) - ideally a power of 2 but any other number will work. The chart is based off this selection
- select the lookback period for the analysis (500 bars by default)
- select the source to analyze (default = close, but you may select other inputs to calculate the returns from)
- results form the statistical tests on different K's in the table on the right/bottom side of the chart (H0 rejected = not random walk; H0 not rejected = it essentially looks rather random and we can't conclude that it's not a random walk)
COMMENTARY ON BTC
- It appears BTC's absolute value of the ZScore on the Variance Ratio is declining year after year - corroborating an increasingly efficient market as new participants join.
- However, we can still detect a fair amount of potential inefficiency using this simple test.
As usual, this is not investment advice. DYOR.
With love,
🐵BCT🐵
Coin support [Supply/Demand]The idea here is to input the appropriate benchmark tickerid to the asset class you're trading and to paint zones according to the price activity of the selected tickerid. This works very well trying to paint meaningful zones against noisy stocks, currencies, commodities etc. Use a correlation coefficient to determine the best benchmark for your asset class.
Triple EMA StrategyThis is my first ever script so any suggestions, recommendations or improvement ideas welcome!
This strategy is an implementation of a standard three exponential moving averages strategy (defaults: EMA1=5, EMA2=20 and EMA3=50 candles). Trades are executed if EMA1 crosses above/below EMA2 and they are both above/below EMA3. In addition, the close of the current candle must be above/below the previous one by at least the number of ticks you specify in the "buffer" parameter (default 150 ticks). This additional check eliminates many bad trades.
There is also a trailing stoploss which comes into play once the price has gone above/below its initial value which it then follows the price with to ensure the trade closes at the highest possible price.
I find this strategy works best on a 15 minute chart but feel free to play around and fine tune the various parameters. If you find a good setup that returns decent profits, I'd be keen to hear it!
RELATIVE STRENGTHstudy(" RELATIVE STRENGTH", shorttitle="RS")
a = tickerid
b = input("NIFTY",type=symbol)
as = security(a,period,close)
bs = security(b,period,close)
plot(as/bs, title="RS" ,color=blue)
`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.
Bull Call Spread Entry StrategyThis strategy script uses the "Spread Entry Strength" overlay indicator script I designed to show entry timing optimized for an Option Bull
Call Spread.
As for this strategy...
The defaults for the strategy itself are as follows:
Period for strategy: 1/1/18 to 12/1/2021. This can be changed to a different period using the settings.
Condition for entry:
Bull Spread Entry Strength >= "Overlay Signal Strength Level"
Limit entry is used, price must be <= close when signaled
Entry occurs by next day or the order is cancelled
Condition for exit (uses a timed exit):
Bars passed since order entry >= 30 (6 weeks..~42 calendar days)
Thursday (day before "option" expiration date... assuming weekly options exist)
All of the user settings from the overlay are pulled into this for customization purposes. Details of the actual Spread Entry Strength overlay are as follows (copied from my shared indicator):
2 background shadings will occur:
The background will shade blue if the ticker is prime for a Bullish Call spread.
The background will shade purple if the the ticker is prime for a Bearish Put spread.
In theory, if the SE Strength is at one of the extremes of the Bear or Bull side, then a spread is prime for entry.
To calculate this, 8 conditions receive a 1 or zero dependent on whether the condition is true (1) or false (0), and then all of those are summed. The primary gist of the strength comes from Nishant's book, or my interpretation thereof, with some additives that limits what I need to review (such as condition 8 below.)
The 8 Bull Conditions are:
1) Bollinger Bands are outside of the Keltner Channels
2) ADX is trending up
3) RSI is trending up
4) -DI is trending down
5) RSI is under 30
6) Price is below the lower Keltner Channel
7) Price is between the lower Bollinger Band and the Bollinger basis.
8) Price at one point within the last 5 bars was below the lower Bollinger Band
The 8 Bear Conditions are the inverse conditions (except the first):
1) Bollinger Bands are outside of the Keltner Channels
2) ADX is trending down
3) RSI is trending down
4) +DI is trending up
5) RSI is over 70
6) Price is above the upper Keltner Channel
7) Price is between the upper Bollinger Band and the Bollinger basis.
8) Price at one point within the last 5 bars was above the upper Bollinger Band
There is a "market noise" filter that will filter out shading when another market move is considered, i.e. if you don't want to see the potential trade when QQQ moves more than 1% then do the following in the settings:
Check "Market Filter"
Enter QQQ in the "Market Ticker To Use"
Enter 1 in the "Market Too Hot Level"
Press Ok
Obviously, the same holds true for the "Market Too Cool Filter."
Second release notes:
Overlay Signal Strength Level - You can set your own "level" for the overlay in the settings, instead of having to change the script code itself. I have the default set to 6. A lower number shows more overlays, a higher number shows fewer (i.e. more conditions have been met.).
Provide Narrative (Troubleshooting) - Narrative label created with several outputs that will show after the last bar. This narrative needs to be turned on in the settings, as the default is "off" ... unchecked.
Remove Strength Indicator When Squeezed - when checked no overlays will be produced regardless of "scoring." Default is off.
Show Squeezes (Will Override Indicator When Concurrent) - overlays an orange background when the ticker is in a squeeze. I am still working on the accuracy here, but it's usable. This will override the strength indicator as well. This needs to be turned on, if you want it.
Short SMA Period - period used to calculate the short SMA, used in the narrative only, at this point in time.
Medium SMA Period - period used to calculate the medium SMA, used in the narrative only, at this point in time.
Long SMA Period - period used to calculate the medium SMA, used in the narrative only, at this point in time.
Outside of the settings... a few calculation adjustments here and there have occurred and some color shading adjustments to allow for the adjustable level setting.
Examples of Rolling Average Using Automated AnchoringIn this study, I present a method to expose NaN values to development environment.
This exposure allows NaN values to be used by methods in scripts.
I also show how to use values, even NaN values, as anchors from which statistics can be computed from.
I demonstrate how to do this with constants and variables in methods for computing the cumulative/rolling average of a series.
I also show how to calculate the cumulative/rolling average from the start of a ticker series using the aforementioned methods.
Each method has a description on how some of their parts work as well as their constraints.
Method #1 - Can only be used for computing the rolling average on the ticker series.
Method #2 - The simple moving average from the Pine Script reference.
- Can be used to calculate the rolling average of the ticker series and number values of a series.
- This method seems to cause an error when there are many bars in the series.
Method #3 - The most versatile method due to the use of computing the rolling average using an array.
- Timeout will occur when computing the rolling average of an entire ticker series which is long.
- Timeout has not occurred when computing a rolling average of a series from NaN or non-NaN anchor points even when the series is long.
This is an attempt to get around the constraints of the built-in sma(source, length) function in which length cannot be dynamically adjusted.
Other Pine Script functions have that constraint which we can get around by defining our own functions.
Spread Entry StrengthThis is an overlay indicator showing a strong potential for entry into an option spread trade.
2 background shadings will occur:
The background will shade blue if the ticker is prime for a Bullish Call spread.
The background will shade purple if the the ticker is prime for a Bearish Put spread.
In theory, if the SE Strength is at one of the extremes of the Bear or Bull side, then a spread is prime for entry.
To calculate this, 8 conditions receive a 1 or zero dependent on whether the condition is true (1) or false (0), and then all of those are summed. The primary gist of the strength comes from Nishant's book, or my interpretation thereof, with some additives that limits what I need to review (such as condition 8 below.)
The 8 Bull Conditions are:
1) Bollinger Bands are outside of the Keltner Channels
2) ADX is trending up
3) RSI is trending up
4) -DI is trending down
5) RSI is under 30
6) Price is below the lower Keltner Channel
7) Price is between the lower Bollinger Band and the Bollinger basis.
8) Price at one point within the last 5 bars was below the lower Bollinger Band
The 8 Bear Conditions are the inverse conditions (except the first):
1) Bollinger Bands are outside of the Keltner Channels
2) ADX is trending down
3) RSI is trending down
4) +DI is trending up
5) RSI is over 70
6) Price is above the upper Keltner Channel
7) Price is between the upper Bollinger Band and the Bollinger basis.
8) Price at one point within the last 5 bars was above the upper Bollinger Band
There is a "market noise" filter that will filter out shading when another market move is considered, i.e. if you don't want to see the potential trade when QQQ moves more than 1% then do the following in the settings:
Check "Market Filter"
Enter QQQ in the "Market Ticker To Use"
Enter 1 in the "Market Too Hot Level"
Press Ok
Obviously, the same holds true for the "Market Too Cool Filter."
Arbitrage BR STOCK / USA STOCKThis Indicator was made to show the BRL difference between an Stock in Brazil's B3 and it's respective ADR traded in the USA.
By default, it will show the spread between PETR4 and it's ADR PBR.A using the USD-BRL pair from Forex.
You can personalize this indicator to any Stock of your preference, and also change to any USD-BRL pair negotiated that you want. You'll have the following options to do so:
B3's Stock Ticker -> Ticker negotiated at B3.
USA's Stock Ticker -> The respective ADR of the first option.
ADR's Multiplicative Factor -> How many B3's Stocks are equivallent to the USA Stock (found at the name of the ADR on Trade View).
BRL/USD Market of Preference -> Which market you want to use to transform the price of the ADR from USD to BRL.
Dollar Divisor -> The BRL must be equivallent to 1 Dollar for the script to work. So, if you want to use a USD/BRL market that does not represent this relation, you must divide it by some number to do so. For example, if you want to use B3's DOLFUT, than you must set this parameter to 1000 (because the points show at B3's DOLFUT are the amount of BRL equivallent to 1000 Dollars). Also, if you are using a market that trades Dollar equivalent to 1 BRL (Globex's 6LFUT, for example), then set this parameter to 0.
Timeframe -> Recommended to be the same of the chart to better visualisation.
Data structure map[string, float]The script shows a workaround for map in pine-script via drawings.
There are few restrictions with them:
1. The size of the map cannot be more that amount of allowed drawings (about 40 by now)
2. Because the map shares the space of drawings throughout the whole script, using drawings with the map must be careful, with handly creating and removing of each drawing, because otherwise pine's garbage collector might break the stack. I'd recommend not using more drawings with the map.
3. setters and getters must be called on every bar, because of implementation of functions in pine there are inner serieses, which must be updated on every bar. So wherever you have a setter or getter in the code - it must be called on every bar. But if it's just an update, then you should pass 'false' as a param of the funtion.
The script shows a way to work with the map: filling it with some tickers and values for each of it and then plot the value if the symbol on the chart equals to one of the tickers in the map.
And there are some examples of updating of the value and removing of the item from the map.
Elder ray ( Bull power and bear power combined )Elder-ray is an indicator named for its similarity to x-rays.
It shows the structure of bullish and bearish
power below the surface of the markets. Elder-ray combines a trend-
following moving average with two oscillators to show when to enter
and exit long or short positions.
A moving average reflects the average consensus of value. The high of
each bar reflects the maximum power of bulls during that bar. The low of
each bar marks the maximum power of bears during that bar.
Elder-ray works by comparing the power of bulls and bears during each
bar with the average consensus of value. Bull Power reflects the maximum
power of bulls relative to the average consensus, and Bear Power the max-
imum power of bears relative to that consensus.
When the high of a bar is above the EMA, Bull Power is positive. When
the entire bar sinks below the EMA, which happens during severe de-
clines, Bull Power becomes negative. When the low of a bar is below the
EMA, Bear Power is negative. When the entire bar rises above the EMA,
which happens during wild rallies, Bear Power becomes positive.
The slope of a moving average identifies the current trend of the mar-
ket. When it rises, it shows that the crowd is becoming more bullish; it is
a good time to be long. When it falls, it shows that the crowd is becoming
more bearish; it is a good time to be short. Prices keep getting away from
a moving average but snap back to it, as if pulled by a rubber band. Bull
Power and Bear Power show the length of that rubber band. Knowing the
“Buy low, sell high” sounds good, but traders and investors seem to have
been more comfortable buying Lucent above 70 than below 7. Perhaps they
are not as rational as the efficient market theorists would like us to believe?
Elder-ray gives rational traders a glimpse into what is going on below the sur-
face of the market.
When the trend, identified by the 22-day EMA, is down and bulls are
under water, the rallies back to the surface mark shorting opportunities
normal height of Bull or Bear Power reveals how far prices are likely to get
away from their moving average before returning. Elder-ray offers one of
the best insights into where to take profits—at a distance away from the
moving average that equals the average Bull Power or Bear Power.
Elder-ray gives buy signals in uptrends when Bear Power turns nega-
tive and then ticks up. A negative Bear Power means that the bar is strad-
dling the EMA, with its low below the average consensus of value. Waiting
for Bear Power to turn negative forces you to buy value rather than chase
runaway moves. The actual buy signal is given by an uptick of Bear Power,
which shows that bears are starting to lose their grip and the uptrend is
about to resume. Take profits at the upper channel line or when a trend-
following indicator stops rising. Profits may be greater if you ride the
uptrend to its conclusion, but taking profits at the upper channel line is
more reliable.
Elder-ray gives shorting signals in downtrends when Bull Power turns
positive and then ticks down. We can identify the downtrend by a declin-
ing daily or weekly EMA. A positive Bull Power shows that the bar is strad-
dling the EMA, with its high above the average consensus of value.
Waiting for Bull Power to turn positive before shorting forces you to sell
at or above value instead of chasing waterfall declines. The actual short-
ing signal is given by a downtick of Bull Power, which shows that bulls
are starting to slip and the downtrend is about to resume. Once short, take
profits at the lower channel line or when the trend-following indicator
stops falling, depending on your style.
FREE TRADINGVIEW FOR TIMEFRAMESWhen doing i.e the 3 minute timeframe turn on the closest timeframe available for you or the candles and wicks will be fucked up.
So if you're doing the 5 hour timeframe candles turn on the 4hr chart on your main chart.
To View the candles in full screen double click the windows with the candlesticks
If you don't have TradingView premium and want to look at custom timeframes you can use this.
For the ticker/coin/pair you want to show enter it like this:
For stocks, only the ticker i.e: MSFT, APPL
For Crypto, "Exchange:ticker" i.e: BITFINEX:BTCUSD, BINANCE:AGIBTC, BITMEX:ADAM19
When setting up the timeframe write i.e:
For minutes/hourly: 5, 240 (4 hour), 360 (6 hour)
For daily/weekly/monthly: 1D, 2W, 3M
When doing i.e the 3 minute timeframe turn on the closest timeframe available for you or the candles and wicks will be fucked up.
So if you're doing the 5 hour timeframe candles turn on the 4hr chart on your main chart.
RSI MTF by PeterOThis is my take on reaching Higher TimeFrame charts, what is usually helpful when determining the trend. On the example of RSI.
So imagine you want to check RSI from higher timeframe. 15x higher for example. There are 3 ways to do it.
1. security(tickerid,"15",rsi(close,14))
DON'T!!! I strongly advise against this method. Security() function is buggy in PineScript, leads to so-called "repainting" issues. Repainting is caused by creating leak from future data and leads to abnormally fantastic strategy backtest results like the one in Open Close Cross Strategy. Theoretically speaking if security() used correctly - with Pine version3 and barmerge.lookahead_off - you should encounter no repainting, but I could swear I saw scripts repaint even with security() implemented properly.
Even assuming security() implemented correctly will not repaint - it will create delay in your script. I'm using "15" multiplier in my example, and this means, I have to wait for 15 candles to close to produce indicators value. If a strong move happens in the meantime, I'm blind, because I have to wait anyway.
So for your own security, stay away from security() at all times.
2. rsi(close,14*15)
This will produce RSI plot with no delay, but a very flattened one. RSI will move between 45 and 45, never even reaching 30 or 70 levels. So pretty useless.
3. Dig-in-the-formula way.
Doing a bit more math produces RSI line, which is not delayed, not repainting and moving in full 0-100 RSI range. Actually - looking almost identical to the one from the higher timeframe. Which was the goal of this script.
