TradingView Alerts (Expo)█ Overview
The TradingView inbuilt alert feature inspires this alert tool.
TradingView Alerts (Expo) enables traders to set alerts on any indicator on TradingView, both public, protected, and invite-only scripts (if you are granted access). In this way, traders can set the alerts they want for any indicator they have access to. This feature is highly needed since many indicators on TradingView do not have the particular alert the trader looks for, this alert tool solves that problem and lets everyone create the alert they need. Many predefined conditions are included, such as "crossings," "turning up/down," "entering a channel," and much more.
█ TradingView alerts
TradingView alerts are a popular and convenient way of getting an immediate notification when the asset meets your set alert criteria. It helps traders to stay updated on the assets and timeframe they follow.
█ Alert table
Keep track of the average amount of alerts that have been triggered per day, per month, and per week. It helps traders to understand how frequently they can expect an alert to trigger.
█ Predefined alerts types
Crossing
The Crossing alert is triggered when the source input crosses (up or down) from the selected price or value.
Crossing Down / Crossing Up
The Crossing Down alert is triggered when the source input crosses down from the selected price or value.
The Crossing Up alert is triggered when the source input crosses up from the selected price or value.
Greater Than / Less Than
The Greater Than alert is triggered when the source input reaches the selected value or price.
The Less Than alert is triggered when the source input reaches the selected value or price.
Entering Channel / Exiting Channel
The Entering Channel alert is triggered when the source input enters the selected channel value.
The Exiting Channel alert is triggered when the source input exits the selected channel value.
Notice that this alert only works if you have selected "Channels."
Inside Channel / Outside Channel
The Inside Channel alert is triggered when the source input is within the selected Upper and Lower Channel boundaries.
The Outside Channel alert is triggered when the source input is outside the selected Upper and Lower Channel boundaries.
Notice that this alert only works if you have selected "Channels."
Moving Up / Moving Down
This alert is the same as "crossing up/down" within x-bars.
The Moving Up alert is triggered when the source input increases by a certain value within x-bars.
The Moving Down alert is triggered when the source input decreases by a certain value within x-bars.
Notice that you have to set the Number of Bars parameter!
The calculation starts from the last formed candlestick.
Moving Up % / Moving Down %
The Moving Up % alert is triggered when the source input increases by a certain percentage value within x-bars.
The Moving Down % alert is triggered when the source input decreases by a certain percentage value within x-bars.
Notice that you have to set the Number of Bars parameter!
The calculation starts from the last formed candlestick.
Turning Up / Turning Down
The Turning Up alert is triggered when the source input turns up.
The Turning Down alert is triggered when the source input turns down.
-----------------
Disclaimer
The information contained in my Scripts/Indicators/Ideas/Algos/Systems does not constitute financial advice or a solicitation to buy or sell any securities of any type. I will not accept liability for any loss or damage, including without limitation any loss of profit, which may arise directly or indirectly from the use of or reliance on such information.
All investments involve risk, and the past performance of a security, industry, sector, market, financial product, trading strategy, backtest, or individual's trading does not guarantee future results or returns. Investors are fully responsible for any investment decisions they make. Such decisions should be based solely on an evaluation of their financial circumstances, investment objectives, risk tolerance, and liquidity needs.
My Scripts/Indicators/Ideas/Algos/Systems are only for educational purposes!
Cerca negli script per "TradingView+手机版"
Tradingview - Screener RatingsEver wondered what is behind the the Tradingview Screener Signals:
www.tradingview.com
Strong buy is between 0.5 and 1
Buy is between 0 and 0.5
Sell is between 0 and -0.5
Strong Sell is between -0.5 and -1
Request█ OVERVIEW
This library is a tool for Pine Script™ programmers that consolidates access to a wide range of lesser-known data feeds available on TradingView, including metrics from the FRED database, FINRA short sale volume, open interest, and COT data. The functions in this library simplify requests for these data feeds, making them easier to retrieve and use in custom scripts.
█ CONCEPTS
Federal Reserve Economic Data (FRED)
FRED (Federal Reserve Economic Data) is a comprehensive online database curated by the Federal Reserve Bank of St. Louis. It provides free access to extensive economic and financial data from U.S. and international sources. FRED includes numerous economic indicators such as GDP, inflation, employment, and interest rates. Additionally, it provides financial market data, regional statistics, and international metrics such as exchange rates and trade balances.
Sourced from reputable organizations, including U.S. government agencies, international institutions, and other public and private entities, FRED enables users to analyze over 825,000 time series, download their data in various formats, and integrate their information into analytical tools and programming workflows.
On TradingView, FRED data is available from ticker identifiers with the "FRED:" prefix. Users can search for FRED symbols in the "Symbol Search" window, and Pine scripts can retrieve data for these symbols via `request.*()` function calls.
FINRA Short Sale Volume
FINRA (the Financial Industry Regulatory Authority) is a non-governmental organization that supervises and regulates U.S. broker-dealers and securities professionals. Its primary aim is to protect investors and ensure integrity and transparency in financial markets.
FINRA's Short Sale Volume data provides detailed information about daily short-selling activity across U.S. equity markets. This data tracks the volume of short sales reported to FINRA's trade reporting facilities (TRFs), including shares sold on FINRA-regulated Alternative Trading Systems (ATSs) and over-the-counter (OTC) markets, offering transparent access to short-selling information not typically available from exchanges. This data helps market participants, researchers, and regulators monitor trends in short-selling and gain insights into bearish sentiment, hedging strategies, and potential market manipulation. Investors often use this data alongside other metrics to assess stock performance, liquidity, and overall trading activity.
It is important to note that FINRA's Short Sale Volume data does not consolidate short sale information from public exchanges and excludes trading activity that is not publicly disseminated.
TradingView provides ticker identifiers for requesting Short Sale Volume data with the format "FINRA:_SHORT_VOLUME", where "" is a supported U.S. equities symbol (e.g., "AAPL").
Open Interest (OI)
Open interest is a cornerstone indicator of market activity and sentiment in derivatives markets such as options or futures. In contrast to volume, which measures the number of contracts opened or closed within a period, OI measures the number of outstanding contracts that are not yet settled. This distinction makes OI a more robust indicator of how money flows through derivatives, offering meaningful insights into liquidity, market interest, and trends. Many traders and investors analyze OI alongside volume and price action to gain an enhanced perspective on market dynamics and reinforce trading decisions.
TradingView offers many ticker identifiers for requesting OI data with the format "_OI", where "" represents a derivative instrument's ticker ID (e.g., "COMEX:GC1!").
Commitment of Traders (COT)
Commitment of Traders data provides an informative weekly breakdown of the aggregate positions held by various market participants, including commercial hedgers, non-commercial speculators, and small traders, in the U.S. derivative markets. Tallied and managed by the Commodity Futures Trading Commission (CFTC) , these reports provide traders and analysts with detailed insight into an asset's open interest and help them assess the actions of various market players. COT data is valuable for gaining a deeper understanding of market dynamics, sentiment, trends, and liquidity, which helps traders develop informed trading strategies.
TradingView has numerous ticker identifiers that provide access to time series containing data for various COT metrics. To learn about COT ticker IDs and how they work, see our LibraryCOT publication.
█ USING THE LIBRARY
Common function characteristics
• This library's functions construct ticker IDs with valid formats based on their specified parameters, then use them as the `symbol` argument in request.security() to retrieve data from the specified context.
• Most of these functions automatically select the timeframe of a data request because the data feeds are not available for all timeframes.
• All the functions have two overloads. The first overload of each function uses values with the "simple" qualifier to define the requested context, meaning the context does not change after the first script execution. The second accepts "series" values, meaning it can request data from different contexts across executions.
• The `gaps` parameter in most of these functions specifies whether the returned data is `na` when a new value is unavailable for request. By default, its value is `false`, meaning the call returns the last retrieved data when no new data is available.
• The `repaint` parameter in applicable functions determines whether the request can fetch the latest unconfirmed values from a higher timeframe on realtime bars, which might repaint after the script restarts. If `false`, the function only returns confirmed higher-timeframe values to avoid repainting. The default value is `true`.
`fred()`
The `fred()` function retrieves the most recent value of a specified series from the Federal Reserve Economic Data (FRED) database. With this function, programmers can easily fetch macroeconomic indicators, such as GDP and unemployment rates, and use them directly in their scripts.
How it works
The function's `fredCode` parameter accepts a "string" representing the unique identifier of a specific FRED series. Examples include "GDP" for the "Gross Domestic Product" series and "UNRATE" for the "Unemployment Rate" series. Over 825,000 codes are available. To access codes for available series, search the FRED website .
The function adds the "FRED:" prefix to the specified `fredCode` to construct a valid FRED ticker ID (e.g., "FRED:GDP"), which it uses in request.security() to retrieve the series data.
Example Usage
This line of code requests the latest value from the Gross Domestic Product series and assigns the returned value to a `gdpValue` variable:
float gdpValue = fred("GDP")
`finraShortSaleVolume()`
The `finraShortSaleVolume()` function retrieves EOD data from a FINRA Short Sale Volume series. Programmers can call this function to retrieve short-selling information for equities listed on supported exchanges, namely NASDAQ, NYSE, and NYSE ARCA.
How it works
The `symbol` parameter determines which symbol's short sale volume information is retrieved by the function. If the value is na , the function requests short sale volume data for the chart's symbol. The argument can be the name of the symbol from a supported exchange (e.g., "AAPL") or a ticker ID with an exchange prefix ("NASDAQ:AAPL"). If the `symbol` contains an exchange prefix, it must be one of the following: "NASDAQ", "NYSE", "AMEX", or "BATS".
The function constructs a ticker ID in the format "FINRA:ticker_SHORT_VOLUME", where "ticker" is the symbol name without the exchange prefix (e.g., "AAPL"). It then uses the ticker ID in request.security() to retrieve the available data.
Example Usage
This line of code retrieves short sale volume for the chart's symbol and assigns the result to a `shortVolume` variable:
float shortVolume = finraShortSaleVolume(syminfo.tickerid)
This example requests short sale volume for the "NASDAQ:AAPL" symbol, irrespective of the current chart:
float shortVolume = finraShortSaleVolume("NASDAQ:AAPL")
`openInterestFutures()` and `openInterestCrypto()`
The `openInterestFutures()` function retrieves EOD open interest (OI) data for futures contracts. The `openInterestCrypto()` function provides more granular OI data for cryptocurrency contracts.
How they work
The `openInterestFutures()` function retrieves EOD closing OI information. Its design is focused primarily on retrieving OI data for futures, as only EOD OI data is available for these instruments. If the chart uses an intraday timeframe, the function requests data from the "1D" timeframe. Otherwise, it uses the chart's timeframe.
The `openInterestCrypto()` function retrieves opening, high, low, and closing OI data for a cryptocurrency contract on a specified timeframe. Unlike `openInterest()`, this function can also retrieve granular data from intraday timeframes.
Both functions contain a `symbol` parameter that determines the symbol for which the calls request OI data. The functions construct a valid OI ticker ID from the chosen symbol by appending "_OI" to the end (e.g., "CME:ES1!_OI").
The `openInterestFutures()` function requests and returns a two-element tuple containing the futures instrument's EOD closing OI and a "bool" condition indicating whether OI is rising.
The `openInterestCrypto()` function requests and returns a five-element tuple containing the cryptocurrency contract's opening, high, low, and closing OI, and a "bool" condition indicating whether OI is rising.
Example usage
This code line calls `openInterest()` to retrieve EOD OI and the OI rising condition for a futures symbol on the chart, assigning the values to two variables in a tuple:
= openInterestFutures(syminfo.tickerid)
This line retrieves the EOD OI data for "CME:ES1!", irrespective of the current chart's symbol:
= openInterestFutures("CME:ES1!")
This example uses `openInterestCrypto()` to retrieve OHLC OI data and the OI rising condition for a cryptocurrency contract on the chart, sampled at the chart's timeframe. It assigns the returned values to five variables in a tuple:
= openInterestCrypto(syminfo.tickerid, timeframe.period)
This call retrieves OI OHLC and rising information for "BINANCE:BTCUSDT.P" on the "1D" timeframe:
= openInterestCrypto("BINANCE:BTCUSDT.P", "1D")
`commitmentOfTraders()`
The `commitmentOfTraders()` function retrieves data from the Commitment of Traders (COT) reports published by the Commodity Futures Trading Commission (CFTC). This function significantly simplifies the COT request process, making it easier for programmers to access and utilize the available data.
How It Works
This function's parameters determine different parts of a valid ticker ID for retrieving COT data, offering a streamlined alternative to constructing complex COT ticker IDs manually. The `metricName`, `metricDirection`, and `includeOptions` parameters are required. They specify the name of the reported metric, the direction, and whether it includes information from options contracts.
The function also includes several optional parameters. The `CFTCCode` parameter allows programmers to request data for a specific report code. If unspecified, the function requests data based on the chart symbol's root prefix, base currency, or quoted currency, depending on the `mode` argument. The call can specify the report type ("Legacy", "Disaggregated", or "Financial") and metric type ("All", "Old", or "Other") with the `typeCOT` and `metricType` parameters.
Explore the CFTC website to find valid report codes for specific assets. To find detailed information about the metrics included in the reports and their meanings, see the CFTC's Explanatory Notes .
View the function's documentation below for detailed explanations of its parameters. For in-depth information about COT ticker IDs and more advanced functionality, refer to our previously published COT library .
Available metrics
Different COT report types provide different metrics . The tables below list all available metrics for each type and their applicable directions:
+------------------------------+------------------------+
| Legacy (COT) Metric Names | Directions |
+------------------------------+------------------------+
| Open Interest | No direction |
| Noncommercial Positions | Long, Short, Spreading |
| Commercial Positions | Long, Short |
| Total Reportable Positions | Long, Short |
| Nonreportable Positions | Long, Short |
| Traders Total | No direction |
| Traders Noncommercial | Long, Short, Spreading |
| Traders Commercial | Long, Short |
| Traders Total Reportable | Long, Short |
| Concentration Gross LT 4 TDR | Long, Short |
| Concentration Gross LT 8 TDR | Long, Short |
| Concentration Net LT 4 TDR | Long, Short |
| Concentration Net LT 8 TDR | Long, Short |
+------------------------------+------------------------+
+-----------------------------------+------------------------+
| Disaggregated (COT2) Metric Names | Directions |
+-----------------------------------+------------------------+
| Open Interest | No Direction |
| Producer Merchant Positions | Long, Short |
| Swap Positions | Long, Short, Spreading |
| Managed Money Positions | Long, Short, Spreading |
| Other Reportable Positions | Long, Short, Spreading |
| Total Reportable Positions | Long, Short |
| Nonreportable Positions | Long, Short |
| Traders Total | No Direction |
| Traders Producer Merchant | Long, Short |
| Traders Swap | Long, Short, Spreading |
| Traders Managed Money | Long, Short, Spreading |
| Traders Other Reportable | Long, Short, Spreading |
| Traders Total Reportable | Long, Short |
| Concentration Gross LE 4 TDR | Long, Short |
| Concentration Gross LE 8 TDR | Long, Short |
| Concentration Net LE 4 TDR | Long, Short |
| Concentration Net LE 8 TDR | Long, Short |
+-----------------------------------+------------------------+
+-------------------------------+------------------------+
| Financial (COT3) Metric Names | Directions |
+-------------------------------+------------------------+
| Open Interest | No Direction |
| Dealer Positions | Long, Short, Spreading |
| Asset Manager Positions | Long, Short, Spreading |
| Leveraged Funds Positions | Long, Short, Spreading |
| Other Reportable Positions | Long, Short, Spreading |
| Total Reportable Positions | Long, Short |
| Nonreportable Positions | Long, Short |
| Traders Total | No Direction |
| Traders Dealer | Long, Short, Spreading |
| Traders Asset Manager | Long, Short, Spreading |
| Traders Leveraged Funds | Long, Short, Spreading |
| Traders Other Reportable | Long, Short, Spreading |
| Traders Total Reportable | Long, Short |
| Concentration Gross LE 4 TDR | Long, Short |
| Concentration Gross LE 8 TDR | Long, Short |
| Concentration Net LE 4 TDR | Long, Short |
| Concentration Net LE 8 TDR | Long, Short |
+-------------------------------+------------------------+
Example usage
This code line retrieves "Noncommercial Positions (Long)" data, without options information, from the "Legacy" report for the chart symbol's root, base currency, or quote currency:
float nonCommercialLong = commitmentOfTraders("Noncommercial Positions", "Long", false)
This example retrieves "Managed Money Positions (Short)" data, with options included, from the "Disaggregated" report:
float disaggregatedData = commitmentOfTraders("Managed Money Positions", "Short", true, "", "Disaggregated")
█ NOTES
• This library uses dynamic requests , allowing dynamic ("series") arguments for the parameters defining the context (ticker ID, timeframe, etc.) of a `request.*()` function call. With this feature, a single `request.*()` call instance can flexibly retrieve data from different feeds across historical executions. Additionally, scripts can use such calls in the local scopes of loops, conditional structures, and even exported library functions, as demonstrated in this script. All scripts coded in Pine Script™ v6 have dynamic requests enabled by default. To learn more about the behaviors and limitations of this feature, see the Dynamic requests section of the Pine Script™ User Manual.
• The library's example code offers a simple demonstration of the exported functions. The script retrieves available data using the function specified by the "Series type" input. The code requests a FRED series or COT (Legacy), FINRA Short Sale Volume, or Open Interest series for the chart's symbol with specific parameters, then plots the retrieved data as a step-line with diamond markers.
Look first. Then leap.
█ EXPORTED FUNCTIONS
This library exports the following functions:
fred(fredCode, gaps)
Requests a value from a specified Federal Reserve Economic Data (FRED) series. FRED is a comprehensive source that hosts numerous U.S. economic datasets. To explore available FRED datasets and codes, search for specific categories or keywords at fred.stlouisfed.org Calls to this function count toward a script's `request.*()` call limit.
Parameters:
fredCode (series string) : The unique identifier of the FRED series. The function uses the value to create a valid ticker ID for retrieving FRED data in the format `"FRED:fredCode"`. For example, `"GDP"` refers to the "Gross Domestic Product" series ("FRED:GDP"), and `"GFDEBTN"` refers to the "Federal Debt: Total Public Debt" series ("FRED:GFDEBTN").
gaps (simple bool) : Optional. If `true`, the function returns a non-na value only when a new value is available from the requested context. If `false`, the function returns the latest retrieved value when new data is unavailable. The default is `false`.
Returns: (float) The value from the requested FRED series.
finraShortSaleVolume(symbol, gaps, repaint)
Requests FINRA daily short sale volume data for a specified symbol from one of the following exchanges: NASDAQ, NYSE, NYSE ARCA. If the chart uses an intraday timeframe, the function requests data from the "1D" timeframe. Otherwise, it uses the chart's timeframe. Calls to this function count toward a script's `request.*()` call limit.
Parameters:
symbol (series string) : The symbol for which to request short sale volume data. If the specified value contains an exchange prefix, it must be one of the following: "NASDAQ", "NYSE", "AMEX", "BATS".
gaps (simple bool) : Optional. If `true`, the function returns a non-na value only when a new value is available from the requested context. If `false`, the function returns the latest retrieved value when new data is unavailable. The default is `false`.
repaint (simple bool) : Optional. If `true` and the chart's timeframe is intraday, the value requested on realtime bars may change its time offset after the script restarts its executions. If `false`, the function returns the last confirmed period's values to avoid repainting. The default is `true`.
Returns: (float) The short sale volume for the specified symbol or the chart's symbol.
openInterestFutures(symbol, gaps, repaint)
Requests EOD open interest (OI) and OI rising information for a valid futures symbol. If the chart uses an intraday timeframe, the function requests data from the "1D" timeframe. Otherwise, it uses the chart's timeframe. Calls to this function count toward a script's `request.*()` call limit.
Parameters:
symbol (series string) : The symbol for which to request open interest data.
gaps (simple bool) : Optional. If `true`, the function returns non-na values only when new values are available from the requested context. If `false`, the function returns the latest retrieved values when new data is unavailable. The default is `false`.
repaint (simple bool) : Optional. If `true` and the chart's timeframe is intraday, the value requested on realtime bars may change its time offset after the script restarts its executions. If `false`, the function returns the last confirmed period's values to avoid repainting. The default is `true`.
Returns: ( ) A tuple containing the following values:
- The closing OI value for the symbol.
- `true` if the closing OI is above the previous period's value, `false` otherwise.
openInterestCrypto(symbol, timeframe, gaps, repaint)
Requests opening, high, low, and closing open interest (OI) data and OI rising information for a valid cryptocurrency contract on a specified timeframe. Calls to this function count toward a script's `request.*()` call limit.
Parameters:
symbol (series string) : The symbol for which to request open interest data.
timeframe (series string) : The timeframe of the data request. If the timeframe is lower than the chart's timeframe, it causes a runtime error.
gaps (simple bool) : Optional. If `true`, the function returns non-na values only when new values are available from the requested context. If `false`, the function returns the latest retrieved values when new data is unavailable. The default is `false`.
repaint (simple bool) : Optional. If `true` and the `timeframe` represents a higher timeframe, the function returns unconfirmed values from the timeframe on realtime bars, which repaint when the script restarts its executions. If `false`, it returns only confirmed higher-timeframe values to avoid repainting. The default is `true`.
Returns: ( ) A tuple containing the following values:
- The opening, high, low, and closing OI values for the symbol, respectively.
- `true` if the closing OI is above the previous period's value, `false` otherwise.
commitmentOfTraders(metricName, metricDirection, includeOptions, CFTCCode, typeCOT, mode, metricType)
Requests Commitment of Traders (COT) data with specified parameters. This function provides a simplified way to access CFTC COT data available on TradingView. Calls to this function count toward a script's `request.*()` call limit. For more advanced tools and detailed information about COT data, see TradingView's LibraryCOT library.
Parameters:
metricName (series string) : One of the valid metric names listed in the library's documentation and source code.
metricDirection (series string) : Metric direction. Possible values are: "Long", "Short", "Spreading", and "No direction". Consult the library's documentation or code to see which direction values apply to the specified metric.
includeOptions (series bool) : If `true`, the COT symbol includes options information. Otherwise, it does not.
CFTCCode (series string) : Optional. The CFTC code for the asset. For example, wheat futures (root "ZW") have the code "001602". If one is not specified, the function will attempt to get a valid code for the chart symbol's root, base currency, or main currency.
typeCOT (series string) : Optional. The type of report to request. Possible values are: "Legacy", "Disaggregated", "Financial". The default is "Legacy".
mode (series string) : Optional. Specifies the information the function extracts from a symbol. Possible modes are:
- "Root": The function extracts the futures symbol's root prefix information (e.g., "ES" for "ESH2020").
- "Base currency": The function extracts the first currency from a currency pair (e.g., "EUR" for "EURUSD").
- "Currency": The function extracts the currency of the symbol's quoted values (e.g., "JPY" for "TSE:9984" or "USDJPY").
- "Auto": The function tries the first three modes (Root -> Base currency -> Currency) until it finds a match.
The default is "Auto". If the specified mode is not available for the symbol, it causes a runtime error.
metricType (series string) : Optional. The metric type. Possible values are: "All", "Old", "Other". The default is "All".
Returns: (float) The specified Commitment of Traders data series. If no data is available, it causes a runtime error.
LibraryCOT█ OVERVIEW
This library is a Pine programmer's tool that provides functions to access Commitment of Traders (COT) data for futures. Four of our scripts use it:
• Commitment of Traders: Legacy Metrics
• Commitment of Traders: Disaggregated Metrics
• Commitment of Traders: Financial Metrics
• Commitment of Traders: Total
If you do not program in Pine and want to use COT data, please see the indicators linked above.
█ CONCEPTS
Commitment of Traders (COT) data is tallied by the Commodity Futures Trading Commission (CFTC) , a US federal agency that oversees the trading of derivative markets such as futures in the US. It is weekly data that provides traders with information about open interest for an asset. The CFTC oversees derivative markets traded on different exchanges, so COT data is available for assets that can be traded on CBOT, CME, NYMEX, COMEX, and ICEUS.
Accessing COT data from a Pine script requires the generation of a ticker ID string for use with request.security() . The ticker string must be encoded in a special format that includes both CFTC and TradingView-specific content. The format of the ticker IDs is somewhat complex; this library's functions make their generation easier. Note that if you know the COT ticker ID string for specific data, you can enter it from the chart's "Symbol Search" dialog box.
A ticker for COT data in Pine has the following structure:
COT:__<_metricDirection><_metricType>
where an underscore prefixing a component name inside <> is only included if the component is not a null string, and:
Is a digit representing the type of the COT report the data comes from: "" for legacy COT data, "2" for disaggregated data and "3" for financial data.
Is a six digit code that represents a commodity. Example: wheat futures (root "ZW") have the code "001602".
Is either "F" if the report data should exclude Options data, or "FO" if such data is included.
Is the TradingView code of the metric. This library's `metricNameAndDirectionToTicker()` function creates both
the and components of a COT ticker from the metric names and directions listed in the above chart.
The different metrics are explained in the CFTC's Explanatory Notes .
Is the direction of the metric: "Long", "Short", "Spreading" or "No direction".
Not all directions are applicable to all metrics. The valid ones are listed next to each metric in the above chart.
Is the type of the metric, possible values are "All", "Old" and "Other".
The difference between the types is explained in the "Old and Other Futures" section of the CFTC's Explanatory Notes .
As an example, the Legacy report Open Interest data for ZW futures (options included) in the old standard has the ticker "COT:001602_FO_OI_OLD". The same data using the current standard without futures has the ticker "COT:001602_F_OI".
█ USING THE LIBRARY
The first functions in the library are helper functions that generate components of a COT ticker ID. The last function, `COTTickerid()`, is the one that generates the full ticker ID string by calling some of the helper functions. We use it like this in our example:
exampleTicker = COTTickerid(
COTType = "Legacy",
CFTCCode = convertRootToCOTCode("Auto"),
includeOptions = false,
metricName = "Open Interest",
metricDirection = "No direction",
metricType = "All")
This library's chart displays the valid values for the `metricName` and `metricDirection` arguments. They vary for each of the three types of COT data (the `COTType` argument). The chart also displays the COT ticker ID string in the `exampleTicker` variable.
Look first. Then leap.
The library's functions are:
rootToCFTCCode(root)
Accepts a futures root and returns the relevant CFTC code.
Parameters:
root : Root prefix of the future's symbol, e.g. "ZC" for "ZC1!"" or "ZCU2021".
Returns: The part of a COT ticker corresponding to `root`, or "" if no CFTC code exists for the `root`.
currencyToCFTCCode(curr)
Converts a currency string to its corresponding CFTC code.
Parameters:
curr : Currency code, e.g., "USD" for US Dollar.
Returns: The corresponding to the currency, if one exists.
optionsToTicker(includeOptions)
Returns the part of a COT ticker using the `includeOptions` value supplied, which determines whether options data is to be included.
Parameters:
includeOptions : A "bool" value: 'true' if the symbol should include options and 'false' otherwise.
Returns: The part of a COT ticker: "FO" for data that includes options and "F" for data that doesn't.
metricNameAndDirectionToTicker(metricName, metricDirection)
Returns a string corresponding to a metric name and direction, which is one component required to build a valid COT ticker ID.
Parameters:
metricName : One of the metric names listed in this library's chart. Invalid values will cause a runtime error.
metricDirection : Metric direction. Possible values are: "Long", "Short", "Spreading", and "No direction".
Valid values vary with metrics. Invalid values will cause a runtime error.
Returns: The part of a COT ticker ID string, e.g., "OI_OLD" for "Open Interest" and "No direction",
or "TC_L" for "Traders Commercial" and "Long".
typeToTicker(metricType)
Converts a metric type into one component required to build a valid COT ticker ID.
See the "Old and Other Futures" section of the CFTC's Explanatory Notes for details on types.
Parameters:
metricType : Metric type. Accepted values are: "All", "Old", "Other".
Returns: The part of a COT ticker.
convertRootToCOTCode(mode, convertToCOT)
Depending on the `mode`, returns a CFTC code using the chart's symbol or its currency information when `convertToCOT = true`.
Otherwise, returns the symbol's root or currency information. If no COT data exists, a runtime error is generated.
Parameters:
mode : A string determining how the function will work. Valid values are:
"Root": the function extracts the futures symbol root (e.g. "ES" in "ESH2020") and looks for its CFTC code.
"Base currency": the function extracts the first currency in a pair (e.g. "EUR" in "EURUSD") and looks for its CFTC code.
"Currency": the function extracts the quote currency ("JPY" for "TSE:9984" or "USDJPY") and looks for its CFTC code.
"Auto": the function tries the first three modes (Root -> Base Currency -> Currency) until a match is found.
convertToCOT : "bool" value that, when `true`, causes the function to return a CFTC code.
Otherwise, the root or currency information is returned. Optional. The default is `true`.
Returns: If `convertToCOT` is `true`, the part of a COT ticker ID string.
If `convertToCOT` is `false`, the root or currency extracted from the current symbol.
COTTickerid(COTType, CTFCCode, includeOptions, metricName, metricDirection, metricType)
Returns a valid TradingView ticker for the COT symbol with specified parameters.
Parameters:
COTType : A string with the type of the report requested with the ticker, one of the following: "Legacy", "Disaggregated", "Financial".
CTFCCode : The for the asset, e.g., wheat futures (root "ZW") have the code "001602".
includeOptions : A boolean value. 'true' if the symbol should include options and 'false' otherwise.
metricName : One of the metric names listed in this library's chart.
metricDirection : Direction of the metric, one of the following: "Long", "Short", "Spreading", "No direction".
metricType : Type of the metric. Possible values: "All", "Old", and "Other".
Returns: A ticker ID string usable with `request.security()` to fetch the specified Commitment of Traders data.
█ AVAILABLE METRICS
Different COT types provide different metrics. The table of all metrics available for each of the types can be found below.
+------------------------------+------------------------+
| Legacy (COT) Metric Names | Directions |
+------------------------------+------------------------+
| Open Interest | No direction |
| Noncommercial Positions | Long, Short, Spreading |
| Commercial Positions | Long, Short |
| Total Reportable Positions | Long, Short |
| Nonreportable Positions | Long, Short |
| Traders Total | No direction |
| Traders Noncommercial | Long, Short, Spreading |
| Traders Commercial | Long, Short |
| Traders Total Reportable | Long, Short |
| Concentration Gross LT 4 TDR | Long, Short |
| Concentration Gross LT 8 TDR | Long, Short |
| Concentration Net LT 4 TDR | Long, Short |
| Concentration Net LT 8 TDR | Long, Short |
+------------------------------+------------------------+
+-----------------------------------+------------------------+
| Disaggregated (COT2) Metric Names | Directions |
+-----------------------------------+------------------------+
| Open Interest | No Direction |
| Producer Merchant Positions | Long, Short |
| Swap Positions | Long, Short, Spreading |
| Managed Money Positions | Long, Short, Spreading |
| Other Reportable Positions | Long, Short, Spreading |
| Total Reportable Positions | Long, Short |
| Nonreportable Positions | Long, Short |
| Traders Total | No Direction |
| Traders Producer Merchant | Long, Short |
| Traders Swap | Long, Short, Spreading |
| Traders Managed Money | Long, Short, Spreading |
| Traders Other Reportable | Long, Short, Spreading |
| Traders Total Reportable | Long, Short |
| Concentration Gross LE 4 TDR | Long, Short |
| Concentration Gross LE 8 TDR | Long, Short |
| Concentration Net LE 4 TDR | Long, Short |
| Concentration Net LE 8 TDR | Long, Short |
+-----------------------------------+------------------------+
+-------------------------------+------------------------+
| Financial (COT3) Metric Names | Directions |
+-------------------------------+------------------------+
| Open Interest | No Direction |
| Dealer Positions | Long, Short, Spreading |
| Asset Manager Positions | Long, Short, Spreading |
| Leveraged Funds Positions | Long, Short, Spreading |
| Other Reportable Positions | Long, Short, Spreading |
| Total Reportable Positions | Long, Short |
| Nonreportable Positions | Long, Short |
| Traders Total | No Direction |
| Traders Dealer | Long, Short, Spreading |
| Traders Asset Manager | Long, Short, Spreading |
| Traders Leveraged Funds | Long, Short, Spreading |
| Traders Other Reportable | Long, Short, Spreading |
| Traders Total Reportable | Long, Short |
| Concentration Gross LE 4 TDR | Long, Short |
| Concentration Gross LE 8 TDR | Long, Short |
| Concentration Net LE 4 TDR | Long, Short |
| Concentration Net LE 8 TDR | Long, Short |
+-------------------------------+------------------------+
Color█ OVERVIEW
This library is a Pine Script® programming tool for advanced color processing. It provides a comprehensive set of functions for specifying and analyzing colors in various color spaces, mixing and manipulating colors, calculating custom gradients and schemes, detecting contrast, and converting colors to or from hexadecimal strings.
█ CONCEPTS
Color
Color refers to how we interpret light of different wavelengths in the visible spectrum . The colors we see from an object represent the light wavelengths that it reflects, emits, or transmits toward our eyes. Some colors, such as blue and red, correspond directly to parts of the spectrum. Others, such as magenta, arise from a combination of wavelengths to which our minds assign a single color.
The human interpretation of color lends itself to many uses in our world. In the context of financial data analysis, the effective use of color helps transform raw data into insights that users can understand at a glance. For example, colors can categorize series, signal market conditions and sessions, and emphasize patterns or relationships in data.
Color models and spaces
A color model is a general mathematical framework that describes colors using sets of numbers. A color space is an implementation of a specific color model that defines an exact range (gamut) of reproducible colors based on a set of primary colors , a reference white point , and sometimes additional parameters such as viewing conditions.
There are numerous different color spaces — each describing the characteristics of color in unique ways. Different spaces carry different advantages, depending on the application. Below, we provide a brief overview of the concepts underlying the color spaces supported by this library.
RGB
RGB is one of the most well-known color models. It represents color as an additive mixture of three primary colors — red, green, and blue lights — with various intensities. Each cone cell in the human eye responds more strongly to one of the three primaries, and the average person interprets the combination of these lights as a distinct color (e.g., pure red + pure green = yellow).
The sRGB color space is the most common RGB implementation. Developed by HP and Microsoft in the 1990s, sRGB provided a standardized baseline for representing color across CRT monitors of the era, which produced brightness levels that did not increase linearly with the input signal. To match displays and optimize brightness encoding for human sensitivity, sRGB applied a nonlinear transformation to linear RGB signals, often referred to as gamma correction . The result produced more visually pleasing outputs while maintaining a simple encoding. As such, sRGB quickly became a standard for digital color representation across devices and the web. To this day, it remains the default color space for most web-based content.
TradingView charts and Pine Script `color.*` built-ins process color data in sRGB. The red, green, and blue channels range from 0 to 255, where 0 represents no intensity, and 255 represents maximum intensity. Each combination of red, green, and blue values represents a distinct color, resulting in a total of 16,777,216 displayable colors.
CIE XYZ and xyY
The XYZ color space, developed by the International Commission on Illumination (CIE) in 1931, aims to describe all color sensations that a typical human can perceive. It is a cornerstone of color science, forming the basis for many color spaces used today. XYZ, and the derived xyY space, provide a universal representation of color that is not tethered to a particular display. Many widely used color spaces, including sRGB, are defined relative to XYZ or derived from it.
The CIE built the color space based on a series of experiments in which people matched colors they perceived from mixtures of lights. From these experiments, the CIE developed color-matching functions to calculate three components — X, Y, and Z — which together aim to describe a standard observer's response to visible light. X represents a weighted response to light across the color spectrum, with the highest contribution from long wavelengths (e.g., red). Y represents a weighted response to medium wavelengths (e.g., green), and it corresponds to a color's relative luminance (i.e., brightness). Z represents a weighted response to short wavelengths (e.g., blue).
From the XYZ space, the CIE developed the xyY chromaticity space, which separates a color's chromaticity (hue and colorfulness) from luminance. The CIE used this space to define the CIE 1931 chromaticity diagram , which represents the full range of visible colors at a given luminance. In color science and lighting design, xyY is a common means for specifying colors and visualizing the supported ranges of other color spaces.
CIELAB and Oklab
The CIELAB (L*a*b*) color space, derived from XYZ by the CIE in 1976, expresses colors based on opponent process theory. The L* component represents perceived lightness, and the a* and b* components represent the balance between opposing unique colors. The a* value specifies the balance between green and red , and the b* value specifies the balance between blue and yellow .
The primary intention of CIELAB was to provide a perceptually uniform color space, where fixed-size steps through the space correspond to uniform perceived changes in color. Although relatively uniform, the color space has been found to exhibit some non-uniformities, particularly in the blue part of the color spectrum. Regardless, modern applications often use CIELAB to estimate perceived color differences and calculate smooth color gradients.
In 2020, a new LAB-oriented color space, Oklab , was introduced by Björn Ottosson as an attempt to rectify the non-uniformities of other perceptual color spaces. Similar to CIELAB, the L value in Oklab represents perceived lightness, and the a and b values represent the balance between opposing unique colors. Oklab has gained widespread adoption as a perceptual space for color processing, with support in the latest CSS Color specifications and many software applications.
Cylindrical models
A cylindrical-coordinate model transforms an underlying color model, such as RGB or LAB, into an alternative expression of color information that is often more intuitive for the average person to use and understand.
Instead of a mixture of primary colors or opponent pairs, these models represent color as a hue angle on a color wheel , with additional parameters that describe other qualities such as lightness and colorfulness (a general term for concepts like chroma and saturation). In cylindrical-coordinate spaces, users can select a color and modify its lightness or other qualities without altering the hue.
The three most common RGB-based models are HSL (Hue, Saturation, Lightness), HSV (Hue, Saturation, Value), and HWB (Hue, Whiteness, Blackness). All three define hue angles in the same way, but they define colorfulness and lightness differently. Although they are not perceptually uniform, HSL and HSV are commonplace in color pickers and gradients.
For CIELAB and Oklab, the cylindrical-coordinate versions are CIELCh and Oklch , which express color in terms of perceived lightness, chroma, and hue. They offer perceptually uniform alternatives to RGB-based models. These spaces create unique color wheels, and they have more strict definitions of lightness and colorfulness. Oklch is particularly well-suited for generating smooth, perceptual color gradients.
Alpha and transparency
Many color encoding schemes include an alpha channel, representing opacity . Alpha does not help define a color in a color space; it determines how a color interacts with other colors in the display. Opaque colors appear with full intensity on the screen, whereas translucent (semi-opaque) colors blend into the background. Colors with zero opacity are invisible.
In Pine Script, there are two ways to specify a color's alpha:
• Using the `transp` parameter of the built-in `color.*()` functions. The specified value represents transparency (the opposite of opacity), which the functions translate into an alpha value.
• Using eight-digit hexadecimal color codes. The last two digits in the code represent alpha directly.
A process called alpha compositing simulates translucent colors in a display. It creates a single displayed color by mixing the RGB channels of two colors (foreground and background) based on alpha values, giving the illusion of a semi-opaque color placed over another color. For example, a red color with 80% transparency on a black background produces a dark shade of red.
Hexadecimal color codes
A hexadecimal color code (hex code) is a compact representation of an RGB color. It encodes a color's red, green, and blue values into a sequence of hexadecimal ( base-16 ) digits. The digits are numerals ranging from `0` to `9` or letters from `a` (for 10) to `f` (for 15). Each set of two digits represents an RGB channel ranging from `00` (for 0) to `ff` (for 255).
Pine scripts can natively define colors using hex codes in the format `#rrggbbaa`. The first set of two digits represents red, the second represents green, and the third represents blue. The fourth set represents alpha . If unspecified, the value is `ff` (fully opaque). For example, `#ff8b00` and `#ff8b00ff` represent an opaque orange color. The code `#ff8b0033` represents the same color with 80% transparency.
Gradients
A color gradient maps colors to numbers over a given range. Most color gradients represent a continuous path in a specific color space, where each number corresponds to a mix between a starting color and a stopping color. In Pine, coders often use gradients to visualize value intensities in plots and heatmaps, or to add visual depth to fills.
The behavior of a color gradient depends on the mixing method and the chosen color space. Gradients in sRGB usually mix along a straight line between the red, green, and blue coordinates of two colors. In cylindrical spaces such as HSL, a gradient often rotates the hue angle through the color wheel, resulting in more pronounced color transitions.
Color schemes
A color scheme refers to a set of colors for use in aesthetic or functional design. A color scheme usually consists of just a few distinct colors. However, depending on the purpose, a scheme can include many colors.
A user might choose palettes for a color scheme arbitrarily, or generate them algorithmically. There are many techniques for calculating color schemes. A few simple, practical methods are:
• Sampling a set of distinct colors from a color gradient.
• Generating monochromatic variants of a color (i.e., tints, tones, or shades with matching hues).
• Computing color harmonies — such as complements, analogous colors, triads, and tetrads — from a base color.
This library includes functions for all three of these techniques. See below for details.
█ CALCULATIONS AND USE
Hex string conversion
The `getHexString()` function returns a string containing the eight-digit hexadecimal code corresponding to a "color" value or set of sRGB and transparency values. For example, `getHexString(255, 0, 0)` returns the string `"#ff0000ff"`, and `getHexString(color.new(color.red, 80))` returns `"#f2364533"`.
The `hexStringToColor()` function returns the "color" value represented by a string containing a six- or eight-digit hex code. The `hexStringToRGB()` function returns a tuple containing the sRGB and transparency values. For example, `hexStringToColor("#f23645")` returns the same value as color.red .
Programmers can use these functions to parse colors from "string" inputs, perform string-based color calculations, and inspect color data in text outputs such as Pine Logs and tables.
Color space conversion
All other `get*()` functions convert a "color" value or set of sRGB channels into coordinates in a specific color space, with transparency information included. For example, the tuple returned by `getHSL()` includes the color's hue, saturation, lightness, and transparency values.
To convert data from a color space back to colors or sRGB and transparency values, use the corresponding `*toColor()` or `*toRGB()` functions for that space (e.g., `hslToColor()` and `hslToRGB()`).
Programmers can use these conversion functions to process inputs that define colors in different ways, perform advanced color manipulation, design custom gradients, and more.
The color spaces this library supports are:
• sRGB
• Linear RGB (RGB without gamma correction)
• HSL, HSV, and HWB
• CIE XYZ and xyY
• CIELAB and CIELCh
• Oklab and Oklch
Contrast-based calculations
Contrast refers to the difference in luminance or color that makes one color visible against another. This library features two functions for calculating luminance-based contrast and detecting themes.
The `contrastRatio()` function calculates the contrast between two "color" values based on their relative luminance (the Y value from CIE XYZ) using the formula from version 2 of the Web Content Accessibility Guidelines (WCAG) . This function is useful for identifying colors that provide a sufficient brightness difference for legibility.
The `isLightTheme()` function determines whether a specified background color represents a light theme based on its contrast with black and white. Programmers can use this function to define conditional logic that responds differently to light and dark themes.
Color manipulation and harmonies
The `negative()` function calculates the negative (i.e., inverse) of a color by reversing the color's coordinates in either the sRGB or linear RGB color space. This function is useful for calculating high-contrast colors.
The `grayscale()` function calculates a grayscale form of a specified color with the same relative luminance.
The functions `complement()`, `splitComplements()`, `analogousColors()`, `triadicColors()`, `tetradicColors()`, `pentadicColors()`, and `hexadicColors()` calculate color harmonies from a specified source color within a given color space (HSL, CIELCh, or Oklch). The returned harmonious colors represent specific hue rotations around a color wheel formed by the chosen space, with the same defined lightness, saturation or chroma, and transparency.
Color mixing and gradient creation
The `add()` function simulates combining lights of two different colors by additively mixing their linear red, green, and blue components, ignoring transparency by default. Users can calculate a transparency-weighted mixture by setting the `transpWeight` argument to `true`.
The `overlay()` function estimates the color displayed on a TradingView chart when a specific foreground color is over a background color. This function aids in simulating stacked colors and analyzing the effects of transparency.
The `fromGradient()` and `fromMultiStepGradient()` functions calculate colors from gradients in any of the supported color spaces, providing flexible alternatives to the RGB-based color.from_gradient() function. The `fromGradient()` function calculates a color from a single gradient. The `fromMultiStepGradient()` function calculates a color from a piecewise gradient with multiple defined steps. Gradients are useful for heatmaps and for coloring plots or drawings based on value intensities.
Scheme creation
Three functions in this library calculate palettes for custom color schemes. Scripts can use these functions to create responsive color schemes that adjust to calculated values and user inputs.
The `gradientPalette()` function creates an array of colors by sampling a specified number of colors along a gradient from a base color to a target color, in fixed-size steps.
The `monoPalette()` function creates an array containing monochromatic variants (tints, tones, or shades) of a specified base color. Whether the function mixes the color toward white (for tints), a form of gray (for tones), or black (for shades) depends on the `grayLuminance` value. If unspecified, the function automatically chooses the mix behavior with the highest contrast.
The `harmonyPalette()` function creates a matrix of colors. The first column contains the base color and specified harmonies, e.g., triadic colors. The columns that follow contain tints, tones, or shades of the harmonic colors for additional color choices, similar to `monoPalette()`.
█ EXAMPLE CODE
The example code at the end of the script generates and visualizes color schemes by processing user inputs. The code builds the scheme's palette based on the "Base color" input and the additional inputs in the "Settings/Inputs" tab:
• "Palette type" specifies whether the palette uses a custom gradient, monochromatic base color variants, or color harmonies with monochromatic variants.
• "Target color" sets the top color for the "Gradient" palette type.
• The "Gray luminance" inputs determine variation behavior for "Monochromatic" and "Harmony" palette types. If "Auto" is selected, the palette mixes the base color toward white or black based on its brightness. Otherwise, it mixes the color toward the grayscale color with the specified relative luminance (from 0 to 1).
• "Harmony type" specifies the color harmony used in the palette. Each row in the palette corresponds to one of the harmonious colors, starting with the base color.
The code creates a table on the first bar to display the collection of calculated colors. Each cell in the table shows the color's `getHexString()` value in a tooltip for simple inspection.
Look first. Then leap.
█ EXPORTED FUNCTIONS
Below is a complete list of the functions and overloads exported by this library.
getRGB(source)
Retrieves the sRGB red, green, blue, and transparency components of a "color" value.
getHexString(r, g, b, t)
(Overload 1 of 2) Converts a set of sRGB channel values to a string representing the corresponding color's hexadecimal form.
getHexString(source)
(Overload 2 of 2) Converts a "color" value to a string representing the sRGB color's hexadecimal form.
hexStringToRGB(source)
Converts a string representing an sRGB color's hexadecimal form to a set of decimal channel values.
hexStringToColor(source)
Converts a string representing an sRGB color's hexadecimal form to a "color" value.
getLRGB(r, g, b, t)
(Overload 1 of 2) Converts a set of sRGB channel values to a set of linear RGB values with specified transparency information.
getLRGB(source)
(Overload 2 of 2) Retrieves linear RGB channel values and transparency information from a "color" value.
lrgbToRGB(lr, lg, lb, t)
Converts a set of linear RGB channel values to a set of sRGB values with specified transparency information.
lrgbToColor(lr, lg, lb, t)
Converts a set of linear RGB channel values and transparency information to a "color" value.
getHSL(r, g, b, t)
(Overload 1 of 2) Converts a set of sRGB channels to a set of HSL values with specified transparency information.
getHSL(source)
(Overload 2 of 2) Retrieves HSL channel values and transparency information from a "color" value.
hslToRGB(h, s, l, t)
Converts a set of HSL channel values to a set of sRGB values with specified transparency information.
hslToColor(h, s, l, t)
Converts a set of HSL channel values and transparency information to a "color" value.
getHSV(r, g, b, t)
(Overload 1 of 2) Converts a set of sRGB channels to a set of HSV values with specified transparency information.
getHSV(source)
(Overload 2 of 2) Retrieves HSV channel values and transparency information from a "color" value.
hsvToRGB(h, s, v, t)
Converts a set of HSV channel values to a set of sRGB values with specified transparency information.
hsvToColor(h, s, v, t)
Converts a set of HSV channel values and transparency information to a "color" value.
getHWB(r, g, b, t)
(Overload 1 of 2) Converts a set of sRGB channels to a set of HWB values with specified transparency information.
getHWB(source)
(Overload 2 of 2) Retrieves HWB channel values and transparency information from a "color" value.
hwbToRGB(h, w, b, t)
Converts a set of HWB channel values to a set of sRGB values with specified transparency information.
hwbToColor(h, w, b, t)
Converts a set of HWB channel values and transparency information to a "color" value.
getXYZ(r, g, b, t)
(Overload 1 of 2) Converts a set of sRGB channels to a set of XYZ values with specified transparency information.
getXYZ(source)
(Overload 2 of 2) Retrieves XYZ channel values and transparency information from a "color" value.
xyzToRGB(x, y, z, t)
Converts a set of XYZ channel values to a set of sRGB values with specified transparency information
xyzToColor(x, y, z, t)
Converts a set of XYZ channel values and transparency information to a "color" value.
getXYY(r, g, b, t)
(Overload 1 of 2) Converts a set of sRGB channels to a set of xyY values with specified transparency information.
getXYY(source)
(Overload 2 of 2) Retrieves xyY channel values and transparency information from a "color" value.
xyyToRGB(xc, yc, y, t)
Converts a set of xyY channel values to a set of sRGB values with specified transparency information.
xyyToColor(xc, yc, y, t)
Converts a set of xyY channel values and transparency information to a "color" value.
getLAB(r, g, b, t)
(Overload 1 of 2) Converts a set of sRGB channels to a set of CIELAB values with specified transparency information.
getLAB(source)
(Overload 2 of 2) Retrieves CIELAB channel values and transparency information from a "color" value.
labToRGB(l, a, b, t)
Converts a set of CIELAB channel values to a set of sRGB values with specified transparency information.
labToColor(l, a, b, t)
Converts a set of CIELAB channel values and transparency information to a "color" value.
getOKLAB(r, g, b, t)
(Overload 1 of 2) Converts a set of sRGB channels to a set of Oklab values with specified transparency information.
getOKLAB(source)
(Overload 2 of 2) Retrieves Oklab channel values and transparency information from a "color" value.
oklabToRGB(l, a, b, t)
Converts a set of Oklab channel values to a set of sRGB values with specified transparency information.
oklabToColor(l, a, b, t)
Converts a set of Oklab channel values and transparency information to a "color" value.
getLCH(r, g, b, t)
(Overload 1 of 2) Converts a set of sRGB channels to a set of CIELCh values with specified transparency information.
getLCH(source)
(Overload 2 of 2) Retrieves CIELCh channel values and transparency information from a "color" value.
lchToRGB(l, c, h, t)
Converts a set of CIELCh channel values to a set of sRGB values with specified transparency information.
lchToColor(l, c, h, t)
Converts a set of CIELCh channel values and transparency information to a "color" value.
getOKLCH(r, g, b, t)
(Overload 1 of 2) Converts a set of sRGB channels to a set of Oklch values with specified transparency information.
getOKLCH(source)
(Overload 2 of 2) Retrieves Oklch channel values and transparency information from a "color" value.
oklchToRGB(l, c, h, t)
Converts a set of Oklch channel values to a set of sRGB values with specified transparency information.
oklchToColor(l, c, h, t)
Converts a set of Oklch channel values and transparency information to a "color" value.
contrastRatio(value1, value2)
Calculates the contrast ratio between two colors values based on the formula from version 2 of the Web Content Accessibility Guidelines (WCAG).
isLightTheme(source)
Detects whether a background color represents a light theme or dark theme, based on the amount of contrast between the color and the white and black points.
grayscale(source)
Calculates the grayscale version of a color with the same relative luminance (i.e., brightness).
negative(source, colorSpace)
Calculates the negative (i.e., inverted) form of a specified color.
complement(source, colorSpace)
Calculates the complementary color for a `source` color using a cylindrical color space.
analogousColors(source, colorSpace)
Calculates the analogous colors for a `source` color using a cylindrical color space.
splitComplements(source, colorSpace)
Calculates the split-complementary colors for a `source` color using a cylindrical color space.
triadicColors(source, colorSpace)
Calculates the two triadic colors for a `source` color using a cylindrical color space.
tetradicColors(source, colorSpace, square)
Calculates the three square or rectangular tetradic colors for a `source` color using a cylindrical color space.
pentadicColors(source, colorSpace)
Calculates the four pentadic colors for a `source` color using a cylindrical color space.
hexadicColors(source, colorSpace)
Calculates the five hexadic colors for a `source` color using a cylindrical color space.
add(value1, value2, transpWeight)
Additively mixes two "color" values, with optional transparency weighting.
overlay(fg, bg)
Estimates the resulting color that appears on the chart when placing one color over another.
fromGradient(value, bottomValue, topValue, bottomColor, topColor, colorSpace)
Calculates the gradient color that corresponds to a specific value based on a defined value range and color space.
fromMultiStepGradient(value, steps, colors, colorSpace)
Calculates a multi-step gradient color that corresponds to a specific value based on an array of step points, an array of corresponding colors, and a color space.
gradientPalette(baseColor, stopColor, steps, strength, model)
Generates a palette from a gradient between two base colors.
monoPalette(baseColor, grayLuminance, variations, strength, colorSpace)
Generates a monochromatic palette from a specified base color.
harmonyPalette(baseColor, harmonyType, grayLuminance, variations, strength, colorSpace)
Generates a palette consisting of harmonious base colors and their monochromatic variants.
Forex Heatmap█ OVERVIEW
This indicator creates a dynamic grid display of currency pair cross rates (exchange rates) and percentage changes, emulating the Cross Rates and Heat Map widgets available on our Forex page. It provides a view of realtime exchange rates for all possible pairs derived from a user-specified list of currencies, allowing users to monitor the relative performance of several currencies directly on a TradingView chart.
█ CONCEPTS
Foreign exchange
The Foreign Exchange (Forex/FX) market is the largest, most liquid financial market globally, with an average daily trading volume of over 5 trillion USD. Open 24 hours a day, five days a week, it operates through a decentralized network of financial hubs in various major cities worldwide. In this market, participants trade currencies in pairs , where the listed price of a currency pair represents the exchange rate from a given base currency to a specific quote currency . For example, the "EURUSD" pair's price represents the amount of USD (quote currency) that equals one unit of EUR (base currency). Globally, the most traded currencies include the U.S. dollar (USD), Euro (EUR), Japanese yen (JPY), British pound (GBP), and Australian dollar (AUD), with USD involved in over 87% of all trades.
Understanding the Forex market is essential for traders and investors, even those who do not trade currency pairs directly, because exchange rates profoundly affect global markets. For instance, fluctuations in the value of USD can impact the demand for U.S. exports or the earnings of companies that handle multinational transactions, either of which can affect the prices of stocks, indices, and commodities. Additionally, since many factors influence exchange rates, including economic policies and interest rate changes, analyzing the exchange rates across currencies can provide insight into global economic health.
█ FEATURES
Requesting a list of currencies
This indicator requests data for every valid currency pair combination from the list of currencies defined by the "Currency list" input in the "Settings/Inputs" tab. The list can contain up to six unique currency codes separated by commas, resulting in a maximum of 30 requested currency pairs.
For example, if the specified "Currency list" input is "CAD, USD, EUR", the indicator requests and displays relevant data for six currency pair combinations: "CADUSD", "USDCAD", "CADEUR", "EURCAD", "USDEUR", "EURUSD". See the "Grid display" section below to understand how the script organizes the requested information.
Each item in the comma-separated list must represent a valid currency code. If the "Currency list" input contains an invalid currency code, the corresponding cells for that currency in the "Cross rates" or "Heat map" grid show "NaN" values. If the list contains empty items, e.g., "CAD, ,EUR, ", the indicator ignores them in its data requests and calculations.
NOTE: Some uncommon currency pair combinations might not have data feeds available. If no available symbols provide the exchange rates between two specified currencies, the corresponding table cells show "NaN" results.
Realtime data
The indicator retrieves realtime market prices, daily price changes, and minimum tick sizes for all the currency pairs derived from the "Currency list" input. It updates the retrieved information shown in its grid display after new ticks become available to reflect the latest known values.
NOTE: Pine scripts execute on realtime bars only when new ticks are available in the chart's data feed. If no new updates are available from the chart's realtime feed, it may cause a delay in the data the indicator receives.
Grid display
This indicator displays the requested data for each currency pair in a table with cells organized as a grid. Each row name corresponds to a pair's base currency , and each column name corresponds to a quote currency . The cell at the intersection of a specific row and column shows the value requested from the corresponding currency pair.
For example, the cell at the intersection of a "EUR" row and "USD" column shows the data retrieved for the "EURUSD" currency pair, and the cell at the "USD" row and "EUR" column shows data for the inverse pair ("USDEUR").
Note that the main diagonal cells in the table, where rows and columns with the same names intersect, are blank. The exchange rate from one currency to itself is always 1, and no Forex symbols such as "EUREUR" exist.
The dropdown input at the top of the "Settings/Inputs" tab determines the type of information displayed in the table. Two options are available: "Cross rates" and "Heat map" . Both modes color their cells for light and dark themes separately based on the inputs in the "Colors" section.
Cross rates
When a user selects the "Cross rates" display mode, the table's cells show the latest available exchange rate for each currency pair, emulating the behavior of the Cross Rates widget. Each cell's value represents the amount of the quote currency (column name) that equals one unit of the base currency (row name). This display allows users to compare cross rates across currency pairs, and their inverses.
The background color of each cell changes based on the most recent update to the exchange rate, allowing users to monitor the direction of short-term fluctuations as they occur. By default, the background turns green (positive cell color) when the cross rate increases from the last recorded update and red (negative cell color) when the rate decreases. The cell's color reverts to the chart's background color after no new updates are available for 200 milliseconds.
Heat map
When a user selects the "Heat map" display mode, the table's cells show the latest daily percentage change of each currency pair, emulating the behavior of the Heat Map widget.
In this mode, the background color of each cell depends on the corresponding currency pair's daily performance. Heat maps typically use colors that vary in intensity based on the calculated values. This indicator uses the following color coding by default:
• Green (Positive cell color): Percentage change > +0.1%
• No color: Percentage change between 0.0% and +0.1%
• Bright red (Negative cell color): Percentage change < -0.1%
• Lighter/darker red (Minor negative cell color): Percentage change between 0.0% and -0.1%
█ FOR Pine Script™ CODERS
• This script utilizes dynamic requests to iteratively fetch information from multiple contexts using a single request.security() instance in the code. Previously, `request.*()` functions were not allowed within the local scopes of loops or conditional structures, and most `request.*()` function parameters, excluding `expression`, required arguments of a simple or weaker qualified type. The new `dynamic_requests` parameter in script declaration statements enables more flexibility in how scripts can use `request.*()` calls. When its value is `true`, all `request.*()` functions can accept series arguments for the parameters that define their requested contexts, and `request.*()` functions can execute within local scopes. See the Dynamic requests section of the Pine Script™ User Manual to learn more.
• Scripts can execute up to 40 unique `request.*()` function calls. A `request.*()` call is unique only if the script does not already call the same function with the same arguments. See this section of the User Manual's Limitations page for more information.
• Typically, when requesting higher-timeframe data with request.security() using barmerge.lookahead_on as the `lookahead` argument, the `expression` argument should use the history-referencing operator to offset the series, preventing lookahead bias on historical bars. However, the request.security() call in this script uses barmerge.lookahead_on without offsetting the `expression` because the script only displays results for the latest historical bar and all realtime bars, where there is no future information to leak into the past. Instead, using this call on those bars ensures each request fetches the most recent data available from each context.
• The request.security() instance in this script includes a `calc_bars_count` argument to specify that each request retrieves only a minimal number of bars from the end of each symbol's historical data feed. The script does not need to request all the historical data for each symbol because it only shows results on the last chart bar that do not depend on the entire time series. In this case, reducing the retrieved bars in each request helps minimize resource usage without impacting the calculated results.
Look first. Then leap.
Sharpe and Sortino Ratios█ OVERVIEW
This indicator calculates the Sharpe and Sortino ratios using a chart symbol's periodic price returns, offering insights into the symbol's risk-adjusted performance. It features the option to calculate these ratios by comparing the periodic returns to a fixed annual rate of return or the returns from another selected symbol's context.
█ CONCEPTS
Returns, risk, and volatility
The return on an investment is the relative gain or loss over a period, often expressed as a percentage. Investment returns can originate from several sources, including capital gains, dividends, and interest income. Many investors seek the highest returns possible in the quest for profit. However, prudent investing and trading entails evaluating such returns against the associated risks (i.e., the uncertainty of returns and the potential for financial losses) for a clearer perspective on overall performance and sustainability.
The profitability of an investment typically comes at the cost of enduring market swings, noise, and general uncertainty. To navigate these turbulent waters, investors and portfolio managers often utilize volatility , a measure of the statistical dispersion of historical returns, as a foundational element in their risk assessments because it provides a tangible way to gauge the uncertainty in returns. High volatility suggests increased uncertainty and, consequently, higher risk, whereas low volatility suggests more stable returns with minimal fluctuations, implying lower risk. These concepts are integral components in several risk-adjusted performance metrics, including the Sharpe and Sortino ratios calculated by this indicator.
Risk-free rate
The risk-free rate represents the rate of return on a hypothetical investment carrying no risk of financial loss. This theoretical rate provides a benchmark for comparing the returns on a risky investment and evaluating whether its excess returns justify the risks. If an investment's returns are at or below the theoretical risk-free rate or the risk premium is below a desired amount, it may suggest that the returns do not compensate for the extra risk, which might be a call to reassess the investment.
Since the risk-free rate is a theoretical concept, investors often utilize proxies for the rate in practice, such as Treasury bills and other government bonds. Conventionally, analysts consider such instruments "risk-free" for a domestic holder, as they are a form of government obligation with a low perceived likelihood of default.
The average yield on short-term Treasury bills, influenced by economic conditions, monetary policies, and inflation expectations, has historically hovered around 2-3% over the long term. This range also aligns with central banks' inflation targets. As such, one may interpret a value within this range as a minimum proxy for the risk-free rate, as it may correspond to the minimum rate required to maintain purchasing power over time. This indicator uses a default value of 2% as the risk-free rate in its Sharpe and Sortino ratio calculations. Users can adjust this value from the "Risk-free rate of return" input in the "Settings/Inputs" tab.
Sharpe and Sortino ratios
The Sharpe and Sortino ratios are two of the most widely used metrics that offer insight into an investment's risk-adjusted performance . They provide a standardized framework to compare the effectiveness of investments relative to their perceived risks. These metrics can help investors determine whether the returns justify the risks taken to achieve them, promoting more informed investment decisions.
Both metrics measure risk-adjusted performance similarly. However, they have some differences in their formulas and their interpretation:
1. Sharpe ratio
The Sharpe ratio , developed by Nobel laureate William F. Sharpe, measures the performance of an investment compared to a theoretically risk-free asset, adjusted for the investment risk. The ratio uses the following formula:
Sharpe Ratio = (𝑅𝑎 − 𝑅𝑓) / 𝜎𝑎
Where:
• 𝑅𝑎 = Average return of the investment
• 𝑅𝑓 = Theoretical risk-free rate of return
• 𝜎𝑎 = Standard deviation of the investment's returns (volatility)
A higher Sharpe ratio indicates a more favorable risk-adjusted return, as it signifies that the investment produced higher excess returns per unit of increase in total perceived risk.
2. Sortino ratio
The Sortino ratio is a modified form of the Sharpe ratio that only considers downside volatility , i.e., the volatility of returns below the theoretical risk-free benchmark. Although it shares close similarities with the Sharpe ratio, it can produce very different values, especially when the returns do not have a symmetrical distribution, since it does not penalize upside and downside volatility equally. The ratio uses the following formula:
Sortino Ratio = (𝑅𝑎 − 𝑅𝑓) / 𝜎𝑑
Where:
• 𝑅𝑎 = Average return of the investment
• 𝑅𝑓 = Theoretical risk-free rate of return
• 𝜎𝑑 = Downside deviation (standard deviation of negative excess returns, or downside volatility)
The Sortino ratio offers an alternative perspective on an investment's return-generating efficiency since it does not consider upside volatility in its calculation. A higher Sortino ratio signifies that the investment produced higher excess returns per unit of increase in perceived downside risk.
The risk-free rate (𝑅𝑓) in the numerator of both ratio formulas acts as a baseline for comparing an investment's performance to a theoretical risk-free alternative. By subtracting the risk-free rate from the expected return (𝑅𝑎−𝑅𝑓), the numerator essentially represents the risk premium of the investment.
Comparison with another symbol
In addition to the conventional Sharpe and Sortino ratios, which compare an instrument's returns to a risk-free rate, this indicator can also compare returns to a user-specified benchmark symbol , allowing the calculation of Information ratios .
An Information ratio is a generalized form of the Sharpe ratio that compares an investment's returns to a risky benchmark , such as SPY, rather than a risk-free rate. It measures the investment's active return (the difference between its returns and the benchmark returns) relative to its tracking error (i.e., the volatility of the active return) using the following formula:
𝐼𝑅 = (𝑅𝑝 − 𝑅𝑏) / 𝑇𝐸
Where:
• 𝑅𝑝 = Average return on the portfolio or investment
• 𝑅𝑏 = Average return from the benchmark instrument
• 𝑇𝐸 = Tracking error (volatility of 𝑅𝑝 − 𝑅𝑏)
Comparing returns to a benchmark instrument rather than a theoretical risk-free rate offers unique insights into risk-adjusted performance. Higher Information ratios signify that the investment produced higher active returns per unit of increase in risk relative to the benchmark. Conventional choices for non-risk-free benchmarks include major composite indices like the S&P 500 and DJIA, as the resulting ratios can provide insight into the effectiveness of an investment relative to the broader market.
Users can enable this generalized calculation for both the Sharpe and Sortino ratios by selecting the "Benchmark symbol returns" option from the "Benchmark type" dropdown in the "Settings/Inputs" tab.
It's crucial to note that this indicator compares the charts symbol's rate of change (return) to the rate of change in the benchmark symbol. Consequently, not all symbols available on TradingView are suitable for use with these ratios due to the nature of what their values represent. For instance, using a bond as a benchmark will produce distorted results since each bar's values represent yields rather than prices, meaning it compares the rate of change in the yield. To maintain consistency and relevance in the calculated ratios, ensure the values from the compared symbols strictly represent price information.
█ FEATURES
This indicator provides traders with two widely used metrics for assessing risk-adjusted performance, generalized to allow users to compare the chart symbol's price returns to a fixed risk-free rate or the returns from another risky symbol. Below are the key features of this indicator:
Timeframe selection
The "Returns timeframe" input determines the timeframe of the calculated price returns. Users can select any value greater than or equal to the chart's timeframe. The default timeframe is "1M".
Periodic returns tracking
This indicator compounds and collects requested price returns from the selected timeframe over monthly or daily periods, similar to how the Broker Emulator works when calculating strategy performance metrics on trade data. It employs the following logic:
• Track returns over monthly periods if the chart's data spans at least two months.
• Track returns over daily periods if the chart's data spans at least two days but not two months.
• Do not track or collect returns if the data spans less than two days, as the amount of data is insufficient for meaningful ratio calculations.
The indicator uses the returns collected from up to a specified number of periods to calculate the Sharpe and Sortino ratios, depending on the available historical data. It also uses these periodic returns to calculate the average returns it displays in the Data Window.
Users can control the maximum number of periods the indicator analyzes with the "Max no. of periods used" input in the "Settings/Inputs" tab. The default value is 60 periods.
Benchmark specification
The "Benchmark return type" input specifies the benchmark type the indicator compares to the chart symbol's returns in the ratio calculations. It features the following two options:
• "Risk-free rate of return (%)": Compares the price returns to a user-specified annual rate of return representing a theoretical risk-free rate (e.g., 2%).
• "Benchmark symbol return": Compares the price returns to a selected benchmark symbol (e.g., "AMEX:SPY) to calculate Information ratios.
When comparing a chart symbol's returns to a specified benchmark symbol, this indicator aligns the times of data points from the benchmark with the times of data points from the chart's symbol to facilitate a fair comparison between symbols with different active sessions.
Visualization and display
• The indicator displays the periodic returns requested from the specified "Returns timeframe" in a separate pane. The plot includes dynamic colors to signify positive and negative returns.
• When the "Returns timeframe" value represents a higher timeframe, the indicator displays background highlights on the main chart pane to signify when a new value is available and whether the return is positive or negative.
• When the specified benchmark return type is a benchmark symbol, the indicator displays the requested symbol's returns in the separate pane as a gray line for visual comparison.
• Within the separate pane, the indicator displays a single-cell table that shows the base period it uses for periodic returns, the number of periods it uses in the calculation, the timeframe of the requested data, and the calculated Sharpe and Sortino ratios.
• The Data Window displays the chart symbol and benchmark returns, their periodic averages, and the Sharpe and Sortino ratios.
█ FOR Pine Script™ CODERS
• This script utilizes the functions from our RiskMetrics library to determine the size of the periods, calculate and collect periodic returns, and compute the Sharpe and Sortino ratios.
• The `getAlignedPrices()` function in this script requests price data for the chart's symbol and a benchmark symbol with consistent time alignment by utilizing spread symbols , which helps facilitate a fair comparison between different symbol types. Retrieving prices from spreads avoids potential information loss and data misalignment that can otherwise occur when using separate requests from each symbol's context when those symbols have different sessions or data times.
• For consistency, the `getAlignedPrices()` function includes extended hours and dividend adjustment modifiers in its data requests. Additionally, it includes other settings inherited from the chart's context, such as "settlement-as-close" preferences for fair comparison between futures instruments.
• This script uses the `changePercent()` function from our ta library to calculate the percentage changes of the requested data.
• The newly released `force_overlay` parameter in display-related functions allows indicators to display visuals on the main chart and a separate pane simultaneously. We use the parameter in this script's bgcolor() call to display background highlights on the main chart.
Look first. Then leap.
RelativeValue█ OVERVIEW
This library is a Pine Script™ programmer's tool offering the ability to compute relative values, which represent comparisons of current data points, such as volume, price, or custom indicators, with their analogous historical data points from corresponding time offsets. This approach can provide insightful perspectives into the intricate dynamics of relative market behavior over time.
█ CONCEPTS
Relative values
In this library, a relative value is a metric that compares a current data point in a time interval to an average of data points with corresponding time offsets across historical periods. Its purpose is to assess the significance of a value by considering the historical context within past time intervals.
For instance, suppose we wanted to calculate relative volume on an hourly chart over five daily periods, and the last chart bar is two hours into the current trading day. In this case, we would compare the current volume to the average of volume in the second hour of trading across five days. We obtain the relative volume value by dividing the current volume by this average.
This form of analysis rests on the hypothesis that substantial discrepancies or aberrations in present market activity relative to historical time intervals might help indicate upcoming changes in market trends.
Cumulative and non-cumulative values
In the context of this library, a cumulative value refers to the cumulative sum of a series since the last occurrence of a specific condition (referred to as `anchor` in the function definitions). Given that relative values depend on time, we use time-based conditions such as the onset of a new hour, day, etc. On the other hand, a non-cumulative value is simply the series value at a specific time without accumulation.
Calculating relative values
Four main functions coordinate together to compute the relative values: `maintainArray()`, `calcAverageByTime()`, `calcCumulativeSeries()`, and `averageAtTime()`. These functions are underpinned by a `collectedData` user-defined type (UDT), which stores data collected since the last reset of the timeframe along with their corresponding timestamps. The relative values are calculated using the following procedure:
1. The `averageAtTime()` function invokes the process leveraging all four of the methods and acts as the main driver of the calculations. For each bar, this function adds the current bar's source and corresponding time value to a `collectedData` object.
2. Within the `averageAtTime()` function, the `maintainArray()` function is called at the start of each anchor period. It adds a new `collectedData` object to the array and ensures the array size does not exceed the predefined `maxSize` by removing the oldest element when necessary. This method plays an essential role in limiting memory usage and ensuring only relevant data over the desired number of periods is in the calculation window.
3. Next, the `calcAverageByTime()` function calculates the average value of elements within the `data` field for each `collectedData` object that corresponds to the same time offset from each anchor condition. This method accounts for cases where the current index of a `collectedData` object exceeds the last index of any past objects by using the last available values instead.
4. For cumulative calculations, the `averageAtTime()` function utilizes the `isCumulative` boolean parameter. If true, the `calcCumulativeSeries()` function will track the running total of the source data from the last bar where the anchor condition was met, providing a cumulative sum of the source values from one anchor point to the next.
To summarize, the `averageAtTime()` function continually stores values with their corresponding times in a `collectedData` object for each bar in the anchor period. When the anchor resets, this object is added to a larger array. The array's size is limited by the specified number of periods to be averaged. To correlate data across these periods, time indexing is employed, enabling the function to compare corresponding points across multiple periods.
█ USING THIS LIBRARY
The library simplifies the complex process of calculating relative values through its intuitive functions. Follow the steps below to use this library in your scripts.
Step 1: Import the library and declare inputs
Import the library and declare variables based on the user's input. These can include the timeframe for each period, the number of time intervals to include in the average, and whether the calculation uses cumulative values. For example:
//@version=5
import TradingView/RelativeValue/1 as TVrv
indicator("Relative Range Demo")
string resetTimeInput = input.timeframe("D")
int lengthInput = input.int(5, "No. of periods")
Step 2: Define the anchor condition
With these inputs declared, create a condition to define the start of a new period (anchor). For this, we use the change in the time value from the input timeframe:
bool anchor = timeframe.change(resetTimeInput)
Step 3: Calculate the average
At this point, one can calculate the average of a value's history at the time offset from the anchor over a number of periods using the `averageAtTime()` function. In this example, we use True Range (TR) as the `source` and set `isCumulative` to false:
float pastRange = TVrv.averageAtTime(ta.tr, lengthInput, anchor, false)
Step 4: Display the data
You can visualize the results by plotting the returned series. These lines display the non-cumulative TR alongside the average value over `lengthInput` periods for relative comparison:
plot(pastRange, "Past True Range Avg", color.new(chart.bg_color, 70), 1, plot.style_columns)
plot(ta.tr, "True Range", close >= open ? color.new(color.teal, 50) : color.new(color.red, 50), 1, plot.style_columns)
This example will display two overlapping series of columns. The green and red columns depict the current TR on each bar, and the light gray columns show the average over a defined number of periods, e.g., the default inputs on an hourly chart will show the average value at the hour over the past five days. This comparative analysis aids in determining whether the range of a bar aligns with its typical historical values or if it's an outlier.
█ NOTES
• The foundational concept of this library was derived from our initial Relative Volume at Time script. This library's logic significantly boosts its performance. Keep an eye out for a forthcoming updated version of the indicator. The demonstration code included in the library emulates a streamlined version of the indicator utilizing the library functions.
• Key efficiencies in the data management are realized through array.binary_search_leftmost() , which offers a performance improvement in comparison to its loop-dependent counterpart.
• This library's architecture utilizes user-defined types (UDTs) to create custom objects which are the equivalent of variables containing multiple parts, each able to hold independent values of different types . The recently added feature was announced in this blog post.
• To enhance readability, the code substitutes array functions with equivalent methods .
Look first. Then leap.
█ FUNCTIONS
This library contains the following functions:
calcCumulativeSeries(source, anchor)
Calculates the cumulative sum of `source` since the last bar where `anchor` was `true`.
Parameters:
source (series float) : Source used for the calculation.
anchor (series bool) : The condition that triggers the reset of the calculation. The calculation is reset when `anchor` evaluates to `true`, and continues using the values accumulated since the previous reset when `anchor` is `false`.
Returns: (float) The cumulative sum of `source`.
averageAtTime(source, length, anchor, isCumulative)
Calculates the average of all `source` values that share the same time difference from the `anchor` as the current bar for the most recent `length` bars.
Parameters:
source (series float) : Source used for the calculation.
length (simple int) : The number of reset periods to consider for the average calculation of historical data.
anchor (series bool) : The condition that triggers the reset of the average calculation. The calculation is reset when `anchor` evaluates to `true`, and continues using the values accumulated since the previous reset when `anchor` is `false`.
isCumulative (simple bool) : If `true`, `source` values are accumulated until the next time `anchor` is `true`. Optional. The default is `true`.
Returns: (float) The average of the source series at the specified time difference.
CVD - Cumulative Volume Delta (Chart)█ OVERVIEW
This indicator displays cumulative volume delta (CVD) as an on-chart oscillator. It uses intrabar analysis to obtain more precise volume delta information compared to methods that only use the chart's timeframe.
The core concepts in this script come from our first CVD indicator , which displays CVD values as plot candles in a separate indicator pane. In this script, CVD values are scaled according to price ranges and represented on the main chart pane.
█ CONCEPTS
Bar polarity
Bar polarity refers to the position of the close price relative to the open price. In other words, bar polarity is the direction of price change.
Intrabars
Intrabars are chart bars at a lower timeframe than the chart's. Each 1H chart bar of a 24x7 market will, for example, usually contain 60 bars at the lower timeframe of 1min, provided there was market activity during each minute of the hour. Mining information from intrabars can be useful in that it offers traders visibility on the activity inside a chart bar.
Lower timeframes (LTFs)
A lower timeframe is a timeframe that is smaller than the chart's timeframe. This script utilizes a LTF to analyze intrabars, or price changes within a chart bar. The lower the LTF, the more intrabars are analyzed, but the less chart bars can display information due to the limited number of intrabars that can be analyzed.
Volume delta
Volume delta is a measure that separates volume into "up" and "down" parts, then takes the difference to estimate the net demand for the asset. This approach gives traders a more detailed insight when analyzing volume and market sentiment. There are several methods for determining whether an asset's volume belongs in the "up" or "down" category. Some indicators, such as On Balance Volume and the Klinger Oscillator , use the change in price between bars to assign volume values to the appropriate category. Others, such as Chaikin Money Flow , make assumptions based on open, high, low, and close prices. The most accurate method involves using tick data to determine whether each transaction occurred at the bid or ask price and assigning the volume value to the appropriate category accordingly. However, this method requires a large amount of data on historical bars, which can limit the historical depth of charts and the number of symbols for which tick data is available.
In the context where historical tick data is not yet available on TradingView, intrabar analysis is the most precise technique to calculate volume delta on historical bars on our charts. This indicator uses intrabar analysis to achieve a compromise between simplicity and accuracy in calculating volume delta on historical bars. Our Volume Profile indicators use it as well. Other volume delta indicators in our Community Scripts , such as the Realtime 5D Profile , use real-time chart updates to achieve more precise volume delta calculations. However, these indicators aren't suitable for analyzing historical bars since they only work for real-time analysis.
This is the logic we use to assign intrabar volume to the "up" or "down" category:
• If the intrabar's open and close values are different, their relative position is used.
• If the intrabar's open and close values are the same, the difference between the intrabar's close and the previous intrabar's close is used.
• As a last resort, when there is no movement during an intrabar and it closes at the same price as the previous intrabar, the last known polarity is used.
Once all intrabars comprising a chart bar are analyzed, we calculate the net difference between "up" and "down" intrabar volume to produce the volume delta for the chart bar.
█ FEATURES
CVD resets
The "cumulative" part of the indicator's name stems from the fact that calculations accumulate during a period of time. By periodically resetting the volume delta accumulation, we can analyze the progression of volume delta across manageable chunks, which is often more useful than looking at volume delta accumulated from the beginning of a chart's history.
You can configure the reset period using the "CVD Resets" input, which offers the following selections:
• None : Calculations do not reset.
• On a fixed higher timeframe : Calculations reset on the higher timeframe you select in the "Fixed higher timeframe" field.
• At a fixed time that you specify.
• At the beginning of the regular session .
• On trend changes : Calculations reset on the direction change of either the Aroon indicator, Parabolic SAR , or Supertrend .
• On a stepped higher timeframe : Calculations reset on a higher timeframe automatically stepped using the chart's timeframe and following these rules:
Chart TF HTF
< 1min 1H
< 3H 1D
<= 12H 1W
< 1W 1M
>= 1W 1Y
Specifying intrabar precision
Ten options are included in the script to control the number of intrabars used per chart bar for calculations. The greater the number of intrabars per chart bar, the fewer chart bars can be analyzed.
The first five options allow users to specify the approximate amount of chart bars to be covered:
• Least Precise (Most chart bars) : Covers all chart bars by dividing the current timeframe by four.
This ensures the highest level of intrabar precision while achieving complete coverage for the dataset.
• Less Precise (Some chart bars) & More Precise (Less chart bars) : These options calculate a stepped LTF in relation to the current chart's timeframe.
• Very precise (2min intrabars) : Uses the second highest quantity of intrabars possible with the 2min LTF.
• Most precise (1min intrabars) : Uses the maximum quantity of intrabars possible with the 1min LTF.
The stepped lower timeframe for "Less Precise" and "More Precise" options is calculated from the current chart's timeframe as follows:
Chart Timeframe Lower Timeframe
Less Precise More Precise
< 1hr 1min 1min
< 1D 15min 1min
< 1W 2hr 30min
> 1W 1D 60min
The last five options allow users to specify an approximate fixed number of intrabars to analyze per chart bar. The available choices are 12, 24, 50, 100, and 250. The script will calculate the LTF which most closely approximates the specified number of intrabars per chart bar. Keep in mind that due to factors such as the length of a ticker's sessions and rounding of the LTF, it is not always possible to produce the exact number specified. However, the script will do its best to get as close to the value as possible.
As there is a limit to the number of intrabars that can be analyzed by a script, a tradeoff occurs between the number of intrabars analyzed per chart bar and the chart bars for which calculations are possible.
Display
This script displays raw or cumulative volume delta values on the chart as either line or histogram oscillator zones scaled according to the price chart, allowing traders to visualize volume activity on each bar or cumulatively over time. The indicator's background shows where CVD resets occur, demarcating the beginning of new zones. The vertical axis of each oscillator zone is scaled relative to the one with the highest price range, and the oscillator values are scaled relative to the highest volume delta. A vertical offset is applied to each oscillator zone so that the highest oscillator value aligns with the lowest price. This method ensures an accurate, intuitive visual comparison of volume activity within zones, as the scale is consistent across the chart, and oscillator values sit below prices. The vertical scale of oscillator zones can be adjusted using the "Zone Height" input in the script settings.
This script displays labels at the highest and lowest oscillator values in each zone, which can be enabled using the "Hi/Lo Labels" input in the "Visuals" section of the script settings. Additionally, the oscillator's value on a chart bar is displayed as a tooltip when a user hovers over the bar, which can be enabled using the "Value Tooltips" input.
Divergences occur when the polarity of volume delta does not match that of the chart bar. The script displays divergences as bar colors and background colors that can be enabled using the "Color bars on divergences" and "Color background on divergences" inputs.
An information box in the lower-left corner of the indicator displays the HTF used for resets, the LTF used for intrabars, the average quantity of intrabars per chart bar, and the number of chart bars for which there is LTF data. This is enabled using the "Show information box" input in the "Visuals" section of the script settings.
FOR Pine Script™ CODERS
• This script utilizes `ltf()` and `ltfStats()` from the lower_tf library.
The `ltf()` function determines the appropriate lower timeframe from the selected calculation mode and chart timeframe, and returns it in a format that can be used with request.security_lower_tf() .
The `ltfStats()` function, on the other hand, is used to compute and display statistical information about the lower timeframe in an information box.
• The script utilizes display.data_window and display.status_line to restrict the display of certain plots.
These new built-ins allow coders to fine-tune where a script’s plot values are displayed.
• The newly added session.isfirstbar_regular built-in allows for resetting the CVD segments at the start of the regular session.
• The VisibleChart library developed by our resident PineCoders team leverages the chart.left_visible_bar_time and chart.right_visible_bar_time variables to optimize the performance of this script.
These variables identify the opening time of the leftmost and rightmost visible bars on the chart, allowing the script to recalculate and draw objects only within the range of visible bars as the user scrolls.
This functionality also enables the scaling of the oscillator zones.
These variables are just a couple of the many new built-ins available in the chart.* namespace.
For more information, check out this blog post or look them up by typing "chart." in the Pine Script™ Reference Manual .
• Our ta library has undergone significant updates recently, including the incorporation of the `aroon()` indicator used as a method for resetting CVD segments within this script.
Revisit the library to see more of the newly added content!
Look first. Then leap.
TechnicalRating█ OVERVIEW
This library is a Pine Script™ programmer’s tool for incorporating TradingView's well-known technical ratings within their scripts. The ratings produced by this library are the same as those from the speedometers in the technical analysis summary and the "Rating" indicator in the Screener , which use the aggregate biases of 26 technical indicators to calculate their results.
█ CONCEPTS
Ensemble analysis
Ensemble analysis uses multiple weaker models to produce a potentially stronger one. A common form of ensemble analysis in technical analysis is the usage of aggregate indicators together in hopes of gaining further market insight and reinforcing trading decisions.
Technical ratings
Technical ratings provide a simplified way to analyze financial markets by combining signals from an ensemble of indicators into a singular value, allowing traders to assess market sentiment more quickly and conveniently than analyzing each constituent separately. By consolidating the signals from multiple indicators into a single rating, traders can more intuitively and easily interpret the "technical health" of the market.
Calculating the rating value
Using a variety of built-in TA functions and functions from our ta library, this script calculates technical ratings for moving averages, oscillators, and their overall result within the `calcRatingAll()` function.
The function uses the script's `calcRatingMA()` function to calculate the moving average technical rating from an ensemble of 15 moving averages and filters:
• Six Simple Moving Averages and six Exponential Moving Averages with periods of 10, 20, 30, 50, 100, and 200
• A Hull Moving Average with a period of 9
• A Volume-Weighted Moving Average with a period of 20
• An Ichimoku Cloud with a conversion line length of 9, base length of 26, and leading span B length of 52
The function uses the script's `calcRating()` function to calculate the oscillator technical rating from an ensemble of 11 oscillators:
• RSI with a period of 14
• Stochastic with a %K period of 14, a smoothing period of 3, and a %D period of 3
• CCI with a period of 20
• ADX with a DI length of 14 and an ADX smoothing period of 14
• Awesome Oscillator
• Momentum with a period of 10
• MACD with fast, slow, and signal periods of 12, 26, and 9
• Stochastic RSI with an RSI period of 14, a %K period of 14, a smoothing period of 3, and a %D period of 3
• Williams %R with a period of 14
• Bull Bear Power with a period of 50
• Ultimate Oscillator with fast, middle, and slow lengths of 7, 14, and 28
Each indicator is assigned a value of +1, 0, or -1, representing a bullish, neutral, or bearish rating. The moving average rating is the mean of all ratings that use the `calcRatingMA()` function, and the oscillator rating is the mean of all ratings that use the `calcRating()` function. The overall rating is the mean of the moving average and oscillator ratings, which ranges between +1 and -1. This overall rating, along with the separate MA and oscillator ratings, can be used to gain insight into the technical strength of the market. For a more detailed breakdown of the signals and conditions used to calculate the indicators' ratings, consult our Help Center explanation.
Determining rating status
The `ratingStatus()` function produces a string representing the status of a series of ratings. The `strongBound` and `weakBound` parameters, with respective default values of 0.5 and 0.1, define the bounds for "strong" and "weak" ratings.
The rating status is determined as follows:
Rating Value Rating Status
< -strongBound Strong Sell
< -weakBound Sell
-weakBound to weakBound Neutral
> weakBound Buy
> strongBound Strong Buy
By customizing the `strongBound` and `weakBound` values, traders can tailor the `ratingStatus()` function to fit their trading style or strategy, leading to a more personalized approach to evaluating ratings.
Look first. Then leap.
█ FUNCTIONS
This library contains the following functions:
calcRatingAll()
Calculates 3 ratings (ratings total, MA ratings, indicator ratings) using the aggregate biases of 26 different technical indicators.
Returns: A 3-element tuple: ( [(float) ratingTotal, (float) ratingOther, (float) ratingMA ].
countRising(plot)
Calculates the number of times the values in the given series increase in value up to a maximum count of 5.
Parameters:
plot : (series float) The series of values to check for rising values.
Returns: (int) The number of times the values in the series increased in value.
ratingStatus(ratingValue, strongBound, weakBound)
Determines the rating status of a given series based on its values and defined bounds.
Parameters:
ratingValue : (series float) The series of values to determine the rating status for.
strongBound : (series float) The upper bound for a "strong" rating.
weakBound : (series float) The upper bound for a "weak" rating.
Returns: (string) The rating status of the given series ("Strong Buy", "Buy", "Neutral", "Sell", or "Strong Sell").
CVD - Cumulative Volume Delta Candles█ OVERVIEW
This indicator displays cumulative volume delta in candle form. It uses intrabar information to obtain more precise volume delta information than methods using only the chart's timeframe.
█ CONCEPTS
Bar polarity
By bar polarity , we mean the direction of a bar, which is determined by looking at the bar's close vs its open .
Intrabars
Intrabars are chart bars at a lower timeframe than the chart's. Each 1H chart bar of a 24x7 market will, for example, usually contain 60 bars at the lower timeframe of 1min, provided there was market activity during each minute of the hour. Mining information from intrabars can be useful in that it offers traders visibility on the activity inside a chart bar.
Lower timeframes (LTFs)
A lower timeframe is a timeframe that is smaller than the chart's timeframe. This script uses a LTF to access intrabars. The lower the LTF, the more intrabars are analyzed, but the less chart bars can display CVD information because there is a limit to the total number of intrabars that can be analyzed.
Volume delta
The volume delta concept divides a bar's volume in "up" and "down" volumes. The delta is calculated by subtracting down volume from up volume. Many calculation techniques exist to isolate up and down volume within a bar. The simplest techniques use the polarity of interbar price changes to assign their volume to up or down slots, e.g., On Balance Volume or the Klinger Oscillator . Others such as Chaikin Money Flow use assumptions based on a bar's OHLC values. The most precise calculation method uses tick data and assigns the volume of each tick to the up or down slot depending on whether the transaction occurs at the bid or ask price. While this technique is ideal, it requires huge amounts of data on historical bars, which usually limits the historical depth of charts and the number of symbols for which tick data is available.
This indicator uses intrabar analysis to achieve a compromise between the simplest and most precise methods of calculating volume delta. In the context where historical tick data is not yet available on TradingView, intrabar analysis is the most precise technique to calculate volume delta on historical bars on our charts. Our Volume Profile indicators use it. Other volume delta indicators in our Community Scripts such as the Realtime 5D Profile use realtime chart updates to achieve more precise volume delta calculations, but that method cannot be used on historical bars, so those indicators only work in real time.
This is the logic we use to assign intrabar volume to up or down slots:
• If the intrabar's open and close values are different, their relative position is used.
• If the intrabar's open and close values are the same, the difference between the intrabar's close and the previous intrabar's close is used.
• As a last resort, when there is no movement during an intrabar and it closes at the same price as the previous intrabar, the last known polarity is used.
Once all intrabars making up a chart bar have been analyzed and the up or down property of each intrabar's volume determined, the up volumes are added and the down volumes subtracted. The resulting value is volume delta for that chart bar.
█ FEATURES
CVD Candles
Cumulative Volume Delta Candles present volume delta information as it evolves during a period of time.
This is how each candle's levels are calculated:
• open : Each candle's' open level is the cumulative volume delta for the current period at the start of the bar.
This value becomes zero on the first candle following a CVD reset.
The candles after the first one always open where the previous candle closed.
The candle's high, low and close levels are then calculated by adding or subtracting a volume value to the open.
• high : The highest volume delta value found in intrabars. If it is not higher than the volume delta for the bar, then that candle will have no upper wick.
• low : The lowest volume delta value found in intrabars. If it is not lower than the volume delta for the bar, then that candle will have no lower wick.
• close : The aggregated volume delta for all intrabars. If volume delta is positive for the chart bar, then the candle's close will be higher than its open, and vice versa.
The candles are plotted in one of two configurable colors, depending on the polarity of volume delta for the bar.
CVD resets
The "cumulative" part of the indicator's name stems from the fact that calculations accumulate during a period of time. This allows you to analyze the progression of volume delta across manageable chunks, which is often more useful than looking at volume delta cumulated from the beginning of a chart's history.
You can configure the reset period using the "CVD Resets" input, which offers the following selections:
• None : Calculations do not reset.
• On a fixed higher timeframe : Calculations reset on the higher timeframe you select in the "Fixed higher timeframe" field.
• At a fixed time that you specify.
• At the beginning of the regular session .
• On a stepped higher timeframe : Calculations reset on a higher timeframe automatically stepped using the chart's timeframe and following these rules:
Chart TF HTF
< 1min 1H
< 3H 1D
<= 12H 1W
< 1W 1M
>= 1W 1Y
The indicator's background shows where resets occur.
Intrabar precision
The precision of calculations increases with the number of intrabars analyzed for each chart bar. It is controlled through the script's "Intrabar precision" input, which offers the following selections:
• Least precise, covering many chart bars
• Less precise, covering some chart bars
• More precise, covering less chart bars
• Most precise, 1min intrabars
As there is a limit to the number of intrabars that can be analyzed by a script, a tradeoff occurs between the number of intrabars analyzed per chart bar and the chart bars for which calculations are possible.
Total volume candles
You can choose to display candles showing the total intrabar volume for the chart bar. This provides you with more context to evaluate a bar's volume delta by showing it relative to the sum of intrabar volume. Note that because of the reasons explained in the "NOTES" section further down, the total volume is the sum of all intrabar volume rather than the volume of the bar at the chart's timeframe.
Total volume candles can be configured with their own up and down colors. You can also control the opacity of their bodies to make them more or less prominent. This publication's chart shows the indicator with total volume candles. They are turned off by default, so you will need to choose to display them in the script's inputs for them to plot.
Divergences
Divergences occur when the polarity of volume delta does not match that of the chart bar. You can identify divergences by coloring the CVD candles differently for them, or by coloring the indicator's background.
Information box
An information box in the lower-left corner of the indicator displays the HTF used for resets, the LTF used for intrabars, and the average quantity of intrabars per chart bar. You can hide the box using the script's inputs.
█ INTERPRETATION
The first thing to look at when analyzing CVD candles is the side of the zero line they are on, as this tells you if CVD is generally bullish or bearish. Next, one should consider the relative position of successive candles, just as you would with a price chart. Are successive candles trending up, down, or stagnating? Keep in mind that whatever trend you identify must be considered in the context of where it appears with regards to the zero line; an uptrend in a negative CVD (below the zero line) may not be as powerful as one taking place in positive CVD values, but it may also predate a movement into positive CVD territory. The same goes with stagnation; a trader in a long position will find stagnation in positive CVD territory less worrisome than stagnation under the zero line.
After consideration of the bigger picture, one can drill down into the details. Exactly what you are looking for in markets will, of course, depend on your trading methodology, but you may find it useful to:
• Evaluate volume delta for the bar in relation to price movement for that bar.
• Evaluate the proportion that volume delta represents of total volume.
• Notice divergences and if the chart's candle shape confirms a hesitation point, as a Doji would.
• Evaluate if the progress of CVD candles correlates with that of chart bars.
• Analyze the wicks. As with price candles, long wicks tend to indicate weakness.
Always keep in mind that unless you have chosen not to reset it, your CVD resets for each period, whether it is fixed or automatically stepped. Consequently, any trend from the preceding period must re-establish itself in the next.
█ NOTES
Know your volume
Traders using volume information should understand the volume data they are using: where it originates and what transactions it includes, as this can vary with instruments, sectors, exchanges, timeframes, and between historical and realtime bars. The information used to build a chart's bars and display volume comes from data providers (exchanges, brokers, etc.) who often maintain distinct feeds for intraday and end-of-day (EOD) timeframes. How volume data is assembled for the two feeds depends on how instruments are traded in that sector and/or the volume reporting policy for each feed. Instruments from crypto and forex markets, for example, will often display similar volume on both feeds. Stocks will often display variations because block trades or other types of trades may not be included in their intraday volume data. Futures will also typically display variations.
Note that as intraday vs EOD variations exist for historical bars on some instruments, differences may also exist between the realtime feeds used on intraday vs 1D or greater timeframes for those same assets. Realtime reporting rules will often be different from historical feed reporting rules, so variations between realtime feeds will often be different from the variations between historical feeds for the same instrument. The Volume X-ray indicator can help you analyze differences between intraday and EOD volumes for the instruments you trade.
If every unit of volume is both bought by a buyer and sold by a seller, how can volume delta make sense?
Traders who do not understand the mechanics of matching engines (the exchange software that matches orders from buyers and sellers) sometimes argue that the concept of volume delta is flawed, as every unit of volume is both bought and sold. While they are rigorously correct in stating that every unit of volume is both bought and sold, they overlook the fact that information can be mined by analyzing variations in the price of successive ticks, or in our case, intrabars.
Our calculations model the situation where, in fully automated order handling, market orders are generally matched to limit orders sitting in the order book. Buy market orders are matched to quotes at the ask level and sell market orders are matched to quotes at the bid level. As explained earlier, we use the same logic when comparing intrabar prices. While using intrabar analysis does not produce results as precise as when individual transactions — or ticks — are analyzed, results are much more precise than those of methods using only chart prices.
Not only does the concept underlying volume delta make sense, it provides a window on an oft-overlooked variable which, with price and time, is the only basic information representing market activity. Furthermore, because the calculation of volume delta also uses price and time variations, one could conceivably surmise that it can provide a more complete model than ones using price and time only. Whether or not volume delta can be useful in your trading practice, as usual, is for you to decide, as each trader's methodology is different.
For Pine Script™ coders
As our latest Polarity Divergences publication, this script uses the recently released request.security_lower_tf() Pine Script™ function discussed in this blog post . It works differently from the usual request.security() in that it can only be used at LTFs, and it returns an array containing one value per intrabar. This makes it much easier for programmers to access intrabar information.
Look first. Then leap.
FINRA Daily Short Sale Volume█ OVERVIEW
This indicator displays the Daily Short Sale Volume data reported by FINRA for US Stocks markets, namely NASDAQ, NYSE and NYSE ARCA.
█ CONCEPTS
Daily Short Sale Volume data is different from the bi-monthly Short Interest data also reported by FINRA. Whereas Short Interest represents open positions, Short Sale Volume represents transactions, some of which are executed to offset other trades that will not necessarily result in an open short position reported in Short Interest data. This explains why Short Sale Volume values are always greater than Short Interest ones.
Daily Short Sale Volume provides aggregated volume by security for all short trades executed and reported to FINRA during normal market hours, i.e., media-reported trades. It's important to note that Short Sale Volume is not consolidated with exchange data and excludes trading activity that is not publicly disseminated.
█ HOW TO USE IT
Load the indicator on an active chart (see here if you don't know how).
If the chart's symbol is traded on one of the exchanges for which FINRA provides Daily Short Sale Volume, it will be displayed in columns. The columns are a brighter red when their value is above average.
You can display Short Sale Volume for another symbol by checking the "Other symbol" checkbox of the script settings' "Inputs" tab and selecting the symbol.
The moving average's length is in days, as Short Volume is daily data. You can hide the average in the script's settings "Style" tab.
█ NOTES
You will find more information on the Short Sale Volume Data and Understanding Short Sale Volume Data pages of the FINRA website.
Short Interest data reported by FINRA is not yet available on our platform.
On TradingView, Short Sale Volume data is accessible through tickers using special names. For example, NASDAQ:AAPL's Short Sale Volume data can be loaded on your chart via the FINRA:AAPL_SHORT_VOLUME ticker. The indicator displays the name of the ticker used to fetch data in the bottom left. It can be hidden by unchecking the "Tables" item in the "Style" tab of the script's settings.
Look first. Then leap.
Technical Ratings█ OVERVIEW
This indicator calculates TradingView's well-known "Strong Buy", "Buy", "Neutral", "Sell" or "Strong Sell" states using the aggregate biases of 26 different technical indicators.
█ FEATURES
Differences with the built-in version
• You can adjust the weight of the Oscillators and MAs components of the rating here.
• The built-in version produces values matching the states displayed in the "Technicals" ratings gauge; this one does not always, where weighting is used.
• A strategy version is also available as a built-in; this script is an indicator—not a strategy.
• This indicator will show a slightly different vertical scale, as it does not use a fixed scale like the built-in.
• This version allows control over repainting of the signal when you do not use a higher timeframe. Higher timeframe (HTF) information from this version does not repaint.
• You can configure markers on signal breaches of configurable levels, or on advances declines of the signal.
The indicator's settings allow you to:
• Choose the timeframe you want calculations to be made on.
• When not using a HTF, you can select a repainting or non-repainting signal.
• When using both MAs and Oscillators groups to calculate the rating, you can vary the weight of each group in the calculation. The default is 50/50.
Because the MAs group uses longer periods for some of its components, its value is not as jumpy as the Oscillators value.
Increasing the weight of the MAs group will thus have a calming effect on the signal.
• Alerts can be created on the indicator using the conditions configured to control the display of markers.
Display
The calculated rating is displayed as columns, but you can change the style in the inputs. The color of the signal can be one of three colors: bull, bear, or neutral. You can choose from a few presets, or check one and edit its color. The color is determined from the rating's value. Between 0.1 and -0.1 it is in the neutral color. Above/below 0.1/-0.1 it will appear in the bull/bear color. The intensity of the bull/bear color is determined by cumulative advances/declines in the rating. It is capped to 5, so there are five intensities for each of the bull/bear colors.
The "Strong Buy", "Buy", "Neutral", "Sell" or "Strong Sell" state of the last calculated value is displayed to the right of the last bar for each of the three groups: All, MAs and Oscillators. The first value always reflects your selection in the "Rating uses" field and is the one used to display the signal. A "Strong Buy" or "Strong Sell" state appears when the signal is above/below the 0.5/-0.5 level. A "Buy" or "Sell" state appears when the signal is above/below the 0.1/-0.1 level. The "Neutral" state appears when the signal is between 0.1 and -0.1 inclusively.
Five levels are always displayed: 0.5 and 0.1 in the bull color, zero in the neutral color, and -0.1 and - 0.5 in the bull color.
The levels that can be used to determine the breaches displaying long/short markers will only be visible when their respective long/short markers are turned on in the "Direction" input. The levels appear as a bright dotted line in bull/bear colors. You can control both levels separately through the "Longs Level" and "Shorts Level" inputs.
If you specify a higher timeframe that is not greater than the chart's timeframe, an error message will appear and the indicator's background will turn red, as it doesn't make sense to use a lower timeframe than the chart's.
Markers
Markers are small triangles that appear at the bottom and top of the indicator's pane. The marker settings define the conditions that will trigger an alert when you configure an alert on the indicator. You can:
• Choose if you want long, short or both long and short markers.
• Determine the signal level and/or the number of cumulative advances/declines in the signal which must be reached for either a long or short marker to appear.
Reminder: the number of advances/declines is also what controls the brightness of the plotted signal.
• Decide if you want to restrict markers to ones that alternate between longs and shorts, if you are displaying both directions.
This helps to minimize the number of markers, e.g., only the first long marker will be displayed, and then no more long markers will appear until a short comes in, then a long, etc.
Alerts
When you create an alert from this indicator, that alert will trigger whenever your marker conditions are confirmed. Before creating your alert, configure the makers so they reflect the conditions you want your alert to trigger on.
The script uses the alert() function, which entails that you select the "Any alert() function call" condition from the "Create Alert" dialog box when creating alerts on the script. The alert messages can be configured in the inputs. You can safely disregard the warning popup that appears when you create alerts from this script. Alerts will not repaint. Markers will appear, and thus alerts will trigger, at the opening of the bar following the confirmation of the marker condition. Markers will never disappear from the bar once they appear.
Repainting
This indicator uses a two-pronged approach to control repainting. The repainting of the displayed signal is controlled through the "Repainting" field in the script's inputs. This only applies when you have "Same as chart" selected in the "Timeframe" field, as higher timeframe data never repaints. Regardless of that setting, markers and thus alerts never repaint.
When using the chart's timeframe, choosing a non-repainting signal makes the signal one bar late, so that it only displays a value once the bar it was calculated has elapsed. When using a higher timeframe, new values are only displayed once the higher timeframe completes.
Because the markers never repaint, their logic adapts to the repainting setting used for the signal. When the signal repaints, markers will only appear at the close of a realtime bar. When the signal does not repaint (or if you use a higher timeframe), alerts will appear at the beginning of the realtime bar, since they are calculated on values that already do not repaint.
█ CALCULATIONS
The indicator calculates the aggregate value of two groups of indicators: moving averages and oscillators.
The "MAs" group is comprised of 15 different components:
• Six Simple Moving Averages of periods 10, 20, 30, 50, 100 and 200
• Six Exponential Moving Averages of the same periods
• A Hull Moving Average of period 9
• A Volume-weighed Moving Average of period 20
• Ichimoku
The "Oscillators" group includes 11 components:
• RSI
• Stochastic
• CCI
• ADX
• Awesome Oscillator
• Momentum
• MACD
• Stochastic RSI
• Wiliams %R
• Bull Bear Power
• Ultimate Oscillator
The state of each group's components is evaluated to a +1/0/-1 value corresponding to its bull/neutral/bear bias. The resulting value for each of the two groups are then averaged to produce the overall value for the indicator, which oscillates between +1 and -1. The complete conditions used in the calculations are documented in the Help Center .
█ NOTES
Accuracy
When comparing values to the other versions of the Rating, make sure you are comparing similar timeframes, as the "Technicals" gauge in the chart's right pane, for example, uses a 1D timeframe by default.
For coders
We use a handy characteristic of array.avg() which, contrary to avg() , does not return na when one of the averaged values is na . It will average only the array elements which are not na . This is useful in the context where the functions used to calculate the bull/neutral/bear bias for each component used in the rating include special checks to return na whenever the dataset does not yet contain enough data to provide reliable values. This way, components gradually kick in the calculations as the script calculates on more and more historical data.
We also use the new `group` and `tooltip` parameters to input() , as well as dynamic color generation of different transparencies from the bull/bear/neutral colors selected by the user.
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.
Bits and pieces were lifted from the PineCoders' MTF Selection Framework .
Look first. Then leap.
Exploring UnicodeThis script demonstrates how to display Unicode characters and symbols, including emoji, in Pine:
• Part 1 displays multi-line labels on hi/lo pivots.
• Part 2 displays price/volume bumps using small up/down arrows plotted with plotchar() .
• Part 3 detects bounces and uses plotshape() to mark them.
You can use our `f_bounceFrom()` function from this part as confirmation for signals in your strategies.
Note that the labels displayed on pivots with the code in Part 1 are plotted in the past. In realtime, they would only appear where they are after 50 bars have elapsed from that point. The other plots are plotted on the bar where their conditions are detected.
You can display thousands of Unicode characters and symbols using Pine. As you can see with our script, it is very easy to do so. The challenge will often be to find the exact symbols you are looking for. Many websites exist to help you explore Unicode characters or symbols. The PineCoders Resources page contains a section presenting a few of them.
Duyck has a Unicode font function script containing functions to convert strings to monospaced Unicode representations. TradingView uses the Trebuchet font for most of its text, including text displayed with Pine scripts. While its numerals are monospace and will align vertically in labels text, Duyck's functions will be handy when you need to convert characters to a monospaced form, so they also align vertically in multi-line labels.
What is Unicode?
Unicode is to character encoding what Wikipedia is to knowledge; it holds codes to a good proportion of the characters or symbols used by humans, past or present. In the early days of computing, environments from different manufacturers often used different character encoding schemes, making transport between them difficult. Unicode solves that challenge. It is a comprehensive encoding scheme that visionaries from Xerox and Apple came up with in the late 80's. The addition of members from the Research Libraries Group, Sun Microsystems, Microsoft, Next and Metaphor created the "Unicode working group" and later, the Unicode Consortium , which continues to improve and manage the Unicode standard.
Theoretically, Unicode encodes values representing characters or glyphs —not their pictorial representations. The letters "A" or "a", or the blue heart emoji "💙" are each represented by a Unicode value. In practice, however, there are many different versions of the Latin alphabet in Unicode. That is how our low pivot label can display different representations of the letters "ITV". The exact rendition of Unicode symbols on a specific device is left to equipment manufacturers and typeface designers.
The current Unicode space is comprised of 17 planes of 65,536 characters each, which allows for more than one million code points . Planes are further divided into character blocks , which typically hold a character set corresponding to one script—or language. Emoticons are in the character block starting at U+1F600.
Look first. Then leap.
TradingView Alerts to MT4 MT5 - Forex, indices, commoditiesHowdy Algo-Traders! This example script has been created for educational purposes - to present how to use and automatically execute TradingView Alerts on real markets.
I'm posting this script today for a reason. TradingView has just released a new feature of the PineScript language - ALERT() function. Why is it important? It is finally possible to set alerts inside PineScript strategy-type script, without the need to convert the script into study-type. You may say triggering alerts straight from strategies was possible in PineScript before (since June 2020), but it had its limitations. Starting today you can attach alert to any custom event you might want to include in your PineScript code.
With the new feature, it is easier not only to execute strategies, but to maintain codebase - having to update 2 versions of the code with each single modification was... ahem... inconvenient. Moreover, the need to convert strategy into study also meant it was required to rip the code from all strategy...() calls, which carried a lot of useful information, like entry price, position size, and more, definitely influencing results calculated by strategy backtest. So the strategy without these features very likely produced different results than with them. While it was possible to convert these features into study with some advanced "coding gymnastics", it was also quite difficult to test whether those gymnastics didn't introduce serious, bankrupting bugs.
//////
How does this new feature work? It is really simple. On your custom events in the code like "GoLong" or "GoShort", create a string variable containing all the values you need inside your alert and this string variable will be your alert's message. Then, invoke brand new alert() function and that's it (see lines 67 onwards in the script). Set it up in CreateAlert popup and enjoy. Alerts will trigger on candle close as freq= parameter specifies. Detailed specification of the new alert() function can be found in TradingView's PineScript Reference (www.tradingview.com), but there's nothing more than message= and freq= parameters. Nothing else is needed, it is very simple. Yet powerful :)
//////
Alert syntax in this script is prepared to work with TradingConnector. Strategy here is not too complex, but also not the most basic one: it includes full exits, partial exits, stop-losses and it also utilizes dynamic variables calculated by the code (such as stop-loss price). This is only an example use case, because you could handle variety of other functionalities as well: conditional entries, pending entries, pyramiding, hedging, moving stop-loss to break-even, delivering alerts to multiple brokers and more.
//////
This script is a spin-off from my previous work, posted over a year ago here: Some comments on strategy parameters have been discussed there, but let me copy-paste most important points:
* Commission is taken into consideration.
* Slippage is intentionally left at 0. Due to shorter than 1 second delivery time of TradingConnector, slippage is practically non-existing.
* This strategy is NON-REPAINTING and uses NO TRAILING-STOP or any other feature known to be causing problems.
* The strategy was backtested on EURUSD 6h timeframe, will perform differently on other markets and timeframes.
Despite the fact this strategy seems to be still profitable, it is not guaranteed it will continue to perform well in the future. Remember the no.1 rule of backtesting - no matter how profitable and good looking a script is, it only tells about the past. There is zero guarantee the same strategy will get similar results in the future.
Full specs of TradingView alerts and how to set them up can be found here: www.tradingview.com
Why is it ok to backtest on TradingView from now on!TradingView backtester has bad reputation. For a good reason - it was producing wrong results, and it was clear at first sight how bad they were.
But this has changed. Along with many other improvements in its PineScript coding capabilities, TradingView fixed important bug, which was the main reason for miscalculations. TradingView didn't really speak out about this fix, so let me try :)
Have a look at this short code of a swing trading strategy (PLEASE DON'T FOCUS ON BACKTEST RESULTS ATTACHED HERE - THEY DO NOT MATTER). Sometimes entry condition happens together with closing condition for the already ongoing trade. Example: the condition to close Long entry is the same as a condition to enter Short. And when these two aligned, not only a Long was closed and Short was entered (as intended), but also a second Short was entered, too!!! What's even worse, that second short was not controlled with closing conditions inside strategy.exit() function and it very often lead to losses exceeding whatever was declared in "loss=" parameter. This could not have worked well...
But HOORAY!!! - it has been fixed and won't happen anymore. So together with other improvements - TradingView's backtester and PineScript is now ok to work with on standard candlesticks :)
Yep, no need to code strategies and backtest them on other platforms anymore.
----------------
Having said the above, there are still some pitfalls remaining, which you need to be aware of and avoid:
Don't backtest on HeikenAshi, Renko, Kagi candlesticks. They were not invented with backtesting in mind. There are still using wrong price levels for entries and therefore producing always too good backtesting results. Only standard candlesticks are reliable to backtest on.
Don't use Trailing Stop in your code. TradingView operates only on closed candlesticks, not on tick data and because of that, backtester will always assume price has first reached its favourable extreme (so 'high' when you are in Long trade and 'low' when you are in Short trade) before it starts to pull back. Which is rarely the truth in reality. Therefore strategies using Trailing Stop are also producing too good backtesting results. It is especially well visible on higher timeframe strategies - for some reason your strategy manages to make gains on those huge, fat candlesticks :) But that's not reality.
"when=" inside strategy.exit() does not work as you would intuitively expect. If you want to have logical condition to close your trade (for example - crossover(rsi(close,14),20)) you need to place it inside strategy.close() function. And leave StopLoss + TakeProfit conditions inside strategy.exit() function. Just as in attached code.
If you're working with pyramiding, add "process_orders_on_close=ANY" to your strategy() script header. Default setting ("=FIFO") will first close the trade, which was opened first, not the one which was hit by Stop-Loss condidtion.
----------------
That's it, I guess :) If you are noticing other issues with backtester and would like to share, let everyone know in comments. If the issue is indeed a bug, there is a chance TradingView dev team will hear your voice and take it into account when working on other improvements. Just like they heard about the bug I described above.
P.S. I know for a fact that more improvements in the backtesting area are coming. Some will change the game even for non-coding traders. If you want to be notified quickly and with my comment - gimme "follow".
TradingView Alerts to MT4 MT5 + dynamic variables NON-REPAINTINGAccidentally, I’m sharing open-source profitable Forex strategy. Accidentally, because this was aimed to be purely educational material. A few days ago TradingView released a very powerful feature of dynamic values from PineScript now being allowed to be passed in Alerts. And thanks to TradingConnector, they could be instantly executed in MT4 or MT5 platform of any broker in the world. So yeah - TradingConnector works with indices and commodities, too.
The logic of this EURUSD 6h strategy is very simple - it is based on Stochastic crossovers with stop-loss set under most recent pivot point. Setting stop-loss with surgical precision is possible exactly thanks to allowance of dynamic values in alerts. TradingConnector has been also upgraded to take advantage of these dynamic values and it now enables executing trades with pre-calculated stop-loss, take-profit, as well as stop and limit orders.
Another fresh feature of TradingConnector, is closing positions only partly - provided that the broker allows it, of course. A position needs to have trade_id specified at entry, referred to in further alerts with partial closing. Detailed spec of alerts syntax and functionalities can be found at TradingConnector website. How to include dynamic variables in alert messages can be seen at the very end of the script in alertcondition() calls.
The strategy also takes commission into consideration.
Slippage is intentionally left at 0. Due to shorter than 1 second delivery time of TradingConnector, slippage is practically non-existing. This can be achieved especially if you’re using VPS server, hosted in the same datacenter as your brokers’ servers. I am using such setup, it is doable. Small slippage and spread is already included in commission value.
This strategy is NON-REPAINTING and uses NO TRAILING-STOP or any other feature known to be faulty in TradingView backtester. Does it make this strategy bulletproof and 100% success-guaranteed? Hell no! Remember the no.1 rule of backtesting - no matter how profitable and good looking a script is, it only tells about the past. There is zero guarantee the same strategy will get similar results in the future.
To turn this script into study so that alerts can be produced, do 2 things:
1. comment “strategy” line at the beginning and uncomment “study” line
2. comment lines 54-59 and uncomment lines 62-65.
Then add script to the chart and configure alerts.
This script was build for educational purposes only.
Certainly this is not financial advice. Anybody using this script or any of its parts in any way, must be aware of high risks connected with trading.
Thanks @LucF and @a.tesla2018 for helping me with code fixes :)
TradingView PartyNow you can enjoy TradingView as your very own personal party lights display!
This script is not designed to be seriously used for trading. It draws lines, boxes and labels randomly to simulate party lights. I recommend disabling other chart plots, including the price and also to use this script on a live chart (one on which the price is moving) with a low timeframe such as a 1 second or 1 minute chart, so that what you see will change often.
The point of this script is to have cool looking things appear on the chart somewhat randomly. Hue, saturation, lightness and transparency can be edited the settings. All colours are generated randomly within those constraints.
Thanks to @RicardoSantos and @HeWhoMustNotBeNamed for their contributions to the random colour generation in this ground breaking work.
Tradingview ToolkitA new trader's biggest barrier to entry is lack of understanding where they are in terms of time and price and with tradingview free they are often limited to just 1 or 2 extra indicators as many new traders slap on RSI and MACD as 2/3 free ones. While these indicators are fine for trend analysis, its important to know where the price is in relation to time. Thus, this all-in-one script is meant to have a lot of customizable utility to save on indicator spots and act as a hotspot for many common needs.
-2 Sets of VWAP line w/ standard deviation bands with customizable timeframes.
-1 more customizable timeframe VWAP line (no std dev bands) to use as a long time frame reference
-Ability to plot previous VWAP close prices over current timeframe on all VWAP lines w/ basic color changing if price closes above/below
-2 Sets of Bollinger Bands with customizable source length and MA type
-3 customizable moving averages with custom timeframe/resolutions
-Inside candle barcolor repainter to easily notice if a candle was inside the range of the previous candle (price contraction)
Not meant to have everything on at once, but simply a place to enable and disable different things and save spots for more important things
TradingView's Technical AnalysisAll indicators used on the Technical Analysis Summary from TradingView, composed with oscillators and moving averages. Sell and strong sell will represent more indicators showing sell signals. Buy and strong buy will represent more indicators showing buy signals. A white bar will show neutral signal (don't trade). This can be good for binary options or scalping on small time frames, but also very good on higher times for forex. The signal will appear on the candle before, so wait for the new candle to appear to see what direction the signal will indicate.
[blackcat] L1 TradingView Array and Series ConversionsLevel 1
Background
It just so happens that I need some functions that can convert between the Series data type and the Array data type.
Function
Series is a unique data type of TradingView. By operating Series data, the algorithm can be simplified, which is very convenient. However, in high-level languages, Array is a basic data type that provides great flexibility and can be used to develop advanced algorithms. This is why TradingView introduces the Array data type. This script simply demonstrates how to convert between these two data types.
s2a function: Convert a TV series into an array.
a2s function: Convert an array into a TV series
Finally, Courtesy of Electrified for his "Average Lib":
Remarks
Feedbacks are appreciated.
Modified TradingView's Up/Down Volume [vnhilton]
When plotting columns, histograms, etc. You'll notice that the indicator does not stick to the bottom of the pane. To fix this, you need another indicator (we'll call this 'placeholder') in the same pane as this indicator. Pin the placeholder indicator to the left scale, & pin the main indicator to the left scale. Then, pin the placeholder indicator to scale A, & finally the main indictor to the right scale.
Note: On the daily timeframes & higher, the up/down volume isn't accurate. Therefore, I've added a feature where you can toggle on the main indicator to disappear & only show ordinary total volume similar to the TradingView volume indicator.
The original code belongs to TradingView. This is a modified indicator that displays the down volume above the up volume similar to the volume profile. Also includes a moving average using the total volume, & a feature to display ordinary volume to solve the up/down inaccuracies on the daily timeframe & higher.
TCP | Money Management indicator | Crypto Version📌 TCP | Money Management Indicator | Crypto Version
A robust, multi-target risk and capital management indicator tailored for crypto traders. Whether you're trading spot, perpetual futures, or leverage tokens, this tool empowers you with precise control over risk, reward, and position sizing—directly on your chart. Eliminate guesswork and trade with confidence.
🔰 Introduction: Master Your Capital, Master Your Trades
Poor money management is the number one reason traders lose their accounts, even with solid strategies. The TCP Money Management Indicator, built by Trade City Pro (TCP), solves this problem by providing a structured, rule-based approach to capital allocation.
Want to dive deeper into the concept of money management? Check out our comprehensive tutorial on TradingView, " TradeCityPro Academy: Money Management ", to understand the principles that power this indicator and transform your trading mindset.
This indicator equips you to:
• Calculate optimal position sizes based on your capital, risk percentage, and leverage
• Set up to 5 customizable take-profit targets with partial close percentages
• Access real-time metrics like Risk-to-Reward (R/R), USD profit, and margin usage
• Trade with discipline, avoiding emotional or inconsistent decisions
💸 Money Management Formula
The indicator uses a professional capital allocation model:
Position Size = (Capital × Risk %) ÷ (Stop Loss % × Leverage)
From this, it calculates:
• Total risk amount in USD
• Optimal position size for your trade
• Margin required for each take-profit target
• Adjusted R/R for each target, accounting for partial position closures
🛠 How to Use
Enter Trade Parameters: Input your capital, risk %, leverage, entry price, and stop-loss price.
Set Take-Profit Targets: Enable 1 to 5 take-profit levels and specify the percentage of the position to close at each.
Real-Time Calculations: The indicator automatically computes:
• R/R ratio for each target
• Profit in USD for each partial close
• Margin used per target (in % and USD)
Visualize Your Trade:
• Price levels for entry, stop-loss, and take-profits are plotted on the chart.
• A dynamic info panel on the left side displays all key metrics.
🔄 Dynamic Adjustments: As each take-profit target is hit and a portion of the position is closed, the indicator recalculates the remaining position size, expected profit, R/R, and margin for subsequent targets. This ensures accuracy and reflects real-world trade behavior.
📊 Table Overview
The left-side panel provides a clear snapshot:
• Trade Setup: Capital, entry price, stop-loss, risk amount, and position size
• Per Target: Percentage closed, R/R, profit in USD, and margin used
• Summary: Total expected profit across all targets
⚙️ Settings Panel
• Total Capital ($): Your account size for the trade
• Risk per Trade (%): The percentage of capital you’re willing to risk
• Leverage: The leverage applied to the trade
• Entry/Stop-Loss Prices: Define your trade’s risk zone
• Take-Profit Targets (1–5): Set price levels and percentage to close at each
🔍 Use Case Example
Imagine you have $1,000 capital, risking 1%, using 10x leverage:
• Entry: $100 | Stop-Loss: $95
• TP1: $110 (close 50%) | TP2: $115 (close 50%)
The indicator calculates the exact position size, profit at each target, and margin allocation in real time, with all metrics displayed on the chart.
✅ Why Traders Love It
• Precision: No more manual calculations or guesswork
• Versatility: Works on all crypto pairs (BTC, ETH, altcoins, etc.)
• Flexibility: Perfect for scalping, swing trading, or futures strategies
• Universal: Compatible with all timeframes
• Transparency: Fully manual, with clear and reliable outputs
🧩 Built by Trade City Pro (TCP)
Developed by TCP, a trusted name in trading tools, used by over 150,000 traders worldwide. This indicator is coded in Pine Script v5, ensuring compatibility with TradingView’s platform.
🧾 Final Notes
• No Auto-Trading: This is a manual tool for disciplined traders
• No Repainting: All calculations are accurate and non-repainting
• Tested: Rigorously validated across major crypto pairs
• Publish-Ready: Built for seamless use on TradingView
🔗 Resources
• Money Management Tutorial: Learn the fundamentals of capital management with our detailed guide: TradeCityPro Academy: Money Management
• TradingView Profile: Explore more tools by TCP on TradingView
