taLibrary "ta"
█ OVERVIEW
This library holds technical analysis functions calculating values for which no Pine built-in exists.
Look first. Then leap.
█ FUNCTIONS
cagr(entryTime, entryPrice, exitTime, exitPrice)
It calculates the "Compound Annual Growth Rate" between two points in time. The CAGR is a notional, annualized growth rate that assumes all profits are reinvested. It only takes into account the prices of the two end points — not drawdowns, so it does not calculate risk. It can be used as a yardstick to compare the performance of two instruments. Because it annualizes values, the function requires a minimum of one day between the two end points (annualizing returns over smaller periods of times doesn't produce very meaningful figures).
Parameters:
entryTime : The starting timestamp.
entryPrice : The starting point's price.
exitTime : The ending timestamp.
exitPrice : The ending point's price.
Returns: CAGR in % (50 is 50%). Returns `na` if there is not >=1D between `entryTime` and `exitTime`, or until the two time points have not been reached by the script.
█ v2, Mar. 8, 2022
Added functions `allTimeHigh()` and `allTimeLow()` to find the highest or lowest value of a source from the first historical bar to the current bar. These functions will not look ahead; they will only return new highs/lows on the bar where they occur.
allTimeHigh(src)
Tracks the highest value of `src` from the first historical bar to the current bar.
Parameters:
src : (series int/float) Series to track. Optional. The default is `high`.
Returns: (float) The highest value tracked.
allTimeLow(src)
Tracks the lowest value of `src` from the first historical bar to the current bar.
Parameters:
src : (series int/float) Series to track. Optional. The default is `low`.
Returns: (float) The lowest value tracked.
█ v3, Sept. 27, 2022
This version includes the following new functions:
aroon(length)
Calculates the values of the Aroon indicator.
Parameters:
length (simple int) : (simple int) Number of bars (length).
Returns: ( [float, float ]) A tuple of the Aroon-Up and Aroon-Down values.
coppock(source, longLength, shortLength, smoothLength)
Calculates the value of the Coppock Curve indicator.
Parameters:
source (float) : (series int/float) Series of values to process.
longLength (simple int) : (simple int) Number of bars for the fast ROC value (length).
shortLength (simple int) : (simple int) Number of bars for the slow ROC value (length).
smoothLength (simple int) : (simple int) Number of bars for the weigted moving average value (length).
Returns: (float) The oscillator value.
dema(source, length)
Calculates the value of the Double Exponential Moving Average (DEMA).
Parameters:
source (float) : (series int/float) Series of values to process.
length (simple int) : (simple int) Length for the smoothing parameter calculation.
Returns: (float) The double exponentially weighted moving average of the `source`.
dema2(src, length)
An alternate Double Exponential Moving Average (Dema) function to `dema()`, which allows a "series float" length argument.
Parameters:
src : (series int/float) Series of values to process.
length : (series int/float) Length for the smoothing parameter calculation.
Returns: (float) The double exponentially weighted moving average of the `src`.
dm(length)
Calculates the value of the "Demarker" indicator.
Parameters:
length (simple int) : (simple int) Number of bars (length).
Returns: (float) The oscillator value.
donchian(length)
Calculates the values of a Donchian Channel using `high` and `low` over a given `length`.
Parameters:
length (int) : (series int) Number of bars (length).
Returns: ( [float, float, float ]) A tuple containing the channel high, low, and median, respectively.
ema2(src, length)
An alternate ema function to the `ta.ema()` built-in, which allows a "series float" length argument.
Parameters:
src : (series int/float) Series of values to process.
length : (series int/float) Number of bars (length).
Returns: (float) The exponentially weighted moving average of the `src`.
eom(length, div)
Calculates the value of the Ease of Movement indicator.
Parameters:
length (simple int) : (simple int) Number of bars (length).
div (simple int) : (simple int) Divisor used for normalzing values. Optional. The default is 10000.
Returns: (float) The oscillator value.
frama(source, length)
The Fractal Adaptive Moving Average (FRAMA), developed by John Ehlers, is an adaptive moving average that dynamically adjusts its lookback period based on fractal geometry.
Parameters:
source (float) : (series int/float) Series of values to process.
length (int) : (series int) Number of bars (length).
Returns: (float) The fractal adaptive moving average of the `source`.
ft(source, length)
Calculates the value of the Fisher Transform indicator.
Parameters:
source (float) : (series int/float) Series of values to process.
length (simple int) : (simple int) Number of bars (length).
Returns: (float) The oscillator value.
ht(source)
Calculates the value of the Hilbert Transform indicator.
Parameters:
source (float) : (series int/float) Series of values to process.
Returns: (float) The oscillator value.
ichimoku(conLength, baseLength, senkouLength)
Calculates values of the Ichimoku Cloud indicator, including tenkan, kijun, senkouSpan1, senkouSpan2, and chikou. NOTE: offsets forward or backward can be done using the `offset` argument in `plot()`.
Parameters:
conLength (int) : (series int) Length for the Conversion Line (Tenkan). The default is 9 periods, which returns the mid-point of the 9 period Donchian Channel.
baseLength (int) : (series int) Length for the Base Line (Kijun-sen). The default is 26 periods, which returns the mid-point of the 26 period Donchian Channel.
senkouLength (int) : (series int) Length for the Senkou Span 2 (Leading Span B). The default is 52 periods, which returns the mid-point of the 52 period Donchian Channel.
Returns: ( [float, float, float, float, float ]) A tuple of the Tenkan, Kijun, Senkou Span 1, Senkou Span 2, and Chikou Span values. NOTE: by default, the senkouSpan1 and senkouSpan2 should be plotted 26 periods in the future, and the Chikou Span plotted 26 days in the past.
ift(source)
Calculates the value of the Inverse Fisher Transform indicator.
Parameters:
source (float) : (series int/float) Series of values to process.
Returns: (float) The oscillator value.
kvo(fastLen, slowLen, trigLen)
Calculates the values of the Klinger Volume Oscillator.
Parameters:
fastLen (simple int) : (simple int) Length for the fast moving average smoothing parameter calculation.
slowLen (simple int) : (simple int) Length for the slow moving average smoothing parameter calculation.
trigLen (simple int) : (simple int) Length for the trigger moving average smoothing parameter calculation.
Returns: ( [float, float ]) A tuple of the KVO value, and the trigger value.
pzo(length)
Calculates the value of the Price Zone Oscillator.
Parameters:
length (simple int) : (simple int) Length for the smoothing parameter calculation.
Returns: (float) The oscillator value.
rms(source, length)
Calculates the Root Mean Square of the `source` over the `length`.
Parameters:
source (float) : (series int/float) Series of values to process.
length (int) : (series int) Number of bars (length).
Returns: (float) The RMS value.
rwi(length)
Calculates the values of the Random Walk Index.
Parameters:
length (simple int) : (simple int) Lookback and ATR smoothing parameter length.
Returns: ( [float, float ]) A tuple of the `rwiHigh` and `rwiLow` values.
stc(source, fast, slow, cycle, d1, d2)
Calculates the value of the Schaff Trend Cycle indicator.
Parameters:
source (float) : (series int/float) Series of values to process.
fast (simple int) : (simple int) Length for the MACD fast smoothing parameter calculation.
slow (simple int) : (simple int) Length for the MACD slow smoothing parameter calculation.
cycle (simple int) : (simple int) Number of bars for the Stochastic values (length).
d1 (simple int) : (simple int) Length for the initial %D smoothing parameter calculation.
d2 (simple int) : (simple int) Length for the final %D smoothing parameter calculation.
Returns: (float) The oscillator value.
stochFull(periodK, smoothK, periodD)
Calculates the %K and %D values of the Full Stochastic indicator.
Parameters:
periodK (simple int) : (simple int) Number of bars for Stochastic calculation. (length).
smoothK (simple int) : (simple int) Number of bars for smoothing of the %K value (length).
periodD (simple int) : (simple int) Number of bars for smoothing of the %D value (length).
Returns: ( [float, float ]) A tuple of the slow %K and the %D moving average values.
stochRsi(lengthRsi, periodK, smoothK, periodD, source)
Calculates the %K and %D values of the Stochastic RSI indicator.
Parameters:
lengthRsi (simple int) : (simple int) Length for the RSI smoothing parameter calculation.
periodK (simple int) : (simple int) Number of bars for Stochastic calculation. (length).
smoothK (simple int) : (simple int) Number of bars for smoothing of the %K value (length).
periodD (simple int) : (simple int) Number of bars for smoothing of the %D value (length).
source (float) : (series int/float) Series of values to process. Optional. The default is `close`.
Returns: ( [float, float ]) A tuple of the slow %K and the %D moving average values.
supertrend(factor, atrLength, wicks)
Calculates the values of the SuperTrend indicator with the ability to take candle wicks into account, rather than only the closing price.
Parameters:
factor (float) : (series int/float) Multiplier for the ATR value.
atrLength (simple int) : (simple int) Length for the ATR smoothing parameter calculation.
wicks (simple bool) : (simple bool) Condition to determine whether to take candle wicks into account when reversing trend, or to use the close price. Optional. Default is false.
Returns: ( [float, int ]) A tuple of the superTrend value and trend direction.
szo(source, length)
Calculates the value of the Sentiment Zone Oscillator.
Parameters:
source (float) : (series int/float) Series of values to process.
length (simple int) : (simple int) Length for the smoothing parameter calculation.
Returns: (float) The oscillator value.
t3(source, length, vf)
Calculates the value of the Tilson Moving Average (T3).
Parameters:
source (float) : (series int/float) Series of values to process.
length (simple int) : (simple int) Length for the smoothing parameter calculation.
vf (simple float) : (simple float) Volume factor. Affects the responsiveness.
Returns: (float) The Tilson moving average of the `source`.
t3Alt(source, length, vf)
An alternate Tilson Moving Average (T3) function to `t3()`, which allows a "series float" `length` argument.
Parameters:
source (float) : (series int/float) Series of values to process.
length (float) : (series int/float) Length for the smoothing parameter calculation.
vf (simple float) : (simple float) Volume factor. Affects the responsiveness.
Returns: (float) The Tilson moving average of the `source`.
tema(source, length)
Calculates the value of the Triple Exponential Moving Average (TEMA).
Parameters:
source (float) : (series int/float) Series of values to process.
length (simple int) : (simple int) Length for the smoothing parameter calculation.
Returns: (float) The triple exponentially weighted moving average of the `source`.
tema2(source, length)
An alternate Triple Exponential Moving Average (TEMA) function to `tema()`, which allows a "series float" `length` argument.
Parameters:
source (float) : (series int/float) Series of values to process.
length (float) : (series int/float) Length for the smoothing parameter calculation.
Returns: (float) The triple exponentially weighted moving average of the `source`.
trima(source, length)
Calculates the value of the Triangular Moving Average (TRIMA).
Parameters:
source (float) : (series int/float) Series of values to process.
length (int) : (series int) Number of bars (length).
Returns: (float) The triangular moving average of the `source`.
trima2(src, length)
An alternate Triangular Moving Average (TRIMA) function to `trima()`, which allows a "series int" length argument.
Parameters:
src : (series int/float) Series of values to process.
length : (series int) Number of bars (length).
Returns: (float) The triangular moving average of the `src`.
trix(source, length, signalLength, exponential)
Calculates the values of the TRIX indicator.
Parameters:
source (float) : (series int/float) Series of values to process.
length (simple int) : (simple int) Length for the smoothing parameter calculation.
signalLength (simple int) : (simple int) Length for smoothing the signal line.
exponential (simple bool) : (simple bool) Condition to determine whether exponential or simple smoothing is used. Optional. The default is `true` (exponential smoothing).
Returns: ( [float, float, float ]) A tuple of the TRIX value, the signal value, and the histogram.
uo(fastLen, midLen, slowLen)
Calculates the value of the Ultimate Oscillator.
Parameters:
fastLen (simple int) : (series int) Number of bars for the fast smoothing average (length).
midLen (simple int) : (series int) Number of bars for the middle smoothing average (length).
slowLen (simple int) : (series int) Number of bars for the slow smoothing average (length).
Returns: (float) The oscillator value.
vhf(source, length)
Calculates the value of the Vertical Horizontal Filter.
Parameters:
source (float) : (series int/float) Series of values to process.
length (simple int) : (simple int) Number of bars (length).
Returns: (float) The oscillator value.
vi(length)
Calculates the values of the Vortex Indicator.
Parameters:
length (simple int) : (simple int) Number of bars (length).
Returns: ( [float, float ]) A tuple of the viPlus and viMinus values.
vzo(length)
Calculates the value of the Volume Zone Oscillator.
Parameters:
length (simple int) : (simple int) Length for the smoothing parameter calculation.
Returns: (float) The oscillator value.
williamsFractal(period)
Detects Williams Fractals.
Parameters:
period (int) : (series int) Number of bars (length).
Returns: ( [bool, bool ]) A tuple of an up fractal and down fractal. Variables are true when detected.
wpo(length)
Calculates the value of the Wave Period Oscillator.
Parameters:
length (simple int) : (simple int) Length for the smoothing parameter calculation.
Returns: (float) The oscillator value.
█ v7, Nov. 2, 2023
This version includes the following new and updated functions:
atr2(length)
An alternate ATR function to the `ta.atr()` built-in, which allows a "series float" `length` argument.
Parameters:
length (float) : (series int/float) Length for the smoothing parameter calculation.
Returns: (float) The ATR value.
changePercent(newValue, oldValue)
Calculates the percentage difference between two distinct values.
Parameters:
newValue (float) : (series int/float) The current value.
oldValue (float) : (series int/float) The previous value.
Returns: (float) The percentage change from the `oldValue` to the `newValue`.
donchian(length)
Calculates the values of a Donchian Channel using `high` and `low` over a given `length`.
Parameters:
length (int) : (series int) Number of bars (length).
Returns: ( [float, float, float ]) A tuple containing the channel high, low, and median, respectively.
highestSince(cond, source)
Tracks the highest value of a series since the last occurrence of a condition.
Parameters:
cond (bool) : (series bool) A condition which, when `true`, resets the tracking of the highest `source`.
source (float) : (series int/float) Series of values to process. Optional. The default is `high`.
Returns: (float) The highest `source` value since the last time the `cond` was `true`.
lowestSince(cond, source)
Tracks the lowest value of a series since the last occurrence of a condition.
Parameters:
cond (bool) : (series bool) A condition which, when `true`, resets the tracking of the lowest `source`.
source (float) : (series int/float) Series of values to process. Optional. The default is `low`.
Returns: (float) The lowest `source` value since the last time the `cond` was `true`.
relativeVolume(length, anchorTimeframe, isCumulative, adjustRealtime)
Calculates the volume since the last change in the time value from the `anchorTimeframe`, the historical average volume using bars from past periods that have the same relative time offset as the current bar from the start of its period, and the ratio of these volumes. The volume values are cumulative by default, but can be adjusted to non-accumulated with the `isCumulative` parameter.
Parameters:
length (simple int) : (simple int) The number of periods to use for the historical average calculation.
anchorTimeframe (simple string) : (simple string) The anchor timeframe used in the calculation. Optional. Default is "D".
isCumulative (simple bool) : (simple bool) If `true`, the volume values will be accumulated since the start of the last `anchorTimeframe`. If `false`, values will be used without accumulation. Optional. The default is `true`.
adjustRealtime (simple bool) : (simple bool) If `true`, estimates the cumulative value on unclosed bars based on the data since the last `anchor` condition. Optional. The default is `false`.
Returns: ( [float, float, float ]) A tuple of three float values. The first element is the current volume. The second is the average of volumes at equivalent time offsets from past anchors over the specified number of periods. The third is the ratio of the current volume to the historical average volume.
rma2(source, length)
An alternate RMA function to the `ta.rma()` built-in, which allows a "series float" `length` argument.
Parameters:
source (float) : (series int/float) Series of values to process.
length (float) : (series int/float) Length for the smoothing parameter calculation.
Returns: (float) The rolling moving average of the `source`.
supertrend2(factor, atrLength, wicks)
An alternate SuperTrend function to `supertrend()`, which allows a "series float" `atrLength` argument.
Parameters:
factor (float) : (series int/float) Multiplier for the ATR value.
atrLength (float) : (series int/float) Length for the ATR smoothing parameter calculation.
wicks (simple bool) : (simple bool) Condition to determine whether to take candle wicks into account when reversing trend, or to use the close price. Optional. Default is `false`.
Returns: ( [float, int ]) A tuple of the superTrend value and trend direction.
vStop(source, atrLength, atrFactor)
Calculates an ATR-based stop value that trails behind the `source`. Can serve as a possible stop-loss guide and trend identifier.
Parameters:
source (float) : (series int/float) Series of values that the stop trails behind.
atrLength (simple int) : (simple int) Length for the ATR smoothing parameter calculation.
atrFactor (float) : (series int/float) The multiplier of the ATR value. Affects the maximum distance between the stop and the `source` value. A value of 1 means the maximum distance is 100% of the ATR value. Optional. The default is 1.
Returns: ( [float, bool ]) A tuple of the volatility stop value and the trend direction as a "bool".
vStop2(source, atrLength, atrFactor)
An alternate Volatility Stop function to `vStop()`, which allows a "series float" `atrLength` argument.
Parameters:
source (float) : (series int/float) Series of values that the stop trails behind.
atrLength (float) : (series int/float) Length for the ATR smoothing parameter calculation.
atrFactor (float) : (series int/float) The multiplier of the ATR value. Affects the maximum distance between the stop and the `source` value. A value of 1 means the maximum distance is 100% of the ATR value. Optional. The default is 1.
Returns: ( [float, bool ]) A tuple of the volatility stop value and the trend direction as a "bool".
Removed Functions:
allTimeHigh(src)
Tracks the highest value of `src` from the first historical bar to the current bar.
allTimeLow(src)
Tracks the lowest value of `src` from the first historical bar to the current bar.
trima2(src, length)
An alternate Triangular Moving Average (TRIMA) function to `trima()`, which allows a
"series int" length argument.
Komut dosyalarını "bar" için ara
Realtime Delta Volume Action [LucF]█ OVERVIEW
This indicator displays on-chart, realtime, delta volume and delta ticks information for each bar. It aims to provide traders who trade price action on small timeframes with volume and tick information gathered as updates come in the chart's feed. It builds its own candles, which are optimized to display volume delta information. It only works in realtime.
█ WARNING
This script is intended for traders who can already profitably trade discretionary on small timeframes. The high cost in fees and the excitement of trading at small timeframes have ruined many newcomers to trading. While trading at small timeframes can work magic for adrenaline junkies in search of thrills rather than profits, I DO NOT recommend it to most traders. Only seasoned discretionary traders able to factor in the relatively high cost of such a trading practice can ever hope to take money out of markets in that type of environment, and I would venture they account for an infinitesimal percentage of traders. If you are a newcomer to trading, AVOID THIS TOOL AT ALL COSTS — unless you are interested in experimenting with the interpretation of volume delta combined with price action. No tool currently available on TradingView provides this type of close monitoring of volume delta information, but if you are not already trading small timeframes profitably, please do not let yourself become convinced that it is the missing piece you needed. Avoid becoming a sucker who only contributes by providing liquidity to markets.
The information calculated by the indicator cannot be saved on charts, nor can it be recalculated from historical bars.
If you refresh the chart or restart the script, the accumulated information will be lost.
█ FEATURES
Key values
The script displays the following key values:
• Above the bar: ticks delta (DT), the total ticks for the bar, the percentage of total ticks that DT represents (DT%)
• Below the bar: volume delta (DV), the total volume for the bar, the percentage of total volume that DV represents (DV%).
Candles
Candles are composed of four components:
1. A top shaped like this: ┴, and a bottom shaped like this: ┬ (picture a normal Japanese candle without a body outline; the values used are the same).
2. The candle bodies are filled with the bull/bear color representing the polarity of DV. The intensity of the body's color is determined by the DV% value.
When DV% is 100, the intensity of the fill is brightest. This plays well in interpreting the body colors, as the smaller, less significant DV% values will produce less vivid colors.
3. The bright-colored borders of the candle bodies occur on "strong bars", i.e., bars meeting the criteria selected in the script's inputs, which you can configure.
4. The POC line is a small horizontal line that appears to the left of the candle. It is the volume-weighted average of all price updates during the bar.
Calculations
This script monitors each realtime update of the chart's feed. It first determines if price has moved up or down since the last update. The polarity of the price change, in turn, determines the polarity of the volume and tick for that specific update. If price does not move between consecutive updates, then the last known polarity is used. Using this method, we can calculate a running volume delta and ticks delta for the bar, which becomes the bar's final delta values when the bar closes (you can inspect values of elapsed realtime bars in the Data Window or the indicator's values). Note that these values will all reset if the script re-executes because of a change in inputs or a chart refresh.
While this method of calculating is not perfect, it is by far the most precise way of calculating volume delta available on TradingView at the moment. Calculating more precise results would require scripts to have access to tick data from any chart timeframe. Charts at seconds timeframes do use exchange/broker ticks when the feeds you are using allow for it, and this indicator will run on them, but tick data is not yet available from higher timeframes. Also, note that the method used in this script is far superior to the intrabar inspection technique used on historical bars in my other "Delta Volume" indicators. This is because volume and ticks delta here are calculated from many more realtime updates than the available intrabars in history. Unfortunately, the calculation method used here cannot be used on historical bars, where intrabar inspection remains, in my opinion, the optimal method.
Inputs
The script's inputs provide many ways to personalize all the components: what is displayed, the colors used to display the information, and the marker conditions. Tooltips provide details for many of the inputs; I leave their exploration to you.
Markers
Markers provide a way for you to identify the points of interest of your choice on the chart. You control the set of conditions that trigger each of the five available markers.
You select conditions by entering, in the field for each marker, the number of each condition you want to include, separated by a comma. The conditions are:
1 — The bar's polarity is up/dn.
2 — `close` rises/falls ("rises" means it is higher than its value on the previous bar).
3 — DV's polarity is +/–.
4 — DV% rises (↕).
5 — POC rises/falls.
6 — The quantity of realtime updates rises (↕).
7 — DV > limit (You specify the limit in the inputs. Since DV can be +/–, DV– must be less than `–limit` for a short marker).
8 — DV% > limit (↕).
9 — DV+ rises for a long marker, DV– falls for a short.
10 — Consecutive DV+/DV– on two bars.
11 — Total volume rises (↕).
12 — DT's polarity is +/–.
13 — DT% rises (↕).
14 — DT+ rises for a long marker, DT– falls for a short.
Conditions showing the (↕) symbol do not have symmetrical states; they act more like filters. If you only include condition 4 in a marker's setup, for example, both long and short markers will trigger on bars where DV% rises. To trigger only long or short markers, you must add a condition providing directional differentiation, such as conditions 1 or 2. Accordingly, you would enter "1,4" or "2,4".
For a marker to trigger, ALL the conditions you specified for it must be met. Long markers appear on the chart as "Mx▲" signs under the values displayed below candles. Short markers display "Mx▼" over the number of updates displayed above candles. The marker's number will replace the "x" in "Mx▲". The script loads with five markers that will not trigger because no conditions are associated with them. To activate markers, you will need to select and enter the set of conditions you require for each one.
Alerts
You can configure alerts on this script. They will trigger whenever one of the configured markers triggers. Alerts do not repaint, so they trigger at the bar's close—which is also when the markers will appear.
█ HOW TO USE IT
As a rule, I do not prescribe expected use of my indicators, as traders have proved to be much more creative than me in using them. Additionally, I tend to think that if you expect detailed recommendations from me to be able to use my indicators, it's a sign you are in a precarious situation and should go back to the drawing board and master the necessary basics that will allow you to explore and decide for yourself if my indicators can be useful to you, and how you will use them. I will make an exception for this thing, as it presents fairly novel information. I will use simple logic to surmise potential uses, as contrary to most of my other indicators, I have NOT used this one to actually trade. Markets have a way of throwing wrenches in our seemingly bullet-proof rationalizing, so drive cautiously and please forgive me if the pointers I share here don't pan out.
The first thing to do is to disable your normal bars. You can do this by clicking on the eye icon that appears when you hover over the symbol's name in the upper-left corner of your chart.
The absolute value and polarity of DV mean little without perspective; that's why I include both total volume for the bar and the percentage that DV represents of that total volume. I interpret a low DV% value as indecision. If you share that opinion, you could, let's say, configure one of the markers on "DV% > 80%", for example (to do so you would enter "8" in the condition field of any marker, and "80" in the limit field for condition 8, below the marker conditions).
I also like to analyze price action on the bar with DV%. Small DV% values should often produce small candle bodies. If a small DV% value occurs on a bar with much movement and high volume, I'm thinking "tough battle with potential explosive power when one side wins". Conversely, large bodies with high DV% mean that large volume is breaching through multiple levels, or that nobody is suddenly willing to take the other side of a normal volume of trades.
I find the POC lines really interesting. First, they tell us the price point where the most significant action (taking into account both price occurrences AND volume) during the bar occurred. Second, they can be useful when compared against past values. Third, their color helps us in figuring out which ones are the most significant. Unsurprisingly, bunches of orange POCs tend to appear in consolidation zones, in pauses, and before reversals. It may be useful to often focus more on POC progression than on `close` values. This is not to say that OHLC values are not useful; looking, as is customary, for higher highs or lower lows, or for repeated tests of precise levels can of course still be useful. I do like how POCs add another dimension to chart readings.
What should you do with the ticks delta above bars? Old-time ticker tape readers paid attention to the sounds coming from it (the "ticker" moniker actually comes from the sound they made). They knew activity was picking up when the frequency of the "ticks" increased. My thinking is that the total number of ticks will help you in the same way, since increasing updates usually mean growing interest—and thus perhaps price movement, as increasing volatility or volume would lead us to surmise. Ticks delta can help you figure out when proportionally large, random orders come in from traders with other perspectives than the short-term price action you are typically working with when you use this tool. Just as volume delta, ticks delta are one more informational component that can help you confirm convergence when building your opinions on price action.
What are strong bars? They are an attempt to identify significance. They are like a default marker, except that instead of displaying "Mx▲/▼" below/above the bar, the candle's body is outlined in bright bull/bear color when one is detected. Strong bars require a respectable amount of conditions to be met (you can see and re-configure them in the inputs). Think of them as pushes rather than indications of an upcoming, strong and multi-bar move. Pushes do, for sure, often occur at the beginning of strong trends. You will often see a few strong bars occur at 2-3 bar intervals at the beginning or middle of trends. But they also tend to occur at tops/bottoms, which makes their interpretation problematic. Another pattern that you will see quite frequently is a final strong bar in the direction of the trend, followed a few bars later by another strong bar in the reverse direction. My summary analyses seemed to indicate these were perhaps good points where one could make a bet on an early, risky reversal entry.
The last piece of information displayed by the indicator is the color of the candle bodies. Three possible colors are used. Bull/bear is determined by the polarity of DV, but only when the bar's polarity matches that of DV. When it doesn't, the color is the divergence color (orange, by default). Whichever color is used for the body, its intensity is determined by the DV% value. Maximum intensity occurs when DV%=100, so the more significant DV% values generate more noticeable colors. Body colors can be useful when looking to confirm the convergence of other components. The visual effect this creates hopefully makes it easier to detect patterns on the chart.
One obvious methodology that comes to mind to trade with this tool would be to use another indicator like Technical Ratings at a higher timeframe to identify the larger context's trend, and then use this tool to identify entries for short-term trades in that direction.
█ NOTES AND RAMBLINGS
Instant Calculations
This indicator uses instant values calculated on the bar only. No moving averages or calculations involving historical periods are used. The only exception to this rule is in some of the marker conditions like "Two consecutive DV+ values", where information from the previous bar is used.
Trading Small vs Long Timeframes
I never trade discretionary at the 5sec–5min timeframes this indicator was designed to be used with; I trade discretionary at 1D, 1W and 1M timeframes, and let systems trade at smaller timeframes. The higher the timeframe you trade at, the fewer fees you will pay because you trade less and are not churning trading volume, as is inevitable at smaller timeframes. Trading at higher timeframes is also a good way to gain an instant edge on most of the trading crowd that has its nose to the ground and often tends to forget the big picture. It also makes for a much less demanding trading practice, where you have lots of time to research and build your long-term opinions on potential future outcomes. While the future is always uncertain, I believe trades riding on long-term trends have stronger underlying support from the reality outside markets.
To traders who will ask why I publish an indicator designed for small timeframes, let me say that my main purpose here is to showcase what can be done with Pine. I often see comments by coders who are obviously not aware of what Pine is capable of in 2021. Since its humble beginnings seven years ago, Pine has grown and become a serious programming language. TradingView's growing popularity and its ongoing commitment to keep Pine accessible to newcomers to programming is gradually making Pine more and more of a standard in indicator and strategy programming. The technical barriers to entry for traders interested in owning their trading practice by developing their personal tools to trade have never been so low. I am also publishing this script because I value volume delta information, and I present here what I think is an original way of analyzing it.
Performance
The script puts a heavy load on the Pine runtime and the charting engine. After running the script for a while, you will often notice your chart becoming less responsive, and your chart tab can take longer to activate when you go back to it after using other tabs. That is the reason I encourage you to set the number of historical values displayed on bars to the minimum that meets your needs. When your chart becomes less responsive because the script has been running on it for many hours, refreshing the browser tab will restart everything and bring the chart's speed back up. You will then lose the information displayed on elapsed bars.
Neutral Volume
This script represents a departure from the way I have previously calculated volume delta in my scripts. I used the notion of "neutral volume" when inspecting intrabar timeframes, for bars where price did not move. No longer. While this had little impact when using intrabar inspection because the minimum usable timeframe was 1min (where bars with zero movement are relatively infrequent), a more precise way was required to handle realtime updates, where multiple consecutive prices often have the same value. This will usually happen whenever orders are unable to move across the bid/ask levels, either because of slow action or because a large-volume bid/ask level is taking time to breach. In either case, the proper way to calculate the polarity of volume delta for those updates is to use the last known polarity, which is how I calculate now.
The Order Book
Without access to the order book's levels (the depth of market), we are limited to analyzing transactions that come in the TradingView feed for the chart. That does not mean the volume delta information calculated this way is irrelevant; on the contrary, much of the information calculated here is not available in trading consoles supplied by exchanges/brokers. Yet it's important to realize that without access to the order book, you are forfeiting the valuable information that can be gleaned from it. The order book's levels are always in movement, of course, and some of the information they contain is mere posturing, i.e., attempts to influence the behavior of other players in the market by traders/systems who will often remove their orders when price comes near their order levels. Nonetheless, the order book is an essential tool for serious traders operating at intraday timeframes. It can be used to time entries/exits, to explain the causes of particular price movements, to determine optimal stop levels, to get to know the traders/systems you are betting against (they tend to exhibit behavioral patterns only recognizable through the order book), etc. This tool in no way makes the order book less useful; I encourage all intraday traders to become familiar with it and avoid trading without one.
Delta Volume Candles [LucF]█ OVERVIEW
This indicator plots on-chart volume delta information using candles that can replace your normal candles, tops and bottoms appended to normal candles, optional MAs of those tops and bottoms levels, a divergence channel and a chart background. The indicator calculates volume delta using intrabar analysis, meaning that it uses the lower timeframe bars constituting each chart bar.
█ CONCEPTS
Volume Delta
The volume delta concept divides a bar's volume in "up" and "down" volumes. The delta is calculated by subtracting down volume from up volume. Many calculation techniques exist to isolate up and down volume within a bar. The simplest use the polarity of interbar price changes to assign their volume to up or down slots, e.g., On Balance Volume or the Klinger Oscillator . Others such as Chaikin Money Flow use assumptions based on a bar's OHLC values. The most precise calculation method uses tick data and assigns the volume of each tick to the up or down slot depending on whether the transaction occurs at the bid or ask price. While this technique is ideal, it requires huge amounts of data on historical bars, which considerably limits the historical depth of charts and the number of symbols for which tick data is available. Furthermore, historical tick data is not yet available on TradingView.
This indicator uses intrabar analysis to achieve a compromise between the simplest and most precise methods of calculating volume delta. It is currently the most precise method usable on TradingView charts. TradingView's Volume Profile built-in indicators use it, as do the CVD - Cumulative Volume Delta Candles and CVD - Cumulative Volume Delta (Chart) indicators published from the TradingView account . My Delta Volume Channels and Volume Delta Columns Pro indicators also use intrabar analysis. Other volume delta indicators such as my Realtime 5D Profile use realtime chart updates to calculate volume delta without intrabar analysis, but that type of indicator only works in real time; they cannot calculate on historical bars.
This is the logic I use to determine the polarity of intrabars, which determines the up or down slot where its volume is added:
• If the intrabar's open and close values are different, their relative position is used.
• If the intrabar's open and close values are the same, the difference between the intrabar's close and the previous intrabar's close is used.
• As a last resort, when there is no movement during an intrabar, and it closes at the same price as the previous intrabar, the last known polarity is used.
Once all intrabars making up a chart bar have been analyzed and the up or down property of each intrabar's volume determined, the up volumes are added, and the down volumes subtracted. The resulting value is volume delta for that chart bar, which can be used as an estimate of the buying/selling pressure on an instrument. Not all markets have volume information. Without it, this indicator is useless.
Intrabar analysis
Intrabars are chart bars at a lower timeframe than the chart's. The timeframe used to access intrabars determines the number of intrabars accessible for each chart bar. On a 1H chart, each chart bar of an active market will, for example, usually contain 60 bars at the lower timeframe of 1min, provided there was market activity during each minute of the hour.
This indicator automatically calculates an appropriate lower timeframe using the chart's timeframe and the settings you use in the script's "Intrabars" section of the inputs. As it can access lower timeframes as small as seconds when available, the indicator can be used on charts at relatively small timeframes such as 1min, provided the market is active enough to produce bars at second timeframes.
The quantity of intrabars analyzed in each chart bar determines:
• The precision of calculations (more intrabars yield more precise results).
• The chart coverage of calculations (there is a 100K limit to the quantity of intrabars that can be analyzed on any chart,
so the more intrabars you analyze per chart bar, the less chart bars can be calculated by the indicator).
The information box displayed at the bottom right of the chart shows the lower timeframe used for intrabars, as well as the average number of intrabars detected for chart bars and statistics on chart coverage.
Balances
This indicator calculates five balances from volume delta values. The balances are oscillators with a zero centerline; positive values are bullish, and negative values are bearish. It is important to understand the balances as they can be used to:
• Color candle bodies.
• Calculate body and top and bottom divergences.
• Color an EMA channel.
• Color the chart's background.
• Configure markers and alerts.
The five balances are:
1 — Bar Balance : This is the only balance using instant values; it is simply the subtraction of the down volume from the up volume on the bar, so the instant volume delta for that bar.
2 — Average Balance : Calculates a distinct EMA for both the up and down volumes, and subtracts the down EMA from the up EMA.
The result is akin to MACD's histogram because it is the subtraction of two moving averages.
3 — Momentum Balance : Starts by calculating, separately for both up and down volumes, the difference between the same EMAs used in "Average Balance" and
an SMA of twice the period used for the "Average Balance" EMAs. The difference for the up side is subtracted from the difference for the down side,
and an RSI of that value is calculated and brought over the −50/+50 scale.
4 — Relative Balance : The reference values used in the calculation are the up and down EMAs used in the "Average Balance".
From those, we calculate two intermediate values using how much the instant up and down volumes on the bar exceed their respective EMA — but with a twist.
If the bar's up volume does not exceed the EMA of up volume, a zero value is used. The same goes for the down volume with the EMA of down volume.
Once we have our two intermediate values for the up and down volumes exceeding their respective MA, we subtract them. The final value is an ALMA of that subtraction.
The rationale behind using zero values when the bar's up/down volume does not exceed its EMA is to only take into account the more significant volume.
If both instant volume values exceed their MA, then the difference between the two is the signal's value.
The signal is called "relative" because the intermediate values are the difference between the instant up/down volumes and their respective MA.
This balance flatlines when the bar's up/down volumes do not exceed their EMAs, which makes it useful to spot areas where trader interest dwindles, such as consolidations.
The smaller the period of the final value's ALMA, the more easily it will flatline. These flat zones should be considered no-trade zones.
5 — Percent Balance : This balance is the ALMA of the ratio of the "Bar Balance" over the total volume for that bar.
From the balances and marker conditions, two more values are calculated:
1 — Marker Bias : This sums the up/down (+1/‒1) occurrences of the markers 1 to 4 over a period you define, so it ranges from −4 to +4, times the period.
Its calculation will depend on the modes used to calculate markers 3 and 4.
2 — Combined Balances : This is the sum of the bull/bear (+1/−1) states of each of the five balances, so it ranges from −5 to +5.
The periods for all of these balances can be configured in the "Periods" section at the bottom of the script's inputs. As you cannot see the balances on the chart, you can use my Volume Delta Columns Pro indicator in a pane; it can plot the same balances, so you will be able to analyze them.
Divergences
In the context of this indicator, a divergence is any bar where the bear/bull state of a balance (above/below its zero centerline) diverges from the polarity of a chart bar. No directional bias is assigned to divergences when they occur. Candle bodies and tops/bottoms can each be colored differently on divergences detected from distinct balances.
Divergence Channel
The divergence channel is the space between two levels (by default, the bar's open and close ) saved when divergences occur. When price (by default the close ) has breached a channel and a new divergence occurs, a new channel is created. Until that new channel is breached, bars where additional divergences occur will expand the channel's levels if the bar's price points are outside the channel.
Prices breaches of the divergence channel will change its state. Divergence channels can be in one of three different states:
• Bull (green): Price has breached the channel to the upside.
• Bear (red): Price has breached the channel to the downside.
• Neutral (gray): The channel has not yet been breached.
█ HOW TO USE THE INDICATOR
I do not make videos to explain how to use my indicators. I do, however, try hard to include in their description everything one needs to understand what they do. From there, it's up to you to explore and figure out if they can be useful in your trading practice. Communicating in videos what this description and the script's tooltips contain would make for very long videos that would likely exceed the attention span of most people who find this description too long. There is no quick way to understand an indicator such as this one because it uses many different concepts and has quite a bit of settings one can use to modify its visuals and behavior — thus how one uses it. I will happily answer questions on the inner workings of the indicator, but I do not answer questions like "How do I trade using this indicator?" A useful answer to that question would require an in-depth analysis of who you are, your trading methodology and objectives, which I do not have time for. I do not teach trading.
Start by loading the indicator on an active chart containing volume information. See here if you need help.
The default configuration displays:
• Normal candles where the bodies are only colored if the bar's volume has increased since the last bar.
If you want to use this indicator's candles, you may want to disable your chart's candles by clicking the eye icon to the right of the symbol's name in the top left of the chart.
• A top or bottom appended to the normal candles. It represents the difference between up and down volume for that bar
and is positioned at the top or bottom, depending on its polarity. If up volume is greater than down volume, a top is displayed. If down volume is greater, a bottom is plotted.
The size of tops and bottoms is determined by calculating a factor which is the proportion of volume delta over the bar's total volume.
That factor is then used to calculate the top or bottom size relative to a baseline of the average candle body size of the last 100 bars.
• An information box in the bottom right displaying intrabar and chart coverage information.
• A light red background when the intrabar volume differs from the chart's volume by more than 1%.
The script's inputs contain tooltips explaining most of the fields. I will not repeat them here. Following is a brief description of each section of the indicator's inputs which will give you an idea of what the indicator can do:
Normal Candles is where you configure the replacement candles plotted by the script. You can choose from different coloring schemes for their bodies and specify a unique color for bodies where a divergence calculated using the method you choose occurs.
Volume Tops & Botttoms is where you configure the display of tops and bottoms, and their EMAs. The EMAs are calculated from the high point of tops and the low point of bottoms. They can act as a channel to evaluate price, and you can choose to color the channel using a gradient reflecting the advances/declines in the balance of your choice.
Divergence Channel is where you set up the appearance and behavior of the divergence channel. These areas represent levels where price and volume delta information do not converge. They can be interpreted as regions with no clear direction from where one will look for breaches. You can configure the channel to take into account one or both types of divergences you have configured for candle bodies and tops/bottoms.
Background allows you to configure a gradient background color that reflects the advances/declines in the balance of your choice. You can use this to provide context to the volume delta values from bars. You can also control the background color displayed on volume discrepancies between the intrabar and the chart's timeframe.
Intrabars is where you choose the calculation mode determining the lower timeframe used to access intrabars. The indicator uses the chart's timeframe and the type of market you are on to calculate the lower timeframe. Your setting there should reflect which compromise you prefer between the precision of calculations and chart coverage. This is also where you control the display of the information box in the lower right corner of the chart.
Markers allows you to control the plotting of chart markers on different conditions. Their configuration determines when alerts generated from the indicator will fire. Note that in order to generate alerts from this script, they must be created from your chart. See this Help Center page to learn how. Only the last 500 markers will be visible on the chart, but this will not affect the generation of alerts.
Periods is where you configure the periods for the balances and the EMAs used in the indicator.
The raw values calculated by this script can be inspected using the Data Window.
█ INTERPRETATION
Rightly or wrongly, volume delta is considered by many a useful complement to the interpretation of price action. I use it extensively in an attempt to find convergence between my read of volume delta and price movement — not so much as a predictor of future price movement. No system or person can predict the future. Accordingly, I consider people who speak or act as if they know the future with certainty to be dangerous to themselves and others; they are charlatans, imprudent or blissfully ignorant.
I try to avoid elaborate volume delta interpretation schemes involving too many variables and prefer to keep things simple:
• Trends that have more chances of continuing should be accompanied by VD of the same polarity.
In trends, I am looking for "slow and steady". I work from the assumption that traders and systems often overreact, which translates into unproductive volatility.
Wild trends are more susceptible to overreactions.
• I prefer steady VD values over wildly increasing ones, as large VD increases often come with increased price volatility, which can backfire.
Large VD values caused by stopping volume will also often occur on trend reversals with abnormally high candles.
• Prices escaping divergence channels may be leading a trend in that direction, although there is no telling how long that trend will last; could be just a few bars or hundreds.
When price is in a channel, shifts in VD balances can sometimes give us an idea of the direction where price has the most chance of breaking.
• Dwindling VD will often indicate trend exhaustion and predate reversals by many bars, but the problem is that mere pauses in a trend will often produce the same behavior in VD.
I think it is too perilous to infer rigidly from VD decreases.
Divergence Channel
Here I have configured the divergence channels to be visible. First, I set the bodies to display divergences on the default Bar Balance. They are indicated by yellow bodies. Then I activated the divergence channels by choosing to draw levels on body divergences and checked the "Fill" checkbox to fill the channel with the same color as the levels. The divergence channel is best understood as a direction-less area from where a breach can be acted on if other variables converge with the breach's direction:
Tops and Bottoms EMAs
I find these EMAs rather interesting. They have no equivalent elsewhere, as they are calculated from the top and bottom values this indicator plots. The only similarity they have with volume-weighted MAs, including VWAP, is that they use price and volume. This indicator's Tops and Bottoms EMAs, however, use the price and volume delta. While the channel differs from other channels in how it is calculated, it can be used like others, as a baseline from which to evaluate price movement or, alternatively, as stop levels. Remember that you can change the period used for the EMAs in the "Periods" section of the inputs.
This chart shows the EMAs in action, filled with a gradient representing the advances/decline from the Momentum balance. Notice the anomaly in the chart's latest bars where the Momentum balance gradient has been indicating a bullish bias for some time, during which price was mostly below the EMAs. Price has just broken above the channel on positive VD. My interpretation of this situation would be that it is a risky opportunity for a long trade in the larger context where the market has been in a downtrend since the 5th. Intrepid traders choosing to enter here could do so with a "make or break" tight stop that will minimize their losses should the market continue its downtrend while hopefully preserving the potential upside of price continuing on the longer-term uptrend prevalent since the 28th:
█ NOTES
Volume
If you use indicators such as this one which depends on volume information, it is important to realize that the volume data they consume comes from data feeds, and that all data feeds are NOT created equally. Those who create the data feeds we use must make decisions concerning the nature of the transactions they tally and the way they are tallied in each feed, and these decisions affect the nature of our volume data. My Volume X-ray publication discusses some of the reasons why volume information from different timeframes, brokers/exchanges or sectors may vary considerably. I encourage you to read it. This indicator's display of a warning through a background color on volume discrepancies between the timeframe used to access intrabars and the chart's timeframe is an attempt to help you realize these variations in feeds. Don't take things for granted, and understand that the quality of a given feed's volume information affects the quality of the results this indicator calculates.
Markets as ecosystems
I believe it is perilous to think that behavioral patterns you discover in one market through the lens of this or any other indicator will necessarily port to other markets. While this may sometimes be the case, it will often not. Why is that? Because each market is its own ecosystem. As cities do, all markets share some common characteristics, but they also all have their idiosyncrasies. A proportion of a city's inhabitants is always composed of outsiders who come and go, but a core population of regulars and systems is usually the force that actually defines most of the city's observable characteristics. I believe markets work somewhat the same way; they may look the same, but if you live there for a while and pay attention, you will notice the idiosyncrasies. Some things that work in some markets will, accordingly, not work in others. Please keep that in mind when you draw conclusions.
On Up/Down or Buy/Sell Volume
Buying or selling volume are misnomers, as every unit of volume transacted is both bought and sold by two different traders. While this does not keep me from using the terms, there is no such thing as “buy only” or “sell only” volume. Trader lingo is riddled with peculiarities. Without access to order book information, traders work with the assumption that when price moves up during a bar, there was more buying pressure than selling pressure, just as when buy market orders take out limit ask orders in the order book at successively higher levels. The built-in volume indicator available on TradingView uses this logic to color the volume columns green or red. While this script’s calculations are more precise because it analyses intrabars to calculate its information, it uses pretty much the same imperfect logic. Until Pine scripts can have access to how much volume was transacted at the bid/ask prices, our volume delta calculations will remain a mere proxy.
Repainting
• The values calculated on the realtime bar will update as new information comes from the feed.
• Historical values may recalculate if the historical feed is updated or when calculations start from a new point in history.
• Markers and alerts will not repaint as they only occur on a bar's close. Keep this in mind when viewing markers on historical bars,
where one could understandably and incorrectly assume they appear at the bar's open.
To learn more about repainting, see the Pine Script™ User Manual's page on the subject .
Superfluity
In "The Bed of Procrustes", Nassim Nicholas Taleb writes: To bankrupt a fool, give him information . This indicator can display a lot of information. The inevitable adaptation period you will need to figure out how to use it should help you eliminate all the visuals you do not need. The more you eliminate, the easier it will be to focus on those that are the most useful to your trading practice. Don't be a fool.
█ THANKS
Thanks to alexgrover for his Dekidaka-Ashi indicator. His volume plots on candles were the inspiration for my top/bottom plots.
Kudos to PineCoders for their libraries. I use two of them in this script: Time and lower_tf .
The first versions of this script used functionality that I would not have known about were it not for these two guys:
— A guy called Kuan who commented on a Backtest Rookies presentation of their Volume Profile indicator.
— theheirophant , my partner in the exploration of the sometimes weird abysses of request.security() ’s behavior at lower timeframes.
Great Expectations [LucF]Great Expectations helps traders answer the question: What is possible? It is a powerful question, yet exploration of the unknown always entails risk. A more complete set of questions better suited to traders could be:
What opportunity exists from any given point on a chart?
What portion of this opportunity can be realistically captured?
What risk will be incurred in trying to do so, and how long will it take?
Great Expectations is the result of an exploration of these questions. It is a trade simulator that generates visual and quantitative information to help strategy modelers visually identify and analyse areas of optimal expectation on charts, whether they are designing automated or discretionary strategies.
WARNING: Great Expectations is NOT an indicator that helps determine the current state of a market. It works by looking at points in the past from which the future is already known. It uses one definition of repainting extensively (i.e. it goes back in the past to print information that could not have been know at the time). Repainting understood that way is in fact almost all the indicator does! —albeit for what I hope is a noble cause. The indicator is of no use whatsoever in analyzing markets in real-time. If you do not understand what it does, please stay away!
This is an indicator—not a strategy that uses TradingView’s backtesting engine. It works by simulating trades, not unlike a backtest, but with the crucial difference that it assumes a trade (either long or short) is entered on all bars in the historic sample. It walks forward from each bar and determines possible outcomes, gathering individual trade statistics that in turn generate precious global statistics from all outcomes tested on the chart.
Great Expectations provides numbers summarizing trade results on all simulations run from the chart. Those numbers cannot be compared to backtest-produced numbers since all non-filtered bars are examined, even if an entry was taken on the bar immediately preceding the current one, which never happens in a backtest. This peculiarity does NOT invalidate Great Expectations calculations; it just entails that results be considered under a different light. Provided they are evaluated within the indicator’s context, they can be useful—sometimes even more than backtesting results, e.g. in evaluating the impact of parameter-fitting or variations in entry, exit or filtering strats.
Traders and strategy modelers are creatures of hope often suffering from blurred vision; my hope is that Great Expectations will help them appraise the validity of their setup and strat intuitions in a realistic fashion, preventing confirmation bias from obstructing perspective—and great expectations from turning into financial great deceptions.
USE CASES
You’ve identified what looks like a promising setup on other indicators. You load Great Expectations on the chart and evaluate if its high-expectation areas match locations where your setup’s conditions occur. Unless today is your lucky day, chances are the indicator will help you realize your setup is not as promising as you had hoped.
You want to get a rough estimate of the optimal trade duration for a chart and you don’t mind using the entry and exit strategies provided with the indicator. You use the trade length readouts of the indicator.
You’re experimenting with a new stop strategy and want to know how long it will keep you in trades, on average. You integrate your stop strategy in the indicator’s code and look at the average trade length it produces and the TST ratio to evaluate its performance.
You have put together your own entry and exit criteria and are looking for a filter that will help you improve backtesting results. You visually ascertain the suitability of your filter by looking at its results on the charts with great Expectations, to see if your filter is choosing its areas correctly.
You have a strategy that shows backtested trades on your chart. Great Expectations can help you evaluate how well your strategy is benefitting from high-opportunity areas while avoiding poor expectation spots.
You want more complete statistics on your set of strategies than what backtesting will provide. You use Great Expectations, knowing that it tests all bars in the sample that correspond to your criteria, as opposed to backtesting results which are limited to a subset of all possible entries.
You want to fool your friends into thinking you’ve designed the holy grail of indicators, something that identifies optimal opportunities on any chart; you show them the P&L cloud.
FEATURES
For one trade
At any given point on the chart, assuming a trade is entered there, Great Expectations shows you information specific to that trade simulation both on the chart and in the Data Window.
The chart can display:
the P & L Cloud which shows whether the trade ended profitably or not, and by how much,
the Opportunity & Risk Cloud which the maximum opportunity and risk the simulation encountered. When superimposed over the P & L cloud, you will see what I call the managed opportunity and risk, i.e the portion of maximum opportunity that was captured and the portion of the maximum risk that was incurred,
the target and if it was reached,
a background that uses a gradient to show different levels of trade length, P&L or how frequently the target was reached during simulation.
The Data Window displays more than 40 values on individual trades and global results. For any given trade you will know:
Entry/Exit levels, including slippage impact,
It’s outcome and duration,
P/L achieved,
The fraction of the maximum opportunity/risk managed by the trade.
For all trades
After going through all the possible trades on the chart, the indicator will provide you with a rare view of all outcomes expressed with the P&L cloud, which allows us to instantly see the most/least profitable areas of a chart using trade data as support, while also showing its relationship with the opportunity/risk encountered during the simulation. The difference between the two clouds is the managed opportunity and risk.
The Data Window will present you with numbers which we will go through later. Some of them are: average stop size, P/L, win rate, % opportunity managed, trade lengths for different types of trade outcomes and the TST (Target:Stop Travel) ratio.
Let’s see Great Expectations in action… and remember to open your Data Window!
INPUTS
Trade direction : You must first choose if you wish to look at long or short trades. Because of the way the indicator works and the amount of visual information on the chart, it is only practical to look at one type of trades at a time. The default is Longs.
Maximum trade Length (MaxL) : This is the maximum walk forward distance the simulator will go in analyzing outcomes from any given point in the past. It also determines the size of the dead zone among the chart’s last bars. A red background line identifies the beginning of the dead zone for which not enough bars have elapsed to analyze outcomes for the maximum trade length defined. If an ATR-based entry stop is used, that length is added to the wait time before beginning simulations, so that the first entry starts with a clean ATR value. On a sample of around 16000 bars, my tests show that the indicator runs into server errors at lengths of around 290, i.e. having completed ~4,6M simulation loop iterations. That is way too high a length anyways; 100 will usually be amply enough to ring out all the possibilities out of a simulation, and on shorter time frames, 30 can be enough. While making it unduly small will prevent simulations of expressing the market’s potential, the less you use, the faster the indicator will run. The default is 40.
Unrealized P&L base at End of Trade (EOT) : When a simulation ends and the trade is still open, we calculate unrealized P&L from an exit order executed from either the last in-trade stop on the previous bar, or the close of the last bar. You can readily see the impact of this selection on the chart, with the P&L cloud. The default is on the close.
Display : The check box besides the title does nothing.
Show target : Shows a green line displaying the trade’s target expressed as a multiple of X, i.e. the amplitude of the entry stop. I call this value “X” and use it as a unit to express profit and loss on a trade (some call it “R”). The line is highlighted for trades where the close reached the target during the trade, whether the trade ended in profit or loss. This is also where you specify the multiple of X you wish to use in calculating targets. The multiple is used even if targets are not displayed.
Show P&L Cloud : The cloud allows traders to see right away the profitable areas of the chart. The only line printed with the cloud is the “end of trade line” (EOT). The EOT line is the only way one can see the level where a trade ended on the chart (in the Data Window you can see it as the “Exit Fill” value). The EOT level for the trade determines if the trade ended in a profit or a loss. Its value represents one of the following:
- fill from order executed at close of bar where stop is breached during trade (which produces “Realized P/L”),
- simulation of a fill pseudo-fill at the user-defined EOT level (last close or stop level) if the trade runs its course through MaxL bars without getting stopped (producing Unrealized P/L).
The EOT line and the cloud fill print in green when the trade’s outcome is profitable and in red when it is not. If the trade was closed after breaching the stop, the line appears brighter.
Show Opportunity&Risk Cloud : Displays the maximum opportunity/risk that was present during the trade, i.e. the maximum and minimum prices reached.
Background Color Scheme : Allows you to choose between 3 different color schemes for the background gradients, to accommodate different types of chart background/candles. Select “None” if you don’t want a background.
Background source : Determines what value will be used to generate the different intensities of the gradient. You can choose trade length (brighter is shorter), Trade P&L (brighter is higher) or the number of times the target was reached during simulation (brighter is higher). The default is Trade Length.
Entry strat : The check box besides the title does nothing. The default strat is All bars, meaning a trade will be simulated from all bars not excluded by the filters where a MaxL bars future exists. For fun, I’ve included a pseudo-random entry strat (an indirect way of changing the seed is to vary the starting date of the simulation).
Show Filter State : Displays areas where the combination of filters you have selected are allowing entries. Filtering occurs as per your selection(s), whether the state is displayed or not. The effect of multiple selections is additive. The filters are:
1. Bar direction: Longs will only be entered if close>open and vice versa.
2. Rising Volume: Applies to both long and shorts.
3. Rising/falling MA of the length you choose over the number of bars you choose.
4. Custom indicator: You can feed your own filtering signal through this from another indicator. It must produce a signal of 1 to allow long entries and 0 to allow shorts.
Show Entry Stops :
1. Multiple of user-defined length ATR.
2. Fixed percentage.
3. Fixed value.
All entry stops are calculated using the entry fill price as a reference. The fill price is calculated from the current bar’s open, to which slippage is added if configured. This simulates the case where the strategy issued the entry signal on the previous bar for it to be executed at the next bar’s open.
The entry stop remains active until the in-trade stop becomes the more aggressive of the two stops. From then on, the entry stop will be ignored, unless a bar close breaches the in-trade stop, in which case the stop will be reset with a new entry stop and the process repeats.
Show In-trade stops : Displays in bright red the selected in-trade stop (be sure to read the note in this section about them).
1. ATR multiple: added/subtracted from the average of the two previous bars minimum/maximum of open/close.
2. A trailing stop with a deviation expressed as a multiple of entry stop (X).
3. A fixed percentage trailing stop.
Trailing stops deviations are measured from the highest/lowest high/low reached during the trade.
Note: There is a twist with the in-trade stops. It’s that for any given bar, its in-trade stop can hold multiple values, as each successive pass of the advancing simulation loops goes over it from a different entry points. What is printed is the stop from the loop that ended on that bar, which may have nothing to do with other instances of the trade’s in-trade stop for the same bar when visited from other starting points in previous simulations. There is just no practical way to print all stop values that were used for any given bar. While the printed entry stops are the actual ones used on each bar, the in-trade stops shown are merely the last instance used among many.
Include Slippage : if checked, slippage will be added/subtracted from order price to yield the fill price. Slippage is in percentage. If you choose to include slippage in the simulations, remember to adjust it by considering the liquidity of the markets and the time frame you’ll be analyzing.
Include Fees : if checked, fees will be subtracted/added to both realized an unrealized trade profits/losses. Fees are in percentage. The default fees work well for crypto markets but will need adjusting for others—especially in Forex. Remember to modify them accordingly as they can have a major impact on results. Both fees and slippage are included to remind us of their importance, even if the global numbers produced by the indicator are not representative of a real trading scenario composed of sequential trades.
Date Range filtering : the usual. Just note that the checkbox has to be selected for date filtering to activate.
DATA WINDOW
Most of the information produced by this indicator is made available in the Data Window, which you bring up by using the icon below the Watchlist and Alerts buttons at the right of the TV UI. Here’s what’s there.
Some of the information presented in the Data Window is standard trade data; other values are not so standard; e. g. the notions of managed opportunity and risk and Target:Stop Travel ratio. The interplay between all the values provided by Great Expectations is inherently complex, even for a static set of entry/filter/exit strats. During the constant updating which the habitual process of progressive refinement in building strategies that is the lot of strategy modelers entails, another level of complexity is no doubt added to the analysis of this indicator’s values. While I don’t want to sound like Wolfram presenting A New Kind of Science , I do believe that if you are a serious strategy modeler and spend the time required to get used to using all the information this indicator makes available, you may find it useful.
Trade Information
Entry Order : This is the open of the bar where simulation starts. We suppose that an entry signal was generated at the previous bar.
Entry Fill (including slip.) : The actual entry price, including slippage. This is the base price from which other values will be calculated.
Exit Order : When a stop is breached, an exit order is executed from the close of the bar that breached the stop. While there is no “In-trade stop” value included in the Data Window (other than the End of trade Stop previously discussed), this “Exit Order” value is how we can know the level where the trade was stopped during the simulation. The “Trade Length” value will then show the bar where the stop was breached.
Exit Fill (including slip.) : When the exit order is simulated, slippage is added to the order level to create the fill.
Chart: Target : This is the target calculated at the beginning of the simulation. This value also appear on the chart in teal. It is controlled by the multiple of X defined under the “Show Target” checkbox in the Inputs.
Chart: Entry Stop : This value also appears on the chart (the red dots under points where a trade was simulated). Its value is controlled by the Entry Strat chosen in the Inputs.
X (% Fill, including Fees) and X (currency) : This is the stop’s amplitude (Entry Fill – Entry Stop) + Fees. It represents the risk incurred upon entry and will be used to express P&L. We will show R expressed in both a percentage of the Entry Fill level (this value), and currency (the next value). This value represents the risk in the risk:reward ratio and is considered to be a unit of 1 so that RR can be expressed as a single value (i.e. “2” actually meaning “1:2”).
Trade Length : If trade was stopped, it’s the number of bars elapsed until then. The trade is then considered “Closed”. If the trade ends without being stopped (there is no profit-taking strat implemented, so the stop is the only exit strat), then the trade is “Open”, the length is MaxL and it will show in orange. Otherwise the value will print in green/red to reflect if the trade is winning/losing.
P&L (X) : The P&L of the trade, expressed as a multiple of X, which takes into account fees paid at entry and exit. Given our default target setting at 2 units of “X”, a trade that closes at its target will have produced a P&L of +2.0, i.e. twice the value of X (not counting fees paid at exit ). A trade that gets stopped late 50% further that the entry stop’s level will produce a P&L of -1.5X.
P&L (currency, including Fees) : same value as above, but expressed in currency.
Target first reached at bar : If price closed above the target during the trade (even if it occurs after the trade was stopped), this will show when. This value will be used in calculating our TST ratio.
Times Stop/Target reached in sim. : Includes all occurrences during the complete simulation loop.
Opportunity (X) : The highest/lowest price reached during a simulation, i.e. the maximum opportunity encountered, whether the trade was previously stopped or not, expressed as a multiple of X.
Risk (X) : The lowest/highest price reached during a simulation, i.e. the maximum risk encountered, whether the trade was previously stopped or not, expressed as a multiple of X.
Risk:Opportunity : The greater this ratio, the greater Opportunity is, compared to Risk.
Managed Opportunity (%) : The portion of Opportunity that was captured by the highest/low stop position, even if it occurred after a previous stop closed the trade.
Managed Risk (%) : The portion of risk that was protected by the lowest/highest stop position, even if it occurred after a previous stop closed the trade. When this value is greater than 100%, it means the trade’s stop is protecting more than the maximum risk, which is frequent. You will, however, never see close to those values for the Managed Opportunity value, since the stop would have to be higher than the Maximum opportunity. It is much easier to alleviate the risk than it is to lock in profits.
Managed Risk:Opportunity : The ratio of the two preceding values.
Managed Opp. vs. Risk : The Managed Opportunity minus the Managed Risk. When it is negative, which is most often is, it means your strat is protecting a greater portion of the risk than it captures opportunity.
Global Numbers
Win Rate(%) : Percentage of winning trades over all entries. Open trades are considered winning if their last stop/close (as per user selection) locks in profits.
Avg X%, Avg X (currency) : Averages of previously described values:.
Avg Profitability/Trade (APPT) : This measures expectation using: Average Profitability Per Trade = (Probability of Win × Average Win) − (Probability of Loss × Average Loss) . It quantifies the average expectation/trade, which RR alone can’t do, as the probabilities of each outcome (win/lose) must also be used to calculate expectancy. The APPT combine the RR with the win rate to yield the true expectancy of a strategy. In my usual way of expressing risk with X, APPT is the equivalent of the average P&L per trade expressed in X. An APPT of -1.5 means that we lose on average 1.5X/trade.
Equity (X), Equity (currency) : The cumulative result of all trade outcomes, expressed as a multiple of X. Multiplied by the Average X in currency, this yields the Equity in currency.
Risk:Opportunity, Managed Risk:Opportunity, Managed Opp. vs. Risk : The global values of the ones previously described.
Avg Trade Length (TL) : One of the most important values derived by going through all the simulations. Again, it is composed of either the length of stopped trades, or MaxL when the trade isn’t stopped (open). This value can help systems modelers shape the characteristics of the components they use to build their strategies.
Avg Closed Win TL and Avg Closed Lose TL : The average lengths of winning/losing trades that were stopped.
Target reached? Avg bars to Stop and Target reached? Avg bars to Target : For the trades where the target was reached at some point in the simulation, the number of bars to the first point where the stop was breached and where the target was reached, respectively. These two values are used to calculate the next value.
TST (Target:Stop Travel Ratio) : This tracks the ratio between the two preceding values (Bars to first stop/Bars to first target), but only for trades where the target was reached somewhere in the loop. A ratio of 2 means targets are reached twice as fast as stops.
The next values of this section are counts or percentages and are self-explanatory.
Chart Plots
Contains chart plots of values already describes.
NOTES
Optimization/Overfitting: There is a fine line between optimizing and overfitting. Tools like this indicator can lead unsuspecting modelers down a path of overfitting that often turns strategies into over-specialized beasts that do not perform elegantly when confronted to the real-world. Proven testing strategies like walk forward analysis will go a long way in helping modelers alleviate this risk.
Input tuning: Because the results generated by the indicator will vary with the parameters used in the active entry, filtering and exit strats, it’s important to realize that although it may be fun at first, just slapping the default settings on a chart and time frame will not yield optimal nor reliable results. While using ATR as often as possible (as I do in this indicator) is a good way to make strat parametrization adaptable, it is not a foolproof solution.
There is no data for the last MaxL bars of the chart, since not enough trade future has elapsed to run a simulation from MaxL bars back.
Modifying the code: I have tried to structure the code modularly, even if that entails a larger code base, so that you can adapt it to your needs. I’ve included a few token components in each of the placeholders designed for entry strategies, filters, entry stops and in-trade stops. This will hopefully make it easier to add your own. In the same spirit, I have also commented liberally.
You will find in the code many instances of standard trade management tasks that can be lifted to code TV strategies where, as I do in mine, you manage everything yourself and don’t rely on built-in Pine strategy functions to act on your trades.
Enjoy!
THANKS
To @scarf who showed me how plotchar() could be used to plot values without ruining scale.
To @glaz for the suggestion to include a Chandelier stop strat; I will.
To @simpelyfe for the idea of using an indicator input for the filters (if some day TV lets us use more than one, it will be useful in other modules of the indicator).
To @RicardoSantos for the random generator used in the random entry strat.
To all scripters publishing open source on TradingView; their code is the best way to learn.
To my trading buddies Irving and Bruno; who showed me way back how pro traders get it done.
FA_PA_LIBLibrary "FA_PA_LIB"
A collection of custom tools & utility functions commonly used for coding Dr Al Brooks, Price Action System with my scripts
getBodySize()
Gets the current candle's body size (in POINTS, divide by 10 to get pips)
Returns: The current candle's body size in POINTS
getTopWickSize()
Gets the current candle's top wick size (in POINTS, divide by 10 to get pips)
Returns: The current candle's top wick size in POINTS
getTopWickPercent()
Gets the current candle's top wick size (in POINTS, divide by 10 to get pips)
Returns: Percent of total candle width that is occupied by the upper wick
getBottomWickSize()
Gets the current candle's bottom wick size (in POINTS, divide by 10 to get pips)
Returns: The current candle's bottom wick size in POINTS
getBottomWickPercent()
Gets the current candle's bottom wick size (in POINTS, divide by 10 to get pips)
Returns: Percent of total candle width that is occupied by the lower wick
getBarMidPoint()
Gets the current candle's midpoint wick to wick
Returns: The current candle's mid point
getBodyPercent()
Gets the current candle's body size as a percentage of its entire size including its wicks
Returns: The current candle's body size percentage (00.00)
bullFib(priceLow, priceHigh, fibRatio)
Calculates a bullish fibonacci value
Parameters:
priceLow (float) : The lowest price point
priceHigh (float) : The highest price point
fibRatio (float) : The fibonacci % ratio to calculate
Returns: The fibonacci value of the given ratio between the two price points
bearFib(priceLow, priceHigh, fibRatio)
Calculates a bearish fibonacci value
Parameters:
priceLow (float) : The lowest price point
priceHigh (float) : The highest price point
fibRatio (float) : The fibonacci % ratio to calculate
Returns: The fibonacci value of the given ratio between the two price points
isBr()
Checks if the current bar is a Bear Bar
Returns: A boolean - true if the current bar is bear candle
isBl()
Checks if the current bar is a Bull Bar
Returns: A boolean - true if the current bar is Bull candle
isTrendBar()
Checks if the current bar is a Trend Bar. Candle that its body size is greater than 50% of entire candle size
Returns: A boolean - true if the current bar is Trend candle
isBlTrendBar()
Checks if the current bar is a Bull Trend Bar. Bullish candle that its body size is greater than 50% of entire candle size
Returns: A boolean - true if the current bar is Bull Trend candle
isBrTrendBar()
Checks if the current bar is a Bull Trend Bar. Bullish candle that its body size is greater than 50% of entire candle size
Returns: A boolean - true if the current bar is Bull Trend candle
isBlRevB()
Checks if the current bar is a Bull Reversal Bar. Bullish candle that closes on upper half of candle body
Returns: A boolean - true if the current bar is Bull Reversal candle
isBrRevB()
Checks if the current bar is a Bear Reversal Bar. BulBearish candle that closes on lower half of candle body
Returns: A boolean - true if the current bar is Bear Reversal candle
isDoji(wickSize, bodySize)
Checks if the current bar is a doji candle based on the given parameters
Parameters:
wickSize (float) : (default=2) The maximum top wick size compared to the bottom (and vice versa)
bodySize (float) : (default=0.05) The maximum body size as a percentage compared to the entire candle size
Returns: A boolean - true if the current bar matches the requirements of a doji candle
isHammer(fib, colorMatch)
Checks if the current bar is a hammer candle based on the given parameters
Parameters:
fib (float) : (default=0.382) The fib to base candle body on
colorMatch (bool) : (default=true) Does the candle need to be green? (true/false)
Returns: A boolean - true if the current bar matches the requirements of a hammer candle
isStar(fib, colorMatch)
Checks if the current bar is a shooting star candle based on the given parameters
Parameters:
fib (float) : (default=0.382) The fib to base candle body on
colorMatch (bool) : (default=false) Does the candle need to be red? (true/false)
Returns: A boolean - true if the current bar matches the requirements of a shooting star candle
isBlOB()
Detects Bullish outside bars(OB)
Returns: Returns true if the current bar is a bull outside bar
isBrOB()
Detects Bearish outside bars(OB)
Returns: Returns true if the current bar is a bear outside bar
NextBarColorNextBarColor
This is two-bars pattern search/matching indicator.
This indicator compares multiple values:
current bar high with previous bar open
current bar high with previous bar close
current bar high with previous bar high
current bar high with previous bar low
current bar low with previous bar open
current bar low with previous bar close
current bar low with previous bar high
current bar low with previous bar low
current bar close/current_price with previous bar high
current bar close/current_price with previous bar low
current bar close/current_price with previous bar open
current bar close/current_price with previous bar close
and searches for the same combination of 2 bars (current and previous) in the past.
Then shows as % value how many times the next bar went up or down.
Grey bar compares ups and downs with all results, including cases when price did not move.
My testing is showing better results when current and previous bars colors are also used in the search.
Volume Spread Analysis [TANHEF]Volume Spread Analysis: Understanding Market Intentions through the Interpretation of Volume and Price Movements.
█ Simple Explanation:
The Volume Spread Analysis (VSA) indicator is a comprehensive tool that helps traders identify key market patterns and trends based on volume and spread data. This indicator highlights significant VSA patterns and provides insights into market behavior through color-coded volume/spread bars and identification of bars indicating strength, weakness, and neutrality between buyers and sellers. It also includes powerful volume and spread forecasting capabilities.
█ Laws of Volume Spread Analysis (VSA):
The origin of VSA begins with Richard Wyckoff, a pivotal figure in its development. Wyckoff made significant contributions to trading theory, including the formulation of three basic laws:
The Law of Supply and Demand: This fundamental law states that supply and demand balance each other over time. High demand and low supply lead to rising prices until demand falls to a level where supply can meet it. Conversely, low demand and high supply cause prices to fall until demand increases enough to absorb the excess supply.
The Law of Cause and Effect: This law assumes that a 'cause' will result in an 'effect' proportional to the 'cause'. A strong 'cause' will lead to a strong trend (effect), while a weak 'cause' will lead to a weak trend.
The Law of Effort vs. Result: This law asserts that the result should reflect the effort exerted. In trading terms, a large volume should result in a significant price move (spread). If the spread is small, the volume should also be small. Any deviation from this pattern is considered an anomaly.
█ Volume and Spread Analysis Bars:
Display: Volume and/or spread bars that consist of color coded levels. If both of these are displayed, the number of spread bars can be limited for visual appeal and understanding, with the spread bars scaled to match the volume bars. While automatic calculation of the number of visual bars for auto scaling is possible, it is avoided to prevent the indicator from reloading whenever the number of visual price bars on the chart is adjusted, ensuring uninterrupted analysis. A displayable table (Legend) of bar colors and levels can give context and clarify to each volume/spread bar.
Calculation: Levels are calculated using multipliers applied to moving averages to represent key levels based on historical data: low, normal, high, ultra. This method smooths out short-term fluctuations and focuses on longer-term trends.
Low Level: Indicates reduced volatility and market interest.
Normal Level: Reflects typical market activity and volatility.
High Level: Indicates increased activity and volatility.
Ultra Level: Identifies extreme levels of activity and volatility.
This illustrates the appearance of Volume and Spread bars when scaled and plotted together:
█ Forecasting Capabilities:
Display: Forecasted volume and spread levels using predictive models.
Calculation: Volume and Spread prediction calculations differ as volume is linear and spread is non-linear.
Volume Forecast (Linear Forecasting): Predicts future volume based on current volume rate and bar time till close.
Spread Forecast (Non-Linear Dynamic Forecasting): Predicts future spread using a dynamic multiplier, less near midpoint (consolidation) and more near low or high (trending), reflecting non-linear expansion.
Moving Averages: In forecasting, moving averages utilize forecasted levels instead of actual levels to ensure the correct level is forecasted (low, normal, high, or ultra).
The following compares forecasted volume with actual resulting volume, highlighting the power of early identifying increased volume through forecasted levels:
█ VSA Patterns:
Criteria and descriptions for each VSA pattern are available as tooltips beside them within the indicator’s settings. These tooltips provide explanations of potential developments based on the volume and spread data.
Signs of Strength (🟢): Patterns indicating strong buying pressure and potential market upturns.
Down Thrust
Selling Climax
No Effort → Bearish Result
Bearish Effort → No Result
Inverse Down Thrust
Failed Selling Climax
Bull Outside Reversal
End of Falling Market (Bag Holder)
Pseudo Down Thrust
No Supply
Signs of Weakness (🔴): Patterns indicating strong selling pressure and potential market downturns.
Up Thrust
Buying Climax
No Effort → Bullish Result
Bullish Effort → No Result
Inverse Up Thrust
Failed Buying Climax
Bear Outside Reversal
End of Rising Market (Bag Seller)
Pseudo Up Thrust
No Demand
Neutral Patterns (🔵): Patterns indicating market indecision and potential for continuation or reversal.
Quiet Doji
Balanced Doji
Strong Doji
Quiet Spinning Top
Balanced Spinning Top
Strong Spinning Top
Quiet High Wave
Balanced High Wave
Strong High Wave
Consolidation
Bar Patterns (🟡): Common candlestick patterns that offer insights into market sentiment. These are required in some VSA patterns and can also be displayed independently.
Bull Pin Bar
Bear Pin Bar
Doji
Spinning Top
High Wave
Consolidation
This demonstrates the acronym and descriptive options for displaying bar patterns, with the ability to hover over text to reveal the descriptive text along with what type of pattern:
█ Alerts:
VSA Pattern Alerts: Notifications for identified VSA patterns at bar close.
Volume and Spread Alerts: Alerts for confirmed and forecasted volume/spread levels (Low, High, Ultra).
Forecasted Volume and Spread Alerts: Alerts for forecasted volume/spread levels (High, Ultra) include a minimum percent time elapsed input to reduce false early signals by ensuring sufficient bar time has passed.
█ Inputs and Settings:
Display Volume and/or Spread: Choose between displaying volume bars, spread bars, or both with different lookback periods.
Indicator Bar Color: Select color schemes for bars (Normal, Detail, Levels).
Indicator Moving Average Color: Select schemes for bars (Fill, Lines, None).
Price Bar Colors: Options to color price bars based on VSA patterns and volume levels.
Legend: Display a table of bar colors and levels for context and clarity of volume/spread bars.
Forecast: Configure forecast display and prediction details for volume and spread.
Average Multipliers: Define multipliers for different levels (Low, High, Ultra) to refine the analysis.
Moving Average: Set volume and spread moving average settings.
VSA: Select the VSA patterns to be calculated and displayed (Strength, Weakness, Neutral).
Bar Patterns: Criteria for bar patterns used in VSA (Doji, Bull Pin Bar, Bear Pin Bar, Spinning Top, Consolidation, High Wave).
Colors: Set exact colors used for indicator bars, indicator moving averages, and price bars.
More Display Options: Specify how VSA pattern text is displayed (Acronym, Descriptive), positioning, and sizes.
Alerts: Configure alerts for VSA patterns, volume, and spread levels, including forecasted levels.
█ Usage:
The Volume Spread Analysis indicator is a helpful tool for leveraging volume spread analysis to make informed trading decisions. It offers comprehensive visual and textual cues on the chart, making it easier to identify market conditions, potential reversals, and continuations. Whether analyzing historical data or forecasting future trends, this indicator provides insights into the underlying factors driving market movements.
VolumeSpreadAnalysisLibrary "VolumeSpreadAnalysis"
A library for Volume Spread Analysis (VSA).
spread(_barIndex)
Calculates the spread of a bar.
Parameters:
_barIndex (int) : (int) The index of the bar.
Returns: (float) The spread of the bar.
volume(_barIndex)
Retrieves the volume of a bar.
Parameters:
_barIndex (int) : (int) The index of the bar.
Returns: (float) The volume of the bar.
body(_barIndex)
Calculates the body of a bar.
Parameters:
_barIndex (simple int) : (int) The index of the bar.
Returns: (float) The body size of the bar.
wickUpper(_barIndex)
Calculates the upper wick of a bar (upper shadow).
Parameters:
_barIndex (simple int) : (int) The index of the bar.
Returns: (float) The upper wick size of the bar.
wickLower(_barIndex)
Calculates the lower wick of a bar (lower shadow).
Parameters:
_barIndex (simple int) : (int) The index of the bar.
Returns: (float) The lower wick size of the bar.
calcForecastedSMA(_source, _length, _forecastedLevel)
Calculates the forecasted Simple Moving Average (SMA).
Parameters:
_source (float) : (series float) Source data for calculation.
_length (simple int) : (int) The length of the SMA.
_forecastedLevel (float) : (float) The forecasted level to include in the calculation.
Returns: (float) The forecasted SMA value.
calcForecastedEMA(_source, _length, _forecastedLevel)
Calculates the forecasted Exponential Moving Average (EMA).
Parameters:
_source (float) : (series float) Source data for calculation.
_length (simple int) : (int) The length of the EMA.
_forecastedLevel (float) : (float) The forecasted level to include in the calculation.
Returns: (float) The forecasted EMA value.
calcForecastedRMA(_source, _length, _forecastedLevel)
Calculates the forecasted Relative Moving Average (RMA).
Parameters:
_source (float) : (series float) Source data for calculation.
_length (simple int) : (int) The length of the RMA.
_forecastedLevel (float) : (float) The forecasted level to include in the calculation.
Returns: (float) The forecasted RMA value.
calcForecastedWMA(_source, _length, _forecastedLevel)
Calculates the forecasted Weighted Moving Average (WMA).
Parameters:
_source (float) : (series float) Source data for calculation.
_length (simple int) : (int) The length of the WMA.
_forecastedLevel (float) : (float) The forecasted level to include in the calculation.
Returns: (float) The forecasted WMA value.
calcElapsedTimePercent()
Calculates the elapsed time percent of the current bar.
Returns: (float) The elapsed time percent.
calcForecastedSpread(multiplierAtMidpoints, multiplierAtPeaks)
Calculates the forecasted spread using elapsed time and dynamic multipliers, handling spread's non-linear nature.
Parameters:
multiplierAtMidpoints (float) : (float) The multiplier value at midpoints.
multiplierAtPeaks (float) : (float) The multiplier value at peaks.
Returns: (float) The forecasted spread value.
calcForecastedVolume()
Calculates the forecasted volume using elapsed time, satisfying volume's linear nature.
Returns: (float) The forecasted volume value.
calcForecastedMA(_source, _length, _forecastedSource, _type)
Calculates the forecasted Moving Average (MA) based on the specified type.
Parameters:
_source (float) : (series float) Source data for calculation.
_length (simple int) : (int) The length of the MA.
_forecastedSource (float) : (float) The forecasted level to include in the calculation.
_type (simple string) : (string) The type of the MA ("SMA", "EMA", "SMMA (RMA)", "WMA").
Returns: (float) The forecasted MA value.
calcMA(_source, _length, _type)
Calculates the Moving Average (MA) based on the specified type.
Parameters:
_source (float) : (series float) Source data for calculation.
_length (simple int) : (int) The length of the MA.
_type (simple string) : (string) The type of the MA ("SMA", "EMA", "SMMA (RMA)", "WMA").
Returns: (float) The MA value.
bullBar(_barIndex)
Determines if the bar is bullish.
Parameters:
_barIndex (simple int) : (int) The index of the bar.
Returns: (bool) True if the bar is bullish, otherwise false.
bearBar(_barIndex)
Determines if the bar is bearish.
Parameters:
_barIndex (simple int) : (int) The index of the bar.
Returns: (bool) True if the bar is bearish, otherwise false.
breakout(_barIndex)
Determines if there is a breakout above the previous bar.
Parameters:
_barIndex (simple int) : (int) The index of the bar.
Returns: (bool) True if there is a breakout, otherwise false.
breakdown(_barIndex)
Determines if there is a breakdown below the previous bar.
Parameters:
_barIndex (simple int) : (int) The index of the bar.
Returns: (bool) True if there is a breakdown, otherwise false.
rejectionWickUpper(_rejectionWick)
Determines if the upper wick is a rejection wick.
Parameters:
_rejectionWick (simple float) : (float) The rejection wick percentage.
Returns: (bool) True if the upper wick is a rejection wick, otherwise false.
rejectionWickLower(_rejectionWick)
Determines if the lower wick is a rejection wick.
Parameters:
_rejectionWick (simple float) : (float) The rejection wick percentage.
Returns: (bool) True if the lower wick is a rejection wick, otherwise false.
setupDataVolume(_data, _mult_Low, _mult_High, _mult_Ultra, _maLengthVolume, _maTypeVolume)
Sets up data for volume levels.
Parameters:
_data (map) : (map) The map to store the levels.
_mult_Low (simple float) : (float) The multiplier for low level.
_mult_High (simple float) : (float) The multiplier for high level.
_mult_Ultra (simple float) : (float) The multiplier for ultra level.
_maLengthVolume (simple int) : (int) The length for MA.
_maTypeVolume (simple string) : (string) The type for MA.
Returns: (void) Nothing.
setupDataSpread(_data, _mult_Low, _mult_High, _mult_Ultra, _maLengthSpread, _maTypeSpread)
Sets up data for spread levels.
Parameters:
_data (map) : (map) The map to store the levels.
_mult_Low (simple float) : (float) The multiplier for low level.
_mult_High (simple float) : (float) The multiplier for high level.
_mult_Ultra (simple float) : (float) The multiplier for ultra level.
_maLengthSpread (simple int) : (int) The length for MA.
_maTypeSpread (simple string) : (string) The type for MA.
Returns: (void) Nothing.
setupDataForecastVolume(_dataForecast, _mult_Low, _mult_High, _mult_Ultra, _maLengthVolume, _predictedLevelVolume, _maTypeVolume)
Sets up data for volume and spread levels for forecast.
Parameters:
_dataForecast (map)
_mult_Low (simple float) : (float) The multiplier for low level.
_mult_High (simple float) : (float) The multiplier for high level.
_mult_Ultra (simple float) : (float) The multiplier for ultra level.
_maLengthVolume (simple int) : (int) The length for MA.
_predictedLevelVolume (float) : (float) The predicted level for MA.
_maTypeVolume (simple string) : (string) The type for MA.
Returns: (void) Nothing.
setupDataForecastSpread(_dataForecast, _mult_Low, _mult_High, _mult_Ultra, _maLengthSpread, _predictedLevelSpread, _maTypeSpread)
Sets up data for spread levels for forecast.
Parameters:
_dataForecast (map)
_mult_Low (simple float) : (float) The multiplier for low level.
_mult_High (simple float) : (float) The multiplier for high level.
_mult_Ultra (simple float) : (float) The multiplier for ultra level.
_maLengthSpread (simple int) : (int) The length for MA.
_predictedLevelSpread (float) : (float) The predicted level for MA.
_maTypeSpread (simple string) : (string) The type for MA.
Returns: (void) Nothing.
isVolumeLow(_data, _barIndex)
Determines if the volume is low.
Parameters:
_data (map) : (map) The data map with volume levels.
_barIndex (int)
Returns: (bool) True if the volume is low, otherwise false.
isVolumeNormal(_data, _barIndex)
Determines if the volume is normal.
Parameters:
_data (map) : (map) The data map with volume levels.
_barIndex (int)
Returns: (bool) True if the volume is normal, otherwise false.
isVolumeHigh(_data, _barIndex)
Determines if the volume is high.
Parameters:
_data (map) : (map) The data map with volume levels.
_barIndex (int)
Returns: (bool) True if the volume is high, otherwise false.
isVolumeUltra(_data, _barIndex)
Determines if the volume is ultra.
Parameters:
_data (map) : (map) The data map with volume levels.
_barIndex (int)
Returns: (bool) True if the volume is ultra, otherwise false.
isSpreadLow(_data, _barIndex)
Determines if the spread is low.
Parameters:
_data (map) : (map) The data map with spread levels.
_barIndex (int)
Returns: (bool) True if the spread is low, otherwise false.
isSpreadNormal(_data, _barIndex)
Determines if the spread is normal.
Parameters:
_data (map) : (map) The data map with spread levels.
_barIndex (int)
Returns: (bool) True if the spread is normal, otherwise false.
isSpreadHigh(_data, _barIndex)
Determines if the spread is high.
Parameters:
_data (map) : (map) The data map with spread levels.
_barIndex (int)
Returns: (bool) True if the spread is high, otherwise false.
isSpreadUltra(_data, _barIndex)
Determines if the spread is ultra.
Parameters:
_data (map) : (map) The data map with spread levels.
_barIndex (int)
Returns: (bool) True if the spread is ultra, otherwise false.
isVolumeText(_data)
Determines text string representing the volume area level.
Parameters:
_data (map) : (map) The data map with volume levels.
Returns: (string) Text string of Low, Normal, High, or Ultra.
isSpreadText(_data)
Determines text string representing the spread area level.
Parameters:
_data (map) : (map) The data map with spread levels.
Returns: (string) Text string of Low, Normal, High, or Ultra.
calcBarColor(_value, _level)
Calculates the color based level.
Parameters:
_value (float) : (float) The value to check.
_level (float) : (float) The value level for comparison.
Returns: (color) The color for the bar.
bullPinBar(_maxBodyPercent, _minWickPercent)
Determines if the bar is a bull pin bar.
Parameters:
_maxBodyPercent (simple float) : (float) The maximum body percentage.
_minWickPercent (simple float) : (float) The minimum wick percentage.
Returns: (bool) True if the bar is a bull pin bar, otherwise false.
bearPinBar(_maxBodyPercent, _minWickPercent)
Determines if the bar is a bear pin bar.
Parameters:
_maxBodyPercent (simple float) : (float) The maximum body percentage.
_minWickPercent (simple float) : (float) The minimum wick percentage.
Returns: (bool) True if the bar is a bear pin bar, otherwise false.
dojiBar(_maxBodyPercent)
Determines if the bar is a doji.
Parameters:
_maxBodyPercent (simple float) : (float) The maximum body percentage.
Returns: (bool) True if the bar is a doji, otherwise false.
spinningTopBar(_minWicksPercent, _emaLength)
Determines if the bar is a spinning top.
Parameters:
_minWicksPercent (simple float) : (float) The minimum wicks percentage.
_emaLength (simple int) : (int) The length for EMA calculation.
Returns: (bool) True if the bar is a spinning top, otherwise false.
highWaveBar(_minBodyPercent, _minWickPercent, _bars)
Determines if the bar is a high wave bar.
Parameters:
_minBodyPercent (simple float) : (float) The minimum body percentage.
_minWickPercent (simple float) : (float) The minimum wick percentage.
_bars (simple int) : (int) The number of bars for comparison.
Returns: (bool) True if the bar is a high wave bar, otherwise false.
consolidationBar(_data, _spread, _bars)
Determines if the bars are in consolidation.
Parameters:
_data (map) : (map) The data map with spread levels.
_spread (simple float) : (float) The spread percentage for comparison.
_bars (simple int) : (int) The number of bars for comparison.
Returns: (bool) True if the bars are in consolidation, otherwise false.
S_DownThrust(_data, _bullPinBarMaxBody, _bullPinBarMinWick)
Determines if there is a sign of strength (DownThrust).
Parameters:
_data (map) : (map) The data map with volume and spread levels.
_bullPinBarMaxBody (simple float) : (float) The maximum body percentage for bull pin bar.
_bullPinBarMinWick (simple float) : (float) The minimum wick percentage for bull pin bar.
Returns: (bool) True if there is a sign of strength (DownThrust), otherwise false.
S_SellingClimax(_data, _rejectionWick)
Determines if there is a sign of strength (Selling Climax).
Parameters:
_data (map) : (map) The data map with volume and spread levels.
_rejectionWick (simple float) : (float) The rejection wick percentage.
Returns: (bool) True if there is a sign of strength (Selling Climax), otherwise false.
S_NoEffortBearishResult()
Determines if there is a sign of strength (No Effort Bearish Result).
Returns: (bool) True if there is a sign of strength (No Effort Bearish Result), otherwise false.
S_BearishEffortNoResult()
Determines if there is a sign of strength (Bearish Effort No Result).
Returns: (bool) True if there is a sign of strength (Bearish Effort No Result), otherwise false.
S_InverseDownThrust(_data, _bearPinBarMaxBody, _bearPinBarMinWick)
Determines if there is a sign of strength (Inverse DownThrust).
Parameters:
_data (map) : (map) The data map with volume and spread levels.
_bearPinBarMaxBody (simple float) : (float) The maximum body percentage for bear pin bar.
_bearPinBarMinWick (simple float) : (float) The minimum wick percentage for bear pin bar.
Returns: (bool) True if there is a sign of strength (Inverse DownThrust), otherwise false.
S_FailedSellingClimax()
Determines if there is a sign of strength (Failed Selling Climax).
Returns: (bool) True if there is a sign of strength (Failed Selling Climax), otherwise false.
S_BullOutsideReversal(_data)
Determines if there is a sign of strength (Bull Outside Reversal).
Parameters:
_data (map) : (map) The data map with volume and spread levels.
Returns: (bool) True if there is a sign of strength (Bull Outside Reversal), otherwise false.
S_EndOfFallingMarket(_data)
Determines if there is a sign of strength (End of Falling Market).
Parameters:
_data (map) : (map) The data map with volume and spread levels.
Returns: (bool) True if there is a sign of strength (End of Falling Market), otherwise false.
S_PseudoDownThrust(_bullPinBarMaxBody, _bullPinBarMinWick)
Determines if there is a sign of strength (Pseudo DownThrust).
Parameters:
_bullPinBarMaxBody (simple float) : (float) The maximum body percentage for bull pin bar.
_bullPinBarMinWick (simple float) : (float) The minimum wick percentage for bull pin bar.
Returns: (bool) True if there is a sign of strength (Pseudo DownThrust), otherwise false.
S_NoSupply(_bullPinBarMaxBody, _bullPinBarMinWick)
Determines if there is a sign of strength (No Supply).
Parameters:
_bullPinBarMaxBody (simple float) : (float) The maximum body percentage for bull pin bar.
_bullPinBarMinWick (simple float) : (float) The minimum wick percentage for bull pin bar.
Returns: (bool) True if there is a sign of strength (No Supply), otherwise false.
W_UpThrust(_data, _bearPinBarMaxBody, _bearPinBarMinWick)
Determines if there is a sign of weakness (UpThrust).
Parameters:
_data (map) : (map) The data map with volume and spread levels.
_bearPinBarMaxBody (simple float) : (float) The maximum body percentage for bear pin bar.
_bearPinBarMinWick (simple float) : (float) The minimum wick percentage for bear pin bar.
Returns: (bool) True if there is a sign of weakness (UpThrust), otherwise false.
W_BuyingClimax(_data, _rejectionWick)
Determines if there is a sign of weakness (Buying Climax).
Parameters:
_data (map) : (map) The data map with volume and spread levels.
_rejectionWick (simple float) : (float) The rejection wick percentage.
Returns: (bool) True if there is a sign of weakness (Buying Climax), otherwise false.
W_NoEffortBullishResult()
Determines if there is a sign of weakness (No Effort Bullish Result).
Returns: (bool) True if there is a sign of weakness (No Effort Bullish Result), otherwise false.
W_BullishEffortNoResult()
Determines if there is a sign of weakness (Bullish Effort No Result).
Returns: (bool) True if there is a sign of weakness (Bullish Effort No Result), otherwise false.
W_InverseUpThrust(_data, _bullPinBarMaxBody, _bullPinBarMinWick)
Determines if there is a sign of weakness (Inverse UpThrust).
Parameters:
_data (map) : (map) The data map with volume and spread levels.
_bullPinBarMaxBody (simple float) : (float) The maximum body percentage for bull pin bar.
_bullPinBarMinWick (simple float) : (float) The minimum wick percentage for bull pin bar.
Returns: (bool) True if there is a sign of weakness (Inverse UpThrust), otherwise false.
W_FailedBuyingClimax()
Determines if there is a sign of weakness (Failed Buying Climax).
Returns: (bool) True if there is a sign of weakness (Failed Buying Climax), otherwise false.
W_BearOutsideReversal(_data)
Determines if there is a sign of weakness (Bear Outside Reversal).
Parameters:
_data (map) : (map) The data map with volume and spread levels.
Returns: (bool) True if there is a sign of weakness (Bear Outside Reversal), otherwise false.
W_EndOfRisingMarket(_data)
Determines if there is a sign of weakness (End of Rising Market).
Parameters:
_data (map) : (map) The data map with volume and spread levels.
Returns: (bool) True if there is a sign of weakness (End of Rising Market), otherwise false.
W_PseudoUpThrust(_bearPinBarMaxBody, _bearPinBarMinWick)
Determines if there is a sign of weakness (Pseudo UpThrust).
Parameters:
_bearPinBarMaxBody (simple float) : (float) The maximum body percentage for bear pin bar.
_bearPinBarMinWick (simple float) : (float) The minimum wick percentage for bear pin bar.
Returns: (bool) True if there is a sign of weakness (Pseudo UpThrust), otherwise false.
W_NoDemand(_bearPinBarMaxBody, _bearPinBarMinWick)
Determines if there is a sign of weakness (No Demand).
Parameters:
_bearPinBarMaxBody (simple float) : (float) The maximum body percentage for bear pin bar.
_bearPinBarMinWick (simple float) : (float) The minimum wick percentage for bear pin bar.
Returns: (bool) True if there is a sign of weakness (No Demand), otherwise false.
N_QuietDoji(_dojiBarMaxBody)
Determines if there is a neutral signal (Quiet Doji).
Parameters:
_dojiBarMaxBody (simple float) : (float) The maximum body percentage for doji bar.
Returns: (bool) True if there is a neutral signal (Quiet Doji), otherwise false.
N_BalancedDoji(_data, _dojiBarMaxBody)
Determines if there is a neutral signal (Balanced Doji).
Parameters:
_data (map) : (map) The data map with volume and spread levels.
_dojiBarMaxBody (simple float) : (float) The maximum body percentage for doji bar.
Returns: (bool) True if there is a neutral signal (Balanced Doji), otherwise false.
N_StrongDoji(_dojiBarMaxBody)
Determines if there is a neutral signal (Strong Doji).
Parameters:
_dojiBarMaxBody (simple float) : (float) The maximum body percentage for doji bar.
Returns: (bool) True if there is a neutral signal (Strong Doji), otherwise false.
N_QuietSpinningTop(_spinningTopBarMinWicks, _spinningTopBarEmaLength)
Determines if there is a neutral signal (Quiet Spinning Top).
Parameters:
_spinningTopBarMinWicks (simple float) : (float) The minimum wicks percentage for spinning top bar.
_spinningTopBarEmaLength (simple int) : (int) The length for EMA calculation.
Returns: (bool) True if there is a neutral signal (Quiet Spinning Top), otherwise false.
N_BalancedSpinningTop(_data, _spinningTopBarMinWicks, _spinningTopBarEmaLength)
Determines if there is a neutral signal (Balanced Spinning Top).
Parameters:
_data (map) : (map) The data map with volume and spread levels.
_spinningTopBarMinWicks (simple float) : (float) The minimum wicks percentage for spinning top bar.
_spinningTopBarEmaLength (simple int) : (int) The length for EMA calculation.
Returns: (bool) True if there is a neutral signal (Balanced Spinning Top), otherwise false.
N_StrongSpinningTop(_spinningTopBarMinWicks, _spinningTopBarEmaLength)
Determines if there is a neutral signal (Strong Spinning Top).
Parameters:
_spinningTopBarMinWicks (simple float) : (float) The minimum wicks percentage for spinning top bar.
_spinningTopBarEmaLength (simple int) : (int) The length for EMA calculation.
Returns: (bool) True if there is a neutral signal (Strong Spinning Top), otherwise false.
N_QuietHighWave(_highWaveBarMinBody, _highWaveBarMinWick, _highWaveBarBars)
Determines if there is a neutral signal (Quiet High Wave).
Parameters:
_highWaveBarMinBody (simple float) : (float) The minimum body percentage for high wave bar.
_highWaveBarMinWick (simple float) : (float) The minimum wick percentage for high wave bar.
_highWaveBarBars (simple int) : (int) The number of bars for comparison.
Returns: (bool) True if there is a neutral signal (Quiet High Wave), otherwise false.
N_BalancedHighWave(_data, _highWaveBarMinBody, _highWaveBarMinWick, _highWaveBarBars)
Determines if there is a neutral signal (Balanced High Wave).
Parameters:
_data (map) : (map) The data map with volume and spread levels.
_highWaveBarMinBody (simple float) : (float) The minimum body percentage for high wave bar.
_highWaveBarMinWick (simple float) : (float) The minimum wick percentage for high wave bar.
_highWaveBarBars (simple int) : (int) The number of bars for comparison.
Returns: (bool) True if there is a neutral signal (Balanced High Wave), otherwise false.
N_StrongHighWave(_highWaveBarMinBody, _highWaveBarMinWick, _highWaveBarBars)
Determines if there is a neutral signal (Strong High Wave).
Parameters:
_highWaveBarMinBody (simple float) : (float) The minimum body percentage for high wave bar.
_highWaveBarMinWick (simple float) : (float) The minimum wick percentage for high wave bar.
_highWaveBarBars (simple int) : (int) The number of bars for comparison.
Returns: (bool) True if there is a neutral signal (Strong High Wave), otherwise false.
N_Consolidation(_data, _consolidationBarSpread, _consolidationBarBars)
Determines if there is a neutral signal (Consolidation).
Parameters:
_data (map) : (map) The data map with volume and spread levels.
_consolidationBarSpread (simple float) : (float) The spread percentage for consolidation bar.
_consolidationBarBars (simple int) : (int) The number of bars for comparison.
Returns: (bool) True if there is a neutral signal (Consolidation), otherwise false.
Delta ZigZag [LuxAlgo]The Delta ZigZag indicator is focused on volume analysis during the development of ZigZag lines. Volume data can be retrieved from a Lower timeframe (LTF) or real-time Tick data.
Our Delta ZigZag publication can be helpful in detecting indications of a trend reversal or potential weakening/strengthening of the trend.
This indicator by its very nature backpaints, meaning that the displayed components are offset in the past.
🔶 USAGE
The ZigZag line is formed by connecting Swings , which can be set by adjusting the Left and Right settings.
Left is the number of bars for evaluation at the left of the evaluated point.
Right is the number of bars for evaluation at the right of the evaluated point.
A valid Swing is a value higher or lower than the bars at the left/right .
A higher Left or Right set number will generally create broader ZigZag ( ZZ ) lines, while the drawing of the ZZ line will be delayed (especially when Right is set higher). On the other hand, when Right is set at 0, ZZ line are drawn quickly. However, this results in a hyperactive switching of the ZZ direction.
To ensure maximum visibility of values, we recommend using " Bars " from the " Bar's style " menu.
🔹 Volume examination
The script provides two options for Volume examination :
Examination per ZigZag line
Examination per bar
Bullish Volume is volume associated with a green bar ( close > open )
Bearish Volume is volume associated with a red bar ( close < open )
Neutral Volume (volume on a " close == open" bar) is not included in this publication.
🔹 Examination per ZigZag line
As long as the price moves in the same direction, the present ZZ line will continue. When the direction of the price changes, the bull/bear volume of the previous ZZ line is evaluated and drawn on the chart.
The ZZ line is divided into two parts: a bullish green line and a bearish red line.
The intercept of these two lines will depend on the ratio of bullish/bearish volume
This ratio is displayed at the intercept as % bullish volume (Settings -> Show % Bullish Volume)
* Note that we cannot draw between 2 bars. Therefore, if a ZZ line is only 1 bar long, the intercept will be at one of those 2 bars and not in between. The percentage can be helpful in interpreting bull/bear volume.
In the example above (2 most right labels), you can see that an overlap of 2 labels is prevented, ensuring the ability to evaluate the bullish % volume of the ZZ line .
The percentage will be colored green when more than 50%, red otherwise. The color will fade when the direction is contradictory; for example, 40% when the ZZ line goes up or 70% when the ZZ line falls.
More details can be visualized by enabling " Show " and choosing 1 of 3 options:
Average Volume Delta/bar
Average Volume/bar
Normalised Volume Delta
For both 'averages', the sum of " Volume "/" Volume Delta " of every bar on the ZZ line is divided by the number of bars (per ZZ line ).
The " Normalised Volume Delta " is calculated by dividing the sum of " Delta Volume " by the sum of " Volume " (neutral volume not included), which is displayed as a percentage.
All three options will display a label at the last point of the ZZ line and be coloured similarly: green when the ratio bullish/bearish volume of the ZZ line is bullish and red otherwise. Here, the colour also fades when it is bullish, but the ZZ line falls or when it is bearish with a rising ZZ line .
A tooltip at each label hints at the chosen option.
You can pick one of the options or combine them together.
🔹 Examination per bar
Besides information about what's happening during the ZZ line , information per bar can be visualized by enabling " Show Details " in Settings .
Split Volume per bar : show the sum of bullish (upV) and bearish (dnV) volume per bar
Volume (bar) : Total Volume per bar (bullish + bearish volume, neutral volume not included)
Δ Volume (bar) : Show Delta Volume (bullish - bearish volume)
🔹 Using Lower Timeframe Data
The ZigZag lines using LTF data are colored brighter. Also note the vertical line where the LTF data starts and the gap between ZZ lines with LTF data and without.
When " LTF " is chosen for the " Data from: " option in Settings , data is retrieved from Lower Timeframe bars (default 1 minute). When the LTF setting is higher than the current chart timeframe, the LTF period will automatically be adjusted to the current timeframe to prevent errors.
As there is a 100K limit to the number of LTF intrabars that can be analyzed by a script, this implies the higher the difference between LTF and current TF; the fewer ZZ lines will be seen.
🔹 Using real-time tick data
The principles are mostly the same as those of LTF data. However, in contrast with LTF data, where you already have LTF ZZ lines when loading the script, real-time tick data-based ZZ lines will only start after loading the chart.
Changing the settings of a ticker will reset everything. However, returning to the same settings/ticker would show the cached data again.
Here, you can see that changing settings reset everything, but returning after 2 minutes to the initial settings shows the cached data. Don't expect it to be cached for hours or days, though.
🔶 DETAILS
The timeframe used for LTF data should always be the same or lower than the current TF; otherwise, an error occurs. This snippet prevents the error and adjusts the LTF to the current TF when LTF is too high:
res = input.timeframe('1')
res := timeframe.from_seconds( math.min( timeframe.in_seconds(timeframe.period), timeframe.in_seconds(res) ) )
🔶 SETTINGS
Data from: LTF (Lower TimeFrame) or Ticks (Real-time ticks)
Res: Lower TimeFrame (only applicable when choosing LTF )
Option: choose " high/low " or " close " for Swing detection
🔹 ZigZag
Left: Lookback period for Swings
Right: Confirmation period after potential Swing
🔹 ZigZag Delta
Show % Bullish Volume : % bullish volume against total volume during the ZZ line
Show:
Average Volume Delta/bar
Average Volume/bar
Normalised Volume Delta
See USAGE for more information
🔹 Bar Data
Split Volume per bar: shows the sum of bullish ( upV ) and bearish ( dnV ) volume per bar
Volume (bar): Total Volume per bar (bullish + bearish volume, neutral volume not included)
Δ Volume (bar): Show Volume Delta (bullish - bearish volume)
CVD - Cumulative Volume Delta (Chart)█ OVERVIEW
This indicator displays cumulative volume delta (CVD) as an on-chart oscillator. It uses intrabar analysis to obtain more precise volume delta information compared to methods that only use the chart's timeframe.
The core concepts in this script come from our first CVD indicator , which displays CVD values as plot candles in a separate indicator pane. In this script, CVD values are scaled according to price ranges and represented on the main chart pane.
█ CONCEPTS
Bar polarity
Bar polarity refers to the position of the close price relative to the open price. In other words, bar polarity is the direction of price change.
Intrabars
Intrabars are chart bars at a lower timeframe than the chart's. Each 1H chart bar of a 24x7 market will, for example, usually contain 60 bars at the lower timeframe of 1min, provided there was market activity during each minute of the hour. Mining information from intrabars can be useful in that it offers traders visibility on the activity inside a chart bar.
Lower timeframes (LTFs)
A lower timeframe is a timeframe that is smaller than the chart's timeframe. This script utilizes a LTF to analyze intrabars, or price changes within a chart bar. The lower the LTF, the more intrabars are analyzed, but the less chart bars can display information due to the limited number of intrabars that can be analyzed.
Volume delta
Volume delta is a measure that separates volume into "up" and "down" parts, then takes the difference to estimate the net demand for the asset. This approach gives traders a more detailed insight when analyzing volume and market sentiment. There are several methods for determining whether an asset's volume belongs in the "up" or "down" category. Some indicators, such as On Balance Volume and the Klinger Oscillator , use the change in price between bars to assign volume values to the appropriate category. Others, such as Chaikin Money Flow , make assumptions based on open, high, low, and close prices. The most accurate method involves using tick data to determine whether each transaction occurred at the bid or ask price and assigning the volume value to the appropriate category accordingly. However, this method requires a large amount of data on historical bars, which can limit the historical depth of charts and the number of symbols for which tick data is available.
In the context where historical tick data is not yet available on TradingView, intrabar analysis is the most precise technique to calculate volume delta on historical bars on our charts. This indicator uses intrabar analysis to achieve a compromise between simplicity and accuracy in calculating volume delta on historical bars. Our Volume Profile indicators use it as well. Other volume delta indicators in our Community Scripts , such as the Realtime 5D Profile , use real-time chart updates to achieve more precise volume delta calculations. However, these indicators aren't suitable for analyzing historical bars since they only work for real-time analysis.
This is the logic we use to assign intrabar volume to the "up" or "down" category:
• If the intrabar's open and close values are different, their relative position is used.
• If the intrabar's open and close values are the same, the difference between the intrabar's close and the previous intrabar's close is used.
• As a last resort, when there is no movement during an intrabar and it closes at the same price as the previous intrabar, the last known polarity is used.
Once all intrabars comprising a chart bar are analyzed, we calculate the net difference between "up" and "down" intrabar volume to produce the volume delta for the chart bar.
█ FEATURES
CVD resets
The "cumulative" part of the indicator's name stems from the fact that calculations accumulate during a period of time. By periodically resetting the volume delta accumulation, we can analyze the progression of volume delta across manageable chunks, which is often more useful than looking at volume delta accumulated from the beginning of a chart's history.
You can configure the reset period using the "CVD Resets" input, which offers the following selections:
• None : Calculations do not reset.
• On a fixed higher timeframe : Calculations reset on the higher timeframe you select in the "Fixed higher timeframe" field.
• At a fixed time that you specify.
• At the beginning of the regular session .
• On trend changes : Calculations reset on the direction change of either the Aroon indicator, Parabolic SAR , or Supertrend .
• On a stepped higher timeframe : Calculations reset on a higher timeframe automatically stepped using the chart's timeframe and following these rules:
Chart TF HTF
< 1min 1H
< 3H 1D
<= 12H 1W
< 1W 1M
>= 1W 1Y
Specifying intrabar precision
Ten options are included in the script to control the number of intrabars used per chart bar for calculations. The greater the number of intrabars per chart bar, the fewer chart bars can be analyzed.
The first five options allow users to specify the approximate amount of chart bars to be covered:
• Least Precise (Most chart bars) : Covers all chart bars by dividing the current timeframe by four.
This ensures the highest level of intrabar precision while achieving complete coverage for the dataset.
• Less Precise (Some chart bars) & More Precise (Less chart bars) : These options calculate a stepped LTF in relation to the current chart's timeframe.
• Very precise (2min intrabars) : Uses the second highest quantity of intrabars possible with the 2min LTF.
• Most precise (1min intrabars) : Uses the maximum quantity of intrabars possible with the 1min LTF.
The stepped lower timeframe for "Less Precise" and "More Precise" options is calculated from the current chart's timeframe as follows:
Chart Timeframe Lower Timeframe
Less Precise More Precise
< 1hr 1min 1min
< 1D 15min 1min
< 1W 2hr 30min
> 1W 1D 60min
The last five options allow users to specify an approximate fixed number of intrabars to analyze per chart bar. The available choices are 12, 24, 50, 100, and 250. The script will calculate the LTF which most closely approximates the specified number of intrabars per chart bar. Keep in mind that due to factors such as the length of a ticker's sessions and rounding of the LTF, it is not always possible to produce the exact number specified. However, the script will do its best to get as close to the value as possible.
As there is a limit to the number of intrabars that can be analyzed by a script, a tradeoff occurs between the number of intrabars analyzed per chart bar and the chart bars for which calculations are possible.
Display
This script displays raw or cumulative volume delta values on the chart as either line or histogram oscillator zones scaled according to the price chart, allowing traders to visualize volume activity on each bar or cumulatively over time. The indicator's background shows where CVD resets occur, demarcating the beginning of new zones. The vertical axis of each oscillator zone is scaled relative to the one with the highest price range, and the oscillator values are scaled relative to the highest volume delta. A vertical offset is applied to each oscillator zone so that the highest oscillator value aligns with the lowest price. This method ensures an accurate, intuitive visual comparison of volume activity within zones, as the scale is consistent across the chart, and oscillator values sit below prices. The vertical scale of oscillator zones can be adjusted using the "Zone Height" input in the script settings.
This script displays labels at the highest and lowest oscillator values in each zone, which can be enabled using the "Hi/Lo Labels" input in the "Visuals" section of the script settings. Additionally, the oscillator's value on a chart bar is displayed as a tooltip when a user hovers over the bar, which can be enabled using the "Value Tooltips" input.
Divergences occur when the polarity of volume delta does not match that of the chart bar. The script displays divergences as bar colors and background colors that can be enabled using the "Color bars on divergences" and "Color background on divergences" inputs.
An information box in the lower-left corner of the indicator displays the HTF used for resets, the LTF used for intrabars, the average quantity of intrabars per chart bar, and the number of chart bars for which there is LTF data. This is enabled using the "Show information box" input in the "Visuals" section of the script settings.
FOR Pine Script™ CODERS
• This script utilizes `ltf()` and `ltfStats()` from the lower_tf library.
The `ltf()` function determines the appropriate lower timeframe from the selected calculation mode and chart timeframe, and returns it in a format that can be used with request.security_lower_tf() .
The `ltfStats()` function, on the other hand, is used to compute and display statistical information about the lower timeframe in an information box.
• The script utilizes display.data_window and display.status_line to restrict the display of certain plots.
These new built-ins allow coders to fine-tune where a script’s plot values are displayed.
• The newly added session.isfirstbar_regular built-in allows for resetting the CVD segments at the start of the regular session.
• The VisibleChart library developed by our resident PineCoders team leverages the chart.left_visible_bar_time and chart.right_visible_bar_time variables to optimize the performance of this script.
These variables identify the opening time of the leftmost and rightmost visible bars on the chart, allowing the script to recalculate and draw objects only within the range of visible bars as the user scrolls.
This functionality also enables the scaling of the oscillator zones.
These variables are just a couple of the many new built-ins available in the chart.* namespace.
For more information, check out this blog post or look them up by typing "chart." in the Pine Script™ Reference Manual .
• Our ta library has undergone significant updates recently, including the incorporation of the `aroon()` indicator used as a method for resetting CVD segments within this script.
Revisit the library to see more of the newly added content!
Look first. Then leap.
Intrabar Efficiency Ratio█ OVERVIEW
This indicator displays a directional variant of Perry Kaufman's Efficiency Ratio, designed to gauge the "efficiency" of intrabar price movement by comparing the sum of movements of the lower timeframe bars composing a chart bar with the respective bar's movement on an average basis.
█ CONCEPTS
Efficiency Ratio (ER)
Efficiency Ratio was first introduced by Perry Kaufman in his 1995 book, titled "Smarter Trading". It is the ratio of absolute price change to the sum of absolute changes on each bar over a period. This tells us how strong the period's trend is relative to the underlying noise. Simply put, it's a measure of price movement efficiency. This ratio is the modulator utilized in Kaufman's Adaptive Moving Average (KAMA), which is essentially an Exponential Moving Average (EMA) that adapts its responsiveness to movement efficiency.
ER's output is bounded between 0 and 1. A value of 0 indicates that the starting price equals the ending price for the period, which suggests that price movement was maximally inefficient. A value of 1 indicates that price had travelled no more than the distance between the starting price and the ending price for the period, which suggests that price movement was maximally efficient. A value between 0 and 1 indicates that price had travelled a distance greater than the distance between the starting price and the ending price for the period. In other words, some degree of noise was present which resulted in reduced efficiency over the period.
As an example, let's say that the price of an asset had moved from $15 to $14 by the end of a period, but the sum of absolute changes for each bar of data was $4. ER would be calculated like so:
ER = abs(14 - 15)/4 = 0.25
This suggests that the trend was only 25% efficient over the period, as the total distanced travelled by price was four times what was required to achieve the change over the period.
Intrabars
Intrabars are chart bars at a lower timeframe than the chart's. Each 1H chart bar of a 24x7 market will, for example, usually contain 60 intrabars at the LTF of 1min, provided there was market activity during each minute of the hour. Mining information from intrabars can be useful in that it offers traders visibility on the activity inside a chart bar.
Lower timeframes (LTFs)
A lower timeframe is a timeframe that is smaller than the chart's timeframe. This script determines which LTF to use by examining the chart's timeframe. The LTF determines how many intrabars are examined for each chart bar; the lower the timeframe, the more intrabars are analyzed, but fewer chart bars can display indicator information because there is a limit to the total number of intrabars that can be analyzed.
Intrabar precision
The precision of calculations increases with the number of intrabars analyzed for each chart bar. As there is a 100K limit to the number of intrabars that can be analyzed by a script, a trade-off occurs between the number of intrabars analyzed per chart bar and the chart bars for which calculations are possible.
Intrabar Efficiency Ratio (IER)
Intrabar Efficiency Ratio applies the concept of ER on an intrabar level. Rather than comparing the overall change to the sum of bar changes for the current chart's timeframe over a period, IER compares single bar changes for the current chart's timeframe to the sum of absolute intrabar changes, then applies smoothing to the result. This gives an indication of how efficient changes are on the current chart's timeframe for each bar of data relative to LTF bar changes on an average basis. Unlike the standard ER calculation, we've opted to preserve directional information by not taking the absolute value of overall change, thus allowing it to be utilized as a momentum oscillator. However, by taking the absolute value of this oscillator, it could potentially serve as a replacement for ER in the design of adaptive moving averages.
Since this indicator preserves directional information, IER can be regarded as similar to the Chande Momentum Oscillator (CMO) , which was presented in 1994 by Tushar Chande in "The New Technical Trader". Both CMO and ER essentially measure the same relationship between trend and noise. CMO simply differs in scale, and considers the direction of overall changes.
█ FEATURES
Display
Three different display types are included within the script:
• Line : Displays the middle length MA of the IER as a line .
Color for this display can be customized via the "Line" portion of the "Visuals" section in the script settings.
• Candles : Displays the non-smooth IER and two moving averages of different lengths as candles .
The `open` and `close` of the candle are the longest and shortest length MAs of the IER respectively.
The `high` and `low` of the candle are the max and min of the IER, longest length MA of the IER, and shortest length MA of the IER respectively.
Colors for this display can be customized via the "Candles" portion of the "Visuals" section in the script settings.
• Circles : Displays three MAs of the IER as circles .
The color of each plot depends on the percent rank of the respective MA over the previous 100 bars.
Different colors are triggered when ranks are below 10%, between 10% and 50%, between 50% and 90%, and above 90%.
Colors for this display can be customized via the "Circles" portion of the "Visuals" section in the script settings.
With either display type, an optional information box can be displayed. This box shows the LTF that the script is using, the average number of lower timeframe bars per chart bar, and the number of chart bars that contain LTF data.
Specifying intrabar precision
Ten options are included in the script to control the number of intrabars used per chart bar for calculations. The greater the number of intrabars per chart bar, the fewer chart bars can be analyzed.
The first five options allow users to specify the approximate amount of chart bars to be covered:
• Least Precise (Most chart bars) : Covers all chart bars by dividing the current timeframe by four.
This ensures the highest level of intrabar precision while achieving complete coverage for the dataset.
• Less Precise (Some chart bars) & More Precise (Less chart bars) : These options calculate a stepped LTF in relation to the current chart's timeframe.
• Very precise (2min intrabars) : Uses the second highest quantity of intrabars possible with the 2min LTF.
• Most precise (1min intrabars) : Uses the maximum quantity of intrabars possible with the 1min LTF.
The stepped lower timeframe for "Less Precise" and "More Precise" options is calculated from the current chart's timeframe as follows:
Chart Timeframe Lower Timeframe
Less Precise More Precise
< 1hr 1min 1min
< 1D 15min 1min
< 1W 2hr 30min
> 1W 1D 60min
The last five options allow users to specify an approximate fixed number of intrabars to analyze per chart bar. The available choices are 12, 24, 50, 100, and 250. The script will calculate the LTF which most closely approximates the specified number of intrabars per chart bar. Keep in mind that due to factors such as the length of a ticker's sessions and rounding of the LTF, it is not always possible to produce the exact number specified. However, the script will do its best to get as close to the value as possible.
Specifying MA type
Seven MA types are included in the script for different averaging effects:
• Simple
• Exponential
• Wilder (RMA)
• Weighted
• Volume-Weighted
• Arnaud Legoux with `offset` and `sigma` set to 0.85 and 6 respectively.
• Hull
Weighting
This script includes the option to weight IER values based on the percent rank of absolute price changes on the current chart's timeframe over a specified period, which can be enabled by checking the "Weigh using relative close changes" option in the script settings. This places reduced emphasis on IER values from smaller changes, which may help to reduce noise in the output.
█ FOR Pine Script™ CODERS
• This script imports the recently published lower_ltf library for calculating intrabar statistics and the optimal lower timeframe in relation to the current chart's timeframe.
• This script uses the recently released request.security_lower_tf() Pine Script™ function discussed in this blog post .
It works differently from the usual request.security() in that it can only be used on LTFs, and it returns an array containing one value per intrabar.
This makes it much easier for programmers to access intrabar information.
• This script implements a new recommended best practice for tables which works faster and reduces memory consumption.
Using this new method, tables are declared only once with var , as usual. Then, on the first bar only, we use table.cell() to populate the table.
Finally, table.set_*() functions are used to update attributes of table cells on the last bar of the dataset.
This greatly reduces the resources required to render tables.
Look first. Then leap.
CVD - Cumulative Volume Delta Candles█ OVERVIEW
This indicator displays cumulative volume delta in candle form. It uses intrabar information to obtain more precise volume delta information than methods using only the chart's timeframe.
█ CONCEPTS
Bar polarity
By bar polarity , we mean the direction of a bar, which is determined by looking at the bar's close vs its open .
Intrabars
Intrabars are chart bars at a lower timeframe than the chart's. Each 1H chart bar of a 24x7 market will, for example, usually contain 60 bars at the lower timeframe of 1min, provided there was market activity during each minute of the hour. Mining information from intrabars can be useful in that it offers traders visibility on the activity inside a chart bar.
Lower timeframes (LTFs)
A lower timeframe is a timeframe that is smaller than the chart's timeframe. This script uses a LTF to access intrabars. The lower the LTF, the more intrabars are analyzed, but the less chart bars can display CVD information because there is a limit to the total number of intrabars that can be analyzed.
Volume delta
The volume delta concept divides a bar's volume in "up" and "down" volumes. The delta is calculated by subtracting down volume from up volume. Many calculation techniques exist to isolate up and down volume within a bar. The simplest techniques use the polarity of interbar price changes to assign their volume to up or down slots, e.g., On Balance Volume or the Klinger Oscillator . Others such as Chaikin Money Flow use assumptions based on a bar's OHLC values. The most precise calculation method uses tick data and assigns the volume of each tick to the up or down slot depending on whether the transaction occurs at the bid or ask price. While this technique is ideal, it requires huge amounts of data on historical bars, which usually limits the historical depth of charts and the number of symbols for which tick data is available.
This indicator uses intrabar analysis to achieve a compromise between the simplest and most precise methods of calculating volume delta. In the context where historical tick data is not yet available on TradingView, intrabar analysis is the most precise technique to calculate volume delta on historical bars on our charts. Our Volume Profile indicators use it. Other volume delta indicators in our Community Scripts such as the Realtime 5D Profile use realtime chart updates to achieve more precise volume delta calculations, but that method cannot be used on historical bars, so those indicators only work in real time.
This is the logic we use to assign intrabar volume to up or down slots:
• If the intrabar's open and close values are different, their relative position is used.
• If the intrabar's open and close values are the same, the difference between the intrabar's close and the previous intrabar's close is used.
• As a last resort, when there is no movement during an intrabar and it closes at the same price as the previous intrabar, the last known polarity is used.
Once all intrabars making up a chart bar have been analyzed and the up or down property of each intrabar's volume determined, the up volumes are added and the down volumes subtracted. The resulting value is volume delta for that chart bar.
█ FEATURES
CVD Candles
Cumulative Volume Delta Candles present volume delta information as it evolves during a period of time.
This is how each candle's levels are calculated:
• open : Each candle's' open level is the cumulative volume delta for the current period at the start of the bar.
This value becomes zero on the first candle following a CVD reset.
The candles after the first one always open where the previous candle closed.
The candle's high, low and close levels are then calculated by adding or subtracting a volume value to the open.
• high : The highest volume delta value found in intrabars. If it is not higher than the volume delta for the bar, then that candle will have no upper wick.
• low : The lowest volume delta value found in intrabars. If it is not lower than the volume delta for the bar, then that candle will have no lower wick.
• close : The aggregated volume delta for all intrabars. If volume delta is positive for the chart bar, then the candle's close will be higher than its open, and vice versa.
The candles are plotted in one of two configurable colors, depending on the polarity of volume delta for the bar.
CVD resets
The "cumulative" part of the indicator's name stems from the fact that calculations accumulate during a period of time. This allows you to analyze the progression of volume delta across manageable chunks, which is often more useful than looking at volume delta cumulated from the beginning of a chart's history.
You can configure the reset period using the "CVD Resets" input, which offers the following selections:
• None : Calculations do not reset.
• On a fixed higher timeframe : Calculations reset on the higher timeframe you select in the "Fixed higher timeframe" field.
• At a fixed time that you specify.
• At the beginning of the regular session .
• On a stepped higher timeframe : Calculations reset on a higher timeframe automatically stepped using the chart's timeframe and following these rules:
Chart TF HTF
< 1min 1H
< 3H 1D
<= 12H 1W
< 1W 1M
>= 1W 1Y
The indicator's background shows where resets occur.
Intrabar precision
The precision of calculations increases with the number of intrabars analyzed for each chart bar. It is controlled through the script's "Intrabar precision" input, which offers the following selections:
• Least precise, covering many chart bars
• Less precise, covering some chart bars
• More precise, covering less chart bars
• Most precise, 1min intrabars
As there is a limit to the number of intrabars that can be analyzed by a script, a tradeoff occurs between the number of intrabars analyzed per chart bar and the chart bars for which calculations are possible.
Total volume candles
You can choose to display candles showing the total intrabar volume for the chart bar. This provides you with more context to evaluate a bar's volume delta by showing it relative to the sum of intrabar volume. Note that because of the reasons explained in the "NOTES" section further down, the total volume is the sum of all intrabar volume rather than the volume of the bar at the chart's timeframe.
Total volume candles can be configured with their own up and down colors. You can also control the opacity of their bodies to make them more or less prominent. This publication's chart shows the indicator with total volume candles. They are turned off by default, so you will need to choose to display them in the script's inputs for them to plot.
Divergences
Divergences occur when the polarity of volume delta does not match that of the chart bar. You can identify divergences by coloring the CVD candles differently for them, or by coloring the indicator's background.
Information box
An information box in the lower-left corner of the indicator displays the HTF used for resets, the LTF used for intrabars, and the average quantity of intrabars per chart bar. You can hide the box using the script's inputs.
█ INTERPRETATION
The first thing to look at when analyzing CVD candles is the side of the zero line they are on, as this tells you if CVD is generally bullish or bearish. Next, one should consider the relative position of successive candles, just as you would with a price chart. Are successive candles trending up, down, or stagnating? Keep in mind that whatever trend you identify must be considered in the context of where it appears with regards to the zero line; an uptrend in a negative CVD (below the zero line) may not be as powerful as one taking place in positive CVD values, but it may also predate a movement into positive CVD territory. The same goes with stagnation; a trader in a long position will find stagnation in positive CVD territory less worrisome than stagnation under the zero line.
After consideration of the bigger picture, one can drill down into the details. Exactly what you are looking for in markets will, of course, depend on your trading methodology, but you may find it useful to:
• Evaluate volume delta for the bar in relation to price movement for that bar.
• Evaluate the proportion that volume delta represents of total volume.
• Notice divergences and if the chart's candle shape confirms a hesitation point, as a Doji would.
• Evaluate if the progress of CVD candles correlates with that of chart bars.
• Analyze the wicks. As with price candles, long wicks tend to indicate weakness.
Always keep in mind that unless you have chosen not to reset it, your CVD resets for each period, whether it is fixed or automatically stepped. Consequently, any trend from the preceding period must re-establish itself in the next.
█ NOTES
Know your volume
Traders using volume information should understand the volume data they are using: where it originates and what transactions it includes, as this can vary with instruments, sectors, exchanges, timeframes, and between historical and realtime bars. The information used to build a chart's bars and display volume comes from data providers (exchanges, brokers, etc.) who often maintain distinct feeds for intraday and end-of-day (EOD) timeframes. How volume data is assembled for the two feeds depends on how instruments are traded in that sector and/or the volume reporting policy for each feed. Instruments from crypto and forex markets, for example, will often display similar volume on both feeds. Stocks will often display variations because block trades or other types of trades may not be included in their intraday volume data. Futures will also typically display variations.
Note that as intraday vs EOD variations exist for historical bars on some instruments, differences may also exist between the realtime feeds used on intraday vs 1D or greater timeframes for those same assets. Realtime reporting rules will often be different from historical feed reporting rules, so variations between realtime feeds will often be different from the variations between historical feeds for the same instrument. The Volume X-ray indicator can help you analyze differences between intraday and EOD volumes for the instruments you trade.
If every unit of volume is both bought by a buyer and sold by a seller, how can volume delta make sense?
Traders who do not understand the mechanics of matching engines (the exchange software that matches orders from buyers and sellers) sometimes argue that the concept of volume delta is flawed, as every unit of volume is both bought and sold. While they are rigorously correct in stating that every unit of volume is both bought and sold, they overlook the fact that information can be mined by analyzing variations in the price of successive ticks, or in our case, intrabars.
Our calculations model the situation where, in fully automated order handling, market orders are generally matched to limit orders sitting in the order book. Buy market orders are matched to quotes at the ask level and sell market orders are matched to quotes at the bid level. As explained earlier, we use the same logic when comparing intrabar prices. While using intrabar analysis does not produce results as precise as when individual transactions — or ticks — are analyzed, results are much more precise than those of methods using only chart prices.
Not only does the concept underlying volume delta make sense, it provides a window on an oft-overlooked variable which, with price and time, is the only basic information representing market activity. Furthermore, because the calculation of volume delta also uses price and time variations, one could conceivably surmise that it can provide a more complete model than ones using price and time only. Whether or not volume delta can be useful in your trading practice, as usual, is for you to decide, as each trader's methodology is different.
For Pine Script™ coders
As our latest Polarity Divergences publication, this script uses the recently released request.security_lower_tf() Pine Script™ function discussed in this blog post . It works differently from the usual request.security() in that it can only be used at LTFs, and it returns an array containing one value per intrabar. This makes it much easier for programmers to access intrabar information.
Look first. Then leap.
HighTimeframeSamplingLibrary "HighTimeframeSampling"
Library for sampling high timeframe (HTF) data. Returns an array of historical values, an arbitrary historical value, or the highest/lowest value in a range, spending a single security() call.
An optional pass-through for the chart timeframe is included. Other than that case, the data is fixed and does not alter over the course of the HTF bar. It behaves consistently on historical and elapsed realtime bars.
The first version returns floating-point numbers only. I might extend it if there's interest.
🙏 Credits: This library is (yet another) attempt at a solution of the problems in using HTF data that were laid out by Pinecoders - to whom, especially to Luc F, many thanks are due - in "security() revisited" - which I recommend you consult first. Go ahead, I'll wait.
All code is my own.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
WHAT'S THE PROBLEM? OR, WHY NOT JUST USE SECURITY()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are many difficulties with using HTF data, and many potential solutions. It's not really possible to convey it only in words: you need to see it on a chart.
Before using this library, please refer to my other HTF library, HighTimeframeTiming: which explains it extensively, compares many different solutions, and demonstrates (what I think are) the advantages of using this very library, namely, that it's stable, accurate, versatile and inexpensive. Then if you agree, come back here and choose your function.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
MOAR EXPLANATION
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🧹 Housekeeping: To see which plot is which, turn line labels on: Settings > Scales > Indicator Name Label. Vertical lines at the top of the chart show the open of a HTF bar: grey for historical and white for real-time bars.
‼ LIMITATIONS: To avoid strange behaviour, use this library on liquid assets and at chart timeframes high enough to reliably produce updates at least once per bar period.
A more conventional and universal limitation is that the library does not offer an unlimited view of historical bars. You need to define upfront how many HTF bars you want to store. Very large numbers might conceivably run into data or performance issues.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BRING ON THE FUNCTIONS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@function f_HTF_Value(string _HTF, float _source, int _arrayLength, int _HTF_Offset, bool _useLiveDataOnChartTF=false)
Returns a floating-point number from a higher timeframe, with a historical operator within an abitrary (but limited) number of bars.
@param string _HTF is the string that represents the higher timeframe. It must be in a format that the request.security() function recognises. The input timeframe cannot be lower than the chart timeframe or an error is thrown.
@param float _source is the source value that you want to sample, e.g. close, open, etc., or you can use any floating-point number.
@param int _arrayLength is the number of HTF bars you want to store and must be greater than zero. You can't go back further in history than this number of bars (minus one, because the current/most recent available bar is also stored).
@param int _HTF_Offset is the historical operator for the value you want to return. E.g., if you want the most recent fixed close, _source=close and _HTF_Offset = 0. If you want the one before that, _HTF_Offset=1, etc.
The number of HTF bars to look back must be zero or more, and must be one less than the number of bars stored.
@param bool _useLiveDataOnChartTF uses live data on the chart timeframe.
If the higher timeframe is the same as the chart timeframe, store the live value (i.e., from this very bar). For all truly higher timeframes, store the fixed value (i.e., from the previous bar).
The default is to use live data for the chart timeframe, so that this function works intuitively, that is, it does not fix data unless it has to (i.e., because the data is from a higher timeframe).
This means that on default settings, on the chart timeframe, it matches the raw source values from security(){0}.
You can override this behaviour by passing _useLiveDataOnChartTF as false. Then it will fix all data for all timeframes.
@returns a floating-point value that you requested from the higher timeframe.
@function f_HTF_Array(string _HTF, float _source, int _arrayLength, bool _useLiveDataOnChartTF=false, int _startIn, int _endIn)
Returns an array of historical values from a higher timeframe, starting with the current bar. Optionally, returns a slice of the array. The array is in reverse chronological order, i.e., index 0 contains the most recent value.
@param string _HTF is the string that represents the higher timeframe. It must be in a format that the request.security() function recognises. The input timeframe cannot be lower than the chart timeframe or an error is thrown.
@param float _source is the source value that you want to sample, e.g. close, open, etc., or you can use any floating-point number.
@param int _arrayLength is the number of HTF bars you want to keep in the array.
@param bool _useLiveDataOnChartTF uses live data on the chart timeframe.
If the higher timeframe is the same as the chart timeframe, store the live value (i.e., from this very bar). For all truly higher timeframes, store the fixed value (i.e., from the previous bar).
The default is to use live data for the chart timeframe, so that this function works intuitively, that is, it does not fix data unless it has to (i.e., because the data is from a higher timeframe).
This means that on default settings, on the chart timeframe, it matches raw source values from security().
You can override this behaviour by passing _useLiveDataOnChartTF as false. Then it will fix all data for all timeframes.
@param int _startIn is the array index to begin taking a slice. Must be at least one less than the length of the array; if out of bounds it is corrected to 0.
@param int _endIn is the array index BEFORE WHICH to end the slice. If the ending index of the array slice would take the slice past the end of the array, it is corrected to the end of the array. The ending index of the array slice must be greater than or equal to the starting index. If the end is less than the start, the whole array is returned. If the starting index is the same as the ending index, an empty array is returned. If either the starting or ending index is negative, the entire array is returned (which is the default behaviour; this is effectively a switch to bypass the slicing without taking up an extra parameter).
@returns an array of HTF values.
@function f_HTF_Highest(string _HTF="", float _source, int _arrayLength, bool _useLiveDataOnChartTF=true, int _rangeIn)
Returns the highest value within a range consisting of a given number of bars back from the most recent bar.
@param string _HTF is the string that represents the higher timeframe. It must be in a format that the request.security() function recognises. The input timeframe cannot be lower than the chart timeframe or an error is thrown.
@param float _source is the source value that you want to sample, e.g. close, open, etc., or you can use any floating-point number.
@param int _arrayLength is the number of HTF bars you want to store and must be greater than zero. You can't have a range greater than this number.
@param bool _useLiveDataOnChartTF uses live data on the chart timeframe.
If the higher timeframe is the same as the chart timeframe, store the live value (i.e., from this very bar). For all truly higher timeframes, store the fixed value (i.e., from the previous bar).
The default is to use live data for the chart timeframe, so that this function works intuitively, that is, it does not fix data unless it has to (i.e., because the data is from a higher timeframe).
This means that on default settings, on the chart timeframe, it matches raw source values from security().
You can override this behaviour by passing _useLiveDataOnChartTF as false. Then it will fix all data for all timeframes.
@param _rangeIn is the number of bars to include in the range of bars from which we want to find the highest value. It is NOT the historical operator of the last bar in the range. The range always starts at the current bar. A value of 1 doesn't make much sense but the function will generously return the only value it can anyway. A value less than 1 doesn't make sense and will return an error. A value that is higher than the number of stored values will be corrected to equal the number of stored values.
@returns a floating-point number representing the highest value in the range.
@function f_HTF_Lowest(string _HTF="", float _source, int _arrayLength, bool _useLiveDataOnChartTF=true, int _rangeIn)
Returns the lowest value within a range consisting of a given number of bars back from the most recent bar.
@param string _HTF is the string that represents the higher timeframe. It must be in a format that the request.security() function recognises. The input timeframe cannot be lower than the chart timeframe or an error is thrown.
@param float _source is the source value that you want to sample, e.g. close, open, etc., or you can use any floating-point number.
@param int _arrayLength is the number of HTF bars you want to store and must be greater than zero. You can't go back further in history than this number of bars (minus one, because the current/most recent available bar is also stored).
@param bool _useLiveDataOnChartTF uses live data on the chart timeframe.
If the higher timeframe is the same as the chart timeframe, store the live value (i.e., from this very bar). For all truly higher timeframes, store the fixed value (i.e., from the previous bar).
The default is to use live data for the chart timeframe, so that this function works intuitively, that is, it does not fix data unless it has to (i.e., because the data is from a higher timeframe).
This means that on default settings, on the chart timeframe, it matches raw source values from security().
You can override this behaviour by passing _useLiveDataOnChartTF as false. Then it will fix all data for all timeframes.
@param _rangeIn is the number of bars to include in the range of bars from which we want to find the highest value. It is NOT the historical operator of the last bar in the range. The range always starts at the current bar. A value of 1 doesn't make much sense but the function will generously return the only value it can anyway. A value less than 1 doesn't make sense and will return an error. A value that is higher than the number of stored values will be corrected to equal the number of stored values.
@returns a floating-point number representing the lowest value in the range.
LeoLibraryLibrary "LeoLibrary"
A collection of custom tools & utility functions commonly used with my scripts
getDecimals() Calculates how many decimals are on the quote price of the current market
Returns: The current decimal places on the market quote price
truncate(float, float) Truncates (cuts) excess decimal places
Parameters:
float : _number The number to truncate
float : _decimalPlaces (default=2) The number of decimal places to truncate to
Returns: The given _number truncated to the given _decimalPlaces
toWhole(float) Converts pips into whole numbers
Parameters:
float : _number The pip number to convert into a whole number
Returns: The converted number
toPips(float) Converts whole numbers back into pips
Parameters:
float : _number The whole number to convert into pips
Returns: The converted number
av_getPositionSize(float, float, float, float) Calculates OANDA forex position size for AutoView based on the given parameters
Parameters:
float : _balance The account balance to use
float : _risk The risk percentage amount (as a whole number - eg. 1 = 1% risk)
float : _stopPoints The stop loss distance in POINTS (not pips)
float : _conversionRate The conversion rate of our account balance currency
Returns: The calculated position size (in units - only compatible with OANDA)
getMA(int, string) Gets a Moving Average based on type
Parameters:
int : _length The MA period
string : _maType The type of MA
Returns: A moving average with the given parameters
getEAP(float) Performs EAP stop loss size calculation (eg. ATR >= 20.0 and ATR < 30, returns 20)
Parameters:
float : _atr The given ATR to base the EAP SL calculation on
Returns: The EAP SL converted ATR size
barsAboveMA(int, float) Counts how many candles are above the MA
Parameters:
int : _lookback The lookback period to look back over
float : _ma The moving average to check
Returns: The bar count of how many recent bars are above the MA
barsBelowMA(int, float) Counts how many candles are below the MA
Parameters:
int : _lookback The lookback period to look back over
float : _ma The moving average to reference
Returns: The bar count of how many recent bars are below the EMA
barsCrossedMA(int, float) Counts how many times the EMA was crossed recently
Parameters:
int : _lookback The lookback period to look back over
float : _ma The moving average to reference
Returns: The bar count of how many times price recently crossed the EMA
getPullbackBarCount(int, int) Counts how many green & red bars have printed recently (ie. pullback count)
Parameters:
int : _lookback The lookback period to look back over
int : _direction The color of the bar to count (1 = Green, -1 = Red)
Returns: The bar count of how many candles have retraced over the given lookback & direction
getBodySize() Gets the current candle's body size (in POINTS, divide by 10 to get pips)
Returns: The current candle's body size in POINTS
getTopWickSize() Gets the current candle's top wick size (in POINTS, divide by 10 to get pips)
Returns: The current candle's top wick size in POINTS
getBottomWickSize() Gets the current candle's bottom wick size (in POINTS, divide by 10 to get pips)
Returns: The current candle's bottom wick size in POINTS
getBodyPercent() Gets the current candle's body size as a percentage of its entire size including its wicks
Returns: The current candle's body size percentage
isHammer(float, bool) Checks if the current bar is a hammer candle based on the given parameters
Parameters:
float : _fib (default=0.382) The fib to base candle body on
bool : _colorMatch (default=false) Does the candle need to be green? (true/false)
Returns: A boolean - true if the current bar matches the requirements of a hammer candle
isStar(float, bool) Checks if the current bar is a shooting star candle based on the given parameters
Parameters:
float : _fib (default=0.382) The fib to base candle body on
bool : _colorMatch (default=false) Does the candle need to be red? (true/false)
Returns: A boolean - true if the current bar matches the requirements of a shooting star candle
isDoji(float, bool) Checks if the current bar is a doji candle based on the given parameters
Parameters:
float : _wickSize (default=2) The maximum top wick size compared to the bottom (and vice versa)
bool : _bodySize (default=0.05) The maximum body size as a percentage compared to the entire candle size
Returns: A boolean - true if the current bar matches the requirements of a doji candle
isBullishEC(float, float, bool) Checks if the current bar is a bullish engulfing candle
Parameters:
float : _allowance (default=0) How many POINTS to allow the open to be off by (useful for markets with micro gaps)
float : _rejectionWickSize (default=disabled) The maximum rejection wick size compared to the body as a percentage
bool : _engulfWick (default=false) Does the engulfing candle require the wick to be engulfed as well?
Returns: A boolean - true if the current bar matches the requirements of a bullish engulfing candle
isBearishEC(float, float, bool) Checks if the current bar is a bearish engulfing candle
Parameters:
float : _allowance (default=0) How many POINTS to allow the open to be off by (useful for markets with micro gaps)
float : _rejectionWickSize (default=disabled) The maximum rejection wick size compared to the body as a percentage
bool : _engulfWick (default=false) Does the engulfing candle require the wick to be engulfed as well?
Returns: A boolean - true if the current bar matches the requirements of a bearish engulfing candle
timeFilter(string, bool) Determines if the current price bar falls inside the specified session
Parameters:
string : _sess The session to check
bool : _useFilter (default=false) Whether or not to actually use this filter
Returns: A boolean - true if the current bar falls within the given time session
dateFilter(int, int) Determines if this bar's time falls within date filter range
Parameters:
int : _startTime The UNIX date timestamp to begin searching from
int : _endTime the UNIX date timestamp to stop searching from
Returns: A boolean - true if the current bar falls within the given dates
dayFilter(bool, bool, bool, bool, bool, bool, bool) Checks if the current bar's day is in the list of given days to analyze
Parameters:
bool : _monday Should the script analyze this day? (true/false)
bool : _tuesday Should the script analyze this day? (true/false)
bool : _wednesday Should the script analyze this day? (true/false)
bool : _thursday Should the script analyze this day? (true/false)
bool : _friday Should the script analyze this day? (true/false)
bool : _saturday Should the script analyze this day? (true/false)
bool : _sunday Should the script analyze this day? (true/false)
Returns: A boolean - true if the current bar's day is one of the given days
atrFilter(float, float) Checks the current bar's size against the given ATR and max size
Parameters:
float : _atr (default=ATR 14 period) The given ATR to check
float : _maxSize The maximum ATR multiplier of the current candle
Returns: A boolean - true if the current bar's size is less than or equal to _atr x _maxSize
fillCell(table, int, int, string, string, color, color) This updates the given table's cell with the given values
Parameters:
table : _table The table ID to update
int : _column The column to update
int : _row The row to update
string : _title The title of this cell
string : _value The value of this cell
color : _bgcolor The background color of this cell
color : _txtcolor The text color of this cell
Returns: A boolean - true if the current bar falls within the given dates
ZenLibraryLibrary "ZenLibrary"
A collection of custom tools & utility functions commonly used with my scripts.
getDecimals() Calculates how many decimals are on the quote price of the current market
Returns: The current decimal places on the market quote price
truncate(float, float) Truncates (cuts) excess decimal places
Parameters:
float : _number The number to truncate
float : _decimalPlaces (default=2) The number of decimal places to truncate to
Returns: The given _number truncated to the given _decimalPlaces
toWhole(float) Converts pips into whole numbers
Parameters:
float : _number The pip number to convert into a whole number
Returns: The converted number
toPips(float) Converts whole numbers back into pips
Parameters:
float : _number The whole number to convert into pips
Returns: The converted number
av_getPositionSize(float, float, float, float) Calculates OANDA forex position size for AutoView based on the given parameters
Parameters:
float : _balance The account balance to use
float : _risk The risk percentage amount (as a whole number - eg. 1 = 1% risk)
float : _stopPoints The stop loss distance in POINTS (not pips)
float : _conversionRate The conversion rate of our account balance currency
Returns: The calculated position size (in units - only compatible with OANDA)
getMA(int, string) Gets a Moving Average based on type
Parameters:
int : _length The MA period
string : _maType The type of MA
Returns: A moving average with the given parameters
getEAP(float) Performs EAP stop loss size calculation (eg. ATR >= 20.0 and ATR < 30, returns 20)
Parameters:
float : _atr The given ATR to base the EAP SL calculation on
Returns: The EAP SL converted ATR size
barsAboveMA(int, float) Counts how many candles are above the MA
Parameters:
int : _lookback The lookback period to look back over
float : _ma The moving average to check
Returns: The bar count of how many recent bars are above the MA
barsBelowMA(int, float) Counts how many candles are below the MA
Parameters:
int : _lookback The lookback period to look back over
float : _ma The moving average to reference
Returns: The bar count of how many recent bars are below the EMA
barsCrossedMA(int, float) Counts how many times the EMA was crossed recently
Parameters:
int : _lookback The lookback period to look back over
float : _ma The moving average to reference
Returns: The bar count of how many times price recently crossed the EMA
getPullbackBarCount(int, int) Counts how many green & red bars have printed recently (ie. pullback count)
Parameters:
int : _lookback The lookback period to look back over
int : _direction The color of the bar to count (1 = Green, -1 = Red)
Returns: The bar count of how many candles have retraced over the given lookback & direction
getBodySize() Gets the current candle's body size (in POINTS, divide by 10 to get pips)
Returns: The current candle's body size in POINTS
getTopWickSize() Gets the current candle's top wick size (in POINTS, divide by 10 to get pips)
Returns: The current candle's top wick size in POINTS
getBottomWickSize() Gets the current candle's bottom wick size (in POINTS, divide by 10 to get pips)
Returns: The current candle's bottom wick size in POINTS
getBodyPercent() Gets the current candle's body size as a percentage of its entire size including its wicks
Returns: The current candle's body size percentage
isHammer(float, bool) Checks if the current bar is a hammer candle based on the given parameters
Parameters:
float : _fib (default=0.382) The fib to base candle body on
bool : _colorMatch (default=false) Does the candle need to be green? (true/false)
Returns: A boolean - true if the current bar matches the requirements of a hammer candle
isStar(float, bool) Checks if the current bar is a shooting star candle based on the given parameters
Parameters:
float : _fib (default=0.382) The fib to base candle body on
bool : _colorMatch (default=false) Does the candle need to be red? (true/false)
Returns: A boolean - true if the current bar matches the requirements of a shooting star candle
isDoji(float, bool) Checks if the current bar is a doji candle based on the given parameters
Parameters:
float : _wickSize (default=2) The maximum top wick size compared to the bottom (and vice versa)
bool : _bodySize (default=0.05) The maximum body size as a percentage compared to the entire candle size
Returns: A boolean - true if the current bar matches the requirements of a doji candle
isBullishEC(float, float, bool) Checks if the current bar is a bullish engulfing candle
Parameters:
float : _allowance (default=0) How many POINTS to allow the open to be off by (useful for markets with micro gaps)
float : _rejectionWickSize (default=disabled) The maximum rejection wick size compared to the body as a percentage
bool : _engulfWick (default=false) Does the engulfing candle require the wick to be engulfed as well?
Returns: A boolean - true if the current bar matches the requirements of a bullish engulfing candle
isBearishEC(float, float, bool) Checks if the current bar is a bearish engulfing candle
Parameters:
float : _allowance (default=0) How many POINTS to allow the open to be off by (useful for markets with micro gaps)
float : _rejectionWickSize (default=disabled) The maximum rejection wick size compared to the body as a percentage
bool : _engulfWick (default=false) Does the engulfing candle require the wick to be engulfed as well?
Returns: A boolean - true if the current bar matches the requirements of a bearish engulfing candle
timeFilter(string, bool) Determines if the current price bar falls inside the specified session
Parameters:
string : _sess The session to check
bool : _useFilter (default=false) Whether or not to actually use this filter
Returns: A boolean - true if the current bar falls within the given time session
dateFilter(int, int) Determines if this bar's time falls within date filter range
Parameters:
int : _startTime The UNIX date timestamp to begin searching from
int : _endTime the UNIX date timestamp to stop searching from
Returns: A boolean - true if the current bar falls within the given dates
dayFilter(bool, bool, bool, bool, bool, bool, bool) Checks if the current bar's day is in the list of given days to analyze
Parameters:
bool : _monday Should the script analyze this day? (true/false)
bool : _tuesday Should the script analyze this day? (true/false)
bool : _wednesday Should the script analyze this day? (true/false)
bool : _thursday Should the script analyze this day? (true/false)
bool : _friday Should the script analyze this day? (true/false)
bool : _saturday Should the script analyze this day? (true/false)
bool : _sunday Should the script analyze this day? (true/false)
Returns: A boolean - true if the current bar's day is one of the given days
atrFilter(float, float) Checks the current bar's size against the given ATR and max size
Parameters:
float : _atr (default=ATR 14 period) The given ATR to check
float : _maxSize The maximum ATR multiplier of the current candle
Returns: A boolean - true if the current bar's size is less than or equal to _atr x _maxSize
fillCell(table, int, int, string, string, color, color) This updates the given table's cell with the given values
Parameters:
table : _table The table ID to update
int : _column The column to update
int : _row The row to update
string : _title The title of this cell
string : _value The value of this cell
color : _bgcolor The background color of this cell
color : _txtcolor The text color of this cell
Returns: A boolean - true if the current bar falls within the given dates
Pinescript - Common Label & Line Array Functions Library by RRBPinescript - Common Label & Line Array Functions Library by RagingRocketBull 2021
Version 1.0
This script provides a library of common array functions for arrays of label and line objects with live testing of all functions.
Using this library you can easily create, update, delete, join label/line object arrays, and get/set properties of individual label/line object array items.
You can find the full list of supported label/line array functions below.
There are several libraries:
- Common String Functions Library
- Standard Array Functions Library
- Common Fixed Type Array Functions Library
- Common Label & Line Array Functions Library
- Common Variable Type Array Functions Library
Features:
- 30 array functions in categories create/update/delete/join/get/set with support for both label/line objects (45+ including all implementations)
- Create, Update label/line object arrays from list/array params
- GET/SET properties of individual label/line array items by index
- Join label/line objects/arrays into a single string for output
- Supports User Input of x,y coords of 5 different types: abs/rel/rel%/inc/inc% list/array, auto transforms x,y input into list/array based on type, base and xloc, translates rel into abs bar indexes
- Supports User Input of lists with shortened names of string properties, auto expands all standard string properties to their full names for use in functions
- Live Output for all/selected functions based on User Input. Test any function for possible errors you may encounter before using in script.
- Output filters: hide all excluded and show only allowed functions using a list of function names
- Output Panel customization options: set custom style, color, text size, and line spacing
Usage:
- select create function - create label/line arrays from lists or arrays (optional). Doesn't affect the update functions. The only change in output should be function name regardless of the selected implementation.
- specify num_objects for both label/line arrays (default is 7)
- specify common anchor point settings x,y base/type for both label/line arrays and GET/SET items in Common Settings
- fill lists with items to use as inputs for create label/line array functions in Create Label/Line Arrays section
- specify label/line array item index and properties to SET in corresponding sections
- select label/line SET function to see the changes applied live
Code Structure:
- translate x,y depending on x,y type, base and xloc as specified in UI (required for all functions)
- expand all shortened standard property names to full names (required for create/update* from arrays and set* functions, not needed for create/update* from lists) to prevent errors in label.new and line.new
- create param arrays from string lists (required for create/update* from arrays and set* functions, not needed for create/update* from lists)
- create label/line array from string lists (property names are auto expanded) or param arrays (requires already expanded properties)
- update entire label/line array or
- get/set label/line array item properties by index
Transforming/Expanding Input values:
- for this script to work on any chart regardless of price/scale, all x*,y* are specified as % increase relative to x0,y0 base levels by default, but user can enter abs x,price values specific for that chart if necessary.
- all lists can be empty, contain 1 or several items, have the same/different lengths. Array Length = min(min(len(list*)), mum_objects) is used to create label/line objects. Missing list items are replaced with default property values.
- when a list contains only 1 item it is duplicated (label name/tooltip is also auto incremented) to match the calculated Array Length
- since this script processes user input, all x,y values must be translated to abs bar indexes before passing them to functions. Your script may provide all data internally and doesn't require this step.
- at first int x, float y arrays are created from user string lists, transformed as described below and returned as x,y arrays.
- translated x,y arrays can then be passed to create from arrays function or can be converted back to x,y string lists for the create from lists function if necessary.
- all translation logic is separated from create/update/set functions for the following reasons:
- to avoid redundant code/dependency on ext functions/reduce local scopes and to be able to translate everything only once in one place - should be faster
- to simplify internal logic of all functions
- because your script may provide all data internally without user input and won't need the translation step
- there are 5 types available for both x,y: abs, rel, rel%, inc, inc%. In addition to that, x can be: bar index or time, y is always price.
- abs - absolute bar index/time from start bar0 (x) or price (y) from 0, is >= 0
- rel - relative bar index/time from cur bar n (x) or price from y0 base level, is >= 0
- rel% - relative % increase of bar index/time (x) or price (y) from corresponding base level (x0 or y0), can be <=> 0
- inc - relative increment (step) for each new level of bar index/time (x) or price (y) from corresponding base level (x0 or y0), can be <=> 0
- inc% - relative % increment (% step) for each new level of bar index/time (x) or price (y) from corresponding base level (x0 or y0), can be <=> 0
- x base level >= 0
- y base level can be 0 (empty) or open, close, high, low of cur bar
- single item x1_list = "50" translates into:
- for x type abs: "50, 50, 50 ..." num_objects times regardless of xloc => x = 50
- for x type rel: "50, 50, 50 ... " num_objects times => x = x_base + 50
- for x type rel%: "50%, 50%, 50% ... " num_objects times => x_base * (1 + 0.5)
- for x type inc: "0, 50, 100 ... " num_objects times => x_base + 50 * i
- for x type inc%: "0%, 50%, 100% ... " num_objects times => x_base * (1 + 0.5 * i)
- when xloc = xloc.bar_index each rel*/inc* value in the above list is then subtracted from n: n - x to convert rel to abs bar index, values of abs type are not affected
- x1_list = "0, 50, 100, ..." of type rel is the same as "50" of type inc
- x1_list = "50, 50, 50, ..." of type abs/rel/rel% produces a sequence of the same values and can be shortened to just "50"
- single item y1_list = "2" translates into (ragardless of yloc):
- for y type abs: "2, 2, 2 ..." num_objects times => y = 2
- for y type rel: "2, 2, 2 ... " num_objects times => y = y_base + 2
- for y type rel%: "2%, 2%, 2% ... " num_objects times => y = y_base * (1 + 0.02)
- for y type inc: "0, 2, 4 ... " num_objects times => y = y_base + 2 * i
- for y type inc%: "0%, 2%, 4% ... " num_objects times => y = y_base * (1 + 0.02 * i)
- when yloc != yloc.price all calculated values above are simply ignored
- y1_list = "0, 2, 4" of type rel% is the same as "2" with type inc%
- y1_list = "2, 2, 2" of type abs/rel/rel% produces a sequence of the same values and can be shortened to just "2"
- you can enter shortened property names in lists. To lookup supported shortened names use corresponding dropdowns in Set Label/Line Array Item Properties sections
- all shortened standard property names must be expanded to full names (required for create/update* from arrays and set* functions, not needed for create/update* from lists) to prevent errors in label.new and line.new
- examples of shortened property names that can be used in lists: bar_index, large, solid, label_right, white, left, left, price
- expanded to their corresponding full names: xloc.bar_index, size.large, line.style_solid, label.style_label_right, color.white, text.align_left, extend.left, yloc.price
- all expanding logic is separated from create/update* from arrays and set* functions for the same reasons as above, and because param arrays already have different types, implying the use of final values.
- all expanding logic is included in the create/update* from lists functions because it seemed more natural to process string lists from user input directly inside the function, since they are already strings.
Creating Label/Line Objects:
- use study max_lines_count and max_labels_count params to increase the max number of label/line objects to 500 (+3) if necessary. Default number of label/line objects is 50 (+3)
- all functions use standard param sequence from methods in reference, except style always comes before colors.
- standard label/line.get* functions only return a few properties, you can't read style, color, width etc.
- label.new(na, na, "") will still create a label with x = n-301, y = NaN, text = "" because max default scope for a var is 300 bars back.
- there are 2 types of color na, label color requires color(na) instead of color_na to prevent error. text_color and line_color can be color_na
- for line to be visible both x1, x2 ends must be visible on screen, also when y1 == y2 => abs(x1 - x2) >= 2 bars => line is visible
- xloc.bar_index line uses abs x1, x2 indexes and can only be within 0 and n ends, where n <= 5000 bars (free accounts) or 10000 bars (paid accounts) limit, can't be plotted into the future
- xloc.bar_time line uses abs x1, x2 times, can't go past bar0 time but can continue past cur bar time into the future, doesn't have a length limit in bars.
- xloc.bar_time line with length = exact number of bars can be plotted only within bar0 and cur bar, can't be plotted into the future reliably because of future gaps due to sessions on some charts
- xloc.bar_index line can't be created on bar 0 with fixed length value because there's only 1 bar of horiz length
- it can be created on cur bar using fixed length x < n <= 5000 or
- created on bar0 using na and then assigned final x* values on cur bar using set_x*
- created on bar0 using n - fixed_length x and then updated on cur bar using set_x*, where n <= 5000
- default orientation of lines (for style_arrow* and extend) is from left to right (from bar 50 to bar 0), it reverses when x1 and x2 are swapped
- price is a function, not a line object property
Variable Type Arrays:
- you can't create an if/function that returns var type value/array - compiler uses strict types and doesn't allow that
- however you can assign array of any type to another array of any type creating an arr pointer of invalid type that must be reassigned to a matching array type before used in any expression to prevent error
- create_any_array2 uses this loophole to return an int_arr pointer of a var type array
- this works for all array types defined with/without var keyword and doesn't work for string arrays defined with var keyword for some reason
- you can't do this with var type vars, only var type arrays because arrays are pointers passed by reference, while vars are actual values passed by value.
- you can only pass a var type value/array param to a function if all functions inside support every type - otherwise error
- alternatively values of every type must be passed simultaneously and processed separately by corresponding if branches/functions supporting these particular types returning a common single type result
- get_var_types solves this problem by generating a list of dummy values of every possible type including the source type, tricking the compiler into allowing a single valid branch to execute without error, while ignoring all dummy results
Notes:
- uses Pinescript v3 Compatibility Framework
- uses Common String Functions Library, Common Fixed Type Array Functions Library, Common Variable Type Array Functions Library
- has to be a separate script to reduce the number of local scopes/compiled file size, can't be merged with another library.
- lets you live test all label/line array functions for errors. If you see an error - change params in UI
- if you see "Loop too long" error - hide/unhide or reattach the script
- if you see "Chart references too many candles" error - change x type or value between abs/rel*. This can happen on charts with 5000+ bars when a rel bar index x is passed to label.new or line.new instead of abs bar index n - x
- create/update_label/line_array* use string lists, while create/update_label/line_array_from_arrays* use array params to create label/line arrays. "from_lists" is dropped to shorten the names of the most commonly used functions.
- create_label/line_array2,4 are preferable, 5,6 are listed for pure demonstration purposes only - don't use them, they don't improve anything but dramatically increase local scopes/compiled file size
- for this reason you would mainly be using create/update_label/line_array2,4 for list params or create/update_label/line_array_from_arrays2 for array params
- all update functions are executed after each create as proof of work and can be disabled. Only create functions are required. Use update functions when necessary - when list/array params are changed by your script.
- both lists and array item properties use the same x,y_type, x,y_base from common settings
- doesn't use pagination, a single str contains all output
- why is this so complicated? What are all these functions for?
- this script merges standard label/line object methods with standard array functions to create a powerful set of label/line object array functions to simplify manipulation of these arrays.
- this library also extends the functionality of Common Variable Type Array Functions Library providing support for label/line types in var type array functions (any_to_str6, join_any_array5)
- creating arrays from either lists or arrays adds a level of flexibility that comes with complexity. It's very likely that in your script you'd have to deal with both string lists as input, and arrays internally, once everything is converted.
- processing user input, allowing customization and targeting for any chart adds a whole new layer of complexity, all inputs must be translated and expanded before used in functions.
- different function implementations can increase/reduce local scopes and compiled file size. Select a version that best suits your needs. Creating complex scripts often requires rewriting your code multiple times to fit the limits, every line matters.
P.S. Don't rely too much on labels, for too often they are fables.
List of functions*:
* - functions from other libraries are not listed
1. Join Functions
Labels
- join_label_object(label_, d1, d2)
- join_label_array(arr, d1, d2)
- join_label_array2(arr, d1, d2, d3)
Lines
- join_line_object(line_, d1, d2)
- join_line_array(arr, d1, d2)
- join_line_array2(arr, d1, d2, d3)
Any Type
- any_to_str6(arr, index, type)
- join_any_array4(arr, d1, d2, type)
- join_any_array5(arr, d, type)
2. GET/SET Functions
Labels
- label_array_get_text(arr, index)
- label_array_get_xy(arr, index)
- label_array_get_fields(arr, index)
- label_array_set_text(arr, index, str)
- label_array_set_xy(arr, index, x, y)
- label_array_set_fields(arr, index, x, y, str)
- label_array_set_all_fields(arr, index, x, y, str, xloc, yloc, label_style, label_color, text_color, text_size, text_align, tooltip)
- label_array_set_all_fields2(arr, index, x, y, str, xloc, yloc, label_style, label_color, text_color, text_size, text_align, tooltip)
Lines
- line_array_get_price(arr, index, bar)
- line_array_get_xy(arr, index)
- line_array_get_fields(arr, index)
- line_array_set_text(arr, index, width)
- line_array_set_xy(arr, index, x1, y1, x2, y2)
- line_array_set_fields(arr, index, x1, y1, x2, y2, width)
- line_array_set_all_fields(arr, index, x1, y1, x2, y2, xloc, extend, line_style, line_color, width)
- line_array_set_all_fields2(arr, index, x1, y1, x2, y2, xloc, extend, line_style, line_color, width)
3. Create/Update/Delete Functions
Labels
- delete_label_array(label_arr)
- create_label_array(list1, list2, list3, list4, list5, d)
- create_label_array2(x_list, y_list, str_list, xloc_list, yloc_list, style_list, color1_list, color2_list, size_list, align_list, tooltip_list, d)
- create_label_array3(x_list, y_list, str_list, xloc_list, yloc_list, style_list, color1_list, color2_list, size_list, align_list, tooltip_list, d)
- create_label_array4(x_list, y_list, str_list, xloc_list, yloc_list, style_list, color1_list, color2_list, size_list, align_list, tooltip_list, d)
- create_label_array5(x_list, y_list, str_list, xloc_list, yloc_list, style_list, color1_list, color2_list, size_list, align_list, tooltip_list, d)
- create_label_array6(x_list, y_list, str_list, xloc_list, yloc_list, style_list, color1_list, color2_list, size_list, align_list, tooltip_list, d)
- update_label_array2(label_arr, x_list, y_list, str_list, xloc_list, yloc_list, style_list, color1_list, color2_list, size_list, align_list, tooltip_list, d)
- update_label_array4(label_arr, x_list, y_list, str_list, xloc_list, yloc_list, style_list, color1_list, color2_list, size_list, align_list, tooltip_list, d)
- create_label_array_from_arrays2(x_arr, y_arr, str_arr, xloc_arr, yloc_arr, style_arr, color1_arr, color2_arr, size_arr, align_arr, tooltip_arr, d)
- create_label_array_from_arrays4(x_arr, y_arr, str_arr, xloc_arr, yloc_arr, style_arr, color1_arr, color2_arr, size_arr, align_arr, tooltip_arr, d)
- update_label_array_from_arrays2(label_arr, x_arr, y_arr, str_arr, xloc_arr, yloc_arr, style_arr, color1_arr, color2_arr, size_arr, align_arr, tooltip_arr, d)
Lines
- delete_line_array(line_arr)
- create_line_array(list1, list2, list3, list4, list5, list6, d)
- create_line_array2(x1_list, y1_list, x2_list, y2_list, xloc_list, extend_list, style_list, color_list, width_list, d)
- create_line_array3(x1_list, y1_list, x2_list, y2_list, xloc_list, extend_list, style_list, color_list, width_list, d)
- create_line_array4(x1_list, y1_list, x2_list, y2_list, xloc_list, extend_list, style_list, color_list, width_list, d)
- create_line_array5(x1_list, y1_list, x2_list, y2_list, xloc_list, extend_list, style_list, color_list, width_list, d)
- create_line_array6(x1_list, y1_list, x2_list, y2_list, xloc_list, extend_list, style_list, color_list, width_list, d)
- update_line_array2(line_arr, x1_list, y1_list, x2_list, y2_list, xloc_list, extend_list, style_list, color_list, width_list, d)
- update_line_array4(line_arr, x1_list, y1_list, x2_list, y2_list, xloc_list, extend_list, style_list, color_list, width_list, d)
- create_line_array_from_arrays2(x1_arr, y1_arr, x2_arr, y2_arr, xloc_arr, extend_arr, style_arr, color_arr, width_arr, d)
- update_line_array_from_arrays2(line_arr, x1_arr, y1_arr, x2_arr, y2_arr, xloc_arr, extend_arr, style_arr, color_arr, width_arr, d)
Using `varip` variables [PineCoders]█ OVERVIEW
The new varip keyword in Pine can be used to declare variables that escape the rollback process, which is explained in the Pine User Manual's page on the execution model . This publication explains how Pine coders can use variables declared with varip to implement logic that was impossible to code in Pine before, such as timing events during the realtime bar, or keeping track of sequences of events that occur during successive realtime updates. We present code that allows you to calculate for how much time a given condition is true during a realtime bar, and show how this can be used to generate alerts.
█ WARNINGS
1. varip is an advanced feature which should only be used by coders already familiar with Pine's execution model and bar states .
2. Because varip only affects the behavior of your code in the realtime bar, it follows that backtest results on strategies built using logic based on varip will be meaningless,
as varip behavior cannot be simulated on historical bars. This also entails that plots on historical bars will not be able to reproduce the script's behavior in realtime.
3. Authors publishing scripts that behave differently in realtime and on historical bars should imperatively explain this to traders.
█ CONCEPTS
Escaping the rollback process
Whereas scripts only execute once at the close of historical bars, when a script is running in realtime, it executes every time the chart's feed detects a price or volume update. At every realtime update, Pine's runtime normally resets the values of a script's variables to their last committed value, i.e., the value they held when the previous bar closed. This is generally handy, as each realtime script execution starts from a known state, which simplifies script logic.
Sometimes, however, script logic requires code to be able to save states between different executions in the realtime bar. Declaring variables with varip now makes that possible. The "ip" in varip stands for "intrabar persist".
Let's look at the following code, which does not use varip :
//@version=4
study("")
int updateNo = na
if barstate.isnew
updateNo := 1
else
updateNo := updateNo + 1
plot(updateNo, style = plot.style_circles)
On historical bars, barstate.isnew is always true, so the plot shows a value of "1". On realtime bars, barstate.isnew is only true when the script first executes on the bar's opening. The plot will then briefly display "1" until subsequent executions occur. On the next executions during the realtime bar, the second branch of the if statement is executed because barstate.isnew is no longer true. Since `updateNo` is initialized to `na` at each execution, the `updateNo + 1` expression yields `na`, so nothing is plotted on further realtime executions of the script.
If we now use varip to declare the `updateNo` variable, the script behaves very differently:
//@version=4
study("")
varip int updateNo = na
if barstate.isnew
updateNo := 1
else
updateNo := updateNo + 1
plot(updateNo, style = plot.style_circles)
The difference now is that `updateNo` tracks the number of realtime updates that occur on each realtime bar. This can happen because the varip declaration allows the value of `updateNo` to be preserved between realtime updates; it is no longer rolled back at each realtime execution of the script. The test on barstate.isnew allows us to reset the update count when a new realtime bar comes in.
█ OUR SCRIPT
Let's move on to our script. It has three parts:
— Part 1 demonstrates how to generate alerts on timed conditions.
— Part 2 calculates the average of realtime update prices using a varip array.
— Part 3 presents a function to calculate the up/down/neutral volume by looking at price and volume variations between realtime bar updates.
Something we could not do in Pine before varip was to time the duration for which a condition is continuously true in the realtime bar. This was not possible because we could not save the beginning time of the first occurrence of the true condition.
One use case for this is a strategy where the system modeler wants to exit before the end of the realtime bar, but only if the exit condition occurs for a specific amount of time. One can thus design a strategy running on a 1H timeframe but able to exit if the exit condition persists for 15 minutes, for example. REMINDER: Using such logic in strategies will make backtesting their complete logic impossible, and backtest results useless, as historical behavior will not match the strategy's behavior in realtime, just as using `calc_on_every_tick = true` will do. Using `calc_on_every_tick = true` is necessary, by the way, when using varip in a strategy, as you want the strategy to run like a study in realtime, i.e., executing on each price or volume update.
Our script presents an `f_secondsSince(_cond, _resetCond)` function to calculate the time for which a condition is continuously true during, or even across multiple realtime bars. It only works in realtime. The abundant comments in the script hopefully provide enough information to understand the details of what it's doing. If you have questions, feel free to ask in the Comments section.
Features
The script's inputs allow you to:
• Specify the number of seconds the tested conditions must last before an alert is triggered (the default is 20 seconds).
• Determine if you want the duration to reset on new realtime bars.
• Require the direction of alerts (up or down) to alternate, which minimizes the number of alerts the script generates.
The inputs showcase the new `tooltip` parameter, which allows additional information to be displayed for each input by hovering over the "i" icon next to it.
The script only displays useful information on realtime bars. This information includes:
• The MA against which the current price is compared to determine the bull or bear conditions.
• A dash which prints on the chart when the bull or bear condition is true.
• An up or down triangle that prints when an alert is generated. The triangle will only appear on the update where the alert is triggered,
and unless that happens to be on the last execution of the realtime bar, it will not persist on the chart.
• The log of all triggered alerts to the right of the realtime bar.
• A gray square on top of the elapsed realtime bars where one or more alerts were generated. The square's tooltip displays the alert log for that bar.
• A yellow dot corresponding to the average price of all realtime bar updates, which is calculated using a varip array in "Part 2" of the script.
• Various key values in the Data Window for each parts of the script.
Note that the directional volume information calculated in Part 3 of the script is not plotted on the chart—only in the Data Window.
Using the script
You can try running the script on an open market with a 30sec timeframe. Because the default settings reset the duration on new realtime bars and require a 20 second delay, a reasonable amount of alerts will trigger.
Creating an alert on the script
You can create a script alert on the script. Keep in mind that when you create an alert from this script, the duration calculated by the instance of the script running the alert will not necessarily match that of the instance running on your chart, as both started their calculations at different times. Note that we use alert.freq_all in our alert() calls, so that alerts will trigger on all instances where the associated condition is met. If your alert is being paused because it reaches the maximum of 15 triggers in 3 minutes, you can configure the script's inputs so that up/down alerts must alternate. Also keep in mind that alerts run a distinct instance of your script on different servers, so discrepancies between the behavior of scripts running on charts and alerts can occur, especially if they trigger very often.
Challenges
Events detected in realtime using variables declared with varip can be transient and not leave visible traces at the close of the realtime bar, as is the case with our script, which can trigger multiple alerts during the same realtime bar, when the script's inputs allow for this. In such cases, elapsed realtime bars will be of no use in detecting past realtime bar events unless dedicated code is used to save traces of events, as we do with our alert log in this script, which we display as a tooltip on elapsed realtime bars.
█ NOTES
Realtime updates
We have no control over when realtime updates occur. A realtime bar can open, and then no realtime updates can occur until the open of the next realtime bar. The time between updates can vary considerably.
Past values
There is no mechanism to refer to past values of a varip variable across realtime executions in the same bar. Using the history-referencing operator will, as usual, return the variable's committed value on previous bars. If you want to preserve past values of a varip variable, they must be saved in other variables or in an array .
Resetting variables
Because varip variables not only preserve their values across realtime updates, but also across bars, you will typically need to plan conditions that will at some point reset their values to a known state. Testing on barstate.isnew , as we do, is a good way to achieve that.
Repainting
The fact that a script uses varip does not make it necessarily repainting. A script could conceivably use varip to calculate values saved when the realtime bar closes, and then use confirmed values of those calculations from the previous bar to trigger alerts or display plots, avoiding repaint.
timenow resolution
Although the variable is expressed in milliseconds it has an actual resolution of seconds, so it only increments in multiples of 1000 milliseconds.
Warn script users
When using varip to implement logic that cannot be replicated on historical bars, it's really important to explain this to traders in published script descriptions, even if you publish open-source. Remember that most TradingViewers do not know Pine.
New Pine features used in this script
This script uses three new Pine features:
• varip
• The `tooltip` parameter in input() .
• The new += assignment operator. See these also: -= , *= , /= and %= .
Example scripts
These are other scripts by PineCoders that use varip :
• Tick Delta Volume , by RicadoSantos .
• Tick Chart and Volume Info from Lower Time Frames by LonesomeTheBlue .
Thanks
Thanks to the PineCoders who helped improve this publication—especially to bmistiaen .
Look first. Then leap.
VPA ANALYSIS VPA Analysis provide the indications for various conditions as per the Volume Spread Analysis concept. The various legends are provided below
LEGEND DETAILS
UT1 - Upthrust Bar: This will be widespread Bar on high Volume closing on the low. This normally happens after an up move. Here the smart money move the price to the High and then quickly brings to the Low trapping many retail trader who rushed into in order not to miss the bullish move. This is a bearish Signal
UT2 -Upthrust Bar Confirmation: A widespread Down Bar following a Upthrust Bar. This confirms the weakness of the Upthrust Bar. Expect the stock to move down
Confirms . This is a Bearish Signal
PUT - Pseudo Upthrust: An Upthrust Bar in bar action but the volume remains average. This still indicates weakness. Indicate Possible Bearishness
PUC -Pseudo Upthrust Confirmation: widespread Bar after a pseudo–Upthrust Bar confirms the weakness of the Pseudo Upthrust Bar
Confirms Bearishness
BC - Buying Climax: A very wide Spread bar on ultra-High Volume closing at the top. Such a Bar indicates the climatic move in an uptrend. This Bar traps many retailers as the uptrend ends and reverses quickly. Confirms Bearishness
TC - Trend Change: This Indicates a possible Trend Change in an uptrend. Indicates Weakness
SEC- Sell Condition: This bar indicates confluence of some bearish signals. Possible end of Uptrend and start of Downtrend soon. Bearish Signal
UT - Upthrust Condition: When multiple bearish signals occur, the legend is printed in two lines. The Legend “UT” indicates that an upthrust condition is present. Bearish Signal
ND - No demand in uptrend: This bar indicates that there is no demand. In an uptrend this indicates weakness. Bearish Signal
ND - No Demand: This bar indicates that there is no demand. This can occur in any part of the Trend. In all place other than in an uptrend this just indicates just weakness
ED - Effort to Move Down: Widespread Bar closing down on High volume or above average volume . The smart money is pushing the prices down. Bearish Signal
EDF - Effort to Move Down Failed: Widespread / above average spread Bar closing up on High volume or above average volume appearing after ‘Effort to move down” bar.
This indicates that the Effort to move the pries down has failed. Bullish signal
SV - Stopping Volume: A high volume medium to widespread Bar closing in the upper middle part in a down trend indicates that smart money is buying. This is an indication that the down trend is likely to end soon. Indicates strength
ST1 - Strength Returning 1: Strength seen returning after a down trend. High volume adds to strength. Indicates Strength
ST2 - Strength Returning 2: Strength seen returning after a down trend. High volume adds to strength.
BYC - Buy Condition: This bar indicates confluence of some bullish signals Possible end of downtrend and start of uptrend soon. Indicates Strength
EU - Effort to Move Up: Widespread Bar closing up on High volume or above average volume . The smart money is pushing the prices up. Bullish Signal
EUF - Effort to Move Up Failed: Widespread / above average spread Bar closing down on High volume or above average volume appearing after ‘Effort to move up” bar.
This indicates that the Effort to move the pries up has failed. Bearish Signal
LVT- Low Volume Test: A low volume bar dipping into previous supply area and closing in the upper part of the Bar. A successful test is a positive sign. Indicates Strength
ST(after a LVT ) - Strength after Successful Low Volume Test: An up Bar closing near High after a Test confirms strength. Bullish Signal
RUT - Reverse Upthrust Bar: This will be a widespread Bar on high Volume closing on the high is a Down Trend. Here the buyers have become active and move the prices from the low to High. The down Move is likely to end and up trend likely to start soon. indicates Strength
NS - No supply Bar: This bar indicates that there is no supply. This is a sign of strength especially in a down trend. Indicates strength
ST - Strength Returns: When multiple bullish signals occur, the legend is printed in two lines. The Legend “ST” indicates that an condition of strength other than the condition mentioned in the second line is present. Bullish Signals
BAR COLORS
Green- Bullish / Strength
Red - Bearish / weakness
Blue / White - Sentiment Changing from bullish to Bearish and Vice Versa
Trend Gauge [BullByte]Trend Gauge
Summary
A multi-factor trend detection indicator that aggregates EMA alignment, VWMA momentum scaling, volume spikes, ATR breakout strength, higher-timeframe confirmation, ADX-based regime filtering, and RSI pivot-divergence penalty into one normalized trend score. It also provides a confidence meter, a Δ Score momentum histogram, divergence highlights, and a compact, scalable dashboard for at-a-glance status.
________________________________________
## 1. Purpose of the Indicator
Why this was built
Traders often monitor several indicators in parallel - EMAs, volume signals, volatility breakouts, higher-timeframe trends, ADX readings, divergence alerts, etc., which can be cumbersome and sometimes contradictory. The “Trend Gauge” indicator was created to consolidate these complementary checks into a single, normalized score that reflects the prevailing market bias (bullish, bearish, or neutral) and its strength. By combining multiple inputs with an adaptive regime filter, scaling contributions by magnitude, and penalizing weakening signals (divergence), this tool aims to reduce noise, highlight genuine trend opportunities, and warn when momentum fades.
Key Design Goals
Signal Aggregation
Merged trend-following signals (EMA crossover, ATR breakout, higher-timeframe confirmation) and momentum signals (VWMA thrust, volume spikes) into a unified score that reflects directional bias more holistically.
Market Regime Awareness
Implemented an ADX-style filter to distinguish between trending and ranging markets, reducing the influence of trend signals during sideways phases to avoid false breakouts.
Magnitude-Based Scaling
Replaced binary contributions with scaled inputs: VWMA thrust and ATR breakout are weighted relative to recent averages, allowing for more nuanced score adjustments based on signal strength.
Momentum Divergence Penalty
Integrated pivot-based RSI divergence detection to slightly reduce the overall score when early signs of momentum weakening are detected, improving risk-awareness in entries.
Confidence Transparency
Added a live confidence metric that shows what percentage of enabled sub-indicators currently agree with the overall bias, making the scoring system more interpretable.
Momentum Acceleration Visualization
Plotted the change in score (Δ Score) as a histogram bar-to-bar, highlighting whether momentum is increasing, flattening, or reversing, aiding in more timely decision-making.
Compact Informational Dashboard
Presented a clean, scalable dashboard that displays each component’s status, the final score, confidence %, detected regime (Trending/Ranging), and a labeled strength gauge for quick visual assessment.
________________________________________
## 2. Why a Trader Should Use It
Main benefits and use cases
1. Unified View: Rather than juggling multiple windows or panels, this indicator delivers a single score synthesizing diverse signals.
2. Regime Filtering: In ranging markets, trend signals often generate false entries. The ADX-based regime filter automatically down-weights trend-following components, helping you avoid chasing false breakouts.
3. Nuanced Momentum & Volatility: VWMA and ATR breakout contributions are normalized by recent averages, so strong moves register strongly while smaller fluctuations are de-emphasized.
4. Early Warning of Weakening: Pivot-based RSI divergence is detected and used to slightly reduce the score when price/momentum diverges, giving a cautionary signal before a full reversal.
5. Confidence Meter: See at a glance how many sub-indicators align with the aggregated bias (e.g., “80% confidence” means 4 out of 5 components agree ). This transparency avoids black-box decisions.
6. Trend Acceleration/Deceleration View: The Δ Score histogram visualizes whether the aggregated score is rising (accelerating trend) or falling (momentum fading), supplementing the main oscillator.
7. Compact Dashboard: A corner table lists each check’s status (“Bull”, “Bear”, “Flat” or “Disabled”), plus overall Score, Confidence %, Regime, Trend Strength label, and a gauge bar. Users can scale text size (Normal, Small, Tiny) without removing elements, so the full picture remains visible even in compact layouts.
8. Customizable & Transparent: All components can be enabled/disabled and parameterized (lengths, thresholds, weights). The full Pine code is open and well-commented, letting users inspect or adapt the logic.
9. Alert-ready: Built-in alert conditions fire when the score crosses weak thresholds to bullish/bearish or returns to neutral, enabling timely notifications.
________________________________________
## 3. Component Rationale (“Why These Specific Indicators?”)
Each sub-component was chosen because it adds complementary information about trend or momentum:
1. EMA Cross
o Basic trend measure: compares a faster EMA vs. a slower EMA. Quickly reflects trend shifts but by itself can whipsaw in sideways markets.
2. VWMA Momentum
o Volume-weighted moving average change indicates momentum with volume context. By normalizing (dividing by a recent average absolute change), we capture the strength of momentum relative to recent history. This scaling prevents tiny moves from dominating and highlights genuinely strong momentum.
3. Volume Spikes
o Sudden jumps in volume combined with price movement often accompany stronger moves or reversals. A binary detection (+1 for bullish spike, -1 for bearish spike) flags high-conviction bars.
4. ATR Breakout
o Detects price breaking beyond recent highs/lows by a multiple of ATR. Measures breakout strength by how far beyond the threshold price moves relative to ATR, capped to avoid extreme outliers. This gives a volatility-contextual trend signal.
5. Higher-Timeframe EMA Alignment
o Confirms whether the shorter-term trend aligns with a higher timeframe trend. Uses request.security with lookahead_off to avoid future data. When multiple timeframes agree, confidence in direction increases.
6. ADX Regime Filter (Manual Calculation)
o Computes directional movement (+DM/–DM), smoothes via RMA, computes DI+ and DI–, then a DX and ADX-like value. If ADX ≥ threshold, market is “Trending” and trend components carry full weight; if ADX < threshold, “Ranging” mode applies a configurable weight multiplier (e.g., 0.5) to trend-based contributions, reducing false signals in sideways conditions. Volume spikes remain binary (optional behavior; can be adjusted if desired).
7. RSI Pivot-Divergence Penalty
o Uses ta.pivothigh / ta.pivotlow with a lookback to detect pivot highs/lows on price and corresponding RSI values. When price makes a higher high but RSI makes a lower high (bearish divergence), or price makes a lower low but RSI makes a higher low (bullish divergence), a divergence signal is set. Rather than flipping the trend outright, the indicator subtracts (or adds) a small penalty (configurable) from the aggregated score if it would weaken the current bias. This subtle adjustment warns of weakening momentum without overreacting to noise.
8. Confidence Meter
o Counts how many enabled components currently agree in direction with the aggregated score (i.e., component sign × score sign > 0). Displays this as a percentage. A high percentage indicates strong corroboration; a low percentage warns of mixed signals.
9. Δ Score Momentum View
o Plots the bar-to-bar change in the aggregated score (delta_score = score - score ) as a histogram. When positive, bars are drawn in green above zero; when negative, bars are drawn in red below zero. This reveals acceleration (rising Δ) or deceleration (falling Δ), supplementing the main oscillator.
10. Dashboard
• A table in the indicator pane’s top-right with 11 rows:
1. EMA Cross status
2. VWMA Momentum status
3. Volume Spike status
4. ATR Breakout status
5. Higher-Timeframe Trend status
6. Score (numeric)
7. Confidence %
8. Regime (“Trending” or “Ranging”)
9. Trend Strength label (e.g., “Weak Bullish Trend”, “Strong Bearish Trend”)
10. Gauge bar visually representing score magnitude
• All rows always present; size_opt (Normal, Small, Tiny) only changes text size via text_size, not which elements appear. This ensures full transparency.
________________________________________
## 4. What Makes This Indicator Stand Out
• Regime-Weighted Multi-Factor Score: Trend and momentum signals are adaptively weighted by market regime (trending vs. ranging) , reducing false signals.
• Magnitude Scaling: VWMA and ATR breakout contributions are normalized by recent average momentum or ATR, giving finer gradation compared to simple ±1.
• Integrated Divergence Penalty: Divergence directly adjusts the aggregated score rather than appearing as a separate subplot; this influences alerts and trend labeling in real time.
• Confidence Meter: Shows the percentage of sub-signals in agreement, providing transparency and preventing blind trust in a single metric.
• Δ Score Histogram Momentum View: A histogram highlights acceleration or deceleration of the aggregated trend score, helping detect shifts early.
• Flexible Dashboard: Always-visible component statuses and summary metrics in one place; text size scaling keeps the full picture available in cramped layouts.
• Lookahead-Safe HTF Confirmation: Uses lookahead_off so no future data is accessed from higher timeframes, avoiding repaint bias.
• Repaint Transparency: Divergence detection uses pivot functions that inherently confirm only after lookback bars; description documents this lag so users understand how and when divergence labels appear.
• Open-Source & Educational: Full, well-commented Pine v6 code is provided; users can learn from its structure: manual ADX computation, conditional plotting with series = show ? value : na, efficient use of table.new in barstate.islast, and grouped inputs with tooltips.
• Compliance-Conscious: All plots have descriptive titles; inputs use clear names; no unnamed generic “Plot” entries; manual ADX uses RMA; all request.security calls use lookahead_off. Code comments mention repaint behavior and limitations.
________________________________________
## 5. Recommended Timeframes & Tuning
• Any Timeframe: The indicator works on small (e.g., 1m) to large (daily, weekly) timeframes. However:
o On very low timeframes (<1m or tick charts), noise may produce frequent whipsaws. Consider increasing smoothing lengths, disabling certain components (e.g., volume spike if volume data noisy), or using a larger pivot lookback for divergence.
o On higher timeframes (daily, weekly), consider longer lookbacks for ATR breakout or divergence, and set Higher-Timeframe trend appropriately (e.g., 4H HTF when on 5 Min chart).
• Defaults & Experimentation: Default input values are chosen to be balanced for many liquid markets. Users should test with replay or historical analysis on their symbol/timeframe and adjust:
o ADX threshold (e.g., 20–30) based on instrument volatility.
o VWMA and ATR scaling lengths to match average volatility cycles.
o Pivot lookback for divergence: shorter for faster markets, longer for slower ones.
• Combining with Other Analysis: Use in conjunction with price action, support/resistance, candlestick patterns, order flow, or other tools as desired. The aggregated score and alerts can guide attention but should not be the sole decision-factor.
________________________________________
## 6. How Scoring and Logic Works (Step-by-Step)
1. Compute Sub-Scores
o EMA Cross: Evaluate fast EMA > slow EMA ? +1 : fast EMA < slow EMA ? -1 : 0.
o VWMA Momentum: Calculate vwma = ta.vwma(close, length), then vwma_mom = vwma - vwma . Normalize: divide by recent average absolute momentum (e.g., ta.sma(abs(vwma_mom), lookback)), clip to .
o Volume Spike: Compute vol_SMA = ta.sma(volume, len). If volume > vol_SMA * multiplier AND price moved up ≥ threshold%, assign +1; if moved down ≥ threshold%, assign -1; else 0.
o ATR Breakout: Determine recent high/low over lookback. If close > high + ATR*mult, compute distance = close - (high + ATR*mult), normalize by ATR, cap at a configured maximum. Assign positive contribution. Similarly for bearish breakout below low.
o Higher-Timeframe Trend: Use request.security(..., lookahead=barmerge.lookahead_off) to fetch HTF EMAs; assign +1 or -1 based on alignment.
2. ADX Regime Weighting
o Compute manual ADX: directional movements (+DM, –DM), smoothed via RMA, DI+ and DI–, then DX and ADX via RMA. If ADX ≥ threshold, market is considered “Trending”; otherwise “Ranging.”
o If trending, trend-based contributions (EMA, VWMA, ATR, HTF) use full weight = 1.0. If ranging, use weight = ranging_weight (e.g., 0.5) to down-weight them. Volume spike stays binary ±1 (optional to change if desired).
3. Aggregate Raw Score
o Sum weighted contributions of all enabled components. Count the number of enabled components; if zero, default count = 1 to avoid division by zero.
4. Divergence Penalty
o Detect pivot highs/lows on price and corresponding RSI values, using a lookback. When price and RSI diverge (bearish or bullish divergence), check if current raw score is in the opposing direction:
If bearish divergence (price higher high, RSI lower high) and raw score currently positive, subtract a penalty (e.g., 0.5).
If bullish divergence (price lower low, RSI higher low) and raw score currently negative, add a penalty.
o This reduces score magnitude to reflect weakening momentum, without flipping the trend outright.
5. Normalize and Smooth
o Normalized score = (raw_score / number_of_enabled_components) * 100. This yields a roughly range.
o Optional EMA smoothing of this normalized score to reduce noise.
6. Interpretation
o Sign: >0 = net bullish bias; <0 = net bearish bias; near zero = neutral.
o Magnitude Zones: Compare |score| to thresholds (Weak, Medium, Strong) to label trend strength (e.g., “Weak Bullish Trend”, “Medium Bearish Trend”, “Strong Bullish Trend”).
o Δ Score Histogram: The histogram bars from zero show change from previous bar’s score; positive bars indicate acceleration, negative bars indicate deceleration.
o Confidence: Percentage of sub-indicators aligned with the score’s sign.
o Regime: Indicates whether trend-based signals are fully weighted or down-weighted.
________________________________________
## 7. Oscillator Plot & Visualization: How to Read It
Main Score Line & Area
The oscillator plots the aggregated score as a line, with colored fill: green above zero for bullish area, red below zero for bearish area. Horizontal reference lines at ±Weak, ±Medium, and ±Strong thresholds mark zones: crossing above +Weak suggests beginning of bullish bias, above +Medium for moderate strength, above +Strong for strong trend; similarly for bearish below negative thresholds.
Δ Score Histogram
If enabled, a histogram shows score - score . When positive, bars appear in green above zero, indicating accelerating bullish momentum; when negative, bars appear in red below zero, indicating decelerating or reversing momentum. The height of each bar reflects the magnitude of change in the aggregated score from the prior bar.
Divergence Highlight Fill
If enabled, when a pivot-based divergence is confirmed:
• Bullish Divergence : fill the area below zero down to –Weak threshold in green, signaling potential reversal from bearish to bullish.
• Bearish Divergence : fill the area above zero up to +Weak threshold in red, signaling potential reversal from bullish to bearish.
These fills appear with a lag equal to pivot lookback (the number of bars needed to confirm the pivot). They do not repaint after confirmation, but users must understand this lag.
Trend Direction Label
When score crosses above or below the Weak threshold, a small label appears near the score line reading “Bullish” or “Bearish.” If the score returns within ±Weak, the label “Neutral” appears. This helps quickly identify shifts at the moment they occur.
Dashboard Panel
In the indicator pane’s top-right, a table shows:
1. EMA Cross status: “Bull”, “Bear”, “Flat”, or “Disabled”
2. VWMA Momentum status: similarly
3. Volume Spike status: “Bull”, “Bear”, “No”, or “Disabled”
4. ATR Breakout status: “Bull”, “Bear”, “No”, or “Disabled”
5. Higher-Timeframe Trend status: “Bull”, “Bear”, “Flat”, or “Disabled”
6. Score: numeric value (rounded)
7. Confidence: e.g., “80%” (colored: green for high, amber for medium, red for low)
8. Regime: “Trending” or “Ranging” (colored accordingly)
9. Trend Strength: textual label based on magnitude (e.g., “Medium Bullish Trend”)
10. Gauge: a bar of blocks representing |score|/100
All rows remain visible at all times; changing Dashboard Size only scales text size (Normal, Small, Tiny).
________________________________________
## 8. Example Usage (Illustrative Scenario)
Example: BTCUSD 5 Min
1. Setup: Add “Trend Gauge ” to your BTCUSD 5 Min chart. Defaults: EMAs (8/21), VWMA 14 with lookback 3, volume spike settings, ATR breakout 14/5, HTF = 5m (or adjust to 4H if preferred), ADX threshold 25, ranging weight 0.5, divergence RSI length 14 pivot lookback 5, penalty 0.5, smoothing length 3, thresholds Weak=20, Medium=50, Strong=80. Dashboard Size = Small.
2. Trend Onset: At some point, price breaks above recent high by ATR multiple, volume spikes upward, faster EMA crosses above slower EMA, HTF EMA also bullish, and ADX (manual) ≥ threshold → aggregated score rises above +20 (Weak threshold) into +Medium zone. Dashboard shows “Bull” for EMA, VWMA, Vol Spike, ATR, HTF; Score ~+60–+70; Confidence ~100%; Regime “Trending”; Trend Strength “Medium Bullish Trend”; Gauge ~6–7 blocks. Δ Score histogram bars are green and rising, indicating accelerating bullish momentum. Trader notes the alignment.
3. Divergence Warning: Later, price makes a slightly higher high but RSI fails to confirm (lower RSI high). Pivot lookback completes; the indicator highlights a bearish divergence fill above zero and subtracts a small penalty from the score, causing score to stall or retrace slightly. Dashboard still bullish but score dips toward +Weak. This warns the trader to tighten stops or take partial profits.
4. Trend Weakens: Score eventually crosses below +Weak back into neutral; a “Neutral” label appears, and a “Neutral Trend” alert fires if enabled. Trader exits or avoids new long entries. If score subsequently crosses below –Weak, a “Bearish” label and alert occur.
5. Customization: If the trader finds VWMA noise too frequent on this instrument, they may disable VWMA or increase lookback. If ATR breakouts are too rare, adjust ATR length or multiplier. If ADX threshold seems off, tune threshold. All these adjustments are explained in Inputs section.
6. Visualization: The screenshot shows the main score oscillator with colored areas, reference lines at ±20/50/80, Δ Score histogram bars below/above zero, divergence fill highlighting potential reversal, and the dashboard table in the top-right.
________________________________________
## 9. Inputs Explanation
A concise yet clear summary of inputs helps users understand and adjust:
1. General Settings
• Theme (Dark/Light): Choose background-appropriate colors for the indicator pane.
• Dashboard Size (Normal/Small/Tiny): Scales text size only; all dashboard elements remain visible.
2. Indicator Settings
• Enable EMA Cross: Toggle on/off basic EMA alignment check.
o Fast EMA Length and Slow EMA Length: Periods for EMAs.
• Enable VWMA Momentum: Toggle VWMA momentum check.
o VWMA Length: Period for VWMA.
o VWMA Momentum Lookback: Bars to compare VWMA to measure momentum.
• Enable Volume Spike: Toggle volume spike detection.
o Volume SMA Length: Period to compute average volume.
o Volume Spike Multiplier: How many times above average volume qualifies as spike.
o Min Price Move (%): Minimum percent change in price during spike to qualify as bullish or bearish.
• Enable ATR Breakout: Toggle ATR breakout detection.
o ATR Length: Period for ATR.
o Breakout Lookback: Bars to look back for recent highs/lows.
o ATR Multiplier: Multiplier for breakout threshold.
• Enable Higher Timeframe Trend: Toggle HTF EMA alignment.
o Higher Timeframe: E.g., “5” for 5-minute when on 1-minute chart, or “60” for 5 Min when on 15m, etc. Uses lookahead_off.
• Enable ADX Regime Filter: Toggles regime-based weighting.
o ADX Length: Period for manual ADX calculation.
o ADX Threshold: Value above which market considered trending.
o Ranging Weight Multiplier: Weight applied to trend components when ADX < threshold (e.g., 0.5).
• Scale VWMA Momentum: Toggle normalization of VWMA momentum magnitude.
o VWMA Mom Scale Lookback: Period for average absolute VWMA momentum.
• Scale ATR Breakout Strength: Toggle normalization of breakout distance by ATR.
o ATR Scale Cap: Maximum multiple of ATR used for breakout strength.
• Enable Price-RSI Divergence: Toggle divergence detection.
o RSI Length for Divergence: Period for RSI.
o Pivot Lookback for Divergence: Bars on each side to identify pivot high/low.
o Divergence Penalty: Amount to subtract/add to score when divergence detected (e.g., 0.5).
3. Score Settings
• Smooth Score: Toggle EMA smoothing of normalized score.
• Score Smoothing Length: Period for smoothing EMA.
• Weak Threshold: Absolute score value under which trend is considered weak or neutral.
• Medium Threshold: Score above Weak but below Medium is moderate.
• Strong Threshold: Score above this indicates strong trend.
4. Visualization Settings
• Show Δ Score Histogram: Toggle display of the bar-to-bar change in score as a histogram. Default true.
• Show Divergence Fill: Toggle background fill highlighting confirmed divergences. Default true.
Each input has a tooltip in the code.
________________________________________
## 10. Limitations, Repaint Notes, and Disclaimers
10.1. Repaint & Lag Considerations
• Pivot-Based Divergence Lag: The divergence detection uses ta.pivothigh / ta.pivotlow with a specified lookback. By design, a pivot is only confirmed after the lookback number of bars. As a result:
o Divergence labels or fills appear with a delay equal to the pivot lookback.
o Once the pivot is confirmed and the divergence is detected, the fill/label does not repaint thereafter, but you must understand and accept this lag.
o Users should not treat divergence highlights as predictive signals without additional confirmation, because they appear after the pivot has fully formed.
• Higher-Timeframe EMA Alignment: Uses request.security(..., lookahead=barmerge.lookahead_off), so no future data from the higher timeframe is used. This avoids lookahead bias and ensures signals are based only on completed higher-timeframe bars.
• No Future Data: All calculations are designed to avoid using future information. For example, manual ADX uses RMA on past data; security calls use lookahead_off.
10.2. Market & Noise Considerations
• In very choppy or low-liquidity markets, some components (e.g., volume spikes or VWMA momentum) may be noisy. Users can disable or adjust those components’ parameters.
• On extremely low timeframes, noise may dominate; consider smoothing lengths or disabling certain features.
• On very high timeframes, pivots and breakouts occur less frequently; adjust lookbacks accordingly to avoid sparse signals.
10.3. Not a Standalone Trading System
• This is an indicator, not a complete trading strategy. It provides signals and context but does not manage entries, exits, position sizing, or risk management.
• Users must combine it with their own analysis, money management, and confirmations (e.g., price patterns, support/resistance, fundamental context).
• No guarantees: past behavior does not guarantee future performance.
10.4. Disclaimers
• Educational Purposes Only: The script is provided as-is for educational and informational purposes. It does not constitute financial, investment, or trading advice.
• Use at Your Own Risk: Trading involves risk of loss. Users should thoroughly test and use proper risk management.
• No Guarantees: The author is not responsible for trading outcomes based on this indicator.
• License: Published under Mozilla Public License 2.0; code is open for viewing and modification under MPL terms.
________________________________________
## 11. Alerts
• The indicator defines three alert conditions:
1. Bullish Trend: when the aggregated score crosses above the Weak threshold.
2. Bearish Trend: when the score crosses below the negative Weak threshold.
3. Neutral Trend: when the score returns within ±Weak after being outside.
Good luck
– BullByte
FVG Premium [no1x]█ OVERVIEW
This indicator provides a comprehensive toolkit for identifying, visualizing, and tracking Fair Value Gaps (FVGs) across three distinct timeframes (current chart, a user-defined Medium Timeframe - MTF, and a user-defined High Timeframe - HTF). It is designed to offer traders enhanced insight into FVG dynamics through detailed state monitoring (formation, partial fill, full mitigation, midline touch), extensive visual customization for FVG representation, and a rich alert system for timely notifications on FVG-related events.
█ CONCEPTS
This indicator is built upon the core concept of Fair Value Gaps (FVGs) and their significance in price action analysis, offering a multi-layered approach to their detection and interpretation across different timeframes.
Fair Value Gaps (FVGs)
A Fair Value Gap (FVG), also known as an imbalance, represents a range in price delivery where one side of the market (buying or selling) was more aggressive, leaving an inefficiency or an "imbalance" in the price action. This concept is prominently featured within Smart Money Concepts (SMC) and Inner Circle Trader (ICT) methodologies, where such gaps are often interpreted as footprints left by "smart money" due to rapid, forceful price movements. These methodologies suggest that price may later revisit these FVG zones to rebalance a prior inefficiency or to seek liquidity before continuing its path. These gaps are typically identified by a three-bar pattern:
Bullish FVG : This is a three-candle formation where the second candle shows a strong upward move. The FVG is the space created between the high of the first candle (bottom of FVG) and the low of the third candle (top of FVG). This indicates a strong upward impulsive move.
Bearish FVG : This is a three-candle formation where the second candle shows a strong downward move. The FVG is the space created between the low of the first candle (top of FVG) and the high of the third candle (bottom of FVG). This indicates a strong downward impulsive move.
FVGs are often watched by traders as potential areas where price might return to "rebalance" or find support/resistance.
Multi-Timeframe (MTF) Analysis
The indicator extends FVG detection beyond the current chart's timeframe (Low Timeframe - LTF) to two higher user-defined timeframes: Medium Timeframe (MTF) and High Timeframe (HTF). This allows traders to:
Identify FVGs that might be significant on a broader market structure.
Observe how FVGs from different timeframes align or interact.
Gain a more comprehensive perspective on potential support and resistance zones.
FVG State and Lifecycle Management
The indicator actively tracks the lifecycle of each detected FVG:
Formation : The initial identification of an FVG.
Partial Fill (Entry) : When price enters but does not completely pass through the FVG. The indicator updates the "current" top/bottom of the FVG to reflect the filled portion.
Midline (Equilibrium) Touch : When price touches the 50% level of the FVG.
Full Mitigation : When price completely trades through the FVG, effectively "filling" or "rebalancing" the gap. The indicator records the mitigation time.
This state tracking is crucial for understanding how price interacts with these zones.
FVG Classification (Large FVG)
FVGs can be optionally classified as "Large FVGs" (LV) if their size (top to bottom range) exceeds a user-defined multiple of the Average True Range (ATR) for that FVG's timeframe. This helps distinguish FVGs that are significantly larger relative to recent volatility.
Visual Customization and Information Delivery
A key concept is providing extensive control over how FVGs are displayed. This control is achieved through a centralized set of visual parameters within the indicator, allowing users to configure numerous aspects (colors, line styles, visibility of boxes, midlines, mitigation lines, labels, etc.) for each timeframe. Additionally, an on-chart information panel summarizes the nearest unmitigated bullish and bearish FVG levels for each active timeframe, providing a quick glance at key price points.
█ FEATURES
This indicator offers a rich set of features designed to provide a highly customizable and comprehensive Fair Value Gap (FVG) analysis experience. Users can tailor the FVG detection, visual representation, and alerting mechanisms across three distinct timeframes: the current chart (Low Timeframe - LTF), a user-defined Medium Timeframe (MTF), and a user-defined High Timeframe (HTF).
Multi-Timeframe FVG Detection and Display
The core strength of this indicator lies in its ability to identify and display FVGs from not only the current chart's timeframe (LTF) but also from two higher, user-selectable timeframes (MTF and HTF).
Timeframe Selection: Users can specify the exact MTF (e.g., "60", "240") and HTF (e.g., "D", "W") through dedicated inputs in the "MTF (Medium Timeframe)" and "HTF (High Timeframe)" settings groups. The visibility of FVGs from these higher timeframes can be toggled independently using the "Show MTF FVGs" and "Show HTF FVGs" checkboxes.
Consistent Detection Logic: The FVG detection logic, based on the classic three-bar imbalance pattern detailed in the 'Concepts' section, is applied consistently across all selected timeframes (LTF, MTF, HTF)
Timeframe-Specific Visuals: Each timeframe's FVGs (LTF, MTF, HTF) can be customized with unique colors for bullish/bearish states and their mitigated counterparts. This allows for easy visual differentiation of FVGs originating from different market perspectives.
Comprehensive FVG Visualization Options
The indicator provides extensive control over how FVGs are visually represented on the chart for each timeframe (LTF, MTF, HTF).
FVG Boxes:
Visibility: Main FVG boxes can be shown or hidden per timeframe using the "Show FVG Boxes" (for LTF), "Show Boxes" (for MTF/HTF) inputs.
Color Customization: Colors for bullish, bearish, active, and mitigated FVG boxes (including Large FVGs, if classified) are fully customizable for each timeframe.
Box Extension & Length: FVG boxes can either be extended to the right indefinitely ("Extend Boxes Right") or set to a fixed length in bars ("Short Box Length" or "Box Length" equivalent inputs).
Box Labels: Optional labels can display the FVG's timeframe and fill percentage on the box. These labels are configurable for all timeframes (LTF, MTF, and HTF). Please note: If FVGs are positioned very close to each other on the chart, their respective labels may overlap. This can potentially lead to visual clutter, and it is a known behavior in the current version of the indicator.
Box Borders: Visibility, width, style (solid, dashed, dotted), and color of FVG box borders are customizable per timeframe.
Midlines (Equilibrium/EQ):
Visibility: The 50% level (midline or EQ) of FVGs can be shown or hidden for each timeframe.
Style Customization: Width, style, and color of the midline are customizable per timeframe. The indicator tracks if this midline has been touched by price.
Mitigation Lines:
Visibility: Mitigation lines (representing the FVG's opening level that needs to be breached for full mitigation) can be shown or hidden for each timeframe. If shown, these lines are always extended to the right.
Style Customization: Width, style, and color of the mitigation line are customizable per timeframe.
Mitigation Line Labels: Optional price labels can be displayed on mitigation lines, with a customizable horizontal bar offset for positioning. For optimal label placement, the following horizontal bar offsets are recommended: 4 for LTF, 8 for MTF, and 12 for HTF.
Persistence After Mitigation: Users can choose to keep mitigation lines visible even after an FVG is fully mitigated, with a distinct color for such lines. Importantly, this option is only effective if the general setting 'Hide Fully Mitigated FVGs' is disabled, as otherwise, the entire FVG and its lines will be removed upon mitigation.
FVG State Management and Behavior
The indicator tracks and visually responds to changes in FVG states.
Hide Fully Mitigated FVGs: This option, typically found in the indicator's general settings, allows users to automatically remove all visual elements of an FVG from the chart once price has fully mitigated it. This helps maintain chart clarity by focusing on active FVGs.
Partial Fill Visualization: When price enters an FVG, the indicator offers a dynamic visual representation: the portion of the FVG that has been filled is shown as a "mitigated box" (typically with a distinct color), while the original FVG box shrinks to clearly highlight the remaining, unfilled portion. This two-part display provides an immediate visual cue about how much of the FVG's imbalance has been addressed and what potential remains within the gap.
Visual Filtering by ATR Proximity: To help users focus on the most relevant price action, FVGs can be dynamically hidden if they are located further from the current price than a user-defined multiple of the Average True Range (ATR). This behavior is controlled by the "Filter Band Width (ATR Multiple)" input; setting this to zero disables the filter entirely, ensuring all detected FVGs remain visible regardless of their proximity to price.
Alternative Usage Example: Mitigation Lines as Key Support/Resistance Levels
For traders preferring a minimalist chart focused on key Fair Value Gap (FVG) levels, the indicator's visualization settings can be customized to display only FVG mitigation lines. This approach leverages these lines as potential support and resistance zones, reflecting areas where price might revisit to address imbalances.
To configure this view:
Disable FVG Boxes: Turn off "Show FVG Boxes" (for LTF) or "Show Boxes" (for MTF/HTF) for the desired timeframes.
Hide Midlines: Disable the visibility of the 50% FVG Midlines (Equilibrium/EQ).
Ensure Mitigation Lines are Visible: Keep "Mitigation Lines" enabled.
Retain All Mitigation Lines:
Disable the "Hide Fully Mitigated FVGs" option in the general settings.
Enable the feature to "keep mitigation lines visible even after an FVG is fully mitigated". This ensures lines from all FVGs (active or fully mitigated) remain on the chart, which is only effective if "Hide Fully Mitigated FVGs" is disabled.
This setup offers:
A Decluttered Chart: Focuses solely on the FVG opening levels.
Precise S/R Zones: Treats mitigation lines as specific points for potential price reactions.
Historical Level Analysis: Includes lines from past, fully mitigated FVGs for a comprehensive view of significant price levels.
For enhanced usability with this focused view, consider these optional additions:
The on-chart Information Panel can be activated to display a quick summary of the nearest unmitigated FVG levels.
Mitigation Line Labels can also be activated for clear price level identification. A customizable horizontal bar offset is available for positioning these labels; for example, offsets of 4 for LTF, 8 for MTF, and 12 for HTF can be effective.
FVG Classification (Large FVG)
This feature allows for distinguishing FVGs based on their size relative to market volatility.
Enable Classification: Users can enable "Classify FVG (Large FVG)" to identify FVGs that are significantly larger than average.
ATR-Based Threshold: An FVG is classified as "Large" if its height (price range) is greater than or equal to the Average True Range (ATR) of its timeframe multiplied by a user-defined "Large FVG Threshold (ATR Multiple)". The ATR period for this calculation is also configurable.
Dedicated Colors: Large FVGs (both bullish/bearish and active/mitigated) can be assigned unique colors, making them easily distinguishable on the chart.
Panel Icon: Large FVGs are marked with a special icon in the Info Panel.
Information Panel
An on-chart panel provides a quick summary of the nearest unmitigated FVG levels.
Visibility and Position: The panel can be shown/hidden and positioned in any of the nine standard locations on the chart (e.g., Top Right, Middle Center).
Content: It displays the price levels of the nearest unmitigated bullish and bearish FVGs for LTF, MTF (if active), and HTF (if active). It also indicates if these nearest FVGs are Large FVGs (if classification is enabled) using a selectable icon.
Styling: Text size, border color, header background/text colors, default text color, and "N/A" cell background color are customizable.
Highlighting: Background and text colors for the cells displaying the overall nearest bullish and bearish FVG levels (across all active timeframes) can be customized to draw attention to the most proximate FVG.
Comprehensive Alert System
The indicator offers a granular alert system for various FVG-related events, configurable for each timeframe (LTF, MTF, HTF) independently. Users can enable alerts for:
New FVG Formation: Separate alerts for new bullish and new bearish FVG formations.
FVG Entry/Partial Fill: Separate alerts for price entering a bullish FVG or a bearish FVG.
FVG Full Mitigation: Separate alerts for full mitigation of bullish and bearish FVGs.
FVG Midline (EQ) Touch: Separate alerts for price touching the midline of a bullish or bearish FVG.
Alert messages are detailed, providing information such as the timeframe, FVG type (bull/bear, Large FVG), relevant price levels, and timestamps.
█ NOTES
This section provides additional information regarding the indicator's usage, performance considerations, and potential interactions with the TradingView platform. Understanding these points can help users optimize their experience and troubleshoot effectively.
Performance and Resource Management
Maximum FVGs to Track : The "Max FVGs to Track" input (defaulting to 25) limits the number of FVG objects processed for each category (e.g., LTF Bullish, MTF Bearish). Increasing this value significantly can impact performance due to more objects being iterated over and potentially drawn, especially when multiple timeframes are active.
Drawing Object Limits : To manage performance, this script sets its own internal limits on the number of drawing objects it displays. While it allows for up to approximately 500 lines (max_lines_count=500) and 500 labels (max_labels_count=500), the number of FVG boxes is deliberately restricted to a maximum of 150 (max_boxes_count=150). This specific limit for boxes is a key performance consideration: displaying too many boxes can significantly slow down the indicator, and a very high number is often not essential for analysis. Enabling all visual elements for many FVGs across all three timeframes can cause the indicator to reach these internal limits, especially the stricter box limit
Optimization Strategies : To help you manage performance, reduce visual clutter, and avoid exceeding drawing limits when using this indicator, I recommend the following strategies:
Maintain or Lower FVG Tracking Count: The "Max FVGs to Track" input defaults to 25. I find this value generally sufficient for effective analysis and balanced performance. You can keep this default or consider reducing it further if you experience performance issues or prefer a less dense FVG display.
Utilize Proximity Filtering: I suggest activating the "Filter Band Width (ATR Multiple)" option (found under "General Settings") to display only those FVGs closer to the current price. From my experience, a value of 5 for the ATR multiple often provides a good starting point for balanced performance, but you should feel free to adjust this based on market volatility and your specific trading needs.
Hide Fully Mitigated FVGs: I strongly recommend enabling the "Hide Fully Mitigated FVGs" option. This setting automatically removes all visual elements of an FVG from the chart once it has been fully mitigated by price. Doing so significantly reduces the number of active drawing objects, lessens computational load, and helps maintain chart clarity by focusing only on active, relevant FVGs.
Disable FVG Display for Unused Timeframes: If you are not actively monitoring certain higher timeframes (MTF or HTF) for FVG analysis, I advise disabling their display by unchecking "Show MTF FVGs" or "Show HTF FVGs" respectively. This can provide a significant performance boost.
Simplify Visual Elements: For active FVGs, consider hiding less critical visual elements if they are not essential for your specific analysis. This could include box labels, borders, or even entire FVG boxes if, for example, only the mitigation lines are of interest for a particular timeframe.
Settings Changes and Platform Limits : This indicator is comprehensive and involves numerous calculations and drawings. When multiple settings are changed rapidly in quick succession, it is possible, on occasion, for TradingView to issue a "Runtime error: modify_study_limit_exceeding" or similar. This can cause the indicator to temporarily stop updating or display errors.
Recommended Approach : When adjusting settings, it is advisable to wait a brief moment (a few seconds) after each significant change. This allows the indicator to reprocess and update on the chart before another change is made
Error Recovery : Should such a runtime error occur, making a minor, different adjustment in the settings (e.g., toggling a checkbox off and then on again) and waiting briefly will typically allow the indicator to recover and resume correct operation. This behavior is related to platform limitations when handling complex scripts with many inputs and drawing objects.
Multi-Timeframe (MTF/HTF) Data and Behavior
HTF FVG Confirmation is Essential: : For an FVG from a higher timeframe (MTF or HTF) to be identified and displayed on your current chart (LTF), the three-bar pattern forming the FVG on that higher timeframe must consist of fully closed bars. The indicator does not draw speculative FVGs based on incomplete/forming bars from higher timeframes.
Data Retrieval and LTF Processing: The indicator may use techniques like lookahead = barmerge.lookahead_on for timely data retrieval from higher timeframes. However, the actual detection of an FVG occurs after all its constituent bars on the HTF have closed.
Appearance Timing on LTF (1 LTF Candle Delay): As a natural consequence of this, an FVG that is confirmed on an HTF (i.e., its third bar closes) will typically become visible on your LTF chart one LTF bar after its confirmation on the HTF.
Example: Assume an FVG forms on a 30-minute chart at 15:30 (i.e., with the close of the 30-minute bar that covers the 15:00-15:30 period). If you are monitoring this FVG on a 15-minute chart, the indicator will detect this newly formed 30-minute FVG while processing the data for the 15-minute bar that starts at 15:30 and closes at 15:45. Therefore, the 30-minute FVG will become visible on your 15-minute chart at the earliest by 15:45 (i.e., with the close of that relevant 15-minute LTF candle). This means the HTF FVG is reflected on the LTF chart with a delay equivalent to one LTF candle.
FVG Detection and Display Logic
Fair Value Gaps (FVGs) on the current chart timeframe (LTF) are detected based on barstate.isconfirmed. This means the three-bar pattern must be complete with closed bars before an FVG is identified. This confirmation method prevents FVGs from being prematurely identified on the forming bar.
Alerts
Alert Setup : To receive alerts from this indicator, you must first ensure you have enabled the specific alert conditions you are interested in within the indicator's own settings (see 'Comprehensive Alert System' under the 'FEATURES' section). Once configured, open TradingView's 'Create Alert' dialog. In the 'Condition' tab, select this indicator's name, and crucially, choose the 'Any alert() function call' option from the dropdown list. This setup allows the indicator to trigger alerts based on the precise event conditions you have activated in its settings
Alert Frequency : Alerts are designed to trigger once per bar close (alert.freq_once_per_bar_close) for the specific event.
User Interface (UI) Tips
Settings Group Icons: In the indicator settings menu, timeframe-specific groups are marked with star icons for easier navigation: 🌟 for LTF (Current Chart Timeframe), 🌟🌟 for MTF (Medium Timeframe), and 🌟🌟🌟 for HTF (High Timeframe).
Dependent Inputs: Some input settings are dependent on others being enabled. These dependencies are visually indicated in the settings menu using symbols like "↳" (dependent setting on the next line), "⟷" (mutually exclusive inline options), or "➜" (directly dependent inline option).
Settings Layout Overview: The indicator settings are organized into logical groups for ease of use. Key global display controls – such as toggles for MTF FVGs, HTF FVGs (along with their respective timeframe selectors), and the Information Panel – are conveniently located at the very top within the '⚙️ General Settings' group. This placement allows for quick access to frequently adjusted settings. Other sections provide detailed customization options for each timeframe (LTF, MTF, HTF), specific FVG components, and alert configurations.
█ FOR Pine Script® CODERS
This section provides a high-level overview of the FVG Premium indicator's internal architecture, data flow, and the interaction between its various library components. It is intended for Pine Script™ programmers who wish to understand the indicator's design, potentially extend its functionality, or learn from its structure.
System Architecture and Modular Design
The indicator is architected moduarly, leveraging several custom libraries to separate concerns and enhance code organization and reusability. Each library has a distinct responsibility:
FvgTypes: Serves as the foundational data definition layer. It defines core User-Defined Types (UDTs) like fvgObject (for storing all attributes of an FVG) and drawSettings (for visual configurations), along with enumerations like tfType.
CommonUtils: Provides utility functions for common tasks like mapping user string inputs (e.g., "Dashed" for line style) to their corresponding Pine Script™ constants (e.g., line.style_dashed) and formatting timeframe strings for display.
FvgCalculations: Contains the core logic for FVG detection (both LTF and MTF/HTF via requestMultiTFBarData), FVG classification (Large FVGs based on ATR), and checking FVG interactions with price (mitigation, partial fill).
FvgObject: Implements an object-oriented approach by attaching methods to the fvgObject UDT. These methods manage the entire visual lifecycle of an FVG on the chart, including drawing, updating based on state changes (e.g., mitigation), and deleting drawing objects. It's responsible for applying the visual configurations defined in drawSettings.
FvgPanel: Manages the creation and dynamic updates of the on-chart information panel, which displays key FVG levels.
The main indicator script acts as the orchestrator, initializing these libraries, managing user inputs, processing data flow between libraries, and handling the main event loop (bar updates) for FVG state management and alerts.
Core Data Flow and FVG Lifecycle Management
The general data flow and FVG lifecycle can be summarized as follows:
Input Processing: User inputs from the "Settings" dialog are read by the main indicator script. Visual style inputs (colors, line styles, etc.) are consolidated into a types.drawSettings object (defined in FvgTypes). Other inputs (timeframes, filter settings, alert toggles) control the behavior of different modules. CommonUtils assists in mapping some string inputs to Pine constants.
FVG Detection:
For the current chart timeframe (LTF), FvgCalculations.detectFvg() identifies potential FVGs based on bar patterns.
For MTF/HTF, the main indicator script calls FvgCalculations.requestMultiTFBarData() to fetch necessary bar data from higher timeframes, then FvgCalculations.detectMultiTFFvg() identifies FVGs.
Newly detected FVGs are instantiated as types.fvgObject and stored in arrays within the main script. These objects also undergo classification (e.g., Large FVG) by FvgCalculations.
State Update & Interaction: On each bar, the main indicator script iterates through active FVG objects to manage their state based on price interaction:
Initially, the main script calls FvgCalculations.fvgInteractionCheck() to efficiently determine if the current bar's price might be interacting with a given FVG.
If a potential interaction is flagged, the main script then invokes methods directly on the fvgObject instance (e.g., updateMitigation(), updatePartialFill(), checkMidlineTouch(), which are part of FvgObject).
These fvgObject methods are responsible for the detailed condition checking and the actual modification of the FVG's state. For instance, the updateMitigation() and updatePartialFill() methods internally utilize specific helper functions from FvgCalculations (like checkMitigation() and checkPartialMitigation()) to confirm the precise nature of the interaction before updating the fvgObject’s state fields (such as isMitigated, currentTop, currentBottom, or isMidlineTouched).
Visual Rendering:
The FvgObject.updateDrawings() method is called for each fvgObject. This method is central to drawing management; it creates, updates, or deletes chart drawings (boxes, lines, labels) based on the FVG's current state, its prev_* (previous bar state) fields for optimization, and the visual settings passed via the drawSettings object.
Information Panel Update: The main indicator script determines the nearest FVG levels, populates a panelData object (defined in FvgPanelLib), and calls FvgPanel.updatePanel() to refresh the on-chart display.
Alert Generation: Based on the updated FVG states and user-enabled alert settings, the main indicator script constructs and triggers alerts using Pine Script's alert() function."
Key Design Considerations
UDT-Centric Design: The fvgObject UDT is pivotal, acting as a stateful container for all information related to a single FVG. Most operations revolve around creating, updating, or querying these objects.
State Management: To optimize drawing updates and manage FVG lifecycles, fvgObject instances store their previous bar's state (e.g., prevIsVisible, prevCurrentTop). The FvgObject.updateDrawings() method uses this to determine if a redraw is necessary, minimizing redundant drawing calls.
Settings Object: A drawSettings object is populated once (or when inputs change) and passed to drawing functions. This avoids repeatedly reading numerous input() values on every bar or within loops, improving performance.
Dynamic Arrays for FVG Storage: Arrays are used to store collections of fvgObject instances, allowing for dynamic management (adding new FVGs, iterating for updates).
Multi-Timeframe Continuity Custom Candle ConfirmationMulti-Timeframe Continuity Custom Candle Confirmation
Overview
The Timeframe Continuity Indicator is a versatile tool designed to help traders identify alignment between their current chart’s candlestick direction and higher timeframes of their choice. By coloring bars on the current chart (e.g., 1-minute) based on the directional alignment with selected higher timeframes (e.g., 10-minute, daily), this indicator provides a visual cue for confirming trends across multiple timeframes—a concept known as Timeframe Continuity. This approach is particularly useful for day traders, swing traders, and scalpers looking to ensure their trades align with broader market trends, reducing the risk of trading against the prevailing momentum.
Originality and Usefulness
This indicator is an original creation, built from scratch to address a common challenge in trading: ensuring that price action on a lower timeframe aligns with the trend on higher timeframes. Unlike many trend-following indicators that rely on moving averages, oscillators, or other lagging metrics, this script directly compares the bullish or bearish direction of candlesticks across timeframes. It introduces the following unique features:
Customizable Timeframes: Users can select from a range of higher timeframes (5m, 10m, 15m, 30m, 1h, 2h, 4h, 1d, 1w, 1M) to check for alignment, making it adaptable to various trading styles.
Neutral Candle Handling: The script accounts for neutral candles (where close == open) on the current timeframe by allowing them to inherit the direction of the higher timeframe, ensuring continuity in trend visualization.
Table: A table displays the direction of each selected timeframe and the current timeframe, helping identify direction in the event you don't want to color bars.
Toggles for Flexibility: Options to disable bar coloring and the debug table allow users to customize the indicator’s visual output for cleaner charts or focused analysis.
This indicator is not a mashup of existing scripts but a purpose-built tool to visualize timeframe alignment directly through candlestick direction, offering traders a straightforward way to confirm trend consistency.
What It Does
The Timeframe Continuity Indicator colors bars on your chart when the direction of the current timeframe’s candlestick (bullish, bearish, or neutral) aligns with the direction of the selected higher timeframes:
Lime: The current bar (e.g., 1m) is bullish or neutral, and all selected higher timeframes (e.g., 10m) are bullish.
Pink: The current bar is bearish or neutral, and all selected higher timeframes are bearish.
Default Color: If the directions don’t align (e.g., 1m bar is bearish but 10m is bullish), the bar remains the default chart color.
The indicator also includes a debug table (toggleable) that shows the direction of each selected timeframe and the current timeframe, helping traders diagnose alignment issues.
How It Works
The script uses the following methodology:
1. Direction Calculation: For each timeframe (current and selected higher timeframes), the script determines the candlestick’s direction:
Bullish (1): close > open / Bearish (-1): close < open / Neutral (0): close == open
Higher timeframe directions are fetched using Pine Script’s request.security function, ensuring accurate data retrieval.
2. Alignment Check: The script checks if all selected higher timeframes are uniformly bullish (full_bullish) or bearish (full_bearish).
o A higher timeframe must have a clear direction (bullish or bearish) to trigger coloring. If any selected timeframe is neutral, alignment fails, and no coloring occurs.
3. Coloring Logic: The current bar is colored only if its direction aligns with the higher timeframes:
Lime if the higher timeframes are bullish and the current bar is bullish or neutral.
Maroon if the higher timeframes are bearish and the current bar is bearish or neutral.
If the current bar’s direction opposes the higher timeframe (e.g., 1m bearish, 10m bullish), the bar remains uncolored.
Users can disable bar coloring entirely via the settings, leaving bars in their default chart color.
4. Direction Table:
A table in the top-right corner (toggleable) displays the direction of each selected timeframe and the current timeframe, using color-coded labels (green for bullish, red for bearish, gray for neutral).
This feature helps traders understand why a bar is or isn’t colored, making the indicator accessible to users unfamiliar with Pine Script.
How to Use
1. Add the Indicator: Add the "Timeframe Continuity Indicator" to your chart in TradingView (e.g., a 1m chart of SPY).
2. Configure Settings:
Timeframe Selection: Check the boxes for the higher timeframes you want to compare against (default: 10m). Options include 5m, 10m, 15m, 30m, 1h, 2h, 4h, 1D, 1W, and 1M. Select multiple timeframes if you want to ensure alignment across all of them (e.g., 10m and 1d).
Enable Bar Coloring: Default: true (bars are colored lime or maroon when aligned). Set to false to disable coloring and keep the default chart colors.
Show Table: Default: true (table is displayed in the top-right corner). Set to false to hide the table for a cleaner chart.
3. Interpret the Output:
Colored Bars: Lime bars indicate the current bar (e.g., 1m) is bullish or neutral, and all selected higher timeframes are bullish. Maroon bars indicate the current bar is bearish or neutral, and all selected higher timeframes are bearish. Uncolored bars (default chart color) indicate a mismatch (e.g., 1m bar is bearish while 10m is bullish) or no coloring if disabled.
Direction Table: Check the table to see the direction of each selected timeframe and the current timeframe.
4. Example Use Case:
On a 1m chart of SPY, select the 10m timeframe.
If the 10m timeframe is bearish, 1m bars that are bearish or neutral will color maroon, confirming you’re trading with the higher timeframe’s trend.
If a 1m bar is bullish while the 10m is bearish, it remains uncolored, signaling a potential misalignment to avoid trading.
Underlying Concepts
The indicator is based on the concept of Timeframe Continuity, a strategy used by traders to ensure that price action on a lower timeframe aligns with the trend on higher timeframes. This reduces the risk of entering trades against the broader market direction. The script directly compares candlestick directions (bullish, bearish, or neutral) rather than relying on lagging indicators like moving averages or RSI, providing a real-time, price-action-based confirmation of trend alignment. The handling of neutral candles ensures that minor indecision on the lower timeframe doesn’t interrupt the visualization of the higher timeframe’s trend.
Why This Indicator?
Simplicity: Directly compares candlestick directions, avoiding complex calculations or lagging indicators.
Flexibility: Customizable timeframes and toggles cater to various trading strategies.
Transparency: The debug table makes the indicator’s logic accessible to all users, not just those who can read Pine Script.
Practicality: Helps traders confirm trend alignment, a key factor in successful trading across timeframes.
ADR Nivele Horizontale dhe EMAThe user provided a Pine Script code for an indicator called "ADR Nivele Horizontale dhe EMA". The task is to explain how this code works. Hmm, first, I need to understand what this indicator does. The title mentions ADR levels and EMA, so it's probably combining horizontal lines based on Average Daily Range and some Exponential Moving Averages.
Looking at the code, the first part is the indicator declaration with version 6. The settings include an ADR period, levels above and below the mid, and line style. Then there's a section for calculations. They request daily high and low to compute the daily range. The ADR is the SMA of the daily range over the specified period. The mid is the average of daily high and low. The adr_val is half of ADR, maybe to create symmetrical levels around the mid.
Next, they create arrays for lines and labels above and below the mid. The loops go from 1 to levels_above/below, calculate each level, draw lines and labels. The mid line is also drawn with a different color. Then, there are several EMAs plotted: 13, 50, 200, 400, 600, 800, each with different colorsWait, but in Pine Script, when you use arrays to store lines and labels, you have to manage them properly to avoid repainting or memory issues. The code uses array.concat to add new lines and labels each bar. However, since this code is running on each bar, the for loops might be creating multiple lines each time, leading to too many objects. Oh right, but they use var to initialize the arrays, so they are only initialized once. Wait, no. The var keyword initializes the variable once, but in each iteration, they are concatenating new lines. Wait, no: the for loops are inside the main script, which runs on each bar. So every time a new bar is processed, the loops will run again, adding new lines and labels. That's a problem because each bar would create new lines, leading to an ever-increasing number of lines, which could hit the maximum limit (max_lines_count is set to 20, but maybe they have more bars). Oh, the indicator has max_lines_count=20, but the code might be creating multiple lines per bar. So maybe the code isn't handling the line management correctly. For example, if levels_above is 2, then each bar would create 2 new lines above and 2 below, plus the mid line. Over 20 bars, that's way over 20 lines. So this could cause the indicator to stop drawing after 20 lines. The user might not have realized that the lines are being recreated every bar, leading to a buildup. But perhaps the original code intended to have the lines update each bar, extending to the current bar. Let's see: in line.new, they use bar_index as the starting x1 and bar_index as x2. So each line is drawn from the previous bar's index to the current one. But since this is done on every bar, each line is only one bar long. Wait, no. Because on each new bar, the code creates a new line from the previous bar's index (bar_index , which is now the bar before the current one) to the current bar_index. So each line is just a segment from the previous bar to the current bar. But when the next bar comes, a new line is created again. So the result is that each level line is a series of one-bar-length segments, which might not be intended. The user probably wants continuous lines that extend from the left to the right, not just per bar. So this approach is incorrect. The correct way would be to have a line that starts at the first bar of the calculation and extends to the right, updating each bar. But the current code creates a new line each bar, leading to multiple short lines instead of one continuous line. That's a mistake.
So the main issue here is that the code is generating a new line segment for each bar, which is not efficient and would quickly hit the line limit. To fix this, instead of creating a new line every bar, they should create the line once and then update its position each bar. But in Pine Script, you can't directly update a line after it's created; instead, you need to track the line ID and use line.set_xy() to extend it. However, the current code uses array.concat to add new lines each bar, which isn't the right approach.
Therefore, the code as written will create multiple short lines instead of continuous horizontal lines. The correct approach for horizontal levels that extend to the right is to create the line once, starting at a certain bar and extending indefinitely, or to update the line's end point each new bar. But in Pine Script, you can't extend lines infinitely; you have to manage them each bar. Alternatively, using the 'line.extend' style might help, but I think the original code's logic is flawed here.
Additionally, the EMA part is straightforward: plotting multiple EMAs with different periods. That part should work as expected.
So the explanation should mention that the ADR levels are calculated based on the daily high and low, then the code attempts to draw horizontal lines above and below the mid-point. However, the way the lines are drawn may lead to multiple short segments instead of continuous lines, potentially causing performance issues or hitting the maximum line count. The EMAs are plotted correctly with various periods..
waves█ OVERVIEW
This library intended for use in Bar Replay provides functions to generate various wave forms (sine, cosine, triangle, square) based on time and customizable parameters. Useful for testing and in creating oscillators, indicators, or visual effects.
█ FUNCTIONS
• getSineWave()
• getCosineWave()
• getTriangleWave()
• getSquareWave()
█ USAGE EXAMPLE
//@version=6
indicator("Wave Example")
import kaigouthro/waves/1
plot(waves.getSineWave(cyclesPerMinute=15))
█ NOTES
* barsPerSecond defaults to 10. Adjust this if not using 10x in Bar Replay.
* Phase shift is in degrees.
---
Library "waves"
getSineWave(cyclesPerMinute, bar, barsPerSecond, amplitude, verticalShift, phaseShift)
`getSineWave`
> Calculates a sine wave based on bar index, cycles per minute (BPM), and wave parameters.
Parameters:
cyclesPerMinute (float) : (float) The desired number of cycles per minute (BPM). Default is 30.0.
bar (int) : (int) The current bar index. Default is bar_index.
barsPerSecond (float) : (float) The number of bars per second. Default is 10.0 for Bar Replay
amplitude (float) : (float) The amplitude of the sine wave. Default is 1.0.
verticalShift (float) : (float) The vertical shift of the sine wave. Default is 0.0.
phaseShift (float) : (float) The phase shift of the sine wave in radians. Default is 0.0.
Returns: (float) The calculated sine wave value.
getCosineWave(cyclesPerMinute, bar, barsPerSecond, amplitude, verticalShift, phaseShift)
`getCosineWave`
> Calculates a cosine wave based on bar index, cycles per minute (BPM), and wave parameters.
Parameters:
cyclesPerMinute (float) : (float) The desired number of cycles per minute (BPM). Default is 30.0.
bar (int) : (int) The current bar index. Default is bar_index.
barsPerSecond (float) : (float) The number of bars per second. Default is 10.0 for Bar Replay
amplitude (float) : (float) The amplitude of the cosine wave. Default is 1.0.
verticalShift (float) : (float) The vertical shift of the cosine wave. Default is 0.0.
phaseShift (float) : (float) The phase shift of the cosine wave in radians. Default is 0.0.
Returns: (float) The calculated cosine wave value.
getTriangleWave(cyclesPerMinute, bar, barsPerSecond, amplitude, verticalShift, phaseShift)
`getTriangleWave`
> Calculates a triangle wave based on bar index, cycles per minute (BPM), and wave parameters.
Parameters:
cyclesPerMinute (float) : (float) The desired number of cycles per minute (BPM). Default is 30.0.
bar (int) : (int) The current bar index. Default is bar_index.
barsPerSecond (float) : (float) The number of bars per second. Default is 10.0 for Bar Replay
amplitude (float) : (float) The amplitude of the triangle wave. Default is 1.0.
verticalShift (float) : (float) The vertical shift of the triangle wave. Default is 0.0.
phaseShift (float) : (float) The phase shift of the triangle wave in radians. Default is 0.0.
Returns: (float) The calculated triangle wave value.
getSquareWave(cyclesPerMinute, bar, barsPerSecond, amplitude, verticalShift, dutyCycle, phaseShift)
`getSquareWave`
> Calculates a square wave based on bar index, cycles per minute (BPM), and wave parameters.
Parameters:
cyclesPerMinute (float) : (float) The desired number of cycles per minute (BPM). Default is 30.0.
bar (int) : (int) The current bar index. Default is bar_index.
barsPerSecond (float) : (float) The number of bars per second. Default is 10.0 for Bar Replay
amplitude (float) : (float) The amplitude of the square wave. Default is 1.0.
verticalShift (float) : (float) The vertical shift of the square wave. Default is 0.0.
dutyCycle (float) : (float) The duty cycle of the square wave (0.0 to 1.0). Default is 0.5 (50% duty cycle).
phaseShift (float) : (float) The phase shift of the square wave in radians. Default is 0.0.
Returns: (float) The calculated square wave value.
