Şimdi başlat

Komut dosyalarını "bar" için ara

Madrid MA Ribbon BarThis study is the companion of the MMAR, displayed here in this publication. This displays the same information as MMAR, but in a linear format. This measures the possibilities of a trend reversal. If the bar fills over 50% of the opposite color from bottom to top then chances are there will be a trend reversal. Otherwise it is just a reentry point. This study doesn't require but one parameter, and the default is very good. Define if you want to use the standard or the exponential moving average. It is simple, easy to interpret and doesn't require much space on the screen. It uses only four standard colors 1. Red : A downtrend in progress 2. Green: A short reentry or a trend reversal warning 3. Lime : An uptrend in progress 4. Maroon: A long reentry or a trend reversal warning
Pine Script® göstergesi
Madrid tarafından
9
FVE Volatility color-coded Volume bar The FVE is a pure volume indicator. Unlike most of the other indicators (except OBV), price change doesn?t come into the equation for the FVE (price is not multiplied by volume), but is only used to determine whether money is flowing in or out of the stock. This is contrary to the current trend in the design of modern money flow indicators. The author decided against a price-volume indicator for the following reasons: - A pure volume indicator has more power to contradict. - The number of buyers or sellers (which is assessed by volume) will be the same, regardless of the price fluctuation. - Price-volume indicators tend to spike excessively at breakouts or breakdowns. This study is an addition to FVE indicator. Indicator plots different-coloured volume bars depending on volatility.
Pine Script® göstergesi
HPotter tarafından
2
Custom Indicator Clearly Shows If Bulls or Bears are in Control!The Two Versions of this Indicator I learned from Two Famous and Highly Successful Traders. This Indicator shows With No Lag Clear Up and Down Trends in Market by Documenting Clearly If Bulls or Bears are in Control. The Version In SubChart 1 Shows Consecutive Closes if the Current Close is Greater than of Less than the Midpoint of the Previous Bar (Why Midpoint Explained in Detail in 1st Post). The Version in SubChart 2 Shows Consecutive Closes that are Greater than or Less Than the Previous Close (Will Discuss Specific Uses in 1st Post). Works on Stocks, Forex, Futures, on All Timeframes.
Pine Script® göstergesi
ChrisMoody tarafından
36
VWAP filtered MACD Bars with positive MACD histogram value and closing above VWAP are colored, long positions should be taken in areas made of those bars. Similarly, bars with negative MACD histogram value and closing below VWAP are also colored, short positions should be taken there. This indicator by default should be a part of your trend following trading system. In the setting you can change colors Above grow: positive and rising MACD histogram value Above fall: positive and falling MACD histogram value Below fall: negative and falling MACD histogram value Below grow: negative and rising MACD histogram value
Pine Script® göstergesi
phk28 tarafından
Bars pattern MLThis script implements a K-Nearest Neighbors (KNN)-based machine learning model to predict future price movements in financial markets. It analyzes past price action using Euclidean distance and selects the most similar historical patterns to estimate future price changes. Unlike traditional KNN implementations, this approach optimizes distance calculations by maintaining a dynamically updated list of the closest neighbors, ensuring efficient selection without the need for sorting. The model generates a forecasted price trajectory based on incremental predictions, which are visualized on the chart using polylines for better interpretability.
Pine Script® göstergesi
tkarolak tarafından
2
Volume HighlightBar colouring: this indicator is simple but effective, it repaints higher than normal candles a certain colour (by default gold/yellow) it helps to know what are valuable areas to trade around for longs and shorts. Changing the volume multiplier manually helps you to screen volume relevant to the timeframe you are trading on. For example, some charts 1min the best filter/setting would be 12-35 multiplier where others like btc 1-4 hourly, the filter/setting might be 8-12. The key is having only the highest/most relevant 3-4 volume candles showing as they often represent supports and resistances.
Pine Script® göstergesi
retrosoul tarafından
Pivot Points And Breakout Price Action With LuckyNickVaBar Color Candle Aligned with pivot points swing high and swing lows For Those Who Are Familiar with Trading The Breakouts Of Highs & Lows Of Structure. Pivots are said to be key areas in the market where price shows heavy reaction to where reversals make occur. At these points there are swing Highs & swing lows that traders may be able to find opportunity in the market. This Script is a combination of pivot points and Barcolor signals for the breakout.
Pine Script® göstergesi
Nickafella tarafından
3
Bars CharacteristicsThis code is for defining or explaining market conditions via micro trend and the characterized bars. lines 5,6: show the conditions for a normal trend, means market can go in the direction that it has in the past. lines 11,12: show the conditions for kind of the trend having cumulative energy itself, mean market can go in the same direction. lines 18,19: show the conditions for kind of the trend having overbought/sold concept, means it's better exit from the market or to look for the other clues. lines 24,25: show some kind of noise not a stable trend, it's better not to enter the market.
Pine Script® göstergesi
SuYan tarafından
WhenWasThePriceAction Bars of largest range (volatility) * see moments of strongest price action immediately * colored & upDown by candle color * amplifier: you see only the bull runs, and subsequent dumps Very nice on the 5 years scale of BITSTAMP:BTCUSD - nothing comparable to 2013 has happened yet. Internals: squared_range = pow(high-low, 2) That is essentially it already. The rest are details: * gauge with (in case of Bitcoin exponentially rising) price * show in red for negative candles * take even higher polynomial (than 2) to show only the very largest values * allow some user input (but there is not much more that can be chosen here.) Sorry for such a simple formula - but sometimes the easiest things are powerful. Please give feedback. www.tradingview.com and/or in the cryptocurrency chat. Thanks.
Pine Script® göstergesi
akd tarafından
3
Bollinger Bands Entry/Exit ThresholdsBollinger Bands Entry/Exit Thresholds Author of enhancements: chuckaschultz Inspired and adapted from the original 'Bollinger Bands Breakout Oscillator' by LuxAlgo Overview Pairs nicely with Contrarian 100 MA The Bollinger Bands Entry/Exit Thresholds is a powerful momentum-based indicator designed to help traders identify potential entry and exit points in trending or breakout markets. By leveraging Bollinger Bands, this indicator quantifies price deviations from the bands to generate bullish and bearish momentum signals, displayed as an oscillator. It includes customizable entry and exit signals based on user-defined thresholds, with visual cues plotted either on the oscillator panel or directly on the price chart. This indicator is ideal for traders looking to capture breakout opportunities or confirm trend strength, with flexible settings to adapt to various markets and trading styles. How It Works The Bollinger Bands Entry/Exit Thresholds calculates two key metrics: Bullish Momentum (Bull): Measures the extent to which the price exceeds the upper Bollinger Band, expressed as a percentage (0–100). Bearish Momentum (Bear): Measures the extent to which the price falls below the lower Bollinger Band, also expressed as a percentage (0–100). The indicator generates: Long Entry Signals: Triggered when the bearish momentum (bear) crosses below a user-defined Long Threshold (default: 40). This suggests weakening bearish pressure, potentially indicating a reversal or breakout to the upside. Exit Signals: Triggered when the bullish momentum (bull) crosses below a user-defined Sell Threshold (default: 80), indicating a potential reduction in bullish momentum and a signal to exit long positions. Signals are visualized as tiny colored dots: Long Entry: Blue dots, plotted either at the bottom of the oscillator or below the price bar (depending on user settings). Exit Signal: White dots, plotted either at the top of the oscillator or above the price bar. Calculation Methodology Bollinger Bands: A user-defined Length (default: 14) is used to calculate an Exponential Moving Average (EMA) of the source price (default: close). Standard deviation is computed over the same length, multiplied by a user-defined Multiplier (default: 1.0). Upper Band = EMA + (Standard Deviation × Multiplier) Lower Band = EMA - (Standard Deviation × Multiplier) Bull and Bear Momentum: For each bar in the lookback period (length), the indicator calculates: Bullish Momentum: The sum of positive deviations of the price above the upper band, normalized by the total absolute deviation from the upper band, scaled to a 0–100 range. Bearish Momentum: The sum of positive deviations of the price below the lower band, normalized by the total absolute deviation from the lower band, scaled to a 0–100 range. Formula: bull = (sum of max(price - upper, 0) / sum of abs(price - upper)) * 100 bear = (sum of max(lower - price, 0) / sum of abs(lower - price)) * 100 Signal Generation: Long Entry: Triggered when bear crosses below the Long Threshold. Exit: Triggered when bull crosses below the Sell Threshold. Settings Length: Lookback period for EMA and standard deviation (default: 14). Multiplier: Multiplier for standard deviation to adjust Bollinger Band width (default: 1.0). Source: Input price data (default: close). Long Threshold: Bearish momentum level below which a long entry signal is generated (default: 40). Sell Threshold: Bullish momentum level below which an exit signal is generated (default: 80). Plot Signals on Main Chart: Option to display entry/exit signals on the price chart instead of the oscillator panel (default: false). Style: Bullish Color: Color for bullish momentum plot (default: #f23645). Bearish Color: Color for bearish momentum plot (default: #089981). Visual Features Bull and Bear Plots: Displayed as colored lines with gradient fills for visual clarity. Midline: Horizontal line at 50 for reference. Threshold Lines: Dashed green line for Long Threshold and dashed red line for Sell Threshold. Signal Dots: Long Entry: Tiny blue dots (below price bar or at oscillator bottom). Exit: Tiny white dots (above price bar or at oscillator top). How to Use Add to Chart: Apply the indicator to your TradingView chart. Adjust Settings: Customize the Length, Multiplier, Long Threshold, and Sell Threshold to suit your trading strategy. Interpret Signals: Enter a long position when a blue dot appears, indicating bearish momentum dropping below the Long Threshold. Exit the long position when a white dot appears, indicating bullish momentum dropping below the Sell Threshold. Toggle Plot Location: Enable Plot Signals on Main Chart to display signals on the price chart for easier integration with price action analysis. Combine with Other Tools: Use alongside other indicators (e.g., trendlines, support/resistance) to confirm signals. Notes This indicator is inspired by LuxAlgo’s Bollinger Bands Breakout Oscillator but has been enhanced with customizable entry/exit thresholds and signal plotting options. Best used in conjunction with other technical analysis tools to filter false signals, especially in choppy or range-bound markets. Adjust the Multiplier to make the Bollinger Bands wider or narrower, affecting the sensitivity of the momentum calculations. Disclaimer This indicator is provided for educational and informational purposes only.
Pine Script® göstergesi
chuckaschultz tarafından
ValueAtTime█ OVERVIEW This library is a Pine Script® programming tool for accessing historical values in a time series using UNIX timestamps . Its data structure and functions index values by time, allowing scripts to retrieve past values based on absolute timestamps or relative time offsets instead of relying on bar index offsets. █ CONCEPTS UNIX timestamps In Pine Script®, a UNIX timestamp is an integer representing the number of milliseconds elapsed since January 1, 1970, at 00:00:00 UTC (the UNIX Epoch ). The timestamp is a unique, absolute representation of a specific point in time. Unlike a calendar date and time, a UNIX timestamp's meaning does not change relative to any time zone . This library's functions process series values and corresponding UNIX timestamps in pairs , offering a simplified way to identify values that occur at or near distinct points in time instead of on specific bars. Storing and retrieving time-value pairs This library's `Data` type defines the structure for collecting time and value information in pairs. Objects of the `Data` type contain the following two fields:  • `times` – An array of "int" UNIX timestamps for each recorded value.  • `values` – An array of "float" values for each saved timestamp. Each index in both arrays refers to a specific time-value pair. For instance, the `times` and `values` elements at index 0 represent the first saved timestamp and corresponding value. The library functions that maintain `Data` objects queue up to one time-value pair per bar into the object's arrays, where the saved timestamp represents the bar's opening time . Because the `times` array contains a distinct UNIX timestamp for each item in the `values` array, it serves as a custom mapping for retrieving saved values. All the library functions that return information from a `Data` object use this simple two-step process to identify a value based on time:  1. Perform a binary search on the `times` array to find the earliest saved timestamp closest to the specified time or offset and get the element's index.  2. Access the element from the `values` array at the retrieved index, returning the stored value corresponding to the found timestamp. Value search methods There are several techniques programmers can use to identify historical values from corresponding timestamps. This library's functions include three different search methods to locate and retrieve values based on absolute times or relative time offsets: Timestamp search   Find the value with the earliest saved timestamp closest to a specified timestamp. Millisecond offset search Find the value with the earliest saved timestamp closest to a specified number of milliseconds behind the current bar's opening time. This search method provides a time-based alternative to retrieving historical values at specific bar offsets. Period offset search Locate the value with the earliest saved timestamp closest to a defined period offset behind the current bar's opening time. The function calculates the span of the offset based on a period string . The "string" must contain one of the following unit tokens:  • "D" for days  • "W" for weeks  • "M" for months  • "Y" for years  • "YTD" for year-to-date, meaning the time elapsed since the beginning of the bar's opening year in the exchange time zone. The period string can include a multiplier prefix for all supported units except "YTD" (e.g., "2W" for two weeks). Note that the precise span covered by the "M", "Y", and "YTD" units varies across time. The "1M" period can cover 28, 29, 30, or 31 days, depending on the bar's opening month and year in the exchange time zone. The "1Y" period covers 365 or 366 days, depending on leap years. The "YTD" period's span changes with each new bar, because it always measures the time from the start of the current bar's opening year. █ CALCULATIONS AND USE This library's functions offer a flexible, structured approach to retrieving historical values at or near specific timestamps, millisecond offsets, or period offsets for different analytical needs. See below for explanations of the exported functions and how to use them. Retrieving single values The library includes three functions that retrieve a single stored value using timestamp, millisecond offset, or period offset search methods:  • `valueAtTime()` – Locates the saved value with the earliest timestamp closest to a specified timestamp.  • `valueAtTimeOffset()` – Finds the saved value with the earliest timestamp closest to the specified number of milliseconds behind the current bar's opening time.  • `valueAtPeriodOffset()` – Finds the saved value with the earliest timestamp closest to the period-based offset behind the current bar's opening time. Each function has two overloads for advanced and simple use cases. The first overload searches for a value in a user-specified `Data` object created by the `collectData()` function (see below). It returns a tuple containing the found value and the corresponding timestamp. The second overload maintains a `Data` object internally to store and retrieve values for a specified `source` series. This overload returns a tuple containing the historical `source` value, the corresponding timestamp, and the current bar's `source` value, making it helpful for comparing past and present values from requested contexts. Retrieving multiple values The library includes the following functions to retrieve values from multiple historical points in time, facilitating calculations and comparisons with values retrieved across several intervals:  • `getDataAtTimes()` – Locates a past `source` value for each item in a `timestamps` array. Each retrieved value's timestamp represents the earliest time closest to one of the specified timestamps.  • `getDataAtTimeOffsets()` – Finds a past `source` value for each item in a `timeOffsets` array. Each retrieved value's timestamp represents the earliest time closest to one of the specified millisecond offsets behind the current bar's opening time.  • `getDataAtPeriodOffsets()` – Finds a past value for each item in a `periods` array. Each retrieved value's timestamp represents the earliest time closest to one of the specified period offsets behind the current bar's opening time. Each function returns a tuple with arrays containing the found `source` values and their corresponding timestamps. In addition, the tuple includes the current `source` value and the symbol's description, which also makes these functions helpful for multi-interval comparisons using data from requested contexts. Processing period inputs When writing scripts that retrieve historical values based on several user-specified period offsets, the most concise approach is to create a single text input that allows users to list each period, then process the "string" list into an array for use in the `getDataAtPeriodOffsets()` function. This library includes a `getArrayFromString()` function to provide a simple way to process strings containing comma-separated lists of periods. The function splits the specified `str` by its commas and returns an array containing every non-empty item in the list with surrounding whitespaces removed. View the example code to see how we use this function to process the value of a text area input . Calculating period offset times Because the exact amount of time covered by a specified period offset can vary, it is often helpful to verify the resulting times when using the `valueAtPeriodOffset()` or `getDataAtPeriodOffsets()` functions to ensure the calculations work as intended for your use case. The library's `periodToTimestamp()` function calculates an offset timestamp from a given period and reference time. With this function, programmers can verify the time offsets in a period-based data search and use the calculated offset times in additional operations. For periods with "D" or "W" units, the function calculates the time offset based on the absolute number of milliseconds the period covers (e.g., `86400000` for "1D"). For periods with "M", "Y", or "YTD" units, the function calculates an offset time based on the reference time's calendar date in the exchange time zone. Collecting data All the `getDataAt*()` functions, and the second overloads of the `valueAt*()` functions, collect and maintain data internally, meaning scripts do not require a separate `Data` object when using them. However, the first overloads of the `valueAt*()` functions do not collect data, because they retrieve values from a user-specified `Data` object. For cases where a script requires a separate `Data` object for use with these overloads or other custom routines, this library exports the `collectData()` function. This function queues each bar's `source` value and opening timestamp into a `Data` object and returns the object's ID. This function is particularly useful when searching for values from a specific series more than once. For instance, instead of using multiple calls to the second overloads of `valueAt*()` functions with the same `source` argument, programmers can call `collectData()` to store each bar's `source` and opening timestamp, then use the returned `Data` object's ID in calls to the first `valueAt*()` overloads to reduce memory usage. The `collectData()` function and all the functions that collect data internally include two optional parameters for limiting the saved time-value pairs to a sliding window: `timeOffsetLimit` and `timeframeLimit`. When either has a non-na argument, the function restricts the collected data to the maximum number of recent bars covered by the specified millisecond- and timeframe-based intervals. NOTE : All calls to the functions that collect data for a `source` series can execute up to once per bar or realtime tick, because each stored value requires a unique corresponding timestamp. Therefore, scripts cannot call these functions iteratively within a loop . If a call to these functions executes more than once inside a loop's scope, it causes a runtime error. █ EXAMPLE CODE The example code at the end of the script demonstrates one possible use case for this library's functions. The code retrieves historical price data at user-specified period offsets, calculates price returns for each period from the retrieved data, and then populates a table with the results. The example code's process is as follows:   1. Input a list of periods – The user specifies a comma-separated list of period strings in the script's "Period list" input (e.g., "1W, 1M, 3M, 1Y, YTD"). Each item in the input list represents a period offset from the latest bar's opening time.   2. Process the period list – The example calls `getArrayFromString()` on the first bar to split the input list by its commas and construct an array of period strings.   3. Request historical data – The code uses a call to `getDataAtPeriodOffsets()` as the `expression` argument in a request.security() call to retrieve the closing prices of "1D" bars for each period included in the processed `periods` array.   4. Display information in a table – On the latest bar, the code uses the retrieved data to calculate price returns over each specified period, then populates a two-row table with the results. The cells for each return percentage are color-coded based on the magnitude and direction of the price change. The cells also include tooltips showing the compared daily bar's opening date in the exchange time zone. █ NOTES  • This library's architecture relies on a user-defined type (UDT) for its data storage format. UDTs are blueprints from which scripts create objects , i.e., composite structures with fields containing independent values or references of any supported type.  • The library functions search through a `Data` object's `times` array using the array.binary_search_leftmost() function, which is more efficient than looping through collected data to identify matching timestamps. Note that this built-in works only for arrays with elements sorted in ascending order .  • Each function that collects data from a `source` series updates the values and times stored in a local `Data` object's arrays. If a single call to these functions were to execute in a loop , it would store multiple values with an identical timestamp, which can cause erroneous search behavior. To prevent looped calls to these functions, the library uses the `checkCall()` helper function in their scopes. This function maintains a counter that increases by one each time it executes on a confirmed bar. If the count exceeds the total number of bars, indicating the call executes more than once in a loop, it raises a runtime error .  • Typically, when requesting higher-timeframe data with request.security() while using barmerge.lookahead_on as the `lookahead` argument, the `expression` argument should be offset with the history-referencing operator to prevent lookahead bias on historical bars. However, the call in this script's example code enables lookahead without offsetting the `expression` because the script displays results only on the last historical bar and all realtime bars, where there is no future data to leak into the past. This call ensures the displayed results use the latest data available from the context on realtime bars. Look first. Then leap. █ EXPORTED TYPES Data   A structure for storing successive timestamps and corresponding values from a dataset.   Fields:      times (array) : An "int" array containing a UNIX timestamp for each value in the `values` array.      values (array) : A "float" array containing values corresponding to the timestamps in the `times` array. █ EXPORTED FUNCTIONS getArrayFromString(str)   Splits a "string" into an array of substrings using the comma (`,`) as the delimiter. The function trims surrounding whitespace characters from each substring, and it excludes empty substrings from the result.   Parameters:      str (series string) : The "string" to split into an array based on its commas.   Returns: (array) An array of trimmed substrings from the specified `str`. periodToTimestamp(period, referenceTime)   Calculates a UNIX timestamp representing the point offset behind a reference time by the amount of time within the specified `period`.   Parameters:      period (series string) : The period string, which determines the time offset of the returned timestamp. The specified argument must contain a unit and an optional multiplier (e.g., "1Y", "3M", "2W", "YTD"). Supported units are: - "Y" for years. - "M" for months. - "W" for weeks. - "D" for days. - "YTD" (Year-to-date) for the span from the start of the `referenceTime` value's year in the exchange time zone. An argument with this unit cannot contain a multiplier.      referenceTime (series int) : The millisecond UNIX timestamp from which to calculate the offset time.   Returns: (int) A millisecond UNIX timestamp representing the offset time point behind the `referenceTime`. collectData(source, timeOffsetLimit, timeframeLimit)   Collects `source` and `time` data successively across bars. The function stores the information within a `Data` object for use in other exported functions/methods, such as `valueAtTimeOffset()` and `valueAtPeriodOffset()`. Any call to this function cannot execute more than once per bar or realtime tick.   Parameters:      source (series float) : The source series to collect. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.      timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.      timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.   Returns: (Data) A `Data` object containing collected `source` values and corresponding timestamps over the allowed time range. method valueAtTime(data, timestamp)   (Overload 1 of 2) Retrieves value and time data from a `Data` object's fields at the index of the earliest timestamp closest to the specified `timestamp`. Callable as a method or a function.   Parameters:      data (series Data) : The `Data` object containing the collected time and value data.      timestamp (series int) : The millisecond UNIX timestamp to search. The function returns data for the earliest saved timestamp that is closest to the value.   Returns: ( ) A tuple containing the following data from the `Data` object: - The stored value corresponding to the identified timestamp ("float"). - The earliest saved timestamp that is closest to the specified `timestamp` ("int"). valueAtTime(source, timestamp, timeOffsetLimit, timeframeLimit)   (Overload 2 of 2) Retrieves `source` and time information for the earliest bar whose opening timestamp is closest to the specified `timestamp`. Any call to this function cannot execute more than once per bar or realtime tick.   Parameters:      source (series float) : The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.      timestamp (series int) : The millisecond UNIX timestamp to search. The function returns data for the earliest bar whose timestamp is closest to the value.      timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.      timeframeLimit (simple string) : (simple string) Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.   Returns: ( ) A tuple containing the following data: - The `source` value corresponding to the identified timestamp ("float"). - The earliest bar's timestamp that is closest to the specified `timestamp` ("int"). - The current bar's `source` value ("float"). method valueAtTimeOffset(data, timeOffset)   (Overload 1 of 2) Retrieves value and time data from a `Data` object's fields at the index of the earliest saved timestamp closest to `timeOffset` milliseconds behind the current bar's opening time. Callable as a method or a function.   Parameters:      data (series Data) : The `Data` object containing the collected time and value data.      timeOffset (series int) : The millisecond offset behind the bar's opening time. The function returns data for the earliest saved timestamp that is closest to the calculated offset time.   Returns: ( ) A tuple containing the following data from the `Data` object: - The stored value corresponding to the identified timestamp ("float"). - The earliest saved timestamp that is closest to `timeOffset` milliseconds before the current bar's opening time ("int"). valueAtTimeOffset(source, timeOffset, timeOffsetLimit, timeframeLimit)   (Overload 2 of 2) Retrieves `source` and time information for the earliest bar whose opening timestamp is closest to `timeOffset` milliseconds behind the current bar's opening time. Any call to this function cannot execute more than once per bar or realtime tick.   Parameters:      source (series float) : The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.      timeOffset (series int) : The millisecond offset behind the bar's opening time. The function returns data for the earliest bar's timestamp that is closest to the calculated offset time.      timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.      timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.   Returns: ( ) A tuple containing the following data: - The `source` value corresponding to the identified timestamp ("float"). - The earliest bar's timestamp that is closest to `timeOffset` milliseconds before the current bar's opening time ("int"). - The current bar's `source` value ("float"). method valueAtPeriodOffset(data, period)   (Overload 1 of 2) Retrieves value and time data from a `Data` object's fields at the index of the earliest timestamp closest to a calculated offset behind the current bar's opening time. The calculated offset represents the amount of time covered by the specified `period`. Callable as a method or a function.   Parameters:      data (series Data) : The `Data` object containing the collected time and value data.      period (series string) : The period string, which determines the calculated time offset. The specified argument must contain a unit and an optional multiplier (e.g., "1Y", "3M", "2W", "YTD"). Supported units are: - "Y" for years. - "M" for months. - "W" for weeks. - "D" for days. - "YTD" (Year-to-date) for the span from the start of the current bar's year in the exchange time zone. An argument with this unit cannot contain a multiplier.   Returns: ( ) A tuple containing the following data from the `Data` object: - The stored value corresponding to the identified timestamp ("float"). - The earliest saved timestamp that is closest to the calculated offset behind the bar's opening time ("int"). valueAtPeriodOffset(source, period, timeOffsetLimit, timeframeLimit)   (Overload 2 of 2) Retrieves `source` and time information for the earliest bar whose opening timestamp is closest to a calculated offset behind the current bar's opening time. The calculated offset represents the amount of time covered by the specified `period`. Any call to this function cannot execute more than once per bar or realtime tick.   Parameters:      source (series float) : The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.      period (series string) : The period string, which determines the calculated time offset. The specified argument must contain a unit and an optional multiplier (e.g., "1Y", "3M", "2W", "YTD"). Supported units are: - "Y" for years. - "M" for months. - "W" for weeks. - "D" for days. - "YTD" (Year-to-date) for the span from the start of the current bar's year in the exchange time zone. An argument with this unit cannot contain a multiplier.      timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.      timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.   Returns: ( ) A tuple containing the following data: - The `source` value corresponding to the identified timestamp ("float"). - The earliest bar's timestamp that is closest to the calculated offset behind the current bar's opening time ("int"). - The current bar's `source` value ("float"). getDataAtTimes(timestamps, source, timeOffsetLimit, timeframeLimit)   Retrieves `source` and time information for each bar whose opening timestamp is the earliest one closest to one of the UNIX timestamps specified in the `timestamps` array. Any call to this function cannot execute more than once per bar or realtime tick.   Parameters:      timestamps (array) : An array of "int" values representing UNIX timestamps. The function retrieves `source` and time data for each element in this array.      source (series float) : The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.      timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.      timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.   Returns: ( ) A tuple of the following data: - An array containing a `source` value for each identified timestamp (array). - An array containing an identified timestamp for each item in the `timestamps` array (array). - The current bar's `source` value ("float"). - The symbol's description from `syminfo.description` ("string"). getDataAtTimeOffsets(timeOffsets, source, timeOffsetLimit, timeframeLimit)   Retrieves `source` and time information for each bar whose opening timestamp is the earliest one closest to one of the time offsets specified in the `timeOffsets` array. Each offset in the array represents the absolute number of milliseconds behind the current bar's opening time. Any call to this function cannot execute more than once per bar or realtime tick.   Parameters:      timeOffsets (array) : An array of "int" values representing the millisecond time offsets used in the search. The function retrieves `source` and time data for each element in this array. For example, the array ` ` specifies that the function returns data for the timestamps closest to one day and one week behind the current bar's opening time.      source (float) : (series float) The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.      timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.      timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.   Returns: ( ) A tuple of the following data: - An array containing a `source` value for each identified timestamp (array). - An array containing an identified timestamp for each offset specified in the `timeOffsets` array (array). - The current bar's `source` value ("float"). - The symbol's description from `syminfo.description` ("string"). getDataAtPeriodOffsets(periods, source, timeOffsetLimit, timeframeLimit)   Retrieves `source` and time information for each bar whose opening timestamp is the earliest one closest to a calculated offset behind the current bar's opening time. Each calculated offset represents the amount of time covered by a period specified in the `periods` array. Any call to this function cannot execute more than once per bar or realtime tick.   Parameters:      periods (array) : An array of period strings, which determines the time offsets used in the search. The function retrieves `source` and time data for each element in this array. For example, the array ` ` specifies that the function returns data for the timestamps closest to one day, week, and month behind the current bar's opening time. Each "string" in the array must contain a unit and an optional multiplier. Supported units are: - "Y" for years. - "M" for months. - "W" for weeks. - "D" for days. - "YTD" (Year-to-date) for the span from the start of the current bar's year in the exchange time zone. An argument with this unit cannot contain a multiplier.      source (float) : (series float) The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.      timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.      timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.   Returns: ( ) A tuple of the following data: - An array containing a `source` value for each identified timestamp (array). - An array containing an identified timestamp for each period specified in the `periods` array (array). - The current bar's `source` value ("float"). - The symbol's description from `syminfo.description` ("string").
Pine Script® kütüphanesi
TradingView tarafından
1
`security()` revisited [PineCoders]NOTE The non-repainting technique in this publication that relies on bar states is now deprecated, as we have identified inconsistencies that undermine its credibility as a universal solution. The outputs that use the technique are still available for reference in this publication. However, we do not endorse its usage. See this publication for more information about the current best practices for requesting HTF data and why they work. █  OVERVIEW This script presents a new function to help coders use security() in both repainting and non-repainting modes. We revisit this often misunderstood and misused function, and explain its behavior in different contexts, in the hope of dispelling some of the coder lure surrounding it. The function is incredibly powerful, yet misused, it can become a dangerous WMD and an instrument of deception, for both coders and traders. We will discuss:  • How to use our new `f_security()` function.  • The behavior of Pine code and security() on the three very different types of bars that make up any chart.  • Why what you see on a chart is a simulation, and should be taken with a grain of salt.  • Why we are presenting a new version of a function handling security() calls.  • Other topics of interest to coders using higher timeframe (HTF) data. █  WARNING We have tried to deliver a function that is simple to use and will, in non-repainting mode, produce reliable results for both experienced and novice coders. If you are a novice coder, stick to our recommendations to avoid getting into trouble, and DO NOT change our `f_security()` function when using it. Use `false` as the function's last argument and refrain from using your script at smaller timeframes than the chart's. To call our function to fetch a non-repainting value of close from the 1D timeframe, use: f_security(_sym, _res, _src, _rep) => security(_sym, _res, _src ) previousDayClose = f_security(syminfo.tickerid, "D", close, false) If that's all you're interested in, you are done. If you choose to ignore our recommendation and use the function in repainting mode by changing the `false` in there for `true`, we sincerely hope you read the rest of our ramblings before you do so, to understand the consequences of your choice. Let's now have a look at what security() is showing you. There is a lot to cover, so buckle up! But before we dig in, one last thing. What is a chart? A chart is a graphic representation of events that occur in markets. As any representation, it is not reality, but rather a model of reality. As Scott Page eloquently states in The Model Thinker : "All models are wrong; many are useful". Having in mind that both chart bars and plots on our charts are imperfect and incomplete renderings of what actually occurred in realtime markets puts us coders in a place from where we can better understand the nature of, and the causes underlying the inevitable compromises necessary to build the data series our code uses, and print chart bars. Traders or coders complaining that charts do not reflect reality act like someone who would complain that the word "dog" is not a real dog. Let's recognize that we are dealing with models here, and try to understand them the best we can. Sure, models can be improved; TradingView is constantly improving the quality of the information displayed on charts, but charts nevertheless remain mere translations. Plots of data fetched through security() being modelized renderings of what occurs at higher timeframes, coders will build more useful and reliable tools for both themselves and traders if they endeavor to perfect their understanding of the abstractions they are working with. We hope this publication helps you in this pursuit. █  FEATURES This script's "Inputs" tab has four settings:  • Repaint : Determines whether the functions will use their repainting or non-repainting mode.   Note that the setting will not affect the behavior of the yellow plot, as it always repaints.  • Source : The source fetched by the security() calls.  • Timeframe : The timeframe used for the security() calls. If it is lower than the chart's timeframe, a warning appears.  • Show timeframe reminder : Displays a reminder of the timeframe after the last bar. █  THE CHART The chart shows two different pieces of information and we want to discuss other topics in this section, so we will be covering:  A — The type of chart bars we are looking at, indicated by the colored band at the top.  B — The plots resulting of calling security() with the close price in different ways.  C — Points of interest on the chart. A — Chart bars The colored band at the top shows the three types of bars that any chart on a live market will print. It is critical for coders to understand the important distinctions between each type of bar:  1 — Gray : Historical bars, which are bars that were already closed when the script was run on them.  2 — Red : Elapsed realtime bars, i.e., realtime bars that have run their course and closed.    The state of script calculations showing on those bars is that of the last time they were made, when the realtime bar closed.  3 — Green : The realtime bar. Only the rightmost bar on the chart can be the realtime bar at any given time, and only when the chart's market is active. Refer to the Pine User Manual's Execution model page for a more detailed explanation of these types of bars. B — Plots The chart shows the result of letting our 5sec chart run for a few minutes with the following settings: "Repaint" = "On" (the default is "Off"), "Source" = `close` and "Timeframe" = 1min. The five lines plotted are the following. They have progressively thinner widths:  1 — Yellow : A normal, repainting security() call.  2 — Silver : Our recommended security() function.  3 — Fuchsia : Our recommended way of achieving the same result as our security() function, for cases when the source used is a function returning a tuple.  4 — White : The method we previously recommended in our MTF Selection Framework , which uses two distinct security() calls.  5 — Black : A lame attempt at fooling traders that MUST be avoided. All lines except the first one in yellow will vary depending on the "Repaint" setting in the script's inputs. The first plot does not change because, contrary to all other plots, it contains no conditional code to adapt to repainting/no-repainting modes; it is a simple security() call showing its default behavior. C — Points of interest on the chart Historical bars do not show actual repainting behavior To appreciate what a repainting security()  call will plot in realtime, one must look at the realtime bar and at elapsed realtime bars, the bars where the top line is green or red on the chart at the top of this page. There you can see how the plots go up and down, following the close value of each successive chart bar making up a single bar of the higher timeframe. You would see the same behavior in "Replay" mode. In the realtime bar, the movement of repainting plots will vary with the source you are fetching: open will not move after a new timeframe opens, low and high will change when a new low or high are found, close will follow the last feed update. If you are fetching a value calculated by a function, it may also change on each update. Now notice how different the plots are on historical bars. There, the plot shows the close of the previously completed timeframe for the whole duration of the current timeframe, until on its last bar the price updates to the current timeframe's close when it is confirmed (if the timeframe's last bar is missing, the plot will only update on the next timeframe's first bar). That last bar is the only one showing where the plot would end if that timeframe's bars had elapsed in realtime. If one doesn't understand this, one cannot properly visualize how his script will calculate in realtime when using repainting. Additionally, as published scripts typically show charts where the script has only run on historical bars, they are, in fact, misleading traders who will naturally assume the script will behave the same way on realtime bars. Non-repainting plots are more accurate on historical bars Now consider this chart, where we are using the same settings as on the chart used to publish this script, except that we have turned "Repainting" off this time: The yellow line here is our reference, repainting line, so although repainting is turned off, it is still repainting, as expected. Because repainting is now off, however, plots on historical bars show the previous timeframe's close until the first bar of a new timeframe, at which point the plot updates. This correctly reflects the behavior of the script in the realtime bar, where because we are offsetting the series by one, we are always showing the previously calculated—and thus confirmed—higher timeframe value. This means that in realtime, we will only get the previous timeframe's values one bar after the timeframe's last bar has elapsed, at the open of the first bar of a new timeframe. Historical and elapsed realtime bars will not actually show this nuance because they reflect the state of calculations made on their close , but we can see the plot update on that bar nonetheless. ► This more accurate representation on historical bars of what will happen in the realtime bar is one of the two key reasons why using non-repainting data is preferable.    The other is that in realtime, your script will be using more reliable data and behave more consistently. Misleading plots Valiant attempts by coders to show non-repainting, higher timeframe data updating earlier than on our chart are futile. If updates occur one bar earlier because coders use the repainting version of the function, then so be it, but they must then also accept that their historical bars are not displaying information that is as accurate. Not informing script users of this is to mislead them. Coders should also be aware that if they choose to use repainting data in realtime, they are sacrificing reliability to speed and may be running a strategy that behaves very differently from the one they backtested, thus invalidating their tests. When, however, coders make what are supposed to be non-repainting plots plot artificially early on historical bars, as in examples "c4" and "c5" of our script, they would want us to believe they have achieved the miracle of time travel. Our understanding of the current state of science dictates that for now, this is impossible. Using such techniques in scripts is plainly misleading, and public scripts using them will be moderated. We are coding trading tools here—not video games. Elementary ethics prescribe that we should not mislead traders, even if it means not being able to show sexy plots. As the great Feynman said: You should not fool the layman when you're talking as a scientist. You can readily appreciate the fantasy plot of "c4", the thinnest line in black, by comparing its supposedly non-repainting behavior between historical bars and realtime bars. After updating—by miracle—as early as the wide yellow line that is repainting, it suddenly moves in a more realistic place when the script is running in realtime, in synch with our non-repainting lines. The "c5" version does not plot on the chart, but it displays in the Data Window. It is even worse than "c4" in that it also updates magically early on historical bars, but goes on to evaluate like the repainting yellow line in realtime, except one bar late. Data Window The Data Window shows the values of the chart's plots, then the values of both the inside and outside offsets used in our calculations, so you can see them change bar by bar. Notice their differences between historical and elapsed realtime bars, and the realtime bar itself. If you do not know about the Data Window, have a look at this essential tool for Pine coders in the Pine User Manual's page on Debugging . The conditional expressions used to calculate the offsets may seem tortuous but their objective is quite simple. When repainting is on, we use this form, so with no offset on all bars: security(ticker, i_timeframe, i_source ) // which is equivalent to: security(ticker, i_timeframe, i_source) When repainting is off, we use two different and inverted offsets on historical bars and the realtime bar: // Historical bars: security(ticker, i_timeframe, i_source ) // Realtime bar (and thus, elapsed realtime bars): security(ticker, i_timeframe, i_source ) The offsets in the first line show how we prevent repainting on historical bars without the need for the `lookahead` parameter. We use the value of the function call on the chart's previous bar. Since values between the repainting and non-repainting versions only differ on the timeframe's last bar, we can use the previous value so that the update only occurs on the timeframe's first bar, as it will in realtime when not repainting. In the realtime bar, we use the second call, where the offsets are inverted. This is because if we used the first call in realtime, we would be fetching the value of the repainting function on the previous bar, so the close of the last bar. What we want, instead, is the data from the previous, higher timeframe bar , which has elapsed and is confirmed, and thus will not change throughout realtime bars, except on the first constituent chart bar belonging to a new higher timeframe. After the offsets, the Data Window shows values for the `barstate.*` variables we use in our calculations. █  NOTES Why are we revisiting security()  ? For four reasons:  1 — We were seeing coders misuse our `f_secureSecurity()` function presented in How to avoid repainting when using security() .    Some novice coders were modifying the offset used with the history-referencing operator in the function, making it zero instead of one,    which to our horror, caused look-ahead bias when used with `lookahead = barmerge.lookahead_on`.    We wanted to present a safer function which avoids introducing the dreaded "lookahead" in the scripts of unsuspecting coders.  2 — The popularity of security() in screener-type scripts where coders need to use the full 40 calls allowed per script made us want to propose    a solid method of allowing coders to offer a repainting/no-repainting choice to their script users with only one security() call.  3 — We wanted to explain why some alternatives we see circulating are inadequate and produce misleading behavior.  4 — Our previous publication on security() focused on how to avoid repainting, yet many other considerations worthy of attention are not related to repainting. Handling tuples When sending function calls that return tuples with security() , our `f_security()` function will not work because Pine does not allow us to use the history-referencing operator with tuple return values. The solution is to integrate the inside offset to your function's arguments, use it to offset the results the function is returning, and then add the outside offset in a reassignment of the tuple variables, after security() returns its values to the script, as we do in our "c2" example. Does it repaint? We're pretty sure Wilder was not asked very often if RSI repainted. Why? Because it wasn't in fashion—and largely unnecessary—to ask that sort of question in the 80's. Many traders back then used daily charts only, and indicator values were calculated at the day's close, so everybody knew what they were getting. Additionally, indicator values were calculated by generally reputable outfits or traders themselves, so data was pretty reliable. Today, almost anybody can write a simple indicator, and the programming languages used to write them are complex enough for some coders lacking the caution, know-how or ethics of the best professional coders, to get in over their heads and produce code that does not work the way they think it does. As we hope to have clearly demonstrated, traders do have legitimate cause to ask if MTF scripts repaint or not when authors do not specify it in their script's description. ► We recommend that authors always use our `f_security()` with `false` as the last argument to avoid repainting when fetching data dependent on OHLCV information. This is the only way to obtain reliable HTF data. If you want to offer users a choice, make non-repainting mode the default, so that if users choose repainting, it will be their responsibility. Non-repainting security() calls are also the only way for scripts to show historical behavior that matches the script's realtime behavior, so you are not misleading traders. Additionally, non-repainting HTF data is the only way that non-repainting alerts can be configured on MTF scripts, as users of MTF scripts cannot prevent their alerts from repainting by simply configuring them to trigger on the bar's close. Data feeds A chart at one timeframe is made up of multiple feeds that mesh seamlessly to form one chart. Historical bars can use one feed, and the realtime bar another, which brokers/exchanges can sometimes update retroactively so that elapsed realtime bars will reappear with very slight modifications when the browser's tab is refreshed. Intraday and daily chart prices also very often originate from different feeds supplied by brokers/exchanges. That is why security() calls at higher timeframes may be using a completely different feed than the chart, and explains why the daily high value, for example, can vary between timeframes. Volume information can also vary considerably between intraday and daily feeds in markets like stocks, because more volume information becomes available at the end of day. It is thus expected behavior—and not a bug—to see data variations between timeframes. Another point to keep in mind concerning feeds it that when you are using a repainting security() plot in realtime, you will sometimes see discrepancies between its plot and the realtime bars. An artefact revealing these inconsistencies can be seen when security() plots sometimes skip a realtime chart bar during periods of high market activity. This occurs because of races between the chart and the security() feeds, which are being monitored by independent, concurrent processes. A blue arrow on the chart indicates such an occurrence. This is another cause of repainting, where realtime bar-building logic can produce different outcomes on one closing price. It is also another argument supporting our recommendation to use non-repainting data. Alternatives There is an alternative to using security() in some conditions. If all you need are OHLC prices of a higher timeframe, you can use a technique like the one Duyck demonstrates in his security free MTF example - JD script. It has the great advantage of displaying actual repainting values on historical bars, which mimic the code's behavior in the realtime bar—or at least on elapsed realtime bars, contrary to a repainting security() plot. It has the disadvantage of using the current chart's TF data feed prices, whereas higher timeframe data feeds may contain different and more reliable prices when they are compiled at the end of the day. In its current state, it also does not allow for a repainting/no-repainting choice. When `lookahead` is useful When retrieving non-price data, or in special cases, for experiments, it can be useful to use `lookahead`. One example is our Backtesting on Non-Standard Charts: Caution! script where we are fetching prices of standard chart bars from non-standard charts. Warning users Normal use of security() dictates that it only be used at timeframes equal to or higher than the chart's. To prevent users from inadvertently using your script in contexts where it will not produce expected behavior, it is good practice to warn them when their chart is on a higher timeframe than the one in the script's "Timeframe" field. Our `f_tfReminderAndErrorCheck()` function in this script does that. It can also print a reminder of the higher timeframe. It uses one security() call. Intrabar timeframes security() is not supported by TradingView when used with timeframes lower than the chart's. While it is still possible to use security() at intrabar timeframes, it then behaves differently. If no care is taken to send a function specifically written to handle the successive intrabars, security() will return the value of the last intrabar in the chart's timeframe, so the last 1H bar in the current 1D bar, if called at "60" from a "D" chart timeframe. If you are an advanced coder, see our FAQ entry on the techniques involved in processing intrabar timeframes. Using intrabar timeframes comes with important limitations, which you must understand and explain to traders if you choose to make scripts using the technique available to others. Special care should also be taken to thoroughly test this type of script. Novice coders should refrain from getting involved in this. █  TERMINOLOGY Timeframe Timeframe , interval and resolution are all being used to name the concept of timeframe. We have, in the past, used "timeframe" and "resolution" more or less interchangeably. Recently, members from the Pine and PineCoders team have decided to settle on "timeframe", so from hereon we will be sticking to that term. Multi-timeframe (MTF) Some coders use "multi-timeframe" or "MTF" to name what are in fact "multi-period" calculations, as when they use MAs of progressively longer periods. We consider that a misleading use of "multi-timeframe", which should be reserved for code using calculations actually made from another timeframe's context and using security() , safe for scripts like Duyck's one mentioned earlier, or TradingView's Relative  Volume  at  Time , which use a user-selected timeframe as an anchor to reset calculations. Calculations made at the chart's timeframe by varying the period of MAs or other rolling window calculations should be called "multi-period", and "MTF-anchored" could be used for scripts that reset calculations on timeframe boundaries. Colophon Our script was written using the PineCoders Coding Conventions for Pine . The description was formatted using the techniques explained in the How We Write and Format Script Descriptions PineCoders publication. Snippets were lifted from our MTF Selection Framework , then massaged to create the `f_tfReminderAndErrorCheck()` function. █  THANKS Thanks to apozdnyakov for his help with the innards of security() . Thanks to bmistiaen for proofreading our description. Look first. Then leap.
Pine Script® göstergesi
PineCoders tarafından
60
FvgCalculations█ OVERVIEW This library provides the core calculation engine for identifying Fair Value Gaps (FVGs) across different timeframes and for processing their interaction with price. It includes functions to detect FVGs on both the current chart and higher timeframes, as well as to check for their full or partial mitigation. █ CONCEPTS The library's primary functions revolve around the concept of Fair Value Gaps and their lifecycle. Fair Value Gap (FVG) Identification An FVG, or imbalance, represents a price range where buying or selling pressure was significant enough to cause a rapid price movement, leaving an "inefficiency" in the market. This library identifies FVGs based on three-bar patterns: Bullish FVG: Forms when the low of the current bar (bar 3) is higher than the high of the bar two periods prior (bar 1). The FVG is the space between the high of bar 1 and the low of bar 3. Bearish FVG: Forms when the high of the current bar (bar 3) is lower than the low of the bar two periods prior (bar 1). The FVG is the space between the low of bar 1 and the high of bar 3. The library provides distinct functions for detecting FVGs on the current (Low Timeframe - LTF) and specified higher timeframes (Medium Timeframe - MTF / High Timeframe - HTF). FVG Mitigation Mitigation refers to price revisiting an FVG. Full Mitigation: An FVG is considered fully mitigated when price completely closes the gap. For a bullish FVG, this occurs if the current low price moves below or touches the FVG's bottom. For a bearish FVG, it occurs if the current high price moves above or touches the FVG's top. Partial Mitigation (Entry/Fill): An FVG is partially mitigated when price enters the FVG's range but does not fully close it. The library tracks the extent of this fill. For a bullish FVG, if the current low price enters the FVG from above, that low becomes the new effective top of the remaining FVG. For a bearish FVG, if the current high price enters the FVG from below, that high becomes the new effective bottom of the remaining FVG. FVG Interaction This refers to any instance where the current bar's price range (high to low) touches or crosses into the currently unfilled portion of an active (visible and not fully mitigated) FVG. Multi-Timeframe Data Acquisition To detect FVGs on higher timeframes, specific historical bar data (high, low, and time of bars at indices and relative to the higher timeframe's last completed bar) is required. The requestMultiTFBarData function is designed to fetch this data efficiently. █ CALCULATIONS AND USE The functions in this library are typically used in a sequence to manage FVGs: 1. Data Retrieval (for MTF/HTF FVGs): Call requestMultiTFBarData() with the desired higher timeframe string (e.g., "60", "D"). This returns a tuple of htfHigh1, htfLow1, htfTime1, htfHigh3, htfLow3, htfTime3. 2. FVG Detection: For LTF FVGs: Call detectFvg() on each confirmed bar. It uses high , low, low , and high along with barstate.isconfirmed. For MTF/HTF FVGs: Call detectMultiTFFvg() using the data obtained from requestMultiTFBarData(). Both detection functions return an fvgObject (defined in FvgTypes) if an FVG is found, otherwise na. They also can classify FVGs as "Large Volume" (LV) if classifyLV is true and the FVG size (top - bottom) relative to the tfAtr (Average True Range of the respective timeframe) meets the lvAtrMultiplier. 3. FVG State Updates (on each new bar for existing FVGs): First, check for overall price interaction using fvgInteractionCheck(). This function determines if the current bar's high/low has touched or entered the FVG's currentTop or currentBottom. If interaction occurs and the FVG is not already mitigated: Call checkMitigation() to determine if the FVG has been fully mitigated by the current bar's currentHigh and currentLow. If true, the FVG's isMitigated status is updated. If not fully mitigated, call checkPartialMitigation() to see if the price has further entered the FVG. This function returns the newLevel to which the FVG has been filled (e.g., currentLow for a bullish FVG, currentHigh for bearish). This newLevel is then used to update the FVG's currentTop or currentBottom. The calling script (e.g., fvgMain.c) is responsible for storing and managing the array of fvgObject instances and passing them to these update functions. █ NOTES Bar State for LTF Detection: The detectFvg() function relies on barstate.isconfirmed to ensure FVG detection is based on closed bars, preventing FVGs from being detected prematurely on the currently forming bar. Higher Timeframe Data (lookahead): The requestMultiTFBarData() function uses lookahead = barmerge.lookahead_on. This means it can access historical data from the higher timeframe that corresponds to the current bar on the chart, even if the higher timeframe bar has not officially closed. This is standard for multi-timeframe analysis aiming to plot historical HTF data accurately on a lower timeframe chart. Parameter Typing: Functions like detectMultiTFFvg and detectFvg infer the type for boolean (classifyLV) and numeric (lvAtrMultiplier) parameters passed from the main script, while explicitly typed series parameters (like htfHigh1, currentAtr) expect series data. fvgObject Dependency: The FVG detection functions return fvgObject instances, and fvgInteractionCheck takes an fvgObject as a parameter. This UDT is defined in the FvgTypes library, making it a dependency for using FvgCalculations. ATR for LV Classification: The tfAtr (for MTF/HTF) and currentAtr (for LTF) parameters are expected to be the Average True Range values for the respective timeframes. These are used, if classifyLV is enabled, to determine if an FVG's size qualifies it as a "Large Volume" FVG based on the lvAtrMultiplier. MTF/HTF FVG Appearance Timing: When displaying FVGs from a higher timeframe (MTF/HTF) on a lower timeframe (LTF) chart, users might observe that the most recent MTF/HTF FVG appears one LTF bar later compared to its appearance on a native MTF/HTF chart. This is an expected behavior due to the detection mechanism in `detectMultiTFFvg`. This function uses historical bar data from the MTF/HTF (specifically, data equivalent to `HTF_bar ` and `HTF_bar `) to identify an FVG. Therefore, all three bars forming the FVG on the MTF/HTF must be fully closed and have shifted into these historical index positions relative to the `request.security` call from the LTF chart before the FVG can be detected and displayed on the LTF. This ensures that the MTF/HTF FVG is identified based on confirmed, closed bars from the higher timeframe. █ EXPORTED FUNCTIONS requestMultiTFBarData(timeframe)   Requests historical bar data for specific previous bars from a specified higher timeframe.   It fetches H , L , T (for the bar before last) and H , L , T (for the bar three periods prior) from the requested timeframe.   This is typically used to identify FVG patterns on MTF/HTF.   Parameters:      timeframe (simple string) : The higher timeframe to request data from (e.g., "60" for 1-hour, "D" for Daily).   Returns: A tuple containing: .   - htfHigh1 (series float): High of the bar at index 1 (one bar before the last completed bar on timeframe).   - htfLow1 (series float): Low of the bar at index 1.   - htfTime1 (series int) : Time of the bar at index 1.   - htfHigh3 (series float): High of the bar at index 3 (three bars before the last completed bar on timeframe).   - htfLow3 (series float): Low of the bar at index 3.   - htfTime3 (series int) : Time of the bar at index 3. detectMultiTFFvg(htfHigh1, htfLow1, htfTime1, htfHigh3, htfLow3, htfTime3, tfAtr, classifyLV, lvAtrMultiplier, tfType)   Detects a Fair Value Gap (FVG) on a higher timeframe (MTF/HTF) using pre-fetched bar data.   Parameters:      htfHigh1 (float) : High of the first relevant bar (typically high ) from the higher timeframe.      htfLow1 (float) : Low of the first relevant bar (typically low ) from the higher timeframe.      htfTime1 (int) : Time of the first relevant bar (typically time ) from the higher timeframe.      htfHigh3 (float) : High of the third relevant bar (typically high ) from the higher timeframe.      htfLow3 (float) : Low of the third relevant bar (typically low ) from the higher timeframe.      htfTime3 (int) : Time of the third relevant bar (typically time ) from the higher timeframe.      tfAtr (float) : ATR value for the higher timeframe, used for Large Volume (LV) FVG classification.      classifyLV (bool) : If true, FVGs will be assessed to see if they qualify as Large Volume.      lvAtrMultiplier (float) : The ATR multiplier used to define if an FVG is Large Volume.      tfType (series tfType enum from no1x/FvgTypes/1) : The timeframe type (e.g., types.tfType.MTF, types.tfType.HTF) of the FVG being detected.   Returns: An fvgObject instance if an FVG is detected, otherwise na. detectFvg(classifyLV, lvAtrMultiplier, currentAtr)   Detects a Fair Value Gap (FVG) on the current (LTF - Low Timeframe) chart.   Parameters:      classifyLV (bool) : If true, FVGs will be assessed to see if they qualify as Large Volume.      lvAtrMultiplier (float) : The ATR multiplier used to define if an FVG is Large Volume.      currentAtr (float) : ATR value for the current timeframe, used for LV FVG classification.   Returns: An fvgObject instance if an FVG is detected, otherwise na. checkMitigation(isBullish, fvgTop, fvgBottom, currentHigh, currentLow)   Checks if an FVG has been fully mitigated by the current bar's price action.   Parameters:      isBullish (bool) : True if the FVG being checked is bullish, false if bearish.      fvgTop (float) : The top price level of the FVG.      fvgBottom (float) : The bottom price level of the FVG.      currentHigh (float) : The high price of the current bar.      currentLow (float) : The low price of the current bar.   Returns: True if the FVG is considered fully mitigated, false otherwise. checkPartialMitigation(isBullish, currentBoxTop, currentBoxBottom, currentHigh, currentLow)   Checks for partial mitigation of an FVG by the current bar's price action.   It determines if the price has entered the FVG and returns the new fill level.   Parameters:      isBullish (bool) : True if the FVG being checked is bullish, false if bearish.      currentBoxTop (float) : The current top of the FVG box (this might have been adjusted by previous partial fills).      currentBoxBottom (float) : The current bottom of the FVG box (similarly, might be adjusted).      currentHigh (float) : The high price of the current bar.      currentLow (float) : The low price of the current bar.   Returns: The new price level to which the FVG has been filled (e.g., currentLow for a bullish FVG).   Returns na if no new partial fill occurred on this bar. fvgInteractionCheck(fvg, highVal, lowVal)   Checks if the current bar's price interacts with the given FVG.   Interaction means the price touches or crosses into the FVG's current (possibly partially filled) range.   Parameters:      fvg (fvgObject type from no1x/FvgTypes/1) : The FVG object to check.     Its isMitigated, isVisible, isBullish, currentTop, and currentBottom fields are used.      highVal (float) : The high price of the current bar.      lowVal (float) : The low price of the current bar.   Returns: True if price interacts with the FVG, false otherwise.
Pine Script® kütüphanesi
no1x tarafından
chrono_utilsLibrary "chrono_utils" Collection of objects and common functions that are related to datetime windows session days and time ranges. The main purpose of this library is to handle time-related functionality and make it easy to reason about a future bar and see if it is part of a predefined user session and/or inside a datetime window. All existing session functions I found in the documentation e.g. "not na(time(timeframe, session, timezone))" are not suitable for strategies, since the execution of the orders is delayed by one bar due to the execution happening at the bar close. So a prediction for the next bar is necessary. Moreover, a history operator with a negative value is not allowed e.g. `not na(time(timeframe, session, timezone) )` expression is not valid. Thus, I created this library to overcome this small but very important limitation. In the meantime, I added useful functionality to handle session-based behavior. An interesting utility that emerged from this development is data anomaly detection where a comparison between the prediction and the actual value is happening. If those two values are different then a data inconsistency happens between the prediction bar and the actual bar (probably due to a holiday or half session day etc..) exTimezone(timezone)   exTimezone - Convert extended timezone to timezone string   Parameters:      timezone (simple string) : - The timezone or a special string   Returns: string representing the timezone nameOfDay(day)   nameOfDay - Convert the day id into a short nameOfDay   Parameters:      day (int) : - The day id to convert   Returns: - The short name of the day today()   today - Get the day id of this day   Returns: - The day id nthDayAfter(day, n)   nthDayAfter - Get the day id of n days after the given day   Parameters:      day (int) : - The day id of the reference day      n (int) : - The number of days to go forward   Returns: - The day id of the day that is n days after the reference day nextDayAfter(day)   nextDayAfter - Get the day id of next day after the given day   Parameters:      day (int) : - The day id of the reference day   Returns: - The day id of the next day after the reference day nthDayBefore(day, n)   nthDayBefore - Get the day id of n days before the given day   Parameters:      day (int) : - The day id of the reference day      n (int) : - The number of days to go forward   Returns: - The day id of the day that is n days before the reference day prevDayBefore(day)   prevDayBefore - Get the day id of previous day before the given day   Parameters:      day (int) : - The day id of the reference day   Returns: - The day id of the previous day before the reference day tomorrow()   tomorrow - Get the day id of the next day   Returns: - The next day day id normalize(num, min, max)   normalizeHour - Check if number is inthe range of   Parameters:      num (int)      min (int)      max (int)   Returns: - The normalized number normalizeHour(hourInDay)   normalizeHour - Check if hour is valid and return a noralized hour range from   Parameters:      hourInDay (int)   Returns: - The normalized hour normalizeMinute(minuteInHour)   normalizeMinute - Check if minute is valid and return a noralized minute from   Parameters:      minuteInHour (int)   Returns: - The normalized minute monthInMilliseconds(mon)   monthInMilliseconds - Calculate the miliseconds in one bar of the timeframe   Parameters:      mon (int) : - The month of reference to get the miliseconds   Returns: - The number of milliseconds of the month barInMilliseconds()   barInMilliseconds - Calculate the miliseconds in one bar of the timeframe   Returns: - The number of milliseconds in one bar method init(this, fromDateTime, toDateTime)   init - Initialize the time window object from boolean values of each session day   Namespace types: DateTimeWindow   Parameters:      this (DateTimeWindow) : - The time window object that will hold the from and to datetimes      fromDateTime (int) : - The starting datetime of the time window      toDateTime (int) : - The ending datetime of the time window   Returns: - The time window object method init(this, refTimezone, chTimezone, fromDateTime, toDateTime)   init - Initialize the time window object from boolean values of each session day   Namespace types: DateTimeWindow   Parameters:      this (DateTimeWindow) : - The time window object that will hold the from and to datetimes      refTimezone (simple string) : - The timezone of reference of the 'from' and 'to' dates      chTimezone (simple string) : - The target timezone to convert the 'from' and 'to' dates      fromDateTime (int) : - The starting datetime of the time window      toDateTime (int) : - The ending datetime of the time window   Returns: - The time window object method init(this, sun, mon, tue, wed, thu, fri, sat)   init - Initialize the session days object from boolean values of each session day   Namespace types: SessionDays   Parameters:      this (SessionDays) : - The session days object that will hold the day selection      sun (bool) : - Is Sunday a trading day?      mon (bool) : - Is Monday a trading day?      tue (bool) : - Is Tuesday a trading day?      wed (bool) : - Is Wednesday a trading day?      thu (bool) : - Is Thursday a trading day?      fri (bool) : - Is Friday a trading day?      sat (bool) : - Is Saturday a trading day?   Returns: - The session days objectfrom_chart method init(this, unixTime)   init - Initialize the object from the hour and minute of the session time in exchange timezone (syminfo.timezone)   Namespace types: SessionTime   Parameters:      this (SessionTime) : - The session time object with the hour and minute of the time of the day      unixTime (int) : - The unix time   Returns: - The session time object method init(this, hourInDay, minuteInHour)   init - Initialize the object from the hour and minute of the session time in exchange timezone (syminfo.timezone)   Namespace types: SessionTime   Parameters:      this (SessionTime) : - The session time object with the hour and minute of the time of the day      hourInDay (int) : - The hour of the time      minuteInHour (int) : - The minute of the time   Returns: - The session time object method init(this, hourInDay, minuteInHour, refTimezone)   init - Initialize the object from the hour and minute of the session time   Namespace types: SessionTime   Parameters:      this (SessionTime) : - The session time object with the hour and minute of the time of the day      hourInDay (int) : - The hour of the time      minuteInHour (int) : - The minute of the time      refTimezone (string) : - The timezone of reference of the 'hour' and 'minute'   Returns: - The session time object method init(this, startTime, endTime)   init - Initialize the object from the start and end session time in exchange timezone (syminfo.timezone)   Namespace types: SessionTimeRange   Parameters:      this (SessionTimeRange) : - The session time range object that will hold the start and end time of the daily session      startTime (SessionTime) : - The time the session begins      endTime (SessionTime) : - The time the session ends   Returns: - The session time range object method init(this, startTimeHour, startTimeMinute, endTimeHour, endTimeMinute, refTimezone)   init - Initialize the object from the start and end session time   Namespace types: SessionTimeRange   Parameters:      this (SessionTimeRange) : - The session time range object that will hold the start and end time of the daily session      startTimeHour (int) : - The time hour the session begins      startTimeMinute (int) : - The time minute the session begins      endTimeHour (int) : - The time hour the session ends      endTimeMinute (int) : - The time minute the session ends      refTimezone (string)   Returns: - The session time range object method init(this, days, timeRanges)   init - Initialize the user session object from session days and time range   Namespace types: UserSession   Parameters:      this (UserSession) : - The user-defined session object that will hold the day and the time range selection      days (SessionDays) : - The session days object that defines the days the session is happening      timeRanges (SessionTimeRange ) : - The array of all the session time ranges during a session day   Returns: - The user session object method to_string(this)   to_string - Formats the time window into a human-readable string   Namespace types: DateTimeWindow   Parameters:      this (DateTimeWindow) : - The time window object with the from and to datetimes   Returns: - The string of the time window method to_string(this)   to_string - Formats the session days into a human-readable string with short day names   Namespace types: SessionDays   Parameters:      this (SessionDays) : - The session days object with the day selection   Returns: - The string of the session day short names method to_string(this)   to_string - Formats the session time into a human-readable string   Namespace types: SessionTime   Parameters:      this (SessionTime) : - The session time object with the hour and minute of the time of the day   Returns: - The string of the session time method to_string(this)   to_string - Formats the session time into a human-readable string   Namespace types: SessionTimeRange   Parameters:      this (SessionTimeRange) : - The session time range object with the start and end time of the daily session   Returns: - The string of the session time method to_string(this)   to_string - Formats the user session into a human-readable string   Namespace types: UserSession   Parameters:      this (UserSession) : - The user-defined session object with the day and the time range selection   Returns: - The string of the user session method to_string(this)   to_string - Formats the bar into a human-readable string   Namespace types: Bar   Parameters:      this (Bar) : - The bar object with the open and close times   Returns: - The string of the bar times method to_string(this)   to_string - Formats the chart session into a human-readable string   Namespace types: ChartSession   Parameters:      this (ChartSession) : - The chart session object that contains the days and the time range shown in the chart   Returns: - The string of the chart session method get_size_in_secs(this)   get_size_in_secs - Count the seconds from start to end in the given timeframe   Namespace types: DateTimeWindow   Parameters:      this (DateTimeWindow) : - The time window object with the from and to datetimes   Returns: - The number of seconds inside the time widow for the given timeframe method get_size_in_secs(this)   get_size_in_secs - Calculate the seconds inside the session   Namespace types: SessionTimeRange   Parameters:      this (SessionTimeRange) : - The session time range object with the start and end time of the daily session   Returns: - The number of seconds inside the session method get_size_in_bars(this)   get_size_in_bars - Count the bars from start to end in the given timeframe   Namespace types: DateTimeWindow   Parameters:      this (DateTimeWindow) : - The time window object with the from and to datetimes   Returns: - The number of bars inside the time widow for the given timeframe method get_size_in_bars(this)   get_size_in_bars - Calculate the bars inside the session   Namespace types: SessionTimeRange   Parameters:      this (SessionTimeRange) : - The session time range object with the start and end time of the daily session   Returns: - The number of bars inside the session for the given timeframe method from_chart(this)   from_chart - Initialize the session days object from the chart   Namespace types: SessionDays   Parameters:      this (SessionDays) : - The session days object that will hold the day selection   Returns: - The user session object method from_chart(this)   from_chart - Initialize the session time range object from the chart   Namespace types: SessionTimeRange   Parameters:      this (SessionTimeRange) : - The session time range object that will hold the start and end time of the daily session   Returns: - The session time range object method from_chart(this)   from_chart - Initialize the session object from the chart   Namespace types: ChartSession   Parameters:      this (ChartSession) : - The chart session object that will hold the days and the time range shown in the chart   Returns: - The chart session object method to_sess_string(this)   to_sess_string - Formats the session days into a session string with day ids   Namespace types: SessionDays   Parameters:      this (SessionDays) : - The session days object   Returns: - The string of the session day ids method to_sess_string(this)   to_sess_string - Formats the session time into a session string   Namespace types: SessionTime   Parameters:      this (SessionTime) : - The session time object with the hour and minute of the time of the day   Returns: - The string of the session time method to_sess_string(this)   to_sess_string - Formats the session time into a session string   Namespace types: SessionTimeRange   Parameters:      this (SessionTimeRange) : - The session time range object with the start and end time of the daily session   Returns: - The string of the session time method to_sess_string(this)   to_sess_string - Formats the user session into a session string   Namespace types: UserSession   Parameters:      this (UserSession) : - The user-defined session object with the day and the time range selection   Returns: - The string of the user session method to_sess_string(this)   to_sess_string - Formats the chart session into a session string   Namespace types: ChartSession   Parameters:      this (ChartSession) : - The chart session object that contains the days and the time range shown in the chart   Returns: - The string of the chart session method from_sess_string(this, sess)   from_sess_string - Initialize the session days object from the session string   Namespace types: SessionDays   Parameters:      this (SessionDays) : - The session days object that will hold the day selection      sess (string) : - The session string part that represents the days   Returns: - The session days object method from_sess_string(this, sess)   from_sess_string - Initialize the session time object from the session string in exchange timezone (syminfo.timezone)   Namespace types: SessionTime   Parameters:      this (SessionTime) : - The session time object that will hold the hour and minute of the time      sess (string) : - The session string part that represents the time HHmm   Returns: - The session time object method from_sess_string(this, sess, refTimezone)   from_sess_string - Initialize the session time object from the session string   Namespace types: SessionTime   Parameters:      this (SessionTime) : - The session time object that will hold the hour and minute of the time      sess (string) : - The session string part that represents the time HHmm      refTimezone (simple string) : - The timezone of reference of the 'hour' and 'minute'   Returns: - The session time object method from_sess_string(this, sess)   from_sess_string - Initialize the session time range object from the session string in exchange timezone (syminfo.timezone)   Namespace types: SessionTimeRange   Parameters:      this (SessionTimeRange) : - The session time range object that will hold the start and end time of the daily session      sess (string) : - The session string part that represents the time range HHmm-HHmm   Returns: - The session time range object method from_sess_string(this, sess, refTimezone)   from_sess_string - Initialize the session time range object from the session string   Namespace types: SessionTimeRange   Parameters:      this (SessionTimeRange) : - The session time range object that will hold the start and end time of the daily session      sess (string) : - The session string part that represents the time range HHmm-HHmm      refTimezone (simple string) : - The timezone of reference of the time ranges   Returns: - The session time range object method from_sess_string(this, sess)   from_sess_string - Initialize the user session object from the session string in exchange timezone (syminfo.timezone)   Namespace types: UserSession   Parameters:      this (UserSession) : - The user-defined session object that will hold the day and the time range selection      sess (string) : - The session string that represents the user session HHmm-HHmm,HHmm-HHmm:ddddddd   Returns: - The session time range object method from_sess_string(this, sess, refTimezone)   from_sess_string - Initialize the user session object from the session string   Namespace types: UserSession   Parameters:      this (UserSession) : - The user-defined session object that will hold the day and the time range selection      sess (string) : - The session string that represents the user session HHmm-HHmm,HHmm-HHmm:ddddddd      refTimezone (simple string) : - The timezone of reference of the time ranges   Returns: - The session time range object method nth_day_after(this, day, n)   nth_day_after - The nth day after the given day that is a session day (true) in the object   Namespace types: SessionDays   Parameters:      this (SessionDays) : - The session days object with the day selection      day (int) : - The day id of the reference day      n (int) : - The number of days after   Returns: - The day id of the nth session day of the week after the given day method nth_day_before(this, day, n)   nth_day_before - The nth day before the given day that is a session day (true) in the object   Namespace types: SessionDays   Parameters:      this (SessionDays) : - The session days object with the day selection      day (int) : - The day id of the reference day      n (int) : - The number of days after   Returns: - The day id of the nth session day of the week before the given day method next_day(this)   next_day - The next day that is a session day (true) in the object   Namespace types: SessionDays   Parameters:      this (SessionDays) : - The session days object with the day selection   Returns: - The day id of the next session day of the week method previous_day(this)   previous_day - The previous day that is session day (true) in the object   Namespace types: SessionDays   Parameters:      this (SessionDays) : - The session days object with the day selection   Returns: - The day id of the previous session day of the week method get_sec_in_day(this)   get_sec_in_day - Count the seconds since the start of the day this session time represents   Namespace types: SessionTime   Parameters:      this (SessionTime) : - The session time object with the hour and minute of the time of the day   Returns: - The number of seconds passed from the start of the day until that session time method get_ms_in_day(this)   get_ms_in_day - Count the milliseconds since the start of the day this session time represents   Namespace types: SessionTime   Parameters:      this (SessionTime) : - The session time object with the hour and minute of the time of the day   Returns: - The number of milliseconds passed from the start of the day until that session time method eq(this, other)   eq - Compare two bars   Namespace types: Bar   Parameters:      this (Bar) : - The bar object with the open and close times      other (Bar) : - The bar object to compare with   Returns: - Whether this bar is equal to the other one method get_open_time(this)   get_open_time - The open time object   Namespace types: Bar   Parameters:      this (Bar) : - The bar object with the open and close times   Returns: - The open time object method get_close_time(this)   get_close_time - The close time object   Namespace types: Bar   Parameters:      this (Bar) : - The bar object with the open and close times   Returns: - The close time object method get_time_range(this)   get_time_range - Get the time range of the bar   Namespace types: Bar   Parameters:      this (Bar) : - The bar object with the open and close times   Returns: - The time range that the bar is in getBarNow()   getBarNow - Get the current bar object with time and time_close timestamps   Returns: - The current bar getFixedBarNow()   getFixedBarNow - Get the current bar with fixed width defined by the timeframe. Note: There are case like SPX 15min timeframe where the last session bar is only 10min. This will return a bar of 15 minutes   Returns: - The current bar method is_in_window(this, win)   is_in_window - Check if the given bar is between the start and end dates of the window   Namespace types: Bar   Parameters:      this (Bar) : - The bar to check if it is between the from and to datetimes of the window      win (DateTimeWindow) : - The time window object with the from and to datetimes   Returns: - Whether the current bar is inside the datetime window method is_in_timerange(this, rng)   is_in_timerange - Check if the given bar is inside the session time range   Namespace types: Bar   Parameters:      this (Bar) : - The bar to check if it is between the from and to datetimes      rng (SessionTimeRange) : - The session time range object with the start and end time of the daily session   Returns: - Whether the bar is inside the session time range and if this part of the next trading day method is_in_days(this, days)   is_in_days - Check if the given bar is inside the session days   Namespace types: Bar   Parameters:      this (Bar) : - The bar to check if its day is a trading day      days (SessionDays) : - The session days object with the day selection   Returns: - Whether the current bar day is inside the session method is_in_session(this, sess)   is_in_session - Check if the given bar is inside the session as defined by the input params (what "not na(time(timeframe.period, this.to_sess_string()) )" should return if you could write it   Namespace types: Bar   Parameters:      this (Bar) : - The bar to check if it is between the from and to datetimes      sess (UserSession) : - The user-defined session object with the day and the time range selection   Returns: - Whether the current time is inside the session method next_bar(this, offsetBars)   next_bar - Predicts the next bars open and close time based on the charts session   Namespace types: ChartSession   Parameters:      this (ChartSession) : - The chart session object that contains the days and the time range shown in the chart      offsetBars (simple int) : - The number of bars forward   Returns: - Whether the current time is inside the session DateTimeWindow   DateTimeWindow - Object that represents a datetime window with a beginning and an end   Fields:      fromDateTime (series int) : - The beginning of the datetime window      toDateTime (series int) : - The end of the datetime window SessionDays   SessionDays - Object that represent the trading days of the week   Fields:      days (map) : - The map that contains all days of the week and their session flag SessionTime   SessionTime - Object that represents the time (hour and minutes)   Fields:      hourInDay (series int) : - The hour of the day that ranges from 0 to 24      minuteInHour (series int) : - The minute of the hour that ranges from 0 to 59      minuteInDay (series int) : - The minute of the day that ranges from 0 to 1440. They will be calculated based on hourInDay and minuteInHour when method is called SessionTimeRange   SessionTimeRange - Object that represents a range that extends from the start to the end time   Fields:      startTime (SessionTime) : - The beginning of the time range      endTime (SessionTime) : - The end of the time range      isOvernight (series bool) : - Whether or not this is an overnight time range UserSession   UserSession - Object that represents a user-defined session   Fields:      days (SessionDays) : - The map of the user-defined trading days      timeRanges (SessionTimeRange ) : - The array with all time ranges of the user-defined session during the trading days Bar   Bar - Object that represents the bars' open and close times   Fields:      openUnixTime (series int) : - The open time of the bar      closeUnixTime (series int) : - The close time of the bar      chartDayOfWeek (series int) ChartSession   ChartSession - Object that represents the default session that is shown in the chart   Fields:      days (SessionDays) : - A map with the trading days shown in the chart      timeRange (SessionTimeRange) : - The time range of the session during a trading day      isFinalized (series bool)
Pine Script® kütüphanesi
thetradingbot tarafından