DAX/CAC40 SpreadOne more spread. You can change symbol by click on the input symbol window, and use anyone you like
在脚本中搜索"one一季度财报"
USDCAD/WTI SpreadOne more spread , this is USDCAD/WTI . Is the change of the moment of this 2 security.
One White Soldier StudyThis shows a green indicator on this study (17Jun & 15Aug on TRN) when a bullish candle opens and closes above the prior day's bearish candle, ignoring gap ups. This will only show in the DAILY chart, not intraday.
Ehlers Simple Cycle Indicator [LazyBear]One of the early cycle indicators from John Ehlers.
Ehlers suggests using this with ITrend (see linked PDF below). Osc/signal crosses identify entry/exit points.
Options page has the usual set of configurable params.
More info:
- Simple Cycle Indicator: www.mesasoftware.com
List of my public indicators: bit.ly
List of my app-store indicators: blog.tradingview.com
Ehlers Instantaneous Trend [LazyBear]One more to add to the Ehlers collection.
Ehlers Instantaneous Trendline, by John Ehlers, identifies the market trend by doing removing cycle component. I think, this simplicity is what makes it attractive :) To understand Ehlers's thought process behind this, refer to the PDF linked below.
There are atleast 6 variations of this ITrend. This version is from his early presentations.
Is this better than a simple HMA? May be, May be not. I will leave it to you to decide :)
I have added options to show this as a ribbon, and to color bars based on ITrend. Check out the options page.
More info:
- ITrend: www.mesasoftware.com
List of my public indicators: bit.ly
List of my app-store indicators: blog.tradingview.com
Renko BandsThis is renko without the candles, just the endpoint plotted as a line with bands around it that represent the brick size. The idea came from thinking about what renko actually gives you once you strip away the visual brick format. At its core, renko is a filtered price series that only updates when price moves a fixed amount, which means it's inherently a trend-following mechanism with built-in noise reduction. By plotting just the renko price level and surrounding it with bands at the brick threshold distances, you get something that works like regular volatility bands while still behaving as a trend indicator.
The center line is the current renko price, which trails actual price based on whichever brick sizing method you've selected. When price moves enough to complete a brick in the renko calculation, the center line jumps to the new brick level. The bands sit at plus and minus one brick size from that center line, showing you exactly how far price needs to move before the next brick would form. This makes the bands function as dynamic breakout levels. When price touches or crosses a band, you know a new renko brick is forming and the trend calculation is updating.
What makes this cool is the dual-purpose nature. You can use it like traditional volatility bands where the outer edges represent boundaries of normal price movement, and breaks beyond those boundaries signal potential trend continuation or exhaustion. But because the underlying calculation is renko rather than standard deviation or ATR around a moving average, the bands also give you direct insight into trend state. When the center line is rising consistently and price stays near the upper band, you're in a clean uptrend. When it's falling and price hugs the lower band, downtrend. When the center line is flat and price is bouncing between both bands, you're ranging.
The three brick sizing methods work the same way as standard renko implementations. Traditional sizing uses a fixed price range, so your bands are always the same absolute distance from the center line. ATR-based sizing calculates brick range from historical volatility, which makes the bands expand and contract based on the ATR measurement you chose at startup. Percentage-based sizing scales the brick size with price level, so the bands naturally widen as price increases and narrow as it decreases. This automatic scaling is particularly useful for instruments that move proportionally rather than in fixed increments.
The visual simplicity compared to full renko bricks makes this more practical for overlay use on your main chart. Instead of trying to read brick patterns in a separate pane or cluttering your price chart with boxes and lines, you get a single smoothed line with two bands that convey the same information about trend state and momentum. The center line shows you the filtered trend direction, the bands show you the threshold levels, and the relationship between price and the bands tells you whether the current move has legs or is stalling out.
From a trend-following perspective, the renko line naturally stays flat during consolidation and only moves when directional momentum is strong enough to complete bricks. This built-in filter removes a lot of the whipsaw that affects moving averages during choppy periods. Traditional moving averages continue updating with every bar regardless of whether meaningful directional movement is happening, which leads to false signals when price is just oscillating. The renko line only responds to sustained moves that meet the brick size threshold, so it tends to stay quiet when price is going nowhere and only signals when something is actually happening.
The bands also serve as natural stop-loss or profit-target references since they represent the distance price needs to move before the trend calculation changes. If you're long and the renko line is rising, you might place stops below the lower band on the theory that if price falls far enough to reverse the renko trend, your thesis is probably invalidated. Conversely, the upper band can mark levels where you'd expect the current brick to complete and potentially see some consolidation or pullback before the next brick forms.
What this really highlights is that renko's value isn't just in the brick visualization, it's in the underlying filtering mechanism. By extracting that mechanism and presenting it in a more traditional band format, you get access to renko's trend-following properties without needing to commit to the brick chart aesthetic or deal with the complications of overlaying brick drawings on a time-based chart. It's renko after all, so you get the trend filtering and directional clarity that makes renko useful, but packaged in a way that integrates more naturally with standard technical analysis workflows.
10Y–2Y Treasury Yield Curve Spread & MES % Change📝 Description:
This indicator tracks the U.S. 10-Year minus 2-Year Treasury yield spread — a powerful macroeconomic signal often used by professional traders to gauge market sentiment and recession risk — and overlays an optional MES % change line to help intraday futures traders spot macro–price divergences in real time.
Features:
🏦 Plots the 10Y–2Y spread, with optional EMA smoothing.
📉 Highlights yield curve inversion (background turns red when spread < 0).
📊 Optional MES % change line from daily or RTH open for directional bias.
🔔 Alert conditions for:
Yield curve inversion / un-inversion.
Sudden spread spikes in basis points (customizable).
🧮 Optional correlation plot to visualize relationship strength between MES and the yield curve.
🧭 Z-score normalization allows both series to be viewed in one pane without scaling issues.
Why it matters:
A falling or inverted 2s10s spread often signals risk-off behavior and pressure on equities.
A steepening curve tends to support risk-on rallies.
Divergences between MES price action and the spread can provide early warning signals of reversals or fakeouts.
Best used with:
MES (MES1!) or MYM charts for intraday & swing bias.
Fed event days, CPI/NFP, or any macro-sensitive sessions.
VWAP or structure-based intraday trading strategies.
⚠️ Note: This indicator is for informational purposes only and does not constitute financial advice. Always combine macro context with your own trade plan and risk management.
ValueAtTime█ OVERVIEW
This library is a Pine Script® programming tool for accessing historical values in a time series using UNIX timestamps . Its data structure and functions index values by time, allowing scripts to retrieve past values based on absolute timestamps or relative time offsets instead of relying on bar index offsets.
█ CONCEPTS
UNIX timestamps
In Pine Script®, a UNIX timestamp is an integer representing the number of milliseconds elapsed since January 1, 1970, at 00:00:00 UTC (the UNIX Epoch ). The timestamp is a unique, absolute representation of a specific point in time. Unlike a calendar date and time, a UNIX timestamp's meaning does not change relative to any time zone .
This library's functions process series values and corresponding UNIX timestamps in pairs , offering a simplified way to identify values that occur at or near distinct points in time instead of on specific bars.
Storing and retrieving time-value pairs
This library's `Data` type defines the structure for collecting time and value information in pairs. Objects of the `Data` type contain the following two fields:
• `times` – An array of "int" UNIX timestamps for each recorded value.
• `values` – An array of "float" values for each saved timestamp.
Each index in both arrays refers to a specific time-value pair. For instance, the `times` and `values` elements at index 0 represent the first saved timestamp and corresponding value. The library functions that maintain `Data` objects queue up to one time-value pair per bar into the object's arrays, where the saved timestamp represents the bar's opening time .
Because the `times` array contains a distinct UNIX timestamp for each item in the `values` array, it serves as a custom mapping for retrieving saved values. All the library functions that return information from a `Data` object use this simple two-step process to identify a value based on time:
1. Perform a binary search on the `times` array to find the earliest saved timestamp closest to the specified time or offset and get the element's index.
2. Access the element from the `values` array at the retrieved index, returning the stored value corresponding to the found timestamp.
Value search methods
There are several techniques programmers can use to identify historical values from corresponding timestamps. This library's functions include three different search methods to locate and retrieve values based on absolute times or relative time offsets:
Timestamp search
Find the value with the earliest saved timestamp closest to a specified timestamp.
Millisecond offset search
Find the value with the earliest saved timestamp closest to a specified number of milliseconds behind the current bar's opening time. This search method provides a time-based alternative to retrieving historical values at specific bar offsets.
Period offset search
Locate the value with the earliest saved timestamp closest to a defined period offset behind the current bar's opening time. The function calculates the span of the offset based on a period string . The "string" must contain one of the following unit tokens:
• "D" for days
• "W" for weeks
• "M" for months
• "Y" for years
• "YTD" for year-to-date, meaning the time elapsed since the beginning of the bar's opening year in the exchange time zone.
The period string can include a multiplier prefix for all supported units except "YTD" (e.g., "2W" for two weeks).
Note that the precise span covered by the "M", "Y", and "YTD" units varies across time. The "1M" period can cover 28, 29, 30, or 31 days, depending on the bar's opening month and year in the exchange time zone. The "1Y" period covers 365 or 366 days, depending on leap years. The "YTD" period's span changes with each new bar, because it always measures the time from the start of the current bar's opening year.
█ CALCULATIONS AND USE
This library's functions offer a flexible, structured approach to retrieving historical values at or near specific timestamps, millisecond offsets, or period offsets for different analytical needs.
See below for explanations of the exported functions and how to use them.
Retrieving single values
The library includes three functions that retrieve a single stored value using timestamp, millisecond offset, or period offset search methods:
• `valueAtTime()` – Locates the saved value with the earliest timestamp closest to a specified timestamp.
• `valueAtTimeOffset()` – Finds the saved value with the earliest timestamp closest to the specified number of milliseconds behind the current bar's opening time.
• `valueAtPeriodOffset()` – Finds the saved value with the earliest timestamp closest to the period-based offset behind the current bar's opening time.
Each function has two overloads for advanced and simple use cases. The first overload searches for a value in a user-specified `Data` object created by the `collectData()` function (see below). It returns a tuple containing the found value and the corresponding timestamp.
The second overload maintains a `Data` object internally to store and retrieve values for a specified `source` series. This overload returns a tuple containing the historical `source` value, the corresponding timestamp, and the current bar's `source` value, making it helpful for comparing past and present values from requested contexts.
Retrieving multiple values
The library includes the following functions to retrieve values from multiple historical points in time, facilitating calculations and comparisons with values retrieved across several intervals:
• `getDataAtTimes()` – Locates a past `source` value for each item in a `timestamps` array. Each retrieved value's timestamp represents the earliest time closest to one of the specified timestamps.
• `getDataAtTimeOffsets()` – Finds a past `source` value for each item in a `timeOffsets` array. Each retrieved value's timestamp represents the earliest time closest to one of the specified millisecond offsets behind the current bar's opening time.
• `getDataAtPeriodOffsets()` – Finds a past value for each item in a `periods` array. Each retrieved value's timestamp represents the earliest time closest to one of the specified period offsets behind the current bar's opening time.
Each function returns a tuple with arrays containing the found `source` values and their corresponding timestamps. In addition, the tuple includes the current `source` value and the symbol's description, which also makes these functions helpful for multi-interval comparisons using data from requested contexts.
Processing period inputs
When writing scripts that retrieve historical values based on several user-specified period offsets, the most concise approach is to create a single text input that allows users to list each period, then process the "string" list into an array for use in the `getDataAtPeriodOffsets()` function.
This library includes a `getArrayFromString()` function to provide a simple way to process strings containing comma-separated lists of periods. The function splits the specified `str` by its commas and returns an array containing every non-empty item in the list with surrounding whitespaces removed. View the example code to see how we use this function to process the value of a text area input .
Calculating period offset times
Because the exact amount of time covered by a specified period offset can vary, it is often helpful to verify the resulting times when using the `valueAtPeriodOffset()` or `getDataAtPeriodOffsets()` functions to ensure the calculations work as intended for your use case.
The library's `periodToTimestamp()` function calculates an offset timestamp from a given period and reference time. With this function, programmers can verify the time offsets in a period-based data search and use the calculated offset times in additional operations.
For periods with "D" or "W" units, the function calculates the time offset based on the absolute number of milliseconds the period covers (e.g., `86400000` for "1D"). For periods with "M", "Y", or "YTD" units, the function calculates an offset time based on the reference time's calendar date in the exchange time zone.
Collecting data
All the `getDataAt*()` functions, and the second overloads of the `valueAt*()` functions, collect and maintain data internally, meaning scripts do not require a separate `Data` object when using them. However, the first overloads of the `valueAt*()` functions do not collect data, because they retrieve values from a user-specified `Data` object.
For cases where a script requires a separate `Data` object for use with these overloads or other custom routines, this library exports the `collectData()` function. This function queues each bar's `source` value and opening timestamp into a `Data` object and returns the object's ID.
This function is particularly useful when searching for values from a specific series more than once. For instance, instead of using multiple calls to the second overloads of `valueAt*()` functions with the same `source` argument, programmers can call `collectData()` to store each bar's `source` and opening timestamp, then use the returned `Data` object's ID in calls to the first `valueAt*()` overloads to reduce memory usage.
The `collectData()` function and all the functions that collect data internally include two optional parameters for limiting the saved time-value pairs to a sliding window: `timeOffsetLimit` and `timeframeLimit`. When either has a non-na argument, the function restricts the collected data to the maximum number of recent bars covered by the specified millisecond- and timeframe-based intervals.
NOTE : All calls to the functions that collect data for a `source` series can execute up to once per bar or realtime tick, because each stored value requires a unique corresponding timestamp. Therefore, scripts cannot call these functions iteratively within a loop . If a call to these functions executes more than once inside a loop's scope, it causes a runtime error.
█ EXAMPLE CODE
The example code at the end of the script demonstrates one possible use case for this library's functions. The code retrieves historical price data at user-specified period offsets, calculates price returns for each period from the retrieved data, and then populates a table with the results.
The example code's process is as follows:
1. Input a list of periods – The user specifies a comma-separated list of period strings in the script's "Period list" input (e.g., "1W, 1M, 3M, 1Y, YTD"). Each item in the input list represents a period offset from the latest bar's opening time.
2. Process the period list – The example calls `getArrayFromString()` on the first bar to split the input list by its commas and construct an array of period strings.
3. Request historical data – The code uses a call to `getDataAtPeriodOffsets()` as the `expression` argument in a request.security() call to retrieve the closing prices of "1D" bars for each period included in the processed `periods` array.
4. Display information in a table – On the latest bar, the code uses the retrieved data to calculate price returns over each specified period, then populates a two-row table with the results. The cells for each return percentage are color-coded based on the magnitude and direction of the price change. The cells also include tooltips showing the compared daily bar's opening date in the exchange time zone.
█ NOTES
• This library's architecture relies on a user-defined type (UDT) for its data storage format. UDTs are blueprints from which scripts create objects , i.e., composite structures with fields containing independent values or references of any supported type.
• The library functions search through a `Data` object's `times` array using the array.binary_search_leftmost() function, which is more efficient than looping through collected data to identify matching timestamps. Note that this built-in works only for arrays with elements sorted in ascending order .
• Each function that collects data from a `source` series updates the values and times stored in a local `Data` object's arrays. If a single call to these functions were to execute in a loop , it would store multiple values with an identical timestamp, which can cause erroneous search behavior. To prevent looped calls to these functions, the library uses the `checkCall()` helper function in their scopes. This function maintains a counter that increases by one each time it executes on a confirmed bar. If the count exceeds the total number of bars, indicating the call executes more than once in a loop, it raises a runtime error .
• Typically, when requesting higher-timeframe data with request.security() while using barmerge.lookahead_on as the `lookahead` argument, the `expression` argument should be offset with the history-referencing operator to prevent lookahead bias on historical bars. However, the call in this script's example code enables lookahead without offsetting the `expression` because the script displays results only on the last historical bar and all realtime bars, where there is no future data to leak into the past. This call ensures the displayed results use the latest data available from the context on realtime bars.
Look first. Then leap.
█ EXPORTED TYPES
Data
A structure for storing successive timestamps and corresponding values from a dataset.
Fields:
times (array) : An "int" array containing a UNIX timestamp for each value in the `values` array.
values (array) : A "float" array containing values corresponding to the timestamps in the `times` array.
█ EXPORTED FUNCTIONS
getArrayFromString(str)
Splits a "string" into an array of substrings using the comma (`,`) as the delimiter. The function trims surrounding whitespace characters from each substring, and it excludes empty substrings from the result.
Parameters:
str (series string) : The "string" to split into an array based on its commas.
Returns: (array) An array of trimmed substrings from the specified `str`.
periodToTimestamp(period, referenceTime)
Calculates a UNIX timestamp representing the point offset behind a reference time by the amount of time within the specified `period`.
Parameters:
period (series string) : The period string, which determines the time offset of the returned timestamp. The specified argument must contain a unit and an optional multiplier (e.g., "1Y", "3M", "2W", "YTD"). Supported units are:
- "Y" for years.
- "M" for months.
- "W" for weeks.
- "D" for days.
- "YTD" (Year-to-date) for the span from the start of the `referenceTime` value's year in the exchange time zone. An argument with this unit cannot contain a multiplier.
referenceTime (series int) : The millisecond UNIX timestamp from which to calculate the offset time.
Returns: (int) A millisecond UNIX timestamp representing the offset time point behind the `referenceTime`.
collectData(source, timeOffsetLimit, timeframeLimit)
Collects `source` and `time` data successively across bars. The function stores the information within a `Data` object for use in other exported functions/methods, such as `valueAtTimeOffset()` and `valueAtPeriodOffset()`. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
source (series float) : The source series to collect. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: (Data) A `Data` object containing collected `source` values and corresponding timestamps over the allowed time range.
method valueAtTime(data, timestamp)
(Overload 1 of 2) Retrieves value and time data from a `Data` object's fields at the index of the earliest timestamp closest to the specified `timestamp`. Callable as a method or a function.
Parameters:
data (series Data) : The `Data` object containing the collected time and value data.
timestamp (series int) : The millisecond UNIX timestamp to search. The function returns data for the earliest saved timestamp that is closest to the value.
Returns: ( ) A tuple containing the following data from the `Data` object:
- The stored value corresponding to the identified timestamp ("float").
- The earliest saved timestamp that is closest to the specified `timestamp` ("int").
valueAtTime(source, timestamp, timeOffsetLimit, timeframeLimit)
(Overload 2 of 2) Retrieves `source` and time information for the earliest bar whose opening timestamp is closest to the specified `timestamp`. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
source (series float) : The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timestamp (series int) : The millisecond UNIX timestamp to search. The function returns data for the earliest bar whose timestamp is closest to the value.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : (simple string) Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple containing the following data:
- The `source` value corresponding to the identified timestamp ("float").
- The earliest bar's timestamp that is closest to the specified `timestamp` ("int").
- The current bar's `source` value ("float").
method valueAtTimeOffset(data, timeOffset)
(Overload 1 of 2) Retrieves value and time data from a `Data` object's fields at the index of the earliest saved timestamp closest to `timeOffset` milliseconds behind the current bar's opening time. Callable as a method or a function.
Parameters:
data (series Data) : The `Data` object containing the collected time and value data.
timeOffset (series int) : The millisecond offset behind the bar's opening time. The function returns data for the earliest saved timestamp that is closest to the calculated offset time.
Returns: ( ) A tuple containing the following data from the `Data` object:
- The stored value corresponding to the identified timestamp ("float").
- The earliest saved timestamp that is closest to `timeOffset` milliseconds before the current bar's opening time ("int").
valueAtTimeOffset(source, timeOffset, timeOffsetLimit, timeframeLimit)
(Overload 2 of 2) Retrieves `source` and time information for the earliest bar whose opening timestamp is closest to `timeOffset` milliseconds behind the current bar's opening time. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
source (series float) : The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timeOffset (series int) : The millisecond offset behind the bar's opening time. The function returns data for the earliest bar's timestamp that is closest to the calculated offset time.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple containing the following data:
- The `source` value corresponding to the identified timestamp ("float").
- The earliest bar's timestamp that is closest to `timeOffset` milliseconds before the current bar's opening time ("int").
- The current bar's `source` value ("float").
method valueAtPeriodOffset(data, period)
(Overload 1 of 2) Retrieves value and time data from a `Data` object's fields at the index of the earliest timestamp closest to a calculated offset behind the current bar's opening time. The calculated offset represents the amount of time covered by the specified `period`. Callable as a method or a function.
Parameters:
data (series Data) : The `Data` object containing the collected time and value data.
period (series string) : The period string, which determines the calculated time offset. The specified argument must contain a unit and an optional multiplier (e.g., "1Y", "3M", "2W", "YTD"). Supported units are:
- "Y" for years.
- "M" for months.
- "W" for weeks.
- "D" for days.
- "YTD" (Year-to-date) for the span from the start of the current bar's year in the exchange time zone. An argument with this unit cannot contain a multiplier.
Returns: ( ) A tuple containing the following data from the `Data` object:
- The stored value corresponding to the identified timestamp ("float").
- The earliest saved timestamp that is closest to the calculated offset behind the bar's opening time ("int").
valueAtPeriodOffset(source, period, timeOffsetLimit, timeframeLimit)
(Overload 2 of 2) Retrieves `source` and time information for the earliest bar whose opening timestamp is closest to a calculated offset behind the current bar's opening time. The calculated offset represents the amount of time covered by the specified `period`. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
source (series float) : The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
period (series string) : The period string, which determines the calculated time offset. The specified argument must contain a unit and an optional multiplier (e.g., "1Y", "3M", "2W", "YTD"). Supported units are:
- "Y" for years.
- "M" for months.
- "W" for weeks.
- "D" for days.
- "YTD" (Year-to-date) for the span from the start of the current bar's year in the exchange time zone. An argument with this unit cannot contain a multiplier.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple containing the following data:
- The `source` value corresponding to the identified timestamp ("float").
- The earliest bar's timestamp that is closest to the calculated offset behind the current bar's opening time ("int").
- The current bar's `source` value ("float").
getDataAtTimes(timestamps, source, timeOffsetLimit, timeframeLimit)
Retrieves `source` and time information for each bar whose opening timestamp is the earliest one closest to one of the UNIX timestamps specified in the `timestamps` array. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
timestamps (array) : An array of "int" values representing UNIX timestamps. The function retrieves `source` and time data for each element in this array.
source (series float) : The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple of the following data:
- An array containing a `source` value for each identified timestamp (array).
- An array containing an identified timestamp for each item in the `timestamps` array (array).
- The current bar's `source` value ("float").
- The symbol's description from `syminfo.description` ("string").
getDataAtTimeOffsets(timeOffsets, source, timeOffsetLimit, timeframeLimit)
Retrieves `source` and time information for each bar whose opening timestamp is the earliest one closest to one of the time offsets specified in the `timeOffsets` array. Each offset in the array represents the absolute number of milliseconds behind the current bar's opening time. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
timeOffsets (array) : An array of "int" values representing the millisecond time offsets used in the search. The function retrieves `source` and time data for each element in this array. For example, the array ` ` specifies that the function returns data for the timestamps closest to one day and one week behind the current bar's opening time.
source (float) : (series float) The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple of the following data:
- An array containing a `source` value for each identified timestamp (array).
- An array containing an identified timestamp for each offset specified in the `timeOffsets` array (array).
- The current bar's `source` value ("float").
- The symbol's description from `syminfo.description` ("string").
getDataAtPeriodOffsets(periods, source, timeOffsetLimit, timeframeLimit)
Retrieves `source` and time information for each bar whose opening timestamp is the earliest one closest to a calculated offset behind the current bar's opening time. Each calculated offset represents the amount of time covered by a period specified in the `periods` array. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
periods (array) : An array of period strings, which determines the time offsets used in the search. The function retrieves `source` and time data for each element in this array. For example, the array ` ` specifies that the function returns data for the timestamps closest to one day, week, and month behind the current bar's opening time. Each "string" in the array must contain a unit and an optional multiplier. Supported units are:
- "Y" for years.
- "M" for months.
- "W" for weeks.
- "D" for days.
- "YTD" (Year-to-date) for the span from the start of the current bar's year in the exchange time zone. An argument with this unit cannot contain a multiplier.
source (float) : (series float) The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple of the following data:
- An array containing a `source` value for each identified timestamp (array).
- An array containing an identified timestamp for each period specified in the `periods` array (array).
- The current bar's `source` value ("float").
- The symbol's description from `syminfo.description` ("string").
Adaptive Candlestick Pattern Recognition System█ INTRODUCTION
Nearly three years in the making, intermittently worked on in the few spare hours of weekends and time off, this is a passion project I undertook to flesh out my skills as a computer programmer. This script currently recognizes 85 different candlestick patterns ranging from one to five candles in length. It also performs statistical analysis on those patterns to determine prior performance and changes the coloration of those patterns based on that performance. In searching TradingView's script library for scripts similar to this one, I had found a handful. However, when I reviewed the ones which were open source, I did not see many that truly captured the power of PineScrypt or leveraged the way it works to create efficient and reliable code; one of the main driving factors for releasing this 5,000+ line behemoth open sourced.
Please take the time to review this description and source code to utilize this script to its fullest potential.
█ CONCEPTS
This script covers the following topics: Candlestick Theory, Trend Direction, Higher Timeframes, Price Analysis, Statistic Analysis, and Code Design.
Candlestick Theory - This script focuses solely on the concept of Candlestick Theory: arrangements of candlesticks may form certain patterns that can potentially influence the future price action of assets which experience those patterns. A full list of patterns (grouped by pattern length) will be in its own section of this description. This script contains two modes of operation for identifying candlestick patterns, 'CLASSIC' and 'BREAKOUT'.
CLASSIC: In this mode, candlestick patterns will be identified whenever they appear. The user has a wide variety of inputs to manipulate that can change how certain patterns are identified and even enable alerts to notify themselves when these patterns appear. Each pattern selected to appear will have their Profit or Loss (P/L) calculated starting from the first candle open succeeding the pattern to a candle close specified some number of candles ahead. These P/L calculations are then collected for each pattern, and split among partitions of prior price action of the asset the script is currently applied to (more on that in Higher Timeframes ).
BREAKOUT: In this mode, P/L calculations are held off until a breakout direction has been confirmed. The user may specify the number of candles ahead of a pattern's appearance (from one to five) that a pattern has to confirm a breakout in either an upward or downward direction. A breakout is constituted when there is a candle following the appearance of the pattern that closes above/at the highest high of the pattern, or below/at its lowest low. Only then will percent return calculations be performed for the pattern that's been identified, and these percent returns are broken up not only by the partition they had appeared in but also by the breakout direction itself. Patterns which do not breakout in either direction will be ignored, along with having their labels deleted.
In both of these modes, patterns may be overridden. Overrides occur when a smaller pattern has been detected and ends up becoming one (or more) of the candles of a larger pattern. A key example of this would be the Bearish Engulfing and the Three Outside Down patterns. A Three Outside Down necessitates a Bearish Engulfing as the first two candles in it, while the third candle closes lower. When a pattern is overridden, the return for that pattern will no longer be tracked. Overrides will not occur if the tail end of a larger pattern occurs at the beginning of a smaller pattern (Ex: a Bullish Engulfing occurs on the third candle of a Three Outside Down and the candle immediately following that pattern, the Three Outside Down pattern will not be overridden).
Important Functionality Note: These patterns are only searched for at the most recently closed candle, not on the currently closing candle, which creates an offset of one for this script's execution. (SEE LIMITATIONS)
Trend Direction - Many of the patterns require a trend direction prior to their appearance. Noting TradingView's own publication of candlestick patterns, I utilize a similar method for determining trend direction. Moving Averages are used to determine which trend is currently taking place for candlestick patterns to be sought out. The user has access to two Moving Averages which they may individually modify the following for each: Moving Average type (list of 9), their length, width, source values, and all variables associated with two special Moving Averages (Least Squares and Arnaud Legoux).
There are 3 settings for these Moving Averages, the first two switch between the two Moving Averages, and the third uses both. When using individual Moving Averages, the user may select a 'price point' to compare against the Moving Average (default is close). This price point is compared to the Moving Average at the candles prior to the appearance of candle patterns. Meaning: The close compared to the Moving Average two candles behind determines the trend direction used for Candlestick Analysis of one candle patterns; three candles behind for two candle patterns and so on. If the selected price point is above the Moving Average, then the current trend is an 'uptrend', 'downtrend' otherwise.
The third setting using both Moving Averages will compare the lengths of each, and trend direction is determined by the shorter Moving Average compared to the longer one. If the shorter Moving Average is above the longer, then the current trend is an 'uptrend', 'downtrend' otherwise. If the lengths of the Moving Averages are the same, or both Moving Averages are Symmetrical, then MA1 will be used by default. (SEE LIMITATIONS)
Higher Timeframes - This script employs the use of Higher Timeframes with a few request.security calls. The purpose of these calls is strictly for the partitioning of an asset's chart, splitting the returns of patterns into three separate groups. The four inputs in control of this partitioning split the chart based on: A given resolution to grab values from, the length of time in that resolution, and 'Upper' and 'Lower Limits' which split the trading range provided by that length of time in that resolution that forms three separate groups. The default values for these four inputs will partition the current chart by the yearly high-low range where: the 'Upper' partition is the top 20% of that trading range, the 'Middle' partition is 80% to 33% of the trading range, and the 'Lower' partition covers the trading range within 33% of the yearly low.
Patterns which are identified by this script will have their returns grouped together based on which partition they had appeared in. For example, a Bullish Engulfing which occurs within a third of the yearly low will have its return placed separately from a Bullish Engulfing that occurred within 20% of the yearly high. The idea is that certain patterns may perform better or worse depending on when they had occurred during an asset's trading range.
Price Analysis - Price Analysis is a major part of this script's functionality as it can fundamentally change how patterns are shown to the user. The settings related to Price Analysis include setting the number of candles ahead of a pattern's appearance to determine the return of that pattern. In 'BREAKOUT' mode, an additional setting allows the user to specify where the P/L calculation will begin for a pattern that had appeared and confirmed. (SEE LIMITATIONS)
The calculation for percent returns of patterns is illustrated with the following pseudo-code (CLASSIC mode, this is a simplified version of the actual code):
type patternObj
int ID
int partition
type returnsArray
float returns
// No pattern found = na returned
patternObj TEST_VAL = f_FindPattern()
priorTestVal = TEST_VAL
if not na( priorTestVal )
pnlMatrixRow = priorTestVal.ID
pnlMatrixCol = priorTestVal.partition
matrixReturn = matrix.get(PERCENT_RETURNS, pnlMatrixRow, pnlMatrixCol)
percentReturn = ( (close - open ) / open ) * 100%
array.push(matrixReturn.returns, percentReturn)
Statistic Analysis - This script uses Pine's built-in array functions to conduct the Statistic Analysis for patterns. When a pattern is found and its P/L calculation is complete, its return is added to a 'Return Array' User-Defined-Type that contains numerous fields which retain information on a pattern's prior performance. The actual UDT is as follows:
type returnArray
float returns = na
int size = 0
float avg = 0
float median = 0
float stdDev = 0
int polarities = na
All values within this UDT will be updated when a return is added to it (some based on user input). The array.avg , array.median and array.stdev will be ran and saved into their respective fields after a return is placed in the 'returns' array. The 'polarities' integer array is what will be changed based on user input. The user specifies two different percentages that declare 'Positive' and 'Negative' returns for patterns. When a pattern returns above, below, or in between these two values, different indices of this array will be incremented to reflect the kind of return that pattern had just experienced.
These values (plus the full name, partition the pattern occurred in, and a 95% confidence interval of expected returns) will be displayed to the user on the tooltip of the labels that identify patterns. Simply scroll over the pattern label to view each of these values.
Code Design - Overall this script is as much of an art piece as it is functional. Its design features numerous depictions of ASCII Art that illustrate what is being attempted by the functions that identify patterns, and an incalculable amount of time was spent rewriting portions of code to improve its efficiency. Admittedly, this final version is nearly 1,000 lines shorter than a previous version (one which took nearly 30 seconds after compilation to run, and didn't do nearly half of what this version does). The use of UDTs, especially the 'patternObj' one crafted and redesigned from the Hikkake Hunter 2.0 I published last month, played a significant role in making this script run efficiently. There is a slight rigidity in some of this code mainly around pattern IDs which are responsible for displaying the abbreviation for patterns (as well as the full names under the tooltips, and the matrix row position for holding returns), as each is hard-coded to correspond to that pattern.
However, one thing I would like to mention is the extensive use of global variables for pattern detection. Many scripts I had looked over for ideas on how to identify candlestick patterns had the same idea; break the pattern into a set of logical 'true/false' statements derived from historically referencing candle OHLC values. Some scripts which identified upwards of 20 to 30 patterns would reference Pine's built-in OHLC values for each pattern individually, potentially requesting information from TradingView's servers numerous times that could easily be saved into a variable for re-use and only requested once per candle (what this script does).
█ FEATURES
This script features a massive amount of switches, options, floating point values, detection settings, and methods for identifying/tailoring pattern appearances. All modifiable inputs for patterns are grouped together based on the number of candles they contain. Other inputs (like those for statistics settings and coloration) are grouped separately and presented in a way I believe makes the most sense.
Not mentioned above is the coloration settings. One of the aims of this script was to make patterns visually signify their behavior to the user when they are identified. Each pattern has its own collection of returns which are analyzed and compared to the inputs of the user. The user may choose the colors for bullish, neutral, and bearish patterns. They may also choose the minimum number of patterns needed to occur before assigning a color to that pattern based on its behavior; a color for patterns that have not met this minimum number of occurrences yet, and a color for patterns that are still processing in BREAKOUT mode.
There are also an additional three settings which alter the color scheme for patterns: Statistic Point-of-Reference, Adaptive coloring, and Hard Limiting. The Statistic Point-of-Reference decides which value (average or median) will be compared against the 'Negative' and 'Positive Return Tolerance'(s) to guide the coloration of the patterns (or for Adaptive Coloring, the generation of a color gradient).
Adaptive Coloring will have this script produce a gradient that patterns will be colored along. The more bullish or bearish a pattern is, the further along the gradient those patterns will be colored starting from the 'Neutral' color (hard lined at the value of 0%: values above this will be colored bullish, bearish otherwise). When Adaptive Coloring is enabled, this script will request the highest and lowest values (these being the Statistic Point-of-Reference) from the matrix containing all returns and rewrite global variables tied to the negative and positive return tolerances. This means that all patterns identified will be compared with each other to determine bullish/bearishness in Adaptive Coloring.
Hard Limiting will prevent these global variables from being rewritten, so patterns whose Statistic Point-of-Reference exceed the return tolerances will be fully colored the bullish or bearish colors instead of a generated gradient color. (SEE LIMITATIONS)
Apart from the Candle Detection Modes (CLASSIC and BREAKOUT), there's an additional two inputs which modify how this script behaves grouped under a "MASTER DETECTION SETTINGS" tab. These two "Pattern Detection Settings" are 'SWITCHBOARD' and 'TARGET MODE'.
SWITCHBOARD: Every single pattern has a switch that is associated with its detection. When a switch is enabled, the code which searches for that pattern will be run. With the Pattern Detection Setting set to this, all patterns that have their switches enabled will be sought out and shown.
TARGET MODE: There is an additional setting which operates on top of 'SWITCHBOARD' that singles out an individual pattern the user specifies through a drop down list. The names of every pattern recognized by this script will be present along with an identifier that shows the number of candles in that pattern (Ex: " (# candles)"). All patterns enabled in the switchboard will still have their returns measured, but only the pattern selected from the "Target Pattern" list will be shown. (SEE LIMITATIONS)
The vast majority of other features are held in the one, two, and three candle pattern sections.
For one-candle patterns, there are:
3 — Settings related to defining 'Tall' candles:
The number of candles to sample for previous candle-size averages.
The type of comparison done for 'Tall' Candles: Settings are 'RANGE' and 'BODY'.
The 'Tolerance' for tall candles, specifying what percent of the 'average' size candles must exceed to be considered 'Tall'.
When 'Tall Candle Setting' is set to RANGE, the high-low ranges are what the current candle range will be compared against to determine if a candle is 'Tall'. Otherwise the candle bodies (absolute value of the close - open) will be compared instead. (SEE LIMITATIONS)
Hammer Tolerance - How large a 'discarded wick' may be before it disqualifies a candle from being a 'Hammer'.
Discarded wicks are compared to the size of the Hammer's candle body and are dependent upon the body's center position. Hammer bodies closer to the high of the candle will have the upper wick used as its 'discarded wick', otherwise the lower wick is used.
9 — Doji Settings, some pulled from an old Doji Hunter I made a while back:
Doji Tolerance - How large the body of a candle may be compared to the range to be considered a 'Doji'.
Ignore N/S Dojis - Turns off Trend Direction for non-special Dojis.
GS/DF Doji Settings - 2 Inputs that enable and specify how large wicks that typically disqualify Dojis from being 'Gravestone' or 'Dragonfly' Dojis may be.
4 Settings related to 'Long Wick Doji' candles detailed below.
A Tolerance for 'Rickshaw Man' Dojis specifying how close the center of the body must be to the range to be valid.
The 4 settings the user may modify for 'Long Legged' Dojis are: A Sample Base for determining the previous average of wicks, a Sample Length specifying how far back to look for these averages, a Behavior Setting to define how 'Long Legged' Dojis are recognized, and a tolerance to specify how large in comparison to the prior wicks a Doji's wicks must be to be considered 'Long Legged'.
The 'Sample Base' list has two settings:
RANGE: The wicks of prior candles are compared to their candle ranges and the 'wick averages' will be what the average percent of ranges were in the sample.
WICKS: The size of the wicks themselves are averaged and returned for comparing against the current wicks of a Doji.
The 'Behavior' list has three settings:
ONE: Only one wick length needs to exceed the average by the tolerance for a Doji to be considered 'Long Legged'.
BOTH: Both wick lengths need to exceed the average of the tolerance of their respective wicks (upper wicks are compared to upper wicks, lower wicks compared to lower) to be considered 'Long Legged'.
AVG: Both wicks and the averages of the previous wicks are added together, divided by two, and compared. If the 'average' of the current wicks exceeds this combined average of prior wicks by the tolerance, then this would constitute a valid 'Long Legged' Doji. (For Dojis in general - SEE LIMITATIONS)
The final input is one related to candle patterns which require a Marubozu candle in them. The two settings for this input are 'INCLUSIVE' and 'EXCLUSIVE'. If INCLUSIVE is selected, any opening/closing variant of Marubozu candles will be allowed in the patterns that require them.
For two-candle patterns, there are:
2 — Settings which define 'Engulfing' parameters:
Engulfing Setting - Two options, RANGE or BODY which sets up how one candle may 'engulf' the previous.
Inclusive Engulfing - Boolean which enables if 'engulfing' candles can be equal to the values needed to 'engulf' the prior candle.
For the 'Engulfing Setting':
RANGE: If the second candle's high-low range completely covers the high-low range of the prior candle, this is recognized as 'engulfing'.
BODY: If the second candle's open-close completely covers the open-close of the previous candle, this is recognized as 'engulfing'. (SEE LIMITATIONS)
4 — Booleans specifying different settings for a few patterns:
One which allows for 'opens within body' patterns to let the second candle's open/close values match the prior candles' open/close.
One which forces 'Kicking' patterns to have a gap if the Marubozu setting is set to 'INCLUSIVE'.
And Two which dictate if the individual candles in 'Stomach' patterns need to be 'Tall'.
8 — Floating point values which affect 11 different patterns:
One which determines the distance the close of the first candle in a 'Hammer Inverted' pattern must be to the low to be considered valid.
One which affects how close the opens/closes need to be for all 'Lines' patterns (Bull/Bear Meeting/Separating Lines).
One that allows some leeway with the 'Matching Low' pattern (gives a small range the second candle close may be within instead of needing to match the previous close).
Three tolerances for On Neck/In Neck patterns (2 and 1 respectively).
A tolerance for the Thrusting pattern which give a range the close the second candle may be between the midpoint and close of the first to be considered 'valid'.
A tolerance for the two Tweezers patterns that specifies how close the highs and lows of the patterns need to be to each other to be 'valid'.
The first On Neck tolerance specifies how large the lower wick of the first candle may be (as a % of that candle's range) before the pattern is invalidated. The second tolerance specifies how far up the lower wick to the close the second candle's close may be for this pattern. The third tolerance for the In Neck pattern determines how far into the body of the first candle the second may close to be 'valid'.
For the remaining patterns (3, 4, and 5 candles), there are:
3 — Settings for the Deliberation pattern:
A boolean which forces the open of the third candle to gap above the close of the second.
A tolerance which changes the proximity of the third candle's open to the second candle's close in this pattern.
A tolerance that sets the maximum size the third candle may be compared to the average of the first two candles.
One boolean value for the Two Crows patterns (standard and Upside Gapping) that forces the first two candles in the patterns to completely gap if disabled (candle 1's close < candle 2's low).
10 — Floating point values for the remaining patterns:
One tolerance for defining how much the size of each candle in the Identical Black Crows pattern may deviate from the average of themselves to be considered valid.
One tolerance for setting how close the opens/closes of certain three candle patterns may be to each other's opens/closes.*
Three floating point values that affect the Three Stars in the South pattern.
One tolerance for the Side-by-Side patterns - looks at the second and third candle closes.
One tolerance for the Stick Sandwich pattern - looks at the first and third candle closes.
A floating value that sizes the Concealing Baby Swallow pattern's 3rd candle wick.
Two values for the Ladder Bottom pattern which define a range that the third candle's wick size may be.
* This affects the Three Black Crows (non-identical) and Three White Soldiers patterns, each require the opens and closes of every candle to be near each other.
The first tolerance of the Three Stars in the South pattern affects the first candle body's center position, and defines where it must be above to be considered valid. The second tolerance specifies how close the second candle must be to this same position, as well as the deviation the ratio the candle body to its range may be in comparison to the first candle. The third restricts how large the second candle range may be in comparison to the first (prevents this pattern from being recognized if the second candle is similar to the first but larger).
The last two floating point values define upper and lower limits to the wick size of a Ladder Bottom's fourth candle to be considered valid.
█ HOW TO USE
While there are many moving parts to this script, I attempted to set the default values with what I believed may help identify the most patterns within reasonable definitions. When this script is applied to a chart, the Candle Detection Mode (along with the BREAKOUT settings) and all candle switches must be confirmed before patterns are displayed. All switches are on by default, so this gives the user an opportunity to pick which patterns to identify first before playing around in the settings.
All of the settings/inputs described above are meant for experimentation. I encourage the user to tweak these values at will to find which set ups work best for whichever charts they decide to apply these patterns to.
Refer to the patterns themselves during experimentation. The statistic information provided on the tooltips of the patterns are meant to help guide input decisions. The breadth of candlestick theory is deep, and this was an attempt at capturing what I could in its sea of information.
█ LIMITATIONS
DISCLAIMER: While it may seem a bit paradoxical that this script aims to use past performance to potentially measure future results, past performance is not indicative of future results . Markets are highly adaptive and often unpredictable. This script is meant as an informational tool to show how patterns may behave. There is no guarantee that confidence intervals (or any other metric measured with this script) are accurate to the performance of patterns; caution must be exercised with all patterns identified regardless of how much information regarding prior performance is available.
Candlestick Theory - In the name, Candlestick Theory is a theory , and all theories come with their own limits. Some patterns identified by this script may be completely useless/unprofitable/unpredictable regardless of whatever combination of settings are used to identify them. However, if I truly believed this theory had no merit, this script would not exist. It is important to understand that this is a tool meant to be utilized with an array of others to procure positive (or negative, looking at you, short sellers ) results when navigating the complex world of finance.
To address the functionality note however, this script has an offset of 1 by default. Patterns will not be identified on the currently closing candle, only on the candle which has most recently closed. Attempting to have this script do both (offset by one or identify on close) lead to more trouble than it was worth. I personally just want users to be aware that patterns will not be identified immediately when they appear.
Trend Direction - Moving Averages - There is a small quirk with how MA settings will be adjusted if the user inputs two moving averages of the same length when the "MA Setting" is set to 'BOTH'. If Moving Averages have the same length, this script will default to only using MA 1 regardless of if the types of Moving Averages are different . I will experiment in the future to alleviate/reduce this restriction.
Price Analysis - BREAKOUT mode - With how identifying patterns with a look-ahead confirmation works, the percent returns for patterns that break out in either direction will be calculated on the same candle regardless of if P/L Offset is set to 'FROM CONFIRMATION' or 'FROM APPEARANCE'. This same issue is present in the Hikkake Hunter script mentioned earlier. This does not mean the P/L calculations are incorrect , the offset for the calculation is set by the number of candles required to confirm the pattern if 'FROM APPEARANCE' is selected. It just means that these two different P/L calculations will complete at the same time independent of the setting that's been selected.
Adaptive Coloring/Hard Limiting - Hard Limiting is only used with Adaptive Coloring and has no effect outside of it. If Hard Limiting is used, it is recommended to increase the 'Positive' and 'Negative' return tolerance values as a pattern's bullish/bearishness may be disproportionately represented with the gradient generated under a hard limit.
TARGET MODE - This mode will break rules regarding patterns that are overridden on purpose. If a pattern selected in TARGET mode would have otherwise been absorbed by a larger pattern, it will have that pattern's percent return calculated; potentially leading to duplicate returns being included in the matrix of all returns recognized by this script.
'Tall' Candle Setting - This is a wide-reaching setting, as approximately 30 different patterns or so rely on defining 'Tall' candles. Changing how 'Tall' candles are defined whether by the tolerance value those candles need to exceed or by the values of the candle used for the baseline comparison (RANGE/BODY) can wildly affect how this script functions under certain conditions. Refer to the tooltip of these settings for more information on which specific patterns are affected by this.
Doji Settings - There are roughly 10 or so two to three candle patterns which have Dojis as a part of them. If all Dojis are disabled, it will prevent some of these larger patterns from being recognized. This is a dependency issue that I may address in the future.
'Engulfing' Setting - Functionally, the two 'Engulfing' settings are quite different. Because of this, the 'RANGE' setting may cause certain patterns that would otherwise be valid under textbook and online references/definitions to not be recognized as such (like the Upside Gap Two Crows or Three Outside down).
█ PATTERN LIST
This script recognizes 85 patterns upon initial release. I am open to adding additional patterns to it in the future and any comments/suggestions are appreciated. It recognizes:
15 — 1 Candle Patterns
4 Hammer type patterns: Regular Hammer, Takuri Line, Shooting Star, and Hanging Man
9 Doji Candles: Regular Dojis, Northern/Southern Dojis, Gravestone/Dragonfly Dojis, Gapping Up/Down Dojis, and Long-Legged/Rickshaw Man Dojis
White/Black Long Days
32 — 2 Candle Patterns
4 Engulfing type patterns: Bullish/Bearish Engulfing and Last Engulfing Top/Bottom
Dark Cloud Cover
Bullish/Bearish Doji Star patterns
Hammer Inverted
Bullish/Bearish Haramis + Cross variants
Homing Pigeon
Bullish/Bearish Kicking
4 Lines type patterns: Bullish/Bearish Meeting/Separating Lines
Matching Low
On/In Neck patterns
Piercing pattern
Shooting Star (2 Lines)
Above/Below Stomach patterns
Thrusting
Tweezers Top/Bottom patterns
Two Black Gapping
Rising/Falling Window patterns
29 — 3 Candle Patterns
Bullish/Bearish Abandoned Baby patterns
Advance Block
Collapsing Doji Star
Deliberation
Upside/Downside Gap Three Methods patterns
Three Inside/Outside Up/Down patterns (4 total)
Bullish/Bearish Side-by-Side patterns
Morning/Evening Star patterns + Doji variants
Stick Sandwich
Downside/Upside Tasuki Gap patterns
Three Black Crows + Identical variation
Three White Soldiers
Three Stars in the South
Bullish/Bearish Tri-Star patterns
Two Crows + Upside Gap variant
Unique Three River Bottom
3 — 4 Candle Patterns
Concealing Baby Swallow
Bullish/Bearish Three Line Strike patterns
6 — 5 Candle Patterns
Bullish/Bearish Breakaway patterns
Ladder Bottom
Mat Hold
Rising/Falling Three Methods patterns
█ WORKS CITED
Because of the amount of time needed to complete this script, I am unable to provide exact dates for when some of these references were used. I will also not provide every single reference, as citing a reference for each individual pattern and the place it was reviewed would lead to a bibliography larger than this script and its description combined. There were five major resources I used when building this script, one book, two websites (for various different reasons including patterns, moving averages, and various other articles of information), various scripts from TradingView's public library (including TradingView's own source code for *all* candle patterns ), and PineScrypt's reference manual.
Bulkowski, Thomas N. Encyclopedia of Candlestick Patterns . Hoboken, New Jersey: John Wiley & Sons Inc., 2008. E-book (google books).
Various. Numerous webpages. CandleScanner . 2023. online. Accessed 2020 - 2023.
Various. Numerous webpages. Investopedia . 2023. online. Accessed 2020 - 2023.
█ AKNOWLEDGEMENTS
I want to take the time here to thank all of my friends and family, both online and in real life, for the support they've given me over the last few years in this endeavor. My pets who tried their hardest to keep me from completing it. And work for the grit to continue pushing through until this script's completion.
This belongs to me just as much as it does anyone else. Whether you are an institutional trader, gold bug hedging against the dollar, retail ape who got in on a squeeze, or just parents trying to grow their retirement/save for the kids. This belongs to everyone.
Private Beta for new features to be tested can be found here .
Vires In Numeris
`security()` revisited [PineCoders]NOTE
The non-repainting technique in this publication that relies on bar states is now deprecated, as we have identified inconsistencies that undermine its credibility as a universal solution. The outputs that use the technique are still available for reference in this publication. However, we do not endorse its usage. See this publication for more information about the current best practices for requesting HTF data and why they work.
█ OVERVIEW
This script presents a new function to help coders use security() in both repainting and non-repainting modes. We revisit this often misunderstood and misused function, and explain its behavior in different contexts, in the hope of dispelling some of the coder lure surrounding it. The function is incredibly powerful, yet misused, it can become a dangerous WMD and an instrument of deception, for both coders and traders.
We will discuss:
• How to use our new `f_security()` function.
• The behavior of Pine code and security() on the three very different types of bars that make up any chart.
• Why what you see on a chart is a simulation, and should be taken with a grain of salt.
• Why we are presenting a new version of a function handling security() calls.
• Other topics of interest to coders using higher timeframe (HTF) data.
█ WARNING
We have tried to deliver a function that is simple to use and will, in non-repainting mode, produce reliable results for both experienced and novice coders. If you are a novice coder, stick to our recommendations to avoid getting into trouble, and DO NOT change our `f_security()` function when using it. Use `false` as the function's last argument and refrain from using your script at smaller timeframes than the chart's. To call our function to fetch a non-repainting value of close from the 1D timeframe, use:
f_security(_sym, _res, _src, _rep) => security(_sym, _res, _src )
previousDayClose = f_security(syminfo.tickerid, "D", close, false)
If that's all you're interested in, you are done.
If you choose to ignore our recommendation and use the function in repainting mode by changing the `false` in there for `true`, we sincerely hope you read the rest of our ramblings before you do so, to understand the consequences of your choice.
Let's now have a look at what security() is showing you. There is a lot to cover, so buckle up! But before we dig in, one last thing.
What is a chart?
A chart is a graphic representation of events that occur in markets. As any representation, it is not reality, but rather a model of reality. As Scott Page eloquently states in The Model Thinker : "All models are wrong; many are useful". Having in mind that both chart bars and plots on our charts are imperfect and incomplete renderings of what actually occurred in realtime markets puts us coders in a place from where we can better understand the nature of, and the causes underlying the inevitable compromises necessary to build the data series our code uses, and print chart bars.
Traders or coders complaining that charts do not reflect reality act like someone who would complain that the word "dog" is not a real dog. Let's recognize that we are dealing with models here, and try to understand them the best we can. Sure, models can be improved; TradingView is constantly improving the quality of the information displayed on charts, but charts nevertheless remain mere translations. Plots of data fetched through security() being modelized renderings of what occurs at higher timeframes, coders will build more useful and reliable tools for both themselves and traders if they endeavor to perfect their understanding of the abstractions they are working with. We hope this publication helps you in this pursuit.
█ FEATURES
This script's "Inputs" tab has four settings:
• Repaint : Determines whether the functions will use their repainting or non-repainting mode.
Note that the setting will not affect the behavior of the yellow plot, as it always repaints.
• Source : The source fetched by the security() calls.
• Timeframe : The timeframe used for the security() calls. If it is lower than the chart's timeframe, a warning appears.
• Show timeframe reminder : Displays a reminder of the timeframe after the last bar.
█ THE CHART
The chart shows two different pieces of information and we want to discuss other topics in this section, so we will be covering:
A — The type of chart bars we are looking at, indicated by the colored band at the top.
B — The plots resulting of calling security() with the close price in different ways.
C — Points of interest on the chart.
A — Chart bars
The colored band at the top shows the three types of bars that any chart on a live market will print. It is critical for coders to understand the important distinctions between each type of bar:
1 — Gray : Historical bars, which are bars that were already closed when the script was run on them.
2 — Red : Elapsed realtime bars, i.e., realtime bars that have run their course and closed.
The state of script calculations showing on those bars is that of the last time they were made, when the realtime bar closed.
3 — Green : The realtime bar. Only the rightmost bar on the chart can be the realtime bar at any given time, and only when the chart's market is active.
Refer to the Pine User Manual's Execution model page for a more detailed explanation of these types of bars.
B — Plots
The chart shows the result of letting our 5sec chart run for a few minutes with the following settings: "Repaint" = "On" (the default is "Off"), "Source" = `close` and "Timeframe" = 1min. The five lines plotted are the following. They have progressively thinner widths:
1 — Yellow : A normal, repainting security() call.
2 — Silver : Our recommended security() function.
3 — Fuchsia : Our recommended way of achieving the same result as our security() function, for cases when the source used is a function returning a tuple.
4 — White : The method we previously recommended in our MTF Selection Framework , which uses two distinct security() calls.
5 — Black : A lame attempt at fooling traders that MUST be avoided.
All lines except the first one in yellow will vary depending on the "Repaint" setting in the script's inputs. The first plot does not change because, contrary to all other plots, it contains no conditional code to adapt to repainting/no-repainting modes; it is a simple security() call showing its default behavior.
C — Points of interest on the chart
Historical bars do not show actual repainting behavior
To appreciate what a repainting security() call will plot in realtime, one must look at the realtime bar and at elapsed realtime bars, the bars where the top line is green or red on the chart at the top of this page. There you can see how the plots go up and down, following the close value of each successive chart bar making up a single bar of the higher timeframe. You would see the same behavior in "Replay" mode. In the realtime bar, the movement of repainting plots will vary with the source you are fetching: open will not move after a new timeframe opens, low and high will change when a new low or high are found, close will follow the last feed update. If you are fetching a value calculated by a function, it may also change on each update.
Now notice how different the plots are on historical bars. There, the plot shows the close of the previously completed timeframe for the whole duration of the current timeframe, until on its last bar the price updates to the current timeframe's close when it is confirmed (if the timeframe's last bar is missing, the plot will only update on the next timeframe's first bar). That last bar is the only one showing where the plot would end if that timeframe's bars had elapsed in realtime. If one doesn't understand this, one cannot properly visualize how his script will calculate in realtime when using repainting. Additionally, as published scripts typically show charts where the script has only run on historical bars, they are, in fact, misleading traders who will naturally assume the script will behave the same way on realtime bars.
Non-repainting plots are more accurate on historical bars
Now consider this chart, where we are using the same settings as on the chart used to publish this script, except that we have turned "Repainting" off this time:
The yellow line here is our reference, repainting line, so although repainting is turned off, it is still repainting, as expected. Because repainting is now off, however, plots on historical bars show the previous timeframe's close until the first bar of a new timeframe, at which point the plot updates. This correctly reflects the behavior of the script in the realtime bar, where because we are offsetting the series by one, we are always showing the previously calculated—and thus confirmed—higher timeframe value. This means that in realtime, we will only get the previous timeframe's values one bar after the timeframe's last bar has elapsed, at the open of the first bar of a new timeframe. Historical and elapsed realtime bars will not actually show this nuance because they reflect the state of calculations made on their close , but we can see the plot update on that bar nonetheless.
► This more accurate representation on historical bars of what will happen in the realtime bar is one of the two key reasons why using non-repainting data is preferable.
The other is that in realtime, your script will be using more reliable data and behave more consistently.
Misleading plots
Valiant attempts by coders to show non-repainting, higher timeframe data updating earlier than on our chart are futile. If updates occur one bar earlier because coders use the repainting version of the function, then so be it, but they must then also accept that their historical bars are not displaying information that is as accurate. Not informing script users of this is to mislead them. Coders should also be aware that if they choose to use repainting data in realtime, they are sacrificing reliability to speed and may be running a strategy that behaves very differently from the one they backtested, thus invalidating their tests.
When, however, coders make what are supposed to be non-repainting plots plot artificially early on historical bars, as in examples "c4" and "c5" of our script, they would want us to believe they have achieved the miracle of time travel. Our understanding of the current state of science dictates that for now, this is impossible. Using such techniques in scripts is plainly misleading, and public scripts using them will be moderated. We are coding trading tools here—not video games. Elementary ethics prescribe that we should not mislead traders, even if it means not being able to show sexy plots. As the great Feynman said: You should not fool the layman when you're talking as a scientist.
You can readily appreciate the fantasy plot of "c4", the thinnest line in black, by comparing its supposedly non-repainting behavior between historical bars and realtime bars. After updating—by miracle—as early as the wide yellow line that is repainting, it suddenly moves in a more realistic place when the script is running in realtime, in synch with our non-repainting lines. The "c5" version does not plot on the chart, but it displays in the Data Window. It is even worse than "c4" in that it also updates magically early on historical bars, but goes on to evaluate like the repainting yellow line in realtime, except one bar late.
Data Window
The Data Window shows the values of the chart's plots, then the values of both the inside and outside offsets used in our calculations, so you can see them change bar by bar. Notice their differences between historical and elapsed realtime bars, and the realtime bar itself. If you do not know about the Data Window, have a look at this essential tool for Pine coders in the Pine User Manual's page on Debugging . The conditional expressions used to calculate the offsets may seem tortuous but their objective is quite simple. When repainting is on, we use this form, so with no offset on all bars:
security(ticker, i_timeframe, i_source )
// which is equivalent to:
security(ticker, i_timeframe, i_source)
When repainting is off, we use two different and inverted offsets on historical bars and the realtime bar:
// Historical bars:
security(ticker, i_timeframe, i_source )
// Realtime bar (and thus, elapsed realtime bars):
security(ticker, i_timeframe, i_source )
The offsets in the first line show how we prevent repainting on historical bars without the need for the `lookahead` parameter. We use the value of the function call on the chart's previous bar. Since values between the repainting and non-repainting versions only differ on the timeframe's last bar, we can use the previous value so that the update only occurs on the timeframe's first bar, as it will in realtime when not repainting.
In the realtime bar, we use the second call, where the offsets are inverted. This is because if we used the first call in realtime, we would be fetching the value of the repainting function on the previous bar, so the close of the last bar. What we want, instead, is the data from the previous, higher timeframe bar , which has elapsed and is confirmed, and thus will not change throughout realtime bars, except on the first constituent chart bar belonging to a new higher timeframe.
After the offsets, the Data Window shows values for the `barstate.*` variables we use in our calculations.
█ NOTES
Why are we revisiting security() ?
For four reasons:
1 — We were seeing coders misuse our `f_secureSecurity()` function presented in How to avoid repainting when using security() .
Some novice coders were modifying the offset used with the history-referencing operator in the function, making it zero instead of one,
which to our horror, caused look-ahead bias when used with `lookahead = barmerge.lookahead_on`.
We wanted to present a safer function which avoids introducing the dreaded "lookahead" in the scripts of unsuspecting coders.
2 — The popularity of security() in screener-type scripts where coders need to use the full 40 calls allowed per script made us want to propose
a solid method of allowing coders to offer a repainting/no-repainting choice to their script users with only one security() call.
3 — We wanted to explain why some alternatives we see circulating are inadequate and produce misleading behavior.
4 — Our previous publication on security() focused on how to avoid repainting, yet many other considerations worthy of attention are not related to repainting.
Handling tuples
When sending function calls that return tuples with security() , our `f_security()` function will not work because Pine does not allow us to use the history-referencing operator with tuple return values. The solution is to integrate the inside offset to your function's arguments, use it to offset the results the function is returning, and then add the outside offset in a reassignment of the tuple variables, after security() returns its values to the script, as we do in our "c2" example.
Does it repaint?
We're pretty sure Wilder was not asked very often if RSI repainted. Why? Because it wasn't in fashion—and largely unnecessary—to ask that sort of question in the 80's. Many traders back then used daily charts only, and indicator values were calculated at the day's close, so everybody knew what they were getting. Additionally, indicator values were calculated by generally reputable outfits or traders themselves, so data was pretty reliable. Today, almost anybody can write a simple indicator, and the programming languages used to write them are complex enough for some coders lacking the caution, know-how or ethics of the best professional coders, to get in over their heads and produce code that does not work the way they think it does.
As we hope to have clearly demonstrated, traders do have legitimate cause to ask if MTF scripts repaint or not when authors do not specify it in their script's description.
► We recommend that authors always use our `f_security()` with `false` as the last argument to avoid repainting when fetching data dependent on OHLCV information. This is the only way to obtain reliable HTF data. If you want to offer users a choice, make non-repainting mode the default, so that if users choose repainting, it will be their responsibility. Non-repainting security() calls are also the only way for scripts to show historical behavior that matches the script's realtime behavior, so you are not misleading traders. Additionally, non-repainting HTF data is the only way that non-repainting alerts can be configured on MTF scripts, as users of MTF scripts cannot prevent their alerts from repainting by simply configuring them to trigger on the bar's close.
Data feeds
A chart at one timeframe is made up of multiple feeds that mesh seamlessly to form one chart. Historical bars can use one feed, and the realtime bar another, which brokers/exchanges can sometimes update retroactively so that elapsed realtime bars will reappear with very slight modifications when the browser's tab is refreshed. Intraday and daily chart prices also very often originate from different feeds supplied by brokers/exchanges. That is why security() calls at higher timeframes may be using a completely different feed than the chart, and explains why the daily high value, for example, can vary between timeframes. Volume information can also vary considerably between intraday and daily feeds in markets like stocks, because more volume information becomes available at the end of day. It is thus expected behavior—and not a bug—to see data variations between timeframes.
Another point to keep in mind concerning feeds it that when you are using a repainting security() plot in realtime, you will sometimes see discrepancies between its plot and the realtime bars. An artefact revealing these inconsistencies can be seen when security() plots sometimes skip a realtime chart bar during periods of high market activity. This occurs because of races between the chart and the security() feeds, which are being monitored by independent, concurrent processes. A blue arrow on the chart indicates such an occurrence. This is another cause of repainting, where realtime bar-building logic can produce different outcomes on one closing price. It is also another argument supporting our recommendation to use non-repainting data.
Alternatives
There is an alternative to using security() in some conditions. If all you need are OHLC prices of a higher timeframe, you can use a technique like the one Duyck demonstrates in his security free MTF example - JD script. It has the great advantage of displaying actual repainting values on historical bars, which mimic the code's behavior in the realtime bar—or at least on elapsed realtime bars, contrary to a repainting security() plot. It has the disadvantage of using the current chart's TF data feed prices, whereas higher timeframe data feeds may contain different and more reliable prices when they are compiled at the end of the day. In its current state, it also does not allow for a repainting/no-repainting choice.
When `lookahead` is useful
When retrieving non-price data, or in special cases, for experiments, it can be useful to use `lookahead`. One example is our Backtesting on Non-Standard Charts: Caution! script where we are fetching prices of standard chart bars from non-standard charts.
Warning users
Normal use of security() dictates that it only be used at timeframes equal to or higher than the chart's. To prevent users from inadvertently using your script in contexts where it will not produce expected behavior, it is good practice to warn them when their chart is on a higher timeframe than the one in the script's "Timeframe" field. Our `f_tfReminderAndErrorCheck()` function in this script does that. It can also print a reminder of the higher timeframe. It uses one security() call.
Intrabar timeframes
security() is not supported by TradingView when used with timeframes lower than the chart's. While it is still possible to use security() at intrabar timeframes, it then behaves differently. If no care is taken to send a function specifically written to handle the successive intrabars, security() will return the value of the last intrabar in the chart's timeframe, so the last 1H bar in the current 1D bar, if called at "60" from a "D" chart timeframe. If you are an advanced coder, see our FAQ entry on the techniques involved in processing intrabar timeframes. Using intrabar timeframes comes with important limitations, which you must understand and explain to traders if you choose to make scripts using the technique available to others. Special care should also be taken to thoroughly test this type of script. Novice coders should refrain from getting involved in this.
█ TERMINOLOGY
Timeframe
Timeframe , interval and resolution are all being used to name the concept of timeframe. We have, in the past, used "timeframe" and "resolution" more or less interchangeably. Recently, members from the Pine and PineCoders team have decided to settle on "timeframe", so from hereon we will be sticking to that term.
Multi-timeframe (MTF)
Some coders use "multi-timeframe" or "MTF" to name what are in fact "multi-period" calculations, as when they use MAs of progressively longer periods. We consider that a misleading use of "multi-timeframe", which should be reserved for code using calculations actually made from another timeframe's context and using security() , safe for scripts like Duyck's one mentioned earlier, or TradingView's Relative Volume at Time , which use a user-selected timeframe as an anchor to reset calculations. Calculations made at the chart's timeframe by varying the period of MAs or other rolling window calculations should be called "multi-period", and "MTF-anchored" could be used for scripts that reset calculations on timeframe boundaries.
Colophon
Our script was written using the PineCoders Coding Conventions for Pine .
The description was formatted using the techniques explained in the How We Write and Format Script Descriptions PineCoders publication.
Snippets were lifted from our MTF Selection Framework , then massaged to create the `f_tfReminderAndErrorCheck()` function.
█ THANKS
Thanks to apozdnyakov for his help with the innards of security() .
Thanks to bmistiaen for proofreading our description.
Look first. Then leap.
HTFMAs█ OVERVIEW
Contains a type HTFMA used to return data on six moving averages from a higher timeframe.
Several types of MA's are supported.
█ HOW TO USE
Please see instructions in the code (in library description). (Important: first fold all sections of the script: press Cmd + K then Cmd + - (for Windows Ctrl + K then Ctrl + -)
█ FULL LIST OF FUNCTIONS AND PARAMETERS
method getMaType(this)
Enumerator function, given a key returns `enum MaTypes` value
Namespace types: series string, simple string, input string, const string
Parameters:
this (string)
method init(this, enableAll, ma1Enabled, ma1MaType, ma1Src, ma1Prd, ma2Enabled, ma2MaType, ma2Src, ma2Prd, ma3Enabled, ma3MaType, ma3Src, ma3Prd, ma4Enabled, ma4MaType, ma4Src, ma4Prd, ma5Enabled, ma5MaType, ma5Src, ma5Prd, ma6Enabled, ma6MaType, ma6Src, ma6Prd)
Namespace types: RsParamsMAs
Parameters:
this (RsParamsMAs)
enableAll (simple MaEnable)
ma1Enabled (bool)
ma1MaType (series MaTypes)
ma1Src (string)
ma1Prd (int)
ma2Enabled (bool)
ma2MaType (series MaTypes)
ma2Src (string)
ma2Prd (int)
ma3Enabled (bool)
ma3MaType (series MaTypes)
ma3Src (string)
ma3Prd (int)
ma4Enabled (bool)
ma4MaType (series MaTypes)
ma4Src (string)
ma4Prd (int)
ma5Enabled (bool)
ma5MaType (series MaTypes)
ma5Src (string)
ma5Prd (int)
ma6Enabled (bool)
ma6MaType (series MaTypes)
ma6Src (string)
ma6Prd (int)
method init(this, enableAll, tf, rngAtrQ, showRecentBars, lblsOffset, lblsShow, lnOffset, lblSize, lblStyle, smoothen, ma1lnClr, ma1lnWidth, ma1lnStyle, ma2lnClr, ma2lnWidth, ma2lnStyle, ma3lnClr, ma3lnWidth, ma3lnStyle, ma4lnClr, ma4lnWidth, ma4lnStyle, ma5lnClr, ma5lnWidth, ma5lnStyle, ma6lnClr, ma6lnWidth, ma6lnStyle, ma1ShowHistory, ma2ShowHistory, ma3ShowHistory, ma4ShowHistory, ma5ShowHistory, ma6ShowHistory, ma1ShowLabel, ma2ShowLabel, ma3ShowLabel, ma4ShowLabel, ma5ShowLabel, ma6ShowLabel)
Namespace types: HTFMAs
Parameters:
this (HTFMAs)
enableAll (series MaEnable)
tf (string)
rngAtrQ (int)
showRecentBars (int)
lblsOffset (int)
lblsShow (bool)
lnOffset (int)
lblSize (string)
lblStyle (string)
smoothen (bool)
ma1lnClr (color)
ma1lnWidth (int)
ma1lnStyle (string)
ma2lnClr (color)
ma2lnWidth (int)
ma2lnStyle (string)
ma3lnClr (color)
ma3lnWidth (int)
ma3lnStyle (string)
ma4lnClr (color)
ma4lnWidth (int)
ma4lnStyle (string)
ma5lnClr (color)
ma5lnWidth (int)
ma5lnStyle (string)
ma6lnClr (color)
ma6lnWidth (int)
ma6lnStyle (string)
ma1ShowHistory (bool)
ma2ShowHistory (bool)
ma3ShowHistory (bool)
ma4ShowHistory (bool)
ma5ShowHistory (bool)
ma6ShowHistory (bool)
ma1ShowLabel (bool)
ma2ShowLabel (bool)
ma3ShowLabel (bool)
ma4ShowLabel (bool)
ma5ShowLabel (bool)
ma6ShowLabel (bool)
method get(this, id)
Namespace types: RsParamsMAs
Parameters:
this (RsParamsMAs)
id (int)
method set(this, id, prop, val)
Namespace types: RsParamsMAs
Parameters:
this (RsParamsMAs)
id (int)
prop (string)
val (string)
method set(this, id, prop, val)
Namespace types: HTFMAs
Parameters:
this (HTFMAs)
id (int)
prop (string)
val (string)
method htfUpdateTuple(rsParams, repaint)
Namespace types: RsParamsMAs
Parameters:
rsParams (RsParamsMAs)
repaint (bool)
method clear(this)
Namespace types: MaDrawing
Parameters:
this (MaDrawing)
method importRsRetTuple(this, htfBi, ma1, ma2, ma3, ma4, ma5, ma6)
Namespace types: HTFMAs
Parameters:
this (HTFMAs)
htfBi (int)
ma1 (float)
ma2 (float)
ma3 (float)
ma4 (float)
ma5 (float)
ma6 (float)
method getDrw(this, id)
Namespace types: HTFMAs
Parameters:
this (HTFMAs)
id (int)
method setDrwProp(this, id, prop, val)
Namespace types: HTFMAs
Parameters:
this (HTFMAs)
id (int)
prop (string)
val (string)
method initDrawings(this, rsPrms, dispBandWidth)
Namespace types: HTFMAs
Parameters:
this (HTFMAs)
rsPrms (RsParamsMAs)
dispBandWidth (float)
method updateDrawings(this, rsPrms, dispBandWidth)
Namespace types: HTFMAs
Parameters:
this (HTFMAs)
rsPrms (RsParamsMAs)
dispBandWidth (float)
method update(this)
Namespace types: HTFMAs
Parameters:
this (HTFMAs)
method importConfig(this, oCfg, maCount)
Imports HTF MAs settings from objProps (of any level) into `RsParamsMAs` child `RsMaCalcParams` objects (into the first first `maCount` of them)
Namespace types: RsParamsMAs
Parameters:
this (RsParamsMAs) : (RsParamsMAs) Target object to import prop values to.
oCfg (objProps type from moebius1977/CSVParser/1) : (CSVP.objProps) (one of objProps types) an objProps, ... opjProps8 containing properties' values in a child objProps objects
maCount (int) : (int) Number of tgtObj's RsMaCalcParams childs of tgtObj to set (1 to 6, starting from 1)
Returns: this
method importConfig(this, oCfg, maCount)
Imports HTF MAs settings from objProps (of any level) into `RsParamsMAs` child `RsMaCalcParams` objects (into the first first `maCount` of them)
Namespace types: RsParamsMAs
Parameters:
this (RsParamsMAs) : (RsParamsMAs) Target object to import prop values to.
oCfg (objProps0 type from moebius1977/CSVParser/1) : (CSVP.objProps) (one of objProps types) an objProps, ... opjProps8 containing properties' values in a child objProps objects
maCount (int) : (int) Number of tgtObj's RsMaCalcParams childs of tgtObj to set (1 to 6, starting from 1)
Returns: this
method importConfig(this, oCfg, maCount)
Imports HTF MAs settings from objProps (of any level) into `RsParamsMAs` child `RsMaCalcParams` objects (into the first first `maCount` of them)
Namespace types: RsParamsMAs
Parameters:
this (RsParamsMAs) : (RsParamsMAs) Target object to import prop values to.
oCfg (objProps1 type from moebius1977/CSVParser/1) : (CSVP.objProps) (one of objProps types) an objProps, ... opjProps8 containing properties' values in a child objProps objects
maCount (int) : (int) Number of tgtObj's RsMaCalcParams childs of tgtObj to set (1 to 6, starting from 1)
Returns: this
method importConfig(this, oCfg, maCount)
Imports HTF MAs settings from objProps (of any level) into `RsParamsMAs` child `RsMaCalcParams` objects (into the first first `maCount` of them)
Namespace types: RsParamsMAs
Parameters:
this (RsParamsMAs) : (RsParamsMAs) Target object to import prop values to.
oCfg (objProps2 type from moebius1977/CSVParser/1) : (CSVP.objProps) (one of objProps types) an objProps, ... opjProps8 containing properties' values in a child objProps objects
maCount (int) : (int) Number of tgtObj's RsMaCalcParams childs of tgtObj to set (1 to 6, starting from 1)
Returns: this
method importConfig(this, oCfg, maCount)
Imports HTF MAs settings from objProps (of any level) into `RsParamsMAs` child `RsMaCalcParams` objects (into the first first `maCount` of them)
Namespace types: RsParamsMAs
Parameters:
this (RsParamsMAs) : (RsParamsMAs) Target object to import prop values to.
oCfg (objProps3 type from moebius1977/CSVParser/1) : (CSVP.objProps) (one of objProps types) an objProps, ... opjProps8 containing properties' values in a child objProps objects
maCount (int) : (int) Number of tgtObj's RsMaCalcParams childs of tgtObj to set (1 to 6, starting from 1)
Returns: this
method importConfig(this, oCfg, maCount)
Imports HTF MAs settings from objProps (of any level) into `RsParamsMAs` child `RsMaCalcParams` objects (into the first first `maCount` of them)
Namespace types: RsParamsMAs
Parameters:
this (RsParamsMAs) : (RsParamsMAs) Target object to import prop values to.
oCfg (objProps4 type from moebius1977/CSVParser/1) : (CSVP.objProps) (one of objProps types) an objProps, ... opjProps8 containing properties' values in a child objProps objects
maCount (int) : (int) Number of tgtObj's RsMaCalcParams childs of tgtObj to set (1 to 6, starting from 1)
Returns: this
method importConfig(this, oCfg, maCount)
Imports HTF MAs settings from objProps (of any level) into `RsParamsMAs` child `RsMaCalcParams` objects (into the first first `maCount` of them)
Namespace types: RsParamsMAs
Parameters:
this (RsParamsMAs) : (RsParamsMAs) Target object to import prop values to.
oCfg (objProps5 type from moebius1977/CSVParser/1) : (CSVP.objProps) (one of objProps types) an objProps, ... opjProps8 containing properties' values in a child objProps objects
maCount (int) : (int) Number of tgtObj's RsMaCalcParams childs of tgtObj to set (1 to 6, starting from 1)
Returns: this
method importConfig(this, oCfg, maCount)
Imports HTF MAs settings from objProps (of any level) into `RsParamsMAs` child `RsMaCalcParams` objects (into the first first `maCount` of them)
Namespace types: RsParamsMAs
Parameters:
this (RsParamsMAs) : (RsParamsMAs) Target object to import prop values to.
oCfg (objProps6 type from moebius1977/CSVParser/1) : (CSVP.objProps) (one of objProps types) an objProps, ... opjProps8 containing properties' values in a child objProps objects
maCount (int) : (int) Number of tgtObj's RsMaCalcParams childs of tgtObj to set (1 to 6, starting from 1)
Returns: this
method importConfig(this, oCfg, maCount)
Namespace types: RsParamsMAs
Parameters:
this (RsParamsMAs)
oCfg (objProps7 type from moebius1977/CSVParser/1)
maCount (int)
method importConfig(this, oCfg, maCount)
Imports HTF MAs settings from objProps (of any level) into `HTFMAs` child `MaDrawing` objects (into the first first `maCount` of them)
Namespace types: RsParamsMAs
Parameters:
this (RsParamsMAs) : (HTFMAs) Target object to import prop values to.
oCfg (objProps8 type from moebius1977/CSVParser/1) : (CSVP.objProps) (one of objProps types) an objProps, ... opjProps8 containing properties' values in a child objProps objects
maCount (int) : (int) Number of tgtObj's RsMaCalcParams childs of tgtObj to set (1 to 6, starting from 1)
Returns: this
method importConfig(this, oCfg, maCount)
Imports HTF MAs settings from objProps (of any level) into `HTFMAs` child `MaDrawing` objects (into the first first `maCount` of them)
Namespace types: HTFMAs
Parameters:
this (HTFMAs) : (HTFMAs) Target object to import prop values to.
oCfg (objProps type from moebius1977/CSVParser/1) : (CSVP.objProps) (one of objProps types) an objProps, ... opjProps8 containing properties' values in a child objProps objects
maCount (int) : (int) Number of tgtObj's RsMaCalcParams childs of tgtObj to set (1 to 6, starting from 1)
Returns: this
method importConfig(this, oCfg, maCount)
Imports HTF MAs settings from objProps (of any level) into `HTFMAs` child `MaDrawing` objects (into the first first `maCount` of them)
Namespace types: HTFMAs
Parameters:
this (HTFMAs) : (HTFMAs) Target object to import prop values to.
oCfg (objProps0 type from moebius1977/CSVParser/1) : (CSVP.objProps) (one of objProps types) an objProps, ... opjProps8 containing properties' values in a child objProps objects
maCount (int) : (int) Number of tgtObj's RsMaCalcParams childs of tgtObj to set (1 to 6, starting from 1)
Returns: this
method importConfig(this, oCfg, maCount)
Imports HTF MAs settings from objProps (of any level) into `HTFMAs` child `MaDrawing` objects (into the first first `maCount` of them)
Namespace types: HTFMAs
Parameters:
this (HTFMAs) : (HTFMAs) Target object to import prop values to.
oCfg (objProps1 type from moebius1977/CSVParser/1) : (CSVP.objProps) (one of objProps types) an objProps, ... opjProps8 containing properties' values in a child objProps objects
maCount (int) : (int) Number of tgtObj's RsMaCalcParams childs of tgtObj to set (1 to 6, starting from 1)
Returns: this
method importConfig(this, oCfg, maCount)
Imports HTF MAs settings from objProps (of any level) into `HTFMAs` child `MaDrawing` objects (into the first first `maCount` of them)
Namespace types: HTFMAs
Parameters:
this (HTFMAs) : (HTFMAs) Target object to import prop values to.
oCfg (objProps2 type from moebius1977/CSVParser/1) : (CSVP.objProps) (one of objProps types) an objProps, ... opjProps8 containing properties' values in a child objProps objects
maCount (int) : (int) Number of tgtObj's RsMaCalcParams childs of tgtObj to set (1 to 6, starting from 1)
Returns: this
method importConfig(this, oCfg, maCount)
Imports HTF MAs settings from objProps (of any level) into `HTFMAs` child `MaDrawing` objects (into the first first `maCount` of them)
Namespace types: HTFMAs
Parameters:
this (HTFMAs) : (HTFMAs) Target object to import prop values to.
oCfg (objProps3 type from moebius1977/CSVParser/1) : (CSVP.objProps) (one of objProps types) an objProps, ... opjProps8 containing properties' values in a child objProps objects
maCount (int) : (int) Number of tgtObj's RsMaCalcParams childs of tgtObj to set (1 to 6, starting from 1)
Returns: this
method importConfig(this, oCfg, maCount)
Imports HTF MAs settings from objProps (of any level) into `HTFMAs` child `MaDrawing` objects (into the first first `maCount` of them)
Namespace types: HTFMAs
Parameters:
this (HTFMAs) : (HTFMAs) Target object to import prop values to.
oCfg (objProps4 type from moebius1977/CSVParser/1) : (CSVP.objProps) (one of objProps types) an objProps, ... opjProps8 containing properties' values in a child objProps objects
maCount (int) : (int) Number of tgtObj's RsMaCalcParams childs of tgtObj to set (1 to 6, starting from 1)
Returns: this
method importConfig(this, oCfg, maCount)
Imports HTF MAs settings from objProps (of any level) into `HTFMAs` child `MaDrawing` objects (into the first first `maCount` of them)
Namespace types: HTFMAs
Parameters:
this (HTFMAs) : (HTFMAs) Target object to import prop values to.
oCfg (objProps5 type from moebius1977/CSVParser/1) : (CSVP.objProps) (one of objProps types) an objProps, ... opjProps8 containing properties' values in a child objProps objects
maCount (int) : (int) Number of tgtObj's RsMaCalcParams childs of tgtObj to set (1 to 6, starting from 1)
Returns: this
method importConfig(this, oCfg, maCount)
Imports HTF MAs settings from objProps (of any level) into `HTFMAs` child `MaDrawing` objects (into the first first `maCount` of them)
Namespace types: HTFMAs
Parameters:
this (HTFMAs) : (HTFMAs) Target object to import prop values to.
oCfg (objProps6 type from moebius1977/CSVParser/1) : (CSVP.objProps) (one of objProps types) an objProps, ... opjProps8 containing properties' values in a child objProps objects
maCount (int) : (int) Number of tgtObj's RsMaCalcParams childs of tgtObj to set (1 to 6, starting from 1)
Returns: this
method importConfig(this, oCfg, maCount)
Namespace types: HTFMAs
Parameters:
this (HTFMAs)
oCfg (objProps7 type from moebius1977/CSVParser/1)
maCount (int)
method importConfig(this, oCfg, maCount)
Namespace types: HTFMAs
Parameters:
this (HTFMAs)
oCfg (objProps8 type from moebius1977/CSVParser/1)
maCount (int)
method newRsParamsMAs(this)
Namespace types: LO
Parameters:
this (LO)
method newHTFMAs(this)
Namespace types: LO
Parameters:
this (LO)
RsMaCalcParams
Parameters of one MA (only calculation params needed within req.sec(), visual parameters are within htfMAs type)
Fields:
enabled (series bool)
maType (series MaTypes) : MA type options: SMA / EMA / WMA / ...
src (series string)
prd (series int) : MA period
RsParamsMAs
Collection of parameters of 6 MAs. Used to pass params to req.sec()
Fields:
ma1CalcParams (RsMaCalcParams)
ma2CalcParams (RsMaCalcParams)
ma3CalcParams (RsMaCalcParams)
ma4CalcParams (RsMaCalcParams)
ma5CalcParams (RsMaCalcParams)
ma6CalcParams (RsMaCalcParams)
RsReturnMAs
Used to return data from req.sec().
Fields:
htfBi (series int)
ma1 (series float)
ma2 (series float)
ma3 (series float)
ma4 (series float)
ma5 (series float)
ma6 (series float)
MaDrawing
MA's plot parameters plus drawing objects for MA's current level (line and label).
Fields:
lnClr (series color) : (color) MA plot line color (like in plot())
lnWidth (series int) : (int) MA plot line width (like in plot())
lnStyle (series string) : (string) MA plot line style (like in plot())
showHistory (series bool) : (bool) Whether to plot the MA on historical bars or only show current level to the right of the latest bar.
showLabel (series bool) : (bool) Whether to show the name of the MA to the right of the MA's level
ln (series line) : (line) line to show MA"s current level
lbl (series label) : (label) label showing MA's name
HTFMAs
Contains data and drawing parameters for MA's of one timeframe (MA calculation parameters for MA's of one timeframe are in a separate object RsParamsMAs)
Fields:
rsRet (RsReturnMAs) : (RsReturnMAs) Contains data returned from req.sec(). Is set to na in between HTF bar changes if smoothing is enabled.
rsRetLast (RsReturnMAs) : (RsReturnMAs) Contains a copy of data returned from req.sec() in case rsRet is set to na for smoothing.
rsRetNaObj (RsReturnMAs) : (RsReturnMAs) An empty object as `na` placeholder
ma1Drawing (MaDrawing) : (MaDrawing) MA drawing properties
ma2Drawing (MaDrawing) : (MaDrawing) MA drawing properties
ma3Drawing (MaDrawing) : (MaDrawing) MA drawing properties
ma4Drawing (MaDrawing) : (MaDrawing) MA drawing properties
ma5Drawing (MaDrawing) : (MaDrawing) MA drawing properties
ma6Drawing (MaDrawing) : (MaDrawing) MA drawing properties
enabled (series bool) : (bool ) Enables/disables all of the MAs of one timeframe.
tf (series string) : (string) Timeframe
showHistory (series bool) : (bool ) Plot MA line on historical bars
rngAtrQ (series int) : (int ) A multiplier for atr(14). Determines a range within which the MA's will be plotted. MA's too far away will not be plotted.
showRecentBars (series int) : (int ) Only plot MA on these recent bars
smoothen (series bool) : (bool ) Smoothen MA plot. If false the same HTF value is returned on all chart bars within a HTF bar (intrabars), so the plot looks like steps.
lblsOffset (series int) : (int ) Show MA name this number of bars to the right off last bar.
lblsShow (series bool) : (bool ) Show MA name
lnOffset (series int) : (int ) Start line showing current level of the MA this number of bars to the right off the last bar.
lblSize (series string) : (string) Label size
lblStyle (series string) : (string) Label style
lblTxtAlign (series string) : (string) Label text align
bPopupLabel (series bool) : (bool ) Show current MA value as a tooltip to MA's name.
LO
LO Library object, whose only purpose is to serve as a shorthand for library name in script code.
Fields:
dummy (series string)
Realtime 5D Profile [LucF]█ OVERVIEW
This indicator displays a realtime profile that can be configured to visualize five dimensions: volume, price, time, activity and age. For each price level in a bar or timeframe, you can display total or delta volume or ticks. The tick count measures activity on a level. The thickness of each level's line indicates its age, which helps you identify the most recent levels.
█ WARNING
The indicator only works in real time. Contrary to TradingView's line of volume profile indicators , it does not show anything on historical bars or closed markets, and it cannot display volume information if none exists for the data feed the chart is using. A realtime indicator such as this one only displays information accumulated while it is running on a chart. The information it calculates cannot be saved on charts, nor can it be recalculated from historical bars. If you refresh the chart, or the script must re-execute for some reason, as when you change inputs, the accumulated information will be lost.
Because "Realtime 5D Profile" requires time to accumulate information on the chart, it will be most useful to traders working on small timeframes who trade only one instrument and do not frequently change their chart's symbol or timeframe. Traders working on higher timeframes or constantly changing charts will be better served by TradingView's volume profiles. Before using this indicator, please see the "Limitations" section further down for other important information.
█ HOW TO USE IT
Load the indicator on an active chart (see here if you don't know how).
The default configuration displays:
• A double-sided volume profile showing at what price levels activity has occurred.
• The left side shows "down" volume, the right side shows "up" volume.
• The value corresponding to each level is displayed.
• The width of lines reflects their relative value.
• The thickness of lines reflects their age. Four thicknesses are used, with the thicker lines being the most recent.
• The total value of down/up values for the profile appears at the top.
To understand how to use profiles in your trading, please research the subject. Searches on "volume profile" or "market profile" will yield many useful results. I provide you with tools — I do not teach trading. To understand more about this indicator, read on. If you choose not to do so, please don't ask me to answer questions that are already answered here, nor to make videos; I don't.
█ CONCEPTS
Delta calculations
Volume is slotted in up or down slots depending on whether the price of each new chart update is higher or lower than the previous update's price. When price does not move between chart updates, the last known direction is used. In a perfect world, Pine scripts would have access to bid and ask levels, as this would allow us to know for sure if market orders are being filled on upticks (at the ask) or downticks (at the bid). Comparing the price of successive chart updates provides the most precise way to calculate volume delta on TradingView, but it is still a compromise. Order books are in constant movement; in some cases, order cancellations can cause sudden movements of both the bid and ask levels such that the next chart update can occur on an uptick at a lower price than the previous one (or vice versa). While this update's volume should be slotted in the up slot because a buy market order was filled, it will erroneously be slotted in the down slot because the price of the chart's update is lower than that of the previous one. Luckily, these conditions are relatively rare, so they should not adversely affect calculations.
Levels
A profile is a tool that displays information organized by price levels. You can select the maximum quantity of levels this indicator displays by using the script's "Levels" input. If the profile's height is small enough for level increments to be less than the symbol's tick size, a smaller quantity of levels is used until the profile's height grows sufficiently to allow your specified quantity of levels to be displayed. The exact position of levels is not tethered to the symbol's tick increments. Activity for one level is that which happens on either side of the level, halfway between its higher or lower levels. The lowest/highest levels in the profile thus appear higher/lower than the profile's low/high limits, which are determined by the lowest/highest points reached by price during the profile's life.
Level Values and Length
The profile's vertical structure is dynamic. As the profile's height changes with the price range, it is rebalanced and the price points of its levels may be recalculated. When this happens, past updates will be redistributed among the new profile's levels, and the level values may thus change. The new levels where updates are slotted will of course always be near past ones, but keep this fluidity in mind when watching level values evolve.
The profile's horizontal structure is also dynamic. The maximum length of level lines is controlled by the "Maximum line length" input value. This maximum length is always used for the largest level value in the profile, and the length of other levels is determined by their value relative to that maximum.
Updates vs Ticks
Strictly speaking, a tick is the record of a transaction between two parties. On TradingView, these are detected on seconds charts. On other charts, ticks are aggregated to form a chart update . I use the broader "update" term when it names both events. Note that, confusingly, tick is also used to name an instrument's minimal price increment.
Volume Quality
If you use volume, it's important to understand its nature and quality, as it varies with sectors and instruments. My Volume X-ray indicator is one way you can appraise the quality of an instrument's intraday volume.
█ FEATURES
Double-Sided Profiles
When you choose one of the first two configuration selections in the "Configuration" field's dropdown menu, you are asking the indicator to display a double-sided profile, i.e., where the down values appear on the left and the up ones on the right. In this mode, the formatting options in the top section of inputs apply to both sides of the profile.
Single-Sided Profiles
The six other selections down the "Configuration" field's dropdown menu select single-sided profiles, where one side aggregates the up/down values for either volume or ticks. In this mode, the formatting options in the top section of inputs apply to the left profile. The ones in the following "Right format" section apply to the right profile.
Calculation Mode
The "Calculation" input field allows the selection of one of two modes which applies to single-sided profiles only. Values can represent the simple total of volume or ticks at each level, or their delta. The mode has no effect when a double-sided profile is used because then, the total is represented by the sum of the left and right sides. Note that when totals are selected, all levels appear in the up color.
Age
The age of each level is always displayed as one of four line thicknesses. Thicker lines are used for the youngest levels. The age of levels is determined by averaging the times of the updates composing that level. When viewing double-sided profiles, the age of each side is calculated independently, which entails you can have a down level on the left side of the profile appear thinner than its corresponding up side level line on the right side because the updates composing the up side are more recent. When calculating the age of single-sided profiles, the age of the up/down values aggregated to calculate the side are averaged. Since they may be different, the averaged level ages will not be as responsive as when using a double-sided profile configuration, where the age of levels on each side is calculated independently and follows price action more closely. Moreover, when displaying two single-sided profiles (volume on one side and ticks on the other), the age of both sides will match because they are calculated from the same realtime updates.
Profile Resets
The profile can reset on timeframes or trend changes. The usual timeframe selections are available, including the chart's, in which case the profile will reset on each new chart bar. One of two trend detection logics can be used: Supertrend or the one used by LazyBear in his Weis Wave indicator . Settings for the trend logics are in the bottommost section of the inputs, where you can also control the display of trend changes and states. Note that the "Timeframe" field's setting also applies to the trend detection mechanism. Whatever the timeframe used for trend detection, its logic will not repaint.
Format
Formatting a profile for charts is often a challenge for traders, and this one is no exception. Varying zoom factors on your chart and the frequency of profile resets will require different profile formats. You can achieve a reasonable variety of effects by playing with the following input fields:
• "Resets on" controls how frequently new profiles are drawn. Spacing out profiles between bars can help make them more usable.
• "Levels" determines the maximum quantity of levels displayed.
• "Offset" allows you to shift the profile horizontally.
• "Profile size" affects the global size of the profile.
• Another "Size" field provides control over the size of the totals displayed above the profile.
• "Maximum line length" controls how far away from the center of the bar the lines will stretch left and right.
Colors
The color and brightness of levels and totals always allows you to determine the winning side between up and down values. On double-sided profiles, each side is always of one color, since the left side is down values and the right side, up values. However, the losing side is colored with half its brightness, so the emphasis is put on the winning side. When there is no winner, the toned-down version of each color is used for both sides. Single-sided profiles use the up and down colors in full brightness on the same side. Which one is used reflects the winning side.
Candles
The indicator can color candle bodies and borders independently. If you choose to do so, you may want to disable the chart's bars by using the eye icon near the symbol's name.
Tooltips
A tooltip showing the value of each level is available. If they do not appear when hovering over levels, select the indicator by clicking on its chart name. This should get the tooltips working.
Data Window
As usual, I provide key values in the Data Window, so you can track them. If you compare total realtime volumes for the profile and the built-in "Volume" indicator, you may see variations at some points. They are due to the different mechanisms running each program. In my experience, the values from the built-in don't always update as often as those of the profile, but they eventually catch up.
█ LIMITATIONS
• The levels do not appear exactly at the position they are calculated. They are positioned slightly lower than their actual price levels.
• Drawing a 20-level double-sided profile with totals requires 42 labels. The script will only display the last 500 labels,
so the number of levels you choose affects how many past profiles will remain visible.
• The script is quite taxing, which will sometimes make the chart's tab less responsive.
• When you first load the indicator on a chart, it will begin calculating from that moment; it will not take into account prior chart activity.
• If you let the script run long enough when using profile reset criteria that make profiles last for a long time, the script will eventually run out of memory,
as it will be tracking unmanageable amounts of chart updates. I don't know the exact quantity of updates that will cause this,
but the script can handle upwards of 60K updates per profile, which should last 1D except on the most active markets. You can follow the number of updates in the Data Window.
• The indicator's nature makes it more useful at very small timeframes, typically in the sub 15min realm.
• The Weis Wave trend detection used here has nothing to do with how David Weis detects trend changes.
LazyBear's version was a port of a port, so we are a few generations removed from the Weis technique, which uses reversals by a price unit.
I believe the version used here is useful nonetheless because it complements Supertrend rather well.
█ NOTES
The aggregated view that volume and tick profiles calculate for traders is a good example of one of the most useful things software can do for traders: look at things from a methodical, mathematical perspective, and present results in a meaningful way. Profiles are powerful because, if the volume data they use is of good enough quality, they tell us what levels are important for traders, regardless of the nature or rationality of the methods traders have used to determine those levels. Profiles don't care whether traders use the news, fundamentals, Fib numbers, pivots, or the phases of the moon to find "their" levels. They don't attempt to forecast or explain markets. They show us real stuff containing zero uncertainty, i.e., what HAS happened. I like this.
The indicator's "VPAA" chart name represents four of the five dimensions the indicator displays: volume, price, activity and age. The time dimension is implied by the fact it's a profile — and I couldn't find a proper place for a "T" in there )
I have not included alerts in the script. I may do so in the future.
For the moment, I have no plans to write a profile indicator that works on historical bars. TradingView's volume profiles already do that, and they run much faster than Pine versions could, so I don't see the point in spending efforts on a poor ersatz.
For Pine Coders
• The script uses labels that draw varying quantities of characters to break the limitation constraining other Pine plots/lines to bar boundaries.
• The code's structure was optimized for performance. When it was feasible, global arrays, "input" and other variables were used from functions,
sacrificing function readability and portability for speed. Code was also repeated in some places, to avoid the overhead of frequent function calls in high-traffic areas.
• I wrote my script using the revised recommendations in the Style Guide from the Pine v5 User Manual.
█ THANKS
• To Duyck for his function that sorts an array while keeping it in synch with another array.
The `sortTwoArrays()` function in my script is derived from the Pine Wizard 's code.
• To the one and only Maestro, RicardoSantos , the creative volcano who worked hard to write a function to produce fixed-width, figure space-padded numeric values.
A change in design made the function unnecessary in this script, but I am grateful to you nonetheless.
• To midtownskr8guy , another Pine Wizard who is also a wizard with colors. I use the colors from his Pine Color Magic and Chart Theme Simulator constantly.
• Finally, thanks to users of my earlier "Delta Volume" scripts. Comments and discussions with them encouraged me to persist in figuring out how to achieve what this indicator does.
LEGEND IsoPulse Fusion Universal Volume Trend Buy Sell RadarLEGEND IsoPulse Fusion • Universal Volume Trend Buy Sell Radar
One line summary
LEGEND IsoPulse Fusion reads intent from price and volume together, learns which features matter most on your symbol, blends them into a single signed Fusion line in a stable unit range, and emits clear Buy Sell Close events with a structure gate and a liquidity safety gate so you act only when the tape is favorable.
What this script is and why it exists
Many traders keep separate windows for trend, volume, volatility, and regime filters. The result can feel fragmented. This script merges two complementary engines into one consistent view that is easy to read and simple to act on.
LEGEND Tensor estimates directional quality from five causally computed features that are normalized for stationarity. The features are Flow, Tail Pressure with Volume Mix, Path Curvature, Streak Persistence, and Entropy Order.
IsoPulse transforms raw volume into two decaying reservoirs for buy effort and sell effort using body location and wick geometry, then measures price travel per unit volume for efficiency, and detects volume bursts with a recency memory.
Both engines are mapped into the same unit range and fused by a regime aware mixer. When the tape is orderly the mixer leans toward trend features. When the tape is messy but a true push appears in volume efficiency with bursts the mixer allows IsoPulse to speak louder. The outcome is a single Fusion line that lives in a familiar range with calm behavior in quiet periods and expressive pushes when energy concentrates.
What makes it original and useful
Two reservoir volume split . The script assigns a portion of the bar volume to up effort and down effort using body location and wick geometry together. Effort decays through time using a forgetting factor so memory is present without becoming sticky.
Efficiency of move . Price travel per unit volume is often more informative than raw volume or raw range. The script normalizes both sides and centers the efficiency so it becomes signed fuel when multiplied by flow skew.
Burst detection with recency memory . Percent rank of volume highlights bursts. An exponential memory of how recently bursts clustered converts isolated blips into useful context.
Causal adaptive weighting . The LEGEND features do not receive static weights. The script learns, causally, which features have correlated with future returns on your symbol over a rolling window. Only positive contributions are allowed and weights are normalized for interpretability.
Regime aware fusion . Entropy based order and persistence create a mixer that blends IsoPulse with LEGEND. You see a single line rather than two competing panels, which reduces decision conflict.
How to read the screen in seconds
Fusion area . The pane fills above and below zero with a soft gradient. Deeper fill means stronger conviction. The white Fusion line sits on top for precise crossings.
Entry guides and exit guides . Two entry guides draw symmetrically at the active fused entry level. Two exit guides sit inside at a fraction of the entry. Think of them as an adaptive envelope.
Letters . B prints once when the script flips from flat to long. S prints once when the script flips from flat to short. C prints when a held position ends on the appropriate side. T prints when the structure gate first opens. A prints when the liquidity safety flag first appears.
Price bar paint . Bars tint green while long and red while short on the chart to mirror your virtual position.
HUD . A compact dashboard in the corner shows Fusion, IsoPulse, LEGEND, active entry and exit levels, regime status, current virtual position, and the vacuum z value with its avoid threshold.
What signals actually mean
Buy . A Buy prints when the Fusion line crosses above the active entry level while gates are open and the previous state was flat.
Sell . A Sell prints when the Fusion line crosses below the negative entry level while gates are open and the previous state was flat.
Close . A Close prints when Fusion cools back inside the exit envelope or when an opposite cross would occur or when a gate forces a stop, and the previous state was a hold.
Gates . The Trend gate requires sufficient entropy order or significant persistence. The Avoid gate uses a liquidity vacuum z score. Gates exist to protect you from weak tape and poor liquidity.
Inputs and practical tuning
Every input has a tooltip in the script. This section provides a concise reference that you can keep in mind while you work.
Setup
Core window . Controls statistics across features. Scalping often prefers the thirties or low fifties. Intraday often prefers the fifties to eighties. Swing often prefers the eighties to low hundreds. Smaller responds faster with more noise. Larger is calmer.
Smoothing . Short EMA on noisy features. A small value catches micro shifts. A larger value reduces whipsaw.
Fusion and thresholds
Weight lookback . Sample size for weight learning. Use at least five times the horizon. Larger is slower and more confident. Smaller is nimble and more reactive.
Weight horizon . How far ahead return is measured to assess feature value. Smaller favors quick reversion impulses. Larger favors continuation.
Adaptive thresholds . Entry and exit levels from rolling percentiles of the absolute LEGEND score. This self scales across assets and timeframes.
Entry percentile . Eighty selects the top quintile of pushes. Lower to seventy five for more signals. Raise for cleanliness.
Exit percentile . Mid fifties keeps trades honest without overstaying. Sixty holds longer with wider give back.
Order threshold . Minimum structure to trade. Zero point fifteen is a reasonable start. Lower to trade more. Raise to filter chop.
Avoid if Vac z . Liquidity safety level. One point two five is a good default on liquid markets. Thin markets may prefer a slightly higher setting to avoid permanent avoid mode.
IsoPulse
Iso forgetting per bar . Memory for the two reservoirs. Values near zero point nine eight to zero point nine nine five work across many symbols.
Wick weight in effort split . Balance between body location and wick geometry. Values near zero point three to zero point six capture useful behavior.
Efficiency window . Travel per volume window. Lower for snappy symbols. Higher for stability.
Burst percent rank window . Window for percent rank of volume. Around one hundred to three hundred covers most use cases.
Burst recency half life . How long burst clusters matter. Lower for quick fades. Higher for cluster memory.
IsoPulse gain . Pre compression gain before the atan mapping. Tune until the Fusion line lives inside a calm band most of the time with expressive spikes on true pushes.
Continuation and Reversal guides . Visual rails for IsoPulse that help you sense continuation or exhaustion zones. They do not force events.
Entry sensitivity and exit fraction
Entry sensitivity . Loose multiplies the fused entry level by a smaller factor which prints more trades. Strict multiplies by a larger factor which selects fewer and cleaner trades. Balanced is neutral.
Exit fraction . Exit level relative to the entry level in fused unit space. Values around one half to two thirds fit most symbols.
Visuals and UX
Columns and line . Use both to see context and precise crossings. If you present a very clean chart you can turn columns off and keep the line.
HUD . Keep it on while you learn the script. It teaches you how the gates and thresholds respond to your market.
Letters . B S C T A are informative and compact. For screenshots you can toggle them off.
Debug triggers . Show raw crosses even when gates block entries. This is useful when you tune the gates. Turn them off for normal use.
Quick start recipes
Scalping one to five minutes
Core window in the thirties to low fifties.
Horizon around five to eight.
Entry percentile around seventy five.
Exit fraction around zero point five five.
Order threshold around zero point one zero.
Avoid level around one point three zero.
Tune IsoPulse gain until normal Fusion sits inside a calm band and true squeezes push outside.
Intraday five to thirty minutes
Core window around fifty to eighty.
Horizon around ten to twelve.
Entry percentile around eighty.
Exit fraction around zero point five five to zero point six zero.
Order threshold around zero point one five.
Avoid level around one point two five.
Swing one hour to daily
Core window around eighty to one hundred twenty.
Horizon around twelve to twenty.
Entry percentile around eighty to eighty five.
Exit fraction around zero point six zero to zero point seven zero.
Order threshold around zero point two zero.
Avoid level around one point two zero.
How to connect signals to your risk plan
This is an indicator. You remain in control of orders and risk.
Stops . A simple choice is an ATR multiple measured on your chart timeframe. Intraday often prefers one point two five to one point five ATR. Swing often prefers one point five to two ATR. Adjust to symbol behavior and personal risk tolerance.
Exits . The script already prints a Close when Fusion cools inside the exit envelope. If you prefer targets you can mirror the entry envelope distance and convert that to points or percent in your own plan.
Position size . Fixed fractional or fixed risk per trade remains a sound baseline. One percent or less per trade is a common starting point for testing.
Sessions and news . Even with self scaling, some traders prefer to skip the first minutes after an open or scheduled news. Gate with your own session logic if needed.
Limitations and honest notes
No look ahead . The script is causal. The adaptive learner uses a shifted correlation, crosses are evaluated without peeking into the future, and no lookahead security calls are used. If you enable intrabar calculations a letter may appear then disappear before the close if the condition fails. This is normal for any cross based logic in real time.
No performance promises . Markets change. This is a decision aid, not a prediction machine. It will not win every sequence and it cannot guarantee statistical outcomes.
No dependence on other indicators . The chart should remain clean. You can add personal tools in private use but publications should keep the example chart readable.
Standard candles only for public signals . Non standard chart types can change event timing and produce unrealistic sequences. Use regular candles for demonstrations and publications.
Internal logic walkthrough
LEGEND feature block
Flow . Current return normalized by ATR then smoothed by a short EMA. This gives directional intent scaled to recent volatility.
Tail pressure with volume mix . The relative sizes of upper and lower wicks inside the high to low range produce a tail asymmetry. A volume based mix can emphasize wick information when volume is meaningful.
Path curvature . Second difference of close normalized by ATR and smoothed. This captures changes in impulse shape that can precede pushes or fades.
Streak persistence . Up and down close streaks are counted and netted. The result is normalized for the window length to keep behavior stable across symbols.
Entropy order . Shannon entropy of the probability of an up close. Lower entropy means more order. The value is oriented by Flow to preserve sign.
Causal weights . Each feature becomes a z score. A shifted correlation against future returns over the horizon produces a positive weight per feature. Weights are normalized so they sum to one for clarity. The result is angle mapped into a compact unit.
IsoPulse block
Effort split . The script estimates up effort and down effort per bar using both body location and wick geometry. Effort is integrated through time into two reservoirs using a forgetting factor.
Skew . The reservoir difference over the sum yields a stable skew in a known range. A short EMA smooths it.
Efficiency . Move size divided by average volume produces travel per unit volume. Normalization and centering around zero produce a symmetric measure.
Bursts and recency . Percent rank of volume highlights bursts. An exponential function of bars since last burst adds the notion of cluster memory.
IsoPulse unit . Skew multiplied by centered efficiency then scaled by the burst factor produces the raw IsoPulse that is angle mapped into the unit range.
Fusion and events
Regime factor . Entropy order and streak persistence form a mixer. Low structure favors IsoPulse. Higher structure favors LEGEND. The blend is convex so it remains interpretable.
Blended guides . Entry and exit guides are blended in the same way as the line so they stay consistent when regimes change. The envelope does not jump unexpectedly.
Virtual position . The script maintains state. Buy and Sell require a cross while flat and gates open. Close requires an exit or force condition while holding. Letters print once at the state change.
Disclosures
This script and description are educational. They do not constitute investment advice. Markets involve risk. You are responsible for your own decisions and for compliance with local rules. The logic is causal and does not look ahead. Signals on non standard chart types can be misleading and are not recommended for publication. When you test a strategy wrapper, use realistic commission and slippage, moderate risk per trade, and enough trades to form a meaningful sample, then document those assumptions if you share results.
Closing thoughts
Clarity builds confidence. The Fusion line gives a single view of intent. The letters communicate action without clutter. The HUD confirms context at a glance. The gates protect you from weak tape and poor liquidity. Tune it to your instrument, observe it across regimes, and use it as a consistent lens rather than a prediction oracle. The goal is not to trade every wiggle. The goal is to pick your spots with a calm process and to stand aside when the tape is not inviting.
Luxy Momentum, Trend, Bias and Breakout Indicators V7
TABLE OF CONTENTS
This is Version 7 (V7) - the latest and most optimized release. If you are using any older versions (V6, V5, V4, V3, etc.), it is highly recommended to replace them with V7.
Why This Indicator is Different
Who Should Use This
Core Components Overview
The UT Bot Trading System
Understanding the Market Bias Table
Candlestick Pattern Recognition
Visual Tools and Features
How to Use the Indicator
Performance and Optimization
FAQ
---
### CREDITS & ATTRIBUTION
This indicator implements proven trading concepts using entirely original code developed specifically for this project.
### CONCEPTUAL FOUNDATIONS
• UT Bot ATR Trailing System
- Original concept by @QuantNomad: (search "UT-Bot-Strategy"
- Our version is a complete reimplementation with significant enhancements:
- Volume-weighted momentum adjustment
- Composite stop loss from multiple S/R layers
- Multi-filter confirmation system (swing, %, 2-bar, ZLSMA)
- Full integration with multi-timeframe bias table
- Visual audit trail with freeze-on-touch
- NOTE: No code was copied - this is a complete reimplementation with enhancements.
• Standard Technical Indicators (Public Domain Formulas):
- Supertrend: ATR-based trend calculation with custom gradient fills
- MACD: Gerald Appel's formula with separation filters
- RSI: J. Welles Wilder's formula with pullback zone logic
- ADX/DMI: Custom trend strength formula inspired by Wilder's directional movement concept, reimplemented with volume weighting and efficiency metrics
- ZLSMA: Zero-lag formula enhanced with Hull MA and momentum prediction
### Custom Implementations
- Trend Strength: Inspired by Wilder's ADX concept but using volume-weighted pressure calculation and efficiency metrics (not traditional +DI/-DI smoothing)
- All code implementations are original
### ORIGINAL FEATURES (70%+ of codebase)
- Multi-Timeframe Bias Table with live updates
- Risk Management System (R-multiple TPs, freeze-on-touch)
- Opening Range Breakout tracker with session management
- Composite Stop Loss calculator using 6+ S/R layers
- Performance optimization system (caching, conditional calcs)
- VIX Fear Index integration
- Previous Day High/Low auto-detection
- Candlestick pattern recognition with interactive tooltips
- Smart label and visual management
- All UI/UX design and table architecture
### DEVELOPMENT PROCESS
**AI Assistance:** This indicator was developed over 2+ months with AI assistance (ChatGPT/Claude) used for:
- Writing Pine Script code based on design specifications
- Optimizing performance and fixing bugs
- Ensuring Pine Script v6 compliance
- Generating documentation
**Author's Role:** All trading concepts, system design, feature selection, integration logic, and strategic decisions are original work by the author. The AI was a coding tool, not the system designer.
**Transparency:** We believe in full disclosure - this project demonstrates how AI can be used as a powerful development tool while maintaining creative and strategic ownership.
---
1. WHY THIS INDICATOR IS DIFFERENT
Most traders use multiple separate indicators on their charts, leading to cluttered screens, conflicting signals, and analysis paralysis. The Suite solves this by integrating proven technical tools into a single, cohesive system.
Key Advantages:
All-in-One Design: Instead of loading 5-10 separate indicators, you get everything in one optimized script. This reduces chart clutter and improves TradingView performance.
Multi-Timeframe Bias Table: Unlike standard indicators that only show the current timeframe, the Bias Table aggregates trend signals across multiple timeframes simultaneously. See at a glance whether 1m, 5m, 15m, 1h are aligned bullish or bearish - no more switching between charts.
Smart Confirmations: The indicator doesn't just give signals - it shows you WHY. Every entry has multiple layers of confirmation (MA cross, MACD momentum, ADX strength, RSI pullback, volume, etc.) that you can toggle on/off.
Dynamic Stop Loss System: Instead of static ATR stops, the SL is calculated from multiple support/resistance layers: UT trailing line, Supertrend, VWAP, swing structure, and MA levels. This creates more intelligent, price-action-aware stops.
R-Multiple Take Profits: Built-in TP system calculates targets based on your initial risk (1R, 1.5R, 2R, 3R). Lines freeze when touched with visual checkmarks, giving you a clean audit trail of partial exits.
Educational Tooltips Everywhere: Every single input has detailed tooltips explaining what it does, typical values, and how it impacts trading. You're not guessing - you're learning as you configure.
Performance Optimized: Smart caching, conditional calculations, and modular design mean the indicator runs fast despite having 15+ features. Turn off what you don't use for even better performance.
No Repainting: All signals respect bar close. Alerts fire correctly. What you see in history is what you would have gotten in real-time.
What Makes It Unique:
Integrated UT Bot + Bias Table: No other indicator combines UT Bot's ATR trailing system with a live multi-timeframe dashboard. You get precision entries with macro trend context.
Candlestick Pattern Recognition with Interactive Tooltips: Patterns aren't just marked - hover over any emoji for a full explanation of what the pattern means and how to trade it.
Opening Range Breakout Tracker: Built-in ORB system for intraday traders with customizable session times and real-time status updates in the Bias Table.
Previous Day High/Low Auto-Detection: Automatically plots PDH/PDL on intraday charts with theme-aware colors. Updates daily without manual input.
Dynamic Row Labels in Bias Table: The table shows your actual settings (e.g., "EMA 10 > SMA 20") not generic labels. You know exactly what's being evaluated.
Modular Filter System: Instead of forcing a fixed methodology, the indicator lets you build your own strategy. Start with just UT Bot, add filters one at a time, test what works for your style.
---
2. WHO WHOULD USE THIS
Designed For:
Intermediate to Advanced Traders: You understand basic technical analysis (MAs, RSI, MACD) and want to combine multiple confirmations efficiently. This isn't a "one-click profit" system - it's a professional toolkit.
Multi-Timeframe Traders: If you trade one asset but check multiple timeframes for confirmation (e.g., enter on 5m after checking 15m and 1h alignment), the Bias Table will save you hours every week.
Trend Followers: The indicator excels at identifying and following trends using UT Bot, Supertrend, and MA systems. If you trade breakouts and pullbacks in trending markets, this is built for you.
Intraday and Swing Traders: Works equally well on 5m-1h charts (day trading) and 4h-D charts (swing trading). Scalpers can use it too with appropriate settings adjustments.
Discretionary Traders: This isn't a black-box system. You see all the components, understand the logic, and make final decisions. Perfect for traders who want tools, not automation.
Works Across All Markets:
Stocks (US, international)
Cryptocurrency (24/7 markets supported)
Forex pairs
Indices (SPY, QQQ, etc.)
Commodities
NOT Ideal For :
Complete Beginners: If you don't know what a moving average or RSI is, start with basics first. This indicator assumes foundational knowledge.
Algo Traders Seeking Black Box: This is discretionary. Signals require context and confirmation. Not suitable for blind automated execution.
Mean-Reversion Only Traders: The indicator is trend-following at its core. While VWAP bands support mean-reversion, the primary methodology is trend continuation.
---
3. CORE COMPONENTS OVERVIEW
The indicator combines these proven systems:
Trend Analysis:
Moving Averages: Four customizable MAs (Fast, Medium, Medium-Long, Long) with six types to choose from (EMA, SMA, WMA, VWMA, RMA, HMA). Mix and match for your style.
Supertrend: ATR-based trend indicator with unique gradient fill showing trend strength. One-sided ribbon visualization makes it easier to see momentum building or fading.
ZLSMA : Zero-lag linear-regression smoothed moving average. Reduces lag compared to traditional MAs while maintaining smooth curves.
Momentum & Filters:
MACD: Standard MACD with separation filter to avoid weak crossovers.
RSI: Pullback zone detection - only enter longs when RSI is in your defined "buy zone" and shorts in "sell zone".
ADX/DMI: Trend strength measurement with directional filter. Ensures you only trade when there's actual momentum.
Volume Filter: Relative volume confirmation - require above-average volume for entries.
Donchian Breakout: Optional channel breakout requirement.
Signal Systems:
UT Bot: The primary signal generator. ATR trailing stop that adapts to volatility and gives clear entry/exit points.
Base Signals: MA cross system with all the above filters applied. More conservative than UT Bot alone.
Market Bias Table: Multi-timeframe dashboard showing trend alignment across 7 timeframes plus macro bias (3-day, weekly, monthly, quarterly, VIX).
Candlestick Patterns: Six major reversal patterns auto-detected with interactive tooltips.
ORB Tracker: Opening range high/low with breakout status (intraday only).
PDH/PDL: Previous day levels plotted automatically on intraday charts.
VWAP + Bands : Session-anchored VWAP with up to three standard deviation band pairs.
---
4. THE UT BOT TRADING SYSTEM
The UT Bot is the heart of the indicator's signal generation. It's an advanced ATR trailing stop that adapts to market volatility.
Why UT Bot is Superior to Fixed Stops:
Traditional ATR stops use a fixed multiplier (e.g., "stop = entry - 2×ATR"). UT Bot is smarter:
It TRAILS the stop as price moves in your favor
It WIDENS during high volatility to avoid premature stops
It TIGHTENS during consolidation to lock in profits
It FLIPS when price breaks the trailing line, signaling reversals
Visual Elements You'll See:
Orange Trailing Line: The actual UT stop level that adapts bar-by-bar
Buy/Sell Labels: Aqua triangle (long) or orange triangle (short) when the line flips
ENTRY Line: Horizontal line at your entry price (optional, can be turned off)
Suggested Stop Loss: A composite SL calculated from multiple support/resistance layers:
- UT trailing line
- Supertrend level
- VWAP
- Swing structure (recent lows/highs)
- Long-term MA (200)
- ATR-based floor
Take Profit Lines: TP1, TP1.5, TP2, TP3 based on R-multiples. When price touches a TP, it's marked with a checkmark and the line freezes for audit trail purposes.
Status Messages: "SL Touched ❌" or "SL Frozen" when the trade leg completes.
How UT Bot Differs from Other ATR Systems:
Multiple Filters Available: You can require 2-bar confirmation, minimum % price change, swing structure alignment, or ZLSMA directional filter. Most UT implementations have none of these.
Smart SL Calculation: Instead of just using the UT line as your stop, the indicator suggests a better SL based on actual support/resistance. This prevents getting stopped out by wicks while keeping risk controlled.
Visual Audit Trail: All SL/TP lines freeze when touched with clear markers. You can review your trades weeks later and see exactly where entries, stops, and targets were.
Performance Options: "Draw UT visuals only on bar close" lets you reduce rendering load without affecting logic or alerts - critical for slower machines or 1m charts.
Trading Logic:
UT Bot flips direction (Buy or Sell signal appears)
Check Bias Table for multi-timeframe confirmation
Optional: Wait for Base signal or candlestick pattern
Enter at signal bar close or next bar open
Place stop at "Suggested Stop Loss" line
Scale out at TP levels (TP1, TP2, TP3)
Exit remaining position on opposite UT signal or stop hit
---
5. UNDERSTANDING THE MARKET BIAS TABLE
This is the indicator's unique multi-timeframe intelligence layer. Instead of looking at one chart at a time, the table aggregates signals across seven timeframes plus macro trend bias.
Why Multi-Timeframe Analysis Matters:
Professional traders check higher and lower timeframes for context:
Is the 1h uptrend aligning with my 5m entry?
Are all short-term timeframes bullish or just one?
Is the daily trend supportive or fighting me?
Doing this manually means opening multiple charts, checking each indicator, and making mental notes. The Bias Table does it automatically in one glance.
Table Structure:
Header Row:
On intraday charts: 1m, 5m, 15m, 30m, 1h, 2h, 4h (toggle which ones you want)
On daily+ charts: D, W, M (automatic)
Green dot next to title = live updating
Headline Rows - Macro Bias:
These show broad market direction over longer periods:
3 Day Bias: Trend over last 3 trading sessions (uses 1h data)
Weekly Bias: Trend over last 5 trading sessions (uses 4h data)
Monthly Bias: Trend over last 30 daily bars
Quarterly Bias: Trend over last 13 weekly bars
VIX Fear Index: Market regime based on VIX level - bullish when low, bearish when high
Opening Range Breakout: Status of price vs. session open range (intraday only)
These rows show text: "BULLISH", "BEARISH", or "NEUTRAL"
Indicator Rows - Technical Signals:
These evaluate your configured indicators across all active timeframes:
Fast MA > Medium MA (shows your actual MA settings, e.g., "EMA 10 > SMA 20")
Price > Long MA (e.g., "Price > SMA 200")
Price > VWAP
MACD > Signal
Supertrend (up/down/neutral)
ZLSMA Rising
RSI In Zone
ADX ≥ Minimum
These rows show emojis: GREEB (bullish), RED (bearish), GRAY/YELLOW (neutral/NA)
AVG Column:
Shows percentage of active timeframes that are bullish for that row. This is the KEY metric:
AVG > 70% = strong multi-timeframe bullish alignment
AVG 40-60% = mixed/choppy, no clear trend
AVG < 30% = strong multi-timeframe bearish alignment
How to Use the Table:
For a long trade:
Check AVG column - want to see > 60% ideally
Check headline bias rows - want to see BULLISH, not BEARISH
Check VIX row - bullish market regime preferred
Check ORB row (intraday) - want ABOVE for longs
Scan indicator rows - more green = better confirmation
For a short trade:
Check AVG column - want to see < 40% ideally
Check headline bias rows - want to see BEARISH, not BULLISH
Check VIX row - bearish market regime preferred
Check ORB row (intraday) - want BELOW for shorts
Scan indicator rows - more red = better confirmation
When AVG is 40-60%:
Market is choppy, mixed signals. Either stay out or reduce position size significantly. These are low-probability environments.
Unique Features:
Dynamic Labels: Row names show your actual settings (e.g., "EMA 10 > SMA 20" not generic "Fast > Slow"). You know exactly what's being evaluated.
Customizable Rows: Turn off rows you don't care about. Only show what matters to your strategy.
Customizable Timeframes: On intraday charts, disable 1m or 4h if you don't trade them. Reduces calculation load by 20-40%.
Automatic HTF Handling: On Daily/Weekly/Monthly charts, the table automatically switches to D/W/M columns. No configuration needed.
Performance Smart: "Hide BIAS table on 1D or above" option completely skips all table calculations on higher timeframes if you only trade intraday.
---
6. CANDLESTICK PATTERN RECOGNITION
The indicator automatically detects six major reversal patterns and marks them with emojis at the relevant bars.
Why These Six Patterns:
These are the most statistically significant reversal patterns according to trading literature:
High win rate when appearing at support/resistance
Clear visual structure (not subjective)
Work across all timeframes and assets
Studied extensively by institutions
The Patterns:
Bullish Patterns (appear at bottoms):
Bullish Engulfing: Green candle completely engulfs prior red candle's body. Strong reversal signal.
Hammer: Small body with long lower wick (at least 2× body size). Shows rejection of lower prices by buyers.
Morning Star: Three-candle pattern (large red → small indecision → large green). Very strong bottom reversal.
Bearish Patterns (appear at tops):
Bearish Engulfing: Red candle completely engulfs prior green candle's body. Strong reversal signal.
Shooting Star: Small body with long upper wick (at least 2× body size). Shows rejection of higher prices by sellers.
Evening Star: Three-candle pattern (large green → small indecision → large red). Very strong top reversal.
Interactive Tooltips:
Unlike most pattern indicators that just draw shapes, this one is educational:
Hover your mouse over any pattern emoji
A tooltip appears explaining: what the pattern is, what it means, when it's most reliable, and how to trade it
No need to memorize - learn as you trade
Noise Filter:
"Min candle body % to filter noise" setting prevents false signals:
Patterns require minimum body size relative to price
Filters out tiny candles that don't represent real buying/selling pressure
Adjust based on asset volatility (higher % for crypto, lower for low-volatility stocks)
How to Trade Patterns:
Patterns are NOT standalone entry signals. Use them as:
Confirmation: UT Bot gives signal + pattern appears = stronger entry
Reversal Warning: In a trade, opposite pattern appears = consider tightening stop or taking profit
Support/Resistance Validation: Pattern at key level (PDH, VWAP, MA 200) = level is being respected
Best combined with:
UT Bot or Base signal in same direction
Bias Table alignment (AVG > 60% or < 40%)
Appearance at obvious support/resistance
---
7. VISUAL TOOLS AND FEATURES
VWAP (Volume Weighted Average Price):
Session-anchored VWAP with standard deviation bands. Shows institutional "fair value" for the trading session.
Anchor Options: Session, Day, Week, Month, Quarter, Year. Choose based on your trading timeframe.
Bands: Up to three pairs (X1, X2, X3) showing statistical deviation. Price at outer bands often reverses.
Auto-Hide on HTF: VWAP hides on Daily/Weekly/Monthly charts automatically unless you enable anchored mode.
Use VWAP as:
Directional bias (above = bullish, below = bearish)
Mean reversion levels (outer bands)
Support/resistance (the VWAP line itself)
Previous Day High/Low:
Automatically plots yesterday's high and low on intraday charts:
Updates at start of each new trading day
Theme-aware colors (dark text for light charts, light text for dark charts)
Hidden automatically on Daily/Weekly/Monthly charts
These levels are critical for intraday traders - institutions watch them closely as support/resistance.
Opening Range Breakout (ORB):
Tracks the high/low of the first 5, 15, 30, or 60 minutes of the trading session:
Customizable session times (preset for NYSE, LSE, TSE, or custom)
Shows current breakout status in Bias Table row (ABOVE, BELOW, INSIDE, BUILDING)
Intraday only - auto-disabled on Daily+ charts
ORB is a classic day trading strategy - breakout above opening range often leads to continuation.
Extra Labels:
Change from Open %: Shows how far price has moved from session open (intraday) or daily open (HTF). Green if positive, red if negative.
ADX Badge: Small label at bottom of last bar showing current ADX value. Green when above your minimum threshold, red when below.
RSI Badge: Small label at top of last bar showing current RSI value with zone status (buy zone, sell zone, or neutral).
These labels provide quick at-a-glance confirmation without needing separate indicator windows.
---
8. HOW TO USE THE INDICATOR
Step 1: Add to Chart
Load the indicator on your chosen asset and timeframe
First time: Everything is enabled by default - the chart will look busy
Don't panic - you'll turn off what you don't need
Step 2: Start Simple
Turn OFF everything except:
UT Bot labels (keep these ON)
Bias Table (keep this ON)
Moving Averages (Fast and Medium only)
Suggested Stop Loss and Take Profits
Hide everything else initially. Get comfortable with the basic UT Bot + Bias Table workflow first.
Step 3: Learn the Core Workflow
UT Bot gives a Buy or Sell signal
Check Bias Table AVG column - do you have multi-timeframe alignment?
If yes, enter the trade
Place stop at Suggested Stop Loss line
Scale out at TP levels
Exit on opposite UT signal
Trade this simple system for a week. Get a feel for signal frequency and win rate with your settings.
Step 4: Add Filters Gradually
If you're getting too many losing signals (whipsaws in choppy markets), add filters one at a time:
Try: "Require 2-Bar Trend Confirmation" - wait for 2 bars to confirm direction
Try: ADX filter with minimum threshold - only trade when trend strength is sufficient
Try: RSI pullback filter - only enter on pullbacks, not chasing
Try: Volume filter - require above-average volume
Add one filter, test for a week, evaluate. Repeat.
Step 5: Enable Advanced Features (Optional)
Once you're profitable with the core system, add:
Supertrend for additional trend confirmation
Candlestick patterns for reversal warnings
VWAP for institutional anchor reference
ORB for intraday breakout context
ZLSMA for low-lag trend following
Step 6: Optimize Settings
Every setting has a detailed tooltip explaining what it does and typical values. Hover over any input to read:
What the parameter controls
How it impacts trading
Suggested ranges for scalping, day trading, and swing trading
Start with defaults, then adjust based on your results and style.
Step 7: Set Up Alerts
Right-click chart → Add Alert → Condition: "Luxy Momentum v6" → Choose:
"UT Bot — Buy" for long entries
"UT Bot — Sell" for short entries
"Base Long/Short" for filtered MA cross signals
Optionally enable "Send real-time alert() on UT flip" in settings for immediate notifications.
Common Workflow Variations:
Conservative Trader:
UT signal + Base signal + Candlestick pattern + Bias AVG > 70%
Enter only at major support/resistance
Wider UT sensitivity, multiple filters
Aggressive Trader:
UT signal + Bias AVG > 60%
Enter immediately, no waiting
Tighter UT sensitivity, minimal filters
Swing Trader:
Focus on Daily/Weekly Bias alignment
Ignore intraday noise
Use ORB and PDH/PDL less (or not at all)
Wider stops, patient approach
---
9. PERFORMANCE AND OPTIMIZATION
The indicator is optimized for speed, but with 15+ features running simultaneously, chart load time can add up. Here's how to keep it fast:
Biggest Performance Gains:
Disable Unused Timeframes: In "Time Frames" settings, turn OFF any timeframe you don't actively trade. Each disabled TF saves 10-15% calculation time. If you only day trade 5m, 15m, 1h, disable 1m, 2h, 4h.
Hide Bias Table on Daily+: If you only trade intraday, enable "Hide BIAS table on 1D or above". This skips ALL table calculations on higher timeframes.
Draw UT Visuals Only on Bar Close: Reduces intrabar rendering of SL/TP/Entry lines. Has ZERO impact on logic or alerts - purely visual optimization.
Additional Optimizations:
Turn off VWAP bands if you don't use them
Disable candlestick patterns if you don't trade them
Turn off Supertrend fill if you find it distracting (keep the line)
Reduce "Limit to 10 bars" for SL/TP lines to minimize line objects
Performance Features Built-In:
Smart Caching: Higher timeframe data (3-day bias, weekly bias, etc.) updates once per day, not every bar
Conditional Calculations: Volume filter only calculates when enabled. Swing filter only runs when enabled. Nothing computes if turned off.
Modular Design: Every component is independent. Turn off what you don't need without breaking other features.
Typical Load Times:
5m chart, all features ON, 7 timeframes: ~2-3 seconds
5m chart, core features only, 3 timeframes: ~1 second
1m chart, all features: ~4-5 seconds (many bars to calculate)
If loading takes longer, you likely have too many indicators on the chart total (not just this one).
---
10. FAQ
Q: How is this different from standard UT Bot indicators?
A: Standard UT Bot (originally by @QuantNomad) is just the ATR trailing line and flip signals. This implementation adds:
- Volume weighting and momentum adjustment to the trailing calculation
- Multiple confirmation filters (swing, %, 2-bar, ZLSMA)
- Smart composite stop loss system from multiple S/R layers
- R-multiple take profit system with freeze-on-touch
- Integration with multi-timeframe Bias Table
- Visual audit trail with checkmarks
Q: Can I use this for automated trading?
A: The indicator is designed for discretionary trading. While it has clear signals and alerts, it's not a mechanical system. Context and judgment are required.
Q: Does it repaint?
A: No. All signals respect bar close. UT Bot logic runs intrabar but signals only trigger on confirmed bars. Alerts fire correctly with no lookahead.
Q: Do I need to use all the features?
A: Absolutely not. The indicator is modular. Many profitable traders use just UT Bot + Bias Table + Moving Averages. Start simple, add complexity only if needed.
Q: How do I know which settings to use?
A: Every single input has a detailed tooltip. Hover over any setting to see:
What it does
How it affects trading
Typical values for scalping, day trading, swing trading
Start with defaults, adjust gradually based on results.
Q: Can I use this on crypto 24/7 markets?
A: Yes. ORB will not work (no defined session), but everything else functions normally. Use "Day" anchor for VWAP instead of "Session".
Q: The Bias Table is blank or not showing.
A: Check:
"Show Table" is ON
Table position isn't overlapping another indicator's table (change position)
At least one row is enabled
"Hide BIAS table on 1D or above" is OFF (if on Daily+ chart)
Q: Why are candlestick patterns not appearing?
A: Patterns are relatively rare by design - they only appear at genuine reversal points. Check:
Pattern toggles are ON
"Min candle body %" isn't too high (try 0.05-0.10)
You're looking at a chart with actual reversals (not strong trending market)
Q: UT Bot is too sensitive/not sensitive enough.
A: Adjust "Sensitivity (Key×ATR)". Lower number = tighter stop, more signals. Higher number = wider stop, fewer signals. Read the tooltip for guidance.
Q: Can I get alerts for the Bias Table?
A: The Bias Table is a dashboard for visual analysis, not a signal generator. Set alerts on UT Bot or Base signals, then manually check Bias Table for confirmation.
Q: Does this work on stocks with low volume?
A: Yes, but turn OFF the volume filter. Low volume stocks will never meet relative volume requirements.
Q: How often should I check the Bias Table?
A: Before every entry. It takes 2 seconds to glance at the AVG column and headline rows. This one check can save you from fighting the trend.
Q: What if UT signal and Base signal disagree?
A: UT Bot is more aggressive (ATR trailing). Base signals are more conservative (MA cross + filters). If they disagree, either:
Wait for both to align (safest)
Take the UT signal but with smaller size (aggressive)
Skip the trade (conservative)
There's no "right" answer - depends on your risk tolerance.
---
FINAL NOTES
The indicator gives you an edge. How you use that edge determines results.
For questions, feedback, or support, comment on the indicator page or message the author.
Happy Trading!
Gann Swing Strategy [1 Bar - Multi Layer]Use this Strategy to Fine-tune inputs for your Gann swing strategy.
Strategy allows you to fine-tune the indicator for 1 TimeFrame at a time; cross Timeframe Input fine-tuning is done manually after exporting the chart data.
MEANINGFUL DESCRIPTION:
The Gann Swing Chart using the One-Bar type, also known as the Minor Trend Chart, is designed to follow single-bar movements in the market. It helps identify trends by tracking price movements. When the market makes a higher high than the previous bar from a low price, the One-Bar trend line moves up, indicating a new high and establishing the previous low as a One-Bar bottom. Conversely, when the market makes a lower low than the previous bar from a high price, the One-Bar swing line moves down, marking a new low and setting the previous high as a One-Bar top. The crossing of these swing tops and bottoms indicates a change in trend direction.
HOW TO USE THE INDICATOR / Gann-swing Strategy:
The indicator shows 1, 2, and 3-bar swings. The strategy triggers a buy when the price crosses the previously determined high.
HOW TO USE THE STRATEGY:
Strategy to Fine-Tune Inputs for Your Gann Swing Strategy
This strategy allows for the fine-tuning of indicators for one timeframe at a time. Cross-timeframe input fine-tuning is done manually after exporting the chart data.
Meaningful Description:
The Gann Swing Chart using the One-Bar type, also known as the Minor Trend Chart, is designed to follow single-bar movements in the market. It helps identify trends by tracking price movements. When the market makes a higher high than the previous bar from a low price, the One-Bar trend line moves up, indicating a new high and establishing the previous low as a One-Bar bottom. Conversely, when the market makes a lower low than the previous bar from a high price, the One-Bar swing line moves down, marking a new low and setting the previous high as a One-Bar top. The crossing of these swing tops and bottoms indicates a change in trend direction.
How to Use the Indicator / Gann-Swing Strategy:
The indicator shows 1, 2, and 3-bar swings. The strategy triggers a buy when the price crosses the previously determined high.
How to Use the Strategy:
The strategy initiates a buy if the price breaks 1, 2, or 3-bar highs, or any combination thereof. Use the inputs to determine which highs or lows need to be crossed for the strategy to go long or short.
ORIGINALITY & USEFULNESS:
The One-Bar Swing Chart stands out for its simplicity and effectiveness in capturing minor market trends. Developed by meomeo105, this Gann high and low algorithm forms the basis of the strategy. I used my approach to creating strategy out of Gann swing indicator.
DETAILED DESCRIPTION:
What is a Swing Chart?
Swing charts help traders visualize price movements and identify trends by focusing on price highs and lows. They are instrumental in spotting trend reversals and continuations.
What is the One-Bar Swing Chart?
The One-Bar Swing Chart, also known as the Minor Trend Chart, follows single-bar price movements. It plots upward swings from a low price when a higher high is made, and downward swings from a high price when a lower low is made.
Key Features:
Trend Identification : Highlights minor trends by plotting swing highs and lows based on one-bar movements.
Simple Interpretation : Crossing a swing top indicates an uptrend, while crossing a swing bottom signals a downtrend.
Customizable Periods : Users can adjust the period to fine-tune the sensitivity of the swing chart to market movements.
Practical Application:
Bullish Trend : When the One-Bar Swing line moves above a previous swing top, it indicates a bullish trend.
Bearish Trend : When the One-Bar Swing line moves below a previous swing bottom, it signals a bearish trend.
Trend Reversal : Watch for crossings of swing tops and bottoms to detect potential trend reversals.
The One-Bar Swing Chart is a powerful tool for traders looking to capture and understand market trends. By following the simple rules of swing highs and lows, it provides clear and actionable insights into market direction.
Why the Strategy Uses 100% Allocation of a Portfolio:
This strategy allocates 100% of the portfolio to trading this specific pair, which does not mean 100% of all capital but 100% of the allocated trading capital for this pair. The strategy is swing-based and does not use take profit (TP) or stop losses.
Physics CandlesPhysics Candles embed volume and motion physics directly onto price candles or market internals according to the cyclic pattern of financial securities. The indicator works on both real-time “ticks” and historical data using statistical modeling to highlight when these values, like volume or momentum, is unusual or relatively high for some periodic window in time. Each candle is made out of one or more sub-candles that each contain their own information of motion, which converts to the color and transparency, or brightness, of that particular candle segment. The segments extend throughout the entire candle, both body and wicks, and Thick Wicks can be implemented to see the color coding better. This candle segmentation allows you to see if all the volume or energy is evenly distributed throughout the candle or highly contained in one small portion of it, and how intense these values are compared to similar time periods without going to lower time frames. Candle segmentation can also change a trader’s perspective on how valuable the information is. A “low” volume candle, for instance, could signify high value short-term stopping volume if the volume is all concentrated in one segment.
The Candles are flexible. The physics information embedded on the candles need not be from the same price security or market internal as the chart when using the Physics Source option, and multiple Candles can be overlayed together. You could embed stock price Candles with market volume, market price Candles with stock momentum, market structure with internal acceleration, stock price with stock force, etc. My particular use case is scalping the SPX futures market (ES), whose price action is also dictated by the volume action in the associated cash market, or SPY, as well as a host of other securities. Physics allows you to embed the ES volume on the SPY price action, or the SPY volume on the ES price action, or you can combine them both by overlaying two Candle streams and increasing the Number of Overlays option to two. That option decreases the transparency levels of your coloring scheme so that overlaying multiple Candles converges toward the same visual color intensity as if you had one. The Candle and Physics Sources allows for both Symbols and Spreads to visualize Candle physics from a single ticker or some mathematical transformation of tickers.
Due to certain TradingView programming restrictions, each Candle can only be made out of a maximum of 8 candle segments, or an “8-bit” resolution. Since limits are just an opportunity to go beyond, the user has the option to stack multiple Candle indicators together to further increase the candle resolution. If you don’t want to see the Candles for some particular period of the day, you can hide them, or use the hiding feature to have multiple Candles calibrated to show multiple parts of the trading day. Securities tend to have low volume after hours with sharp spikes at the open or close. Multiple Candles can be used for multiple parts of the trading day to accommodate these different cycles in volume.
The Candles do not need be associated with the nominal security listed on the TV chart. The Candle Source allows the user to look at AAPL Candles, for instance, while on a TSLA or SPY chart, each with their respective volume actions integrated into the candles, for instance, to allow the user to see multiple security price and volume correlation on a single chart.
The physics information currently embeddable on Candles are volume or time, velocity, momentum, acceleration, force, and kinetic energy. In order to apply equations of motion containing a mass variable to financial securities, some analogous value for mass must be assumed. Traders often regard volume or time as inextricable variables to a securities price that can indicate the direction and strength of a move. Since mass is the inextricable variable to calculating the momentum, force, or kinetic energy of motion, the user has the option to assume either time or volume is analogous to mass. Volume may be a better option for mass as it is not strictly dependent on the speed of a security, whereas time is.
Data transformations and outlier statistics are used to color code the intensity of the physics for each candle segment relative to past periodic behavior. A million shares during pre-market or a million shares during noontime may be more intense signals than a typical million shares traded at the open, and should have more intense color signals. To account for a specific cyclic behavior in the market, the user can specify the Window and Cycle Time Frames. The Window Time Frame splits up a Cycle into windows, samples and aggregates the statistics for each window, then compares the current physics values against past values in the same window. Intraday traders may benefit from using a Daily Cycle with a 30-minute Window Time Frame and 1-minute Sample Time Frame. These settings sample and compare the physics of 1-minute candles within the current 30-minute window to the same 30-minute window statistics for all past trading days, up until the data limit imposed by TradingView, or until the Data Collection Start Date specified in the settings. Longer-term traders may benefit from using a Monthly Cycle with a Weekly Time Frame, or a Yearly Cycle with a Quarterly Time Frame.
Multiple statistics and data transformation methods are available to convey relative intensity in different ways for different trading signals. Physics Candles allows for both Normal and Log-Normal assumptions in the physics distribution. The data can then be transformed by Linear, Logarithmic, Z-Score, or Power-Law scoring, where scoring simply assigns an intensity to the relative physics value of each candle segment based on some mathematical transformation. Z-scoring often renders adequate detection by scoring the segment value, such as volume or momentum, according to the mean and standard deviation of the data set in each window of the cycle. Logarithmic or power-law transformation with a gamma below 1 decreases the disparity between intensities so more less-important signals will show up, whereas the power-law transformation with gamma values above 1 increases the disparity between intensities, so less more-important signals will show up. These scores are then converted to color and transparency between the Min Score and the Max Score Cutoffs. The Auto-Normalization feature can automatically pick these cutoffs specific to each window based on the mean and standard deviation of the data set, or the user can manually set them. Physics was developed with novices in mind so that most users could calibrate their own settings by plotting the candle segment distributions directly on the chart and fiddling with the settings to see how different cutoffs capture different portions of the distribution and affect the relative color intensities differently. Security distributions are often skewed with fat-tails, known as kurtosis, where high-volume segments for example, have a higher-probabilities than expected for a normal distribution. These distribution are really log-normal, so that taking the logarithm leads to a standard bell-shaped distribution. Taking the Z-score of the Log-Normal distribution could make the most statistical sense, but color sensitivity is a discretionary preference.
Background Philosophy
This indicator was developed to study and trade the physics of motion in financial securities from a visually intuitive perspective. Newton’s laws of motion are loosely applied to financial motion:
“A body remains at rest, or in motion at a constant speed in a straight line, unless acted upon by a force”.
Financial securities remain at rest, or in motion at constant speed up or down, unless acted upon by the force of traders exchanging securities.
“When a body is acted upon by a force, the time rate of change of its momentum equals the force”.
Momentum is the product of mass and velocity, and force is the product of mass and acceleration. Traders render force on the security through the mass of their trading activity and the acceleration of price movement.
“If two bodies exert forces on each other, these forces have the same magnitude but opposite directions.”
Force arises from the interaction of traders, buyers and sellers. One body of motion, traders’ capitalization, exerts an equal and opposite force on another body of motion, the financial security. A securities movement arises at the expense of a buyer or seller’s capitalization.
Volume
The premise of this indicator assumes that volume, v, is an analogous means of measuring physical mass, m. This premise allows the application of the equations of motion to the movement of financial securities. We know from E=mc^2 that mass has energy. Energy can be used to create motion as kinetic energy. Taking a simple hypothetical example, the interaction of one short seller looking to cover lower and one buyer looking to sell higher exchange shares in a security at an agreed upon price to create volume or mass, and therefore, potential energy. Eventually the short seller will actively cover and buy the security from the previous buyer, moving the security higher, or the buyer will actively sell to the short seller, moving the security lower. The potential energy inherent in the initial consolidation or trading activity between buy and seller is now converted to kinetic energy on the subsequent trading activity that moves the securities price. The more potential energy that is created in the consolidation, the more kinetic energy there is to move price. This is why point and figure traders are said to give price targets based on the level of volatility or size of a consolidation range, or why Gann traders square price and time, as time is roughly proportional to mass and trading activity. The build-up of potential energy between short sellers and buyers in GME or TSLA led to their explosive moves beyond their standard fundamental valuations.
Position
Position, p, is simply the price or value of a financial security or market internal.
Time
Time, t, is another means of measuring mass to discover price behavior beyond the time snapshots that simple candle charts provide. We know from E=mc^2 that time is related to rest mass and energy given the speed of light, c, where time ≈ distance * sqrt(mass/E). This relation can also be derived from F=ma. The more mass there is, the longer it takes to compute the physics of a system. The more energy there is, the shorter it takes to compute the physics of a system. Similarly, more time is required to build a “resting” low-volatility trading consolidation with more mass. More energy added to that trading consolidation by competing buyers and sellers decreases the time it takes to build that same mass. Time is also related to price through velocity.
Velocity = (p(t1) – p(t0)) / p(t0)
Velocity, v, is the relative percent change of a securities price, p, over a period of time, t0 to t1. The period of time is between subsequent candles, and since time is constant between candles within the same timeframe, it is not used to calculate velocity or acceleration. Price moves faster with higher velocity, and slower with slower velocity, over the same fixed period of time. The product of velocity and mass gives momentum.
Momentum = mv
This indicator uses physics definition of momentum, not finance’s. In finance, momentum is defined as the amount of change in a securities price, either relative or absolute. This is definition is unfortunate, pun intended, since a one dollar move in a security from a thousand shares traded between a few traders has the exact same “momentum” as a one dollar move from millions of shares traded between hundreds of traders with everything else equal. If momentum is related to the energy of the move, momentum should consider both the level of activity in a price move, and the amount of that price move. If we equate mass to volume to account for the level of trading activity and use physics definition of momentum as the product of mass and velocity, this revised definition now gives a thousand-times more momentum to a one-dollar price move that has a thousand-times more volume behind it. If you want to use finance’s volume-less definition of momentum, use velocity in this indicator.
Acceleration = v(t1) – v(t0)
Acceleration, a, is the difference between velocities over some period of time, t0 to t1. Positive acceleration is necessary to increase a securities speed in the positive direction, while negative acceleration is necessary to decrease it. Acceleration is related to force by mass.
Force = ma
Force is required to change the speed of a securities valuation. Price movements with considerable force have considerably more impact on future direction. A change in direction requires force.
Kinetic Energy = 0.5mv^2
Kinetic energy is the energy that a financial security gains from the change in its velocity by force. The built-up of potential energy in trading consolidations can be converted to kinetic energy on a breakout from the consolidation.
Cycle Theory and Relativity
Just as the physics of motion is relative to a point of reference, so too should the physics of financial securities be relative to a point of reference. An object moving at a 100 mph towards another object moving in the same direction at 100 mph will not appear to be moving relative to each other, nor will they collide, but from an outsider observer, the objects are going 100 mph and will collide with significant impact if they run into a stationary object relative to the observer. Similarly, trading with a hundred thousand shares at the open when the average volume is a couple million may have a much smaller impact on the price compared to trading a hundred thousand shares pre-market when the average volume is ten thousand shares. The point of reference used in this indicator is the average statistics collected for a given Window Time Frame for every Cycle Time Frame. The physics values are normalized relative to these statistics.
Examples
The main chart of this publication shows the Force Candles for the SPY. An intense force candle is observed pre-market that implicates the directional overtone of the day. The assumption that direction should follow force arises from physical observation. If a large object is accelerating intensely in a particular direction, it may be fair to assume that the object continues its direction for the time being unless acted upon by another force.
The second example shows a similar Force Candle for the SPY that counters the assumption made in the first example and emphasizes the importance of both motion and context. While it’s fair to assume that a heavy highly accelerating object should continue its course, if that object runs into an obstacle, say a brick wall, it’s course may deviate. This example shows SPY running into the 50% retracement wall from the low of Mar 2020, a significant support level noted in literature. The example also conveys Gann’s idea of “lost motion”, where the SPY penetrated the 50% price but did not break through it. A brick wall is not one atom thick and price support is not one tick thick. An object can penetrate only one layer of a wall and not go through it.
The third example shows how Volume Candles can be used to identify scalping opportunities on the SPY and conveys why price behavior is as important as motion and context. It doesn’t take a brick wall to impede direction if you know that the person driving the car tends to forget to feed the cats before they leave. In the chart below, the SPY breaks down to a confluence of the 5-day SMA, 20-day SMA, and an important daily trendline (not shown) after the bullish bounce from the 50% retracement days earlier. High volume candles on the SMA signify stopping volume that reverse price direction. The character of the day changes. Bulls become more aggressive than bears with higher volume on upswings and resistance, whiles bears take on a defensive position with lower volume on downswings and support. High volume stopping candles are seen after rallies, and can tell you when to take profit, get out of a position, or go short. The character change can indicate that its relatively safe to re-enter bullish positions on many major supports, especially given the overarching bullish theme from the large reaction off the 50% retracement level.
The last example emphasizes the importance of relativity. The Volume Candles in the chart below are brightest pre-market even though the open has much higher volume since the pre-market activity is much higher compared to past pre-markets than the open is compared to past opens. Pre-market behavior is a good indicator for the character of the day. These bullish Volume Candles are some of the brightest seen since the bounce off the 50% retracement and indicates that bulls are making a relatively greater attempt to bring the SPY higher at the start of the day.
Infrequently Asked Questions
Where do I start?
The default settings are what I use to scalp the SPY throughout most of the extended trading day, on a one-minute chart using SPY volume. I also overlay another Candle set containing ES future volume on the SPY price structure by setting the Physics Source to ES1! and the Number of Overlays setting to 2 for each Candle stream in order to account for pre- and post-market trading activity better. Since the closing volume is exponential-like up until the end of the regular trading day, adding additional Candle streams with a tighter Window Time Frame (e.g., 2-5 minute) in the last 15 minutes of trading can be beneficial. The Hide feature can allow you to set certain intraday timeframes to hide one Candle set in order to show another Candle set during that time.
How crazy can you get with this indicator?
I hope you can answer this question better. One interesting use case is embedding the velocity of market volume onto an internal market structure. The PCTABOVEVWAP.US is a market statistic that indicates the percent of securities above their VWAP among US stocks and is helpful for determining short term trends in the US market. When securities are rising above their VWAP, the average long is up on the day and a rising PCTABOVEVWAP.US can be viewed as more bullish. When securities are falling below their VWAP, the average short is up on the day and a falling PCTABOVEVWAP.US can be viewed as more bearish. (UPVOL.US - DNVOL.US) / TVOL.US is a “spread” symbol, in TV parlance, that indicates the decimal percent difference between advancing volume and declining volume in the US market, showing the relative flow of volume between stocks that are up on the day, and stocks that are down on the day. Setting PCTABOVEVWAP.US in the Candle Source, (UPVOL.US - DNVOL.US) / TVOL.US in the Physics Source, and selecting the Physics to Velocity will embed the relative velocity of the spread symbol onto the PCTABOVEVWAP.US candles. This can be helpful in seeing short term trends in the US market that have an increasing amount of volume behind them compared to other trends. The chart below shows Volume Candles (top) and these Spread Candles (bottom). The first top at 9:30 and second top at 10:30, the high of the day, break down when the spread candles light up, showing a high velocity volume transfer from up stocks to down stocks.
How do I plot the indicator distribution and why should I even care?
The distribution is visually helpful in seeing how different normalization settings effect the distribution of candle segments. It is also helpful in seeing what physics intensities you want to ignore or show by segmenting part of the distribution within the Min and Max Cutoff values. The intensity of color is proportional to the physics value between the Min and Max Cutoff values, which correspond to the Min and Max Colors in your color scheme. Any physics value outside these Min and Max Cutoffs will be the same as the Min and Max Colors.
Select the Print Windows feature to show the window numbers according to the Cycle Time Frame and Window Time Frame settings. The window numbers are labeled at the start of each window and are candle width in size, so you may need to zoom into to see them. Selecting the Plot Window feature and input the window number of interest to shows the distribution of physics values for that particular window along with some statistics.
A log-normal volume distribution of segmented z-scores is shown below for 30-minute opening of the SPY. The Min and Max Cutoff at the top of the graph contain the part of the distribution whose intensities will be linearly color-coded between the Min and Max Colors of the color scheme. The part of the distribution below the Min Cutoff will be treated as lowest quality signals and set to the Min Color, while the few segments above the Max Cutoff will be treated as the highest quality signals and set to the Max Color.
What do I do if I don’t see anything?
Troubleshooting issues with this indicator can involve checking for error messages shown near the indicator name on the chart or using the Data Validation section to evaluate the statistics and normalization cutoffs. For example, if the Plot Window number is set to a window number that doesn’t exist, an error message will tell you and you won’t see any candles. You can use the Print Windows option to show windows that do exist for you current settings. The auto-normalization cutoff values may be inappropriate for your particular use case and literally cut the candles out of the chart. Try changing the chart time frame to see if they are appropriate for your cycle, sample and window time frames. If you get a “Timeframe passed to the request.security_lower_tf() function must be lower than the timeframe of the main chart” error, this means that the chart timeframe should be increased above the sample time frame. If you get a “Symbol resolve error”, ensure that you have correct symbol or spread in the Candle or Physics Source.
How do I see a relative physics values without cycles?
Set the Window Time Frame to be equal to the Cycle Time Frame. This will aggregate all the statistics into one bucket and show the physics values, such as volume, relative to all the past volumes that TV will allow.
How do I see candles without segmentation?
Segmentation can be very helpful in one context or annoying in another. Segmentation can be removed by setting the candle resolution value to 1.
Notes
I have yet to find a trading platform that consistently provides accurate real-time volume and pricing information, lacking adequate end-user data validation or quality control. I can provide plenty of examples of real-time volume counts or prices provided by TradingView and other platforms that were significantly off from what they should have been when comparing against the exchanges own data, and later retroactively corrected or not corrected at all. Since no indicator can work accurately with inaccurate data, please use at your own discretion.
The first version is a beta version. Debugging and validating code in Pine script is difficult without proper unit testing. Please report any bugs with enough information to reproduce them and indicate why they are important. I also encourage you to export the data from TradingView and verify the calculations for your particular use case.
The indicator works on real-time updates that occur at a higher frequency than the candle time frame, which TV incorrectly refers to as ticks. They use this terminology inaccurately as updates are really aggregated tick data that can take place at different prices and may not accurately reflect the real tick price action. Consequently, this inaccuracy also impacts the real-time segmentation accuracy to some degree. TV does not provide a means of retaining “tick” information, so the higher granularity of information seen real-time will be lost on a disconnect.
TV does not provide time and sales information. The volume and price information collected using the Sample Time Frame is intraday, which provides only part of the picture. Intraday volume is generally 50 to 80% of the end of day volume. Consequently, the daily+ OHLC prices are intraday, and may differ significantly from exchanged settled OHLC prices.
The Cycle and Window Time Frames refer to calendar days and time, not trading days or time. For example, the first window week of a monthly cycle is the first seven days of the month, not the first Monday through Friday of trading for the month.
Chart Time Frames that are higher than the Window Time Frames average the normalized physics for price action that occurred within a given Candle segment. It does not average price action that did not occur.
One of the main performance bottleneck in TradingView’s Pine Script is client-side drawing and plotting. The performance of this indicator can be increased by lowering the resolution (the number of sub-candles this indicator plots), getting a faster computer, or increasing the performance of your computer like plugging your laptop in and eliminating unnecessary processes.
The statistical integrity of this indicator relies on the number of samples collected per sample window in a given cycle. Higher sample counts can be obtained by increasing the chart time frame or upgrading the TradingView plan for a higher bar count. While increasing the chart time frame doesn’t increase the visual number of bars plotted on the chart, it does increase the number of bars that can be pulled at a lower time frame, up to 100,000.
Due to a limitation in Pine Scripts request_lower_tf() function, using a spread symbol will only work for regular trading hours, not extended trading hours.
Ideally, velocity or momentum should be calculated between candle closes. To eliminate the need to deal with price gaps that would lead to an incorrect statistical distributions, momentum is calculated between candle open and closes as a percent change of the price or value, which should not be an issue for most liquid securities.
Backtesting & Trading Engine [PineCoders]The PineCoders Backtesting and Trading Engine is a sophisticated framework with hybrid code that can run as a study to generate alerts for automated or discretionary trading while simultaneously providing backtest results. It can also easily be converted to a TradingView strategy in order to run TV backtesting. The Engine comes with many built-in strats for entries, filters, stops and exits, but you can also add you own.
If, like any self-respecting strategy modeler should, you spend a reasonable amount of time constantly researching new strategies and tinkering, our hope is that the Engine will become your inseparable go-to tool to test the validity of your creations, as once your tests are conclusive, you will be able to run this code as a study to generate the alerts required to put it in real-world use, whether for discretionary trading or to interface with an execution bot/app. You may also find the backtesting results the Engine produces in study mode enough for your needs and spend most of your time there, only occasionally converting to strategy mode in order to backtest using TV backtesting.
As you will quickly grasp when you bring up this script’s Settings, this is a complex tool. While you will be able to see results very quickly by just putting it on a chart and using its built-in strategies, in order to reap the full benefits of the PineCoders Engine, you will need to invest the time required to understand the subtleties involved in putting all its potential into play.
Disclaimer: use the Engine at your own risk.
Before we delve in more detail, here’s a bird’s eye view of the Engine’s features:
More than 40 built-in strategies,
Customizable components,
Coupling with your own external indicator,
Simple conversion from Study to Strategy modes,
Post-Exit analysis to search for alternate trade outcomes,
Use of the Data Window to show detailed bar by bar trade information and global statistics, including some not provided by TV backtesting,
Plotting of reminders and generation of alerts on in-trade events.
By combining your own strats to the built-in strats supplied with the Engine, and then tuning the numerous options and parameters in the Inputs dialog box, you will be able to play what-if scenarios from an infinite number of permutations.
USE CASES
You have written an indicator that provides an entry strat but it’s missing other components like a filter and a stop strategy. You add a plot in your indicator that respects the Engine’s External Signal Protocol, connect it to the Engine by simply selecting your indicator’s plot name in the Engine’s Settings/Inputs and then run tests on different combinations of entry stops, in-trade stops and profit taking strats to find out which one produces the best results with your entry strat.
You are building a complex strategy that you will want to run as an indicator generating alerts to be sent to a third-party execution bot. You insert your code in the Engine’s modules and leverage its trade management code to quickly move your strategy into production.
You have many different filters and want to explore results using them separately or in combination. Integrate the filter code in the Engine and run through different permutations or hook up your filtering through the external input and control your filter combos from your indicator.
You are tweaking the parameters of your entry, filter or stop strat. You integrate it in the Engine and evaluate its performance using the Engine’s statistics.
You always wondered what results a random entry strat would yield on your markets. You use the Engine’s built-in random entry strat and test it using different combinations of filters, stop and exit strats.
You want to evaluate the impact of fees and slippage on your strategy. You use the Engine’s inputs to play with different values and get immediate feedback in the detailed numbers provided in the Data Window.
You just want to inspect the individual trades your strategy generates. You include it in the Engine and then inspect trades visually on your charts, looking at the numbers in the Data Window as you move your cursor around.
You have never written a production-grade strategy and you want to learn how. Inspect the code in the Engine; you will find essential components typical of what is being used in actual trading systems.
You have run your system for a while and have compiled actual slippage information and your broker/exchange has updated his fees schedule. You enter the information in the Engine and run it on your markets to see the impact this has on your results.
FEATURES
Before going into the detail of the Inputs and the Data Window numbers, here’s a more detailed overview of the Engine’s features.
Built-in strats
The engine comes with more than 40 pre-coded strategies for the following standard system components:
Entries,
Filters,
Entry stops,
2 stage in-trade stops with kick-in rules,
Pyramiding rules,
Hard exits.
While some of the filter and stop strats provided may be useful in production-quality systems, you will not devise crazy profit-generating systems using only the entry strats supplied; that part is still up to you, as will be finding the elusive combination of components that makes winning systems. The Engine will, however, provide you with a solid foundation where all the trade management nitty-gritty is handled for you. By binding your custom strats to the Engine, you will be able to build reliable systems of the best quality currently allowed on the TV platform.
On-chart trade information
As you move over the bars in a trade, you will see trade numbers in the Data Window change at each bar. The engine calculates the P&L at every bar, including slippage and fees that would be incurred were the trade exited at that bar’s close. If the trade includes pyramided entries, those will be taken into account as well, although for those, final fees and slippage are only calculated at the trade’s exit.
You can also see on-chart markers for the entry level, stop positions, in-trade special events and entries/exits (you will want to disable these when using the Engine in strategy mode to see TV backtesting results).
Customization
You can couple your own strats to the Engine in two ways:
1. By inserting your own code in the Engine’s different modules. The modular design should enable you to do so with minimal effort by following the instructions in the code.
2. By linking an external indicator to the engine. After making the proper selections in the engine’s Settings and providing values respecting the engine’s protocol, your external indicator can, when the Engine is used in Indicator mode only:
Tell the engine when to enter long or short trades, but let the engine’s in-trade stop and exit strats manage the exits,
Signal both entries and exits,
Provide an entry stop along with your entry signal,
Filter other entry signals generated by any of the engine’s entry strats.
Conversion from strategy to study
TradingView strategies are required to backtest using the TradingView backtesting feature, but if you want to generate alerts with your script, whether for automated trading or just to trigger alerts that you will use in discretionary trading, your code has to run as a study since, for the time being, strategies can’t generate alerts. From hereon we will use indicator as a synonym for study.
Unless you want to maintain two code bases, you will need hybrid code that easily flips between strategy and indicator modes, and your code will need to restrict its use of strategy() calls and their arguments if it’s going to be able to run both as an indicator and a strategy using the same trade logic. That’s one of the benefits of using this Engine. Once you will have entered your own strats in the Engine, it will be a matter of commenting/uncommenting only four lines of code to flip between indicator and strategy modes in a matter of seconds.
Additionally, even when running in Indicator mode, the Engine will still provide you with precious numbers on your individual trades and global results, some of which are not available with normal TradingView backtesting.
Post-Exit Analysis for alternate outcomes (PEA)
While typical backtesting shows results of trade outcomes, PEA focuses on what could have happened after the exit. The intention is to help traders get an idea of the opportunity/risk in the bars following the trade in order to evaluate if their exit strategies are too aggressive or conservative.
After a trade is exited, the Engine’s PEA module continues analyzing outcomes for a user-defined quantity of bars. It identifies the maximum opportunity and risk available in that space, and calculates the drawdown required to reach the highest opportunity level post-exit, while recording the number of bars to that point.
Typically, if you can’t find opportunity greater than 1X past your trade using a few different reasonable lengths of PEA, your strategy is doing pretty good at capturing opportunity. Remember that 100% of opportunity is never capturable. If, however, PEA was finding post-trade maximum opportunity of 3 or 4X with average drawdowns of 0.3 to those areas, this could be a clue revealing your system is exiting trades prematurely. To analyze PEA numbers, you can uncomment complete sets of plots in the Plot module to reveal detailed global and individual PEA numbers.
Statistics
The Engine provides stats on your trades that TV backtesting does not provide, such as:
Average Profitability Per Trade (APPT), aka statistical expectancy, a crucial value.
APPT per bar,
Average stop size,
Traded volume .
It also shows you on a trade-by-trade basis, on-going individual trade results and data.
In-trade events
In-trade events can plot reminders and trigger alerts when they occur. The built-in events are:
Price approaching stop,
Possible tops/bottoms,
Large stop movement (for discretionary trading where stop is moved manually),
Large price movements.
Slippage and Fees
Even when running in indicator mode, the Engine allows for slippage and fees to be included in the logic and test results.
Alerts
The alert creation mechanism allows you to configure alerts on any combination of the normal or pyramided entries, exits and in-trade events.
Backtesting results
A few words on the numbers calculated in the Engine. Priority is given to numbers not shown in TV backtesting, as you can readily convert the script to a strategy if you need them.
We have chosen to focus on numbers expressing results relative to X (the trade’s risk) rather than in absolute currency numbers or in other more conventional but less useful ways. For example, most of the individual trade results are not shown in percentages, as this unit of measure is often less meaningful than those expressed in units of risk (X). A trade that closes with a +25% result, for example, is a poor outcome if it was entered with a -50% stop. Expressed in X, this trade’s P&L becomes 0.5, which provides much better insight into the trade’s outcome. A trade that closes with a P&L of +2X has earned twice the risk incurred upon entry, which would represent a pre-trade risk:reward ratio of 2.
The way to go about it when you think in X’s and that you adopt the sound risk management policy to risk a fixed percentage of your account on each trade is to equate a currency value to a unit of X. E.g. your account is 10K USD and you decide you will risk a maximum of 1% of it on each trade. That means your unit of X for each trade is worth 100 USD. If your APPT is 2X, this means every time you risk 100 USD in a trade, you can expect to make, on average, 200 USD.
By presenting results this way, we hope that the Engine’s statistics will appeal to those cognisant of sound risk management strategies, while gently leading traders who aren’t, towards them.
We trade to turn in tangible profits of course, so at some point currency must come into play. Accordingly, some values such as equity, P&L, slippage and fees are expressed in currency.
Many of the usual numbers shown in TV backtests are nonetheless available, but they have been commented out in the Engine’s Plot module.
Position sizing and risk management
All good system designers understand that optimal risk management is at the very heart of all winning strategies. The risk in a trade is defined by the fraction of current equity represented by the amplitude of the stop, so in order to manage risk optimally on each trade, position size should adjust to the stop’s amplitude. Systems that enter trades with a fixed stop amplitude can get away with calculating position size as a fixed percentage of current equity. In the context of a test run where equity varies, what represents a fixed amount of risk translates into different currency values.
Dynamically adjusting position size throughout a system’s life is optimal in many ways. First, as position sizing will vary with current equity, it reproduces a behavioral pattern common to experienced traders, who will dial down risk when confronted to poor performance and increase it when performance improves. Second, limiting risk confers more predictability to statistical test results. Third, position sizing isn’t just about managing risk, it’s also about maximizing opportunity. By using the maximum leverage (no reference to trading on margin here) into the trade that your risk management strategy allows, a dynamic position size allows you to capture maximal opportunity.
To calculate position sizes using the fixed risk method, we use the following formula: Position = Account * MaxRisk% / Stop% [, which calculates a position size taking into account the trade’s entry stop so that if the trade is stopped out, 100 USD will be lost. For someone who manages risk this way, common instructions to invest a certain percentage of your account in a position are simply worthless, as they do not take into account the risk incurred in the trade.
The Engine lets you select either the fixed risk or fixed percentage of equity position sizing methods. The closest thing to dynamic position sizing that can currently be done with alerts is to use a bot that allows syntax to specify position size as a percentage of equity which, while being dynamic in the sense that it will adapt to current equity when the trade is entered, does not allow us to modulate position size using the stop’s amplitude. Changes to alerts are on the way which should solve this problem.
In order for you to simulate performance with the constraint of fixed position sizing, the Engine also offers a third, less preferable option, where position size is defined as a fixed percentage of initial capital so that it is constant throughout the test and will thus represent a varying proportion of current equity.
Let’s recap. The three position sizing methods the Engine offers are:
1. By specifying the maximum percentage of risk to incur on your remaining equity, so the Engine will dynamically adjust position size for each trade so that, combining the stop’s amplitude with position size will yield a fixed percentage of risk incurred on current equity,
2. By specifying a fixed percentage of remaining equity. Note that unless your system has a fixed stop at entry, this method will not provide maximal risk control, as risk will vary with the amplitude of the stop for every trade. This method, as the first, does however have the advantage of automatically adjusting position size to equity. It is the Engine’s default method because it has an equivalent in TV backtesting, so when flipping between indicator and strategy mode, test results will more or less correspond.
3. By specifying a fixed percentage of the Initial Capital. While this is the least preferable method, it nonetheless reflects the reality confronted by most system designers on TradingView today. In this case, risk varies both because the fixed position size in initial capital currency represents a varying percentage of remaining equity, and because the trade’s stop amplitude may vary, adding another variability vector to risk.
Note that the Engine cannot display equity results for strategies entering trades for a fixed amount of shares/contracts at a variable price.
SETTINGS/INPUTS
Because the initial text first published with a script cannot be edited later and because there are just too many options, the Engine’s Inputs will not be covered in minute detail, as they will most certainly evolve. We will go over them with broad strokes; you should be able to figure the rest out. If you have questions, just ask them here or in the PineCoders Telegram group.
Display
The display header’s checkbox does nothing.
For the moment, only one exit strategy uses a take profit level, so only that one will show information when checking “Show Take Profit Level”.
Entries
You can activate two simultaneous entry strats, each selected from the same set of strats contained in the Engine. If you select two and they fire simultaneously, the main strat’s signal will be used.
The random strat in each list uses a different seed, so you will get different results from each.
The “Filter transitions” and “Filter states” strats delegate signal generation to the selected filter(s). “Filter transitions” signals will only fire when the filter transitions into bull/bear state, so after a trade is stopped out, the next entry may take some time to trigger if the filter’s state does not change quickly. When you choose “Filter states”, then a new trade will be entered immediately after an exit in the direction the filter allows.
If you select “External Indicator”, your indicator will need to generate a +2/-2 (or a positive/negative stop value) to enter a long/short position, providing the selected filters allow for it. If you wish to use the Engine’s capacity to also derive the entry stop level from your indicator’s signal, then you must explicitly choose this option in the Entry Stops section.
Filters
You can activate as many filters as you wish; they are additive. The “Maximum stop allowed on entry” is an important component of proper risk management. If your system has an average 3% stop size and you need to trade using fixed position sizes because of alert/execution bot limitations, you must use this filter because if your system was to enter a trade with a 15% stop, that trade would incur 5 times the normal risk, and its result would account for an abnormally high proportion in your system’s performance.
Remember that any filter can also be used as an entry signal, either when it changes states, or whenever no trade is active and the filter is in a bull or bear mode.
Entry Stops
An entry stop must be selected in the Engine, as it requires a stop level before the in-trade stop is calculated. Until the selected in-trade stop strat generates a stop that comes closer to price than the entry stop (or respects another one of the in-trade stops kick in strats), the entry stop level is used.
It is here that you must select “External Indicator” if your indicator supplies a +price/-price value to be used as the entry stop. A +price is expected for a long entry and a -price value will enter a short with a stop at price. Note that the price is the absolute price, not an offset to the current price level.
In-Trade Stops
The Engine comes with many built-in in-trade stop strats. Note that some of them share the “Length” and “Multiple” field, so when you swap between them, be sure that the length and multiple in use correspond to what you want for that stop strat. Suggested defaults appear with the name of each strat in the dropdown.
In addition to the strat you wish to use, you must also determine when it kicks in to replace the initial entry’s stop, which is determined using different strats. For strats where you can define a positive or negative multiple of X, percentage or fixed value for a kick-in strat, a positive value is above the trade’s entry fill and a negative one below. A value of zero represents breakeven.
Pyramiding
What you specify in this section are the rules that allow pyramiding to happen. By themselves, these rules will not generate pyramiding entries. For those to happen, entry signals must be issued by one of the active entry strats, and conform to the pyramiding rules which act as a filter for them. The “Filter must allow entry” selection must be chosen if you want the usual system’s filters to act as additional filtering criteria for your pyramided entries.
Hard Exits
You can choose from a variety of hard exit strats. Hard exits are exit strategies which signal trade exits on specific events, as opposed to price breaching a stop level in In-Trade Stops strategies. They are self-explanatory. The last one labelled When Take Profit Level (multiple of X) is reached is the only one that uses a level, but contrary to stops, it is above price and while it is relative because it is expressed as a multiple of X, it does not move during the trade. This is the level called Take Profit that is show when the “Show Take Profit Level” checkbox is checked in the Display section.
While stops focus on managing risk, hard exit strategies try to put the emphasis on capturing opportunity.
Slippage
You can define it as a percentage or a fixed value, with different settings for entries and exits. The entry and exit markers on the chart show the impact of slippage on the entry price (the fill).
Fees
Fees, whether expressed as a percentage of position size in and out of the trade or as a fixed value per in and out, are in the same units of currency as the capital defined in the Position Sizing section. Fees being deducted from your Capital, they do not have an impact on the chart marker positions.
In-Trade Events
These events will only trigger during trades. They can be helpful to act as reminders for traders using the Engine as assistance to discretionary trading.
Post-Exit Analysis
It is normally on. Some of its results will show in the Global Numbers section of the Data Window. Only a few of the statistics generated are shown; many more are available, but commented out in the Plot module.
Date Range Filtering
Note that you don’t have to change the dates to enable/diable filtering. When you are done with a specific date range, just uncheck “Date Range Filtering” to disable date filtering.
Alert Triggers
Each selection corresponds to one condition. Conditions can be combined into a single alert as you please. Just be sure you have selected the ones you want to trigger the alert before you create the alert. For example, if you trade in both directions and you want a single alert to trigger on both types of exits, you must select both “Long Exit” and “Short Exit” before creating your alert.
Once the alert is triggered, these settings no longer have relevance as they have been saved with the alert.
When viewing charts where an alert has just triggered, if your alert triggers on more than one condition, you will need the appropriate markers active on your chart to figure out which condition triggered the alert, since plotting of markers is independent of alert management.
Position sizing
You have 3 options to determine position size:
1. Proportional to Stop -> Variable, with a cap on size.
2. Percentage of equity -> Variable.
3. Percentage of Initial Capital -> Fixed.
External Indicator
This is where you connect your indicator’s plot that will generate the signals the Engine will act upon. Remember this only works in Indicator mode.
DATA WINDOW INFORMATION
The top part of the window contains global numbers while the individual trade information appears in the bottom part. The different types of units used to express values are:
curr: denotes the currency used in the Position Sizing section of Inputs for the Initial Capital value.
quote: denotes quote currency, i.e. the value the instrument is expressed in, or the right side of the market pair (USD in EURUSD ).
X: the stop’s amplitude, itself expressed in quote currency, which we use to express a trade’s P&L, so that a trade with P&L=2X has made twice the stop’s amplitude in profit. This is sometimes referred to as R, since it represents one unit of risk. It is also the unit of measure used in the APPT, which denotes expected reward per unit of risk.
X%: is also the stop’s amplitude, but expressed as a percentage of the Entry Fill.
The numbers appearing in the Data Window are all prefixed:
“ALL:” the number is the average for all first entries and pyramided entries.
”1ST:” the number is for first entries only.
”PYR:” the number is for pyramided entries only.
”PEA:” the number is for Post-Exit Analyses
Global Numbers
Numbers in this section represent the results of all trades up to the cursor on the chart.
Average Profitability Per Trade (X): This value is the most important gauge of your strat’s worthiness. It represents the returns that can be expected from your strat for each unit of risk incurred. E.g.: your APPT is 2.0, thus for every unit of currency you invest in a trade, you can on average expect to obtain 2 after the trade. APPT is also referred to as “statistical expectancy”. If it is negative, your strategy is losing, even if your win rate is very good (it means your winning trades aren’t winning enough, or your losing trades lose too much, or both). Its counterpart in currency is also shown, as is the APPT/bar, which can be a useful gauge in deciding between rivalling systems.
Profit Factor: Gross of winning trades/Gross of losing trades. Strategy is profitable when >1. Not as useful as the APPT because it doesn’t take into account the win rate and the average win/loss per trade. It is calculated from the total winning/losing results of this particular backtest and has less predictive value than the APPT. A good profit factor together with a poor APPT means you just found a chart where your system outperformed. Relying too much on the profit factor is a bit like a poker player who would think going all in with two’s against aces is optimal because he just won a hand that way.
Win Rate: Percentage of winning trades out of all trades. Taken alone, it doesn’t have much to do with strategy profitability. You can have a win rate of 99% but if that one trade in 100 ruins you because of poor risk management, 99% doesn’t look so good anymore. This number speaks more of the system’s profile than its worthiness. Still, it can be useful to gauge if the system fits your personality. It can also be useful to traders intending to sell their systems, as low win rate systems are more difficult to sell and require more handholding of worried customers.
Equity (curr): This the sum of initial capital and the P&L of your system’s trades, including fees and slippage.
Return on Capital is the equivalent of TV’s Net Profit figure, i.e. the variation on your initial capital.
Maximum drawdown is the maximal drawdown from the highest equity point until the drop . There is also a close to close (meaning it doesn’t take into account in-trade variations) maximum drawdown value commented out in the code.
The next values are self-explanatory, until:
PYR: Avg Profitability Per Entry (X): this is the APPT for all pyramided entries.
PEA: Avg Max Opp . Available (X): the average maximal opportunity found in the Post-Exit Analyses.
PEA: Avg Drawdown to Max Opp . (X): this represents the maximum drawdown (incurred from the close at the beginning of the PEA analysis) required to reach the maximal opportunity point.
Trade Information
Numbers in this section concern only the current trade under the cursor. Most of them are self-explanatory. Use the description’s prefix to determine what the values applies to.
PYR: Avg Profitability Per Entry (X): While this value includes the impact of all current pyramided entries (and only those) and updates when you move your cursor around, P&L only reflects fees at the trade’s last bar.
PEA: Max Opp . Available (X): It’s the most profitable close reached post-trade, measured from the trade’s Exit Fill, expressed in the X value of the trade the PEA follows.
PEA: Drawdown to Max Opp . (X): This is the maximum drawdown from the trade’s Exit Fill that needs to be sustained in order to reach the maximum opportunity point, also expressed in X. Note that PEA numbers do not include slippage and fees.
EXTERNAL SIGNAL PROTOCOL
Only one external indicator can be connected to a script; in order to leverage its use to the fullest, the engine provides options to use it as either an entry signal, an entry/exit signal or a filter. When used as an entry signal, you can also use the signal to provide the entry’s stop. Here’s how this works:
For filter state: supply +1 for bull (long entries allowed), -1 for bear (short entries allowed).
For entry signals: supply +2 for long, -2 for short.
For exit signals: supply +3 for exit from long, -3 for exit from short.
To send an entry stop level with an entry signal: Send positive stop level for long entry (e.g. 103.33 to enter a long with a stop at 103.33), negative stop level for short entry (e.g. -103.33 to enter a short with a stop at 103.33). If you use this feature, your indicator will have to check for exact stop levels of 1.0, 2.0 or 3.0 and their negative counterparts, and fudge them with a tick in order to avoid confusion with other signals in the protocol.
Remember that mere generation of the values by your indicator will have no effect until you explicitly allow their use in the appropriate sections of the Engine’s Settings/Inputs.
An example of a script issuing a signal for the Engine is published by PineCoders.
RECOMMENDATIONS TO ASPIRING SYSTEM DESIGNERS
Stick to higher timeframes. On progressively lower timeframes, margins decrease and fees and slippage take a proportionally larger portion of profits, to the point where they can very easily turn a profitable strategy into a losing one. Additionally, your margin for error shrinks as the equilibrium of your system’s profitability becomes more fragile with the tight numbers involved in the shorter time frames. Avoid <1H time frames.
Know and calculate fees and slippage. To avoid market shock, backtest using conservative fees and slippage parameters. Systems rarely show unexpectedly good returns when they are confronted to the markets, so put all chances on your side by being outrageously conservative—or a the very least, realistic. Test results that do not include fees and slippage are worthless. Slippage is there for a reason, and that’s because our interventions in the market change the market. It is easier to find alpha in illiquid markets such as cryptos because not many large players participate in them. If your backtesting results are based on moving large positions and you don’t also add the inevitable slippage that will occur when you enter/exit thin markets, your backtesting will produce unrealistic results. Even if you do include large slippage in your settings, the Engine can only do so much as it will not let slippage push fills past the high or low of the entry bar, but the gap may be much larger in illiquid markets.
Never test and optimize your system on the same dataset , as that is the perfect recipe for overfitting or data dredging, which is trying to find one precise set of rules/parameters that works only on one dataset. These setups are the most fragile and often get destroyed when they meet the real world.
Try to find datasets yielding more than 100 trades. Less than that and results are not as reliable.
Consider all backtesting results with suspicion. If you never entertained sceptic tendencies, now is the time to begin. If your backtest results look really good, assume they are flawed, either because of your methodology, the data you’re using or the software doing the testing. Always assume the worse and learn proper backtesting techniques such as monte carlo simulations and walk forward analysis to avoid the traps and biases that unchecked greed will set for you. If you are not familiar with concepts such as survivor bias, lookahead bias and confirmation bias, learn about them.
Stick to simple bars or candles when designing systems. Other types of bars often do not yield reliable results, whether by design (Heikin Ashi) or because of the way they are implemented on TV (Renko bars).
Know that you don’t know and use that knowledge to learn more about systems and how to properly test them, about your biases, and about yourself.
Manage risk first , then capture opportunity.
Respect the inherent uncertainty of the future. Cleanse yourself of the sad arrogance and unchecked greed common to newcomers to trading. Strive for rationality. Respect the fact that while backtest results may look promising, there is no guarantee they will repeat in the future (there is actually a high probability they won’t!), because the future is fundamentally unknowable. If you develop a system that looks promising, don’t oversell it to others whose greed may lead them to entertain unreasonable expectations.
Have a plan. Understand what king of trading system you are trying to build. Have a clear picture or where entries, exits and other important levels will be in the sort of trade you are trying to create with your system. This stated direction will help you discard more efficiently many of the inevitably useless ideas that will pop up during system design.
Be wary of complexity. Experienced systems engineers understand how rapidly complexity builds when you assemble components together—however simple each one may be. The more complex your system, the more difficult it will be to manage.
Play! . Allow yourself time to play around when you design your systems. While much comes about from working with a purpose, great ideas sometimes come out of just trying things with no set goal, when you are stuck and don’t know how to move ahead. Have fun!
@LucF
NOTES
While the engine’s code can supply multiple consecutive entries of longs or shorts in order to scale positions (pyramid), all exits currently assume the execution bot will exit the totality of the position. No partial exits are currently possible with the Engine.
Because the Engine is literally crippled by the limitations on the number of plots a script can output on TV; it can only show a fraction of all the information it calculates in the Data Window. You will find in the Plot Module vast amounts of commented out lines that you can activate if you also disable an equivalent number of other plots. This may be useful to explore certain characteristics of your system in more detail.
When backtesting using the TV backtesting feature, you will need to provide the strategy parameters you wish to use through either Settings/Properties or by changing the default values in the code’s header. These values are defined in variables and used not only in the strategy() statement, but also as defaults in the Engine’s relevant Inputs.
If you want to test using pyramiding, then both the strategy’s Setting/Properties and the Engine’s Settings/Inputs need to allow pyramiding.
If you find any bugs in the Engine, please let us know.
THANKS
To @glaz for allowing the use of his unpublished MA Squize in the filters.
To @everget for his Chandelier stop code, which is also used as a filter in the Engine.
To @RicardoSantos for his pseudo-random generator, and because it’s from him that I first read in the Pine chat about the idea of using an external indicator as input into another. In the PineCoders group, @theheirophant then mentioned the idea of using it as a buy/sell signal and @simpelyfe showed a piece of code implementing the idea. That’s the tortuous story behind the use of the external indicator in the Engine.
To @admin for the Volatility stop’s original code and for the donchian function lifted from Ichimoku .
To @BobHoward21 for the v3 version of Volatility Stop .
To @scarf and @midtownsk8rguy for the color tuning.
To many other scripters who provided encouragement and suggestions for improvement during the long process of writing and testing this piece of code.
To J. Welles Wilder Jr. for ATR, used extensively throughout the Engine.
To TradingView for graciously making an account available to PineCoders.
And finally, to all fellow PineCoders for the constant intellectual stimulation; it is a privilege to share ideas with you all. The Engine is for all TradingView PineCoders, of course—but especially for you.
Look first. Then leap.
Quantum Flux Universal Strategy Summary in one paragraph
Quantum Flux Universal is a regime switching strategy for stocks, ETFs, index futures, major FX pairs, and liquid crypto on intraday and swing timeframes. It helps you act only when the normalized core signal and its guide agree on direction. It is original because the engine fuses three adaptive drivers into the smoothing gains itself. Directional intensity is measured with binary entropy, path efficiency shapes trend quality, and a volatility squash preserves contrast. Add it to a clean chart, watch the polarity lane and background, and trade from positive or negative alignment. For conservative workflows use on bar close in the alert settings when you add alerts in a later version.
Scope and intent
• Markets. Large cap equities and ETFs. Index futures. Major FX pairs. Liquid crypto
• Timeframes. One minute to daily
• Default demo used in the publication. QQQ on one hour
• Purpose. Provide a robust and portable way to detect when momentum and confirmation align, while dampening chop and preserving turns
• Limits. This is a strategy. Orders are simulated on standard candles only
Originality and usefulness
• Unique concept or fusion. The novelty sits in the gain map. Instead of gating separate indicators, the model mixes three drivers into the adaptive gains that power two one pole filters. Directional entropy measures how one sided recent movement has been. Kaufman style path efficiency scores how direct the path has been. A volatility squash stabilizes step size. The drivers are blended into the gains with visible inputs for strength, windows, and clamps.
• What failure mode it addresses. False starts in chop and whipsaw after fast spikes. Efficiency and the squash reduce over reaction in noise.
• Testability. Every component has an input. You can lengthen or shorten each window and change the normalization mode. The polarity plot and background provide a direct readout of state.
• Portable yardstick. The core is normalized with three options. Z score, percent rank mapped to a symmetric range, and MAD based Z score. Clamp bounds define the effective unit so context transfers across symbols.
Method overview in plain language
The strategy computes two smoothed tracks from the chart price source. The fast track and the slow track use gains that are not fixed. Each gain is modulated by three drivers. A driver for directional intensity, a driver for path efficiency, and a driver for volatility. The difference between the fast and the slow tracks forms the raw flux. A small phase assist reduces lag by subtracting a portion of the delayed value. The flux is then normalized. A guide line is an EMA of a small lead on the flux. When the flux and its guide are both above zero, the polarity is positive. When both are below zero, the polarity is negative. Polarity changes create the trade direction.
Base measures
• Return basis. The step is the change in the chosen price source. Its absolute value feeds the volatility estimate. Mean absolute step over the window gives a stable scale.
• Efficiency basis. The ratio of net move to the sum of absolute step over the window gives a value between zero and one. High values mean trend quality. Low values mean chop.
• Intensity basis. The fraction of up moves over the window plugs into binary entropy. Intensity is one minus entropy, which maps to zero in uncertainty and one in very one sided moves.
Components
• Directional Intensity. Measures how one sided recent bars have been. Smoothed with RMA. More intensity increases the gain and makes the fast and slow tracks react sooner.
• Path Efficiency. Measures the straightness of the price path. A gamma input shapes the curve so you can make trend quality count more or less. Higher efficiency lifts the gain in clean trends.
• Volatility Squash. Normalizes the absolute step with Z score then pushes it through an arctangent squash. This caps the effect of spikes so they do not dominate the response.
• Normalizer. Three modes. Z score for familiar units, percent rank for a robust monotone map to a symmetric range, and MAD based Z for outlier resistance.
• Guide Line. EMA of the flux with a small lead term that counteracts lag without heavy overshoot.
Fusion rule
• Weighted sum of the three drivers with fixed weights visible in the code comments. Intensity has fifty percent weight. Efficiency thirty percent. Volatility twenty percent.
• The blend power input scales the driver mix. Zero means fixed spans. One means full driver control.
• Minimum and maximum gain clamps bound the adaptive gain. This protects stability in quiet or violent regimes.
Signal rule
• Long suggestion appears when flux and guide are both above zero. That sets polarity to plus one.
• Short suggestion appears when flux and guide are both below zero. That sets polarity to minus one.
• When polarity flips from plus to minus, the strategy closes any long and enters a short.
• When flux crosses above the guide, the strategy closes any short.
What you will see on the chart
• White polarity plot around the zero line
• A dotted reference line at zero named Zen
• Green background tint for positive polarity and red background tint for negative polarity
• Strategy long and short markers placed by the TradingView engine at entry and at close conditions
• No table in this version to keep the visual clean and portable
Inputs with guidance
Setup
• Price source. Default ohlc4. Stable for noisy symbols.
• Fast span. Typical range 6 to 24. Raising it slows the fast track and can reduce churn. Lowering it makes entries more reactive.
• Slow span. Typical range 20 to 60. Raising it lengthens the baseline horizon. Lowering it brings the slow track closer to price.
Logic
• Guide span. Typical range 4 to 12. A small guide smooths without eating turns.
• Blend power. Typical range 0.25 to 0.85. Raising it lets the drivers modulate gains more. Lowering it pushes behavior toward fixed EMA style smoothing.
• Vol window. Typical range 20 to 80. Larger values calm the volatility driver. Smaller values adapt faster in intraday work.
• Efficiency window. Typical range 10 to 60. Larger values focus on smoother trends. Smaller values react faster but accept more noise.
• Efficiency gamma. Typical range 0.8 to 2.0. Above one increases contrast between clean trends and chop. Below one flattens the curve.
• Min alpha multiplier. Typical range 0.30 to 0.80. Lower values increase smoothing when the mix is weak.
• Max alpha multiplier. Typical range 1.2 to 3.0. Higher values shorten smoothing when the mix is strong.
• Normalization window. Typical range 100 to 300. Larger values reduce drift in the baseline.
• Normalization mode. Z score, percent rank, or MAD Z. Use MAD Z for outlier heavy symbols.
• Clamp level. Typical range 2.0 to 4.0. Lower clamps reduce the influence of extreme runs.
Filters
• Efficiency filter is implicit in the gain map. Raising efficiency gamma and the efficiency window increases the preference for clean trends.
• Micro versus macro relation is handled by the fast and slow spans. Increase separation for swing, reduce for scalping.
• Location filter is not included in v1.0. If you need distance gates from a reference such as VWAP or a moving mean, add them before publication of a new version.
Alerts
• This version does not include alertcondition lines to keep the core minimal. If you prefer alerts, add names Long Polarity Up, Short Polarity Down, Exit Short on Flux Cross Up in a later version and select on bar close for conservative workflows.
Strategy has been currently adapted for the QQQ asset with 30/60min timeframe.
For other assets may require new optimization
Properties visible in this publication
• Initial capital 25000
• Base currency Default
• Default order size method percent of equity with value 5
• Pyramiding 1
• Commission 0.05 percent
• Slippage 10 ticks
• Process orders on close ON
• Bar magnifier ON
• Recalculate after order is filled OFF
• Calc on every tick OFF
Honest limitations and failure modes
• Past results do not guarantee future outcomes
• Economic releases, circuit breakers, and thin books can break the assumptions behind intensity and efficiency
• Gap heavy symbols may benefit from the MAD Z normalization
• Very quiet regimes can reduce signal contrast. Use longer windows or higher guide span to stabilize context
• Session time is the exchange time of the chart
• If both stop and target can be hit in one bar, tie handling would matter. This strategy has no fixed stops or targets. It uses polarity flips for exits. If you add stops later, declare the preference
Open source reuse and credits
• None beyond public domain building blocks and Pine built ins such as EMA, SMA, standard deviation, RMA, and percent rank
• Method and fusion are original in construction and disclosure
Legal
Education and research only. Not investment advice. You are responsible for your decisions. Test on historical data and in simulation before any live use. Use realistic costs.
Strategy add on block
Strategy notice
Orders are simulated by the TradingView engine on standard candles. No request.security() calls are used.
Entries and exits
• Entry logic. Enter long when both the normalized flux and its guide line are above zero. Enter short when both are below zero
• Exit logic. When polarity flips from plus to minus, close any long and open a short. When the flux crosses above the guide line, close any short
• Risk model. No initial stop or target in v1.0. The model is a regime flipper. You can add a stop or trail in later versions if needed
• Tie handling. Not applicable in this version because there are no fixed stops or targets
Position sizing
• Percent of equity in the Properties panel. Five percent is the default for examples. Risk per trade should not exceed five to ten percent of equity. One to two percent is a common choice
Properties used on the published chart
• Initial capital 25000
• Base currency Default
• Default order size percent of equity with value 5
• Pyramiding 1
• Commission 0.05 percent
• Slippage 10 ticks
• Process orders on close ON
• Bar magnifier ON
• Recalculate after order is filled OFF
• Calc on every tick OFF
Dataset and sample size
• Test window Jan 2, 2014 to Oct 16, 2025 on QQQ one hour
• Trade count in sample 324 on the example chart
Release notes template for future updates
Version 1.1.
• Add alertcondition lines for long, short, and exit short
• Add optional table with component readouts
• Add optional stop model with a distance unit expressed as ATR or a percent of price
Notes. Backward compatibility Yes. Inputs migrated Yes.
Vector2Library "Vector2"
Representation of two dimensional vectors or points.
This structure is used to represent positions in two dimensional space or vectors,
for example in spacial coordinates in 2D space.
~~~
references:
docs.unity3d.com
gist.github.com
github.com
gist.github.com
gist.github.com
gist.github.com
~~~
new(x, y)
Create a new Vector2 object.
Parameters:
x : float . The x value of the vector, default=0.
y : float . The y value of the vector, default=0.
Returns: Vector2. Vector2 object.
-> usage:
`unitx = Vector2.new(1.0) , plot(unitx.x)`
from(value)
Assigns value to a new vector `x,y` elements.
Parameters:
value : float, x and y value of the vector.
Returns: Vector2. Vector2 object.
-> usage:
`one = Vector2.from(1.0), plot(one.x)`
from(value, element_sep, open_par, close_par)
Assigns value to a new vector `x,y` elements.
Parameters:
value : string . The `x` and `y` value of the vector in a `x,y` or `(x,y)` format, spaces and parentesis will be removed automatically.
element_sep : string . Element separator character, default=`,`.
open_par : string . Open parentesis character, default=`(`.
close_par : string . Close parentesis character, default=`)`.
Returns: Vector2. Vector2 object.
-> usage:
`one = Vector2.from("1.0,2"), plot(one.x)`
copy(this)
Creates a deep copy of a vector.
Parameters:
this : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = Vector2.new(1.0) , b = a.copy() , plot(b.x)`
down()
Vector in the form `(0, -1)`.
Returns: Vector2. Vector2 object.
left()
Vector in the form `(-1, 0)`.
Returns: Vector2. Vector2 object.
right()
Vector in the form `(1, 0)`.
Returns: Vector2. Vector2 object.
up()
Vector in the form `(0, 1)`.
Returns: Vector2. Vector2 object.
one()
Vector in the form `(1, 1)`.
Returns: Vector2. Vector2 object.
zero()
Vector in the form `(0, 0)`.
Returns: Vector2. Vector2 object.
minus_one()
Vector in the form `(-1, -1)`.
Returns: Vector2. Vector2 object.
unit_x()
Vector in the form `(1, 0)`.
Returns: Vector2. Vector2 object.
unit_y()
Vector in the form `(0, 1)`.
Returns: Vector2. Vector2 object.
nan()
Vector in the form `(float(na), float(na))`.
Returns: Vector2. Vector2 object.
xy(this)
Return the values of `x` and `y` as a tuple.
Parameters:
this : Vector2 . Vector2 object.
Returns: .
-> usage:
`a = Vector2.new(1.0, 1.0) , = a.xy() , plot(ax)`
length_squared(this)
Length of vector `a` in the form. `a.x^2 + a.y^2`, for comparing vectors this is computationaly lighter.
Parameters:
this : Vector2 . Vector2 object.
Returns: float. Squared length of vector.
-> usage:
`a = Vector2.new(1.0, 1.0) , plot(a.length_squared())`
length(this)
Magnitude of vector `a` in the form. `sqrt(a.x^2 + a.y^2)`
Parameters:
this : Vector2 . Vector2 object.
Returns: float. Length of vector.
-> usage:
`a = Vector2.new(1.0, 1.0) , plot(a.length())`
normalize(a)
Vector normalized with a magnitude of 1, in the form. `a / length(a)`.
Parameters:
a : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = normalize(Vector2.new(3.0, 2.0)) , plot(a.y)`
isNA(this)
Checks if any of the components is `na`.
Parameters:
this : Vector2 . Vector2 object.
Returns: bool.
usage:
p = Vector2.new(1.0, na) , plot(isNA(p)?1:0)
add(a, b)
Adds vector `b` to `a`, in the form `(a.x + b.x, a.y + b.y)`.
Parameters:
a : Vector2 . Vector2 object.
b : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = one() , b = one() , c = add(a, b) , plot(c.x)`
add(a, b)
Adds vector `b` to `a`, in the form `(a.x + b, a.y + b)`.
Parameters:
a : Vector2 . Vector2 object.
b : float . Value.
Returns: Vector2. Vector2 object.
-> usage:
`a = one() , b = 1.0 , c = add(a, b) , plot(c.x)`
add(a, b)
Adds vector `b` to `a`, in the form `(a + b.x, a + b.y)`.
Parameters:
a : float . Value.
b : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = 1.0 , b = one() , c = add(a, b) , plot(c.x)`
subtract(a, b)
Subtract vector `b` from `a`, in the form `(a.x - b.x, a.y - b.y)`.
Parameters:
a : Vector2 . Vector2 object.
b : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = one() , b = one() , c = subtract(a, b) , plot(c.x)`
subtract(a, b)
Subtract vector `b` from `a`, in the form `(a.x - b, a.y - b)`.
Parameters:
a : Vector2 . vector2 object.
b : float . Value.
Returns: Vector2. Vector2 object.
-> usage:
`a = one() , b = 1.0 , c = subtract(a, b) , plot(c.x)`
subtract(a, b)
Subtract vector `b` from `a`, in the form `(a - b.x, a - b.y)`.
Parameters:
a : float . value.
b : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = 1.0 , b = one() , c = subtract(a, b) , plot(c.x)`
multiply(a, b)
Multiply vector `a` with `b`, in the form `(a.x * b.x, a.y * b.y)`.
Parameters:
a : Vector2 . Vector2 object.
b : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = one() , b = one() , c = multiply(a, b) , plot(c.x)`
multiply(a, b)
Multiply vector `a` with `b`, in the form `(a.x * b, a.y * b)`.
Parameters:
a : Vector2 . Vector2 object.
b : float . Value.
Returns: Vector2. Vector2 object.
-> usage:
`a = one() , b = 1.0 , c = multiply(a, b) , plot(c.x)`
multiply(a, b)
Multiply vector `a` with `b`, in the form `(a * b.x, a * b.y)`.
Parameters:
a : float . Value.
b : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = 1.0 , b = one() , c = multiply(a, b) , plot(c.x)`
divide(a, b)
Divide vector `a` with `b`, in the form `(a.x / b.x, a.y / b.y)`.
Parameters:
a : Vector2 . Vector2 object.
b : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = from(3.0) , b = from(2.0) , c = divide(a, b) , plot(c.x)`
divide(a, b)
Divide vector `a` with value `b`, in the form `(a.x / b, a.y / b)`.
Parameters:
a : Vector2 . Vector2 object.
b : float . Value.
Returns: Vector2. Vector2 object.
-> usage:
`a = from(3.0) , b = 2.0 , c = divide(a, b) , plot(c.x)`
divide(a, b)
Divide value `a` with vector `b`, in the form `(a / b.x, a / b.y)`.
Parameters:
a : float . Value.
b : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = 3.0 , b = from(2.0) , c = divide(a, b) , plot(c.x)`
negate(a)
Negative of vector `a`, in the form `(-a.x, -a.y)`.
Parameters:
a : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = from(3.0) , b = a.negate , plot(b.x)`
pow(a, b)
Raise vector `a` with exponent vector `b`, in the form `(a.x ^ b.x, a.y ^ b.y)`.
Parameters:
a : Vector2 . Vector2 object.
b : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = from(3.0) , b = from(2.0) , c = pow(a, b) , plot(c.x)`
pow(a, b)
Raise vector `a` with value `b`, in the form `(a.x ^ b, a.y ^ b)`.
Parameters:
a : Vector2 . Vector2 object.
b : float . Value.
Returns: Vector2. Vector2 object.
-> usage:
`a = from(3.0) , b = 2.0 , c = pow(a, b) , plot(c.x)`
pow(a, b)
Raise value `a` with vector `b`, in the form `(a ^ b.x, a ^ b.y)`.
Parameters:
a : float . Value.
b : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = 3.0 , b = from(2.0) , c = pow(a, b) , plot(c.x)`
sqrt(a)
Square root of the elements in a vector.
Parameters:
a : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = from(3.0) , b = sqrt(a) , plot(b.x)`
abs(a)
Absolute properties of the vector.
Parameters:
a : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = from(-3.0) , b = abs(a) , plot(b.x)`
min(a)
Lowest element of a vector.
Parameters:
a : Vector2 . Vector2 object.
Returns: float.
-> usage:
`a = new(3.0, 1.5) , b = min(a) , plot(b)`
max(a)
Highest element of a vector.
Parameters:
a : Vector2 . Vector2 object.
Returns: float.
-> usage:
`a = new(3.0, 1.5) , b = max(a) , plot(b)`
vmax(a, b)
Highest elements of two vectors.
Parameters:
a : Vector2 . Vector2 object.
b : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = new(3.0, 2.0) , b = new(2.0, 3.0) , c = vmax(a, b) , plot(c.x)`
vmax(a, b, c)
Highest elements of three vectors.
Parameters:
a : Vector2 . Vector2 object.
b : Vector2 . Vector2 object.
c : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = new(3.0, 2.0) , b = new(2.0, 3.0) , c = new(1.5, 4.5) , d = vmax(a, b, c) , plot(d.x)`
vmin(a, b)
Lowest elements of two vectors.
Parameters:
a : Vector2 . Vector2 object.
b : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = new(3.0, 2.0) , b = new(2.0, 3.0) , c = vmin(a, b) , plot(c.x)`
vmin(a, b, c)
Lowest elements of three vectors.
Parameters:
a : Vector2 . Vector2 object.
b : Vector2 . Vector2 object.
c : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = new(3.0, 2.0) , b = new(2.0, 3.0) , c = new(1.5, 4.5) , d = vmin(a, b, c) , plot(d.x)`
perp(a)
Perpendicular Vector of `a`, in the form `(a.y, -a.x)`.
Parameters:
a : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = new(3.0, 1.5) , b = perp(a) , plot(b.x)`
floor(a)
Compute the floor of vector `a`.
Parameters:
a : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = new(3.0, 1.5) , b = floor(a) , plot(b.x)`
ceil(a)
Ceils vector `a`.
Parameters:
a : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = new(3.0, 1.5) , b = ceil(a) , plot(b.x)`
ceil(a, digits)
Ceils vector `a`.
Parameters:
a : Vector2 . Vector2 object.
digits : int . Digits to use as ceiling.
Returns: Vector2. Vector2 object.
round(a)
Round of vector elements.
Parameters:
a : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = new(3.0, 1.5) , b = round(a) , plot(b.x)`
round(a, precision)
Round of vector elements.
Parameters:
a : Vector2 . Vector2 object.
precision : int . Number of digits to round vector "a" elements.
Returns: Vector2. Vector2 object.
-> usage:
`a = new(0.123456, 1.234567) , b = round(a, 2) , plot(b.x)`
fractional(a)
Compute the fractional part of the elements from vector `a`.
Parameters:
a : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = new(3.123456, 1.23456) , b = fractional(a) , plot(b.x)`
dot_product(a, b)
dot_product product of 2 vectors, in the form `a.x * b.x + a.y * b.y.
Parameters:
a : Vector2 . Vector2 object.
b : Vector2 . Vector2 object.
Returns: float.
-> usage:
`a = new(3.0, 1.5) , b = from(2.0) , c = dot_product(a, b) , plot(c)`
cross_product(a, b)
cross product of 2 vectors, in the form `a.x * b.y - a.y * b.x`.
Parameters:
a : Vector2 . Vector2 object.
b : Vector2 . Vector2 object.
Returns: float.
-> usage:
`a = new(3.0, 1.5) , b = from(2.0) , c = cross_product(a, b) , plot(c)`
equals(a, b)
Compares two vectors
Parameters:
a : Vector2 . Vector2 object.
b : Vector2 . Vector2 object.
Returns: bool. Representing the equality.
-> usage:
`a = new(3.0, 1.5) , b = from(2.0) , c = equals(a, b) ? 1 : 0 , plot(c)`
sin(a)
Compute the sine of argument vector `a`.
Parameters:
a : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = new(3.0, 1.5) , b = sin(a) , plot(b.x)`
cos(a)
Compute the cosine of argument vector `a`.
Parameters:
a : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = new(3.0, 1.5) , b = cos(a) , plot(b.x)`
tan(a)
Compute the tangent of argument vector `a`.
Parameters:
a : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = new(3.0, 1.5) , b = tan(a) , plot(b.x)`
atan2(x, y)
Approximation to atan2 calculation, arc tangent of `y/x` in the range (-pi,pi) radians.
Parameters:
x : float . The x value of the vector.
y : float . The y value of the vector.
Returns: float. Value with angle in radians. (negative if quadrante 3 or 4)
-> usage:
`a = new(3.0, 1.5) , b = atan2(a.x, a.y) , plot(b)`
atan2(a)
Approximation to atan2 calculation, arc tangent of `y/x` in the range (-pi,pi) radians.
Parameters:
a : Vector2 . Vector2 object.
Returns: float, value with angle in radians. (negative if quadrante 3 or 4)
-> usage:
`a = new(3.0, 1.5) , b = atan2(a) , plot(b)`
distance(a, b)
Distance between vector `a` and `b`.
Parameters:
a : Vector2 . Vector2 object.
b : Vector2 . Vector2 object.
Returns: float.
-> usage:
`a = new(3.0, 1.5) , b = from(2.0) , c = distance(a, b) , plot(c)`
rescale(a, length)
Rescale a vector to a new magnitude.
Parameters:
a : Vector2 . Vector2 object.
length : float . Magnitude.
Returns: Vector2. Vector2 object.
-> usage:
`a = new(3.0, 1.5) , b = 2.0 , c = rescale(a, b) , plot(c.x)`
rotate(a, radians)
Rotates vector by a angle.
Parameters:
a : Vector2 . Vector2 object.
radians : float . Angle value in radians.
Returns: Vector2. Vector2 object.
-> usage:
`a = new(3.0, 1.5) , b = 2.0 , c = rotate(a, b) , plot(c.x)`
rotate_degree(a, degree)
Rotates vector by a angle.
Parameters:
a : Vector2 . Vector2 object.
degree : float . Angle value in degrees.
Returns: Vector2. Vector2 object.
-> usage:
`a = new(3.0, 1.5) , b = 45.0 , c = rotate_degree(a, b) , plot(c.x)`
rotate_around(this, center, angle)
Rotates vector `target` around `origin` by angle value.
Parameters:
this
center : Vector2 . Vector2 object.
angle : float . Angle value in degrees.
Returns: Vector2. Vector2 object.
-> usage:
`a = new(3.0, 1.5) , b = from(2.0) , c = rotate_around(a, b, 45.0) , plot(c.x)`
perpendicular_distance(a, b, c)
Distance from point `a` to line between `b` and `c`.
Parameters:
a : Vector2 . Vector2 object.
b : Vector2 . Vector2 object.
c : Vector2 . Vector2 object.
Returns: float.
-> usage:
`a = new(1.5, 2.6) , b = from(1.0) , c = from(3.0) , d = perpendicular_distance(a, b, c) , plot(d.x)`
project(a, axis)
Project a vector onto another.
Parameters:
a : Vector2 . Vector2 object.
axis : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = new(3.0, 1.5) , b = from(2.0) , c = project(a, b) , plot(c.x)`
projectN(a, axis)
Project a vector onto a vector of unit length.
Parameters:
a : Vector2 . Vector2 object.
axis : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = new(3.0, 1.5) , b = from(2.0) , c = projectN(a, b) , plot(c.x)`
reflect(a, axis)
Reflect a vector on another.
Parameters:
a : Vector2 . Vector2 object.
axis
Returns: Vector2. Vector2 object.
-> usage:
`a = new(3.0, 1.5) , b = from(2.0) , c = reflect(a, b) , plot(c.x)`
reflectN(a, axis)
Reflect a vector to a arbitrary axis.
Parameters:
a : Vector2 . Vector2 object.
axis
Returns: Vector2. Vector2 object.
-> usage:
`a = new(3.0, 1.5) , b = from(2.0) , c = reflectN(a, b) , plot(c.x)`
angle(a)
Angle in radians of a vector.
Parameters:
a : Vector2 . Vector2 object.
Returns: float.
-> usage:
`a = new(3.0, 1.5) , b = angle(a) , plot(b)`
angle_unsigned(a, b)
unsigned degree angle between 0 and +180 by given two vectors.
Parameters:
a : Vector2 . Vector2 object.
b : Vector2 . Vector2 object.
Returns: float.
-> usage:
`a = new(3.0, 1.5) , b = from(2.0) , c = angle_unsigned(a, b) , plot(c)`
angle_signed(a, b)
Signed degree angle between -180 and +180 by given two vectors.
Parameters:
a : Vector2 . Vector2 object.
b : Vector2 . Vector2 object.
Returns: float.
-> usage:
`a = new(3.0, 1.5) , b = from(2.0) , c = angle_signed(a, b) , plot(c)`
angle_360(a, b)
Degree angle between 0 and 360 by given two vectors
Parameters:
a : Vector2 . Vector2 object.
b : Vector2 . Vector2 object.
Returns: float.
-> usage:
`a = new(3.0, 1.5) , b = from(2.0) , c = angle_360(a, b) , plot(c)`
clamp(a, min, max)
Restricts a vector between a min and max value.
Parameters:
a : Vector2 . Vector2 object.
min
max
Returns: Vector2. Vector2 object.
-> usage:
`a = new(3.0, 1.5) , b = from(2.0) , c = from(2.5) , d = clamp(a, b, c) , plot(d.x)`
clamp(a, min, max)
Restricts a vector between a min and max value.
Parameters:
a : Vector2 . Vector2 object.
min : float . Lower boundary value.
max : float . Higher boundary value.
Returns: Vector2. Vector2 object.
-> usage:
`a = new(3.0, 1.5) , b = clamp(a, 2.0, 2.5) , plot(b.x)`
lerp(a, b, rate)
Linearly interpolates between vectors a and b by rate.
Parameters:
a : Vector2 . Vector2 object.
b : Vector2 . Vector2 object.
rate : float . Value between (a:-infinity -> b:1.0), negative values will move away from b.
Returns: Vector2. Vector2 object.
-> usage:
`a = new(3.0, 1.5) , b = from(2.0) , c = lerp(a, b, 0.5) , plot(c.x)`
herp(a, b, rate)
Hermite curve interpolation between vectors a and b by rate.
Parameters:
a : Vector2 . Vector2 object.
b : Vector2 . Vector2 object.
rate : Vector2 . Vector2 object. Value between (a:0 > 1:b).
Returns: Vector2. Vector2 object.
-> usage:
`a = new(3.0, 1.5) , b = from(2.0) , c = from(2.5) , d = herp(a, b, c) , plot(d.x)`
transform(position, mat)
Transform a vector by the given matrix.
Parameters:
position : Vector2 . Source vector.
mat : M32 . Transformation matrix
Returns: Vector2. Transformed vector.
transform(position, mat)
Transform a vector by the given matrix.
Parameters:
position : Vector2 . Source vector.
mat : M44 . Transformation matrix
Returns: Vector2. Transformed vector.
transform(position, mat)
Transform a vector by the given matrix.
Parameters:
position : Vector2 . Source vector.
mat : matrix . Transformation matrix, requires a 3x2 or a 4x4 matrix.
Returns: Vector2. Transformed vector.
transform(this, rotation)
Transform a vector by the given quaternion rotation value.
Parameters:
this : Vector2 . Source vector.
rotation : Quaternion . Rotation to apply.
Returns: Vector2. Transformed vector.
area_triangle(a, b, c)
Find the area in a triangle of vectors.
Parameters:
a : Vector2 . Vector2 object.
b : Vector2 . Vector2 object.
c : Vector2 . Vector2 object.
Returns: float.
-> usage:
`a = new(1.0, 2.0) , b = from(2.0) , c = from(1.0) , d = area_triangle(a, b, c) , plot(d.x)`
random(max)
2D random value.
Parameters:
max : Vector2 . Vector2 object. Vector upper boundary.
Returns: Vector2. Vector2 object.
-> usage:
`a = from(2.0) , b = random(a) , plot(b.x)`
random(max)
2D random value.
Parameters:
max : float, Vector upper boundary.
Returns: Vector2. Vector2 object.
-> usage:
`a = random(2.0) , plot(a.x)`
random(min, max)
2D random value.
Parameters:
min : Vector2 . Vector2 object. Vector lower boundary.
max : Vector2 . Vector2 object. Vector upper boundary.
Returns: Vector2. Vector2 object.
-> usage:
`a = from(1.0) , b = from(2.0) , c = random(a, b) , plot(c.x)`
random(min, max)
2D random value.
Parameters:
min : Vector2 . Vector2 object. Vector lower boundary.
max : Vector2 . Vector2 object. Vector upper boundary.
Returns: Vector2. Vector2 object.
-> usage:
`a = random(1.0, 2.0) , plot(a.x)`
noise(a)
2D Noise based on Morgan McGuire @morgan3d.
Parameters:
a : Vector2 . Vector2 object.
Returns: Vector2. Vector2 object.
-> usage:
`a = from(2.0) , b = noise(a) , plot(b.x)`
to_string(a)
Converts vector `a` to a string format, in the form `"(x, y)"`.
Parameters:
a : Vector2 . Vector2 object.
Returns: string. In `"(x, y)"` format.
-> usage:
`a = from(2.0) , l = barstate.islast ? label.new(bar_index, 0.0, to_string(a)) : label(na)`
to_string(a, format)
Converts vector `a` to a string format, in the form `"(x, y)"`.
Parameters:
a : Vector2 . Vector2 object.
format : string . Format to apply transformation.
Returns: string. In `"(x, y)"` format.
-> usage:
`a = from(2.123456) , l = barstate.islast ? label.new(bar_index, 0.0, to_string(a, "#.##")) : label(na)`
to_array(a)
Converts vector to a array format.
Parameters:
a : Vector2 . Vector2 object.
Returns: array.
-> usage:
`a = from(2.0) , b = to_array(a) , plot(array.get(b, 0))`
to_barycentric(this, a, b, c)
Captures the barycentric coordinate of a cartesian position in the triangle plane.
Parameters:
this : Vector2 . Source cartesian coordinate position.
a : Vector2 . Triangle corner `a` vertice.
b : Vector2 . Triangle corner `b` vertice.
c : Vector2 . Triangle corner `c` vertice.
Returns: bool.
from_barycentric(this, a, b, c)
Captures the cartesian coordinate of a barycentric position in the triangle plane.
Parameters:
this : Vector2 . Source barycentric coordinate position.
a : Vector2 . Triangle corner `a` vertice.
b : Vector2 . Triangle corner `b` vertice.
c : Vector2 . Triangle corner `c` vertice.
Returns: bool.
to_complex(this)
Translate a Vector2 structure to complex.
Parameters:
this : Vector2 . Source vector.
Returns: Complex.
to_polar(this)
Translate a Vector2 cartesian coordinate into polar coordinates.
Parameters:
this : Vector2 . Source vector.
Returns: Pole. The returned angle is in radians.
FluxGate Daily Swing StrategySummary in one paragraph
FluxGate treats long and short as different ecosystems. It runs two independent engines so the long side can be bold when the tape rewards upside persistence while the short side can stay selective when downside is messy. The core reads three directional drivers from price geometry then removes overlap before gating with clean path checks. The complementary risk module anchors stop distance to a higher timeframe ATR so a unit means the same thing on SPY and BTC. It can add take profit breakeven and an ATR trail that only activates after the trade earns it. If a stop is hit the strategy can re enter in the same direction on the next bar with a daily retry cap that you control. Add it to a clean chart. Use defaults to see the intended behavior. For conservative workflows evaluate on bar close.
Scope and intent
• Markets. Large cap equities and liquid ETFs major FX pairs US index futures and liquid crypto pairs
• Timeframes. From one minute to daily
• Default demo in this publication. SPY on one day timeframe
• Purpose. Reduce false starts without missing sustained trends by fusing independent drivers and suppressing activity when the path is noisy
• Limits. This is a strategy. Orders are simulated on standard candles. Non standard chart types are not supported for execution
Originality and usefulness
• Unique fusion. FluxGate extracts three drivers that look at price from different angles. Direction measures slope of a smoothed guide and scales by realized volatility so a point of slope does not mean a different thing on different symbols. Persistence looks at short sign agreement to reward series of closes that keep direction. Curvature measures the second difference of a local fit to wake up during convex pushes. These three are then orthonormalized so a strong reading in one does not double count through another.
• Gates that matter. Efficiency ratio prefers direct paths over treadmills. Entropy turns up versus down frequency into an information read. Light fractal cohesion punishes wrinkly paths. Together they slow the system in chop and allow it to open up when the path is clean.
• Separate long and short engines. Threshold tilts adapt to the skew of score excursions. That lets long engage earlier when upside distribution supports it and keeps short cautious where downside surprise and venue frictions are common.
• Practical risk behavior. Stops are ATR anchored on a higher timeframe so the unit is portable. Take profit is expressed in R so two R means the same concept across symbols. Breakeven and trailing only activate after a chosen R so early noise does not squeeze a good entry. Re entry after stop lets the system try again without you babysitting the chart.
• Testability. Every major window and the aggression controls live in Inputs. There is no hidden magic number.
Method overview in plain language
Base measures
• Return basis. Natural log of close over prior close for stability and easy aggregation through time. Realized volatility is the standard deviation of returns over a moving window.
• Range basis for risk. ATR computed on a higher timeframe anchor such as day week or month. That anchor is steady across venues and avoids chasing chart specific quirks.
Components
• Directional intensity. Use an EMA of typical price as a guide. Take the day to day slope as raw direction. Divide by realized volatility to get a unit free measure. Soft clip to keep outliers from dominating.
• Persistence. Encode whether each bar closed up or down. Measure short sign agreement so a string of higher closes scores better than a jittery sequence. This favors push continuity without guessing tops or bottoms.
• Curvature. Fit a short linear regression and compute the second difference of the fitted series. Strong curvature flags acceleration that slope alone may miss.
• Efficiency gate. Compare net move to path length over a gate window. Values near one indicate direct paths. Values near zero indicate treadmill behavior.
• Entropy gate. Convert up versus down frequency into a probability of direction. High entropy means coin toss. The gate narrows there.
• Fractal cohesion. A light read of path wrinkliness relative to span. Lower cohesion reduces the urge to act.
• Phase assist. Map price inside a recent channel to a small signed bias that grows with confidence. This helps entries lean toward the right half of the channel without becoming a breakout rule.
• Shock control. Compare short volatility to long volatility. When short term volatility spikes the shock gate temporarily damps activity so the system waits for pressure to normalize.
Fusion rule
• Normalize the three drivers after removing overlap
• Blend with weights that adapt to your aggression input
• Multiply by the gates to respect path quality
• Smooth just enough to avoid jitter while keeping timing responsive
• Compute an adaptive mean and deviation of the score and set separate long and short thresholds with a small tilt informed by skew sign
• The result is one long score and one short score that can cross their thresholds at different times for the same tape which is a feature not a bug
Signal rule
• A long suggestion appears when the long score crosses above its long threshold while all gates are active
• A short suggestion appears when the short score crosses below its short threshold while all gates are active
• If any required gate is missing the state is wait
• When a position is open the status is in long or in short until the complementary risk engine exits or your entry mode closes and flips
Inputs with guidance
Setup Long
• Base length Long. Master window for the long engine. Typical range twenty four to eighty. Raising it improves selectivity and reduces trade count. Lowering it reacts faster but can increase noise
• Aggression Long. Zero to one. Higher values make thresholds more permissive and shorten smoothing
Setup Short
• Base length Short. Master window for the short engine. Typical range twenty eight to ninety six
• Aggression Short. Zero to one. Lower values keep shorts conservative which is often useful on upward drifting symbols
Entries and UI
• Entry mode. Both or Long only or Short only
Complementary risk engine
• Enable risk engine. Turns on bracket exits while keeping your signal logic untouched
• ATR anchor timeframe. Day Week or Month. This sets the structural unit of stop distance
• ATR length. Default fourteen
• Stop multiple. Default one point five times the anchor ATR
• Use take profit. On by default
• Take profit in R. Default two R
• Breakeven trigger in R. Default one R
Usage recipes
Intraday trend focus
• Entry mode Both
• ATR anchor Week
• Aggression Long zero point five Aggression Short zero point three
• Stop multiple one point five Take profit two R
• Expect fewer trades that stick to directional pushes and skip treadmill noise
Intraday mean reversion focus
• Session windows optional if you add them in your copy
• ATR anchor Day
• Lower aggression both sides
• Breakeven later and trailing later so the first bounce has room
• This favors fade entries that still convert into trends when the path stays clean
Swing continuation
• Signal timeframe four hours or one day
• Confirm timeframe one day if you choose to include bias
• ATR anchor Week or Month
• Larger base windows and a steady two R target
• This accepts fewer entries and aims for larger holds
Properties visible in this publication
• Initial capital 25.000
• Base currency USD
• Default order size percent of equity value three - 3% of the total capital
• Pyramiding zero
• Commission zero point zero three percent - 0.03% of total capital
• Slippage five ticks
• Process orders on close off
• Recalculate after order is filled off
• Calc on every tick off
• Bar magnifier off
• Any request security calls use lookahead off everywhere
Realism and responsible publication
• No performance promises. Past results never guarantee future outcomes
• Fills and slippage vary by venue and feed
• Strategies run on standard candles only
• Shapes can update while a bar is forming and settle on close
• Keep risk per trade sensible. Around one percent is typical for study. Above five to ten percent is rarely sustainable
Honest limitations and failure modes
• Sudden news and thin liquidity can break assumptions behind entropy and cohesion reads
• Gap heavy symbols often behave better with a True Range basis for risk than a simple range
• Very quiet regimes can reduce score contrast. Consider longer windows or higher thresholds when markets sleep
• Session windows follow the exchange time of the chart if you add them
• If stop and target can both be inside a single bar this strategy prefers stop first to keep accounting conservative
Open source reuse and credits
• No reused open source beyond public domain building blocks such as ATR EMA and linear regression concepts
Legal
Education and research only. Not investment advice. You are responsible for your decisions. Test on history and in simulation with realistic costs
Outside Candle Session Breakout [CHE]Outside Candle Session Breakout
Session - anchored HTF levels for clear market-structure and precise breakout context
Summary
This indicator is a relevant market-structure tool. It anchors the session to the first higher-timeframe bar, then activates only when the second bar forms an outside condition. Price frequently reacts around these anchors, which provides precise breakout context and a clear overview on both lower and higher timeframes. Robustness comes from close-based validation, an adaptive volatility and tick buffer, first-touch enforcement, optional retest, one-signal-per-session, cooldown, and an optional trend filter.
Pine version: v6. Overlay: true.
Motivation: Why this design?
Short-term breakout tools often trigger during noise, duplicate within the same session, or drift when volatility shifts. The core idea is to gate signals behind a meaningful structure event: a first-bar anchor and a subsequent outside bar on the session timeframe. This narrows attention to structurally important breaks while adaptive buffering and debouncing reduce false or mid-run triggers.
What’s different vs. standard approaches?
Baseline: Simple high-low breaks or fixed buffers without session context.
Architecture: Session-anchored first-bar high/low; outside-bar gate; close-based confirmation with an adaptive ATR and tick buffer; first-touch enforcement; optional retest window; one-signal-per-session and cooldown; optional EMA trend and slope filter; higher-timeframe aggregation with lookahead disabled; themeable visuals and a range fill between levels.
Practical effect: Cleaner timing at structurally relevant levels, fewer redundant or late triggers, and better multi-timeframe situational awareness.
How it works (technical)
The chart timeframe is mapped to an analysis timeframe and a session timeframe.
The first session bar defines the anchor high and low. The setup becomes active only after the next bar forms an outside range relative to that first bar.
While active, the script tracks these anchors and checks for a breakout beyond a buffered threshold, using closing prices or wicks by preference.
The buffer scales with volatility and is limited by a minimum tick floor. First-touch enforcement avoids mid-run confirmations.
Optional retest requires a pullback to the raw anchor followed by a new close beyond the buffered level within a user window.
Optional trend gating uses an EMA on the analysis timeframe, including an optional slope requirement and price-location check.
Higher-timeframe data is requested with lookahead disabled. Values can update during a forming higher-timeframe bar; waiting and confirmation mitigate timing shifts.
Parameter Guide
Enable Long / Enable Short — Direction toggles. Default: true / true. Reduces unwanted side.
Wait Candles — Minimum bars after outside confirmation before entries. Default: five. More waiting increases stability.
Close-based Breakout — Confirm on candle close beyond buffer. Default: true. For wick sensitivity, disable.
ATR Buffer — Enables adaptive volatility buffer. Default: true.
ATR Multiplier — Buffer scaling. Default: zero point two. Increase to reduce noise.
Ticks Buffer — Minimum buffer in ticks. Default: two. Protects in quiet markets.
Cooldown Bars — Blocks new signals after a trigger. Default: three.
One Signal per Session — Prevents duplicates within a session. Default: true.
Require Retest — Pullback to raw anchor before confirming. Default: false.
Retest Window — Bars allowed for retest completion. Default: five.
HTF Trend Filter — EMA-based gating. Default: false.
EMA Length — EMA period. Default: two hundred.
Slope — Require EMA slope direction. Default: true.
Price Above/Below EMA — Require price location relative to EMA. Default: true.
Show Levels / Highlight Session / Show Signals — Visual controls. Default: true.
Color Theme — “Blue-Green” (default), “Monochrome”, “Earth Tones”, “Classic”, “Dark”.
Time Period Box — Visibility, size, position, and colors for the info box. (Optional)
Reading & Interpretation
The two level lines represent the session’s first-bar high and low. The filled band illustrates the active session range.
“OUT” marks that the outside condition is confirmed and the setup is live.
“LONG” or “SHORT” appears only when the breakout clears buffer, debounce, and optional gates.
Background tint indicates sessions where the setup is valid.
Alerts fire on confirmed long or short breakout events.
Practical Workflows & Combinations
Trend-following: Keep close-based validation, ATR buffer near the default, one-signal-per-session enabled; add EMA trend and slope for directional bias.
Retest confirmation: Enable retest with a short window to prioritize cleaner continuation after a pullback.
Lower-timeframe scalping: Reduce waiting and cooldown slightly; keep a small tick buffer to filter micro-whips.
Swing and position context: Increase ATR multiplier and waiting; maintain once-per-session to limit duplicates.
Timeframe Tiers and Trader Profiles
The script adapts its internal mapping based on the chart timeframe:
Under fifteen minutes → Analysis: one minute; Session: sixty minutes. Useful for scalpers and high-frequency intraday reads.
Between fifteen and under sixty minutes → Analysis: fifteen minutes; Session: one day. Suits day traders who need intraday alignment to the daily session.
Between sixty minutes and under one day → Analysis: sixty minutes; Session: one week. Serves intraday-to-swing transitions and end-of-day planning.
Between one day and under one week → Analysis: two hundred forty minutes; Session: two weeks. Fits swing traders who monitor multi-day structure.
Between one week and under thirty days → Analysis: one day; Session: three months. Supports position traders seeking quarterly context.
Thirty days and above → Analysis: one day; Session: twelve months. Provides a broad annual anchor for macro context.
These tiers are designed to keep anchors meaningful across regimes while preserving responsiveness appropriate to the trader profile.
Behavior, Constraints & Performance
Signals can be validated on closed bars through close-based logic; enabling this reduces intrabar flicker.
Higher-timeframe values may evolve during a forming bar; waiting parameters and the outside-bar gate reduce, but do not remove, this effect.
Resource footprint is light; the script uses standard indicators and a single higher-timeframe request per stream.
Known limits: rare setups during very quiet periods, sensitivity to gaps, and reduced reliability on illiquid symbols.
Sensible Defaults & Quick Tuning
Start with close-based validation on, ATR buffer on with a multiplier near zero point two, tick buffer two, cooldown three, once-per-session on.
Too many flips: increase the ATR multiplier and cooldown; consider enabling the EMA filter and slope.
Too sluggish: reduce the ATR multiplier and waiting; disable retest.
Choppy conditions: keep close-based validation, increase tick buffer, shorten the retest window.
What this indicator is—and isn’t
This is a visualization and signal layer for session-anchored breakouts with stability gates. It is not a complete trading system, risk framework, or predictive engine. Combine it with structured analysis, position sizing, and disciplined risk controls.
Disclaimer
The content provided, including all code and materials, is strictly for educational and informational purposes only. It is not intended as, and should not be interpreted as, financial advice, a recommendation to buy or sell any financial instrument, or an offer of any financial product or service. All strategies, tools, and examples discussed are provided for illustrative purposes to demonstrate coding techniques and the functionality of Pine Script within a trading context.
Any results from strategies or tools provided are hypothetical, and past performance is not indicative of future results. Trading and investing involve high risk, including the potential loss of principal, and may not be suitable for all individuals. Before making any trading decisions, please consult with a qualified financial professional to understand the risks involved.
By using this script, you acknowledge and agree that any trading decisions are made solely at your discretion and risk.
Do not use this indicator on Heikin-Ashi, Renko, Kagi, Point-and-Figure, or Range charts, as these chart types can produce unrealistic results for signal markers and alerts.
Best regards and happy trading
Chervolino
Daytrade Forex Scalper TwinPulse Auction Timer IndicatorWhat this indicator is
TwinPulse Auction Timer is a multi component execution aid designed for liquid markets. It looks for two families of opportunities
Breakouts that leave a compression area after a fresh sweep
Reversals that trigger after a sweep with strong wick polarity
It does not try to predict future prices. It measures present auction conditions with transparent rules and shows you when those conditions align. You get a simple table that says LONG SHORT or WAIT, optional session shading, clean entry and exit level visuals, and alerts you can wire to your workflow.
Why it is different
Most tools show a single signal. TwinPulse combines several independent signals into an Edge Score that you can tune. The components are
• Pulse. A signed measure of wick asymmetry with candle body direction
• Compression. Current true range compared with an average range
• Sweep timer. Bars elapsed since the most recent sweep of a prior high or low
• Bias. Direction of a higher timeframe candle
• Regime. Efficiency ratio and the relation of micro to macro volatility
• Location. Distance from the daily anchored VWAP
• Session. London and New York filter by time windows
Each component is visible in the inputs and in the table so you can understand why a suggestion appears. The script uses request.security() with lookahead off in all calls so it does not peek into the future. Shapes may move while a bar is open since price is still forming. They stop moving when the bar closes.
What you will see on the chart
• L and S shapes on entry bars
• An Exit shape at the price where a stop or the runner target would have been hit
• Four horizontal lines while a trade is active
Entry
Stop
TP1 at one R
TP2 at the runner target expressed in R
• Labels anchored to each line so you can instantly read Entry SL TP1 and TP2 with current values
• Optional shading during your session windows
• Optional daily VWAP line
The table in the top right shows
Action LONG SHORT IN LONG IN SHORT or WAIT
Session ON or OFF
Bias UP DOWN or FLAT
Pulse value
Compression value
Edge L percent and Edge S percent
How it works in detail
Pulse
For each bar the script measures up wick minus down wick divided by range and multiplies that by the sign of the candle body. The result is averaged with pulse_len. Positive numbers indicate aggressive buying. Negative numbers indicate aggressive selling. You control the minimum absolute value with pulse_thr.
Compression
Compression is the ratio of current range to an average range. You can choose the range basis. HL SMA uses simple high minus low smoothed by range_len. ATR uses classic True Range smoothed by atr_len. Values below comp_thr indicate a coil.
Sweeps and the timer
A sweep occurs when price trades beyond the highest high or lowest low seen in the previous sweep_len bars. A strict sweep requires a close back inside that prior range. The timer measures how many bars have elapsed since the last sweep. Breakout setups require the timer to exceed timer_thr.
Bias on a confirmation timeframe
A higher timeframe candle is read with confirm_tf. If close is above open bias is UP. If close is below open bias is DOWN. This keeps breakouts aligned with the prevailing drift.
Regime filters
Efficiency ratio measures the straight line change over the sum of absolute bar to bar changes over er_len. It rises in trendy conditions and falls in noise. Minimum efficiency is controlled by er_min.
Micro to macro volatility ratio compares a short lookback average range with a longer lookback average range using your chosen basis. For breakouts you usually want micro volatility to be near or above macro hence mvr_min. For reversals you often want micro volatility that is not overheated relative to macro hence mvr_max_rev.
VWAP distance gate
Daily anchored VWAP is rebuilt from the open of each session. The script computes the absolute distance from VWAP in units of your average range and requires that distance to exceed vwap_dist_thr when use_vwap_gate is true. This keeps entries away from the mean.
Edge Score
Each gate contributes a weight that you control. The script sums weights of the satisfied gates and divides by the sum of all weights to produce an Edge percent for long and an Edge percent for short. You can then require a minimum Edge percent using edge_min_pct. This turns the indicator into a step by step checklist that you can tune to your taste.
Using the indicator step by step
Choose markets and timeframes
The logic is designed for liquid instruments. Major currency pairs, index futures and cash index CFDs, and the most liquid crypto pairs work well. On intraday use one to fifteen minutes for signals and fifteen to sixty minutes for confirmation. On swing use one hour to one day for signals and one day for confirmation.
Decide on entry mode
Breakouts require a compression area and a sweep timer. Reversals require a strict sweep and a strong pulse. If you are unsure leave the default which allows both.
Pick a range basis
For FX and crypto HL SMA is often stable. For indices and single name equities with gaps ATR can adapt better. If results look too reactive increase the window. If results are too slow reduce it.
Tune regime filters
If you trade trend continuation raise er_min and mvr_min. If you trade counter rotation lower them and rely on the reversal path with the strict sweep condition.
Set the VWAP gate
Enabling it helps you avoid entries at the mean. Push the threshold higher on range bound days. Reduce it in strong trend days.
Table driven decision
Watch Action and the Edge percents. If the script says WAIT you can read Pulse and Compression to see what is missing. Often the best trades appear when both Edge percents are well separated and your session switch is ON.
Use the visuals
When a suggestion triggers you will see entry stop and targets. You can mirror the levels in your own workflow or use alerts.
Consider bar close
Signals are computed in real time. For a strict process you can wait until the bar closes to reduce noise.
Inputs explained with quick guidance
Setup
Signal TF chooses where the logic is computed. Leave blank to use the chart.
Confirm TF sets the higher timeframe for bias.
Session filter restricts signals to the London and New York windows you specify.
Invert flips long and short. It is useful on inverse instruments.
Logic options
Entry mode allows Breakouts Reversals or Both.
Average range basis selects HL SMA or ATR.
ATR length is used when ATR is selected.
Pulse source can be Regular OHLC or Heikin Ashi. Heikin Ashi smooths noisy series, but the script still runs on regular bars and you should publish and use it on standard candles to respect the platform guidance.
Core numeric settings
Sweep lookback controls the size of the liquidity pool targeted by the sweep condition.
Pulse window smooths the wick polarity measure.
Average range window controls your base range when you use HL SMA.
Pulse threshold sets the minimum polarity required.
Compression threshold sets the maximum current range relative to average to consider the market coiled.
Expansion timer bars sets how much time has passed since the last sweep before you allow a breakout.
Regime filters
Efficiency ratio length and minimum value keep you out of aimless drift.
Micro and Macro range lengths feed the micro to macro ratio.
Minimum micro to macro for breakouts and maximum micro to macro for reversals steer the two entry families.
VWAP gate and distance threshold keep you away from the mean.
Levels and trade management visuals
Runner target in R sets TP2 as a multiple of initial risk.
Stop distance as average range multiple sets initial risk size for the visuals.
Move stop to entry after one R touch turns on break even logic once price has traveled one risk unit.
Trail buffer as R fraction uses the last sweep as an anchor and keeps a dynamic stop at a chosen fraction of R beyond it.
Cooldown after exit prevents immediate re entries.
Edge Score
Weights for pulse compression timer bias efficiency ratio micro to macro VWAP gate and session let you align the checklist with your style.
Minimum Edge percent to suggest applies a final filter to LONG or SHORT suggestions.
UI
Table and markers switch the compact dashboard and the shapes.
TP and SL lines and labels draw and name each level.
TP1 partial label percent is printed in the TP1 label for clarity.
Session shading helps with focus.
Daily VWAP line is optional.
Alerts
The script provides alerts for Long Short Exit and for Edge percent crossing the threshold on either side. Use them to drive notifications or to sync with webhooks and your broker integration. Alerts trigger in real time and will repaint during a bar. For conservative use trigger on bar close.
Recommended presets
Intraday trend continuation
Confirm TF fifteen minutes
Entry mode Breakouts
Range basis HL SMA
Pulse threshold near 0.10
Compression threshold near 0.60
Timer around 18
Minimum efficiency ratio near 0.20
Minimum micro to macro near 1.00
VWAP gate enabled with distance near 0.35
Edge minimum 50 or higher
Intraday mean reversion at sweeps
Entry mode Reversals
Pulse source Regular OHLC
Compression threshold can be a little higher
Maximum micro to macro near 1.60
Efficiency ratio minimum lower near 0.12
VWAP gate enabled
Edge minimum 40 to 60
Swing trend continuation
Signal TF one hour
Confirm TF one day
Range basis ATR
ATR length around 14
Average range window 20 to 30
Efficiency ratio minimum near 0.18
Micro to macro windows 12 and 60
Edge minimum 50 to 70
These are starting points only. Your instrument and timeframe will require small adjustments.
Limitations and honest warnings
No indicator is perfect. TwinPulse will mark attractive conditions that do not always lead to profitable trades. During economic releases or very thin liquidity the assumptions behind compression and sweeps may fail. In strong gap environments the HL SMA basis may lag while ATR may overreact. Heikin Ashi pulse can help in choppy markets but it will lag during sharp reversals. Session times use the exchange time of your chart. If you switch symbol or exchange verify the windows.
Edge percent is not a probability of profit. It is the fraction of satisfied gates with your chosen weights. Two traders can set different weights and see different Edge readings on the same bar. That is the design. The score is a guide that helps you act with discipline.
This indicator does not place orders or manage real risk. The lines and labels show a model entry a model stop and two model targets built from the average range at entry and from recent swing points. Use them as references and not as hard rules. Always test on historical data and demo first. Past results do not guarantee anything in the future.
Credits and originality
All code in this publication is original and written for this indicator. The concept of the efficiency ratio originates from Perry Kaufman. The use of a daily anchored volume weighted average price is a standard industry tool. The specific combination of pulse from wick polarity strict sweep timing compression and the tunable Edge Score is unique to this script at the time of publication. If you reuse parts of the open source code in your own work remember to credit the author and contribute meaningful improvements.
How to read the table at a glance
Action reflects your current state.
IN LONG or IN SHORT appears while a trade is active.
LONG or SHORT appears when conditions for entry are met and the Edge threshold is satisfied.
WAIT appears when at least one gate is missing.
Session shows ON during your chosen windows.
Bias shows the color of the confirmation candle.
Pulse is the smoothed polarity number.
Comp shows current range divided by the average range. Values below one mean compression.
Edge L percent and Edge S percent show the long and short checklists as percents.
Final thoughts
Markets move because orders accumulate at certain prices and at certain times. The indicator tries to measure two things that often matter at those turning points. One is the existence of a hidden imbalance revealed by wick polarity and by sweeps of prior extremes. The other is the presence of energy stored in a coil that can release in the direction of a drift. Neither force guarantees profit. Together they can improve your selection and your timing.
Use the defaults for a few days so you learn the personality of the signals. After that adjust one group at a time. Start with the session filter and the Edge threshold. Then tune compression and the timer. Finally adjust the regime filters. Keep notes. You will learn which weights matter for your market and timeframe. The result is a process you can apply with consistency.
Disclaimer
This script and description are for education and analysis. They are not investment advice and they do not promise future results. Use at your own risk. Test thoroughly on historical data and in simulation before considering any live use.
TwinPulse Q Lead SPY x QQQ Intermarket Pulse 1HTwinPulse Q Lead is a concise one hour indicator for SPY and QQQ that converts three sources of market information into a single pulse line, a mode readout with BUY SELL WAIT, and compact alerts. It blends intermarket leadership between QQQ and SPY, intraday flow from the slope of session VWAP, and where the current price sits inside the regular trading hours range. The three components are normalized, fused, compressed to a stable range, and smoothed for clear thresholds. The aim is a readable intraday regime signal that helps you decide when to participate and when to stand aside.
The script is built with Pine v6, uses request security with lookahead off, and does not repaint. It is an indicator, not a strategy. It does not contain any solicitation, links, or outside references. The description is self contained and explains both logic and use so that any trader can understand the design without reading code.
What makes this original and useful
Intermarket leadership is measured directly from QQQ and SPY on your working timeframe using a Z score of the return spread. When growth is leading value heavy large caps, leadership turns positive. When it lags, leadership turns negative. This gives a real time read of the Nasdaq versus S and P tug of war that most day traders watch informally.
Intraday flow is taken from the slope of the session VWAP. A linear regression of VWAP over a short window captures whether value is rising or falling inside the day. Dividing by ATR normalizes slope by typical movement so that the signal is comparable across weeks.
Session position places price inside the current regular hours high to low. It answers whether the day is trading in the top half, the bottom half, or the middle. This is a simple but powerful context filter for breakouts and fades.
The three components are fused into one pulse, compressed with either hyperbolic tangent or softsign to keep values bounded, and then smoothed by a short EMA. This yields a stable range with a zero line so the eye can read shifts quickly.
The panel shows a human readable mode with reasons and a strength score. Traders who do not want to read lines can rely on a simple state and a compact justification that explains why the state is set.
This is not a mashup that simply overlays unrelated indicators. Each component was chosen to answer a distinct question that is common to SPY and QQQ intraday decision making. Leadership answers who is in charge, flow answers whether value inside the session is building or leaking, and position answers if price is pressing the extremes or circling the middle. The pulse ties the three together and prevents any single component from dominating.
How the calculations work
Leadership. Compute a short rate of change for SPY and QQQ. Subtract SPY from QQQ to get spread returns, then compute a rolling Z score over a longer window. Positive values mean QQQ is leading. Negative values mean SPY is leading.
Flow. Compute session VWAP on the active symbol. Regress VWAP over a short window to obtain a slope estimate. Divide by ATR to scale slope by current volatility so that a small rise on a quiet day is not treated the same as a small rise on a wild day.
Position. Track the highest high and lowest low since the start of regular hours. Place the current close inside that range on a zero to one scale, then recenter to a minus one to plus one scale. Positive means the top half of the day, negative means the bottom half.
Fusion. Multiply each component by a weight so users can emphasize or de emphasize leadership, flow, or position. Sum to a raw pulse.
Compression. Pass the raw pulse through a bounded function. Hyperbolic tangent is smooth and has natural saturation near the extremes. Softsign is faster and behaves like a smoother version of sign near zero. Compression avoids unbounded excursions and makes thresholds meaningful across days.
Smoothing. Apply a short EMA to the compressed pulse to reduce noise. This creates the main line called TwinPulse in the plot.
Thresholds. You can use static symmetric levels or adaptive levels. The adaptive option computes a mean and a standard deviation of the smoothed pulse over a user window, then sets upper and lower thresholds as mean plus or minus sigma times standard deviation. This allows thresholds to adjust across regimes. Static levels are still available for traders who want repeatable levels.
Events and mode. A long event fires when the smoothed pulse crosses the upper threshold with positive flow and any optional filters agree. A short event fires on the symmetric condition. The mode reads the current state rather than fire and forget. It returns BUY when the smoothed pulse is above the upper threshold with positive flow, SELL when the smoothed pulse is below the lower threshold with negative flow, otherwise WAIT. A cooldown controls how often events can fire so alerts do not spam during choppy periods.
Inputs and default values
The script ships with defaults chosen for SPY and QQQ on one hour charts.
Symbols. SPY and QQQ by default. You can switch to any pair. Many users may test IWM versus SPY for small cap reads.
Regular hours selector. On by default. This restricts the position factor to New York regular hours. Turn it off if you prefer full session behavior.
ROC length is three bars. Z score length is fifty bars. VWAP slope window is ten bars. ATR length is fourteen bars. Pulse smoothing length is three bars.
Compression mode. Choose hyperbolic tangent or softsign. Hyperbolic tangent is default.
Weights. Leadership and flow are one by default. Position is set to zero point seven to give a modest influence to where price sits inside the day.
Thresholds. Adaptive thresholds are on by default with a lookback of one hundred bars and a sigma width of zero point eight. Static levels at plus or minus zero point six are ready if you disable adaptive mode.
Filters. ADX filter is off by default. If you enable it, the script requires ADX above a user minimum before it will signal. Higher time frame confirmation is off by default. When enabled it compares the smoothed pulse on the confirm timeframe to zero and requires alignment for longs or shorts.
Cooldown. Three bars by default so that alerts do not trigger too frequently.
UI. Bar coloring is on by default. The panel is on by default and sits at the top right.
All request security calls use lookahead off and will not request future data. All persistent state variables are assigned in a way that prevents repainting. The indicator does not use non standard chart types in its logic.
How to use the indicator
Load a one hour chart of SPY or QQQ. Keep a clean chart so that the script output is easy to read.
Turn on regular hours if you want the session position to reflect the cash session. This is recommended for SPY and QQQ.
Watch the panel. Mode reads BUY or SELL or WAIT. The strength value is a simple vote based score that ranges from zero to one hundred. It counts leadership, flow, ADX if enabled, and higher time frame confirmation if enabled. You can use strength to filter weak states.
Consider action only when mode is BUY or SELL and the signal has not just fired on the last bar. The triangles mark where an event fired. Alerts use the same logic as the events. WAIT means stand aside.
To slow the system, enable ADX and set a higher minimum or enable higher time frame confirmation. To speed it up, disable the filters, disable adaptive thresholds, or tighten the sigma width.
When publishing, use a clean chart with only this indicator. Show the symbol and timeframe clearly and make sure the plot legend is visible. If you add drawings on the chart, only include ones that help readers understand the output.
Publication notes and compliance
This description is written in English. The title uses ASCII and only uses capital letters for common abbreviations. The script is original and explains how and why the components work together. There are no links or promotional material. The script does not claim performance. It does not use lookahead. The panel and alerts exist to help a human read and act with discipline. The indicator can be published as open source or as protected. If you choose protected, the description still allows readers to understand how the logic works without access to the code.
If you later convert the logic into a strategy for publication, use realistic commission and slippage, risk no more than a small share of equity per trade, and choose a dataset that yields a large enough sample. Explain any deviations from these default recommendations in your strategy description. Do not publish results from non standard chart types since they can mislead readers on signal timing.
Limitations and risks
Intermarket leadership is a relative measure. There are hours when both SPY and QQQ fall while leadership remains positive. Treat leadership as a context, not a stand alone trigger.
VWAP slope is a path measure inside the session. It can flip several times on a choppy day. That is why the script uses a short smoothing and an optional cooldown. Use ADX or higher time frame confirmation to avoid the worst chop.
Session position assumes a meaningful regular hours range. On half days or around openings with gaps the position factor can be less informative. If this bothers you, reduce the weight of position or turn it off.
Compression and smoothing introduce lag by design. The goal is stability and clarity. If you want earlier but noisier signals, reduce smoothing and weights, and use static thresholds.
No indicator guarantees future results. TwinPulse Q Lead is a decision aid. It should be combined with your risk rules, position size policy, and a clear exit plan. Past behavior is not a promise for the future.
Frequently asked questions
What symbols are supported. Any symbol can be used as the chart symbol. Leadership uses the two user symbols which default to SPY and QQQ. Many traders may try IWM versus SPY or DIA versus SPY.
Can I change the timeframe. Yes, but the design target is one hour. On very short timeframes the VWAP slope becomes very sensitive and you should consider stronger filters.
Does the script repaint. No. It uses request security with lookahead off and the panel updates on the last bar only. Events are based on bar close conditions unless you attach alerts on any alert function call which will still respect the logic without looking into the future.
How are the strength numbers built. The strength score is the share of aligned votes across leadership, flow, ADX if enabled, and higher time frame confirmation if enabled. A value near one hundred means many filters agree. A value near fifty means partial alignment. It is not a probability or an accuracy number.
Can I use non standard chart types. You can view the indicator on them but do not publish signals from non standard chart types because that can mislead readers about timing. Use classic candles or bars when you publish and when you test.
Why do I sometimes see BUY but the price is not moving. A BUY mode requires pulse above the upper threshold and positive flow. It does not require higher highs immediately. Treat BUY as a permission to look for entries using your own execution rules.
