Şimdi başlat

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

ForecastForecast (FC), indicator documentation Type: Study, not a strategy Primary timeframe: 1D chart, most plots and the on-chart table only render on daily bars Inspiration: Robert Carver’s “forecast” concept from Advanced Futures Trading Strategies, using normalized, capped signals for comparability across markets ⸻ What the indicator does FC builds a volatility-normalized momentum forecast for a chosen symbol, optionally versus a benchmark. It combines an EWMAC composite with a channel breakout composite, then caps the result to a common scale. You can run it in three data modes: • Absolute: Forecast of the selected symbol • Relative: Forecast of the ratio symbol / benchmark • Combined: Average of Absolute and Relative A compact table can summarize the current forecast, short-term direction on the forecast EMAs, correlation versus the benchmark, and ATR-scaled distances to common price EMAs. ⸻ PineScreener, relative-strength screening This indicator is excellent for screening on relative strength in PineScreener, since the forecast is volatility-normalized and capped on a common scale. Available PineScreener columns PineScreener reads the plotted series. You will see at least these columns: • FC, the capped forecast • from EMA20, (price − EMA20) / ATR in ATR multiples • from EMA50, (price − EMA50) / ATR in ATR multiples • ATR, ATR as a percent of price • Corr, weekly correlation with the chosen benchmark Relative mode and Combined mode are recommended for cross-sectional screens. In Relative mode the calculation uses symbol / benchmark, so ensure the ratio ticker exists for your data source. ⸻ How it works, step by step 1. Volatility model Compute exponentially weighted mean and variance of daily percent returns on D, annualize, optionally blend with a long lookback using 10y %, then convert to a price-scaled sigma. 2. EWMAC momentum, three legs Daily legs: EMA(8) − EMA(32), EMA(16) − EMA(64), EMA(32) − EMA(128). Divide by price-scaled sigma, multiply by leg scalars, cap to Cap = 20, average, then apply a small FDM factor. 3. Breakout momentum, three channels Smoothed position inside 40, 80, and 160 day channels, each scaled, then averaged. 4. Composite forecast Average the EWMAC composite and the breakout composite, then cap to ±20. Relative mode runs the same logic on symbol / benchmark. Combined mode averages Absolute and Relative composites. 5. Weekly correlation Pearson correlation between weekly closes of the asset and the benchmark over a user-set length. 6. Direction overlay Two EMAs on the forecast series plus optional green or red background by sign, and optional horizontal level shading around 0, ±5, ±10, ±15, ±20. ⸻ Plots • FC, capped forecast on the daily chart • 8-32 Abs, 8-32 Rel, single-leg EWMAC plus breakout view • 8-32-128 Abs, 8-32-128 Rel, three-leg composite views • from EMA20, from EMA50, (price − EMA) / ATR • ATR, ATR as a percent of price • Corr, weekly correlation with the benchmark • Forecast EMA1 and EMA2, EMAs of the forecast with an optional fill • Backgrounds and guide lines, optional sign-based background, optional 0, ±5, ±10, ±15, ±20 guides Most plots and the table are gated by timeframe.isdaily. Set the chart to 1D to see them. ⸻ Inputs Symbol selection • Absolute, Relative, Combined • Vs. benchmark for Relative mode and correlation, choices: SPY, QQQ, XLE, GLD • Ticker or Freeform, for Freeform use full TradingView notation, for example NASDAQ:AAPL Engine selection • Include: • 8-32-128, three EWMAC legs plus three breakouts • 8-32, simplified view based on the 8-32 leg plus a 40-day breakout EMA, applied to the forecast • EMA1, EMA2, with line-width controls, plus color and opacity Volatility • Span, EW volatility span for daily returns • 10y %, blend of long-run volatility • Thresh, Too volatile, placeholders in this version Background • Horizontal bg, level shading, enabled by default • Long BG, Hedge BG, colors and opacities Show • Table, Header, Direction, Gain, Extension • Corr, Length for correlation row Table settings • Position, background, opacity, text size, text color Lines • 0-lines, 10-lines, 5-lines, level guides ⸻ Reading the outputs • Forecast > 0, bullish tilt; Forecast < 0, bearish or hedge tilt • ±10 and ±20 indicate strength on a uniform scale • EMA1 vs EMA2 on the forecast, EMA1 above EMA2 suggests improving momentum • Table rows, label colored by sign, current forecast value plus a green or red dot for the forecast EMA cross, optional daily return percent, weekly correlation, and ATR-scaled EMA9, EMA20, EMA50 distances ⸻ Data handling, repainting, and performance • Daily and weekly series are fetched with request.security(). • Calculations use closed bars, values can update until the bar closes. • No lookahead, historical values do not repaint. • Weekly correlation updates during the week, it finalizes on weekly close. • On intraday charts most visuals are hidden by design. ⸻ Good practice and limitations • This is a research indicator, not a trading system. • The fixed Cap = 20 keeps a common scale, extreme moves will be clipped. • Relative mode depends on the ratio symbol / benchmark, ensure both legs have data for your feed. ⸻ Credits Concept inspired by Robert Carver’s forecast methodology in Advanced Futures Trading Strategies. Implementation details, parameters, and visuals are specific to this script. ⸻ Changelog • First version ⸻ Disclaimer For education and research only, not financial advice. Always test on your market and data feed, consider costs and slippage before using any indicator in live decisions.
Pine Script® göstergesi
BB_9791 tarafından
FlowFusion Money Flow — FP + VWAP Drift + PVT (−100..+100)Title (ASCII only) FlowFusion Money Flow — Flow Pressure + Rolling VWAP Drift + PVT (Normalized −100..+100) Short Description Original money-flow oscillator combining Flow Pressure, Rolling VWAP Drift, and PVT Momentum into one normalized score (−100..+100) with a signal line, thresholds, optional component plots, and ready-made alerts. Full Description (meets “originality & usefulness”) What’s original FlowFusion Money Flow is not a generic mashup. It builds a single score from three complementary, volume-aware components that target different facets of order flow: Flow Pressure (FP) — In-bar directional drive scaled by relative volume. Drive = close − open max ⁡ ( high − low ,  tick ) ∈ = max(high−low, tick) close−open ​ ∈ . Relative Volume = volume average volume over  𝑓 𝑝 𝐿 𝑒 𝑛 = average volume over fpLen volume ​ . 𝐹 𝑃 𝑟 𝑎 𝑤 = Drive × RelVol FP raw ​ =Drive×RelVol then squashed (softsign) to . Why it belongs: distinguishes real pushes (big body and big volume) from noise. Rolling VWAP Drift — Direction of VWAP itself over a rolling window, normalized by ATR. 𝑉 𝑊 𝐴 𝑃 𝑡 = ∑ ( 𝑇 𝑃 × 𝑉 𝑜 𝑙 ) ∑ 𝑉 𝑜 𝑙 VWAP t ​ = ∑Vol ∑(TP×Vol) ​ over vwapLen. Drift = 𝑉 𝑊 𝐴 𝑃 𝑡 − 𝑉 𝑊 𝐴 𝑃 𝑡 − 1 𝐴 𝑇 𝑅 = ATR VWAP t ​ −VWAP t−1 ​ ​ → squashed to . Why it belongs: persistent VWAP movement signals sustained accumulation/distribution. PVT Momentum — Price-Volume Trend standardized (z-score) and squashed. 𝑃 𝑉 𝑇 𝑡 = 𝑃 𝑉 𝑇 𝑡 − 1 + 𝑉 𝑜 𝑙 × Δ 𝐶 𝑙 𝑜 𝑠 𝑒 𝐶 𝑙 𝑜 𝑠 𝑒 𝑡 − 1 PVT t ​ =PVT t−1 ​ +Vol× Close t−1 ​ ΔClose ​ . 𝑧 = 𝑃 𝑉 𝑇 − SMA ( 𝑃 𝑉 𝑇 ) StDev ( 𝑃 𝑉 𝑇 ) z= StDev(PVT) PVT−SMA(PVT) ​ → squashed to . Why it belongs: captures volume-weighted trend pressure without relying on price alone. Composite score: Score = 𝑤 𝐹 𝑃 ⋅ 𝐹 𝑃 + 𝑤 𝑉 𝑊 𝐴 𝑃 ⋅ 𝑉 𝑊 𝐴 𝑃 _ 𝐷 𝑟 𝑖 𝑓 𝑡 + 𝑤 𝑃 𝑉 𝑇 ⋅ 𝑃 𝑉 𝑇 _ 𝑀 𝑜 𝑚 𝑤 𝐹 𝑃 + 𝑤 𝑉 𝑊 𝐴 𝑃 + 𝑤 𝑃 𝑉 𝑇 Score= w FP ​ +w VWAP ​ +w PVT ​ w FP ​ ⋅FP+w VWAP ​ ⋅VWAP_Drift+w PVT ​ ⋅PVT_Mom ​ with a Signal = SMA(Score, sigLen). Thresholds mark strong accumulation/distribution zones. How it works (step-by-step) Compute FP, VWAP Drift, PVT Momentum. Normalize each to the same scale. Weighted average → FlowFusion Score. Smooth with a Signal line to reduce whipsaw. Optional background shading when Score exceeds thresholds. How to use Direction filter: Score > 0 favors longs; Score < 0 favors shorts. Momentum turns: Score crosses above Signal → setup for long; below → setup for short. Strength zones: Above Upper Threshold (default +40) = strong buy pressure; below Lower (−40) = strong sell pressure. Confluence: Best near S/R, trendlines, or HTF bias. For scalping on 1–5m, consider sigLen 9–13 and thresholds ±40 to ±50. Alerts included: zero cross, zone entries, and Score/Signal crossovers. Inputs (key) fpLen (20): relative-volume lookback for Flow Pressure. vwapLen (34): rolling VWAP window. pvtLen (50): PVT z-score window. sigLen (9): Signal smoothing. Weights: wFP, wVWAP, wPVT to bias the blend. Thresholds: upperBand / lowerBand (defaults +40/−40). Display: toggle component plots and background shading. Best practices Trending markets: increase wVWAP (VWAP Drift) or widen thresholds. Ranging markets: increase wFP and wPVT; take quicker profits. News: wait for bar close confirmation or reduce size. Data quality: use consistent volume feeds (especially in crypto). Limitations Oscillators can stay extreme in strong trends; use structure/trend filters. Volume anomalies (illiquid pairs, API glitches) can distort signals—sanity-check with another venue when possible. Disclaimer This indicator is for educational purposes only and is not financial advice. Trading involves risk; past performance does not guarantee future results. Always paper-trade first and use appropriate risk controls.
Pine Script® göstergesi
fts4sure tarafından
Session Liquidity & Sweep DetectorThe indicator is an advanced trading tool designed to give traders a complete visual and analytical overview of major market sessions. By tracking the Asia, London, and New York sessions, this indicator highlights session highs/lows, liquidity sweeps, and advanced A++ patterns to help identify high-probability trade setups. It combines session analysis, sweep detection, and pattern recognition into a single, customizable indicator. Traders can use it for spotting breakout points, reversal setups, and areas of stop hunts or liquidity grabs. Key Features: 1. Session Liquidity Boxes: Automatically draws boxes representing Asia, London, and NY trading sessions on the chart. Each session box is color-coded and fully customizable (colors, transparency, border width). Option to display only the most recent session box, reducing chart clutter. Helps traders visually separate trading sessions and understand session structure. 2. High/Low Sweep Detection: Detects when price sweeps the high or low of a completed session, indicating liquidity grabs or stop-hunting behavior. Labels are added to the chart for clear visualization: AHS: Asia High Swept ALS: Asia Low Swept LHS: London High Swept LLS: London Low Swept Horizontal lines are drawn at swept levels to track key support/resistance points. Sweep detection occurs only within the same trading day, preventing false signals. 3. A++ Pattern Detection: Detects advanced Long/Short A++ patterns based on session sweep behavior: Long A++ Pattern: Both Asia and London lows are swept, but highs remain intact. Short A++ Pattern: Both Asia and London highs are swept, but lows remain intact. Patterns are plotted with customizable labels to highlight potential high-probability setups. Helps traders identify early directional bias for the trading day. 4. Customizable Visual Settings: Box colors, sweep line colors, and label colors are fully customizable. Label sizes can be set to “auto”, “tiny”, “small”, “normal”, “large”, or “huge”. Sweep line width and box border width are adjustable. Clear visualization ensures traders can analyze sessions quickly and efficiently. 5. Multi-Session Tracking: Tracks Asia, London, and New York sessions independently. Keeps historical session data while dynamically updating the latest session in real-time. Allows traders to see inter-session liquidity interactions, which are key for breakout and reversal strategies. 6. Optimized for Real-Time Trading: Updates session highs/lows bar by bar during live trading. Works on any timeframe, making it suitable for scalping, intraday, and swing trading. Integrates seamlessly with other indicators like FU Candle Indicator, VWAP, Order Blocks, and more for advanced strategies. Use Cases: Liquidity Hunting: Spot where institutional traders may be triggering stop losses or grabbing liquidity. Breakout Analysis: Identify when price breaks through session highs/lows and confirm trade direction. Session Pattern Trading: Use A++ patterns to anticipate strong directional moves early in the trading day. Multi-Session Strategies: Analyze relationships between Asia, London, and NY sessions to find high-probability entries. Scalping & Day Trading: Visualize key levels for quick trade decisions. Ideal Users: Forex, crypto, and futures traders who want a session-based liquidity and sweep analysis. Traders who use high-probability patterns and breakout strategies. Scalpers, intraday traders, and swing traders looking for clear visual cues and actionable signals. Anyone seeking a comprehensive session overview for smarter trading decisions. This indicator essentially combines session boxes, liquidity sweep labels (AHS, ALS, LHS, LLS), horizontal lines for swept levels, and A++ pattern detection to give traders a full view of market structure, liquidity, and potential directional bias.
Pine Script® göstergesi
Quantel_io 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
61
Screener based on Profitunity strategy for multiple timeframes Screener based on Profitunity strategy by Bill Williams for multiple timeframes (max 5, including chart timeframe) and customizable symbol list. The screener analyzes the Alligator and Awesome Oscillator indicators, Divergent bars and high volume bars. The maximum allowed number of requests (symbols and timeframes) is limited to 40 requests, for example, for 10 symbols by 4 requests of different timeframes. Therefore, the indicator automatically limits the number of displayed symbols depending on the number of timeframes for each symbol, if there are more symbols than are displayed in the screener table, then the ordinal numbers are displayed to the left of the symbols, in this case you can display the next group of symbols by increasing the value by 1 in the "Show tickers from" field, if the "Group" field is enabled, or specify the symbol number by 1 more than the last symbol in the screener table. 👀 When timeframe filtering is applied, the screener table displays only the columns of those timeframes for which the filtering value is selected, which allows displaying more symbols. For each timeframe, in the "TIMEFRAMES > Prev" field, you can enable the display of data for the previous bar relative to the last (current) one, if the market is open for the requested symbol. In the "TIMEFRAMES > Y" field, you can enable filtering depending on the location of the last five bars relative to the Alligator indicator lines, which are designated by special symbols in the screener table: ⬆️ — if the Alligator is open upwards (Lips > Teeth > Jaw) and none of the bars is closed below the Lips line; ↗️ — if one of the bars, except for the penultimate one, is closed below Lips, or two bars, except for the last one, are closed below Lips, or the Alligator is open upwards only below four bars, but none of the bars is closed below Lips; ⬇️ — if the Alligator is open downwards (Lips < Teeth < Jaw), but none of the bars is closed above Lips; ↘️ — if one of the bars, except the penultimate one, is closed above the Lips, or two bars, except the last one, are closed above the Lips, or the Alligator is open down only above four bars, but none of the bars are closed above the Lips; ➡️ — in other cases, including when the Alligator lines intersect and one of the bars is closed behind the Lips line or two bars intersect one of the Alligator lines. In the "TIMEFRAMES > Show bar change value for TF" field, you can add a column to the right of the selected timeframe column with the percentage change between the closing price of the last bar (current) and the closing price of the previous bar ((close – previous close) / previous close * 100). Depending on the percentage value, the background color of the screener table cell will change: dark red if <= -3%; red if <= -2%, light red if <= -0.5%; dark green if >= 3%; green if >= 2%; light green if >= 0.5%. For each timeframe, the screener table displays the symbol of the latest (current) bar, depending on the closing price relative to the bar's midpoint ((high + low) / 2) and its location relative to the Alligator indicator lines: ⎾ — the bar's closing price is above its midpoint; ⎿ — the bar's closing price is below its midpoint; ├ — the bar's closing price is equal to its midpoint; 🟢 — Bullish Divergent bar, i.e. the bar's closing price is above its midpoint, the bar's high is below all Alligator lines, the bar's low is below the previous bar's low; 🔴 — Bearish Divergent bar, i.e. the bar's closing price is below its midpoint, the bar's low is above all Alligator lines, the bar's high is above the previous bar's high. When filtering is enabled in the "TIMEFRAMES > Filtering by Divergent bar" field, the data in the screener table cells will be displayed only for those timeframes that have a Divergent bar. A high bar volume signal is also displayed — 📶/📶² if the bar volume is greater than 40%/70% of the average volume value calculated using a simple moving average (SMA) in the 140 bar interval from the last bar. In the indicator settings in the "SYMBOL LIST" field, each ticker (for example: OANDA:SPX500USD) must be on a separate line. If the market is closed, then the data for requested symbols will be limited to the time of the last (current) bar on the chart, for example, if the current symbol was traded yesterday, and the requested symbol is traded today, when requesting data for an hourly timeframe, the last bar will be for yesterday, if the timeframe of the current chart is not higher than 1 day. Therefore, by default, a warning will be displayed on the chart instead of the screener table that if the market is open, you must wait for the screener to load (after the first price change on the current chart), or if the highest timeframe in the screener is 1 day, you will be prompted to change the timeframe on the current chart to 1 week, if the screener requests data for the timeframe of 1 week, you will be prompted to change the timeframe on the current chart to 1 month, or switch to another symbol on the current chart for which the market is open (for example: BINANCE:BTCUSDT), or disable the warning in the field "SYMBOL LIST > Do not display screener if market is close". The number of the last columns with the color of the AO indicator that will be displayed in the screener table for each timeframe is specified in the indicator settings in the "AWESOME OSCILLATOR > Number of columns" field. For each timeframe, the direction of the trend between the price of the highest and lowest bars in the specified range of bars from the last bar is displayed — ↑ if the trend is up (the highest bar is to the right of the lowest), or ↓ if the trend is down (the lowest bar is to the right of the highest). If there is a divergence on the AO indicator in the specified interval, the symbol ∇ is also displayed. The average volume value is also calculated in the specified interval using a simple moving average (SMA). The number of bars is set in the indicator settings in the "INTERVAL FOR HIGHEST AND LOWEST BARS > Bars count" field. In the indicator settings in the "STYLE" field you can change the position of the screener table relative to the chart window, the background color, the color and size of the text. *** Скринер на основе стратегии Profitunity Билла Вильямса для нескольких таймфреймов (максимум 5, включая таймфрейм графика) и настраиваемого списка символов. Скринер анализирует индикаторы Alligator и Awesome Oscillator, Дивергентные бары и бары с высоким объемом. Максимально допустимое количество запросов (символы и таймфреймы) ограничено 40 запросами, например, для 10 символов по 4 запроса разных таймфреймов. Поэтому в индикаторе автоматически ограничивается количество отображаемых символов в зависимости от количества таймфреймов для каждого символа, если символов больше чем отображено в таблице скринера, то слева от символов отображаются порядковые номера, в таком случае можно отобразить следующую группу символов, увеличив значение на 1 в настройках индикатора поле "Show tickers from", если включено поле "Group", или указать номер символа на 1 больше, чем последний символ в таблице скринера. 👀 Когда применяется фильтрация по таймфрейму, в таблице скринера отображаются только столбцы тех таймфреймов, для которых выбрано значение фильтрации, что позволяет отображать большее количество символов. Для каждого таймфрейма в настройках индикатора в поле "TIMEFRAMES > Prev" можно включить отображение данных для предыдущего бара относительно последнего (текущего), если для запрашиваемого символа рынок открыт. В поле "TIMEFRAMES > Y" можно включить фильтрацию, в зависимости от расположения последних пяти баров относительно линий индикатора Alligator, которые обозначаются специальными символами в таблице скринера: ⬆️ — если Alligator открыт вверх (Lips > Teeth > Jaw) и ни один из баров не закрыт ниже линии Lips; ↗️ — если один из баров, кроме предпоследнего, закрыт ниже Lips, или два бара, кроме последнего, закрыты ниже Lips, или Alligator открыт вверх только ниже четырех баров, но ни один из баров не закрыт ниже Lips; ⬇️ — если Alligator открыт вниз (Lips < Teeth < Jaw), но ни один из баров не закрыт выше Lips; ↘️ — если один из баров, кроме предпоследнего, закрыт выше Lips, или два бара, кроме последнего, закрыты выше Lips, или Alligator открыт вниз только выше четырех баров, но ни один из баров не закрыт выше Lips; ➡️ — в остальных случаях, в то числе когда линии Alligator пересекаются и один из баров закрыт за линией Lips или два бара пересекают одну из линий Alligator. В поле "TIMEFRAMES > Show bar change value for TF" можно добавить справа от выбранного столбца таймфрейма столбец с процентным изменением между ценой закрытия последнего бара (текущего) и ценой закрытия предыдущего бара ((close – previous close) / previous close * 100). В зависимости от величины процента будет меняться цвет фона ячейки таблицы скринера: темно-красный, если <= -3%; красный, если <= -2%, светло-красный, если <= -0.5%; темно-зеленый, если >= 3%; зеленый, если >= 2%; светло-зеленый, если >= 0.5%. Для каждого таймфрейма в таблице скринера отображается символ последнего (текущего) бара, в зависимости от цены закрытия относительно середины бара ((high + low) / 2) и расположения относительно линий индикатора Alligator: ⎾ — цена закрытия бара выше его середины; ⎿ — цена закрытия бара ниже его середины; ├ — цена закрытия бара равна его середине; 🟢 — Бычий Дивергентный бар, т.е. цена закрытия бара выше его середины, максимум бара ниже всех линий Alligator, минимум бара ниже минимума предыдущего бара; 🔴 — Медвежий Дивергентный бар, т.е. цена закрытия бара ниже его середины, минимум бара выше всех линий Alligator, максимум бара выше максимума предыдущего бара. При включении фильтрации в поле "TIMEFRAMES > Filtering by Divergent bar" данные в ячейках таблицы скринера будут отображаться только для тех таймфреймов, где есть Дивергентный бар. Также отображается сигнал высокого объема бара — 📶/📶², если объем бара больше чем на 40%/70% среднего значения объема, рассчитанного с помощью простой скользящей средней (SMA) в интервале 140 баров от последнего бара. В настройках индикатора в поле "SYMBOL LIST" каждый тикер (например: OANDA:SPX500USD) должен быть на отдельной строке. Если рынок закрыт, то данные для запрашиваемых символов будут ограничены временем последнего (текущего) бара на графике, например, если текущий символ торговался последний день вчера, а запрашиваемый символ торгуется сегодня, при запросе данных для часового таймфрейма, последний бар будет за вчерашний день, если таймфрейм текущего графика не выше 1 дня. Поэтому по умолчанию на графике будет отображаться предупреждение вместо таблицы скринера о том, что если рынок открыт, то необходимо дождаться загрузки скринера (после первого изменения цены на текущем графике), или если в скринере самый высокий таймфрейм 1 день, то будет предложено изменить на текущем графике таймфрейм на 1 неделю, если в скринере запрашиваются данные для таймфрейма 1 неделя, то будет предложено изменить на текущем графике таймфрейм на 1 месяц, или же переключиться на другой символ на текущем графике, для которого рынок открыт (например: BINANCE:BTCUSDT), или отключить предупреждение в поле "SYMBOL LIST > Do not display screener if market is close". Количество последних столбцов с цветом индикатора AO, которые будут отображены в таблице скринера для каждого таймфрейма, указывается в настройках индикатора в поле "AWESOME OSCILLATOR > Number of columns". Для каждого таймфрейма отображается направление тренда между ценой самого высокого и самого низкого баров в указанном интервале баров от последнего бара — ↑, если тренд направлен вверх (самый высокий бар справа от самого низкого), или ↓, если тренд направлен вниз (самый низкий бар справа от самого высокого). Если есть дивергенция на индикаторе AO в указанном интервале, то также отображается символ — ∇. В указанном интервале также рассчитывается среднее значение объема с помощью простой скользящей средней (SMA). Количество баров устанавливается в настройках индикатора в поле "INTERVAL FOR HIGHEST AND LOWEST BARS > Bars count". В настройках индикатора в поле "STYLE" можно изменить положение таблицы скринера относительно окна графика, цвет фона, цвет и размер текста.
Pine Script® göstergesi
grigorykov tarafından
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
Uptrick: Oscillator SpectrumUptrick: Oscillator Spectrum is a versatile trading tool designed to bring together multiple aspects of technical analysis—oscillators, momentum signals, divergence checks, correlation insights, and more—into one script. It includes customizable overlays and alert conditions intended to address a wide range of market conditions and trading styles. Developed in Pine Script™, Uptrick: Oscillator Spectrum represents an extended version of the classic Ultimate Oscillator concept. It consolidates short-, medium-, and long-term momentum readings, applies correlation analysis across different symbols, and offers optional table-based metrics to provide traders with a more structured overview of potential trade setups. Whether used alongside your existing charts or as a standalone toolkit, it aims to build on and enhance the functionality of the standard Ultimate Oscillator. ### A Few Key Features - Momentum Insights: Multiple timeframes for oscillators, plus buy/sell signal modes for flexible identification of overbought/oversold situations or crossovers. - Divergence Detection: Automated checks for bullish/bearish divergences, aiming to help traders spot potential shifts in momentum. - Correlation Meter: A visual histogram summarizing how selected assets are collectively trending. It is useful for tracking the bigger market picture. - Gradient Overlays & Bar Coloring: Dynamic color transitions designed to emphasize changes in momentum, trend shifts, and overall sentiment without cluttering the chart. - Money Flow Tracker: Tracks the flow of money into and out of the market using a smoothed Money Flow Index (MFI). Highlights overbought/oversold conditions with dynamic bar coloring and visual gradient fills, helping traders assess volume-driven sentiment shifts. - Advanced Table Metrics: An optional table showing return on investment (ROI), collateral risk, and other contextual metrics for supported assets. - Alerts & Automation: Configurable alerts covering divergence events, crossing of critical levels, and more, helping to keep traders informed of developments in real time. ### Intended Usage - For Multiple Markets: Works on various markets (cryptocurrencies, forex pairs, stocks) to deliver a consistent view of momentum, potential entry/exit signals, and correlation. - Adaptable Trading Styles: With customizable input settings, you can enable or disable specific features to align with your preferred strategies—intraday scalping, swing trading, or position holding. By combining these elements under one indicator, Uptrick: Oscillator Spectrum allows traders to streamline analysis workflows, helping them stay focused on interpreting market moves and making informed decisions rather than juggling multiple scripts. Purpose Purpose of the “Uptrick: Oscillator Spectrum” Indicator The “Uptrick: Oscillator Spectrum” indicator is intended to bring together several technical analysis elements into one tool. It combines oscillator-based momentum readings across different lookback periods, checks for potential divergences, provides optional buy/sell signal triggers, and offers correlation-based insights across multiple symbols. Additionally, it includes features such as bar coloring, gradient visualization, and user-configurable alerts to help highlight various market conditions. By consolidating these functions, the script aims to help users systematically observe changing momentum, identify when prices reach user-defined overbought or oversold levels, detect when oscillator movements diverge from price, and examine whether different assets are aligning or diverging in their trends. The indicator also allows for optional advanced metric tables, which can supply further context on risk, ROI calculations, or other factors for supported assets. Overall, the script’s purpose is to organize multiple layers of technical analysis so that users have a structured way to evaluate potential trade opportunities and market behavior. ## Usage Guide Below is an outline of how you can utilize the various components and features of Uptrick: Oscillator Spectrum in your charting workflow. --- ### 1. Using the Core Oscillator - Basic View: By default, the script calculates a multi-timeframe oscillator (commonly displayed as the “Ultimate Oscillator”). This oscillator combines short-, medium-, and long-term measurements of buying pressure and true range. - Overbought/Oversold Zones: You can configure thresholds (e.g., 70 for overbought, 30 for oversold) to help identify potential turning points. When the oscillator crosses these levels, it may indicate that price is extended in one direction. - You can use the colors of the main oscillator to help you take short-term trades as well: cyan : Buy , red: Sell - Alerts: If you enable alerts, the indicator can notify you when the oscillator crosses above or below your chosen overbought/oversold boundaries or when you get buy/sell signals. --- ### 2. Buy/Sell Signals in Overlay Modes Uptrick: Oscillator Spectrum provides several signal modes and a choice between overlay true and overlay false or both. Additionally, you can pick which “line” (data source) the script uses to generate signals. This is set in the “Line to Analyze” dropdown, which includes Oscillator, HMA of Oscillator, and Moving Average. The following sections describe how each piece fits together. --- #### Line to Analyze - Overlay Flase: Oscillator / HMA of Oscillator / Moving Average 1. Oscillator - The core momentum reading, reflecting short-, medium-, and long-term periods combined. 2. HMA of Oscillator - Applies a Hull Moving Average to the oscillator, creating a smoother but still responsive curve. - Signals will be derived from this smoothed line. Some traders find it filters out minor fluctuations while remaining quicker to react than standard averages. 3. Moving Average - Uses a user-selected MA type (SMA, EMA, WMA, etc.) over the oscillator values, rather than the raw oscillator itself. - Tends to be more stable than the raw oscillator, but might delay signals more depending on the chosen MA settings. --- #### Signal Modes Regardless of which line you choose to analyze, you can use one of the following seven signal modes in overlay being true: 1. Overbought/Oversold (Pyramiding) - What It Does: - Buy signal when the chosen line crosses below the oversold threshold. - Sell signal when it crosses above the overbought threshold. - Pyramiding: - Allows multiple triggers within the same overbought/oversold event. 2. Overbought/Oversold (Non Pyramiding) - What It Does: - Same thresholds but only one signal per oversold or overbought event. - Use Case: - Prevents repeated signals and chart clutter. 3. Smoothed MA Middle Crossover - What It Does: - Uses an MA defined by the user. - Buy when crossing above the midpoint (50), Sell when crossing below. - Use Case: - Generates fewer signals, focusing on broader momentum shifts. There is no pyramiding. In this image ,for example, the VWMA is used with length of 14 to identify buy sell signals. 4. Crossing Above Overbought/Below Oversold (Non Pyramiding) - What It Does: - Buy occurs if the line exits oversold territory by crossing back above it. - Sell occurs if the line exits overbought territory by crossing back below it. - Non Pyramiding: - Restricts repeated signals until conditions reset. 5. Crossing Above Overbought/Below Oversold (Pyramiding) - What It Does: - Same thresholds, but allows multiple signals if the line repeatedly dips in and out of overbought or oversold. - Use Case: - More frequent entries/exits for active traders. 6. Divergence (Non Pyramiding) - What It Does: - Identifies bullish or bearish divergences using the chosen line vs. price. - Buy for bullish divergence (higher low on the line vs. lower low on price), Sell for bearish divergence. - Single Trigger: - Only one signal per identified divergence event. (non pyramiding) 7. Divergence (Pyramiding) - What It Does: - Same divergence logic but triggers multiple times if the script sees repeated divergence in the same direction. - Use Case: - Could suit traders who layer positions during sustained divergence scenarios. #### Overlay Modes: True vs. False 1. Overlay True - Buy/sell arrows or labels plot directly on the main price chart, often at or near candlesticks. - Bar Coloring: - Can turn the candlestick bars green (buy) or red (sell), with intensity reflecting signal recency if bar coloring is enabled for this mode. (read below.) - Advantage: - Everything (price, signals, bar colors) is in one spot, making it straightforward to associate signals with current market action. You can adjust the periods of the main oscillator or lookback periods of divergences or overbought/oversold thresholds, to play around with your signals. 2. Overlay False - Signal Placement: - Signals appear in a sub-window or oscillator panel, leaving the main price chart uncluttered. - Bar Coloring: - You may still enable bar colors on the main chart (green for buy, red for sell) if desired. - Alternatively, you can keep them neutral if you prefer a completely separate display of signals. - Advantage: - Clear separation of price action from signals, useful for cleaner charts or if using multiple overlay-based tools. At the bottom are the signals for overlay being false and on the chart are the signals for overlay being true: #### Bar Color Adjustments 1. Coloring Logic - Bars typically go green on buy signals, red on sell signals. - The opacity or brightness can vary to indicate signal freshness. When a new signal is formed, the color gets brighter. When there is no signal for a longer period of time, then the color slowly fades. 2. Enabling Bar Coloring - In the indicator’s settings, turn on Bar Coloring. - Choose “Signals Overlay True” or “Signals Overlay False” from the “Color should depend on:” dropdown, depending on which overlay approach you want to drive your bar colors. You can also chose the cloud fill in overlay false, correlation meter and smoothed HMA to color bars. Read more below: ### Bar Color Options: When you enable bar coloring in Uptrick: Oscillator Spectrum, you can select which component or signal logic drives the color changes. Below are the five available choices: --- #### Option 1: Overlay True Signals - What It Does: - Uses signals generated under the Overlay True mode to color the bars on your main chart. - If a buy signal is triggered, bars turn green. If a sell signal occurs, bars turn red. - Color Intensity: - Bars appear brighter (more opaque) immediately after a new signal fires, then gradually fade over subsequent bars if no new signal appears. --- #### Option 2: Overlay False Signals - What It Does: - Links bar coloring to signals generated when Overlay False mode is active. - Buy/sell labels typically plot in a separate sub-window instead of the main chart, but your price bars can still change color based on these signals. - Color Intensity: - Similar to Overlay True, new buy/sell signals yield stronger color intensity, which fades over time. - Use Case: - Helps maintain a clean main chart (with signals off-chart) while still providing an immediate color-coded indication of a buy or sell state. - Particularly useful if you prefer less clutter from signal markers on your price chart yet still want a visual representation of signal timing. In this example normal divergence Pyramiding Signals are used in the overlay being true and the signals in overlay false are signals that analyze the HMA. This can help clear out noise (using a combo of both). Option 3: Money Flow Tracker What It Does: The Money Flow Tracker uses the Money Flow Index (MFI), a volume-weighted oscillator, to measure the strength of money flowing into or out of an asset. The script smooths the raw MFI data using an EMA for a more responsive and visually intuitive output. The feature also includes dynamic color gradients and bar coloring that highlight whether money flow is positive or negative. Green Fill/Bar Color: Indicates positive money flow, suggesting potential accumulation. Red Fill/Bar Color: Indicates negative money flow, signaling potential distribution. Overbought and oversold thresholds are dynamically emphasized with transparency, making it easier to identify high-confidence zones. Use Case: Ideal for traders focusing on volume-driven sentiment to identify turning points or confirm existing trends. Suitable for assessing broader market conditions when used alongside other indicators like oscillators or correlation analysis. Provides additional clarity in spotting areas of accumulation or distribution, making it a valuable complement to price action and momentum studies. --- #### Option 4: Correlation Meter - What It Does: - Colors the bars based on the indicator’s Correlation Meter output. The script checks multiple chosen tickers and sums up how many are trending positively or negatively. - If the meter indicates an overall bullish bias (e.g., more than three assets in uptrend), bars turn green; if it’s bearish, bars turn red. - Trend Readings: - The correlation meter typically plots a histogram of bullish/neutral/bearish states. The bar color option links your chart’s candlestick coloring to that higher-level market sentiment. - Use Case: - Useful for traders wanting a quick visual prompt of whether the broader market (or a selection of related assets) is bullish or bearish at any given time. - Helps avoid signals that conflict with the market majority. #### Option 5: Smoothed HMA - What It Does: - Bar colors are driven by the slope or state of the Hull Moving Average (HMA) of the oscillator, rather than individual buy/sell triggers or correlation data. - If the HMA indicates a strong upward slope (possibly darkening), bars may turn green; if the slope is downward (purple in the HMA line), bars turn red. - Use Case: - Ideal for those who focus on momentum continuity rather than discrete signals like overbought/oversold or divergence. - May help identify smoother, more sustained moves, as the HMA filters out minor oscillations. --- ### 3. Using the Hull Moving Average (HMA) of the Oscillator - HMA Calculation: You can enable a dedicated Hull Moving Average (HMA) for the oscillator. This creates a smoother line of the same underlying momentum reading, typically responding more quickly than classic moving averages. - Color Intensity: As the HMA sustains an uptrend or downtrend, the script can adjust the line’s color. When slope momentum persists in one direction, the color appears more opaque. This intensification can hint that the existing direction may be well-established. - Reversal Potential: If you observe the HMA color shifting or darkening after multiple bars of slope in the same direction, it may indicate increasing momentum. Conversely, a sudden flattening or change in color can be a clue that momentum is waning. --- ### 4. Moving Average Overlays & Gradient Cloud - Oscillator MA: The script allows you to apply moving average types (SMA, EMA, SMMA, WMA, or VWMA) to the core oscillator, rather than to price. This can smooth out noise in the oscillator, potentially highlighting more consistent momentum shifts. - Gradient Cloud: You can also enable a cloud in overlay true between two moving averages (for instance, a Hull MA and a Double EMA) on the price chart. The cloud fills with different colors, depending on which MA is above the other. This can provide a quick visual reference to bullish or bearish areas. --- ### 5. Divergence Detection - Bullish & Bearish Divergence: By toggling “Calculate Divergence,” the script looks for oscillator pivots that contrast with price pivots (e.g., price making a lower low while the oscillator makes a higher low). - A divergence is when the price makes an opposite pivot to the indicator value. E.g. Price makes lower low but indicator does higher low - This suggests a bullish divergence. THe opposite is for a bearish divergence. - Visual Labels: When a divergence is found, labels (such as “Bull” or “Bear”) appear on the oscillator. This helps you see if the oscillator’s momentum patterns differ from the price movement. - Filtering Signals: You can combine divergence signals with other features like overbought/oversold or the HMA slope to refine potential entries or exits. --- ### 6. Correlation & Multi-Ticker Analysis - Correlation Meter: You can select up to five tickers in the settings. The script calculates a slope-based metric for each, then combines those metrics to show an overall bullish or bearish tendency (displayed as a histogram). - Bar Coloring & Overlay: If you activate correlation-based bar coloring, it will reflect the broader trend alignment among the selected assets, potentially indicating when most are trending in the same direction. - Use Case: If you trade multiple markets, the correlation histogram can help you quickly see if several major assets support the same market bias or are diverging from one another. — ### 7. Money Flow Tracker Money Flow Calculation: The Money Flow Tracker calculates the Money Flow Index (MFI) based on price and volume data, factoring in buying pressure and selling pressure. The output is smoothed using a low-lag EMA to reduce noise and enhance usability. Visual Features: Dynamic Gradient Fill: The space between the smoothed MFI line and the midline (set at 50) is filled with a gradient. Above 50: Green gradient, with intensity increasing as the MFI moves further above the midline. Below 50: Red gradient, with intensity increasing as the MFI moves further below the midline. This gradient provides a clear visual representation of money flow strength and direction, making it easier to assess sentiment shifts at a glance. Overbought/Oversold Levels: Default thresholds are set at 70 (overbought) and 30 (oversold). When the MFI crosses these levels, it signals potential reversals or trend continuations. Bar Coloring: Bars turn green for positive money flow and red for negative money flow. Color intensity fades over time, ensuring recent signals stand out while older ones remain visible without dominating the chart. Alerts: Alerts are triggered when the Money Flow Tracker crosses into overbought or oversold zones, keeping traders informed of critical conditions without constant monitoring. Practical Applications: Trend Confirmation: Use the Money Flow Tracker alongside the oscillator or HMA to confirm trends or identify potential reversals. Volume-Based Reversal Signals: Spot turning points where price action aligns with shifts in money flow direction. Sentiment Analysis: Gauge whether market participants are accumulating (positive flow) or distributing (negative flow) assets, offering an additional layer of insight into price movement. (Space for an example chart: “Money Flow Tracker with gradient fills and overbought/oversold levels”) ### 8. Putting It All Together - Combining Signals: A practical approach might be to watch for a bullish divergence in the oscillator, confirm it with a shift in the HMA slope color, and then wait for the price to be near or below oversold conditions. The correlation histogram may further confirm if the broader market is also leaning bullish at that time. - Visual Cues: Bar coloring adds another layer, making your chart easier to interpret at a glance. You can also set alerts to ensure you don’t miss key events like divergences, crossovers, or moving average flips. - Flexibility: Not every feature needs to be used simultaneously. You might opt to focus on divergences and overbought/oversold signals, or you could emphasize the correlation histogram and bar colors. The settings let you enable or disable each module to suit your style. --- ### 9. Tips for Customization - Adjust Periods: Shorter periods can yield more signals but also more noise. Longer periods may provide steadier, but fewer, signals. - Set Appropriate Alert Conditions: Only alert on events most relevant to your strategy to avoid overload. - Explore Different MAs: Depending on the instrument, some moving average types may give a smoother or more responsive indication. - Monitor Risk Management: As with any tool, these signals do not guarantee performance, so consider position sizing and stop-loss strategies. --- By toggling and experimenting with the features described above—buy/sell signals, divergences, moving averages, dynamic gradient clouds, and correlation analysis—you can tailor Uptrick: Oscillator Spectrum to your specific trading approach. Each module is designed to give you a clearer, structured view of potential momentum shifts, overbought or oversold states, and the alignment or divergence of multiple assets. ## Features Explanation Below is a detailed overview of key features in Uptrick: Oscillator Spectrum. Each component is designed to provide different angles of market analysis, allowing you to customize the tool to your preferences. --- ### 1. Main Oscillator - Purpose: The primary oscillator in this script merges short-, medium-, and long-term views of buying pressure and true range into a single line. - Calculation: It weights each period’s contribution (e.g., a heavier focus on the short period if desired) and normalizes the result on a 0–100 scale, where higher readings may suggest more robust momentum. (like from the classic Ultimate Oscillator) - Practical Use: - Traders can watch for overbought/oversold conditions at user-defined thresholds (e.g., 70/30). - It can also provide a straightforward momentum reading for those who prefer to see if momentum is rising, falling, or leveling off. --- ### 2. HMA of the Smoothed Oscillator - What It Is: A Hull Moving Average (HMA) applied to the main oscillator values. The HMA is often more responsive than standard MAs, offering smoother lines while preserving relatively quick reaction to changes. - How It Works: - The script takes the oscillator’s output and processes it through a Hull MA calculation. - The HMA’s slope and color can change more dynamically, highlighting sharper momentum shifts. - Why It’s Useful: - By smoothing out minor fluctuations, the HMA can highlight trends in the oscillator’s trajectory. - If you see an extended run in the HMA slope, it may indicate a more persistent trend in momentum. - Color Intensity: - As the HMA continues in one direction for several bars, the script can intensify the color, signaling stronger or more sustained momentum in that direction. - Sudden changes in color or slope can signal the start of a new momentum swing. --- ### 3. Gradient Fill This script uses two gradient-based visual elements: 1. Shining/Layered Gradient on the Main Oscillator - Purpose: Adds multiple layers around the oscillator line (above and below) to emphasize slope changes and highlight how quickly the oscillator is moving up or down. - Color Changes: - When the oscillator rises, it uses a color scheme (e.g., aqua/blue) that intensifies as the slope grows. - When the oscillator declines, it uses a distinct color (e.g., red/pink). - User Benefit: Makes it easier to see at a glance if momentum is accelerating or decelerating, beyond just the numerical reading. 2. Dynamic Cloud Fill (Between MAs) - Purpose: Allows you to plot two moving averages (for example, a short-term Hull MA and a longer-term DEMA) and fill the area between them with a color gradient. - Bullish vs. Bearish: - When the short MA is above the long MA, the cloud might appear in a greenish hue. - When the short MA is below the long MA, the cloud can switch to red or another color. - Transparency/Intensity: - The fill can get more opaque if the difference between the two MAs is large, indicating a stronger trend but a higher probability of a reversal. - User Benefit: Helps visualize changes in trend or momentum across multiple time horizons, all within a single chart overlay. --- ### 4. Correlation Meter & Symbol Inputs - What It Is: This feature looks at multiple user-selected symbols (e.g., BTC, ETH, BNB, etc.) and computes each symbol’s short-term slope. It then aggregates these slopes into an overall “trend” score. - Inputs Configuration: 1. Ticker Inputs: You can specify up to five different tickers. 2. Timeframe: Decide whether to pull data from different chart timeframes for each symbol. 3. Slope Calculation: The script may compute, for instance, a 5-period SMA minus a 20-period SMA to gauge if each symbol is trending up or down. - Market Trend Histogram: - Displays a column that goes above/below zero depending on how many symbols are bullish or bearish. - If more than three (out of five) symbols are bullish, the histogram can show a green bar at +1; if fewer than three are bullish, it can show red at –1. - How to Use: - Quick Glance: Lets you know if most correlated assets are aligning or diverging. - Bar Coloring (Optional): If enabled, your main chart’s bars can reflect the aggregated correlation, turning green or red depending on the meter’s reading. --- ### 5. Advanced Metrics Table - What It Is: An optional table displaying additional metrics for several cryptocurrencies (or any symbols you define). - Metrics Included: 1. ROI (30D): Calculates return relative to the lowest price in a 30-day period. 2. Collateral Risk: Uses standard deviation to assess volatility (higher risk if standard deviation is large). 3. Liquidity Recovery: A rolling average of volume, aiming to show how liquidity flows might recover over time. 4. Weakening (Rate of Change): Reflects how quickly price is changing compared to previous bars. 5. Monetary Bias (SMA): A simple average of recent prices. If price is below this SMA, it might be seen as undervalued relative to the short term. 6. Risk Phase: Categorizes risk as low, medium, or high based on the standard deviation figure. 7. DCA Signal: Suggests “Accumulate” or “Do Not Accumulate” by checking if the current price is below or above the SMA. - Why It’s Useful: - Offers a concise view of multiple assets in one place—helpful for portfolio-level insight. - DCA (Dollar-Cost Averaging) suggestions can guide longer-term strategies, while volatility (collateral risk) helps gauge how aggressive the price swings might be. --- ### 6. Other Vital Aspects - Alerts & Notifications: - The script can trigger alerts for various conditions—crossovers, divergence detections, overbought/oversold transitions, or correlation-based signals. - Useful for automating watchlists or ensuring you don’t miss a key setup while away from the screen. - Customization: - Each module (oscillator settings, divergence detection, correlation meter, advanced metrics table, etc.) can be enabled or disabled based on your preferences. - You can fine-tune parameters (e.g., periods, smoothing lengths, alert triggers) to align the indicator with different trading styles—scalping, swing, or position trading. - Combining Features: - One might watch the main oscillator for momentum extremes, confirm via the HMA slope, check if correlation supports the same bias, and look at the table for risk-phase validation. - This multi-layer approach can help develop a more structured and informed trading view. (Space for an example chart: “A fully configured layout showing oscillator, HMA, gradient cloud, correlation meter, and table all in use.”) 7. Money Flow Tracker Purpose: The Money Flow Tracker adds a volume-based perspective to the indicator suite by incorporating the Money Flow Index (MFI), which assesses buying and selling pressure over a defined period. By smoothing the MFI using an exponential moving average (EMA), the feature highlights the directional flow of capital into and out of the market with greater clarity and reduced noise. Dynamic Gradient Visualization: The Money Flow Tracker enhances visual analysis with gradient fills that reflect the MFI’s relationship to the midline (50). Above 50: A green gradient emerges, intensifying as the MFI moves higher, indicating stronger positive money flow. Below 50: A red gradient appears, with deeper shades signifying increasing selling pressure. Transparency dynamically adjusts based on the MFI’s proximity to the midline, making high-confidence zones (closer to 0 or 100) visually distinct. Directional Sensitivity: The Tracker emphasizes the importance of overbought (above 70) and oversold (below 30) zones. These thresholds help traders identify when an asset might be overextended, signaling potential reversals or trend continuations. The inclusion of a midline (50) as a neutral zone helps gauge shifts between accumulation (money flowing in) and distribution (money flowing out). Bar Integration: By enabling bar coloring linked to the Money Flow Tracker, traders can visualize its impact directly on price bars. Green bars reflect positive money flow (above 50), signaling bullish conditions. Red bars indicate negative money flow (below 50), highlighting bearish sentiment. Intensity adjustments ensure that recent signals are more visually prominent, while older signals gradually fade for a clean, non-cluttered chart. Key Advantages: Volume-Informed Context: Traditional oscillators often focus solely on price; the Money Flow Tracker incorporates volume, adding a crucial dimension for analyzing market behavior. Adaptive Filtering: The EMA-smoothing feature ensures that sudden, insignificant spikes in volume don’t trigger false signals, providing a clearer and more actionable representation of money flow trends. Early Warning System: Divergences between price movement and the Money Flow Tracker’s trends can signal potential turning points, helping traders anticipate reversals before they occur. Practical Use Cases: Trend Confirmation: Pair the Money Flow Tracker with the oscillator or HMA to confirm bullish or bearish trends. For example, a rising oscillator with positive money flow indicates strong buying interest. Identifying Entry/Exit Zones: Use overbought/oversold conditions as entry/exit points, particularly when combined with other features like divergence detection. Market Sentiment Analysis: The Tracker’s ability to dynamically assess buying and selling pressure provides a clear picture of market sentiment, helping traders adjust their strategies to align with broader trends. By understanding these features—main oscillator readings, the HMA’s smoothing capabilities, gradient-based visual highlights, correlation insights, advanced metrics, and the money flow tracker—you can tailor Uptrick: Oscillator Spectrum to your specific needs, whether you’re focusing on quick trades, longer-term market moves, or broad portfolio health. Originality of the “Uptrick: Oscillator Spectrum” Indicator While it includes elements of standard momentum analysis, Uptrick: Oscillator Spectrum sets itself apart by adding an array of features that broaden the typical oscillator’s scope: 1. Slope Coloring & Layered Gradient Effects - Beyond just plotting a single line, the indicator visually highlights momentum shifts using color changes and gradient fills. - As the oscillator’s slope becomes steeper or flatter, these gradients intensify or fade, helping users see at a glance when momentum is accelerating, slowing, or reversing. 2. Mean Reversion & Divergence Detection - The script offers optional logic for marking potential mean reversion points (e.g., overbought/oversold crossovers) and flagging divergences between price and the oscillator line. - These divergence signals come with adjustable lookback parameters, giving traders control over how recent or extended the pivots should be for detection. - This functionality can reveal subtle momentum discrepancies that a basic oscillator might overlook. 3. Integrated Multi-Asset Correlation Meter - In addition to monitoring a single symbol, the indicator can fetch data for multiple tickers. It aggregates each symbol’s slope into a histogram showing whether the broader market (or a group of assets) leans bullish or bearish. - This cross-market insight moves beyond standard “one-symbol, one-oscillator” usage, adding a bigger-picture perspective in one tool. 4. Advanced Metrics Table - Users can enable a table that covers ROI calculations, volatility-based risk (“Collateral Risk”), liquidity checks, DCA signals, and more. - Rather than just seeing an oscillator value, traders can view additional metrics for selected assets in one place, helping them judge overall market conditions or assess multiple instruments simultaneously. 5. Flexible Overlay & Bar Coloring - Signals can be displayed directly on the price chart (Overlay True) or in a sub-window (Overlay False). - Bars themselves may change color (e.g., green for bullish or red for bearish) according to different rules—signals, dynamic cloud fill, correlation meter states, etc. - This adaptability allows traders to keep the chart as simple or as info-rich as they prefer. 6. Custom Smoothing Options & HMA Extensions - The oscillator can be processed further with a Hull Moving Average (HMA) to reduce noise while still reacting quickly to market changes. - Slope-based coloring on the HMA provides an additional layer of visual feedback, which is not common in a standard oscillator. By blending traditional momentum checks with slope-based color feedback, mean reversion triggers, divergence signals, correlation analysis, and an optional metrics table, Uptrick: Oscillator Spectrum offers a more rounded approach than a typical oscillator. It integrates multiple market insights—both visual and analytical—into one script, giving users a broader toolkit for studying potential reversals, gauging momentum strength, and assessing multi-asset trends. ## Conclusion Uptrick: Oscillator Spectrum brings together multiple layers of analysis—oscillator momentum, divergence detection, correlation insights, HMA smoothing, and more—into one adaptable toolkit. It aims to streamline your charting process by offering meaningful visual cues (such as gradient fills and bar color shifts), advanced tables for broader market data, and flexible alerts to keep you informed of potential setups. Traders can choose the specific features that suit their style, whether they prefer to focus on raw oscillator signals, multi-ticker correlation, or smooth trend cues from the HMA. By centralizing these different methods in one place, Uptrick: Oscillator Spectrum can help users build more structured approaches to spotting trend shifts and extended conditions, while also remaining compatible with additional analysis techniques. --- ### Disclaimer This script is provided for informational purposes only and does not constitute financial or investment advice. Past performance is not indicative of future results, and all trading involves risk. You should carefully consider your objectives, risk tolerance, and financial situation before making any trading decisions.
Pine Script® göstergesi
Uptrick 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
GKD-C Double Smoothed Stochastic of Momentum [Loxx]Giga Kaleidoscope Double Smoothed Stochastic of Momentum Confirmation is a Confirmation module included in Loxx's "Giga Kaleidoscope Modularized Trading System". What is Loxx's "Giga Kaleidoscope Modularized Trading System"? The Giga Kaleidoscope Modularized Trading System is a trading system built on the philosophy of the NNFX (No Nonsense Forex) algorithmic trading. What is an NNFX algorithmic trading strategy? The NNFX algorithm is built on the principles of trend, momentum, and volatility. There are six core components in the NNFX trading algorithm: 1. Volatility - price volatility; e.g., Average True Range, True Range Double, Close-to-Close, etc. 2. Baseline - a moving average to identify price trend (such as "Baseline" shown on the chart above) 3. Confirmation 1 - a technical indicator used to identify trends. This should agree with the "Baseline" 4. Confirmation 2 - a technical indicator used to identify trends. This filters/verifies the trend identified by "Baseline" and "Confirmation 1" 5. Volatility/Volume - a technical indicator used to identify volatility/volume breakouts/breakdown. 6. Exit - a technical indicator used to determine when a trend is exhausted. How does Loxx's GKD (Giga Kaleidoscope Modularized Trading System) implement the NNFX algorithm outlined above? Loxx's GKD v1.0 system has five types of modules (indicators/strategies). These modules are: 1. GKD-BT - Backtesting module (Volatility, Number 1 in the NNFX algorithm) 2. GKD-B - Baseline module (Baseline and Volatility/Volume, Numbers 1 and 2 in the NNFX algorithm) 3. GKD-C - Confirmation 1/2 module (Confirmation 1/2, Numbers 3 and 4 in the NNFX algorithm) 4. GKD-V - Volatility/Volume module (Confirmation 1/2, Number 5 in the NNFX algorithm) 5. GKD-E - Exit module (Exit, Number 6 in the NNFX algorithm) (additional module types will added in future releases) Each module interacts with every module by passing data between modules. Data is passed between each module as described below: GKD-B => GKD-V => GKD-C(1) => GKD-C(2) => GKD-E => GKD-BT That is, the Baseline indicator passes its data to Volatility/Volume. The Volatility/Volume indicator passes its values to the Confirmation 1 indicator. The Confirmation 1 indicator passes its values to the Confirmation 2 indicator. The Confirmation 2 indicator passes its values to the Exit indicator, and finally, the Exit indicator passes its values to the Backtest strategy. This chaining of indicators requires that each module conform to Loxx's GKD protocol, therefore allowing for the testing of every possible combination of technical indicators that make up the six components of the NNFX algorithm. What does the application of the GKD trading system look like? Example trading system: Backtest: Strategy with 1-3 take profits, trailing stop loss, multiple types of PnL volatility, and 2 backtesting styles Baseline: Leader Exponential Moving Average as shown on chart Volatility/Volume: Volatility Ratio as shown on chart Confirmation 1: Double Smoothed Stochastic of Momentum as shown on the chart above Confirmation 2: Jurik Turning Point Oscillator Exit: Rex Oscillator Each GKD indicator is denoted with a module identifier of either: GKD-BT, GKD-B, GKD-C, GKD-V, or GKD-E. This allows traders to understand to which module each indicator belongs and where each indicator fits into the GKD protocol chain. Now that you have a general understanding of the NNFX algorithm and the GKD trading system. Let's go over what's inside the GKD-E Double Smoothed Stochastic of Momentum itself. What is Double Smoothed Stochastic of Momentum? The Double Smoothed Stochastic of Momentum demonstrates smoother indicators and therefore gives fewer false signals in comparison with the traditional oscillator. The indicator is written in accordance with the description given in the book by Joe Dinapoli "Trading With DiNapoli Levels". This oscillator smoothing method leads to a filtering of the most "noise" component of the price movement. The Double Smoothed Stochastic of Momentum indicator can be used in the strategies oriented to a standard stochastic. However, the stronger smoothing can lead to the loss of an array of signals. It is recommended to apply any trend indicator for more efficient use of the indicator and its signals filtering. Signals A GKD-C Confirmation indicator can be used as either a Confirmation 1, Confirmation 2, or Solo Confirmation indicator. See step 3 & 4 of the NNFX algorithm above to understand how this indicator fits into the GKD trading system. The Solo Confirmation setting allows you to test this indicator by itself without an additional GKD-C indicator present in the GKD protocol chain. On the chart shown above, this indicator is shown as GKD-C Double Smoothed Stochastic of Momentum and is set to Solo Confirmation. The GKD-B Baseline, GKD-V Volatility Ratio, and this indicator satisfy the first three steps in the GKD trading system chain: GKD-B => GKD-V => GKD-C(solo). The signals from each of these settings are as follows: Confirmation 1 Signal Initial Long (L): Double Smoothed Stochastic of Momentum crosses-up over middle-line* Initial Short (S): Double Smoothed Stochastic of Momentum crosses-down under middle-line* Continuation Long (CL): Double Smoothed Stochastic of Momentum is over middle-line, then crosses-up over the signal** Continuation Short (CS): Double Smoothed Stochastic of Momentum is under middle-line, then crosses-down under the signal** Post Baseline Cross Long (BL): Double Smoothed Stochastic of Momentum crossed-up over middle-line but Baseline is still in downtrend, then Baseline turns to uptrend within XX bars*** Post Baseline Cross Short (BS): Double Smoothed Stochastic of Momentum crossed-down under middle-line but Baseline is still in uptrend, then Baseline turns to downtrend within XX bars*** BL Recovery Continuation Long (RL): Double Smoothed Stochastic of Momentum is above middle-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend; then, Double Smoothed Stochastic of Momentum crosses-up over the signal**** BL Recovery Continuation Short (RS): Double Smoothed Stochastic of Momentum is below middle-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend; then, Double Smoothed Stochastic of Momentum crosses-down under the signal**** *All signals are shown regardless of Baseline and Volatility/Volume qualification **All signals are shown regardless of Baseline qualification; however, when Baseline filter is active, only true continuations are shown. When the Baseline filter is not active, then all continuations are shown. True continuations are when the Baseline is active and maintains its uptrend/downtrend after the initial cross-up/cross-down over the middle-line respectively. This means that if the Baseline trend then moves against the Double Smoothed Stochastic of Momentum then any continuation signals are voided until another initial Long/Short. All continuations are will either show as regular continuations or be converted into recovery continuations ***All signals are shown regardless of Volatility/Volume qualification ****When the Baseline filter is active, some regular continuations are converted to recovery continuations and are shown. When the Baseline filter is not active, then these signals are not shown. Confirmation 2 Signal Initial Long (L): Double Smoothed Stochastic of Momentum crosses-up over middle-line* Initial Short (S): Double Smoothed Stochastic of Momentum crosses-down under middle-line* Continuation Long (CL): Double Smoothed Stochastic of Momentum is over middle-line, then crosses-up over the signal** Continuation Short (CS): Double Smoothed Stochastic of Momentum is under middle-line, then crosses-down under the signal** Post Baseline Cross Long (BL): Double Smoothed Stochastic of Momentum crossed-up over middle-line but Baseline is still in downtrend, then Baseline turns to uptrend within XX bars*** Post Baseline Cross Short (BS): Double Smoothed Stochastic of Momentum crossed-down under middle-line but Baseline is still in uptrend, then Baseline turns to downtrend within XX bars*** BL Recovery Continuation Long (RL): Double Smoothed Stochastic of Momentum is above middle-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend while Double Smoothed Stochastic of Momentum is still above middle-line; then, Double Smoothed Stochastic of Momentum crosses-up over the signal**** BL Recovery Continuation Short (RS): Double Smoothed Stochastic of Momentum is below middle-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend while Double Smoothed Stochastic of Momentum is still below middle-line; then, Double Smoothed Stochastic of Momentum crosses-down under the signal**** *All signals are shown regardless of Baseline and Volatility/Volume qualification **All signals are shown regardless of Baseline qualification; however, when Baseline filter is active, only true continuations are shown. When the Baseline filter is not active, then all continuations are shown. True continuations are when the Baseline is active and maintains its uptrend/downtrend after the initial cross-up/cross-down over the middle-line respectively. This means that if the Baseline trend then moves against the Double Smoothed Stochastic of Momentum then any continuation signals are voided until another initial Long/Short. All continuations are will either show as regular continuations or be converted into recovery continuations ***All signals are shown regardless of Volatility/Volume qualification ****When the Baseline filter is active, some regular continuations are converted to recovery continuations and are shown. When the Baseline filter is not active, then these signals are not shown. Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Initial Long (L): The imported GKD-C Confirmation 1 indicator crosses-up over middle-line, then Double Smoothed Stochastic of Momentum crosses-up over the middle-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below) Initial Short (S): The imported GKD-C Confirmation 1 indicator crosses-down under middle-line, then Double Smoothed Stochastic of Momentum crosses-down under the middle-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below) Continuation Long Confirmation 1 (CL): The imported GKD-C Confirmation 1 indicator is over middle-line, then crosses-up over the signal Continuation Short Confirmation 1 (CS): The imported GKD-C Confirmation 1 indicator is under middle-line, then crosses-down under the signal Post Baseline Cross Long (BL): The imported GKD-C Confirmation 1 crossed-up over middle-line but Baseline is still in downtrend; and Double Smoothed Stochastic of Momentum crossed-up over middle-line on the same bar or XX bars in the future but Baseline is still in downtrend; then Baseline turns to uptrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below) Post Baseline Cross Short (BS): The imported GKD-C Confirmation 1 crossed-down under middle-line but Baseline is still in uptrend; and, Double Smoothed Stochastic of Momentum crossed-down under middle-line on the same bar or XX bars in the future but Baseline is still in uptrend; then Baseline turns to downtrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below) BL Recovery Continuation Long (RL): The imported GKD-C Confirmation 1 indicator is above middle-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend while Double Smoothed Stochastic of Momentum is still above middle-line; then, The imported GKD-C Confirmation 1 crosses-up over the signal BL Recovery Continuation Short (RS): The imported GKD-C Confirmation 1 indicator is below middle-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend while Double Smoothed Stochastic of Momentum is still below middle-line; then, The imported GKD-C Confirmation 1 crosses-down under the signal Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 2 Initial Long (L): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Initial Short (S): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Continuation Long Confirmation 2 (CL): Double Smoothed Stochastic of Momentum is over middle-line, then crosses-up over the signal Continuation Short Confirmation 2 (CS): Double Smoothed Stochastic of Momentum is under middle-line, then crosses-down under the signal Post Baseline Cross Long (BL): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Post Baseline Cross Short (BS): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 BL Recovery Continuation Long (RL): Double Smoothed Stochastic of Momentum is above middle-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend; then, Double Smoothed Stochastic of Momentum crosses-up over the signal BL Recovery Continuation Short (RS): Double Smoothed Stochastic of Momentum is below middle-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend; then, Double Smoothed Stochastic of Momentum crosses-down under the signal Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Both Initial Long (L): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Initial Short (S): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Continuation Long Confirmation 2 (CL): The imported GKD-C Confirmation 1 indicator is over middle-line, then crosses-up over the signal; Double Smoothed Stochastic of Momentum is over middle-line, then crosses-up over the signal within "Number of Bars Confirmation" bars in the future Continuation Short Confirmation 2 (CS): The imported GKD-C Confirmation 1 indicator is under middle-line, then crosses-down under the signal; Double Smoothed Stochastic of Momentum is under middle-line, then crosses-down under the signal within "Number of Bars Confirmation" bars in the future Post Baseline Cross Long (BL): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Post Baseline Cross Short (BS): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 BL Recovery Continuation Long (RL): The imported GKD-C Confirmation 1 indicator is above middle-line and Double Smoothed Stochastic of Momentum is above middle-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend; then, the imported GKD-C Confirmation 1 crosses-up over its signal, and Double Smoothed Stochastic of Momentum crosses-up over its signal within "Number of Bars Confirmation" bars in the future BL Recovery Continuation Short (RS): The imported GKD-C Confirmation 1 indicator is below middle-line and Double Smoothed Stochastic of Momentum is below middle-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend; then, the imported GKD-C Confirmation 1 crosses-down under its signal, and Double Smoothed Stochastic of Momentum crosses-down under its signal within "Number of Bars Confirmation" bars in the future Confirmation 2 Confluence Background Color Signals; Confirmation Order: Both; Confirmation Type: (continuations don't change from the variations above) Initial Long (L): The imported GKD-C Confirmation 1 indicator crosses-up over middle-line, then Double Smoothed Stochastic of Momentum crosses-up over the middle-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below); OR, Double Smoothed Stochastic of Momentum crosses-up over middle-line, then the imported GKD-C Confirmation 1 indicator crosses-up over the middle-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below) Initial Short (S): The imported GKD-C Confirmation 1 indicator crosses-down under middle-line, then Double Smoothed Stochastic of Momentum crosses-down under the middle-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below); OR, Double Smoothed Stochastic of Momentum crosses-down under middle-line, then the imported GKD-C Confirmation 1 indicator crosses-down under the middle-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below) Post Baseline Cross Long (BL): The imported GKD-C Confirmation 1 crossed-down under middle-line but Baseline is still in uptrend; and, Double Smoothed Stochastic of Momentum crossed-down under middle-line on the same bar or XX bars in the future but Baseline is still in uptrend; then Baseline turns to downtrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below); OR, Double Smoothed Stochastic of Momentum crossed-down under middle-line but Baseline is still in uptrend; and, the imported GKD-C Confirmation 1 crossed-down under middle-line on the same bar or XX bars in the future but Baseline is still in uptrend; then Baseline turns to downtrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below) Post Baseline Cross Short (BS): The imported GKD-C Confirmation 1 crossed-down under middle-line but Baseline is still in uptrend; and, Double Smoothed Stochastic of Momentum crossed-down under middle-line on the same bar or XX bars in the future but Baseline is still in uptrend; then Baseline turns to downtrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below); OR, Double Smoothed Stochastic of Momentum crossed-down under middle-line but Baseline is still in uptrend; and, the imported GKD-C Confirmation 1 crossed-down under middle-line on the same bar or XX bars in the future but Baseline is still in uptrend; then Baseline turns to downtrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below) Solo Confirmation Signals Initial Long (L): Double Smoothed Stochastic of Momentum crosses-up over middle-line Initial Short (S): Double Smoothed Stochastic of Momentum crosses-down under middle-line Continuation Long (CL): Double Smoothed Stochastic of Momentum is over middle-line, then crosses-up over the signal Continuation Short (CS): Double Smoothed Stochastic of Momentum is under middle-line, then crosses-down under the signal Post Baseline Cross Long (BL): Double Smoothed Stochastic of Momentum crossed-up over middle-line but Baseline is still in downtrend, then Baseline turns to uptrend within XX bars Post Baseline Cross Short (BS): Double Smoothed Stochastic of Momentum crossed-down under middle-line but Baseline is still in uptrend, then Baseline turns to downtrend within XX bars BL Recovery Continuation Long (RL): Double Smoothed Stochastic of Momentum above middle-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend while Double Smoothed Stochastic of Momentum is still above middle-line BL Recovery Continuation Short (RS): Double Smoothed Stochastic of Momentum below middle-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend while Double Smoothed Stochastic of Momentum is still below middle-line X-bar Rule settings This rule only applies when this indicator "Confirmation Type" set to "Confirmation 2" Requirements Inputs: Confirmation 1 and Solo Confirmation: GKD-V Volatility/Volume indicator; Confirmation 2: GKD-C Confirmation indicator Output: Confirmation 2 and Solo Confirmation: GKD-E Exit indicator; Confirmation 1: GKD-C Confirmation indicator Additional features will be added in future releases. This indicator is only available to ALGX Trading VIP group members . You can see the Author's Instructions below to get more information on how to get access.
Pine Script® göstergesi
loxx tarafından
GKD-C Double Smoothed Stochastic [Loxx]Giga Kaleidoscope Double Smoothed Stochastic Confirmation is a Confirmation module included in Loxx's "Giga Kaleidoscope Modularized Trading System". What is Loxx's "Giga Kaleidoscope Modularized Trading System"? The Giga Kaleidoscope Modularized Trading System is a trading system built on the philosophy of the NNFX (No Nonsense Forex) algorithmic trading. What is an NNFX algorithmic trading strategy? The NNFX algorithm is built on the principles of trend, momentum, and volatility. There are six core components in the NNFX trading algorithm: 1. Volatility - price volatility; e.g., Average True Range, True Range Double, Close-to-Close, etc. 2. Baseline - a moving average to identify price trend (such as "Baseline" shown on the chart above) 3. Confirmation 1 - a technical indicator used to identify trends. This should agree with the "Baseline" 4. Confirmation 2 - a technical indicator used to identify trends. This filters/verifies the trend identified by "Baseline" and "Confirmation 1" 5. Volatility/Volume - a technical indicator used to identify volatility/volume breakouts/breakdown. 6. Exit - a technical indicator used to determine when a trend is exhausted. How does Loxx's GKD (Giga Kaleidoscope Modularized Trading System) implement the NNFX algorithm outlined above? Loxx's GKD v1.0 system has five types of modules (indicators/strategies). These modules are: 1. GKD-BT - Backtesting module (Volatility, Number 1 in the NNFX algorithm) 2. GKD-B - Baseline module (Baseline and Volatility/Volume, Numbers 1 and 2 in the NNFX algorithm) 3. GKD-C - Confirmation 1/2 module (Confirmation 1/2, Numbers 3 and 4 in the NNFX algorithm) 4. GKD-V - Volatility/Volume module (Confirmation 1/2, Number 5 in the NNFX algorithm) 5. GKD-E - Exit module (Exit, Number 6 in the NNFX algorithm) (additional module types will added in future releases) Each module interacts with every module by passing data between modules. Data is passed between each module as described below: GKD-B => GKD-V => GKD-C(1) => GKD-C(2) => GKD-E => GKD-BT That is, the Baseline indicator passes its data to Volatility/Volume. The Volatility/Volume indicator passes its values to the Confirmation 1 indicator. The Confirmation 1 indicator passes its values to the Confirmation 2 indicator. The Confirmation 2 indicator passes its values to the Exit indicator, and finally, the Exit indicator passes its values to the Backtest strategy. This chaining of indicators requires that each module conform to Loxx's GKD protocol, therefore allowing for the testing of every possible combination of technical indicators that make up the six components of the NNFX algorithm. What does the application of the GKD trading system look like? Example trading system: Backtest: Strategy with 1-3 take profits, trailing stop loss, multiple types of PnL volatility, and 2 backtesting styles Baseline: Leader Exponential Moving Average as shown on chart Volatility/Volume: Volatility Ratio as shown on chart Confirmation 1: Double Smoothed Stochastic as shown on the chart above Confirmation 2: Jurik Turning Point Oscillator Exit: Rex Oscillator Each GKD indicator is denoted with a module identifier of either: GKD-BT, GKD-B, GKD-C, GKD-V, or GKD-E. This allows traders to understand to which module each indicator belongs and where each indicator fits into the GKD protocol chain. Now that you have a general understanding of the NNFX algorithm and the GKD trading system. Let's go over what's inside the GKD-E Double Smoothed Stochastic itself. What is Double Smoothed Stochastic? The Double Smoothed Stochastic demonstrates smoother indicators and therefore gives fewer false signals in comparison with the traditional oscillator. The indicator is written in accordance with the description given in the book by Joe Dinapoli "Trading With DiNapoli Levels". This oscillator smoothing method leads to a filtering of the most "noise" component of the price movement. The Double Smoothed Stochastic indicator can be used in the strategies oriented to a standard stochastic. However, the stronger smoothing can lead to the loss of an array of signals. It is recommended to apply any trend indicator for more efficient use of the indicator and its signals filtering. Signals A GKD-C Confirmation indicator can be used as either a Confirmation 1, Confirmation 2, or Solo Confirmation indicator. See step 3 & 4 of the NNFX algorithm above to understand how this indicator fits into the GKD trading system. The Solo Confirmation setting allows you to test this indicator by itself without an additional GKD-C indicator present in the GKD protocol chain. On the chart shown above, this indicator is shown as GKD-C Double Smoothed Stochastic and is set to Solo Confirmation. The GKD-B Baseline, GKD-V Volatility Ratio, and this indicator satisfy the first three steps in the GKD trading system chain: GKD-B => GKD-V => GKD-C(solo). The signals from each of these settings are as follows: Confirmation 1 Signal Initial Long (L): Double Smoothed Stochastic crosses-up over middle-line* Initial Short (S): Double Smoothed Stochastic crosses-down under middle-line* Continuation Long (CL): Double Smoothed Stochastic is over middle-line, then crosses-up over the signal** Continuation Short (CS): Double Smoothed Stochastic is under middle-line, then crosses-down under the signal** Post Baseline Cross Long (BL): Double Smoothed Stochastic crossed-up over middle-line but Baseline is still in downtrend, then Baseline turns to uptrend within XX bars*** Post Baseline Cross Short (BS): Double Smoothed Stochastic crossed-down under middle-line but Baseline is still in uptrend, then Baseline turns to downtrend within XX bars*** BL Recovery Continuation Long (RL): Double Smoothed Stochastic is above middle-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend; then, Double Smoothed Stochastic crosses-up over the signal**** BL Recovery Continuation Short (RS): Double Smoothed Stochastic is below middle-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend; then, Double Smoothed Stochastic crosses-down under the signal**** *All signals are shown regardless of Baseline and Volatility/Volume qualification **All signals are shown regardless of Baseline qualification; however, when Baseline filter is active, only true continuations are shown. When the Baseline filter is not active, then all continuations are shown. True continuations are when the Baseline is active and maintains its uptrend/downtrend after the initial cross-up/cross-down over the middle-line respectively. This means that if the Baseline trend then moves against the Double Smoothed Stochastic then any continuation signals are voided until another initial Long/Short. All continuations are will either show as regular continuations or be converted into recovery continuations ***All signals are shown regardless of Volatility/Volume qualification ****When the Baseline filter is active, some regular continuations are converted to recovery continuations and are shown. When the Baseline filter is not active, then these signals are not shown. Confirmation 2 Signal Initial Long (L): Double Smoothed Stochastic crosses-up over middle-line* Initial Short (S): Double Smoothed Stochastic crosses-down under middle-line* Continuation Long (CL): Double Smoothed Stochastic is over middle-line, then crosses-up over the signal** Continuation Short (CS): Double Smoothed Stochastic is under middle-line, then crosses-down under the signal** Post Baseline Cross Long (BL): Double Smoothed Stochastic crossed-up over middle-line but Baseline is still in downtrend, then Baseline turns to uptrend within XX bars*** Post Baseline Cross Short (BS): Double Smoothed Stochastic crossed-down under middle-line but Baseline is still in uptrend, then Baseline turns to downtrend within XX bars*** BL Recovery Continuation Long (RL): Double Smoothed Stochastic is above middle-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend while Double Smoothed Stochastic is still above middle-line; then, Double Smoothed Stochastic crosses-up over the signal**** BL Recovery Continuation Short (RS): Double Smoothed Stochastic is below middle-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend while Double Smoothed Stochastic is still below middle-line; then, Double Smoothed Stochastic crosses-down under the signal**** *All signals are shown regardless of Baseline and Volatility/Volume qualification **All signals are shown regardless of Baseline qualification; however, when Baseline filter is active, only true continuations are shown. When the Baseline filter is not active, then all continuations are shown. True continuations are when the Baseline is active and maintains its uptrend/downtrend after the initial cross-up/cross-down over the middle-line respectively. This means that if the Baseline trend then moves against the Double Smoothed Stochastic then any continuation signals are voided until another initial Long/Short. All continuations are will either show as regular continuations or be converted into recovery continuations ***All signals are shown regardless of Volatility/Volume qualification ****When the Baseline filter is active, some regular continuations are converted to recovery continuations and are shown. When the Baseline filter is not active, then these signals are not shown. Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Initial Long (L): The imported GKD-C Confirmation 1 indicator crosses-up over middle-line, then Double Smoothed Stochastic crosses-up over the middle-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below) Initial Short (S): The imported GKD-C Confirmation 1 indicator crosses-down under middle-line, then Double Smoothed Stochastic crosses-down under the middle-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below) Continuation Long Confirmation 1 (CL): The imported GKD-C Confirmation 1 indicator is over middle-line, then crosses-up over the signal Continuation Short Confirmation 1 (CS): The imported GKD-C Confirmation 1 indicator is under middle-line, then crosses-down under the signal Post Baseline Cross Long (BL): The imported GKD-C Confirmation 1 crossed-up over middle-line but Baseline is still in downtrend; and Double Smoothed Stochastic crossed-up over middle-line on the same bar or XX bars in the future but Baseline is still in downtrend; then Baseline turns to uptrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below) Post Baseline Cross Short (BS): The imported GKD-C Confirmation 1 crossed-down under middle-line but Baseline is still in uptrend; and, Double Smoothed Stochastic crossed-down under middle-line on the same bar or XX bars in the future but Baseline is still in uptrend; then Baseline turns to downtrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below) BL Recovery Continuation Long (RL): The imported GKD-C Confirmation 1 indicator is above middle-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend while Double Smoothed Stochastic is still above middle-line; then, The imported GKD-C Confirmation 1 crosses-up over the signal BL Recovery Continuation Short (RS): The imported GKD-C Confirmation 1 indicator is below middle-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend while Double Smoothed Stochastic is still below middle-line; then, The imported GKD-C Confirmation 1 crosses-down under the signal Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 2 Initial Long (L): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Initial Short (S): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Continuation Long Confirmation 2 (CL): Double Smoothed Stochastic is over middle-line, then crosses-up over the signal Continuation Short Confirmation 2 (CS): Double Smoothed Stochastic is under middle-line, then crosses-down under the signal Post Baseline Cross Long (BL): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Post Baseline Cross Short (BS): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 BL Recovery Continuation Long (RL): Double Smoothed Stochastic is above middle-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend; then, Double Smoothed Stochastic crosses-up over the signal BL Recovery Continuation Short (RS): Double Smoothed Stochastic is below middle-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend; then, Double Smoothed Stochastic crosses-down under the signal Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Both Initial Long (L): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Initial Short (S): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Continuation Long Confirmation 2 (CL): The imported GKD-C Confirmation 1 indicator is over middle-line, then crosses-up over the signal; Double Smoothed Stochastic is over middle-line, then crosses-up over the signal within "Number of Bars Confirmation" bars in the future Continuation Short Confirmation 2 (CS): The imported GKD-C Confirmation 1 indicator is under middle-line, then crosses-down under the signal; Double Smoothed Stochastic is under middle-line, then crosses-down under the signal within "Number of Bars Confirmation" bars in the future Post Baseline Cross Long (BL): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Post Baseline Cross Short (BS): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 BL Recovery Continuation Long (RL): The imported GKD-C Confirmation 1 indicator is above middle-line and Double Smoothed Stochastic is above middle-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend; then, the imported GKD-C Confirmation 1 crosses-up over its signal, and Double Smoothed Stochastic crosses-up over its signal within "Number of Bars Confirmation" bars in the future BL Recovery Continuation Short (RS): The imported GKD-C Confirmation 1 indicator is below middle-line and Double Smoothed Stochastic is below middle-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend; then, the imported GKD-C Confirmation 1 crosses-down under its signal, and Double Smoothed Stochastic crosses-down under its signal within "Number of Bars Confirmation" bars in the future Confirmation 2 Confluence Background Color Signals; Confirmation Order: Both; Confirmation Type: (continuations don't change from the variations above) Initial Long (L): The imported GKD-C Confirmation 1 indicator crosses-up over middle-line, then Double Smoothed Stochastic crosses-up over the middle-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below); OR, Double Smoothed Stochastic crosses-up over middle-line, then the imported GKD-C Confirmation 1 indicator crosses-up over the middle-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below) Initial Short (S): The imported GKD-C Confirmation 1 indicator crosses-down under middle-line, then Double Smoothed Stochastic crosses-down under the middle-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below); OR, Double Smoothed Stochastic crosses-down under middle-line, then the imported GKD-C Confirmation 1 indicator crosses-down under the middle-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below) Post Baseline Cross Long (BL): The imported GKD-C Confirmation 1 crossed-down under middle-line but Baseline is still in uptrend; and, Double Smoothed Stochastic crossed-down under middle-line on the same bar or XX bars in the future but Baseline is still in uptrend; then Baseline turns to downtrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below); OR, Double Smoothed Stochastic crossed-down under middle-line but Baseline is still in uptrend; and, the imported GKD-C Confirmation 1 crossed-down under middle-line on the same bar or XX bars in the future but Baseline is still in uptrend; then Baseline turns to downtrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below) Post Baseline Cross Short (BS): The imported GKD-C Confirmation 1 crossed-down under middle-line but Baseline is still in uptrend; and, Double Smoothed Stochastic crossed-down under middle-line on the same bar or XX bars in the future but Baseline is still in uptrend; then Baseline turns to downtrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below); OR, Double Smoothed Stochastic crossed-down under middle-line but Baseline is still in uptrend; and, the imported GKD-C Confirmation 1 crossed-down under middle-line on the same bar or XX bars in the future but Baseline is still in uptrend; then Baseline turns to downtrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below) Solo Confirmation Signals Initial Long (L): Double Smoothed Stochastic crosses-up over middle-line Initial Short (S): Double Smoothed Stochastic crosses-down under middle-line Continuation Long (CL): Double Smoothed Stochastic is over middle-line, then crosses-up over the signal Continuation Short (CS): Double Smoothed Stochastic is under middle-line, then crosses-down under the signal Post Baseline Cross Long (BL): Double Smoothed Stochastic crossed-up over middle-line but Baseline is still in downtrend, then Baseline turns to uptrend within XX bars Post Baseline Cross Short (BS): Double Smoothed Stochastic crossed-down under middle-line but Baseline is still in uptrend, then Baseline turns to downtrend within XX bars BL Recovery Continuation Long (RL): Double Smoothed Stochastic above middle-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend while Double Smoothed Stochastic is still above middle-line BL Recovery Continuation Short (RS): Double Smoothed Stochastic below middle-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend while Double Smoothed Stochastic is still below middle-line X-bar Rule settings This rule only applies when this indicator "Confirmation Type" set to "Confirmation 2" Requirements Inputs: Confirmation 1 and Solo Confirmation: GKD-V Volatility/Volume indicator; Confirmation 2: GKD-C Confirmation indicator Output: Confirmation 2 and Solo Confirmation: GKD-E Exit indicator; Confirmation 1: GKD-C Confirmation indicator Additional features will be added in future releases. This indicator is only available to ALGX Trading VIP group members . You can see the Author's Instructions below to get more information on how to get access.
Pine Script® göstergesi
loxx tarafından
GKD-C DiNapoli Stochastic [Loxx]Giga Kaleidoscope DiNapoli Stochastic Confirmation is a Confirmation module included in Loxx's "Giga Kaleidoscope Modularized Trading System". What is Loxx's "Giga Kaleidoscope Modularized Trading System"? The Giga Kaleidoscope Modularized Trading System is a trading system built on the philosophy of the NNFX (No Nonsense Forex) algorithmic trading. What is an NNFX algorithmic trading strategy? The NNFX algorithm is built on the principles of trend, momentum, and volatility. There are six core components in the NNFX trading algorithm: 1. Volatility - price volatility; e.g., Average True Range, True Range Double, Close-to-Close, etc. 2. Baseline - a moving average to identify price trend (such as "Baseline" shown on the chart above) 3. Confirmation 1 - a technical indicator used to identify trends. This should agree with the "Baseline" 4. Confirmation 2 - a technical indicator used to identify trends. This filters/verifies the trend identified by "Baseline" and "Confirmation 1" 5. Volatility/Volume - a technical indicator used to identify volatility/volume breakouts/breakdown. 6. Exit - a technical indicator used to determine when a trend is exhausted. How does Loxx's GKD (Giga Kaleidoscope Modularized Trading System) implement the NNFX algorithm outlined above? Loxx's GKD v1.0 system has five types of modules (indicators/strategies). These modules are: 1. GKD-BT - Backtesting module (Volatility, Number 1 in the NNFX algorithm) 2. GKD-B - Baseline module (Baseline and Volatility/Volume, Numbers 1 and 2 in the NNFX algorithm) 3. GKD-C - Confirmation 1/2 module (Confirmation 1/2, Numbers 3 and 4 in the NNFX algorithm) 4. GKD-V - Volatility/Volume module (Confirmation 1/2, Number 5 in the NNFX algorithm) 5. GKD-E - Exit module (Exit, Number 6 in the NNFX algorithm) (additional module types will added in future releases) Each module interacts with every module by passing data between modules. Data is passed between each module as described below: GKD-B => GKD-V => GKD-C(1) => GKD-C(2) => GKD-E => GKD-BT That is, the Baseline indicator passes its data to Volatility/Volume. The Volatility/Volume indicator passes its values to the Confirmation 1 indicator. The Confirmation 1 indicator passes its values to the Confirmation 2 indicator. The Confirmation 2 indicator passes its values to the Exit indicator, and finally, the Exit indicator passes its values to the Backtest strategy. This chaining of indicators requires that each module conform to Loxx's GKD protocol, therefore allowing for the testing of every possible combination of technical indicators that make up the six components of the NNFX algorithm. What does the application of the GKD trading system look like? Example trading system: Backtest: Strategy with 1-3 take profits, trailing stop loss, multiple types of PnL volatility, and 2 backtesting styles Baseline: Leader Exponential Moving Average as shown on chart Volatility/Volume: Volatility Ratio as shown on chart Confirmation 1: DiNapoli Stochastic as shown on the chart above Confirmation 2: Jurik Turning Point Oscillator Exit: Rex Oscillator Each GKD indicator is denoted with a module identifier of either: GKD-BT, GKD-B, GKD-C, GKD-V, or GKD-E. This allows traders to understand to which module each indicator belongs and where each indicator fits into the GKD protocol chain. Now that you have a general understanding of the NNFX algorithm and the GKD trading system. Let's go over what's inside the GKD-E DiNapoli Stochastic itself. What is DiNapoli Stochastic? The DiNapoli Stochastic demonstrates smoother indicators and therefore gives fewer false signals in comparison with the traditional oscillator. The indicator is written in accordance with the description given in the book by Joe Dinapoli "Trading With DiNapoli Levels". This oscillator smoothing method leads to a filtering of the most "noise" component of the price movement. The DiNapoli Stochastic indicator can be used in the strategies oriented to a standard stochastic. However, the stronger smoothing can lead to the loss of an array of signals. It is recommended to apply any trend indicator for more efficient use of the indicator and its signals filtering. Signals A GKD-C Confirmation indicator can be used as either a Confirmation 1, Confirmation 2, or Solo Confirmation indicator. See step 3 & 4 of the NNFX algorithm above to understand how this indicator fits into the GKD trading system. The Solo Confirmation setting allows you to test this indicator by itself without an additional GKD-C indicator present in the GKD protocol chain. On the chart shown above, this indicator is shown as GKD-C DiNapoli Stochastic and is set to Solo Confirmation. The GKD-B Baseline, GKD-V Volatility Ratio, and this indicator satisfy the first three steps in the GKD trading system chain: GKD-B => GKD-V => GKD-C(solo). The signals from each of these settings are as follows: Confirmation 1 Signal Initial Long (L): DiNapoli Stochastic crosses-up over middle-line* Initial Short (S): DiNapoli Stochastic crosses-down under middle-line* Continuation Long (CL): DiNapoli Stochastic is over middle-line, then crosses-up over the signal** Continuation Short (CS): DiNapoli Stochastic is under middle-line, then crosses-down under the signal** Post Baseline Cross Long (BL): DiNapoli Stochastic crossed-up over middle-line but Baseline is still in downtrend, then Baseline turns to uptrend within XX bars*** Post Baseline Cross Short (BS): DiNapoli Stochastic crossed-down under middle-line but Baseline is still in uptrend, then Baseline turns to downtrend within XX bars*** BL Recovery Continuation Long (RL): DiNapoli Stochastic is above middle-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend; then, DiNapoli Stochastic crosses-up over the signal**** BL Recovery Continuation Short (RS): DiNapoli Stochastic is below middle-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend; then, DiNapoli Stochastic crosses-down under the signal**** *All signals are shown regardless of Baseline and Volatility/Volume qualification **All signals are shown regardless of Baseline qualification; however, when Baseline filter is active, only true continuations are shown. When the Baseline filter is not active, then all continuations are shown. True continuations are when the Baseline is active and maintains its uptrend/downtrend after the initial cross-up/cross-down over the middle-line respectively. This means that if the Baseline trend then moves against the DiNapoli Stochastic then any continuation signals are voided until another initial Long/Short. All continuations are will either show as regular continuations or be converted into recovery continuations ***All signals are shown regardless of Volatility/Volume qualification ****When the Baseline filter is active, some regular continuations are converted to recovery continuations and are shown. When the Baseline filter is not active, then these signals are not shown. Confirmation 2 Signal Initial Long (L): DiNapoli Stochastic crosses-up over middle-line* Initial Short (S): DiNapoli Stochastic crosses-down under middle-line* Continuation Long (CL): DiNapoli Stochastic is over middle-line, then crosses-up over the signal** Continuation Short (CS): DiNapoli Stochastic is under middle-line, then crosses-down under the signal** Post Baseline Cross Long (BL): DiNapoli Stochastic crossed-up over middle-line but Baseline is still in downtrend, then Baseline turns to uptrend within XX bars*** Post Baseline Cross Short (BS): DiNapoli Stochastic crossed-down under middle-line but Baseline is still in uptrend, then Baseline turns to downtrend within XX bars*** BL Recovery Continuation Long (RL): DiNapoli Stochastic is above middle-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend while DiNapoli Stochastic is still above middle-line; then, DiNapoli Stochastic crosses-up over the signal**** BL Recovery Continuation Short (RS): DiNapoli Stochastic is below middle-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend while DiNapoli Stochastic is still below middle-line; then, DiNapoli Stochastic crosses-down under the signal**** *All signals are shown regardless of Baseline and Volatility/Volume qualification **All signals are shown regardless of Baseline qualification; however, when Baseline filter is active, only true continuations are shown. When the Baseline filter is not active, then all continuations are shown. True continuations are when the Baseline is active and maintains its uptrend/downtrend after the initial cross-up/cross-down over the middle-line respectively. This means that if the Baseline trend then moves against the DiNapoli Stochastic then any continuation signals are voided until another initial Long/Short. All continuations are will either show as regular continuations or be converted into recovery continuations ***All signals are shown regardless of Volatility/Volume qualification ****When the Baseline filter is active, some regular continuations are converted to recovery continuations and are shown. When the Baseline filter is not active, then these signals are not shown. Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Initial Long (L): The imported GKD-C Confirmation 1 indicator crosses-up over middle-line, then DiNapoli Stochastic crosses-up over the middle-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below) Initial Short (S): The imported GKD-C Confirmation 1 indicator crosses-down under middle-line, then DiNapoli Stochastic crosses-down under the middle-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below) Continuation Long Confirmation 1 (CL): The imported GKD-C Confirmation 1 indicator is over middle-line, then crosses-up over the signal Continuation Short Confirmation 1 (CS): The imported GKD-C Confirmation 1 indicator is under middle-line, then crosses-down under the signal Post Baseline Cross Long (BL): The imported GKD-C Confirmation 1 crossed-up over middle-line but Baseline is still in downtrend; and DiNapoli Stochastic crossed-up over middle-line on the same bar or XX bars in the future but Baseline is still in downtrend; then Baseline turns to uptrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below) Post Baseline Cross Short (BS): The imported GKD-C Confirmation 1 crossed-down under middle-line but Baseline is still in uptrend; and, DiNapoli Stochastic crossed-down under middle-line on the same bar or XX bars in the future but Baseline is still in uptrend; then Baseline turns to downtrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below) BL Recovery Continuation Long (RL): The imported GKD-C Confirmation 1 indicator is above middle-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend while DiNapoli Stochastic is still above middle-line; then, The imported GKD-C Confirmation 1 crosses-up over the signal BL Recovery Continuation Short (RS): The imported GKD-C Confirmation 1 indicator is below middle-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend while DiNapoli Stochastic is still below middle-line; then, The imported GKD-C Confirmation 1 crosses-down under the signal Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 2 Initial Long (L): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Initial Short (S): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Continuation Long Confirmation 2 (CL): DiNapoli Stochastic is over middle-line, then crosses-up over the signal Continuation Short Confirmation 2 (CS): DiNapoli Stochastic is under middle-line, then crosses-down under the signal Post Baseline Cross Long (BL): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Post Baseline Cross Short (BS): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 BL Recovery Continuation Long (RL): DiNapoli Stochastic is above middle-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend; then, DiNapoli Stochastic crosses-up over the signal BL Recovery Continuation Short (RS): DiNapoli Stochastic is below middle-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend; then, DiNapoli Stochastic crosses-down under the signal Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Both Initial Long (L): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Initial Short (S): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Continuation Long Confirmation 2 (CL): The imported GKD-C Confirmation 1 indicator is over middle-line, then crosses-up over the signal; DiNapoli Stochastic is over middle-line, then crosses-up over the signal within "Number of Bars Confirmation" bars in the future Continuation Short Confirmation 2 (CS): The imported GKD-C Confirmation 1 indicator is under middle-line, then crosses-down under the signal; DiNapoli Stochastic is under middle-line, then crosses-down under the signal within "Number of Bars Confirmation" bars in the future Post Baseline Cross Long (BL): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Post Baseline Cross Short (BS): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 BL Recovery Continuation Long (RL): The imported GKD-C Confirmation 1 indicator is above middle-line and DiNapoli Stochastic is above middle-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend; then, the imported GKD-C Confirmation 1 crosses-up over its signal, and DiNapoli Stochastic crosses-up over its signal within "Number of Bars Confirmation" bars in the future BL Recovery Continuation Short (RS): The imported GKD-C Confirmation 1 indicator is below middle-line and DiNapoli Stochastic is below middle-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend; then, the imported GKD-C Confirmation 1 crosses-down under its signal, and DiNapoli Stochastic crosses-down under its signal within "Number of Bars Confirmation" bars in the future Confirmation 2 Confluence Background Color Signals; Confirmation Order: Both; Confirmation Type: (continuations don't change from the variations above) Initial Long (L): The imported GKD-C Confirmation 1 indicator crosses-up over middle-line, then DiNapoli Stochastic crosses-up over the middle-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below); OR, DiNapoli Stochastic crosses-up over middle-line, then the imported GKD-C Confirmation 1 indicator crosses-up over the middle-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below) Initial Short (S): The imported GKD-C Confirmation 1 indicator crosses-down under middle-line, then DiNapoli Stochastic crosses-down under the middle-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below); OR, DiNapoli Stochastic crosses-down under middle-line, then the imported GKD-C Confirmation 1 indicator crosses-down under the middle-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below) Post Baseline Cross Long (BL): The imported GKD-C Confirmation 1 crossed-down under middle-line but Baseline is still in uptrend; and, DiNapoli Stochastic crossed-down under middle-line on the same bar or XX bars in the future but Baseline is still in uptrend; then Baseline turns to downtrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below); OR, DiNapoli Stochastic crossed-down under middle-line but Baseline is still in uptrend; and, the imported GKD-C Confirmation 1 crossed-down under middle-line on the same bar or XX bars in the future but Baseline is still in uptrend; then Baseline turns to downtrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below) Post Baseline Cross Short (BS): The imported GKD-C Confirmation 1 crossed-down under middle-line but Baseline is still in uptrend; and, DiNapoli Stochastic crossed-down under middle-line on the same bar or XX bars in the future but Baseline is still in uptrend; then Baseline turns to downtrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below); OR, DiNapoli Stochastic crossed-down under middle-line but Baseline is still in uptrend; and, the imported GKD-C Confirmation 1 crossed-down under middle-line on the same bar or XX bars in the future but Baseline is still in uptrend; then Baseline turns to downtrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below) Solo Confirmation Signals Initial Long (L): DiNapoli Stochastic crosses-up over middle-line Initial Short (S): DiNapoli Stochastic crosses-down under middle-line Continuation Long (CL): DiNapoli Stochastic is over middle-line, then crosses-up over the signal Continuation Short (CS): DiNapoli Stochastic is under middle-line, then crosses-down under the signal Post Baseline Cross Long (BL): DiNapoli Stochastic crossed-up over middle-line but Baseline is still in downtrend, then Baseline turns to uptrend within XX bars Post Baseline Cross Short (BS): DiNapoli Stochastic crossed-down under middle-line but Baseline is still in uptrend, then Baseline turns to downtrend within XX bars BL Recovery Continuation Long (RL): DiNapoli Stochastic above middle-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend while DiNapoli Stochastic is still above middle-line BL Recovery Continuation Short (RS): DiNapoli Stochastic below middle-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend while DiNapoli Stochastic is still below middle-line X-bar Rule settings This rule only applies when this indicator "Confirmation Type" set to "Confirmation 2" Requirements Inputs: Confirmation 1 and Solo Confirmation: GKD-V Volatility/Volume indicator; Confiration 2: GKD-C Confirmation indicator Output: Confirmation 2 and Solo Confirmation: GKD-E Exit indicator; Confiration 1: GKD-C Confirmation indicator Additional features will be added in future releases. This indicator is only available to ALGX Trading VIP group members . You can see the Author's Instructions below to get more information on how to get access.
Pine Script® göstergesi
loxx tarafından
GKD-C Universal Oscillator [Loxx]Giga Kaleidoscope Universal Oscillator Confirmation is a Confirmation module included in Loxx's "Giga Kaleidoscope Modularized Trading System". What is Loxx's "Giga Kaleidoscope Modularized Trading System"? The Giga Kaleidoscope Modularized Trading System is a trading system built on the philosophy of the NNFX (No Nonsense Forex) algorithmic trading. What is an NNFX algorithmic trading strategy? The NNFX algorithm is built on the principles of trend, momentum, and volatility. There are six core components in the NNFX trading algorithm: 1. Volatility - price volatility; e.g., Average True Range, True Range Double, Close-to-Close, etc. 2. Baseline - a moving average to identify price trend (such as "Baseline" shown on the chart above) 3. Confirmation 1 - a technical indicator used to identify trends. This should agree with the "Baseline" 4. Confirmation 2 - a technical indicator used to identify trends. This filters/verifies the trend identified by "Baseline" and "Confirmation 1" 5. Volatility/Volume - a technical indicator used to identify volatility/volume breakouts/breakdown. 6. Exit - a technical indicator used to determine when a trend is exhausted. How does Loxx's GKD (Giga Kaleidoscope Modularized Trading System) implement the NNFX algorithm outlined above? Loxx's GKD v1.0 system has five types of modules (indicators/strategies). These modules are: 1. GKD-BT - Backtesting module (Volatility, Number 1 in the NNFX algorithm) 2. GKD-B - Baseline module (Baseline and Volatility/Volume, Numbers 1 and 2 in the NNFX algorithm) 3. GKD-C - Confirmation 1/2 module (Confirmation 1/2, Numbers 3 and 4 in the NNFX algorithm) 4. GKD-V - Volatility/Volume module (Confirmation 1/2, Number 5 in the NNFX algorithm) 5. GKD-E - Exit module (Exit, Number 6 in the NNFX algorithm) (additional module types will added in future releases) Each module interacts with every module by passing data between modules. Data is passed between each module as described below: GKD-B => GKD-V => GKD-C(1) => GKD-C(2) => GKD-E => GKD-BT That is, the Baseline indicator passes its data to Volatility/Volume. The Volatility/Volume indicator passes its values to the Confirmation 1 indicator. The Confirmation 1 indicator passes its values to the Confirmation 2 indicator. The Confirmation 2 indicator passes its values to the Exit indicator, and finally, the Exit indicator passes its values to the Backtest strategy. This chaining of indicators requires that each module conform to Loxx's GKD protocol, therefore allowing for the testing of every possible combination of technical indicators that make up the six components of the NNFX algorithm. What does the application of the GKD trading system look like? Example trading system: Backtest: Strategy with 1-3 take profits, trailing stop loss, multiple types of PnL volatility, and 2 backtesting styles Baseline: Hull Moving Average Volatility/Volume: Volatility Ratio Confirmation 1: Universal Oscillator as shown on the chart above Confirmation 2: Vortex Exit: Universal Oscillator Each GKD indicator is denoted with a module identifier of either: GKD-BT, GKD-B, GKD-C, GKD-V, or GKD-E. This allows traders to understand to which module each indicator belongs and where each indicator fits into the GKD protocol chain. Now that you have a general understanding of the NNFX algorithm and the GKD trading system. Let's go over what's inside the GKD-E Universal Oscillator itself. What is Universal Oscillator? In his article, "Whiter is Brighter," Dr. Ehlers discusses that market data is akin to "pink noise" (a scientific term that refers to a type of noise where the power spectral density is stronger at lower frequencies). Isolating the white spectrum (whose power spectral density is the same at all frequencies) is said to output data that can be transformed into a zero-lag oscillator. The isolation of the white spectrum data is done via a momentum-based equation. This data is further subjected to Ehlers Super Smoother so that undesirable wave components are eliminated. The filtered data is then transformed into an oscillator by using the automatic gain control algorithm. What's different in this version? This version also includes Loxx's Exotic Source Types. You can read about these sources here: Signals A GKD-C Confirmation indicator can be used as either a Confirmation 1, Confirmation 2, or Solo Confirmation indicator. See step 3 & 4 of the NNFX algorithm above to understand how this indicator fits into the GKD trading system. The Solo Confirmation setting allows you to test this indicator by itself without an additional GKD-C indicator present in the GKD protocol chain. On the chart shown above, this indicator is shown as GKD-C Universal Oscillator and is set to Solo Confirmation. The GKD-B Baseline, GKD-V Volatility Ratio, and this indicator satisfy the first three steps in the GKD trading system chain: GKD-B => GKD-V => GKD-C(solo). Overbought and oversold levels are included for a point of reference and have no bearing on the generated signals. The signals from each of these settings are as follows: Confirmation 1 Signal Initial Long (L): Universal Oscillator crosses-up over zero-line* Initial Short (S): Universal Oscillator crosses-down under zero-line* Continuation Long (CL): Universal Oscillator is over zero-line, then crosses-up over the signal** Continuation Short (CS): Universal Oscillator is under zero-line, then crosses-down under the signal** Post Baseline Cross Long (BL): Universal Oscillator crossed-up over zero-line but Baseline is still in downtrend, then Baseline turns to uptrend within XX bars*** Post Baseline Cross Short (BS): Universal Oscillator crossed-down under zero-line but Baseline is still in uptrend, then Baseline turns to downtrend within XX bars*** BL Recovery Continuation Long (RL): Universal Oscillator is above zero-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend; then, Universal Oscillator crosses-up over the signal**** BL Recovery Continuation Short (RS): Universal Oscillator is below zero-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend; then, Universal Oscillator crosses-down under the signal**** *All signals are shown regardless of Baseline and Volatility/Volume qualification **All signals are shown regardless of Baseline qualification; however, when Baseline filter is active, only true continuations are shown. When the Baseline filter is not active, then all continuations are shown. True continuations are when the Baseline is active and maintains its uptrend/downtrend after the initial cross-up/cross-down over the zero-line respectively. This means that if the Baseline trend then moves against the Universal Oscillator then any continuation signals are voided until another initial Long/Short. All continuations are will either show as regular continuations or be converted into recovery continuations ***All signals are shown regardless of Volatility/Volume qualification ****When the Baseline filter is active, some regular continuations are converted to recovery continuations and are shown. When the Baseline filter is not active, then these signals are not shown. Confirmation 2 Signal Initial Long (L): Universal Oscillator crosses-up over zero-line* Initial Short (S): Universal Oscillator crosses-down under zero-line* Continuation Long (CL): Universal Oscillator is over zero-line, then crosses-up over the signal** Continuation Short (CS): Universal Oscillator is under zero-line, then crosses-down under the signal** Post Baseline Cross Long (BL): Universal Oscillator crossed-up over zero-line but Baseline is still in downtrend, then Baseline turns to uptrend within XX bars*** Post Baseline Cross Short (BS): Universal Oscillator crossed-down under zero-line but Baseline is still in uptrend, then Baseline turns to downtrend within XX bars*** BL Recovery Continuation Long (RL): Universal Oscillator is above zero-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend while Universal Oscillator is still above zero-line; then, Universal Oscillator crosses-up over the signal**** BL Recovery Continuation Short (RS): Universal Oscillator is below zero-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend while Universal Oscillator is still below zero-line; then, Universal Oscillator crosses-down under the signal**** *All signals are shown regardless of Baseline and Volatility/Volume qualification **All signals are shown regardless of Baseline qualification; however, when Baseline filter is active, only true continuations are shown. When the Baseline filter is not active, then all continuations are shown. True continuations are when the Baseline is active and maintains its uptrend/downtrend after the initial cross-up/cross-down over the zero-line respectively. This means that if the Baseline trend then moves against the Universal Oscillator then any continuation signals are voided until another initial Long/Short. All continuations are will either show as regular continuations or be converted into recovery continuations ***All signals are shown regardless of Volatility/Volume qualification ****When the Baseline filter is active, some regular continuations are converted to recovery continuations and are shown. When the Baseline filter is not active, then these signals are not shown. Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Initial Long (L): The imported GKD-C Confirmation 1 indicator crosses-up over zero-line, then Universal Oscillator crosses-up over the zero-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below) Initial Short (S): The imported GKD-C Confirmation 1 indicator crosses-down under zero-line, then Universal Oscillator crosses-down under the zero-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below) Continuation Long Confirmation 1 (CL): The imported GKD-C Confirmation 1 indicator is over zero-line, then crosses-up over the signal Continuation Short Confirmation 1 (CS): The imported GKD-C Confirmation 1 indicator is under zero-line, then crosses-down under the signal Post Baseline Cross Long (BL): The imported GKD-C Confirmation 1 crossed-up over zero-line but Baseline is still in downtrend; and Universal Oscillator crossed-up over zero-line on the same bar or XX bars in the future but Baseline is still in downtrend; then Baseline turns to uptrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below) Post Baseline Cross Short (BS): The imported GKD-C Confirmation 1 crossed-down under zero-line but Baseline is still in uptrend; and, Universal Oscillator crossed-down under zero-line on the same bar or XX bars in the future but Baseline is still in uptrend; then Baseline turns to downtrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below) BL Recovery Continuation Long (RL): The imported GKD-C Confirmation 1 indicator is above zero-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend while Universal Oscillator is still above zero-line; then, The imported GKD-C Confirmation 1 crosses-up over the signal BL Recovery Continuation Short (RS): The imported GKD-C Confirmation 1 indicator is below zero-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend while Universal Oscillator is still below zero-line; then, The imported GKD-C Confirmation 1 crosses-down under the signal Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 2 Initial Long (L): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Initial Short (S): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Continuation Long Confirmation 2 (CL): Universal Oscillator is over zero-line, then crosses-up over the signal Continuation Short Confirmation 2 (CS): Universal Oscillator is under zero-line, then crosses-down under the signal Post Baseline Cross Long (BL): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Post Baseline Cross Short (BS): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 BL Recovery Continuation Long (RL): Universal Oscillator is above zero-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend; then, Universal Oscillator crosses-up over the signal BL Recovery Continuation Short (RS): Universal Oscillator is below zero-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend; then, Universal Oscillator crosses-down under the signal Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Both Initial Long (L): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Initial Short (S): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Continuation Long Confirmation 2 (CL): The imported GKD-C Confirmation 1 indicator is over zero-line, then crosses-up over the signal; Universal Oscillator is over zero-line, then crosses-up over the signal within "Number of Bars Confirmation" bars in the future Continuation Short Confirmation 2 (CS): The imported GKD-C Confirmation 1 indicator is under zero-line, then crosses-down under the signal; Universal Oscillator is under zero-line, then crosses-down under the signal within "Number of Bars Confirmation" bars in the future Post Baseline Cross Long (BL): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Post Baseline Cross Short (BS): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 BL Recovery Continuation Long (RL): The imported GKD-C Confirmation 1 indicator is above zero-line and Universal Oscillator is above zero-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend; then, the imported GKD-C Confirmation 1 crosses-up over its signal, and Universal Oscillator crosses-up over its signal within "Number of Bars Confirmation" bars in the future BL Recovery Continuation Short (RS): The imported GKD-C Confirmation 1 indicator is below zero-line and Universal Oscillator is below zero-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend; then, the imported GKD-C Confirmation 1 crosses-down under its signal, and Universal Oscillator crosses-down under its signal within "Number of Bars Confirmation" bars in the future Confirmation 2 Confluence Background Color Signals; Confirmation Order: Both; Confirmation Type: (continuations don't change from the variations above) Initial Long (L): The imported GKD-C Confirmation 1 indicator crosses-up over zero-line, then Universal Oscillator crosses-up over the zero-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below); OR, Universal Oscillator crosses-up over zero-line, then the imported GKD-C Confirmation 1 indicator crosses-up over the zero-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below) Initial Short (S): The imported GKD-C Confirmation 1 indicator crosses-down under zero-line, then Universal Oscillator crosses-down under the zero-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below); OR, Universal Oscillator crosses-down under zero-line, then the imported GKD-C Confirmation 1 indicator crosses-down under the zero-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below) Post Baseline Cross Long (BL): The imported GKD-C Confirmation 1 crossed-down under zero-line but Baseline is still in uptrend; and, Universal Oscillator crossed-down under zero-line on the same bar or XX bars in the future but Baseline is still in uptrend; then Baseline turns to downtrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below); OR, Universal Oscillator crossed-down under zero-line but Baseline is still in uptrend; and, the imported GKD-C Confirmation 1 crossed-down under zero-line on the same bar or XX bars in the future but Baseline is still in uptrend; then Baseline turns to downtrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below) Post Baseline Cross Short (BS): The imported GKD-C Confirmation 1 crossed-down under zero-line but Baseline is still in uptrend; and, Universal Oscillator crossed-down under zero-line on the same bar or XX bars in the future but Baseline is still in uptrend; then Baseline turns to downtrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below); OR, Universal Oscillator crossed-down under zero-line but Baseline is still in uptrend; and, the imported GKD-C Confirmation 1 crossed-down under zero-line on the same bar or XX bars in the future but Baseline is still in uptrend; then Baseline turns to downtrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below) Solo Confirmation Signals Initial Long (L): Universal Oscillator crosses-up over zero-line Initial Short (S): Universal Oscillator crosses-down under zero-line Continuation Long (CL): Universal Oscillator is over zero-line, then crosses-up over the signal Continuation Short (CS): Universal Oscillator is under zero-line, then crosses-down under the signal Post Baseline Cross Long (BL): Universal Oscillator crossed-up over zero-line but Baseline is still in downtrend, then Baseline turns to uptrend within XX bars Post Baseline Cross Short (BS): Universal Oscillator crossed-down under zero-line but Baseline is still in uptrend, then Baseline turns to downtrend within XX bars BL Recovery Continuation Long (RL): Universal Oscillator above zero-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend while Universal Oscillator is still above zero-line BL Recovery Continuation Short (RS): Universal Oscillator below zero-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend while Universal Oscillator is still below zero-line X-bar Rule settings This rule only applies when this indicator "Confirmation Type" set to "Confirmation 2" Requirements Inputs: Confirmation 1 and Solo Confirmation: GKD-V Volatility/Volume indicator; Confiration 2: GKD-C Confirmation indicator Output: Confirmation 2 and Solo Confirmation: GKD-E Exit indicator; Confiration 1: GKD-C Confirmation indicator Additional features will be added in future releases. This indicator is only available to ALGX Trading VIP group members . You can see the Author's Instructions below to get more information on how to get access.
Pine Script® göstergesi
loxx tarafından
GKD-C Fisher Transform [Loxx]Giga Kaleidoscope Fisher Transform Confirmation is a Confirmation module included in Loxx's "Giga Kaleidoscope Modularized Trading System". What is Loxx's "Giga Kaleidoscope Modularized Trading System"? The Giga Kaleidoscope Modularized Trading System is a trading system built on the philosophy of the NNFX (No Nonsense Forex) algorithmic trading. What is an NNFX algorithmic trading strategy? The NNFX algorithm is built on the principles of trend, momentum, and volatility. There are six core components in the NNFX trading algorithm: 1. Volatility - price volatility; e.g., Average True Range, True Range Double, Close-to-Close, etc. 2. Baseline - a moving average to identify price trend (such as "Baseline" shown on the chart above) 3. Confirmation 1 - a technical indicator used to identify trends. This should agree with the "Baseline" 4. Confirmation 2 - a technical indicator used to identify trends. This filters/verifies the trend identified by "Baseline" and "Confirmation 1" 5. Volatility/Volume - a technical indicator used to identify volatility/volume breakouts/breakdown. 6. Exit - a technical indicator used to determine when a trend is exhausted. How does Loxx's GKD (Giga Kaleidoscope Modularized Trading System) implement the NNFX algorithm outlined above? Loxx's GKD v1.0 system has five types of modules (indicators/strategies). These modules are: 1. GKD-BT - Backtesting module (Volatility, Number 1 in the NNFX algorithm) 2. GKD-B - Baseline module (Baseline and Volatility/Volume, Numbers 1 and 2 in the NNFX algorithm) 3. GKD-C - Confirmation 1/2 module (Confirmation 1/2, Numbers 3 and 4 in the NNFX algorithm) 4. GKD-V - Volatility/Volume module (Confirmation 1/2, Number 5 in the NNFX algorithm) 5. GKD-E - Exit module (Exit, Number 6 in the NNFX algorithm) (additional module types will added in future releases) Each module interacts with every module by passing data between modules. Data is passed between each module as described below: GKD-B => GKD-V => GKD-C(1) => GKD-C(2) => GKD-E => GKD-BT That is, the Baseline indicator passes its data to Volatility/Volume. The Volatility/Volume indicator passes its values to the Confirmation 1 indicator. The Confirmation 1 indicator passes its values to the Confirmation 2 indicator. The Confirmation 2 indicator passes its values to the Exit indicator, and finally, the Exit indicator passes its values to the Backtest strategy. This chaining of indicators requires that each module conform to Loxx's GKD protocol, therefore allowing for the testing of every possible combination of technical indicators that make up the six components of the NNFX algorithm. What does the application of the GKD trading system look like? Example trading system: Backtest: Strategy with 1-3 take profits, trailing stop loss, multiple types of PnL volatility, and 2 backtesting styles Baseline: Hull Moving Average Volatility/Volume: Volatility Ratio Confirmation 1: Fisher Transform as shown on the chart above Confirmation 2: Vortex Exit: Fisher Transform Each GKD indicator is denoted with a module identifier of either: GKD-BT, GKD-B, GKD-C, GKD-V, or GKD-E. This allows traders to understand to which module each indicator belongs and where each indicator fits into the GKD protocol chain. Now that you have a general understanding of the NNFX algorithm and the GKD trading system. Let's go over what's inside the GKD-E Fisher Transform itself. What is Fisher Transform? The Fisher Transform is a technical indicator created by John F. Ehlers that converts prices into a Gaussian normal distribution. The indicator highlights when prices have moved to an extreme, based on recent prices. This may help in spotting turning points in the price of an asset. What's different in this version? This version also includes Loxx's Exotic Source Types. You can read about these sources here: Signals A GKD-C Confirmation indicator can be used as either a Confirmation 1, Confirmation 2, or Solo Confirmation indicator. See step 3 & 4 of the NNFX algorithm above to understand how this indicator fits into the GKD trading system. The Solo Confirmation setting allows you to test this indicator by itself without an additional GKD-C indicator present in the GKD protocol chain. On the chart shown above, this indicator is shown as GKD-C Fisher Transform and is set to Solo Confirmation. The GKD-B Baseline, GKD-V Volatility Ratio, and this indicator satisfy the first three steps in the GKD trading system chain: GKD-B => GKD-V => GKD-C(solo). The signals from each of these settings are as follows: Confirmation 1 Signal Initial Long (L): Fisher crosses-up over zero-line* Initial Short (S): Fisher crosses-down under zero-line* Continuation Long (CL): Fisher is over zero-line, then crosses-up over the signal** Continuation Short (CS): Fisher is under zero-line, then crosses-down under the signal** Post Baseline Cross Long (BL): Fisher crossed-up over zero-line but Baseline is still in downtrend, then Baseline turns to uptrend within XX bars*** Post Baseline Cross Short (BS): Fisher crossed-down under zero-line but Baseline is still in uptrend, then Baseline turns to downtrend within XX bars*** BL Recovery Continuation Long (RL): Fisher is above zero-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend; then, Fisher crosses-up over the signal**** BL Recovery Continuation Short (RS): Fisher is below zero-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend; then, Fisher crosses-down under the signal**** *All signals are shown regardless of Baseline and Volatility/Volume qualification **All signals are shown regardless of Baseline qualification; however, when Baseline filter is active, only true continuations are shown. When the Baseline filter is not active, then all continuations are shown. True continuations are when the Baseline is active and maintains its uptrend/downtrend after the initial cross-up/cross-down over the zero-line respectively. This means that if the Baseline trend then moves against the Fisher Transform then any continuation signals are voided until another initial Long/Short. All continuations are will either show as regular continuations or be converted into recovery continuations ***All signals are shown regardless of Volatility/Volume qualification ****When the Baseline filter is active, some regular continuations are converted to recovery continuations and are shown. When the Baseline filter is not active, then these signals are not shown. Confirmation 2 Signal Initial Long (L): Fisher crosses-up over zero-line* Initial Short (S): Fisher crosses-down under zero-line* Continuation Long (CL): Fisher is over zero-line, then crosses-up over the signal** Continuation Short (CS): Fisher is under zero-line, then crosses-down under the signal** Post Baseline Cross Long (BL): Fisher crossed-up over zero-line but Baseline is still in downtrend, then Baseline turns to uptrend within XX bars*** Post Baseline Cross Short (BS): Fisher crossed-down under zero-line but Baseline is still in uptrend, then Baseline turns to downtrend within XX bars*** BL Recovery Continuation Long (RL): Fisher is above zero-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend while Fisher is still above zero-line; then, Fisher crosses-up over the signal**** BL Recovery Continuation Short (RS): Fisher is below zero-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend while Fisher is still below zero-line; then, Fisher crosses-down under the signal**** *All signals are shown regardless of Baseline and Volatility/Volume qualification **All signals are shown regardless of Baseline qualification; however, when Baseline filter is active, only true continuations are shown. When the Baseline filter is not active, then all continuations are shown. True continuations are when the Baseline is active and maintains its uptrend/downtrend after the initial cross-up/cross-down over the zero-line respectively. This means that if the Baseline trend then moves against the Fisher Transform then any continuation signals are voided until another initial Long/Short. All continuations are will either show as regular continuations or be converted into recovery continuations ***All signals are shown regardless of Volatility/Volume qualification ****When the Baseline filter is active, some regular continuations are converted to recovery continuations and are shown. When the Baseline filter is not active, then these signals are not shown. Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Initial Long (L): The imported GKD-C Confirmation 1 indicator crosses-up over zero-line, then Fisher Transform crosses-up over the zero-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below) Initial Short (S): The imported GKD-C Confirmation 1 indicator crosses-down under zero-line, then Fisher Transform crosses-down under the zero-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below) Continuation Long Confirmation 1 (CL): The imported GKD-C Confirmation 1 indicator is over zero-line, then crosses-up over the signal Continuation Short Confirmation 1 (CS): The imported GKD-C Confirmation 1 indicator is under zero-line, then crosses-down under the signal Post Baseline Cross Long (BL): The imported GKD-C Confirmation 1 crossed-up over zero-line but Baseline is still in downtrend; and Fisher crossed-up over zero-line on the same bar or XX bars in the future but Baseline is still in downtrend; then Baseline turns to uptrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below) Post Baseline Cross Short (BS): The imported GKD-C Confirmation 1 crossed-down under zero-line but Baseline is still in uptrend; and, Fisher crossed-down under zero-line on the same bar or XX bars in the future but Baseline is still in uptrend; then Baseline turns to downtrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below) BL Recovery Continuation Long (RL): The imported GKD-C Confirmation 1 indicator is above zero-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend while Fisher is still above zero-line; then, The imported GKD-C Confirmation 1 crosses-up over the signal BL Recovery Continuation Short (RS): The imported GKD-C Confirmation 1 indicator is below zero-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend while Fisher is still below zero-line; then, The imported GKD-C Confirmation 1 crosses-down under the signal Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 2 Initial Long (L): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Initial Short (S): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Continuation Long Confirmation 2 (CL): Fisher is over zero-line, then crosses-up over the signal Continuation Short Confirmation 2 (CS): Fisher is under zero-line, then crosses-down under the signal Post Baseline Cross Long (BL): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Post Baseline Cross Short (BS): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 BL Recovery Continuation Long (RL): Fisher is above zero-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend; then, Fisher crosses-up over the signal BL Recovery Continuation Short (RS): Fisher is below zero-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend; then, Fisher crosses-down under the signal Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Both Initial Long (L): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Initial Short (S): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Continuation Long Confirmation 2 (CL): The imported GKD-C Confirmation 1 indicator is over zero-line, then crosses-up over the signal; Fisher is over zero-line, then crosses-up over the signal within "Number of Bars Confirmation" bars in the future Continuation Short Confirmation 2 (CS): The imported GKD-C Confirmation 1 indicator is under zero-line, then crosses-down under the signal; Fisher is under zero-line, then crosses-down under the signal within "Number of Bars Confirmation" bars in the future Post Baseline Cross Long (BL): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 Post Baseline Cross Short (BS): same as Confirmation 2 Confluence Background Color Signals; Confirmation Order: Regular; Confirmation Type: Confirmation 1 BL Recovery Continuation Long (RL): The imported GKD-C Confirmation 1 indicator is above zero-line and Fisher is above zero-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend; then, the imported GKD-C Confirmation 1 crosses-up over its signal, and Fisher crosses-up over its signal within "Number of Bars Confirmation" bars in the future BL Recovery Continuation Short (RS): The imported GKD-C Confirmation 1 indicator is below zero-line and Fisher is below zero-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend; then, the imported GKD-C Confirmation 1 crosses-down under its signal, and Fisher crosses-down under its signal within "Number of Bars Confirmation" bars in the future Confirmation 2 Confluence Background Color Signals; Confirmation Order: Both; Confirmation Type: (continuations don't change from the variations above) Initial Long (L): The imported GKD-C Confirmation 1 indicator crosses-up over zero-line, then Fisher Transform crosses-up over the zero-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below); OR, Fisher crosses-up over zero-line, then the imported GKD-C Confirmation 1 indicator crosses-up over the zero-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below) Initial Short (S): The imported GKD-C Confirmation 1 indicator crosses-down under zero-line, then Fisher Transform crosses-down under the zero-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below); OR, Fisher crosses-down under zero-line, then the imported GKD-C Confirmation 1 indicator crosses-down under the zero-line on the same bar or "Number of Bars Confirmation" bars in the future (see X-bar rule below) Post Baseline Cross Long (BL): The imported GKD-C Confirmation 1 crossed-down under zero-line but Baseline is still in uptrend; and, Fisher crossed-down under zero-line on the same bar or XX bars in the future but Baseline is still in uptrend; then Baseline turns to downtrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below); OR, Fisher crossed-down under zero-line but Baseline is still in uptrend; and, the imported GKD-C Confirmation 1 crossed-down under zero-line on the same bar or XX bars in the future but Baseline is still in uptrend; then Baseline turns to downtrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below) Post Baseline Cross Short (BS): The imported GKD-C Confirmation 1 crossed-down under zero-line but Baseline is still in uptrend; and, Fisher crossed-down under zero-line on the same bar or XX bars in the future but Baseline is still in uptrend; then Baseline turns to downtrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below); OR, Fisher crossed-down under zero-line but Baseline is still in uptrend; and, the imported GKD-C Confirmation 1 crossed-down under zero-line on the same bar or XX bars in the future but Baseline is still in uptrend; then Baseline turns to downtrend within "Maximum Allowable PSBC Bars Back" bars (see X-bar rule below) Solo Confirmation Signals Initial Long (L): Fisher crosses-up over zero-line Initial Short (S): Fisher crosses-down under zero-line Continuation Long (CL): Fisher is over zero-line, then crosses-up over the signal Continuation Short (CS): Fisher is under zero-line, then crosses-down under the signal Post Baseline Cross Long (BL): Fisher crossed-up over zero-line but Baseline is still in downtrend, then Baseline turns to uptrend within XX bars Post Baseline Cross Short (BS): Fisher crossed-down under zero-line but Baseline is still in uptrend, then Baseline turns to downtrend within XX bars BL Recovery Continuation Long (RL): Fisher above zero-line. Baseline already crossed down into downtrend, then baseline crosses back up to uptrend while Fisher is still above zero-line BL Recovery Continuation Short (RS): Fisher below zero-line. Baseline already crossed up into uptrend, then baseline crosses back down to downtrend while Fisher is still below zero-line X-bar Rule settings This rule only applies when this indicator "Confirmation Type" set to "Confirmation 2" Requirements Inputs: Confirmation 1 and Solo Confirmation: GKD-V Volatility/Volume indicator; Confirmation 2: GKD-C Confirmation indicator Output: Confirmation 2 and Solo Confirmation: GKD-E Exit indicator; Confirmation 1: GKD-C Confirmation indicator Additional features will be added in future releases. This indicator is only available to ALGX Trading VIP group members . You can see the Author's Instructions below to get more information on how to get access.
Pine Script® göstergesi
loxx tarafından
3
[blackcat] L4 Better Stephen Klinger KVOLevel: 4 Background The Klinger Volume Oscillator (KVO) is a trading indicator that uses both price and volume to identify potential longer-term trend reversal points in the markets. Introduced to the trading community by Stephen Klinger, this indicator measures the trend of cash flow based on volume and price movements. In this version, I enhanced it with better volume indicator colorful bars and better trading strategy to have entries and exits, which can be called as Better Klinger Volume Oscillator (BKVO) Function Although it is designed to measure the longer-term cash flow trend, it can also exhibit short-term fluctuations. This may sound confusing, but a simple version of the Klinger calculation can be better explained as follows: The volume moves through the market in each period Price movements, no matter how small they are taken into account The Klinger oscillator uses the lowest, highest, and closing prices The calculation is based on price and volume and is called volume force (VF). We then get an oscillator derived from the VF Slow 55 EMA and Fast 34 EMA (plus a 13 EMA signal line). There are four main ways traders use the BKVO to trade in the markets: Trend direction Buy and sell trading signals Bullish and bearish divergence Colorful volume bars to indicate trend status Trend direction When using the Klinger oscillator for trend, there are two ways to do it. The first method is to wait for the KVO indicator line, not the signal line, to cross the zero line. Traders can also use an intersection of the signal line with the KVO line as a directional sign. It's a little more aggressive. Traders would only consider long or short trades depending on the KVO line relationship with the zero line. Aggressive traders can buy or sell when the trend changes, keeping their strategy objective. Buy and sell trading signals When we use the actual trading signal indicator we are using the signal line the same way we would trade the moving average convergence divergence (MACD) crosses. If you traded every crossover, you can see that you are in draw down and caught in whipsaw. This is not the way to use the original version of KVO as a strategy. Due to original version may produce too many fake crosses. I prefer to use volume bars to display the trends with proper entry and exit alerts. However, it could be better if you can use your own experience and skills to utilize this indicator subjectively besides inherent alerts provided. Klinger Divergence Trading Divergence is essentially technical indicators showing one direction and price doing another. If you see the price chart heading upwards while the Klinger indicator has crossed the signal line and heading towards zero. This would be bearish divergence. Bullish divergence is the opposite. I designed divergence indicator inside. However, they are turned off in default and you have to turn them on by yourself if you think they are helpful. Colorful volume bars Volume has to be the most underrated market variable used in technical analysis. But if you know how to analyze and interpret them, you can watch market turning points develop and anticipate setbacks and trend changes. You can find out if the pros are buying or selling by analyzing: Transaction volume at the bid or ask price High to lower area of ​​the bar and Average trade size. The colorful volume bars improves your typical volume histogram by coloring the bars based on 5 criteria: Volume Climax Up - high volume, high range, up bar (red) Volume Climax Down - high volume, high range, down bar (white) High Volume Churn - bars with high volume and low range (green) Low Volume - bar for low volume (yellow) Volume Climax plus High Volume Churn - both of the above conditions (fuchsia) When there are no volume signals, the default color of the histogram bar is cyan/aqua. Key Signal KVO Volume Climax up/ Peak Up (Red Bar) Volume Climax Up bars are identified by multiplying the buy volume (traded on ask) by the range and then looking for the highest value in the last 8 bars (default setting). Volume Climax Up bars indicate a large volume demand leading to rising prices. By default, the bars are colored red. Volume climax up bars are typically displayed when: The starting signal for upward trends The end of the uptrends and Pullbacks during downtrends. The beginning of an uptrend is almost always marked by a Volume Climax Up bar. This shows that buyers like to get in and bring large quantities to market and raise prices quickly. A valid breakout should be followed by further buying, but occasionally it will test the low of the volume climax up bar. Market highs are also indicated by Volume Climax Up bars, often with high volume and / or low volume test patterns. Trend changes usually take a while to develop, so don't get pulled into it too soon - wait for the market to run out. One useful signal to look out for is the low volume bar - this shows that there is finally no demand and the market is likely to stop moving. During a downtrend, pullbacks are often indicated by Volume Climax Up bars. These show short covers or traders calling a bottom too quickly. As soon as this Climax volume decreases, the downward trend is likely to continue. The continuation of the downtrend is confirmed when the low of the Volume Climax Up bar is taken out. KVO volume Climax Down/ Peak Down (White Bar) Volume Climax Down bars are essentially the opposite of Volume Climax Up bars. Volume Climax Down bars are identified by multiplying the sales volume (traded at bid) by the range and then finding the highest value in the last 8 bars (default). Volume Climax Down bars indicate a large supply that is pushing prices down. The default setting is the white color of the bars. Volume climax down bars are usually displayed when: The beginning of the down trends The end of the down trends and Pullbacks on uptrends. The beginning of a downtrend is almost always marked by a Volume Climax Down bar. This shows that the sellers are happy to join in and that large quantities come onto the market and that prices are quickly depressed. A valid breakdown should be followed by more sales, but occasionally the high of the Volume Climax Down bar is tested. Market lows are also indicated by Volume Climax Down bars, often with low volume churn and / or test patterns. Trend changes usually take a while to develop, so don't get pulled into it too soon - wait for the market to run out. One useful signal to look out for is the low volume bar - it shows that there is finally no supply and the market is likely to stop falling. During an uptrend, pullbacks are often indicated by Volume Climax Down bars. These show profit taking or traders calling a top too quickly. As soon as this Climax volume drops, the uptrend will likely resume. The continuation of the uptrend will be confirmed when the high of the Volume Climax Down bar is removed. KVO High volume churn (Green Bars) High volume churn bars are identified by dividing the volume by the high to low range of the bar and then looking for the highest value in the last 8 bars (default). High volume churn bars indicate profit taking, new supply at the top, or new demand at the bottom of the market. The standard setting is that the bars of the volume histogram are colored green. High volume churn bars are typically seen at: The end of the uptrends The end of the down trends and Mid-trend profit-taking. When volume churn is high, it means that demand is being met by new supply on top or supply is being met by new demand on the bottom - the price cannot actually go up when new supply or demand comes into the market. Hence the bar is low from top to bottom. Occasionally Volume Climax (up or down) and High Volume Churn bars coincide and these bars are magenta in color. Beware of intra-day charts. The high volume churn often occurs on the last bars of the trading day. This does not necessarily represent a possible turning point, but a high volume of day traders closing positions. KVO Low Volume (Yellow Bar) Low volume bars are identified by looking for the lowest volume in the last 8 bars (default). Low volume bars indicate a lack of demand at the highs or a lack of supply at the lows. The default setting is to color the bars yellow. Low volume bars are usually displayed when: The end of the uptrends The end of the down trends and Pullbacks right in the middle of the trend. Low volume bars are important volume indicator signal for trend reversal. They are very useful for confirming indicators of a change in trend direction when the market is testing a high or a low. KVO High Volume Churn + Climax (Fuchsia Bar) This is a mixture of KVO High volume churn (Green Bars) and KVO Volume Climax up/ Peak Up (Red Bar) or KVO volume Climax Down/ Peak Down (White Bar). KVO No Volume Signal (Cyan/Aqua Bar) There is no volume featured signal produced by the indicator. Remarks This is a Level 4 invite-only and closed source indicator. Redeem rule: constant 350 tradingview coins per month and 350X10 tradingview coins per year.
Pine Script® göstergesi
blackcat1402 tarafından
23
Waindrops [Makit0]█  OVERALL Plot waindrops (custom volume profiles) on user defined periods, for each period you get high and low, it slices each period in half to get independent vwap, volume profile and the volume traded per price at each half. It works on intraday charts only, up to 720m (12H). It can plot balanced or unbalanced waindrops, and volume profiles up to 24H sessions. As example you can setup unbalanced periods to get independent volume profiles for the overnight and cash sessions on the futures market, or 24H periods to get the full session volume profile of EURUSD The purpose of this indicator is twofold: 1 — from a Chartist point of view, to have an indicator which displays the volume in a more readable way 2 — from a Pine Coder point of view, to have an example of use for two very powerful tools on Pine Script:    • the recently updated drawing limit to 500 (from 50)    • the recently ability to use drawings arrays (lines and labels) If you are new to Pine Script and you are learning how to code, I hope you read all the code and comments on this indicator, all is designed for you, the variables and functions names, the sometimes too big explanations, the overall structure of the code, all is intended as an example on how to code in Pine Script a specific indicator from a very good specification in form of white paper If you wanna learn Pine Script form scratch just start HERE In case you have any kind of problem with Pine Script please use some of the awesome resources at our disposal: USRMAN , REFMAN , AWESOMENESS , MAGIC █  FEATURES Waindrops are a different way of seeing the volume and price plotted in a chart, its a volume profile indicator where you can see the volume of each price level plotted as a vertical histogram for each half of a custom period. By default the period is 60 so it plots an independent volume profile each 30m You can think of each waindrop as an user defined candlestick or bar with four key values:  • high of the period  • low of the period  • left vwap (volume weighted average price of the first half period)  • right vwap (volume weighted average price of the second half period) The waindrop can have 3 different colors (configurable by the user):  • GREEN: when the right vwap is higher than the left vwap (bullish sentiment )  • RED: when the right vwap is lower than the left vwap (bearish sentiment )  • BLUE: when the right vwap is equal than the left vwap ( neutral sentiment ) KEY FEATURES  • Help menu  • Custom periods  • Central bars  • Left/Right VWAPs  • Custom central bars and vwaps: color and pixels  • Highly configurable volume histogram: execution window, ticks, pixels, color, update frequency and fine tuning the neutral meaning  • Volume labels with custom size and color  • Tracking price dot to be able to see the current price when you hide your default candlesticks or bars █  SETTINGS Click here or set any impar period to see the HELP INFO : show the HELP INFO, if it is activated the indicator will not plot PERIOD SIZE (max 2880 min) : waindrop size in minutes, default 60, max 2880 to allow the first half of a 48H period as a full session volume profile BARS : show the central and vwap bars, default true    Central bars : show the central bars, default true    VWAP bars : show the left and right vwap bars, default true    Bars pixels : width of the bars in pixels, default 2    Bars color mode : bars color behavior    • BARS : gets the color from the 'Bars color' option on the settings panel    • HISTOGRAM : gets the color from the Bearish/Bullish/Neutral Histogram color options from the settings panel    Bars color : color for the central and vwap bars, default white HISTOGRAM show the volume histogram, default true    Execution window (x24H) : last 24H periods where the volume funcionality will be plotted, default 5    Ticks per bar (max 50) : width in ticks of each histogram bar, default 2    Updates per period : number of times the histogram will update    • ONE : update at the last bar of the period    • TWO : update at the last bar of each half period    • FOUR : slice the period in 4 quarters and updates at the last bar of each of them    • EACH BAR : updates at the close of each bar    Pixels per bar : width in pixels of each histogram bar, default 4    Neutral Treshold (ticks) : delta in ticks between left and right vwaps to identify a waindrop as neutral, default 0    Bearish Histogram color : histogram color when right vwap is lower than left vwap, default red    Bullish Histogram color : histogram color when right vwap is higher than left vwap, default green    Neutral Histogram color : histogram color when the delta between right and left vwaps is equal or lower than the Neutral treshold, default blue VOLUME LABELS : show volume labels    Volume labels color : color for the volume labels, default white    Volume Labels size : text size for the volume labels, choose between AUTO, TINY, SMALL, NORMAL or LARGE, default TINY TRACK PRICE : show a yellow ball tracking the last price, default true █  LIMITS This indicator only works on intraday charts (minutes only) up to 12H (720m), the lower chart timeframe you can use is 1m This indicator needs price, time and volume to work, it will not work on an index (there is no volume), the execution will not be allowed The histogram (volume profile) can be plotted on 24H sessions as limit but you can plot several 24H sessions █  ERRORS AND PERFORMANCE Depending on the choosed settings, the script performance will be highly affected and it will experience errors Two of the more common errors it can throw are:  • Calculation takes too long to execute  • Loop takes too long The indicator performance is highly related to the underlying volatility (tick wise), the script takes each candlestick or bar and for each tick in it stores the price and volume, if the ticker in your chart has thousands and thousands of ticks per bar the indicator will throw an error for sure, it can not calculate in time such amount of ticks. What all of that means? Simply put, this will throw error on the BITCOIN pair BTCUSD (high volatility with tick size 0.01) because it has too many ticks per bar, but lucky you it will work just fine on the futures contract BTC1! (tick size 5) because it has a lot less ticks per bar There are some options you can fine tune to boost the script performance, the more demanding option in terms of resources consumption is Updates per period , by default is maxed out so lowering this setting will improve the performance in a high way. If you wanna know more about how to improve the script performance, read the HELP INFO accessible from the settings panel █  HOW-TO SETUP The basic parameters to adjust are Period size , Ticks per bar and Pixels per bar  • Period size is the main setting, defines the waindrop size, to get a better looking histogram set bigger period and smaller chart timeframe  • Ticks per bar is the tricky one, adjust it differently for each underlying (ticker) volatility wise, for some you will need a low value, for others a high one.    To get a more accurate histogram set it as lower as you can (min value is 1)  • Pixels per bar allows you to adjust the width of each histogram bar, with it you can adjust the blank space between them or allow overlaping You must play with these three parameters until you obtain the desired histogram: smoother, sharper, etc... These are some of the different kind of charts you can setup thru the settings:  • Balanced Waindrops (default): charts with waindrops where the two halfs are of same size.    This is the default chart, just select a period (30m, 60m, 120m, 240m, pick your poison), adjust the histogram ticks and pixels and watch  • Unbalanced Waindrops: chart with waindrops where the two halfs are of different sizes.    Do you trade futures and want to plot a waindrop with the first half for the overnight session and the second half for the cash session? you got it;    just adjust the period to 1860 for any CME ticker (like ES1! for example) adjust the histogram ticks and pixels and watch  • Full Session Volume Profile: chart with waindrops where only the first half plots.    Do you use Volume profile to analize the market? Lucky you, now you can trick this one to plot it, just try a period of 780 on SPY, 2760 on ES1!, or 2880 on EURUSD    remember to adjust the histogram ticks and pixels for each underlying  • Only Bars: charts with only central and vwap bars plotted, simply deactivate the histogram and volume labels  • Only Histogram: charts with only the histogram plotted (volume profile charts), simply deactivate the bars and volume labels  • Only Volume: charts with only the raw volume numbers plotted, simply deactivate the bars and histogram If you wanna know more about custom full session periods for different asset classes, read the HELP INFO accessible from the settings panel EXAMPLES Full Session Volume Profile on MES 5m chart: Full Session Unbalanced Waindrop on MNQ 2m chart (left side Overnight session, right side Cash Session): The following examples will have the exact same charts but on four different tickers representing a futures contract, a forex pair, an etf and a stock. We are doing this to be able to see the different parameters we need for plotting the same kind of chart on different assets The chart composition is as follows:  • Left side: Volume Labels chart (period 10)  • Upper Right side: Waindrops (period 60)  • Lower Right side: Full Session Volume Profile The first example will specify the main parameters, the rest of the charts will have only the differences MES :  • Left: Period size: 10, Bars: uncheck, Histogram: uncheck, Execution window: 1, Ticks per bar: 2, Updates per period: EACH BAR,    Pixels per bar: 4, Volume labels: check, Track price: check  • Upper Right: Period size: 60, Bars: check, Bars color mode: HISTOGRAM, Histogram: check, Execution window: 2, Ticks per bar: 2,    Updates per period: EACH BAR, Pixels per bar: 4, Volume labels: uncheck, Track price: check  • Lower Right: Period size: 2760, Bars: uncheck, Histogram: check, Execution window: 1, Ticks per bar: 1, Updates per period: EACH BAR,    Pixels per bar: 2, Volume labels: uncheck, Track price: check EURUSD :  • Upper Right: Ticks per bar: 10  • Lower Right: Period size: 2880, Ticks per bar: 1, Pixels per bar: 1 SPY :  • Left: Ticks per bar: 3  • Upper Right: Ticks per bar: 5, Pixels per bar: 3  • Lower Right: Period size: 780, Ticks per bar: 2, Pixels per bar: 2 AAPL :  • Left: Ticks per bar: 2  • Upper Right: Ticks per bar: 6, Pixels per bar: 3  • Lower Right: Period size: 780, Ticks per bar: 1, Pixels per bar: 2 █  THANKS TO PineCoders for all they do, all the tools and help they provide and their involvement in making a better community scarf for the idea of coding a waindrops like indicator, I did not know something like that existed at all All the Pine Coders, Pine Pros and Pine Wizards, people who share their work and knowledge for the sake of it and helping others, I'm very grateful indeed I'm learning at each step of the way from you all, thanks for this awesome community; Opensource and shared knowledge: this is the way! (said with canned voice from inside my helmet :D) █  NOTE This description was formatted following THIS guidelines ═════════════════════════════════════════════════════════════════════════ I sincerely hope you enjoy reading and using this work as much as I enjoyed developing it :D GOOD LUCK AND HAPPY TRADING!
Pine Script® göstergesi
makit0 tarafından
108
Delta Volume Columns Pro [LucF]█  OVERVIEW This indicator displays volume​​ delta information calculated with intrabar inspection on historical bars, and feed updates when running in realtime. It is designed to run in a pane and can display either stacked buy/sell volume​ columns or a signal line which can be calculated and displayed in many different ways. Five different models are offered to reveal different characteristics of the calculated volume​ delta information. Many options are offered to visualize the calculations, giving you much leeway in morphing the indicator's visuals to suit your needs. If you value delta volume​ information, I hope you will find the time required to master Delta Volume​ Columns Pro well worth the investment. I am confident that if you combine a proper understanding of the indicator's information with an intimate knowledge of the volume​ idiosyncrasies on the markets you trade, you can extract useful market intelligence using this tool. █  WARNINGS 1. The indicator only works on markets where volume​ information is available,   Please validate that your symbol's feed carries volume​ information before asking me why the indicator doesn't plot values. 2. When you refresh your chart or re-execute the script on the chart, the indicator will repaint because elapsed realtime bars will then recalculate as historical bars. 3. Because the indicator uses different modes of calculation on historical and realtime bars, it's critical that you understand the differences between them. Details are provided further down. 4. Calculations using intrabar inspection on historical bars can only be done from some chart timeframes. See further down for a list of supported timeframes.   If the chart's timeframe is not supported, no historical volume​ delta will display. █  CONCEPTS Chart bars Three different types of bars are used in charts:  1. Historical bars are bars that have already closed when the script executes on them.  2. The realtime bar is the current, incomplete bar where a script is running on an open market. There is only one active realtime bar on your chart at any given time.    The realtime bar is where alerts trigger.  3. Elapsed realtime bars are bars that were calculated when they were realtime bars but have since closed.    When a script re-executes on a chart because the browser tab is refreshed or some of its inputs are changed, elapsed realtime bars are recalculated as historical bars. Why does this indicator use two modes of calculation? Historical bars on TradingView charts contain OHLCV data only, which is insufficient to calculate volume​ delta on them with any level of precision. To mine more detailed information from those bars we look at intrabars , i.e., bars from a smaller timeframe (we call it the intrabar timeframe ) that are contained in one chart bar. If your chart Is running at 1D on a 24x7 market for example, most 1D chart bars will contain 24 underlying 1H bars in their dilation. On historical bars, this indicator looks at those intrabars to amass volume​ delta information. If the intrabar is up, its volume​ goes in the Buy bin, and inversely for the Sell bin. When price does not move on an intrabar, the polarity of the last known movement is used to determine in which bin its volume​ goes. In realtime, we have access to price and volume​ change for each update of the chart. Because a 1D chart bar can be updated tens of thousands of times during the day, volume​ delta calculations on those updates is much more precise. This precision, however, comes at a price:  — The script must be running on the chart for it to keep calculating in realtime.  — If you refresh your chart you will lose all accumulated realtime calculations on elapsed realtime bars, and the realtime bar.   Elapsed realtime bars will recalculate as historical bars, i.e., using intrabar inspection, and the realtime bar's calculations will reset.   When the script recalculates elapsed realtime bars as historical bars, the values on those bars will change, which means the script repaints in those conditions.  — When the indicator first calculates on a chart containing an incomplete realtime bar, it will count ALL the existing volume​ on the bar as Buy or Sell volume​,   depending on the polarity of the bar at that point. This will skew calculations for that first bar. Scripts have no access to the history of a realtime bar's previous updates,   and intrabar inspection cannot be used on realtime bars, so this is the only to go about this.  — Even if alerts only trigger upon confirmation of their conditions after the realtime bar closes, they are repainting alerts   because they would perhaps not have calculated the same way using intrabar inspection.  — On markets like stocks that often have different EOD​ and intraday feeds and volume​ information,   the volume's scale may not be the same for the realtime bar if your chart is at 1D, for example,   and the indicator is using an intraday timeframe to calculate on historical bars.  — Any chart timeframe can be used in realtime mode, but plots that include moving averages in their calculations may require many elapsed realtime bars before they can calculate.   You might prefer drastically reducing the periods of the moving averages, or using the volume​ columns mode, which displays instant values, instead of the line. Volume Delta Balances This indicator uses a variety of methods to evaluate five volume​ delta balances and derive other values from those balances. The five balances are: 1 — On Bar Balance : This is the only balance using instant values; it is simply the subtraction of the Sell volume​ from the Buy volume​ on the bar. 2 — Average Balance : Calculates a distinct EMA for both the Buy and Sell volumes, and subtracts the Sell EMA from the Buy EMA. 3 — Momentum Balance : Starts by calculating, separately for both Buy and Sell volumes, the difference between the same EMAs used in "Average Balance" and   an SMA of double the period used for the "Average Balance" EMAs. The difference for the Sell side is subtracted from the difference for the Buy side,   and an RSI of that value is calculated and brought over the −50/+50 scale. 4 — Relative Balance : The reference values used in the calculation are the Buy and Sell EMAs used in the "Average Balance".   From those, we calculate two intermediate values using how much the instant Buy and Sell volumes on the bar exceed their respective EMA — but with a twist.   If the bar's Buy volume​ does not exceed the EMA of Buy volume​, a zero value is used. The same goes for the Sell volume​ with the EMA of Sell volume​.   Once we have our two intermediate values for the Buy and Sell volumes exceeding their respective MA, we subtract them. The final "Relative Balance" value is an ALMA of that subtraction.   The rationale behind using zero values when the bar's Buy/Sell volume​ does not exceed its EMA is to only take into account the more significant volume​.   If both instant volume​ values exceed their MA, then the difference between the two is the signal's value.   The signal is called "relative" because the intermediate values are the difference between the instant Buy/Sell volumes and their respective MA.   This balance flatlines when the bar's Buy/Sell volumes do not exceed their EMAs, which makes it useful to spot areas where trader interest dwindles, such as consolidations.   The smaller the period of the final value's ALMA, the more easily you will see the balance flatline. These flat zones should be considered no-trade zones. 5 — Percent Balance : This balance is the ALMA of the ratio of the "On Bar Balance" value, i.e., the volume​ delta balance on the bar (which can be positive or negative),   over the total volume for that bar. From the balances and marker conditions, two more values are calculated: 1 — Marker Bias : It sums the up/down (+1/‒1) occurrences of the markers 1 to 4 over a period you define, so it ranges from −4 to +4, times the period.   Its calculation will depend on the modes used to calculate markers 3 and 4. 2 — Combined Balances : This is the sum of the bull/bear (+1/−1) states of each of the five balances, so it ranges from −5 to +5. █  FEATURES The indicator has two main modes of operation: Columns and Line . Columns • In Columns mode you can display stacked Buy/Sell volume​ columns. • The buy section always appears above the centerline, the sell section below. • The top and bottom sections can be colored independently using eight different methods. • The EMAs of the Buy/Sell values can be displayed (these are the same EMAs used to calculate the "Average Balance"). Line • Displays one of seven signals: the five balances or one of two complementary values, i.e., the "Marker Bias" or the "Combined Balances". • You can color the line and its fill using independent calculation modes to pack more information in the display.  You can thus appraise the state of 3 different values using the line itself, its color and the color of its fill. • A "Divergence Levels" feature will use the line to automatically draw expanding levels on divergence events. Default settings Using the indicator's default settings, this is the information displayed: • The line is calculated on the "Average Balance". • The line's color is determined by the bull/bear state of the "Percent Balance". • The line's fill gradient is determined by the advances/declines of the "Momentum Balance". • The orange divergence dots are calculated using discrepancies between the polarity of the "On Bar Balance" and the chart's bar. • The divergence levels are determined using the line's level when a divergence occurs. • The background's fill gradient is calculated on advances/declines of the "Marker Bias". • The chart bars are colored using advances/declines of the "Relative Balance". Divergences are shown in orange. • The intrabar timeframe is automatically determined from the chart's timeframe so that a minimum of 50 intrabars are used to calculate volume​ delta on historical bars. Alerts The configuration of the marker conditions explained further is what determines the conditions that will trigger alerts created from this script. Note that simply selecting the display of markers does not create alerts. To create an alert on this script, you must use ALT-A from the chart. You can create multiple alerts triggering on different conditions from this same script; simply configure the markers so they define the trigger conditions for each alert before creating the alert. The configuration of the script's inputs is saved with the alert, so from then on you can change them without affecting the alert. Alert messages will mention the marker(s) that triggered the specific alert event. Keep in mind, when creating alerts on small chart timeframes, that discrepancies between alert triggers and markers displayed on your chart are to be expected. This is because the alert and your chart are running two distinct instances of the indicator on different servers and different feeds. Also keep in mind that while alerts only trigger on confirmed conditions, they are calculated using realtime calculation mode, which entails that if you refresh your chart and elapsed realtime bars recalculate as historical bars using intrabar inspection, markers will not appear in the same places they appeared in realtime. So it's important to understand that even though the alert conditions are confirmed when they trigger, these alerts will repaint. Let's go through the sections of the script's inputs. Columns The size of the Buy/Sell columns always represents their respective importance on the bar, but the coloring mode for tops and bottoms is independent. The default setup uses a standard coloring mode where the Buy/Sell columns are always in the bull/bear color with a higher intensity for the winning side. Seven other coloring modes allow you to pack more information in the columns. When choosing to color the top columns using a bull/bear gradient on "Average Balance", for example, you will have bull/bear colored tops. In order for the color of the bottom columns to continue to show the instant bar balance, you can then choose the "On Bar Balance — Dual Solid Colors" coloring mode to make those bars the color of the winning side for that bar. You can display the averages of the Buy and Sell columns. If you do, its coloring is controlled through the "Line" and "Line fill" sections below. Line and Line fill You can select the calculation mode and the thickness of the line, and independent calculations to determine the line's color and fill. Zero Line The zero line can display dots when all five balances are bull/bear. Divergences You first select the detection mode. Divergences occur whenever the up/down direction of the signal does not match the up/down polarity of the bar. Divergences are used in three components of the indicator's visuals: the orange dot, colored chart bars, and to calculate the divergence levels on the line. The divergence levels are dynamic levels that automatically build from the line's values on divergence events. On consecutive divergences, the levels will expand, creating a channel. This implementation of the divergence levels corresponds to my view that divergences indicate anomalies, hesitations, points of uncertainty if you will. It precludes any attempt to identify a directional bias to divergences. Accordingly, the levels merely take note of divergence events and mark those points in time with levels. Traders then have a reference point from which they can evaluate further movement. The bull/bear/neutral colors used to plot the levels are also congruent with this view in that they are determined by the line's position relative to the levels, which is how I think divergences can be put to the most effective use. One of the coloring modes for the line's fill uses advances/declines in the line after divergence events. Background The background can show a bull/bear gradient on six different calculations. As with other gradients, you can adjust its brightness to make its importance proportional to how you use it in your analysis. Chart bars Chart bars can be colored using seven different methods. You have the option of emptying the body of bars where volume​ does not increase, as does my TLD indicator, and you can choose whether you want to show divergences. Intrabar Timeframe This is the intrabar timeframe that will be used to calculate volume​ delta using intrabar inspection on historical bars. You can choose between four modes. The three "Auto-steps" modes calculate, from the chart's timeframe, the intrabar timeframe where the said number of intrabars will make up the dilation of chart bars. Adjustments are made for non-24x7 markets. "Fixed" mode allows you to select the intrabar timeframe you want. Checking the "Show TF" box will display in the lower-right corner the intrabar timeframe used at any given moment. The proper selection of the intrabar timeframe is important. It must achieve maximal granularity to produce precise results while not unduly slowing down calculations, or worse, causing runtime errors. Note that historical depth will vary with the intrabar timeframe. The smaller the timeframe, the shallower historical plots you will be. Markers Markers appear when the required condition has been confirmed on a closed bar. The configuration of the markers when you create an alert is what determines when the alert will trigger. Five markers are available: • Balances Agreement : All five balances are either bullish​ or bearish​. • Double Bumps : A double bump is two consecutive up/down bars with +/‒ volume​​ delta, and rising Buy/Sell volume​ above its average. • Divergence confirmations : A divergence is confirmed up/down when the chosen balance is up/down on the previous bar when that bar was down/up, and this bar is up/down. • Balance Shifts : These are bull/bear transitions of the selected signal. • Marker Bias Shifts : Marker bias shifts occur when it crosses into bull/bear territory. Periods Allows control over the periods of the different moving averages used to calculate the balances. Volume​ Discrepancies Stock exchanges do not report the same volume​ for intraday and daily (or higher) resolutions. Other variations in how volume​ information is reported can also occur in other markets, namely Forex, where volume​ irregularities can even occur between different intraday timeframes. This will cause discrepancies between the total volume​ on the bar at the chart's timeframe, and the total volume​​ calculated by adding the volume​​ of the intrabars in that bar's dilation. This does not necessarily invalidate the volume​​ delta information calculated from intrabars, but it tells us that we are using partial volume​ data. A mechanism to detect chart vs intrabar timeframe volume​​ discrepancies is provided. It allows you to define a threshold percentage above which the background will indicate a difference has been detected. Other Settings You can control here the display of the gray dot reminder on realtime bars, and the display of error messages if you are using a chart timeframe that is not greater than the fixed intrabar timeframe, when you use that mode. Disabling the message can be useful if you only use realtime mode at chart timeframes that do not support intrabar inspection. █  RAMBLINGS On Volume​ Delta Volume​ is arguably the best complement to interpret price action, and I consider volume​ delta to be the most effective way of processing volume​ information. In periods of low-volatility price consolidations, volume​ will typically also be lower than normal, but slight imbalances in the trend of the buy/sell volume​ balance can sometimes help put early odds on the direction of the break from consolidation. Additionally, the progression of the volume​ imbalance can help determine the proximity of the breakout. I also find volume​ delta and the number of divergences very useful to evaluate the strength of trends. In trends, I am looking for "slow and steady", i.e., relatively low volatility​ and pauses where price action doesn't look like world affairs are being reassessed. In my personal mythology, this type of trend is often more resilient than high-volatility breakouts, especially when volume​ balance confirms the general agreement of traders signaled by the low-volatility usually accompanying this type of trend. The volume​ action on pauses will often help me decide between aggressively taking profits, tightening a stop or going for a longer-term movement. As for reversals, they generally occur in high-volatility areas where entering trades is more expensive and riskier. While the identification of counter-trend reversals fascinates many traders to no end, they represent poor opportunities in my view. Volume​ imbalances often precede reversals, but I prefer to use volume​ delta information to identify the areas following reversals where I can confirm them and make relatively low-cost entries with better odds. On "Buy/Sell" Volume Buying or selling volume​ are misnomers, as every unit of volume​ transacted is both bought and sold by two different traders. While this does not keep me from using the terms, there is no such thing as “buy only” or “sell only” volume​. Trader lingo is riddled with peculiarities. Divergences The divergence detection method used here relies on a difference between the direction of a signal and the polarity (up/down) of a chart bar. When using the default "On Bar Balance" to detect divergences, however, only the bar's volume​ delta is used. You may wonder how there can be divergences between buying/selling volume​ information and price movement on one bar. This will sometimes be due to the calculation's shortcomings, but divergences may also occur in instances where because of order book structure, it takes less volume​ to increase the price of an asset than it takes to decrease it. As usual, divergences are points of interest because they reveal imbalances, which may or may not become turning points. To your pattern-hungry brain, the divergences displayed by this indicator will — as they do on other indicators — appear to often indicate turnarounds. My opinion is that reality is generally quite sobering and I have no reliable information that would tend to prove otherwise. Exercise caution when using them. Consequently, I do not share the overwhelming enthusiasm of traders in identifying bullish​/bearish​ divergences. For me, the best course of action when a divergence occurs is to wait and see what happens from there. That is the rationale underlying how my divergence levels work; they take note of a signal's level when a divergence occurs, and it's the signal's behavior from that point on that determines if the post-divergence action is bullish​/bearish​. Superfluity In "The Bed of Procrustes", Nassim Nicholas Taleb writes: To bankrupt a fool, give him information . This indicator can display lots of information. While learning to use a new indicator inevitably requires an adaptation period where we put it through its paces and try out all its options, once you have become used to it and decide to adopt it, rigorously eliminate the components you don't use and configure the remaining ones so their visual prominence reflects their relative importance in your analysis. I tried to provide flexible options for traders to control this indicator's visuals for that exact reason — not for window dressing. █  LIMITATIONS • This script uses a special characteristic of the `security()` function allowing the inspection of intrabars — which is not officially supported by TradingView.  It has the advantage of permitting a more robust calculation of volume​ delta than other methods on historical bars, but also has its limits. • Intrabar inspection only works on some chart timeframes: 3, 5, 10, 15 and 30 minutes, 1, 2, 3, 4, 6, and 12 hours, 1 day, 1 week and 1 month.  The script’s code can be modified to run on other resolutions. • When the difference between the chart’s timeframe and the intrabar timeframe is too great, runtime errors will occur. The Auto-Steps selection mechanisms should avoid this. • All volume​ is not created equally. Its source, components, quality and reliability will vary considerably with sectors and instruments.  The higher the quality, the more reliably volume​ delta information can be used to guide your decisions.  You should make it your responsibility to understand the volume​ information provided in the data feeds you use. It will help you make the most of volume​ delta. █  NOTES For traders • The Data Window shows key values for the indicator. • While this indicator displays some of the same information calculated in my Delta Volume Columns ,  I have elected to make it a separate publication so that traders continue to have a simpler alternative available to them. Both code bases will continue to evolve separately. • All gradients used in this indicator determine their brightness intensities using advances/declines in the signal—not their relative position in a pre-determined scale. • Volume​ delta being relative, by nature, it is particularly well-suited to Forex markets, as it filters out quite elegantly the cyclical volume​ data characterizing the sector. If you are interested in volume​ delta, consider having a look at my other "Delta Volume" indicators: • Delta Volume Realtime Action displays realtime volume​ delta and tick information on the chart. • Delta Volume Candles builds volume​​ delta candles on the chart. • Delta Volume Columns is a simpler version of this indicator. For coders • I use the `f_c_gradientRelativePro()` from the PineCoders Color Gradient Framework to build my gradients.  This function has the advantage of allowing begin/end colors for both the bull and bear colors. It also allows us to define the number of steps allowed for each gradient.  I use this to modulate the gradients so they perform optimally on the combination of the signal used to calculate advances/declines,  but also the nature of the visual component the gradient applies to. I use fewer steps for choppy signals and when the gradient is used on discrete visual components  such as volume​ columns or chart bars. • I use the PineCoders Coding Conventions for Pine to write my scripts. • I used functions modified from the PineCoders MTF Selection Framework for the selection of timeframes. █  THANKS TO: — The devs from TradingView's Pine and other teams, and the PineCoders who collaborate with them. They are doing amazing work,  and much of what this indicator does could not be done without their recent improvements to Pine. — A guy called Kuan who commented on a Backtest Rookies presentation of their Volume Profile indicator using a `for` loop.  This indicator started from the intrabar inspection technique illustrated in Kuan's snippet. — theheirophant , my partner in the exploration of the sometimes weird abysses of `security()`’s behavior at intrabar timeframes. — midtownsk8rguy , my brilliant companion in mining the depths of Pine graphics.
Pine Script® göstergesi
LucF tarafından
125
MarketLuminaMarketLumina: A Comprehensive Technical Analysis Tool MarketLumina is a technical analysis indicator crafted by a team of traders and developers in Germany. Built for TradingView’s Pine Script, it integrates trend visualization, signal generation, and real-time market insights to provide a multifaceted view of market conditions. This tool is designed to support traders in analyzing trends, spotting potential reversals, and evaluating market dynamics across various timeframes. The best way to get started with MarketLumina is to take your time exploring its wide range of features. Dive in, experiment, and find the 2-3 tools that feel just right for you. Whether you’re a day trader looking for quick signals, a swing trader tracking trends, or an investor watching the bigger picture, MarketLumina lets you pick and choose what works best. Over time, you’ll craft your own unique trading strategy, perfectly tailored to your goals, preferences, and risk tolerance. Key Features Fibonacci Trend-Cloud Displays market direction through Fibonacci-weighted moving averages. The cloud’s color—green (bullish), red (bearish), or yellow (caution)—reflects prevailing conditions, while its width indicates trend intensity. Advanced Signal System Generates signals derived from RSI, momentum, volume, money flow, volatility, price action, divergences, specific cloud-interactions, divergences and historical data. Signal categories include strong reversals, potential reversals, short-term tops/bottoms, strong trend, oversold/overbought conditions, exit signals, and money flow strategy triggers. LuminaPulse – Real-Time Market Insight A proprietary module that delivers real-time market analysis through a dashboard of six progress bars, each tailored to the symbol and timeframe using a machine learning approach. It screens historical data—key levels, consolidation zones, volatility spikes, and past price reactions—to optimize insights. Support & Resistance Zones Highlights critical price levels using volume-weighted historical data and price-action pivot points. Candlestick-Overlay Applies color coding to candlesticks—green (bullish), red (bearish), yellow (caution)—to emphasize signal-relevant bars. Usage Instructions MarketLumina is intended as a component of a broader analytical framework. Below are general guidelines for its application: Multi-Timeframe Analysis Align signals with trends on higher timeframes for context. LuminaPulse Interpretation Evaluate confluence across trend strength, momentum, money flow, and volume to assess market conditions. Additionally, monitor squeeze conditions for potential breakout signals and volatility to gauge market activity. Trend-Cloud Context Use the Fibonacci Trend-Cloud’s direction and width as a filter for signal relevance. Usage Instructions for MarketLumina’s Advanced Signal System The Advanced Signal System is a core component of MarketLumina, designed to empower traders by generating a variety of signals derived from RSI, momentum, volume, money flow, volatility, divergences, price action, and more. These signals are organized into distinct categories to help you identify key market conditions and uncover potential trading opportunities. Below is a comprehensive guide to each signal category, including descriptions, interpretations, and practical applications to enhance your trading decisions: Strong Reversals Reversal Signals are generated using a complex price action and volatility algorithm, pinpointing significant potential turning points in the market with elevated confidence. How to Use: Look for these signals near critical support or resistance levels, especially when supported by the Fibonacci Trend-Cloud or LuminaPulse metrics. Treat them as powerful reversal cues when they align with overarching market trends or follow prolonged price movements. Interpretation: A bullish Reversal signal flags a strong probability of an upward reversal, often in oversold conditions, suggesting a shift to bullish momentum. A bearish Reversal signal points to a likely downward reversal, typically in overbought scenarios, indicating bearish potential. Their reliability increases with confluence factors like divergences or a notable shift in money flow. Potential Reversals These signals flag possible trend continuation after a pullback based on price action, RSI thresholds and specific trend-cloud interaction, offering early insights with moderate certainty compared to strong reversals. How to Use: Use them as preliminary alerts for potential reversals of a pullback continuing its trend, particularly near support or resistance zones. Validate their strength with additional tools like the Trend-Cloud thickness or LuminaPulse to gauge reliability. Interpretation: Bullish potential reversals hint at the onset of an upward move, while bearish ones suggest a downward continuation may be brewing. Ideal for spotting early opportunities, these signals gain credibility when paired with confirming indicators. Short-Term Tops/Bottoms These signals mark temporary price extremes, identifying short-term tops or bottoms within a trend, driven by Multi-RSI algorithms. How to Use: In trending markets, leverage these signals to anticipate brief pullbacks or corrections within the dominant direction. In range-bound markets, use them to pinpoint reversal points within the established range. Interpretation: A short-term top indicates a temporary possible high, offering opportunities to lock in profits or brace for a dip. A short-term bottom suggests a fleeting low, signaling a potential bounce or recovery within the larger trend. Oversold/Overbought Conditions This category highlights extreme market states with oversold/overbought conditions, derived from RSI and price action. How to Use: In strong trends, these signals affirm the likelihood of potential temporary exhaustion. In weaker trends, they signal potential exhaustion and could early indicate reversals. Interpretation: Oversold signals in strong trends could mark a short-term break or slower trend continuation and should not be interpreted as a reversal signal. Strong Trend These signals flag possible trend continuation based on six key metrics—RSI, Money Flow, Momentum, and more—align to confirm robust momentum. How to Use: In strong trends, these signals affirm the likelihood of a continuation. Interpretation: Strong trend signals could be interpreted as a confirmation of the bullish movement and a possible continuation. Money Flow Strategy Triggers Built on money flow analysis, these signals track capital inflows and outflows on multiple timeframes to reveal shifts in buying or selling pressure, offering a window into market sentiment. How to Use: Deploy these triggers to refine entry or exit timing, especially when they sync with other signals and the Trend-Cloud’s direction. Pair them with LuminaPulse’s Money Flow, Momentum and volume sentiment for a deeper understanding of market participation. Interpretation: Positive money flow triggers indicate rising buying pressure, often a precursor to upward price action. Negative money flow triggers signal increasing selling pressure, potentially foreshadowing a downturn. Their value shines when diverging from price action, exposing hidden strength or weakness in the market. Usage Instructions for LuminaPulse LuminaPulse is a standout feature of MarketLumina, delivering real-time insights into market conditions through a sophisticated, machine-learning-driven approach. It analyzes historical data unique to each symbol and timeframe—examining past key levels, consolidation zones, volatility spikes, and price reactions—to create a dashboard of six progress bars. These bars represent the strength of critical market factors: Money Flow Momentum Volume Strength (Trend Strength) Squeeze Volatility Each bar is color-coded—green for bullish conditions, red for bearish—and its fill level reflects the factor’s strength relative to historical patterns. A fully loaded bar suggests a high likelihood of a notable price reaction, based on how the market has responded to similar conditions in the past. What makes LuminaPulse unique is its ability to tailor these insights to the specific symbol and timeframe, going beyond raw metrics to show their historical significance. Additionally, each bar features a "Ghost-Progress" overlay, marking the highest strength level reached in the current trend. This allows you to see whether the current strength is nearing or retreating from recent peaks, adding depth to your analysis. How to Use LuminaPulse LuminaPulse is a confirmation tool, not a standalone signal generator. It shines when paired with other MarketLumina features, like the Fibonacci Trend-Cloud or Advanced Signal System, as part of a broader trading strategy. Here’s how to apply it effectively: Seek Confluence Check for alignment across multiple bars. For example, if Money Flow, Momentum, and Volume are all green and highly filled, it could indicate strong bullish potential. Spot Divergences Look for mismatches between price action and the bars. If price rises but Momentum weakens, it might hint at a fading trend. Monitor Squeeze: A fully loaded Squeeze bar signals consolidation and potential volatility ahead. Use other tools to predict the breakout direction. Assess Volatility: The Volatility bar sets the context—high levels suggest bigger price swings, while low levels indicate a calmer market. Interpreting Each Progress Bar 1. Money Flow Measures the strength of money flowing into or out of the market, compared to historical thresholds, key-levels and past price reactions, using a machine learning approach, tailored to the symbol and timeframe. It’s not just the raw money flow index—it’s the likelihood of a price move based on historical similar money flow movements. How to Use: Look for a fully loaded bar alongside a strong Momentum bar near key levels or signals. Watch for a bar switching colors (e.g., red to green) with a robust Momentum bar for potential trend shifts. Treat it as the fuel behind price moves, not the absolute flow level. Interpretation: A fully loaded green bar suggests strong buying pressure; a red bar indicates selling pressure. Divergence (e.g., price up, Money Flow down) can signal an impending reversal—confirm with other tools. 2. Momentum Gauges the strength and direction of price momentum, factoring in historical key levels, volatility, and past reactions, optimized by a machine learning approach, tailored to the symbol and timeframe. It reflects momentum’s strength and potential impact, not just its current state. How to Use: Pair a fully loaded bar with a strong Money Flow bar near signals or key levels. A switching bar (e.g., bearish to bullish) with a solid Money Flow bar may hint at a trend change. View it as the driving force behind price momentum. Interpretation: A fully loaded green bar signals powerful upward momentum; a red bar shows downward force. Divergence from price action (e.g., price down, Momentum up) can be a reversal clue—verify with confluence. 3. Volume Shows whether volume is pushing price up or down, based on historical patterns and key levels near the current price, tailored to the symbol and timeframe. How to Use: Look for a bar over 50% filled, aligned with Money Flow and Momentum, near signals or key levels. Combine a strong bar with a fully loaded Squeeze bar for breakout potential. See it as the muscle behind buying or selling pressure. Interpretation: A green bar over 50% suggests volume supports upward moves; a red bar indicates downward pressure. Alignment with other bars near support/resistance can confirm breakouts or rejections. 4. Strength (Trend Strength) Focuses on the current trend’s robustness, comparing it to historical price movements, trend direction, and volatility. It helps spot pullbacks or early trend-shift warnings. How to Use: Watch for a fully loaded bar opposite your trade, paired with weakening Money Flow or Momentum, as an exit cue. For reversals, confirm a fully loaded bar with at least two other aligned bars. Use it to gauge the power of short-term price action. Interpretation: A fully loaded bar with supporting bars confirms trend strength. A dropping bar as price tests key levels may signal a pullback or shift—check support/resistance. 5. Squeeze Highlights consolidation and building pressure from buyers and sellers, suggesting a big move ahead. Its color reflects the trend but isn’t a reliable directional guide. How to Use: A fully loaded bar signals an imminent breakout—use other indicators for direction. Pair with strong Strength and Volume for timing confirmation. Treat it as a timing tool, not a directional one. Interpretation: A fully loaded bar means a significant move is likely, but not where it’s headed. Use it to prepare for action, not to predict the outcome—direction comes from confluence. 6. Volatility Measures current volatility relative to historical levels, using a machine learning approach to analyze past volatility and duration patterns specific to the symbol and timeframe. A calm bar might still appear during big swings if that’s normal for the asset or a calm bar could appear after a big move if it's normal for the asset to show single volatility spikes with consolidation afterwards. How to Use: Use a high Volatility bar (fully loaded) to favor short-term trades; a low bar (empty) suggests a quieter market. Pair with Squeeze to anticipate breakout strength. Adjust your strategy based on the market’s activity level. Interpretation: A fully loaded bar signals high volatility and bigger swings; an empty bar indicates low volatility and smaller moves. Context is key—high volatility for one symbol might be calm for another, based on its history. Key Features of LuminaPulse Tailored Insights: Each bar’s strength is customized to the symbol and timeframe’s historical behavior, making it uniquely relevant. Ghost-Progress: See the peak strength in the current trend, helping you judge if conditions are peaking or fading. Individual-Adapting Edge: Algorithms adapt to historical data, ensuring insights reflect past reactions, not just current values. Important Notes LuminaPulse is a complex, unique tool designed to enhance your analysis, not dictate trades. Its strength lies in its historical context and real-time adaptability, but it’s most effective when combined with other MarketLumina features and your own strategy. Illustrative Scenarios Trend Continuation Example Picture a market where momentum is steadily building. The Fibonacci Trend-Cloud turns red across both the primary and higher timeframes, reflecting a strong bearish direction. As this trend takes shape, reversal or strategy-based signals begin to line up with the cloud’s downward tilt, hinting at sustained weakness. Short-term bottoms and tops might start forming, offering clues about the trend’s rhythm, while a widening cloud could suggest growing confidence in the move. This setup showcases how the indicator can highlight a trend gathering steam, with multiple features reinforcing the direction. Reversal Example Imagine a market that’s been rising but approaches a key support zone. Suddenly, strong reversal signals flash on the chart, catching attention near this critical level. Price action starts to stabilize or reject, while LuminaPulse metrics show a subtle uptick in momentum or a shift in volume sentiment. As the market tests this zone, opposing signals fade, and the potential for a downward turn becomes clearer. This scenario illustrates how the indicator’s signals and metrics can converge to spotlight a possible shift in direction. Pullback Analysis Example Consider a strong bullish trend unfolding on the higher timeframe, painting a broad picture of upward movement. Zooming into the lower timeframe, a brief retracement emerges, pulling price back toward a support level. Here, strategy-based or reversal signals might pop up, marking this as a key area to watch. LuminaPulse could reveal a slowdown in downward momentum or a tightening of trend strength, suggesting the retracement might be running out of energy. This example demonstrates how the indicator can help dissect a pullback, revealing opportunities within an ongoing trend. Range-Bound Market Example Envision a market stuck in a sideways drift, with the Fibonacci Trend-Cloud narrowing and turning yellow—a sign of consolidation. Reversal signals begin appearing near support and resistance zones, hinting at potential bounces within the range. LuminaPulse metrics might spike, showing bursts of volatility or squeeze conditions building up. As price nears these boundaries, the chance of a breakout looms, with retests of the zones offering further clarity. These examples show how MarketLumina’s features—like the cloud’s color and width, signal alignments, and LuminaPulse shifts—can work together to illuminate market dynamics. Whether it’s a trend gaining traction, a reversal brewing, a pullback pausing, or a range tightening, the indicator provides visual and analytical cues to explore. By watching how these elements evolve, you can get a feel for the market’s rhythm and sharpen your understanding of what to look for in different situations. Legal Notices MarketLumina is a technical analysis tool, not a substitute for professional financial advice. Trading carries inherent risks; past performance does not guarantee future outcomes. All content is provided for educational purposes only and does not constitute trading recommendations. Users bear full responsibility for their trading decisions and are urged to prioritize robust risk management.
Pine Script® göstergesi
MarketLumina tarafından
5
Percentage price changeThis indicator marks bars whose values increase or decrease by an amount greater than or equal to the value of the specified parameter as a percentage. Bars that meet the condition are marked with labels, boxes and colors. In addition to the standard method of calculating the percentage change at the closing price of the current and previous bars, the indicator allows you to choose non-standard calculation methods (at the prices of opening and closing the current bar, as well as at the prices of the maximum at the minimum of the current bar). You can choose to display the percentage changes of individual bars as well as a series of bars. You can select the number of bars in a series of bars. You can also apply filters by the direction of the bars in the series or by the percentage of individual bars in the series. It is important to remember that in version 5 of Pine Script™, the maximum possible number of labels and the maximum possible number of boxes cannot exceed 500! There are several main parameters that can be changed in section PARAMETERS FOR CALCULATION: 1. 'Bars count' - The number of bars for which the percentage rise or fall is calculated. 2. ‘Percentage change’ - sets the price change as a percentage. Bars with a price range above or equal to the specified value will be marked on the chart. 3. ‘First and second points of calculation’ - the first and second points for calculating the percentage change. Here you can set several different values for the calculation: - 'Cl.pr., Close' - Closing price of the previous bar and closing price of the current bar (or a series of bars) (these values are used for the standard calculation of the percentage change on the chart). - 'Open, Close' - Opening and closing prices of the current bar (or a series of bars). - 'High|Low' - Highest and lowest price of the current bar (or a series of bars). - 'Cl.pr.|High|Low' - Highest or lowest price of the current bar (or a series of bars) (depending on whether the bar is going up or down) or closing price of the previous bar for first point (one of these values is automatically selected, which gives a larger result, depending on whether there is a gap between these values). Highest or lowest price of the current bar for second point. In the LIMITS section, you can set the following parameters. 1. ‘Only for the last bar’ - If this option is selected, the indicator will be applied only for the last bar (or series of bars). 2. 'Only bars in one direction' - A condition that takes into account sequences from the selected number of bars going in only one direction. If at least one bar has a different direction from the other bars, then such a sequence will not be taken into account. This only works if the 'Bars count' is > 1. 3. "Cut off higher values" - This field cuts off higher values. Bars with a price range above or equal to the specified value will not be marked on the chart. This can be used in some cases to make the chart less loaded with data and more visual. Of course, you can also use this option however you want. 4. ‘Min percent in series of bars’ - If the value 'Number of bars' is > 1, then a series of bars is taken into account, in which the percentage change of individual bars is greater than or equal to the set value. In the DATE RANGE section, you can set the limits of the time and date range in which the calculation will be performed. In some cases, this can be used in order not to exceed the limit on the number of labels or boxes, which cannot exceed 500. Of course, you can also use this option however you want. By default, the date range is unlimited. 'Timezone offset, hours' - It is used only for the correct display of the limits of the date range in the parameter table. In the PRICE INCREASE LABELS and PRICE REDUCTION LABELS section, you can define the design of labels bars and boxes, such as colors, shapes, sizes, and location. You can set the colors of the bars separately on the Style tab. On the Style tab, you can also turn on/off the display of frames, labels and color markings of bars. The PARAMETER TABLE section is designed to adjust the display of the table for a more visual display of the selected values of all parameters on the Arguments tab. Depending on which values have been set and which parameters have been enabled or disabled, the table will change its appearance, display or hide some rows. A single line 'Total found' will be displayed all the time. It shows the count of bars that meet the condition and count of labels or boxes used in the diagram. Since the bars are labeled with labels or boxes, their number cannot exceed 500 for Pine script version 5. 1. 'Pos.' - sets the main position of the table on the screen. 2. 'X off.', 'Y off.' - You can set the offset of the table along the X and Y axes. This option can be useful to avoid overlapping multiple tables if you want to use two or more instances of this indicator on your chart. The minimum value is -30, the maximum is 30. Positive values shift the table to the right on the X axis and up on the Y axis. Negative values shift the table to the left on the X axis and down on the Y axis. 3. 'Font color' - The font color in the table. 'Warn. font color', 'Warn. backgr. color' - The font and background colors in the 'Total found' row in the table. If the number of labels or boxes exceeds 500, the font and background will be colored in these colors. 4. ‘Font size’ – Sets the font size in the table. 5. 'Show hours and minutes in date/time range' - changes the date and time format of time range from {yyyy.MM.dd HH:mm} to {yyyy.MM.dd}. 6. 'View all params' - used to display all parameters, even those duplicated in the main line of the indicator. 7. ‘Title’ – If desired, you can make a header for the table. The last row of the table shows the number of bars found that meet the conditions. Since these bars are marked with labels (in the case of one bar) or boxes (in the case of series of bars), the limit that can be marked on the chart is 500. Exceeding this value will be displayed in the table and additionally highlighted in red font. This will signal that not all bars found are displayed on the chart. On the Style tab, you can turn the table display on/off.
Pine Script® göstergesi
Bondar tarafından
CandleAnalysisLibrary "CandleAnalysis" A collection of frequently used candle analysis functions in my scripts. isBullish(barsBack)   Checks if a specific bar is bullish.   Parameters:      barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).   Returns: True if the bar is bullish, otherwise returns false. isBearish(barsBack)   Checks if a specific bar is bearish.   Parameters:      barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).   Returns: True if the bar is bearish, otherwise returns false. isBE(barsBack)   Checks if a specific bar is break even.   Parameters:      barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).   Returns: True if the bar is break even, otherwise returns false. getBodySize(barsBack, inPriceChg)   Calculates a specific candle's body size.   Parameters:      barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).      inPriceChg (bool) : (bool) True to return the body size as a price change value. The default is false (in points).   Returns: The candle's body size in points. getTopWickSize(barsBack, inPriceChg)   Calculates a specific candle's top wick size.   Parameters:      barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).      inPriceChg (bool) : (bool) True to return the wick size as a price change value. The default is false (in points).   Returns: The candle's top wick size in points. getBottomWickSize(barsBack, inPriceChg)   Calculates a specific candle's bottom wick size.   Parameters:      barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).      inPriceChg (bool) : (bool) True to return the wick size as a price change value. The default is false (in points).   Returns: The candle's bottom wick size in points. getBodyPercent(barsBack)   Calculates a specific candle's body size as a percentage of its entire size including its wicks.   Parameters:      barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).   Returns: The candle's body size percentage. isHammer(fib, bullish, barsBack)   Checks if a specific bar is a hammer candle based on a given fibonacci level.   Parameters:      fib (float) : (float) The fibonacci level to base candle's body on. The default is 0.382.      bullish (bool) : (bool) True if the candle must to be green. The default is false.      barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).   Returns: True if the bar matches the requirements of a hammer candle, otherwise returns false. isShootingStar(fib, bearish, barsBack)   Checks if a specific bar is a shooting star candle based on a given fibonacci level.   Parameters:      fib (float) : (float) The fibonacci level to base candle's body on. The default is 0.382.      bearish (bool) : (bool) True if the candle must to be red. The default is false.      barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).   Returns: True if the bar matches the requirements of a shooting star candle, otherwise returns false. isDoji(wickSize, bodySize, barsBack)   Checks if a specific bar is a doji candle based on a given wick and body size.   Parameters:      wickSize (float) : (float) The maximum top wick size compared to the bottom and vice versa. The default is 1.5.      bodySize (float) : (bool) The maximum body size as a percentage compared to the entire candle size. The default is 5.      barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).   Returns: True if the bar matches the requirements of a doji candle. isBullishEC(gapTolerance, rejectionWickSize, engulfWick, barsBack)   Checks if a specific bar is a bullish engulfing candle.   Parameters:      gapTolerance (int)      rejectionWickSize (int) : (int) The maximum top wick size compared to the body as a percentage. The default is 10.      engulfWick (bool) : (bool) True if the engulfed candle's wick requires to be engulfed as well. The default is false.      barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).   Returns: True if the bar matches the requirements of a bullish engulfing candle. isBearishEC(gapTolerance, rejectionWickSize, engulfWick, barsBack)   Checks if a specific bar is a bearish engulfing candle.   Parameters:      gapTolerance (int)      rejectionWickSize (int) : (int) The maximum bottom wick size compared to the body as a percentage. The default is 10.      engulfWick (bool) : (bool) True if the engulfed candle's wick requires to be engulfed as well. The default is false.      barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).   Returns: True if the bar matches the requirements of a bearish engulfing candle.
Pine Script® kütüphanesi
ActiveQuants tarafından
MarcosLibraryLibrary "MarcosLibrary" A colection of frequently used functions in my scripts. bullFibRet(priceLow, priceHigh, fibLevel)   Calculates a bullish fibonacci retracement value.   Parameters:      priceLow (float) : (float) The lowest price point.      priceHigh (float) : (float) The highest price point.      fibLevel (float) : (float) The fibonacci level to calculate.   Returns: The fibonacci value of the given retracement level. bearFibRet(priceLow, priceHigh, fibLevel)   Calculates a bearish fibonacci retracement value.   Parameters:      priceLow (float) : (float) The lowest price point.      priceHigh (float) : (float) The highest price point.      fibLevel (float) : (float) The fibonacci level to calculate.   Returns: The fibonacci value of the given retracement level. bullFibExt(priceLow, priceHigh, thirdPivot, fibLevel)   Calculates a bullish fibonacci extension value.   Parameters:      priceLow (float) : (float) The lowest price point.      priceHigh (float) : (float) The highest price point.      thirdPivot (float) : (float) The third price point.      fibLevel (float) : (float) The fibonacci level to calculate.   Returns: The fibonacci value of the given extension level. bearFibExt(priceLow, priceHigh, thirdPivot, fibLevel)   Calculates a bearish fibonacci extension value.   Parameters:      priceLow (float) : (float) The lowest price point.      priceHigh (float) : (float) The highest price point.      thirdPivot (float) : (float) The third price point.      fibLevel (float) : (float) The fibonacci level to calculate.   Returns: The fibonacci value of the given extension level. isBullish(barsBack)   Checks if a specific bar is bullish.   Parameters:      barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).   Returns: True if the bar is bullish, otherwise returns false. isBearish(barsBack)   Checks if a specific bar is bearish.   Parameters:      barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).   Returns: True if the bar is bearish, otherwise returns false. isBE(barsBack)   Checks if a specific bar is break even.   Parameters:      barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).   Returns: True if the bar is break even, otherwise returns false. getBodySize(barsBack, inPriceChg)   Calculates a specific candle's body size.   Parameters:      barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).      inPriceChg (bool) : (bool) True to return the body size as a price change value. The default is false (in points).   Returns: The candle's body size in points. getTopWickSize(barsBack, inPriceChg)   Calculates a specific candle's top wick size.   Parameters:      barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).      inPriceChg (bool) : (bool) True to return the wick size as a price change value. The default is false (in points).   Returns: The candle's top wick size in points. getBottomWickSize(barsBack, inPriceChg)   Calculates a specific candle's bottom wick size.   Parameters:      barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).      inPriceChg (bool) : (bool) True to return the wick size as a price change value. The default is false (in points).   Returns: The candle's bottom wick size in points. getBodyPercent(barsBack)   Calculates a specific candle's body size as a percentage of its entire size including its wicks.   Parameters:      barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).   Returns: The candle's body size percentage. isHammer(fib, bullish, barsBack)   Checks if a specific bar is a hammer candle based on a given fibonacci level.   Parameters:      fib (float) : (float) The fibonacci level to base candle's body on. The default is 0.382.      bullish (bool) : (bool) True if the candle must to be green. The default is false.      barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).   Returns: True if the bar matches the requirements of a hammer candle, otherwise returns false. isShootingStar(fib, bearish, barsBack)   Checks if a specific bar is a shooting star candle based on a given fibonacci level.   Parameters:      fib (float) : (float) The fibonacci level to base candle's body on. The default is 0.382.      bearish (bool) : (bool) True if the candle must to be red. The default is false.      barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).   Returns: True if the bar matches the requirements of a shooting star candle, otherwise returns false. isDoji(wickSize, bodySize, barsBack)   Checks if a specific bar is a doji candle based on a given wick and body size.   Parameters:      wickSize (float) : (float) The maximum top wick size compared to the bottom and vice versa. The default is 1.5.      bodySize (float) : (bool) The maximum body size as a percentage compared to the entire candle size. The default is 5.      barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).   Returns: True if the bar matches the requirements of a doji candle. isBullishEC(gapTolerance, rejectionWickSize, engulfWick, barsBack)   Checks if a specific bar is a bullish engulfing candle.   Parameters:      gapTolerance (int)      rejectionWickSize (int) : (int) The maximum top wick size compared to the body as a percentage. The default is 10.      engulfWick (bool) : (bool) True if the engulfed candle's wick requires to be engulfed as well. The default is false.      barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).   Returns: True if the bar matches the requirements of a bullish engulfing candle. isBearishEC(gapTolerance, rejectionWickSize, engulfWick, barsBack)   Checks if a specific bar is a bearish engulfing candle.   Parameters:      gapTolerance (int)      rejectionWickSize (int) : (int) The maximum bottom wick size compared to the body as a percentage. The default is 10.      engulfWick (bool) : (bool) True if the engulfed candle's wick requires to be engulfed as well. The default is false.      barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).   Returns: True if the bar matches the requirements of a bearish engulfing candle.
Pine Script® kütüphanesi
ActiveQuants tarafından
Higher-timeframe requests█   OVERVIEW This publication focuses on enhancing awareness of the best practices for accessing higher-timeframe (HTF) data via the request.security() function. Some "traditional" approaches, such as what we explored in our previous `security()` revisited publication, have shown limitations in their ability to retrieve non-repainting HTF data. The fundamental technique outlined in this script is currently the most effective in preventing repainting when requesting data from a higher timeframe. For detailed information about why it works, see this section in the Pine Script™ User Manual . █   CONCEPTS Understanding repainting Repainting is a behavior that occurs when a script's calculations or outputs behave differently after restarting it. There are several types of repainting behavior, not all of which are inherently useless or misleading. The most prevalent form of repainting occurs when a script's calculations or outputs exhibit different behaviors on historical and realtime bars. When a script calculates across historical data, it only needs to execute once per bar, as those values are confirmed and not subject to change. After each historical execution, the script commits the states of its calculations for later access. On a realtime, unconfirmed bar, values are fluid . They are subject to change on each new tick from the data provider until the bar closes. A script's code can execute on each tick in a realtime bar, meaning its calculations and outputs are subject to realtime fluctuations, just like the underlying data it uses. Each time a script executes on an unconfirmed bar, it first reverts applicable values to their last committed states, a process referred to as rollback . It only commits the new values from a realtime bar after the bar closes. See the User Manual's Execution model page to learn more. In essence, a script can repaint when it calculates on realtime bars due to fluctuations before a bar's confirmation, which it cannot reproduce on historical data. A common strategy to avoid repainting when necessary involves forcing only confirmed values on realtime bars, which remain unchanged until each bar's conclusion. Repainting in higher-timeframe (HTF) requests When working with a script that retrieves data from higher timeframes with request.security() , it's crucial to understand the differences in how such requests behave on historical and realtime bars . The request.security() function executes all code required by its `expression` argument using data from the specified context (symbol, timeframe, or modifiers) rather than on the chart's data. As when executing code in the chart's context, request.security() only returns new historical values when a bar closes in the requested context. However, the values it returns on realtime HTF bars can also update before confirmation, akin to the rollback and recalculation process that scripts perform in the chart's context on the open bar. Similar to how scripts operate in the chart's context, request.security() only confirms new values after a realtime bar closes in its specified context. Once a script's execution cycle restarts, what were previously realtime bars become historical bars, meaning the request.security() call will only return confirmed values from the HTF on those bars. Therefore, if the requested data fluctuates across an open HTF bar, the script will repaint those values after it restarts. This behavior is not a bug; it's simply the default behavior of request.security() . In some cases, having the latest information from an unconfirmed HTF bar is precisely what a script needs. However, in many other cases, traders will require confirmed, stable values that do not fluctuate across an open HTF bar. Below, we explain the most reliable approach to achieve such a result. Achieving consistent timing on all bars One can retrieve non-fluctuating values with consistent timing across historical and realtime feeds by exclusively using request.security() to fetch the data from confirmed HTF bars. The best way to achieve this result is offsetting the `expression` argument by at least one bar (e.g., `close [1 ]`) and using barmerge.lookahead_on as the `lookahead` argument. We discourage the use of barmerge.lookahead_on alone since it prompts the function to look toward future values of HTF bars across historical data, which is heavily misleading. However, when paired with a requested `expression` that includes a one-bar historical offset, the "future" data the function retrieves is not from the future. Instead, it represents the last confirmed bar's values at the start of each HTF bar, thus preventing the results on realtime bars from fluctuating before confirmation from the timeframe. For example, this line of code uses a request.security() call with barmerge.lookahead_on to request the close price from the "1D" timeframe, offset by one bar with the history-referencing operator [ ] . This line will return the daily price with consistent timing across all bars: float htfClose = request.security(syminfo.tickerid, "1D", close , lookahead = barmerge.lookahead_on) Note that:  • This technique only works as intended for higher-timeframe requests .  • When designing a script to work specifically with HTFs, we recommend including conditions to prevent request.security() from accessing timeframes equal to or lower than the chart's timeframe, especially if you intend to publish it. In this script, we included an if structure that raises a runtime error when the requested timeframe is too small.  • A necessary trade-off with this approach is that the script must wait for an HTF bar's confirmation to retrieve new data on realtime bars, thus delaying its availability until the open of the subsequent HTF bar. The time elapsed during such a delay varies with each market, but it's typically relatively small. 👉 Failing to offset the function's `expression` argument while using barmerge.lookahead_on will produce historical results with lookahead bias , as it will look to the future states of historical HTF bars, retrieving values before the times at which they're available in the feed. See the `lookahead` and Future leak with `request.security()` sections in the Pine Script™ User Manual for more information. Evolving practices The fundamental technique outlined in this publication is currently the only reliable approach to requesting non-repainting HTF data with request.security() . It is the superior approach because it avoids the pitfalls of other methods, such as the one introduced in the `security()` revisited publication. That publication proposed using a custom `f_security()` function, which applied offsets to the `expression` and the requested result based on historical and realtime bar states. At that time, we explored techniques that didn't carry the risk of lookahead bias if misused (i.e., removing the historical offset on the `expression` while using lookahead), as requests that look ahead to the future on historical bars exhibit dangerously misleading behavior. Despite these efforts, we've unfortunately found that the bar state method employed by `f_security()` can produce inaccurate results with inconsistent timing in some scenarios, undermining its credibility as a universal non-repainting technique. As such, we've deprecated that approach, and the Pine Script™ User Manual no longer recommends it. █   METHOD VARIANTS In this script, all non-repainting requests employ the same underlying technique to avoid repainting. However, we've applied variants to cater to specific use cases, as outlined below: Variant 1 Variant 1, which the script displays using a lime plot, demonstrates a non-repainting HTF request in its simplest form, aligning with the concept explained in the "Achieving consistent timing" section above. It uses barmerge.lookahead_on and offsets the `expression` argument in request.security() by one bar to retrieve the value from the last confirmed HTF bar. For detailed information about why this works, see the Avoiding Repainting section of the User Manual's Other timeframes and data page. Variant 2 Variant 2 ( fuchsia ) introduces a custom function, `htfSecurity()`, which wraps the request.security() function to facilitate convenient repainting control. By specifying a value for its `repaint` parameter, users can determine whether to allow repainting HTF data. When the `repaint` value is `false`, the function applies lookahead and a one-bar offset to request the last confirmed value from the specified `timeframe`. When the value is `true`, the function requests the `expression` using the default behavior of request.security() , meaning the results can fluctuate across chart bars within realtime HTF bars and repaint when the script restarts. Note that:  • This function exclusively handles HTF requests. If the requested timeframe is not higher than the chart's, it will raise a runtime error .  • We prefer this approach since it provides optional repainting control. Sometimes, a script's calculations need to respond immediately to realtime HTF changes, which `repaint = true` allows. In other cases, such as when issuing alerts, triggering strategy commands, and more, one will typically need stable values that do not repaint, in which case `repaint = false` will produce the desired behavior. Variant 3 Variant 3 ( white ) builds upon the same fundamental non-repainting approach used by the first two. The difference in this variant is that it applies repainting control to tuples , which one cannot pass as the `expression` argument in our `htfSecurity()` function. Tuples are handy for consolidating `request.*()` calls when a script requires several values from the same context, as one can request a single tuple from the context rather than executing multiple separate request.security() calls. This variant applies the internal logic of our `htfSecurity()` function in the script's global scope to request a tuple containing open and `srcInput` values from a higher timeframe with repainting control. Historically, Pine Script™ did not allow the history-referencing operator [ ] when requesting tuples unless the tuple came from a function call, which limited this technique. However, updates to Pine over time have lifted this restriction, allowing us to pass tuples with historical offsets directly as the `expression` in request.security() . By offsetting all items in a tuple `expression` by one bar and using barmerge.lookahead_on , we effectively retrieve a tuple of stable, non-repainting HTF values. Since we cannot encapsulate this method within the `htfSecurity()` function and must execute the calculations in the global scope, the script's "Repainting" input directly controls the global `offset` and `lookahead` values to ensure it behaves as intended. Variant 4 (Control) Variant 4, which the script displays as a translucent orange plot, uses a default request.security() call, providing a reference point to compare the difference between a repainting request and the non-repainting variants outlined above. Whenever the script restarts its execution cycle, realtime bars become historical bars, and the request.security() call here will repaint the results on those bars. █   Inputs Repainting The "Repainting" input (`repaintInput` variable) controls whether Variant 2 and Variant 3 are allowed to use fluctuating values from an unconfirmed HTF bar. If its value is `false` (default), these requests will only retrieve stable values from the last confirmed HTF bar. Source The "Source" input (`srcInput` variable) determines the series the script will use in the `expression` for all HTF data requests. Its default value is close . HTF Selection This script features two ways to specify the higher timeframe for all its data requests, which users can control with the "HTF Selection" input (`tfTypeInput` variable):  1) If its value is "Fixed TF", the script uses the timeframe value specified by the "Fixed Higher Timeframe" input (`fixedTfInput` variable). The script will raise a runtime error if the selected timeframe is not larger than the chart's.  2) If the input's value is "Multiple of chart TF", the script multiplies the value of the "Timeframe Multiple" input (`tfMultInput` variable) by the chart's timeframe.in_seconds() value, then converts the result to a valid timeframe string via timeframe.from_seconds() . Timeframe Display This script features the option to display an "information box", i.e., a single-cell table that shows the higher timeframe the script is currently using. Users can toggle the display and determine the table's size, location, and color scheme via the inputs in the "Timeframe Display" group. █   Outputs This script produces the following outputs:  • It plots the results from all four of the above variants for visual comparison.  • It highlights the chart's background gray whenever a new bar starts on the higher timeframe, signifying when confirmations occur in the requested context.  • To demarcate which bars the script considers historical or realtime bars, it plots squares with contrasting colors corresponding to bar states at the bottom of the chart pane.  • It displays the higher timeframe string in a single-cell table with a user-specified size, location, and color scheme. Look first. Then leap.
Pine Script® göstergesi
PineCoders tarafından
14
YinYang TrendTrend Analysis has always been an important aspect of Trading. There are so many important types of Trend Analysis and many times it may be difficult to identify what to use; let alone if an Indicator can/should be used in conjunction with another. For these exact reasons, we decided to make YinYang Trend. It is a Trend Analysis Toolkit which features many New and many Well Known Trend Analysis Indicators. However, everything in there is added specifically for the reason that it may work well in conjunction with the other Indicators prevalent within. You may be wondering, why bother including common Trend Analysis, why not make everything unique? Ideally, we would, however, you need to remember Trend Analysis may be one of the most common forms of charting. Therefore, many other traders may be using similar Trend Analysis either through plotting manually or within other Indicators. This all boils down to Psychology; you are trading against other traders, who may be seeing some of the similar information you are, and therefore, you may likewise want to see this information. What affects their trading decisions may affect yours as well. Now enough about Trend Analysis, what is within this Indicator, and what does it do? Well, first let’s quickly mention all of its components, then we will, through a Tutorial, discuss each individually and finally how each comes together as a cohesive whole. This Indicator features many aspects: Bull and Bear Signals Take Profit Signals Bull and Bear Zones Information Tables displaying: (Boom Meter, Bull/Bear Strength, Yin/Yang State) 16 Cipher Signals Extremes Pivots Trend Lines Custom Bollinger Bands Boom Meter Bar Colors True Value Zones Bar Strength Indexes Volume Profile There are many things to cover within our Tutorial so let's get started, chronologically from the list above. Tutorial: Bull and Bear Signals: We’ve zoomed out quite a bit for this example to help give you a broader aspect of how these Bull and Bear signals work. When a signal appears, it is displaying that there may be a large amount of Bullish or Bearish Trend Analysis occurring. These signals will remain in their state of Bull or Bear until there is enough momentum change that they change over. There are a couple Options within the Settings that dictate when/where/why these signals appear, and this example is using their default Settings of ‘Medium’. They are, Purchase Speed and Purchase Strength. Purchase Speed refers to how much Price Movement is needed for a signal to occur and Purchase Strength refers to how many verifications are required for a signal to occur. For instance: 'High' uses 15 verifications to ensure signal strength. 'Medium' uses 10 verifications to ensure signal strength. 'Low' uses 5 verifications to ensure signal strength. 'Very Low' uses 3 verifications to ensure signal strength. By default it is set to Medium (10 verifications). This means each verification is worth 10%. The verifications used are also relevant to the Purchase Speed; meaning they will be verified faster or slower depending on its speed setting. You may find that Faster Speeds and Lower Verifications may work better on Higher Time Frames; and Slower Speeds and Higher Verifications may work better on Lower Time Frames. We will demonstrate a few examples as to how the Speed and Strength Settings work, and why it may be beneficial to adjust based on the Time Frame you’re on: In this example above, we’ve kept the same Time Frame (1 Day), and scope; but we’ve changed Purchase Speed from Medium->Fast and Purchase Strength from Medium-Very Low. As you can see, it now generates quite a few more signals. The Speed and Strength settings that you use will likely be based on your trading style / strategy. Are you someone who likes to stay in trades longer or do you like to swing trade daily? Likewise, how do you go about identifying your Entry / Exit locations; do you start on the 1 Day for confirmation, then move to the 15/5 minute for your entry / exit? How you trade may determine which Speed and Strength settings work right for you. Let's jump to a lower Time Frame now so you can see how it works on the 15/5 minute. Above is what BTC/USDT looks like on the 15 Minute Time Frame with Purchase Speed and Strength set to Medium. You may note that the signals require a certain amount of movement before they get started. This is normal with Medium and the amount of movement is generally dictated by the Time Frame. You may choose to use Medium on a Lower Time Frame as it may work well, but it may also be best to change it to a little slower. We are still on the 15 Minute Time Frame here, however we simply changed Purchase Speed from Medium->Slow. As you can see, lots of the signals have been removed. Now signals may ‘hold their ground’ for much longer. It is important to adjust your Purchase Speed and Strength Settings to your Time Frame and personalized trading style accordingly. Above we have now jumped down to the 5 Minute Time Frame. Our Purchase Speed is Slow and our Purchase Strength is Medium. We can see it looks pretty good, although there is some signal clustering going on in the middle there. If we change our Settings, we may be able to get rid of that. We have changed our Purchase Speed from Slow->Snail (Slowest it can go) and Purchase Strength from Medium->Very Low (Lowest it can go). Changing it from Slow-Snail helped get rid of the signal clustering. You may be wondering why we lowered the Strength from Medium->Very Low, rather than going from Medium->High. This is a use case scenario and one you’ll need to decide for yourself, but we noticed when we changed the Speed from Slow->Snail that the signal clustering was gone, so then we checked both High and Very Low for Strengths to see which produced the best looking signal locations. Please remember, you don’t have to use it the exact way we’ve displayed in this Tutorial. It is meant to be used to suit your Trading Style and Strategy. This is why we allow you to modify these settings, rather than just automating the change based on Time Frames. You’ll likely need to play around with it, as you’ll notice different settings may work better on certain pairs and Time Frames than others. Take Profit Signals: We’ve reset our Purchase Settings, everything is on defaults right now at Medium. We’ve enabled Take Profit signals. As you can see there are both Take Profit signals for the Bulls and the Bears. These signals are not meant to be used within automation. In fact, none of this indicator is. These signals are meant to show there has been a strong change in momentum, to such an extent that the signal may switch from its current (Bull or Bear) and now may be a good time to Take Profit. Your Take Profit Settings likewise has a Speed and Strength, and you can set them differently than your Purchase Settings. This is in case you want to Take Profit in a different manner than your Purchase Signals. For instance: In the example above we’ve kept Purchase Strength and Speed at Medium but we changed our Take Profit Speed from Medium->Snail and our Take Profit Strength from medium->Very Low. This greatly reduces the amount of Take Profit signals, and in some cases, none are even produced. This form of Take Profit may act more as a Trailing Take Profit that if it’s not hit, nothing appears. In this example we have changed our Purchase Speed from Medium->Fast, our Purchase Strength from Medium->Very Low. We’ve also changed our Take Profit Speed from Snail->Medium and kept our Take Profit Strength on Very Low. Now we may get our signals quicker and likewise our Take Profit may be more rare. There are many different ways you can set up your Purchase and Take Profit Settings to fit your Trading Style / Strategy. Bull and Bear Zones: We have disabled our Take Profit locations so that you can see the Bull and Bear Zones. These zones change color when the Signals switch. They may represent some strong Support and Resistance locations, but more importantly may be useful for visualizing changes in momentum and consolidation. These zones allow you to see various Moving Averages; and when they start to ‘fold’ (cross) each other you may see changes in momentum. Whereas, when they’re fully stretched out and moving all in the same direction, it can provide insight that the current rally may be strong. There is also the case where they look like they’re ‘twisted’ together. This happens when all of the Moving Averages are very close together and may be a sign of Consolidation. We will go over a few examples of each of these scenarios so you can understand what we’re referring to. In this example above, there are a few different things happening. First we have the yellow circle, where the final and slowest Moving Average (MA) crossed over and now all of the MA’s that form the zone are Bullish. You can see this in the white circle where there are no MA’s that are crossing each other. Lastly, within the blue circle, we can see how some of the faster MA’s are crossing under each other. This is a bullish momentum change. The Faster moving MA’s will always be the first ones to cross before the Slower ones do. There is a color scheme in place here to represent the Speed of the MA within the Zone. Light blue is the fastest moving Bull color -> Light Green and finally -> Dark Green. Yellow is the fastest moving Bear color -> Orange and finally -> Red / Dark Red within the Zone. Next we will review a couple different examples of what Consolidation looks like and why it is very important to look out for. Consolidation is when Most, if not All of the MA’s are very tightly ‘twisted’ together. There is very little spacing between almost all of the MA’s in the example above; highlighted by the white circle. Consolidation is important as it may indicate a strong price movement in either direction will occur soon. When the price is consolidating it means it has had very little upwards or downwards movement recently. When this happens for long enough, MA’s may all get very similar in value. This may cause high volatility as the price tries to break out of Consolidation. Let's look at another example. Above we have two more examples of what Consolidation looks like and how high Volatility may occur after the Consolidation is broken. Please note, not all Consolidation will create high Volatility but it is something you may want to look out for. Information Tables displaying: (Boom Meter, Bull/Bear Strength, Yin/Yang State): Information tables are a very important way of displaying information. It contains 3 crucial pieces of information: Boom Meter Bull/Bear Strength Yin/Yang State Boom Meter is a meter that goes from 0-100% and displays whether the current price is Dumping (0 - 29%), Consolidating (30 - 70%) or Pumping (71 - 100%). The Boom Meter is meant to be a Gauge to how the price is currently fairing. It is composed of ~50 different calculations that all vary different weights to calculate its %. Many of the calculations it uses are likewise used in other things, such as the Bull/Bear Strength, Bull/Bear Zone MA cross’, Yin/Yang State, Market Cipher Signals, RSI, Volume and a few others. The Boom Meter, although not meant to be used solely to make purchase decisions, may give you a good idea of current market conditions considering how many different things it evaluates. Bull/Bear Strength is relevant to your Purchase Speed and Strength. It displays which state it is currently in, and the % it is within that state. When a % hits 0, is when the state changes. When states change, they always start at 100% initially and will go down at the rate of Purchase Strength (how many verifications are needed). For instance, if your Purchase Strength is set to ‘Medium’ it will move 10% per verification +/-, if it is set to High, it will move 6.67% per verification +/-. Bull/Bear Strength is a good indicator of how well that current state is fairing. For instance if you started a Long when the state changed to Bull and now it is currently at Bull with 20% left, that may be a good indication it is time to get out (obviously refer to other data as well, but it may be a good way to know that the state is 20% away from transitioning to Bear). Yin/Yang State is the strongest MA cross within our Indicator. It is unique in the sense that it is slow to change, but not so much that it moves slowly. It isn’t as simple as say a Golden/Death Cross (50/200), but it crosses more often and may hold similar weight as it. Yin stands for Negative (Bearish) and Yang stands for Positive (Bullish). The price will always be in either a state of Yin or Yang, and just because it is in one, doesn’t mean the price can’t/won’t move in the opposite direction; it simply means the price may be favoring the state it is in. 16 Cipher Signals: Cipher Signals are key visuals of MA cross’ that may represent price movement and momentum. It would be too confusing and hard to decipher these MA’s as lines on a chart, and therefore we decided to use signals in the form of symbols instead. There are 12 Standard and 4 Predictive/Confirming Cipher signals. The Standard Cipher signals are composed of 6 Bullish and 6 Bearish (they all have opposites that balance each other out). There can never be 2 of the same signal in a row, as the Bull and Bear cancel each other out and it's always in a state of one or the other. When all 6 Bullish or Bearish signals appear in a row, very closely together, without any of the opposing signals it may represent a strong momentum movement is about to occur. If you refer to the example above, you’ll see that the 6 Bullish Cipher signals appeared exactly as mentioned above. Shortly after the Green Circle appeared, there was a large spike in price movement in favor of the Bulls. Cipher signals don’t need to appear in a cluster exactly like the white circle in this photo for momentum to occur, but when it does, it may represent volatility more than if it is broken up with opposing signals or spaced out over a longer time span. Above is an example of the opposite, where all 6 Bearish Cipher signals appeared together without being broken by a Bullish Cipher signal or being too far spaced out. As you can see, even though past it there was a few Bullish signals, they were quickly reversed back to Bearish before a large price movement occurred in favor of the Bears. In the example above we’ve changed Cipher signals to Predictive and Confirming. Support Crosses (Green +) and Blood Diamonds (Red ♦) are the normal Cipher Signals that appear within the Standard Set. They are the first Cipher Signal that appears and are the most common ones as well. However, just because they are the first, that doesn’t mean they aren’t a powerful Cipher signal. For this reason, there are Predictive and Confirming Cipher signals for these. The Predictive do just that, they appear slightly sooner (if not the same bar) as the regular and the Confirming appear later (1+ bars usually). There will be times that the Predictive appears, but it doesn’t resort to the Regular appearing, or the Regular appears and the Confirming doesn’t. This is normal behavior and also the purpose of them. They are meant to be an indication of IF they may appear soon and IF the regular was indeed a valid signal. Extremes: Extremes are MA’s that have a very large length. They are useful for seeing Cross’ and Support and Resistance over a long period of time. However, because they are so long and slow moving, they might not always be relevant. It’s usually advised to turn them on, see if any are close to the current price point, and if they aren’t to turn them off. The main reason being is they stretch out the chart too much if they’re too far away and they also may not be relevant at that point. When they are close to the price however, they may act as strong Support and Resistance locations as circled in the example above. Pivots: Pivots are used to help identify key Support and Resistance locations. They adjust on their own in an attempt to keep their locations as relevant as possible and likewise will adjust when the price pushes their current bounds. They may be useful for seeing when the Price is currently testing their level as this may represent Overbought or Oversold. Keep in mind, just because the price is testing their levels doesn’t mean it will correct; sometimes with high volatility or geopolitical news, movement may continue even if it is exhibiting Overbought or Oversold traits. Pivots may also be useful for seeing how far the price may correct to, giving you a benchmark for potential Take Profit and Stop Loss locations. Trend Lines: Trend Lines may be useful for identifying Support and Resistance locations on the Vertical. Trend Lines may form many different patterns, such as Pennants, Channels, Flags and Wedges. These formations may help predict and drive the price in specific directions. Many traders draw or use Indicators to help create Trend Lines to visualize where these formations will be and they may be very useful alone even for identifying possible Support and Resistance locations. If you refer to the previous example, and now to this example, you’ll notice that the Trend Line that supported it in 2023 was actually created in June 2020 (yellow circle). Trend Lines may be crucial for identifying Support and Resistance locations on the Vertical that may withhold over time. Custom Bollinger Bands: Bollinger Bands are used to help see Movement vs Consolidation Zones (When it's wide vs narrow). It's also very useful for seeing where the correction areas may be. Price may bounce between top and bottom of the Bollinger Bands, unless in a pump or dump. The Boom Meter will show you whether it is currently: Dumping, Consolidation or Pumping. If combined with Boom Meter Bar Colors it may be a good indication if it will break the Bollinger Band (go outside of it). The Middle Line of the Bollinger Band (White Line) may be a very strong support / resistance location. If the price closes above or below it, it may be a good indication of the trend changing (it may indicate one of the first stages to a pump or dump). The color of the Bollinger Bands change based on if it is within a Bull or Bear Zone. What makes this Bollinger Band special is not only that it uses a custom multiplier, but it also incorporates volume to help add weight to the calculation. Boom Meter Bar Colors: Boom Meter Bar Colors are a way to see potential Overbought and Oversold locations on a per bar basis. There are 6 different colors within the Boom Meter bar colors. You have: Overbought and Very Bullish = Dark Green Overbought and Slightly Bullish = Light Green Overbought and Slight Bearish = Light Red Oversold and Very Bearish = Dark Red Oversold and Slightly Bearish = Orange Oversold and Slightly Bullish = Light Purple When there is no Boom Meter Bar Color prevalent there won’t be a color change within the bar at all. Just because there is a Boom Meter Bar Color change doesn’t mean you should act on it purchase or sell wise, but it may be an indication as to how that bar is fairing in an Overbought / Oversold perspective. Boom Meter Bar Colors are mainly based on RSI but do take in other factors like price movement to determine if it is Overbought or Oversold. When it comes to Boom Meter Bar Color, you should take it as it is, in the sense that it may be useful for seeing how Individual bars are fairing, but also note that there may be things such as: When there is Very Overbought (Dark Green) or Very Oversold (Dark Red), during massive pump or dumps, it will maintain this color. However, once it has lost ‘some’ momentum it will likely lose this color. When there has been a massive Pump or Dump, and there is likewise a light purple or light red, this may mean there is a correction or consolidation incoming. True Value Zones: True Value zones are our custom way of displaying something that is similar to a Bollinger Band that can likewise twist like an MA cross. The main purpose of it is to display where the price may reside within. Much like a Bollinger Band it has its High and Low within its zone to specify this location. Since it has the ability to cross over and under, it has the ability to specify what it thinks may be a Bullish or Bearish zone. This zone uses its upper level to display what may be a Resistance location and its lower level to display what may be a Support location. These Support and Resistance locations are based on Momentum and will move with the price in an attempt to stay relevant. You may use these True Values zones as a gauge of if the price is Overbought or Oversold. When the price faces high volatility and moves outside of the True Value Zones, it may face consolidation or likewise a correction to bring it back within these zones. These zones may act as a guideline towards where the price is currently valued at and may belong within. Bar Strength Indexes: Bar Strength Indexes are our way of ranking each bar in correlation to the last few. It is based on a few things but is highly influenced on Open/Close/High/Low, Volume and how the price has moved recently. They may attempt to ‘rate’ each bar and how Bullish/Bearish each of these bars are. The Green number under the bar is its Bullish % and the Red number above the bar is its Bearish %. These %’s will always equal 100% when combined together. Bar Strength Indexes may be useful for seeing when either Bullish or Bearish momentum is picking up or when there may be a reversal / consolidation. These Bar Strength Indexes may allow you to decipher different states. If you refer to the example above, you may notice how based on how the numbers are changing, you may see when it has entered / exited Bullish, Bearish and Consolidation. Likewise, if you refer to the current bar (yellow circle), you can see that the Bullish % has dropped from 93 to 49; this may be signifying that the Bullish movement is losing momentum. You may use these changes in Bar Indexes as a guide to when to enter / end trades. Volume Profile: Volume Profile has been something that has been within TradingView for quite some time. It is a very useful way of seeing at what Horizontal Price there has been the most volume. This may be very useful for seeing not only Support and Resistance locations based on Volume, but also seeing where the majority of Limit Orders are placed. Limit Orders are where traders decide they want to either Buy / Sell but have the order placed so the trade won’t happen until the price reaches a certain amount. Either through many orders from many traders, or a single order from a ‘Whale’ (trader with a lot of capital); you may see Support and Resistance at specific Price Points that have large Volume. Many Volume Profile Indicators feature a breakdown of all the different locations of volume, along with a Point Of Control (POC) line to designate where the most Volume has been. To try and reduce clutter within our already very saturated Toolkit Indicator, we’ve decided to strip our Volume Profile to only display this POC line. This may allow you to see where the crucial Volume Support and Resistance is without all of the clutter. You may be wondering, well how important is this Volume Profile POC line and how do I go about using it? Aside from it being a gauge towards where Support and Resistance may be within Volume, it may also be useful for identifying good Long/Short locations. If you think of the line as a ‘Battle’ between the Bulls and Bears, they’re both fighting over that line. The Bears are wanting to break through it downwards, and the Bulls are wanting to break through it upwards. When one side has temporarily won this battle, this means they may have more Capital to push the price in their direction. For instance, if both the Bulls and the Bears are fighting over this POC price, that means the Bears think that price is a good spot to sell; however, the Bulls also deem that price to be a good point to buy. If the Bulls were to win this battle, that means the Bears either canceled their orders to reevaluate, or all of their orders have been completed from the Bulls buying them all. What may happen after that is, if the Bulls were able to purchase all of these Limit Sell Orders, then they may still have more Capital left to continue to pressure the price upwards. The same may be true for if the Bears were to win this ‘Battle’. How to use YinYang Trend as a cohesive whole: Hopefully you’ve read and understand how each aspect of this Indicator works on its own, as knowing how/what they each do is important to understanding how it is used as a cohesive whole. Due to the fact that this Toolkit of an Indicator displays so much data, you may find it easier to use and understand when you’re zoomed in a little, somewhat like we are in this example above. If we refer to the example above, you may like us, deduce a few things: 1. The current price may be VERY Overbought. This may be seen by a few different things: The Boom Meter Bar Colors have been exhibiting a Dark Green color for 6 bars in a row. The price has continuously been moving the High (red) Pivot Upwards. Our Boom Meter displays ‘Pumping’ at 100%. The price broke through a Downward Trend Line that was created in February of 2022 at 45,000 like it was nothing. The Bar Strength Index hit a Bullish value of 93%. The Price broke out of the Bollinger Bands and continues to test its upper levels. The Low is much greater than our fastest moving MA that creates the Purchase Zones. The Price is vastly outside of the True Value Zone. The Bar Strength Index of our current bar is 50% bullish, which is a massive decrease from the previous bar of 93%. This may indicate that a correction is coming soon. 2. Since we’ve identified the current price may be VERY Overbought, next we need to identify if/when/to where it may correct to: We’ve created a new example here to display potential correction areas. There are a few places it has the ability to correct to / within: The downward Trend Line (red) below the current bar sitting currently at 32,750. This downward Trend Line is at the same price point as the Fastest MA of our Purchase Zone which may provide some decent Support there. Between two crucial Pivot heights, within a zone of 30,000 to 31,815. This zone has the second fastest MA from the Purchase Zone right near the middle of it at 31,200 which may act as a Support within the Zone. Likewise there is the Bollinger Band Basis which is also resting at 30,000 which may provide a strong Support location here. If 30,000 fails there may be a correction all the way to the bottom of our True Value Zone and the top of one of our Extremes at 27,850. If 27,850 fails it may correct all the way to the bottom of our Purchase Zone / lowest of our Extremes at 27,350. If all of the above fails, it may test our Volume Profile POC of 26,430. If this POC fails, the trend may switch to Bearish and continue further down to lower levels of Support. The price can always correct more than the prices mentioned above, but considering overall this Indicator is favoring the Bulls, we will tailor this analysis in Favor of the Bullish Momentum maintaining even during this correction. For these reasons, we think the price may correct between the 30,000 and 31,815 zone before continuing upwards and maintaining this Bullish Momentum. Please note, these correction estimates are just that, they’re estimates. Aside from the fact that the price is very overbought right now and our Bar Strength Index may be declining (bar hasn’t closed yet); the Boom Meter Strength remains at 100%, meaning there may not be much Bearish momentum changes happening yet. We just want to show you how an Preemptive analysis may be done before there are even Bearish Cipher Signals appearing. Using this Indicator, you may be able to decipher Entry and Exits. In the previous example, we went over how you may use it to see where a correction (Exit / Take Profit) may be and how far this correction may go. In this example above we will be discussing how to identify Entry locations. We will be discussing a Bullish Buy entry but the same rules apply for a Bearish Sell Entry just the opposite with the Cipher Signals. If you refer to where we circled in white, this is where the Purchase Zones faced Consolidation. When the Purchase Zones all get tight and close together like that, this may represent Volatility and Momentum in either direction may occur soon. This was then followed by all 6 of the Standard Cipher Signals closely in succession to each other. This means the Momentum may be favoring the Bulls. If this was likewise all 6 of the Bearish Cipher Signals closely in succession, than the momentum change would favor the Bears. If you were looking for an entry, and you saw Consolidation with the Purchase Zones and then shortly after you saw the Green Circle and Blue Flag (they can swap order); this may now be a good Entry location. We will conclude this Tutorial here. Hopefully this has taught you how this Trend Analysis Toolkit may help you locate multiple different types of important Support and Resistance locations; as well as possible Entry and Exit locations. Settings: 1. Bull/Bear Zones: 1.1. Purchase Speed (Bull/Bear Signals and Take Profit Signals): Speed determines how much price movement is needed for a signal to occur. 'Sonic' uses the extremities to try and get you the best entry and exit points, but is so quick, its speed may reduce accuracy. 'Fast' may attempt to capitalize on price movements to help you get SOME or attempt to lose LITTLE quickly. 'Medium' may attempt to get you the most optimal entry and exit locations, but may miss extremities. 'Slow' may stay in trades until it is clear that momentum has changed. 'Snail' may stay in trades even if momentum has changed. Snail may only change when the price has moved significantly (This may result in BIG gains, but potentially also BIG losses). 1.2. Purchase Strength (Bull/Bear Signals and Take Profit Signals): Strength ensures a certain amount of verifications required for signals to happen. The more verifications the more accurate that signal is, but it may also change entry and exit points, and you may miss out on some of the extremities. It is highly advised to find the best combination between Speed and Strength for the TimeFrame and Pair you are trading in, as all pairs and TimeFrames move differently. 'High' uses 15 verifications to ensure signal strength. 'Medium' uses 10 verifications to ensure signal strength. 'Low' uses 5 verifications to ensure signal strength. 'Very Low' uses 3 verifications to ensure signal strength. 2. Cipher Signals: Cipher Signals are very strong EMA and SMA crosses, which may drastically help visualize movement and help you to predict where the price will go. All Symbols have counter opposites that cancel each other out (YinYang). Here is a list, in order of general appearance and strength: White Cross / Diamond (Predictive): The initial indicator showing trend movement. Green Cross / Diamond (Regular): Confirms the Predictive and may add a fair bit of strength to trend movement. Blue Cross / Diamond (Confirming): Confirms the Regular, showing the trend might have some decent momentum now. Green / Red X: Gives momentum to the current trend direction, possibly confirming the Confirming Cross/Diamond. Blue / Orange Triangle: may confirm the X, Possible pump / dump of decent size may be coming soon. Green / Red Circle: EITHER confirms the Triangle and may mean big pump / dump is potentially coming, OR it just hit its peak and signifies a potential reversal correction. PAY ATTENTION! Green / Red Flag: Oddball that helps confirm trend movements on the short term. Blue / Yellow Flag: Oddball that helps confirm trend movements on the medium term (Yin / Yang is the long term Oddball). 3. Bull/Bear Signals: Bear and Bull signals are where the momentum has changed enough based on your Purchase Speed and Strength. They generally represent strong price movement in the direction of the signal, and may be more reliable on higher TimeFrames. Please don’t use JUST these signals for analysis, they are only meant to be a fraction of the important data you are using to make your technical analysis. 4. Take Profit Signals: Take Profit signals are guidelines that momentum has started to change back and now may be a good time to take profit. Your Take Profit signals are based on your Take Profit Speed and Strength and may be adjusted to fit your trading style. 5. Information Tables: Information tables display very important data and help to declutter the screen as they are much less intrusive compared to labels. Our Information tables display: Boom Meter, Purchase Strength of Bull/Bear Zones and Yin/Yang State. Boom Meter: Uses over 50 different calculations to determine if the pair is currently 'Dumping' (0-29%), 'Consolidating' (30-70%), or 'Pumping' (71-100%). Bull / Bear Strength: Shows the strength of the current Bull / Bear signal from 0-100% (Signals start at 100% and change when they hit 0%). The % it moves up or down is based on your 'Purchase Strength'. Yin / Yang state: Is one of the strongest EMA/SMA crosses (long term Oddball) within this Indicator and may be a great indication of which way the price is moving. Do keep in mind if the price is consolidating when changing state, it may have the highest chance of switching back also. Once momentum kicks in and there is price movement the state may be confirmed. Refer to other Cipher Symbols, Extremes, Trend, BOLL, Boom %, Bull / Bear % and Bar colors when Bull / Bear Zones are consolidating and Yin / Yang State changes as this is a very strong indecision zone. 6. Bull / Bear Zones: Our Bull / Bear zones are composed of 8 very important EMA lengths that may act as not only Support and Resistance, but they help to potentially display consolidation and momentum change. You can tell when they are getting tight and close together it may represent consolidation and when they start to flip over on each other it may represent a change in momentum. 7. MA Extremes: Our MA Extremes may be 3 of the most important long term moving averages. They don’t always play a role in trades as sometimes they’re way off from the price (cause they’re extreme lengths), but when they are around price or they cross under or over each other, it may represent large changes in price are about to occur. They may be very useful for seeing strong resistance / support locations based on price averages. Extremes may transition from a Support to a Resistance based on its position above or below them and how many times the price has either bounced up off them (Supporting) or Bounced back down after hitting them (Resistance). 8. Pivots: Pivots may be a very important indicator of support and resistance for horizontal price movement. Pivots may represent the current strongest Support and Resistance. When the Pivot changes, it means a new strong Support or Resistance has been created. Sometimes you'll notice the price constantly pushes the pivot during a massive Pump or Dump. This is normal, and may indicate high levels of volatility. This generally also happens when the price is outside of the Bollinger Bands and is also Over or Undervalued. The price usually consolidates for a while after something like this happens before more drastic movement may occur. 9. Trend Lines: Trend lines may be one of the best indicators of support and resistance for diagonal price movement. When a Trend Line fails to hold it may be a strong indication of a dump. Keep a close eye to where Upward and Downward Trend Lines meet. Trend lines can create different trading formations known as Pennants, Flags and Wedges. Please familiarize yourself with these formations So you know what to look for. 10. Bollinger Bands (BOLL): Bollinger Bands may be very useful, and ours have been customized so they may be even more accurate by using a modified calculation that also incorporates volume. Bollinger Bands may be used to see Movement vs Consolidation Zones (When it’s wide vs narrow). It also may be very useful for seeing where the correction areas are likely to be. Price may bounce between top and bottom of the BOLL, unless perhaps in a pump or dump. The Boom Meter may show you whether it is currently: Dumping, Consolidation or Pumping, along with Boom Meter Bar Colors, may be a good indication if it will break the BOLL. The Middle Line of the BOLL (White Line) may be a very strong support / resistance line. If the price closes above or below it, it may be a good indication of the trend changing (it may be one of the first stages to a pump or dump). 11. Boom Meter Bar Colors: Boom Meter bar colors may be very useful for seeing when the bar is Overbought or Underbought. There are 6 different types of boom meter bar colors, they are: Dark Green: RSI may be very Overbought and price going UP (May be in a big pump. NOTICE, chance of small dump correction if Cherry Red bar appears). Light Green: RSI may be slightly Overbought and price going UP (chance of small pump). Light Purple: RSI may be very Underbought and price going UP (May have chance of small correction). Dark Red: RSI may be very Underbought and price going DOWN (May be in a big dump. NOTICE, chance of small pump correction if Light Purple bar appears). Light Orange: RSI may be slightly Underbought and price going DOWN (chance of small dump). Cherry Red: RSI may be very Overbought and price going DOWN (Chance of small correction). 12. True Value Zone: True Value Zones display zones that represent ranges to show what the price may truly belong within. They may be very useful for knowing if the Price is currently not valued correctly, which generally means a correction may happen soon. True Value Zones can swap from Bullish to Bearish and are represented by Red for Bearish and Green for Bullish. For example, if the price is ABOVE and OUTSIDE of the True Value Zone, this means it may be very overvalued and might correct to go back inside the True Value Zone. This correction may be done by either dumping in price back into the zone, or consolidating horizontally back into it over a longer period of time. Vice Versa is also true if it is BELOW and OUTSIDE of the True Value Zone. 13. Bar Strength Index: Bar Strength Index may display how Bullish/Bearish the current bar is. The strength is important to help see if a pump may be losing momentum or vice versa if a dump may correct. Keep in mind, the Bar Strength Index does a small 'refresh' to account for new bars. It may help to keep the Index more accurate. 14. Volume Profile: Volume Profiles may be important to know where the Horizontal Support/Resistance is in Price base on Volume. Our Volume Profile may identify the point where the most volume has occurred within the most relevant timeframe. Volume Profiles are helpful at identifying where Whales have their orders placed. The reason why they are so helpful at identifying whales is when the volume is profiled to a specific area, there may likely be lots of Limit Buy and/or Sells around there. Limit Buys may act as Support and Limit Sells may act as Resistance. It may be very useful to know where these lie within the price, similar to looking at Order Book Data for Whale locations. If you have any questions, comments, ideas or concerns please don't hesitate to contact us. HAPPY TRADING!
Pine Script® göstergesi
YinYangAlgorithms tarafından
2