How to avoid repainting when using security() - PineCoders FAQ

19808 lượt xem
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 lookaheadsecurity() 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.
Phát hành các Ghi chú: Simplified timeframe validation code and updated comments.
Phát hành các Ghi chú: v1.4
We present two new functions to help coders use `security()`:
f_secureSecurity(_symbol, _res, _src)
A worry-free way to use `security()` so that it never repaints, be it on historical or the realtime bar, and doesn't suffer from lookahead bias.
Use the 3 parameters exactly as you would with a normal call to `security()`. Do not include the offset for the source, as the function already takes care of it.

f_security(_symbol, _res, _src, _repaint)
This is for coders who want to offer their users the choice of a repainting/no-repainting version of the HTF data. It uses only one `security()` call for both.
The first three parameters are identical to the `security()` ones. The fourth is a boolean: false for the non-repainting version, true for the repainting version.

Other changes
• The identification of each line has been simplified.
• You can now choose to show different subsets of the lines.
• The default HTF resolution is 5min, so a 1-minute chart will show the lines clearly.
Mã nguồn mở

Với tinh thần của TradingView, tác giả đã xuất bản tập lệnh theo mã nguồn mở, vì thế trader có thể dễ dàng hiểu và tùy chỉnh được. Bạn có thể sử dụng miễn phí, hoặc tùy chỉnh lại mã đã được cấp phép bởi Quy tắc Chung. Bạn có thể sử dụng nó trên biểu đồ.

Bạn muốn sử dụng tập lệnh này trên biểu đồ?
Tools and ideas for all Pine coders:
Our Pine FAQ & Code:
Pine news broadcasts: or

Bình luận

Please help me understand, if I add the following code to your code above to Enter_Long and create an alert condition to Enter_Long, TV gives the repaint warning when creating an alert.
Enter_Long = sec1ft > sec1ft(1) parentheses used instead of brackets
alertcondition(Enter_Long, title='EnterLong', message='EnterLong')

Warning: this alert is based on an indicator that can get repainted.

How can your method be used to not repaint on an alert?
+4 Phản hồi
PineCoders tstanton4
@tstanton4, The warning message is conservative and preventive. Notice it says "may trigger differently". If you followed our recommendations in your code and alert setup, you can trust that your script will not repaint, warning or not.
Phản hồi
@PineCoders thanks for the great reference. Question - can multiple use of security() function in the same script cause repainting by itself even if all the rules to avoid repainting is there? Maybe some TradingView issue, system overloading?

Example from my code-

myvar = security(syminfo.tickerid, TimeFrame, highest(high, len), gaps = barmerge.gaps_off, lookahead = barmerge.lookahead_on)
myvar2 = security(syminfo.tickerid, TimeFrame, lowest(low, len), gaps = barmerge.gaps_off, lookahead = barmerge.lookahead_on)

I have several of those for highest, lowest and in a couple of different timeframes - 1D, 3D. So in total, I can have 6 or 9 security() calls in the script. The script then compares them and fires an indicator if certain condition is met. I can see it repaints every couple of days.

thanks for your thoughts.
+1 Phản hồi
btrades77 btrades77
little correction, the code actual has this -

myvar = security(syminfo.tickerid, TimeFrame, highest(high, len), gaps = barmerge.gaps_off, lookahead = barmerge.lookahead_on)
myvar2 = security(syminfo.tickerid, TimeFrame, lowest(low, len), gaps = barmerge.gaps_off, lookahead = barmerge.lookahead_on)
Phản hồi
btrades77 btrades77
looks like TradingView removes brakets 1 after 'high' and 'low', I have them in the code.
Phản hồi
PineCoders btrades77
1. You can use
 before and 
after your code (without spaces) to post code and preserve brackets.
2. No, using multiple security() calls should not impact results, as long as you are fetching from higher TFs. Using security() at lower TFs than the chart's sometimes produces anomalies.
3. What exactly do you mean when you say "I can see it repaints every couple of days"? A chart would be helpful to understand.
+1 Phản hồi
PineCoders PineCoders
@PineCoders, Sry, previous reply got parsed as well, so see here:
+1 Phản hồi
btrades77 PineCoders

I am testing something on renko 1m tf. I know you don't like renko but my question is-

- chart is 1m renko
- security() function has all the correct non-repainting and asking for highest(high(1), 3) and lowest(low(1), len) on 4D timeframe.
- the script runs some calculations and generates buy/sell signals based on information received from security() calls from a higher (4D tf) and prints them on the chart.

- however after the next 4 days close -> the signals repaint on the chart - new signals showing.

Is there a logical problem? Code seems to be following all the required non-repainting technics.

Also - when asking for a higher timeframes from a security function, for example 4 days - I plot the 4days long lines on a chart to see where 4 days start and where they end for the script calculations. Looks like the 4 days start/end times shifted and as a result, the calculations produced different results and added new signals.

Does it make sense? Is it possible?
Phản hồi
btrades77 btrades77
@PineCoders here is the chart

is it possible that these 4D start/end dates shift to new dates every 4 days?
Phản hồi
PineCoders btrades77
@btrades77, When we were testing this indicator, we noticed that even when called at the same timeframe as the chart, "security()" didn't always return consistent values on Renko charts, so maybe the same is happening to you? Not sure.

And for the record, it's not that we don't like Renko charts. They are a really interesting way of analyzing price action because of how they do without the classic time division. But as is explained in that script's description, they are not reliable for system trading. We do not use them to system trade and don't recommend using them.
Phản hồi
Trang chủ Bộ lọc cổ phiếu Bộ lọc Forex Bộ lọc Tiền điện tử Lịch kinh tế Cách thức hoạt động Tính năng Biểu đồ Trả phí Giới thiệu bạn Quy tắc Áp dụng Trung tâm Trợ giúp Giải pháp cho Website & Nhà môi giới Widget Giải pháp biểu đồ Thư viện Biểu đồ Lightweight Blog & Tin tức Twitter
Hồ sơ Tùy chỉnh Hồ sơ Tài khoản và Thanh toán Giới thiệu bạn Xu Ticket Hỗ trợ của tôi Trung tâm Trợ giúp Tin nhắn riêng Trò chuyện Đăng xuất