Cyber MondayGIẢM GIÁ lên tới 80%

Tìm kiếm tập lệnh với "one一季度财报"

Multi Color Normalized MACD + Candles (NMACD) [cI8DH]One simple indicator for volatility, divergence and relative momentum Features: - Normalized MACD (by slow MA) - Candle MACD (fast MA length is set to 0 in candle mode, i.e. price minus slow MA) - Multi color histogram - Background coloring based on MACD direction - Choice of different MA types (Exponential, Simple, Weighted, Smoothed, Triple EMA) - Triple EMA smoothing Benefits of normalization: - Absolutely better than RSI for comparing across different periods and assets Applications and benefits of candle visualization: - Zero cross: most traders use MAs overlaid on the main chart and look for price distance and MA cross visually. In candle mode, this indicator measures the difference between price and the slow moving MA. When this indicator crosses zero, it means price is crossing the slow moving MA. - Divergence: full candle visualization (OHLC) is not possible for most other indicators. Candle visualization allows measuring divergence between price high, low and close simultaneously. Some trades incorrectly measure divergence between high, low of price against indicator tops and bottoms while having the indicator input set to default (usually close). With this indicator, you don't need to worry about such complexities. Recommended setting: - Enjoy candle mode :) - Source set to hlc3
Chỉ báo Pine Script®
của cI8DH
13
EMA50Diff & MACD StrategyOne of my attempts to create a strategy for BTC. Its a combination of EMA50Diff (the difference between spot and EMA50) and MACD. Buy signal if (EMA50Diff) < -(EMADiffThreshold), (MACD bearish crossunder), (MACD) < -(MACDThreshold), (EMA50Diff) > (EMA50Diff 1 candle ago), (EMA50Diff 1 candle ago) < (EMA50Diff 2 candles ago) Sell signal if (EMA50Diff) > (EMADiffThreshold), (MACD bullish crossover), (MACD) > (MACDThreshold), (EMA50Diff) < (EMA50Diff 1 candle ago), (EMA50Diff 1 candle ago) > (EMA50Diff 2 candles ago) Exit either when target or stoploss get reached. Initial capital is set to 100k and its currently going all-in on every trade but im looking for a better way to handle position sizes already.. Also i included slippage of 30 ticks and exchange commission of 0.15% (e.g. 2x BitMEX market taker fee) Works best on 15m on bitfinex, bitstamp and gdax and i'm still trying to optimize it for bitmex too, will update when i got there..
Chiến lược Pine Script®
của kggi
2
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
Chỉ báo Pine Script®
của LazyBear
36
Every Hour 1st/Last FVG vTDL OVERVIEW - Shoutout to Micheal J. Huddleston aka ICT This indicator identifies the first Fair Value Gap (FVG) that forms within each trading hour, providing traders with potential entry zones, reversal points, and unmitigated gap targets. Based on the concept that the first presented FVG of each hour represents a significant price delivery array where institutional order flow occurred. The indicator detects FVGs on a lower timeframe (1-minute default) and displays them as boxes on your chart, tracking which gaps get filled and which remain open as potential draw-on-liquidity targets. WHAT IS A FAIR VALUE GAP A Fair Value Gap is a 3-candle price pattern representing an imbalance between buyers and sellers: Bullish FVG: Forms when candle 3's low is above candle 1's high, leaving a gap Bearish FVG: Forms when candle 3's high is below candle 1's low, leaving a gap These gaps often act as magnets for price, which tends to return and "fill" the imbalance before continuing. They function as dynamic support and resistance zones. KEY FEATURES Detection Types FVG: Standard fair value gap detection with volume imbalance expansion Suspension FVG Blocks: Requires outside prints on both sides for more refined signals Hourly Display Modes First Only: Shows whichever FVG appears first each hour (bullish or bearish) Show Both: Shows first bullish AND first bearish FVG independently each hour Last FVG Tracking Optionally display the last FVG of each hour Useful for comparing how the hour developed Can extend into the next hour for continued tracking Breakaway Gap Detection Gaps not traded into during their formation hour extend forward Extended gaps display labels showing formation time and date These unmitigated gaps become price targets and reversal zones Gap Fill Modes Touch Box: Marks filled when price enters the gap Touch Midpoint: Marks filled when price reaches the 50 percent level Fill Completely: Marks filled when price fills the entire gap with visual progress HOW TO USE Entry Points The first FVG of each hour provides potential entry zones based on price reaction: When price returns to an FVG and shows rejection, enter in the direction of rejection The gap zone represents where institutional orders likely reside Use the boundaries of the gap for stop loss placement A clean rejection of the zone confirms it as valid support or resistance Reversal Points Unmitigated gaps that extend beyond their formation hour are high-probability reaction zones: Extended boxes with labels indicate unfilled gaps When price finally reaches these zones, expect a reaction The longer a gap remains unfilled, the stronger the expected response These zones act as magnets drawing price back to them Price Targets Use unmitigated gaps as draw-on-liquidity targets: Look for extended boxes above or below current price Price tends to seek out and fill imbalances The midpoint line often serves as a minimum target Multiple unfilled gaps in one direction suggest strong momentum potential FRAMING DIRECTIONAL BIAS The first presented FVG of each hour acts as a support or resistance zone. The direction of the FVG itself does not determine bias - it is how price reacts to that FVG that reveals the true market intention. Reading Price Reaction Price respects a bullish FVG as support and bounces higher = bullish bias confirmed Price respects a bearish FVG as resistance and rejects lower = bearish bias confirmed Price fails to hold a bullish FVG and breaks through = potential inversion, look for shorts Price fails to hold a bearish FVG and breaks through = potential inversion, look for longs Inversion Fair Value Gaps (IFVG) When price trades through an FVG and closes beyond it, that gap can invert its role: A bullish FVG that fails becomes resistance - use it as a short entry zone A bearish FVG that fails becomes support - use it as a long entry zone The inversion signals a shift in control from one side to the other Watch for price to retest the inverted gap before continuing Support and Resistance Framework Think of each hourly first FVG as a key level: Price above the FVG: the gap acts as potential support Price below the FVG: the gap acts as potential resistance Watch how price behaves when it returns to the gap zone A clean rejection confirms the level; a break through signals inversion SHORT-TERM SCALPING APPLICATION These FVGs provide scalping opportunities each hour: Identify the first FVG of the hour as your key level Wait for price to trade away from it and return Observe the reaction at the gap zone Enter in the direction of the reaction with tight risk Target the next FVG, midpoint, or nearby liquidity Trade Management Use the opposite side of the FVG box as your stop loss zone The midpoint of the gap often provides first target or decision point Scale out at nearby unmitigated gaps or key levels If the gap inverts, flip your bias and look for entries in the new direction MULTI-HOUR CONTEXT If price consistently respects FVGs as support across hours = uptrend context If price consistently respects FVGs as resistance across hours = downtrend context If FVGs keep inverting = choppy or transitional market Use higher timeframe direction to filter which reactions to trade Compare first and last FVG of each hour to see how momentum developed SESSION FILTERING The indicator automatically excludes unreliable periods: 4 PM to 5 PM New York time (market close hours 16-17) Weekend closed periods (Saturday and Sunday before 6 PM) All timestamps use New York timezone for consistency with futures market hours. SETTINGS GUIDE Detection Settings Detection Type: Choose between standard FVG or Suspension FVG Blocks Lower Timeframe: 15 seconds, 1 minute, or 5 minutes for gap detection Min FVG Size: Minimum gap size in ticks to filter noise Display Settings Hourly Display Mode: First Only shows one gap per hour; Show Both shows first bull and bear Show First FVG: Toggle visibility of first FVG boxes Show Last FVG: Toggle visibility of last FVG boxes Show Midpoint Lines: Display the 50 percent level of each gap Show Unfilled Breakaway Gaps: Extend boxes until price fills them Show Only Today: Reduce clutter by hiding older hourly boxes Gap Fill Detection Mode Touch Box: Gap marked filled when price enters the zone Touch Midpoint: Gap marked filled when price reaches 50 percent level Fill Completely: Gap marked filled only when fully closed, shows visual fill progress Recommended Settings by Style Scalping: 1 minute LTF, 4 tick minimum, Show Both mode, Touch Box fill Day Trading: 1 minute LTF, 4-8 tick minimum, First Only mode, Touch Midpoint fill Swing Context: 5 minute LTF, Show Unfilled Gaps enabled, Fill Completely mode COLOR CODING Blue boxes: First bullish FVG of the hour Red boxes: First bearish FVG of the hour Green boxes: Last bullish FVG of the hour Orange boxes: Last bearish FVG of the hour Black midpoint lines: 50 percent level of each gap Filled portion overlay: Shows visual progress in Fill Completely mode All colors are fully customizable in the settings menu. PRACTICAL TIPS The first FVG of each hour is a hidden PD array - treat it as a significant level Not every gap produces a tradeable reaction - wait for confirmation Gaps that remain unfilled for multiple hours carry more weight Use the Show Both mode to see both bullish and bearish opportunities each hour When multiple gaps cluster in one zone, that area becomes even more significant Inversions are powerful signals - a failed level often leads to acceleration NOTES Works on any instrument and timeframe Best used on intraday charts (1 minute to 15 minute) viewing 1 minute LTF gaps Combine with higher timeframe analysis for confluence These are probability zones, not guarantees - always use proper risk management The indicator handles HTF to LTF data fetching automatically
Chỉ báo Pine Script®
của Trades-Dont-Lie
1
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").
Thư viện Pine Script®
của TradingView
1
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
Chỉ báo Pine Script®
của SolCollector
44
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)
Thư viện Pine Script®
của moebius1977
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.
Chỉ báo Pine Script®
của LucF
106
`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.
Chỉ báo Pine Script®
của PineCoders
61
COT IndexTHE HIDDEN INTELLIGENCE IN FUTURES MARKETS What if you could see what the smartest players in the futures markets are doing before the crowd catches on? While retail traders chase momentum indicators and moving averages, obsess over Japanese candlestick patterns, and debate whether the RSI should be set to fourteen or twenty-one periods, institutional players leave footprints in the sand through their mandatory reporting to the Commodity Futures Trading Commission. These footprints, published weekly in the Commitment of Traders reports, have been hiding in plain sight for decades, available to anyone with an internet connection, yet remarkably few traders understand how to interpret them correctly. The COT Index indicator transforms this raw institutional positioning data into actionable trading signals, bringing Wall Street intelligence to your trading screen without requiring expensive Bloomberg terminals or insider connections. The uncomfortable truth is this: Most retail traders operate in a binary world. Long or short. Buy or sell. They apply technical analysis to individual positions, constrained by limited capital that forces them to concentrate risk in single directional bets. Meanwhile, institutional traders operate in an entirely different dimension. They manage portfolios dynamically weighted across multiple markets, adjusting exposure based on evolving market conditions, correlation shifts, and risk assessments that retail traders never see. A hedge fund might be simultaneously long gold, short oil, neutral on copper, and overweight agricultural commodities, with position sizes calibrated to volatility and portfolio Greeks. When they increase gold exposure from five percent to eight percent of portfolio allocation, this rebalancing decision reflects sophisticated analysis of opportunity cost, risk parity, and cross-market dynamics that no individual chart pattern can capture. This portfolio reweighting activity, multiplied across hundreds of institutional participants, manifests in the aggregate positioning data published weekly by the CFTC. The Commitment of Traders report does not show individual trades or strategies. It shows the collective footprint of how actual commercial hedgers and large speculators have allocated their capital across different markets. When mining companies collectively increase forward gold sales to hedge thirty percent more production than last quarter, they are not reacting to a moving average crossover. They are making strategic allocation decisions based on production forecasts, cost structures, and price expectations derived from operational realities invisible to outside observers. This is portfolio management in action, revealed through positioning data rather than price charts. If you want to understand how institutional capital actually flows, how sophisticated traders genuinely position themselves across market cycles, the COT report provides a rare window into that hidden world. But understand what you are getting into. This is not a tool for scalpers seeking confirmation of the next five-minute move. This is not an oscillator that flashes oversold at market bottoms with convenient precision. COT analysis operates on a timescale measured in weeks and months, revealing positioning shifts that precede major market turns but offer no precision timing. The data arrives three days stale, published only once per week, capturing strategic positioning rather than tactical entries. If you need instant gratification, if you trade intraday moves, if you demand mechanical signals with ninety percent accuracy, close this document now. COT analysis rewards patience, position sizing discipline, and tolerance for being early. It punishes impatience, overleveraging, and the expectation that any single indicator can substitute for market understanding. The premise is deceptively simple. Every Tuesday, large traders in futures markets must report their positions to the CFTC. By Friday afternoon, this data becomes public. Academic research spanning three decades has consistently shown that not all market participants are created equal. Some traders consistently profit while others consistently lose. Some anticipate major turning points while others chase trends into exhaustion. Bessembinder and Chan (1992) demonstrated in their seminal study that commercial hedgers, those with actual exposure to the underlying commodity or financial instrument, possess superior forecasting ability compared to speculators. Their research, published in the Journal of Finance, found statistically significant predictive power in commercial positioning, particularly at extreme levels. This finding challenged the efficient market hypothesis and opened the door to a new approach to market analysis based on positioning rather than price alone. Think about what this means. Every week, the government publishes a report showing you exactly how the most informed market participants are positioned. Not their opinions. Not their predictions. Their actual money at risk. When agricultural producers collectively hold their largest short hedge in five years, they are not making idle speculation. They are locking in prices for crops they will harvest, informed by private knowledge of weather conditions, soil quality, inventory levels, and demand expectations invisible to outside observers. When energy companies aggressively hedge forward production at current prices, they reveal information about expected supply that no analyst report can capture. This is not technical analysis based on past prices. This is not fundamental analysis based on publicly available data. This is behavioral analysis based on how the smartest money is actually positioned, how institutions allocate capital across portfolios, and how those allocation decisions shift as market conditions evolve. WHY SOME TRADERS KNOW MORE THAN OTHERS Building on this foundation, Sanders, Boris and Manfredo (2004) conducted extensive research examining the behaviour patterns of different trader categories. Their work, which analyzed over a decade of COT data across multiple commodity markets, revealed a fascinating dynamic that challenges much of what retail traders are taught. Commercial hedgers consistently positioned themselves against market extremes, buying when speculators were most bearish and selling when speculators reached peak bullishness. The contrarian positioning of commercials was not random noise but rather reflected their superior information about supply and demand fundamentals. Meanwhile, large speculators, primarily hedge funds and commodity trading advisors, exhibited strong trend-following behaviour that often amplified market moves beyond fundamental values. Small traders, the retail participants, consistently entered positions late in trends, frequently near turning points, making them reliable contrary indicators. Wang (2003) extended this research by demonstrating that the predictive power of commercial positioning varies significantly across different commodity sectors. His analysis of agricultural commodities showed particularly strong forecasting ability, with commercial net positions explaining up to fifteen percent of return variance in subsequent weeks. This finding suggests that the informational advantages of hedgers are most pronounced in markets where physical supply and demand fundamentals dominate, as opposed to purely financial markets where information asymmetries are smaller. When a corn farmer hedges six months of expected harvest, that decision incorporates private observations about rainfall patterns, crop health, pest pressure, and local storage capacity that no distant analyst can match. When an oil refinery hedges crude oil purchases and gasoline sales simultaneously, the spread relationships reveal expectations about refining margins that reflect operational realities invisible in public data. The theoretical mechanism underlying these empirical patterns relates to information asymmetry and different participant motivations. Commercial hedgers engage in futures markets not for speculative profit but to manage business risks. An agricultural producer selling forward six months of expected harvest is not making a bet on price direction but rather locking in revenue to facilitate financial planning and ensure business viability. However, this hedging activity necessarily incorporates private information about expected supply, inventory levels, weather conditions, and demand trends that the hedger observes through their commercial operations (Irwin and Sanders, 2012). When aggregated across many participants, this private information manifests in collective positioning. Consider a gold mining company deciding how much forward production to hedge. Management must estimate ore grades, recovery rates, production costs, equipment reliability, labor availability, and dozens of other operational variables that determine whether locking in prices at current levels makes business sense. If the industry collectively hedges more aggressively than usual, it suggests either exceptional production expectations or concern about sustaining current price levels or combination of both. Either way, this positioning reveals information unavailable to speculators analyzing price charts and economic data. The hedger sees the physical reality behind the financial abstraction. Large speculators operate under entirely different incentives and constraints. Commodity Trading Advisors managing billions in assets typically employ systematic, trend-following strategies that respond to price momentum rather than fundamental supply and demand. When crude oil rallies from sixty dollars to seventy dollars per barrel, these systems generate buy signals. As the rally continues to eighty dollars, position sizes increase. The strategy works brilliantly during sustained trends but becomes a liability at reversals. By the time oil reaches ninety dollars, trend-following funds are maximally long, having accumulated positions progressively throughout the rally. At this point, they represent not smart money anticipating further gains but rather crowded money vulnerable to reversal. Sanders, Boris and Manfredo (2004) documented this pattern across multiple energy markets, showing that extreme speculator positioning typically marked late-stage trend exhaustion rather than early-stage trend development. Small traders, the retail participants who fall below reporting thresholds, display the weakest forecasting ability. Wang (2003) found that small trader positioning exhibited negative correlation with subsequent returns, meaning their aggregate positioning served as a reliable contrary indicator. The explanation combines several factors. Retail traders often lack the capital reserves to weather normal market volatility, leading to premature exits from positions that would eventually prove profitable. They tend to receive information through slower channels, entering trends after mainstream media coverage when institutional participants are preparing to exit. Perhaps most importantly, they trade with emotion, buying into euphoria and selling into panic at precisely the wrong times. At major turning points, the three groups often position opposite each other with commercials extremely bearish, large speculators extremely bullish, and small traders piling into longs at the last moment. These high-divergence environments frequently precede increased volatility and trend reversals. The insiders with business exposure quietly exit as the momentum traders hit maximum capacity and retail enthusiasm peaks. Within weeks, the reversal begins, and positions unwind in the opposite sequence. FROM RAW DATA TO ACTIONABLE SIGNALS The COT Index indicator operationalizes these academic findings into a practical trading tool accessible through TradingView. At its core, the indicator normalizes net positioning data onto a zero to one hundred scale, creating what we call the COT Index. This normalization is critical because absolute position sizes vary dramatically across different futures contracts and over time. A commercial trader holding fifty thousand contracts net long in crude oil might be extremely bullish by historical standards, or it might be quite neutral depending on the context of total market size and historical ranges. Raw position numbers mean nothing without context. The COT Index solves this problem by calculating where current positioning stands relative to its range over a specified lookback period, typically two hundred fifty-two weeks or approximately five years of weekly data. The mathematical transformation follows the methodology originally popularized by legendary trader Larry Williams, though the underlying concept appears in statistical normalization techniques across many fields. For any given trader category, we calculate the highest and lowest net position values over the lookback period, establishing the historical range for that specific market and trader group. Current positioning is then expressed as a percentage of this range, where zero represents the most bearish positioning ever seen in the lookback window and one hundred represents the most bullish extreme. A reading of fifty indicates positioning exactly in the middle of the historical range, suggesting neither extreme optimism nor pessimism relative to recent history (Williams and Noseworthy, 2009). This index-based approach allows for meaningful comparison across different markets and time periods, overcoming the scaling problems inherent in analyzing raw position data. A commercial index reading of eighty-five in gold carries the same interpretive meaning as an eighty-five reading in wheat or crude oil, even though the absolute position sizes differ by orders of magnitude. This standardization enables systematic analysis across entire futures portfolios rather than requiring market-specific expertise for each contract. The lookback period selection involves a fundamental tradeoff between responsiveness and stability. Shorter lookback periods, perhaps one hundred twenty-six weeks or approximately two and a half years, make the index more sensitive to recent positioning changes. However, it also increases noise and produces more false signals. Longer lookback periods, perhaps five hundred weeks or approximately ten years, create smoother readings that filter short-term noise but become slower to recognize regime changes. The indicator settings allow users to adjust this parameter based on their trading timeframe, risk tolerance, and market characteristics. UNDERSTANDING CFTC DATA STRUCTURES The indicator supports both Legacy and Disaggregated COT report formats, reflecting the evolution of CFTC reporting standards over decades of market development. Legacy reports categorize market participants into three broad groups: commercial traders (hedgers with underlying business exposure), non-commercial traders (large speculators seeking profit without commercial interest), and non-reportable traders (small speculators below reporting thresholds). Each category brings distinct motivations and information advantages to the market (CFTC, 2020). The Disaggregated reports, introduced in September 2009 for physical commodity markets, provide finer granularity by splitting participants into five categories (CFTC, 2009). Producer and merchant positions capture those actually producing, processing, or merchandising the physical commodity. Swap dealers represent financial intermediaries facilitating derivative transactions for clients. Managed money includes commodity trading advisors and hedge funds executing systematic or discretionary strategies. Other reportables encompasses diverse participants not fitting the main categories. Small traders remain as the fifth group, representing retail participation. This enhanced categorization reveals nuances invisible in Legacy reports, particularly distinguishing between different types of institutional capital and their distinct behavioural patterns. The indicator automatically detects which report type is appropriate for each futures contract and adjusts the display accordingly. Importantly, Disaggregated reports exist only for physical commodity futures. Agricultural commodities like corn, wheat, and soybeans have Disaggregated reports because clear producer, merchant, and swap dealer categories exist. Energy commodities like crude oil and natural gas similarly have well-defined commercial hedger categories. Metals including gold, silver, and copper also receive Disaggregated treatment (CFTC, 2009). However, financial futures such as equity index futures, Treasury bond futures, and currency futures remain available only in Legacy format. The CFTC has indicated no plans to extend Disaggregated reporting to financial futures due to different market structures and participant categories in these instruments (CFTC, 2020). THE BEHAVIORAL FOUNDATION Understanding which trader perspective to follow requires appreciation of their distinct trading styles, success rates, and psychological profiles. Commercial hedgers exhibit anticyclical behaviour rooted in their fundamental knowledge and business imperatives. When agricultural producers hedge forward sales during harvest season, they are not speculating on price direction but rather locking in revenue for crops they will harvest. Their business requires converting volatile commodity exposure into predictable cash flows to facilitate planning and ensure survival through difficult periods. Yet their aggregate positioning reveals valuable information because these hedging decisions incorporate private information about supply conditions, inventory levels, weather observations, and demand expectations that hedgers observe through their commercial operations (Bessembinder and Chan, 1992). Consider a practical example from energy markets. Major oil companies continuously hedge portions of forward production based on price levels, operational costs, and financial planning needs. When crude oil trades at ninety dollars per barrel, they might aggressively hedge the next twelve months of production, locking in prices that provide comfortable profit margins above their extraction costs. This hedging appears as short positioning in COT reports. If oil rallies further to one hundred dollars, they hedge even more aggressively, viewing these prices as exceptional opportunities to secure revenue. Their short positioning grows increasingly extreme. To an outside observer watching only price charts, the rally suggests bullishness. But the commercial positioning reveals that the actual producers of oil find these prices attractive enough to lock in years of sales, suggesting skepticism about sustaining even higher levels. When the eventual reversal occurs and oil declines back to eighty dollars, the commercials who hedged at ninety and one hundred dollars profit while speculators who chased the rally suffer losses. Large speculators or managed money traders operate under entirely different incentives and constraints. Their systematic, momentum-driven strategies mean they amplify existing trends rather than anticipate reversals. Trend-following systems, the most common approach among large speculators, by definition require confirmation of trend through price momentum before entering positions (Sanders, Boris and Manfredo, 2004). When crude oil rallies from sixty dollars to eighty dollars per barrel over several months, trend-following algorithms generate buy signals based on moving average crossovers, breakouts, and other momentum indicators. As the rally continues, position sizes increase according to the systematic rules. However, this approach becomes a liability at turning points. By the time oil reaches ninety dollars after a sustained rally, trend-following funds are maximally long, having accumulated positions progressively throughout the move. At this point, their positioning does not predict continued strength. Rather, it often marks late-stage trend exhaustion. The psychological and mechanical explanation is straightforward. Trend followers by definition chase price momentum, entering positions after trends establish rather than anticipating them. Eventually, they become fully invested just as the trend nears completion, leaving no incremental buying power to sustain the rally. When the first signs of reversal appear, systematic stops trigger, creating a cascade of selling that accelerates the downturn. Small traders consistently display the weakest track record across academic studies. Wang (2003) found that small trader positioning exhibited negative correlation with subsequent returns in his analysis across multiple commodity markets. This result means that whatever small traders collectively do, the opposite typically proves profitable. The explanation for small trader underperformance combines several factors documented in behavioral finance literature. Retail traders often lack the capital reserves to weather normal market volatility, leading to premature exits from positions that would eventually prove profitable. They tend to receive information through slower channels, learning about commodity trends through mainstream media coverage that arrives after institutional participants have already positioned. Perhaps most importantly, retail traders are more susceptible to emotional decision-making, buying into euphoria and selling into panic at precisely the wrong times (Tharp, 2008). SETTINGS, THRESHOLDS, AND SIGNAL GENERATION The practical implementation of the COT Index requires understanding several key features and settings that users can adjust to match their trading style, timeframe, and risk tolerance. The lookback period determines the time window for calculating historical ranges. The default setting of two hundred fifty-two bars represents approximately one year on daily charts or five years on weekly charts, balancing responsiveness with stability. Conservative traders seeking only the most extreme, highest-probability signals might extend the lookback to five hundred bars or more. Aggressive traders seeking earlier entry and willing to accept more false positives might reduce it to one hundred twenty-six bars or even less for shorter-term applications. The bullish and bearish thresholds define signal generation levels. Default settings of eighty and twenty respectively reflect academic research suggesting meaningful information content at these extremes. Readings above eighty indicate positioning in the top quintile of the historical range, representing genuine extremes rather than temporary fluctuations. Conversely, readings below twenty occupy the bottom quintile, indicating unusually bearish positioning (Briese, 2008). However, traders must recognize that appropriate thresholds vary by market, trader category, and personal risk tolerance. Some futures markets exhibit wider positioning swings than others due to seasonal patterns, volatility characteristics, or participant behavior. Conservative traders seeking high-probability setups with fewer signals might raise thresholds to eighty-five and fifteen. Aggressive traders willing to accept more false positives for earlier entry could lower them to seventy-five and twenty-five. The key is maintaining meaningful differentiation between bullish, neutral, and bearish zones. The default settings of eighty and twenty create a clear three-zone structure. Readings from zero to twenty represent bearish territory where the selected trader group holds unusually bearish positions. Readings from twenty to eighty represent neutral territory where positioning falls within normal historical ranges. Readings from eighty to one hundred represent bullish territory where the selected trader group holds unusually bullish positions. The trading perspective selection determines which participant group the indicator follows, fundamentally shaping interpretation and signal meaning. For counter-trend traders seeking reversal opportunities, monitoring commercial positioning makes intuitive sense based on the academic research discussed earlier. When commercials reach extreme bearish readings below twenty, indicating unprecedented short positioning relative to recent history, they are effectively betting against the crowd. Given their informational advantages demonstrated by Bessembinder and Chan (1992), this contrarian stance often precedes major bottoms. Trend followers might instead monitor large speculator positioning, but with inverted logic compared to commercials. When managed money reaches extreme bullish readings above eighty, the trend may be exhausting rather than accelerating. This seeming paradox reflects their late-cycle participation documented by Sanders, Boris and Manfredo (2004). Sophisticated traders thus use speculator extremes as fade signals, entering positions opposite to speculator consensus. Small trader monitoring serves primarily as a contrary indicator for all trading styles. Extreme small trader bullishness above seventy-five or eighty typically warns of retail FOMO at market tops. Extreme small trader bearishness below twenty or twenty-five often marks capitulation bottoms where the last weak hands have sold. VISUALIZATION AND USER INTERFACE The visual design incorporates multiple elements working together to facilitate decision-making and maintain situational awareness during active trading. The primary COT Index line plots in bold with adjustable line width, defaulting to two pixels for clear visibility against busy price charts. An optional glow effect, controlled by a simple toggle, adds additional visual prominence through multiple plot layers with progressively increasing transparency and width. A twenty-one period exponential moving average overlays the index line, providing trend context for positioning changes. When the index crosses above its moving average, it signals accelerating bullish sentiment among the selected trader group regardless of whether absolute positioning is extreme. Conversely, when the index crosses below its moving average, it signals deteriorating sentiment and potentially the beginning of a reversal in positioning trends. The EMA provides a dynamic reference line for assessing positioning momentum. When the index trades far above its EMA, positioning is not only extreme in absolute terms but also building with momentum. When the index trades far below its EMA, positioning is contracting or reversing, which may indicate weakening conviction even if absolute levels remain elevated. The data table positioned at the top right of the chart displays eleven metrics for each trader category, transforming the indicator from a simple index calculation into an analytical dashboard providing multidimensional market intelligence. Beyond the COT Index itself, users can monitor positioning extremity, which measures how unusual current levels are compared to historical norms using statistical techniques. The extremity metric clarifies whether a reading represents the ninety-fifth or ninety-ninth percentile, with values above two standard deviations indicating genuinely exceptional positioning. Market power quantifies each group's influence on total open interest. This metric expresses each trader category's net position as a percentage of total market open interest. A commercial entity holding forty percent of total open interest commands significantly more influence than one holding five percent, making their positioning signals more meaningful. Momentum and rate of change metrics reveal whether positions are building or contracting, providing early warning of potential regime shifts. Position velocity measures the rate of change in positioning changes, effectively a second derivative providing even earlier insight into inflection points. Sentiment divergence highlights disagreements between commercial and speculative positioning. This metric calculates the absolute difference between normalized commercial and large speculator index values. Wang (2003) found that these high-divergence environments frequently preceded increased volatility and reversals. The table also displays concentration metrics when available, showing how positioning is distributed among the largest handful of traders in each category. High concentration indicates a few dominant players controlling most of the positioning, while low concentration suggests broad-based participation across many traders. THE ALERT SYSTEM AND MONITORING The alert system, comprising five distinct alert conditions, enables systematic monitoring of dozens of futures markets without constant screen watching. The bullish and bearish COT signal alerts trigger when the index crosses user-defined thresholds, indicating the selected trader group has reached extreme positioning worthy of attention. These alerts fire in real-time as new weekly COT data publishes, typically Friday afternoon following the Tuesday measurement date. Extreme positioning alerts fire at ninety and ten index levels, representing the top and bottom ten percent of the historical range, warning of particularly stretched readings that historically precede reversals with high probability. When commercials reach a COT Index reading below ten, they are expressing their most bearish stance in the entire lookback period. The data staleness alert notifies users when COT reports have not updated for more than ten days, preventing reliance on outdated information for trading decisions. Government shutdowns or federal holidays can interrupt the normal Friday publication schedule. Using stale signals while believing them current creates dangerous false confidence. The indicator's watermark information display positioned in the bottom right corner provides essential context at a glance. This persistent display shows the symbol and timeframe, the COT report date timestamp, days since last update, and the current signal state. A trader analyzing a potential short entry in crude oil can glance at the watermark to instantly confirm positioning context without interrupting analysis flow. LIMITATIONS AND REALISTIC EXPECTATIONS Practical application requires understanding both the indicator's considerable strengths and inherent limitations. COT data inherently lags price action by three days, as Tuesday positions are not published until Friday afternoon. This delay means the indicator cannot catch rapid intraday reversals or respond to surprise news events. Traders using the COT Index for timing entries must accept this latency and focus on swing trading and position trading timeframes where three-day lags matter less than in day trading or scalping. The weekly publication schedule similarly makes the indicator unsuitable for short-term trading strategies requiring immediate feedback. The COT Index works best for traders operating on weekly or longer timeframes, where positioning shifts measured in weeks and months align with trading horizon. Extreme COT readings can persist far longer than typical technical indicators suggest, testing the patience and capital reserves of traders attempting to fade them. When crude oil enters a sustained bull market driven by genuine supply disruptions, commercial hedgers may maintain bearish positioning for many months as prices grind higher. A commercial COT Index reading of fifteen indicating extreme bearishness might persist for three months while prices continue rallying before finally reversing. Traders without sufficient capital and risk tolerance to weather such drawdowns will exit prematurely, precisely when the signal is about to work (Irwin and Sanders, 2012). Position sizing discipline becomes paramount when implementing COT-based strategies. Rather than risking large percentages of capital on individual signals, successful COT traders typically allocate modest position sizes across multiple signals, allowing some to take time to mature while others work more quickly. The indicator also cannot overcome fundamental regime changes that alter the structural drivers of markets. If gold enters a true secular bull market driven by monetary debasement, commercial hedgers may remain persistently bearish as mining companies sell forward years of production at what they perceive as favorable prices. Their positioning indicates valuation concerns from a production cost perspective, but cannot stop prices from rising if investment demand overwhelms physical supply-demand balance. Similarly, structural changes in market participation can alter the meaning of positioning extremes. The growth of commodity index investing in the two thousands brought massive passive long-only capital into futures markets, fundamentally changing typical positioning ranges. Traders relying on COT signals without recognizing this regime change would have generated numerous false bearish signals during the commodity supercycle from 2003 to 2008. The research foundation supporting COT analysis derives primarily from commodity markets where the commercial hedger information advantage is most pronounced. Studies specifically examining financial futures like equity indices and bonds show weaker but still present effects. Traders should calibrate expectations accordingly, recognizing that COT analysis likely works better for crude oil, natural gas, corn, and wheat than for the S&P 500, Treasury bonds, or currency futures. Another important limitation involves the reporting threshold structure. Not all market participants appear in COT data, only those holding positions above specified minimums. In markets dominated by a few large players, concentration metrics become critical for proper interpretation. A single large trader accounting for thirty percent of commercial positioning might skew the entire category if their individual circumstances are idiosyncratic rather than representative. GOLD FUTURES DURING A HYPOTHETICAL MARKET CYCLE Consider a practical example using gold futures during a hypothetical but realistic market scenario that illustrates how the COT Index indicator guides trading decisions through a complete market cycle. Suppose gold has rallied from fifteen hundred to nineteen hundred dollars per ounce over six months, driven by inflation concerns following aggressive monetary expansion, geopolitical uncertainty, and sustained buying by Asian central banks for reserve diversification. Large speculators, operating primarily trend-following strategies, have accumulated increasingly bullish positions throughout this rally. Their COT Index has climbed progressively from forty-five to eighty-five. The table display shows that large speculators now hold net long positions representing thirty-two percent of total open interest, their highest in four years. Momentum indicators show positive readings, indicating positions are still building though at a decelerating rate. Position velocity has turned negative, suggesting the pace of position building is slowing. Meanwhile, commercial hedgers have responded to the rally by aggressively selling forward production and inventory. Their COT Index has moved inversely to price, declining from fifty-five to twenty. This bearish commercial positioning represents mining companies locking in forward sales at prices they view as attractive relative to production costs. The table shows commercials now hold net short positions representing twenty-nine percent of total open interest, their most bearish stance in five years. Concentration metrics indicate this positioning is broadly distributed across many commercial entities, suggesting the bearish stance reflects collective industry view rather than idiosyncratic positioning by a single firm. Small traders, attracted by mainstream financial media coverage of gold's impressive rally, have recently piled into long positions. Their COT Index has jumped from forty-five to seventy-eight as retail investors chase the trend. Television financial networks feature frequent segments on gold with bullish guests. Internet forums and social media show surging retail interest. This retail enthusiasm historically marks late-stage trend development rather than early opportunity. The COT Index indicator, configured to monitor commercial positioning from a contrarian perspective, displays a clear bearish signal given the extreme commercial short positioning. The table displays multiple confirming metrics: positioning extremity shows commercials at the ninety-sixth percentile of bearishness, market power indicates they control twenty-nine percent of open interest, and sentiment divergence registers sixty-five, indicating massive disagreement between commercial hedgers and large speculators. This divergence, the highest in three years, places the market in the historically high-risk category for reversals. The interpretation requires nuance and consideration of context beyond just COT data. Commercials are not necessarily predicting an imminent crash. Rather, they are hedging business operations at what they collectively view as favorable price levels. However, the data reveals they have sold unusually large quantities of forward production, suggesting either exceptional production expectations for the year ahead or concern about sustaining current price levels or combination of both. Combined with extreme speculator positioning indicating a crowded long trade, and small trader enthusiasm confirming retail FOMO, the confluence suggests elevated reversal risk even if the precise timing remains uncertain. A prudent trader analyzing this situation might take several actions based on COT Index signals. Existing long positions could be tightened with closer stop losses. Profit-taking on a portion of long exposure could lock in gains while maintaining some participation. Some traders might initiate modest short positions as portfolio hedges, sizing them appropriately for the inherent uncertainty in timing reversals. Others might simply move to the sidelines, avoiding new long entries until positioning normalizes. The key lesson from case study analysis is that COT signals provide probabilistic edges rather than deterministic predictions. They work over many observations by identifying higher-probability configurations, not by generating perfect calls on individual trades. A fifty-five percent win rate with proper risk management produces substantial profits over time, yet still means forty-five percent of signals will be premature or wrong. Traders must embrace this probabilistic reality rather than seeking the impossible goal of perfect accuracy. INTEGRATION WITH TRADING SYSTEMS Integration with existing trading systems represents a natural and powerful use case for COT analysis, adding a positioning dimension to price-based technical approaches or fundamental analytical frameworks. Few traders rely exclusively on a single indicator or methodology. Rather, they build systems that synthesize multiple information sources, with each component addressing different aspects of market behavior. Trend followers might use COT extremes as regime filters, modifying position sizing or avoiding new trend entries when positioning reaches levels historically associated with reversals. Consider a classic trend-following system based on moving average crossovers and momentum breakouts. Integration of COT analysis adds nuance. When large speculator positioning exceeds ninety or commercial positioning falls below ten, the regime filter recognizes elevated reversal risk. The system might reduce position sizing by fifty percent for new signals during these high-risk periods (Kaufman, 2013). Mean reversion traders might require COT signal confluence before fading extended moves. When crude oil becomes technically overbought and large speculators show extreme long positioning above eighty-five, both signals confirm. If only technical indicators show extremes while positioning remains neutral, the potential short signal is rejected, avoiding fades of trends with underlying institutional support (Kaufman, 2013). Discretionary traders can monitor the indicator as a continuous awareness tool, informing bias and position sizing without dictating mechanical entries and exits. A discretionary trader might notice commercial positioning shifting from neutral to progressively more bullish over several months. This trend informs growing positive bias even without triggering mechanical signals. Multi-timeframe analysis represents another powerful integration approach. A trader might use daily charts for trade execution and timing while monitoring weekly COT positioning for strategic context. When both timeframes align, highest-probability opportunities emerge. Portfolio construction for futures traders can incorporate COT signals as an additional selection criterion. Markets showing strong technical setups AND favorable COT positioning receive highest allocations. Markets with strong technicals but neutral or unfavorable positioning receive reduced allocations. ADVANCED METRICS AND INTERPRETATION The metrics table transforms simple positioning data into multidimensional market intelligence. Position extremity, calculated as the absolute deviation from the historical mean normalized by standard deviation, helps identify truly unusual readings versus routine fluctuations. A reading above two standard deviations indicates ninety-fifth percentile or higher extremity. Above three standard deviations indicates ninety-ninth percentile or higher, genuinely rare positioning that historically precedes major events with high probability. Market power, expressed as a percentage of total open interest, reveals whose positioning matters most from a mechanical market impact perspective. Consider two scenarios in gold futures. In scenario one, commercials show a COT Index reading of fifteen while their market power metric shows they hold net shorts representing thirty-five percent of open interest. This is a high-confidence bearish signal. In scenario two, commercials also show a reading of fifteen, but market power shows only eight percent. While positioning is extreme relative to this category's normal range, their limited market share means less mechanical influence on price. The rate of change and momentum metrics highlight whether positions are accelerating or decelerating, often providing earlier warnings than absolute levels alone. A COT Index reading of seventy-five with rapidly building momentum suggests continued movement toward extremes. Conversely, a reading of eighty-five with decelerating or negative momentum indicates the positioning trend is exhausting. Position velocity measures the rate of change in positioning changes, effectively a second derivative. When velocity shifts from positive to negative, it indicates that while positioning may still be growing, the pace of growth is slowing. This deceleration often precedes actual reversal in positioning direction by several weeks. Sentiment divergence calculates the absolute difference between normalized commercial and large speculator index values. When commercials show extreme bearish positioning at twenty while large speculators show extreme bullish positioning at eighty, the divergence reaches sixty, representing near-maximum disagreement. Wang (2003) found that these high-divergence environments frequently preceded increased volatility and reversals. The mechanism is intuitive. Extreme divergence indicates the informed hedgers and momentum-following speculators have positioned opposite each other with conviction. One group will prove correct and profit while the other proves incorrect and suffers losses. The resolution of this disagreement through price movement often involves volatility. The table also displays concentration metrics when available. High concentration indicates a few dominant players controlling most of the positioning within a category, while low concentration suggests broad-based participation. Broad-based positioning more reliably reflects collective market intelligence and industry consensus. If mining companies globally all independently decide to hedge aggressively at similar price levels, it suggests genuine industry-wide view about price valuations rather than circumstances specific to one firm. DATA QUALITY AND RELIABILITY The CFTC has maintained COT reporting in various forms since the nineteen twenties, providing nearly a century of positioning data across multiple market cycles. However, data quality and reporting standards have evolved substantially over this long period. Modern electronic reporting implemented in the late nineteen nineties and early two thousands significantly improved accuracy and timeliness compared to earlier paper-based systems. Traders should understand that COT reports capture positions as of Tuesday's close each week. Markets remain open three additional days before publication on Friday afternoon, meaning the reported data is three days stale when received. During periods of rapid market movement or major news events, this lag can be significant. The indicator addresses this limitation by including timestamp information and staleness warnings. The three-day lag creates particular challenges during extreme volatility episodes. Flash crashes, surprise central bank interventions, geopolitical shocks, and other high-impact events can completely transform market positioning within hours. Traders must exercise judgment about whether reported positioning remains relevant given intervening events. Reporting thresholds also mean that not all market participants appear in disaggregated COT data. Traders holding positions below specified minimums aggregate into the non-reportable or small trader category. This aggregation affects different markets differently. In highly liquid contracts like crude oil with thousands of participants, reportable traders might represent seventy to eighty percent of open interest. In thinly traded contracts with only dozens of active participants, a few large reportable positions might represent ninety-five percent of open interest. Another data quality consideration involves trader classification into categories. The CFTC assigns traders to commercial or non-commercial categories based on reported business purpose and activities. However, this process is not perfect. Some entities engage in both commercial and speculative activities, creating ambiguity about proper classification. The transition to Disaggregated reports attempted to address some of these ambiguities by creating more granular categories. COMPARISON WITH ALTERNATIVE APPROACHES Several alternative approaches to COT analysis exist in the trading community beyond the normalization methodology employed by this indicator. Some analysts focus on absolute position changes week-over-week rather than index-based normalization. This approach calculates the change in net positioning from one week to the next. The emphasis falls on momentum in positioning changes rather than absolute levels relative to history. This method potentially identifies regime shifts earlier but sacrifices cross-market comparability (Briese, 2008). Other practitioners employ more complex statistical transformations including percentile rankings, z-score standardization, and machine learning classification algorithms. Ruan and Zhang (2018) demonstrated that machine learning models applied to COT data could achieve modest improvements in forecasting accuracy compared to simple threshold-based approaches. However, these gains came at the cost of interpretability and implementation complexity. The COT Index indicator intentionally employs a relatively straightforward normalization methodology for several important reasons. First, transparency enhances user understanding and trust. Traders can verify calculations manually and develop intuitive feel for what different readings mean. Second, academic research suggests that most of the predictive power in COT data comes from extreme positioning levels rather than subtle patterns requiring complex statistical methods to detect. Third, robust methods that work consistently across many markets and time periods tend to be simpler rather than more complex, reducing the risk of overfitting to historical data. Fourth, the complexity costs of implementation matter for retail traders without programming teams or computational infrastructure. PSYCHOLOGICAL ASPECTS OF COT TRADING Trading based on COT data requires psychological fortitude that differs from momentum-based approaches. Contrarian positioning signals inherently mean betting against prevailing market sentiment and recent price action. When commercials reach extreme bearish positioning, prices have typically been rising, sometimes for extended periods. The price chart looks bullish, momentum indicators confirm strength, moving averages align positively. The COT signal says bet against all of this. This psychological difficulty explains why COT analysis remains underutilized relative to trend-following methods. Human psychology strongly predisposes us toward extrapolation and recency bias. When prices rally for months, our pattern-matching brains naturally expect continued rally. The recent price action dominates our perception, overwhelming rational analysis about positioning extremes and historical probabilities. The COT signal asking us to sell requires overriding these powerful psychological impulses. The indicator design attempts to support the required psychological discipline through several features. Clear threshold markers and signal states reduce ambiguity about when signals trigger. When the commercial index crosses below twenty, the signal is explicit and unambiguous. The background shifts to red, the signal label displays bearish, and alerts fire. This explicitness helps traders act on signals rather than waiting for additional confirmation that may never arrive. The metrics table provides analytical justification for contrarian positions, helping traders maintain conviction during inevitable periods of adverse price movement. When a trader enters short positions based on extreme commercial bearish positioning but prices continue rallying for several weeks, doubt naturally emerges. The table display provides reassurance. Commercial positioning remains extremely bearish. Divergence remains high. The positioning thesis remains intact even though price action has not yet confirmed. Alert functionality ensures traders do not miss signals due to inattention while also not requiring constant monitoring that can lead to emotional decision-making. Setting alerts for COT extremes enables a healthier relationship with markets. When meaningful signals occur, alerts notify them. They can then calmly assess the situation and execute planned responses. However, no indicator design can completely overcome the psychological difficulty of contrarian trading. Some traders simply cannot maintain short positions while prices rally. For these traders, COT analysis might be better employed as an exit signal for long positions rather than an entry signal for shorts. Ultimately, successful COT trading requires developing comfort with probabilistic thinking rather than certainty-seeking. The signals work over many observations by identifying higher-probability configurations, not by generating perfect calls on individual trades. A fifty-five or sixty percent win rate with proper risk management produces substantial profits over years, yet still means forty to forty-five percent of signals will be premature or wrong. COT analysis provides genuine edge, but edge means probability advantage, not elimination of losing trades. EDUCATIONAL RESOURCES AND CONTINUOUS LEARNING The indicator provides extensive built-in educational resources through its documentation, detailed tooltips, and transparent calculations. However, mastering COT analysis requires study beyond any single tool or resource. Several excellent resources provide valuable extensions of the concepts covered in this guide. Books and practitioner-focused monographs offer accessible entry points. Stephen Briese published The Commitments of Traders Bible in two thousand eight, offering detailed breakdowns of how different markets and trader categories behave (Briese, 2008). Briese's work stands out for its empirical focus and market-specific insights. Jack Schwager includes discussion of COT analysis within the broader context of market behavior in his book Market Sense and Nonsense (Schwager, 2012). Perry Kaufman's Trading Systems and Methods represents perhaps the most rigorous practitioner-focused text on systematic trading approaches including COT analysis (Kaufman, 2013). Academic journal articles provide the rigorous statistical foundation underlying COT analysis. The Journal of Futures Markets regularly publishes research on positioning data and its predictive properties. Bessembinder and Chan's earlier work on systematic risk, hedging pressure, and risk premiums in futures markets provides theoretical foundation (Bessembinder, 1992). Chang's examination of speculator returns provides historical context (Chang, 1985). Irwin and Sanders provide essential skeptical perspective in their two thousand twelve article (Irwin and Sanders, 2012). Wang's two thousand three article provides one of the most empirical analyses of COT data across multiple commodity markets (Wang, 2003). Online resources extend beyond academic and book-length treatments. The CFTC website provides free access to current and historical COT reports in multiple formats. The explanatory materials section offers detailed documentation of report construction, category definitions, and historical methodology changes. Traders serious about COT analysis should read these official CFTC documents to understand exactly what they are analyzing. Commercial COT data services such as Barchart provide enhanced visualization and analysis tools beyond raw CFTC data. TradingView's educational materials, published scripts library, and user community provide additional resources for exploring different approaches to COT analysis. The key to mastering COT analysis lies not in finding a single definitive source but rather in building understanding through multiple perspectives and information sources. Academic research provides rigorous empirical foundation. Practitioner-focused books offer practical implementation insights. Direct engagement with data through systematic backtesting develops intuition about how positioning dynamics manifest across different market conditions. SYNTHESIZING KNOWLEDGE INTO PRACTICE The COT Index indicator represents the synthesis of academic research, trading experience, and software engineering into a practical tool accessible to retail traders equipped with nothing more than a TradingView account and willingness to learn. What once required expensive data subscriptions, custom programming capabilities, statistical software, and institutional resources now appears as a straightforward indicator requiring only basic parameter selection and modest study to understand. This democratization of institutional-grade analysis tools represents a broader trend in financial markets over recent decades. Yet technology and data access alone provide no edge without understanding and discipline. Markets remain relentlessly efficient at eliminating edges that become too widely known and mechanically exploited. The COT Index indicator succeeds only when users invest time learning the underlying concepts, understand the limitations and probability distributions involved, and integrate signals thoughtfully into trading plans rather than applying them mechanically. The academic research demonstrates conclusively that institutional positioning contains genuine information about future price movements, particularly at extremes where commercial hedgers are maximally bearish or bullish relative to historical norms. This informational content is neither perfect nor deterministic but rather probabilistic, providing edge over many observations through identification of higher-probability configurations. Bessembinder and Chan's finding that commercial positioning explained modest but significant variance in future returns illustrates this probabilistic nature perfectly (Bessembinder and Chan, 1992). The effect is real and statistically significant, yet it explains perhaps ten to fifteen percent of return variance rather than most variance. Much of price movement remains unpredictable even with positioning intelligence. The practical implication is that COT analysis works best as one component of a trading system rather than a standalone oracle. It provides the positioning dimension, revealing where the smart money has positioned and where the crowd has followed, but price action analysis provides the timing dimension. Fundamental analysis provides the catalyst dimension. Risk management provides the survival dimension. These components work together synergistically. The indicator's design philosophy prioritizes transparency and education over black-box complexity, empowering traders to understand exactly what they are analyzing and why. Every calculation is documented and user-adjustable. The threshold markers, background coloring, tables, and clear signal states provide multiple reinforcing channels for conveying the same information. This educational approach reflects a conviction that sustainable trading success comes from genuine understanding rather than mechanical system-following. Traders who understand why commercial positioning matters, how different trader categories behave, what positioning extremes signify, and where signals fit within probability distributions can adapt when market conditions change. Traders mechanically following black-box signals without comprehension abandon systems after normal losing streaks. The research foundation supporting COT analysis comes primarily from commodity markets where commercial hedger informational advantages are most pronounced. Agricultural producers hedging crops know more about supply conditions than distant speculators. Energy companies hedging production know more about operating costs than financial traders. Metals miners hedging output know more about ore grades than index funds. Financial futures markets show weaker but still present effects. The journey from reading this documentation to profitable trading based on COT analysis involves several stages that cannot be rushed. Initial reading and basic understanding represents the first stage. Historical study represents the second stage, reviewing past market cycles to observe how positioning extremes preceded major turning points. Paper trading or small-size real trading represents the third stage to experience the psychological challenges. Refinement based on results and personal psychology represents the fourth stage. Markets will continue evolving. New participant categories will emerge. Regulatory structures will change. Technology will advance. Yet the fundamental dynamics driving COT analysis, that different market participants have different information, different motivations, and different forecasting abilities that manifest in their positioning, will persist as long as futures markets exist. While specific thresholds or optimal parameters may shift over time, the core logic remains sound and adaptable. The trader equipped with this indicator, understanding of the theory and evidence behind COT analysis, realistic expectations about probability rather than certainty, discipline to maintain positions through adverse volatility, and patience to allow signals time to develop possesses genuine edge in markets. The edge is not enormous, markets cannot allow large persistent inefficiencies without arbitraging them away, but it is real, measurable, and exploitable by those willing to invest in learning and disciplined application. REFERENCES Bessembinder, H. (1992) Systematic risk, hedging pressure, and risk premiums in futures markets, Review of Financial Studies, 5(4), pp. 637-667. Bessembinder, H. and Chan, K. (1992) The profitability of technical trading rules in the Asian stock markets, Pacific-Basin Finance Journal, 3(2-3), pp. 257-284. Briese, S. (2008) The Commitments of Traders Bible: How to Profit from Insider Market Intelligence. Hoboken: John Wiley & Sons. Chang, E.C. (1985) Returns to speculators and the theory of normal backwardation, Journal of Finance, 40(1), pp. 193-208. Commodity Futures Trading Commission (CFTC) (2009) Explanatory Notes: Disaggregated Commitments of Traders Report. Available at: www.cftc.gov (Accessed: 15 January 2025). Commodity Futures Trading Commission (CFTC) (2020) Commitments of Traders: About the Report. Available at: www.cftc.gov (Accessed: 15 January 2025). Irwin, S.H. and Sanders, D.R. (2012) Testing the Masters Hypothesis in commodity futures markets, Energy Economics, 34(1), pp. 256-269. Kaufman, P.J. (2013) Trading Systems and Methods. 5th edn. Hoboken: John Wiley & Sons. Ruan, Y. and Zhang, Y. (2018) Forecasting commodity futures prices using machine learning: Evidence from the Chinese commodity futures market, Applied Economics Letters, 25(12), pp. 845-849. Sanders, D.R., Boris, K. and Manfredo, M. (2004) Hedgers, funds, and small speculators in the energy futures markets: an analysis of the CFTC's Commitments of Traders reports, Energy Economics, 26(3), pp. 425-445. Schwager, J.D. (2012) Market Sense and Nonsense: How the Markets Really Work and How They Don't. Hoboken: John Wiley & Sons. Tharp, V.K. (2008) Super Trader: Make Consistent Profits in Good and Bad Markets. New York: McGraw-Hill. Wang, C. (2003) The behavior and performance of major types of futures traders, Journal of Futures Markets, 23(1), pp. 1-31. Williams, L.R. and Noseworthy, M. (2009) The Right Stock at the Right Time: Prospering in the Coming Good Years. Hoboken: John Wiley & Sons. FURTHER READING For traders seeking to deepen their understanding of COT analysis and futures market positioning beyond this documentation, the following resources provide valuable extensions: Academic Journal Articles: Fishe, R.P.H. and Smith, A. (2012) Do speculators drive commodity prices away from supply and demand fundamentals?, Journal of Commodity Markets, 1(1), pp. 1-16. Haigh, M.S., Hranaiova, J. and Overdahl, J.A. (2007) Hedge funds, volatility, and liquidity provision in energy futures markets, Journal of Alternative Investments, 9(4), pp. 10-38. Kocagil, A.E. (1997) Does futures speculation stabilize spot prices? Evidence from metals markets, Applied Financial Economics, 7(1), pp. 115-125. Sanders, D.R. and Irwin, S.H. (2011) The impact of index funds in commodity futures markets: A systems approach, Journal of Alternative Investments, 14(1), pp. 40-49. Books and Practitioner Resources: Murphy, J.J. (1999) Technical Analysis of the Financial Markets: A Guide to Trading Methods and Applications. New York: New York Institute of Finance. Pring, M.J. (2002) Technical Analysis Explained: The Investor's Guide to Spotting Investment Trends and Turning Points. 4th edn. New York: McGraw-Hill. Federal Reserve and Research Institution Publications: Federal Reserve Banks regularly publish working papers examining commodity markets, futures positioning, and price discovery mechanisms. The Federal Reserve Bank of San Francisco and Federal Reserve Bank of Kansas City maintain active research programs in this area. Online Resources: The CFTC website provides free access to current and historical COT reports, explanatory materials, and regulatory documentation. Barchart offers enhanced COT data visualization and screening tools. TradingView's community library contains numerous published scripts and educational materials exploring different approaches to positioning analysis.
Chỉ báo Pine Script®
của EdgeTools
8
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.
Chỉ báo Pine Script®
của exlux
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.
Chiến lược Pine Script®
của AutomatedTradingAlgorithms
2