Downloading...
Download

Repainting

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® indicator
by PineCoders
14
Smoothing R-Squared ComparisonIntroduction Heyo guys, here I made a comparison between my favorised smoothing algorithms. I chose the R-Squared value as rating factor to accomplish the comparison. The indicator is non-repainting. Description In technical analysis, traders often use moving averages to smooth out the noise in price data and identify trends. While moving averages are a useful tool, they can also obscure important information about the underlying relationship between the price and the smoothed price. One way to evaluate this relationship is by calculating the R-squared value, which represents the proportion of the variance in the price that can be explained by the smoothed price in a linear regression model. This PineScript code implements a smoothing R-squared comparison indicator. It provides a comparison of different smoothing techniques such as Kalman filter, T3, JMA, EMA, SMA, Super Smoother and some special combinations of them. The Kalman filter is a mathematical algorithm that uses a series of measurements observed over time, containing statistical noise and other inaccuracies, and produces estimates of unknown variables that tend to be more accurate than those based on a single measurement. The input parameters for the Kalman filter include the process noise covariance and the measurement noise covariance, which help to adjust the sensitivity of the filter to changes in the input data. The T3 smoothing technique is a popular method used in technical analysis to remove noise from a signal. The input parameters for the T3 smoothing method include the length of the window used for smoothing, the type of smoothing used (Normal or New), and the smoothing factor used to adjust the sensitivity to changes in the input data. The JMA smoothing technique is another popular method used in technical analysis to remove noise from a signal. The input parameters for the JMA smoothing method include the length of the window used for smoothing, the phase used to shift the input data before applying the smoothing algorithm, and the power used to adjust the sensitivity of the JMA to changes in the input data. The EMA and SMA techniques are also popular methods used in technical analysis to remove noise from a signal. The input parameters for the EMA and SMA techniques include the length of the window used for smoothing. The indicator displays a comparison of the R-squared values for each smoothing technique, which provides an indication of how well the technique is fitting the data. Higher R-squared values indicate a better fit. By adjusting the input parameters for each smoothing technique, the user can compare the effectiveness of different techniques in removing noise from the input data. Usage You can use it to find the best fitting smoothing method for the timeframe you usually use. Just apply it on your preferred timeframe and look for the highlighted table cell. Conclusion It seems like the T3 works best on timeframes under 4H. There's where I am active, so I will use this one more in the future. Thank you for checking this out. Enjoy your day and leave me a like or comment. 🧙‍♂️ --- Credits to: ▪@loxx – T3 ▪@balipour – Super Smoother ▪ChatGPT – Wrote 80 % of this article and helped with the research
Pine Script® indicator
by simwai
1
VHF Adaptive Linear Regression KAMAIntroduction Heyo, in this indicator I decided to add VHF adaptivness, linear regression and smoothing to a KAMA in order to squeeze all out of it. KAMA: Developed by Perry Kaufman, Kaufman's Adaptive Moving Average (KAMA) is a moving average designed to account for market noise or volatility. KAMA will closely follow prices when the price swings are relatively small and the noise is low. KAMA will adjust when the price swings widen and follow prices from a greater distance. This trend-following indicator can be used to identify the overall trend, time turning points and filter price movements. VHF: Vertical Horizontal Filter (VHF) was created by Adam White to identify trending and ranging markets. VHF measures the level of trend activity, similar to ADX DI. Vertical Horizontal Filter does not, itself, generate trading signals, but determines whether signals are taken from trend or momentum indicators. Using this trend information, one is then able to derive an average cycle length. Linear Regression Curve: A line that best fits the prices specified over a user-defined time period. This is very good to eliminate bad crosses of KAMA and the pric. Usage You can use this indicator on every timeframe I think. I mostly tested it on 1 min, 5 min and 15 min. Signals Enter Long -> crossover(close, kama) and crossover(kama, kama ) Enter Short -> crossunder(close, kama) and crossunder(kama, kama ) Thanks for checking this out! -- Credits to ▪️@cheatcountry – Hann Window Smoohing ▪️@loxx – VHF and T3 ▪️@LucF – Gradient
Pine Script® indicator
by simwai
Chandelier Exit ZLSMA StrategyIntroduction Heyo guys, I recently checked out some eye-catching trading strategy videos on YT and found one to test. This indicator is based on the video. Usage The recommended timeframe is 5 min. Signals Long Entry => L Label Price crosses above ZLSMA and Chandelier Exit shows Buy Long Exit => green circle Price crosses below ZLSMA Short Entry => S Label Price crosses below ZLSMA and Chandelier Exit shows Sell Short Exit => orange circle Prices crosses above ZLSMA Ty for checking this out. Enjoy! -- Credits to @netweaver2011 - ZLSMA @everget – Chandelier Exit
Pine Script® indicator
by simwai
19
Adaptive Fisherized KSTIntroduction Heyo guys, here is a new adaptive fisherized indicator of me. I applied Inverse Fisher Transform, Ehlers dominant cycle analysis, smoothing and divergence analysis on the Know Sure Thing (KST) indicator. Moreover, the indicator doesn't repaint. Usage I didn't backtest the indicator, but I recommend the 5–15 min timeframe. It can be also used on other timeframs, but I have no experience with that. The indicator has no special filter system, so you need to find an own combo in order to build a trading system. A trend filter like KAMA or my Adaptive Fisherized Trend Intensity Index could fit well. If you find a good combo, let me know it in the comments pls. Signals Zero Line KST crossover 0 => Enter Long KST crossunder 0 => Enter Short Cross KST crossover KST MA => Enter Long KST crossunder KST MA => Enter Short Cross Filtered KST crossover KST MA and KST above 0 => Enter Long KST crossunder KST MA and KST under 0 => Enter Short KST crossunder 0 => Exit Long KST crossover 0 => Exit Short More to read: KST Explanation Enjoy and let me know your opinion! -- Credits to - @tista - @blackcat1402 - @DasanC - @cheatcountry
Pine Script® indicator
by simwai
2
Adaptive Fisherized Stochastic Center of GravityIntroduction I modified the script "Fisher Stochastic Center of Gravity" of @DasanC for this indicator. I added inverse Fisher transform, cycle period adaptiveness mode (Ehlers) and smoothing to it. Moreover, I added buy and sell and beautified some stuff. Lastly, it is also non-repainting! Usage This indicator can be used like a normal stochastic, but I don't recommend divergence analysis on it. That fisherization stuff seems to make the graphs unuseable for that because it tries. It works well on every timeframe I would say, but lower timeframes are recommended, because of the fast nature of stochastic. Usually it does a good job on entry confirmation for reversals and trend continuation trades. Recommended indicator to combine with this indicator is RSI cyclic smoothed v2 . This is the best RSI version I know. In trending market it is recommended to look more on the inner bands and in flat market it is recommended to look more on the outer bands. When RSI shows oversold and this indicator shows a crossover of the Center of Gravity plot through the bottom line -> Long entry is confirmed When RSI shows overbought and this indicator shows a crossunder of the Center of Gravity plot through the top line -> Short entry is confirmed Settings The adaptive mode is enabled by default to give you straight the whole indicator experience. The default settings are optimized, but should be changed depending on the market. An example: Market has a low volatility and a high momentum -> I want a slower/higher length to catch the slower new highs and lows. Market has higher volatility and a low momentum, -> I want a faster/lower length to catch the faster new highs and lows Signals Crossover Buy -> cog crossover signalLine Sell -> cog crossunder signalLine Overbought/Oversold Crossover Buy -> cog crossover lowerBand Sell -> cog crossunder lowerBand I use this indicator a lot, because I don't know a better stochastic on this community here. @DasanC did an awesome work with his version I used as base for this script. Enjoy this indicator and let the profit roll! 🔥
Pine Script® indicator
by simwai
9
All for One Moving AverageThis is a collection of all the moving averages available. Some are built-in, a couple were tricky to source out. Higher timeframes can be specified so you aren't limited to your chart setting. Repainting has been disabled by default. There is also an option to use Heikin Ashi candles as the input source rather than standard bars. Hope that someone finds this useful. If you'd like anything added please DM me and I'll include it! Feel free to copy this into your own strategies/indicators. ~Dark
Pine Script® indicator
by darkbrewery
2
HTF High/Low Repaint StrategyHere is an another attempt to demonstrate repainting and how to avoid them. It happened few times to me that I develop a strategy which is giving immense returns - only to realize after few forward testing that it is repainting. Sometimes, it is well disguised even during forward testing. In this simple strategy, conditions are as below: Buy : When a 3M bar produces high and low higher than it's previous 3M bar high, low Sell : When a 3M bar produces high and low lower than its previous 3M bar high, low. Default setting is : lookahead = on and offset = 0 This means current 3M bar high low is plotted for all the daily bars within this month. Which means, strategy looks ahead of time to see this 3M bar high is higher than previous 3M bar high during the start of the first daily bar. Hence, this combination leads to massive repaint. For example, trade made on October 2nd 2018 already knows well ahead of time that price is going to go down in next 3 months: Similarly, after 2 years on October 2nd 2020 - the strategy already knows that last 3M high is going to be breached on 7th December 2020 Solution: If you are using security for higher timeframes, safer option is always to use offset 1. Further details in the trading view script: BUT It may still repaint if we are passing function to security. For example: f_secureSecurity(_symbol, _res, _src) => security(_symbol, _res, _src , lookahead = barmerge.lookahead This function will likely avoid any repainting with Higher timeframe if we are passing in built variables such as high, low, close, open etc. But, if we try to pass supertrend, this will not produce right results. This is because supertrend calculation in turn uses high/low/close values which do not consider the offset while calculating. Hence, even with offset 1, this will still produce issues. Hence, the call: = f_secureSecurity(syminfo.tickerid, derivedResolution, supertrend(3,10), offset) will again lead to massive repainting. Solution to this is to implement supertrend function and use high, low, close values derived from secureSecurity. Quick tips to identify or be suspicious about repainting Unbelievable results on all timeframes and all instruments with both long and short trades Lower timeframes giving significantly higher returns on backtest when compared to higher timeframe If these things happen, be wary about repainting and do a through check of all security function usage in your strategy. All the best :) PS: Apply 3-5 days resolution and see the fun. Also, WHC is one hell of a Christmas tree. Could have made immense profit in the same strategy even without repainting.
Pine Script® strategy
by Trendoscope
14
Higher TF - Repainting + Limiting backtest resultsThis strategy is for illustration purpose only. Do not use this as there is massive repainting. As usual, I was experimenting with adding different entry/exit filters to my main strategy. Thought of adding higher frame filter, picked the code for getting higher time frame supertrend from someone else's script and copied it without thinking much about it. security(syminfo.tickerid, f_multiple_resolution(HTFMultiplier), supertrend(SupertrendMult, SupertrendPd), lookahead = true, gaps=true) Started getting better results with this result. I was very much impressed and while trying to enhance further, I started disabling my other entry and exit filters which I generally use. That worked pretty well without any of my other filters. Hence, thought I will forward test this on a smaller timeframe. To my surprise, even in forward testing, i was not able to notice repainting very much. It also appeared that smaller timeframes yielded better results. (This wasn't the case with any of my strategies) Which then prompted me to study the security function and lookahead and gap parameters. Learned that lookahead and gap when set to true will lead to massive repainting - specially if you are using higher timeframes. Hence, these parameters are not advisable to use in strategies. Further information here: www.tradingview.com I added three repaint options to further illustrate how security function will work: Yes : Use security with lookahead and merge set to true No - set lookahead false : Use security with lookahead and merge set to false No - do not use security : Falls back to original command on current timeframe. Switch timeframe to HTF resolution to compare the difference. Conclusion : Always set lookahead and gaps to false when using security function in strategies. PS: Script also contains code to limit backtesting to certain days/months/years. This can be used as is in other scripts.
Pine Script® strategy
by Trendoscope
2
How to avoid repainting when NOT using security()Even when your code does not use security() calls, repainting dynamics still come into play in the realtime bar. Script coders and users must understand them and, if they choose to avoid repainting, need to know how to do so. This script demonstrates three methods to avoid repainting when NOT using the security() function. Note that repainting dynamics when not using security() usually only come into play in the realtime bar, as historical data is fixed and thus cannot cause repainting, except in situations related to stock splits or dividend adjustments. For those who don’t want to read Configure your alerts to trigger “Once Per Bar Close” and you’re done. For those who want to understand Put this indicator on a 1 minute or seconds chart with a live symbol. As price changes you will see four of this script’s MAs (all except the two orange ones) move in the realtime bar. You are seeing repainting in action. When the current realtime bar closes and becomes a historical bar, the lines on the historical bars will no longer move, as the bar’s OHLC values are fixed. Note that you may need to refresh your chart to see the correct historical OHLC values, as exchange feeds sometimes produce very slight variations between the end values of the realtime bar and those of the same bar once it becomes a historical bar. Some traders do not use signals generated by a script but simply want to avoid seeing the lines plotted by their scripts move during the realtime bar. They are concerned with repainting of the lines . Other traders use their scripts to evaluate conditions, which they use to either plot markers on the chart, trigger alerts, or both. They may not care about the script’s plotted lines repainting, but do not want their markers to appear/disappear on the chart, nor their alerts to trigger for a condition that becomes true during the realtime bar but is no longer true once it closes. Those traders are more concerned with repainting of signals . For each of the three methods shown in this script’s code, comments explain if its lines, markers and alerts will repaint or not. Through the Settings/Inputs you will be able to control plotting of lines and markers corresponding to each method, as well as experiment with the option, for method 2, of disabling only the lines plotting in the realtime bar while still allowing the markers and alerts to be generated. An unavoidable fact is that non-repainting lines, markers or alerts are always late compared to repainting ones. The good news is that how late they are will in many cases be insignificant, so that the added reliability of the information they provide will largely offset the disadvantages of waiting. Method 1 illustrates the usual way of going about things in a script. Its gray lines and markers will always repaint but repainting of the alerts the marker conditions generate can be avoided by configuring alerts to trigger “Once Per Bar Close”. Because this gray marker repaints, you will occasionally see it appear/disappear during the realtime bar when the gray MAs cross/un-cross. Method 2 plots the same MAs as method 1, but in green. The difference is that it delays its marker condition by one bar to ensure it does not repaint. Its lines will normally repaint but its markers will not, as they pop up after the condition has been confirmed on the bar preceding the realtime bar. Its markers appear at the beginning of the realtime bar and will never disappear. When using this method alerts can be configured to trigger “Once Per Bar” so they fire the moment the marker appears on the chart at the beginning of the realtime bar. Note that the delay incurred between methods 1 and 2 is merely the instant between the close of a realtime bar and the beginning of the next one—a delay measured in milliseconds. Method 2 also allows its lines to be hidden in the realtime bar with the corresponding option in the script’s Settings/Inputs . This will be useful to those wishing to eliminate unreliable lines from the realtime bar. Commented lines in method 2 provide for a 2b option, which is to delay the calculation of the MAs rather than the cross condition. It has the obvious inconvenient of plotting delayed MAs, but may come in handy in some situations. Method 3 is not the best solution when using MAs because it uses the open of bars rather than their close to calculate the MAs. While this provides a way of avoiding repainting, it is not ideal in the case of MA calcs but may come in handy in other cases. The orange lines and markers of method 3 will not repaint because the value of open cannot change in the realtime bar. Because its markers do not repaint, alerts may be configured using “Once Per Bar”. Spend some time playing with the different options and looking at how this indicator’s lines plot and behave when you refresh you chart. We hope everything you need to understand and prevent repainting when not using security() is there. Look first. Then leap.
Pine Script® indicator
by PineCoders
27
How to avoid repainting when using security() - PineCoders FAQNOTE 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. This indicator shows how to avoid repainting when using the security() function to retrieve information from higher timeframes. What do we mean by repainting? Repainting is used to describe three different things, in what we’ve seen in TV members comments on indicators: 1. An indicator showing results that change during the realtime bar, whether the script is using the security() function or not, e.g., a Buy signal that goes on and then off, or a plot that changes values. 2. An indicator that uses future data not yet available on historical bars. 3. An indicator that uses a negative offset= parameter when plotting in order to plot information on past bars. The repainting types we will be discussing here are the first two types, as the third one is intentional—sometimes even intentionally misleading when unscrupulous script writers want their strategy to look better than it is. Let’s be clear about one thing: repainting is not caused by a bug ; it is caused by the different context between historical bars and the realtime bar, and script coders or users not taking the necessary precautions to prevent it. Why should repainting be avoided? Repainting matters because it affects the behavior of Pine scripts in the realtime bar, where the action happens and counts, because that is when traders (or our systems) take decisions where odds must be in our favor. Repainting also matters because if you test a strategy on historical bars using only OHLC values, and then run that same code on the realtime bar with more than OHLC information, scripts not properly written or misconfigured alerts will alter the strategy’s behavior. At that point, you will not be running the same strategy you tested, and this invalidates your test results , which were run while not having the additional price information that is available in the realtime bar. The realtime bar on your charts is only one bar, but it is a very important bar. Coding proper strategies and indicators on TV requires that you understand the variations in script behavior and how information available to the script varies between when the script is running on historical and realtime bars. How does repainting occur? Repainting happens because of something all traders instinctively crave: more information. Contrary to trader lure, more information is not always better. In the realtime bar, all TV indicators (a.k.a. studies ) execute every time price changes (i.e. every tick ). TV strategies will also behave the same way if they use the calc_on_every_tick = true parameter in their strategy() declaration statement (the parameter’s default value is false ). Pine coders must decide if they want their code to use the realtime price information as it comes in, or wait for the realtime bar to close before using the same OHLC values for that bar that would be used on historical bars. Strategy modelers often assume that using realtime price information as it comes in the realtime bar will always improve their results. This is incorrect. More information does not necessarily improve performance because it almost always entails more noise. The extra information may or may not improve results; one cannot know until the code is run in realtime for enough time to provide data that can be analyzed and from which somewhat reliable conclusions can be derived. In any case, as was stated before, it is critical to understand that if your strategy is taking decisions on realtime tick data, you are NOT running the same strategy you tested on historical bars with OHLC values only. How do we avoid repainting? It comes down to using reliable information and properly configuring alerts, if you use them. Here are the main considerations: 1. If your code is using security() calls, use the syntax we propose to obtain reliable data from higher timeframes. 2. If your script is a strategy, do not use the calc_on_every_tick = true parameter unless your strategy uses previous bar information to calculate. 3. If your script is a study and is using current timeframe information that is compared to values obtained from a higher timeframe, even if you can rely on reliable higher timeframe information because you are correctly using the security() function, you still need to ensure the realtime bar’s information you use (a cross of current close over a higher timeframe MA, for example) is consistent with your backtest methodology, i.e. that your script calculates on the close of the realtime bar. If your system is using alerts, the simplest solution is to configure alerts to trigger Once Per Bar Close . If you are not using alerts, the best solution is to use information from the preceding bar. When using previous bar information, alerts can be configured to trigger Once Per Bar safely. What does this indicator do? It shows results for 9 different ways of using the security() function and illustrates the simplest and most effective way to avoid repainting, i.e. using security() as in the example above. To show the indicator’s lines the most clearly, price on the chart is shown with a black line rather than candlesticks. This indicator also shows how misusing security() produces repainting. All combinations of using a 0 or 1 offset to reference the series used in the security() , as well as all combinations of values for the gaps= and lookahead= parameters are shown. The close in the call labeled “BEST” means that once security has reached the upper timeframe (1 day in our case), it will fetch the previous day’s value. The gaps= parameter is not specified as it is off by default and that is what we need. This ensures that the value returned by security() will not contain na values on any of our chart’s bars. The lookahead security() to use the last available value for the higher timeframe bar we are using (the previous day, in our case). This ensures that security() will return the value at the end of the higher timeframe, even if it has not occurred yet. In our case, this has no negative impact since we are requesting the previous day’s value, with has already closed. The indicator’s Settings/Inputs allow you to set: - The higher timeframe security() calls will use - The source security() calls will use - If you want identifying labels printed on the lines that have no gaps (the lines containing gaps are plotted using very thick lines that appear as horizontal blocks of one bar in length) For the lines to be plotted, you need to be on a smaller timeframe than the one used for the security() calls. Comments in the code explain what’s going on. Look first. Then leap.
Pine Script® indicator
by PineCoders
173
Zero Phase Filtering [Repaint] - ExperimentalImportant ! The indicator is for experimental purpose only, it must not be used as a decisional tool but only as a visual one (like Zig-Zag, Fractal etc). The information this indicator display is uncertain and subject to drastic changes over time. If you have further question feel free to pm me. Introduction Most of the filters you will find are causal, this mean that they depend on present and past input values, this explain the lag they produce. Non causal filters however will use future input values. A well know way to get a zero-phase filter is by using the forward backward method, but this is not possible in pinescript as i recall. So we have to use some kind of function that will display future values, this is possible using the security function in version 2 or the one in version 3 using barmerge.lookahead_on . The Use Of A Repainting Indicator Its always better to filter data in order to have a clearer view of what is happening, this can be useful when doing some forecasting or doing less formal kind of analysis. However since it repaint you cant use it as a signal provider or use signals of other indicators using this filter as source. For example if you want to forecast a smooth indicator, the forecast of this indicator under normal circumstances could still have lag associated with it, so you would have to react before your forecast, this wont happen if you apply this filter as your indicator source. The Filter We smooth with a simple moving average the price provided by the security function twice, length control the smoothing level. Since security depend on the time frame you are in you must select your time frame in the indicator parameter selection window. Filtering using 45 minutes time frame close price in a 5 minutes chart, we fix this by selecting our time frame. Consider the fact that the input of the indicator is just periodic price, so sometimes the lag can sometimes be less or more than 0 and the estimation not centered. The indicator can work on time frames up to 1h, after that the filter have some lag, i tried fixing this and i ended up having data errors. Applying our filter as source for the rsi oscillator. Conclusion It is possible to have a kind of zero-phase filters, but it would be better if pinescript could support backward indexing thus making us able to do forward backward filtering. Since noise can affect our analysis, applying smoothing without having to use offset in plot can be considered useful.
Pine Script® indicator
by alexgrover
9
Security() Correction - Realtime vs. Historical BarsProblem Pine's implementation of the security() function behaves differently in realtime vs. historical bars. Specifically, for historical bars, calling security() for a time frame (TF) larger/slower than the current chart's TF will return information about the last completed bar of the higher TF. However, for realtime bars (i.e. if you allow the chart to continue to plot in realtime), security() returns information about the presently in-progress bar of the higher TF. Clearly, this leads to discontinuity that is arbitrarily dependent upon when the user last loaded or refreshed the chart. Solution Fortunately, after understanding the problem, solving it is trivial: use security() normally for historical bars, but switch to explicitly requesting prior candle bars once the indicator is operating on realtime bars. I leave the source open here for any to use as they see fit. For testing, I include an input to allow switching back and forth between standard and corrected behavior. Figure 1 displays the standard behavior we see in security() calls, and Figure 2 displays the behavior after my correction: Figure 1: Typical security() behavior in Pine Figure 2: Corrected security() behavior, forcing historical and realtime bars to refer to the same higher TF bar offset. I publish this mostly as a reminder to myself, so I will not forget and then have to figure it out again next time it comes up in my scripting. V21: Initial release.
Pine Script® indicator
by Lemrin
9
Upper Timeframe - Repaint FixThis script is a proof of concept and one possible solution for how to deal with upper timeframe repainting issues. It works for Strategies only . Strategies that utilize data from upper timeframes can still be subject to repainting issues when forward testing. Users can copy the code and use a similar solution in your own scripts. For full code commentary, explanations and examples visit the backtest-rookies (.com) website.
Pine Script® strategy
by BacktestRookies
1
Daily Close Comparison Strategy (by ChartArt via sirolf2009)Comparing daily close prices as a strategy. This strategy is equal to the very popular "ANN Strategy" coded by sirolf2009(1) which calculates the percentage difference of the daily close price, but this bar-bone version works completely without his Artificial Neural Network (ANN) part. Main difference besides stripping out the ANN is that my version uses close prices instead of OHLC4 prices, because they perform better in backtesting. And the default threshold is set to 0 to keep it simple instead of 0.0014 with a larger step value of 0.001 instead of 0.0001. Just like the ANN strategy this strategy goes long if the close of the current day is larger than the close price of the last day. If the inverse logic is true, the strategy goes short (last close larger current close). (2) This basic strategy does not have any stop loss or take profit money management logic. And I repeat, the credit for the fundamental code idea goes to sirolf2009. (2) Because the multi-time-frame close of the current day is future data, meaning not available in live-trading (also described as repainting), is the reason why this strategy and the original "ANN Strategy" coded by sirolf2009 perform so excellent in backtesting. All trading involves high risk; past performance is not necessarily indicative of future results. Hypothetical or simulated performance results have certain inherent limitations. Unlike an actual performance record, simulated results do not represent actual trading. Also, since the trades have not actually been executed, the results may have under- or over-compensated for the impact, if any, of certain market factors, such as lack of liquidity. Simulated trading programs in general are also subject to the fact that they are designed with the benefit of hindsight. No representation is being made that any account will or is likely to achieve profits or losses similar to those shown. (1) You can get the original code by sirolf2009 including the ANN as indicator here: (1) and this is sirolf2009's very popular strategy version of his ANN:
Pine Script® strategy
by ChartArt
80