Bắt đầu

Tìm kiếm tập lệnh với "信达股份40周年"

Trend Persistence Rate Indicator [CC]The Trend Persistence Rate Indicator was created by Richard Poster (Stocks and Commodities Feb 2021 pg 12) and this indicator is a good trend strength indicator similar to ADX. A good strategy with this indicator according to the author is to combine this with a moving average crossover strategy and a volatility indicator. Buy when the price crosses over the moving average and when the volatility and this indicator are over a selected minimum. I think 30-40 as a minimum for this indicator works well. Exit that position when this indicator peaks and starts to go down and it should be very profitable for you. I have included general buy and sell signals with this indicator as well. Let me know if there are any other indicators you would like to see me publish!
Chỉ báo Pine Script®
của cheatcountry
Momentum StrategyThis strategy uses momentum to determine when to enter and exit positions. The default settings are set to look for a new 63 day high (~1 trading quarter) and a new 40 day relative high. If the stock is trending above the 50 day moving average it is a candidate to be bought. Stops are triggered when price closes below the 20 day or 50 day EMAs depending on how well the stock is trending. A stop could also be triggered even if price continues to move up, but is breaking down on a relative basis to a benchmark either SPX or BTCUSD . The goal is to hold on to our winners for as long as possible and cut the losers as soon as possible. This will alow us to capture the majority of major trends while avoiding many large drawdown and relative losers.
Chiến lược Pine Script®
của PrattyCharts
2
(JS) BallistaAlright so this is a script I made by combining two existing ones and making a really cool discovery that has proven very useful. You'll notice that there are two separate oscillators that are laid on top of each other. The background oscillator is my "Tip-and-Dip" oscillator which you can see here (will refer to this as TnD from here), and the foreground oscillator from the Squeeze , which can be viewed here . Initially I just wanted to see how they interacted with one another and compare them, but this led to some pretty interesting observations. First let me go through the options real quick to get that out of the way, though it is mostly self-explanatory. Lookback Period defines the amount of bars used for the TnD oscillator. Smoothing Value smooths out the TnD output. Standard Deviations is used to calculate the TnD formula. Color Scheme is preset BG colors. Using Dark Mode changes colors based on dark mode or not. Squeeze Momentum On turns the Squeeze in the foreground off and on. Arrows Off turns the arrows on the indicator off and on. Now to explain the indicator a bit more. I have the default lookback period as 40 due to the Squeeze being 20, which makes the TnD oscillator the "slow" output with the Squeeze being the "fast" output. Some initial observations were that when both the Squeeze and the TnD are moving in the direction, when the Squeeze is higher (uptrend) or lower (downtrend) it seems to indicate strength in the move. As the move loses steam you'll notice the Squeeze diverge from the TnD. However, the most useful thing I discovered about the interaction between these two indicators is where the name for it came from. So if you aren't familiar with what a Ballista is, per Wikipedia, "The ballista... sometimes called bolt thrower, was an ancient missile weapon that launched either bolts or stones at a distant target." There are instances where the Squeeze seems to get ahead of itself and gets too far away from the TnD (which is the long term trend between the two). The key thing to look for is an "inverted squeeze" - this is when the squeeze oscillator ends up flipping against the TnD. When this occurs there is an extremely high probability that you'll see price shoot back the opposite way of the Squeeze. I've been using this setup myself for about a year now and have been very satisfied with the results thusfar. I circled some examples on the SPX daily chart here to show you what I mean with the inverted Squeeze shooting back.
Chỉ báo Pine Script®
của J-Streak
22
RSI Trend Indicator [paRSI]The Relative Strength Index ( RSI ) is a measurement used by traders to assess the price momentum. It is scaled from 0 to 100. when RSI reads below 30, it is usually interpreted as oversold and when RSI is above 70 it is usually interpreted as overbought. However, it is usually not profitable to trade based on overbought and oversold signal. RSI Trend Indicator or as I like to call it "paRSI" ("Parsa (my name) + RSI") shows that when RSI is above a specific number (default value = 60) it indicates bullish trend and when RSI is below a specific number (default value = 40 ) it indicates bearish trend. Lastly when RSI is below the 2 specified numbers it indicates a neutral trend. I don't recommend trading based on this single indicator. If you're a trend trader this might be useful tool in addition to your own strategy Usage: If the created pattern has worked previously on the chart, you could enter on the first stages of the green or red section (depending on the market's trend). It is not recommended to trade in any direction when there is no color *THIS IS A TREND FOLLOWING STRATEGY AND DOES NOT WORK ON ALL MARKETS*
Chỉ báo Pine Script®
của parsazahed
1
Excitement - Crypto Surfer v1For those of us who need more excitement in our crypto journey besides just HODL, here’s a simple crypto robot that trades on the hourly (1H) candles. I call it the Crypto Surfer because it uses the 20 and 40 EMAs (Exponential Moving Averages) to decide when to enter and exit; price tends to “surf” above these EMAs when it is bullish, and “sink” below these EMAs when it is bearish. An additional 160 SMA (Simple Moving Average) with slope-angle detection, was added as a bull / bear filter to reduce the sting of drawdowns, by filtering-out long trades in a prolonged bear market. USER NOTES: - This script will buy $10,000 USD worth of crypto-currency per trade. - It will only open one trade at a time. - It has been backtested on all the high market cap coins such as Bitcoin, Ethereum, Binance Coin, Polkadot, Cardano. - It should be run on the Hourly (H1) chart. - In general, this moving average strategy *should be* profitable for 80% to 90% of the coins out there - The 160 SMA filter with slope angle detection is designed to stop you from going long in a bear market. - It is recommended you copy this script and modify it to suit your preferred coin during backtesting, before running live. - Trading is inherently risky (exciting), and I shall not be liable for any losses you incur, even if these losses are due to sampling bias.
Chiến lược Pine Script®
của UnknownUnicorn1373033
Quantitative Qualitative Estimation QQE The QQE indicator is a momentum based indicator to determine trend and sideways. The Qualitative Quantitative Estimation (QQE) indicator works like a smoother version of the popular Relative Strength Index (RSI) indicator. QQE expands on RSI by adding two volatility based trailing stop lines. These trailing stop lines are composed of a fast and a slow moving Average True Range (ATR). These ATR lines are smoothed making this indicator less susceptible to short term volatility. The most common method of using QQE is to look for crosses of the fast and slow moving trailing stop lines during periods when the QQE line reflects overbought or oversold conditions Qualitative Quantitative Estimation made up of a smoothed Relative Strength Index (RSI) indicator plus fast and slow volatility-based trailing levels. Qualitative Quantitative Estimation can be used in two directions: 1.Determine the trend, i.e. if the line is above the 50 level, the trend is ascending, if below - descending; 2.Search for signals at the moment of crossing of the QQE FAST (maroon) and QQE SLOW (blue) lines. The QQE itself is generally considered to indicate an up-trend ifQQE FAST is above QQE SLOW, and a down-trend if below QQE SLOW. Often a middle-range between 40 and 60 is set and if the indicator is in that range, then the market is considered to be tracking sideways, or in no trend. You will need to set only one parameter – “SF” "RSI SMoothing Factor", an analogue of the period in RSI. By the way, judging from the open source information, the algorithm used the standard strength index with a period of 14 for calculations. Various signals can be created from the indicator such as: -Buy when QQE FAST crosses above QQE SLOW below 50 level or just buy when QQE lines crosses above 50 level. -Sell when QQE FAST crosses below QQE SLOW above 50 level or just sell when QQE lines crosses below 50 level. WARNING: QQE IS A RSI BASED INDICATOR SO THAT IT CAN TRIGGER FALSE SIGNALS DURING DIVERGENCES! Kıvanç Özbilgiç
Chỉ báo Pine Script®
của KivancOzbilgic
47
[SK] Double MACDThe Double MACD indicator is precisely two different MACD indicators plotted on the same axis for precise visual correlation between each other. This correlation provides more information than a single regular MACD by allowing you to compare the signals of a shorter timeframe to the default or longer timeframe, showing the strength of the change in momentum and the peak of the momentum between both configurations. The indicator has cloud options by default if you toggle on the MACD / Signal lines for better readability. The cloud will change color to the line on top of it's set. This is to help you not get lost in the 4 different lines. Customize the indicator to your preference and make it your own If you'd like a candle like visualization, change the short MACD plot style to a histogram. For a beautiful double bars style, select bars on both configurations and set the transparency to 30 - 40 For a dynamic moving average style, go with the line plot style ( default ) All MACD/Signal lines are toggled off by default, toggle them on in the inputs section. On the styles panel, you can turn off the cloud fills or the lines. Change all the colors you'd like!
Chỉ báo Pine Script®
của sirkriz
10
Grid Bot RSIGrid Bot Simulator. Based on RSI levels. How it works: Prices are divided into grids, or trade zones, that are based on RSI levels. Buys will trigger when the RSI crosses into a higher zone, after descending. Sells will trigger when the RSI crosses into a lower zone, after ascending. After triggering, a new signal will not be produced until the RSI progresses into better zone. Standard Settings : RSI Length Number of Grids RSI Type : Standard RSI or Jurik RSX (based on Everget’s formula) Show All Grids Experimental Features (Adjust in settings menu) : No Trade Zone : RSI Levels where no trades will be signaled. Adjust to prevent over-buying/selling in narrow markets. Default: 35-65: No Trade Zone (40-60) Aggression Level : Increase aggressiveness to stack buys/sells at extreme RSI levels: Aggression = high Aggression = low Market Direction : If market is trending up, the bot will skip every other sell ( = more buys than sells). If down, will skip every other buy (more sells than buys). Default: neutral. Market Direction: down Market Direction: neutral
Chỉ báo Pine Script®
của xxattaxx
24
EMA BANDS//Trades have been checked periodically on daily charts with normal, basically, you'll set in trades for weeks, months, and years in some cases depending on the time frame and strategy you use, DO NOT TRADE ON MARGIN INTEREST WILL RUIN YOU. //You can use the strategies on lower timeframes, however, you'll need to be able to execute trades during all market hours if you choose anything less than a daily. //You MUST stay in your trade until the very end. that means even if you open the trade and you're super in red DON'T DUMP. //Set stop losses to no more than 50% of your entry price. Less is better but understand that you may be stomped out of a trade that could reverse after a 40-49% pullback. //I suggest you pull initial capital out after you 2x to lock in your profit. //You must also have the ability to sell/buy after market hours, you'll make your trades generally one-two hours post-market in most cases. //The green line gives a simple average of the last 1618 candles. The further price action is from the mean, the more the price will be pulled back. (Ideally) //Strategy One (Safe/Slow) //Buy when the closing price is less than the lower bounds of all bands. This does not include the green "Mean" line //Sell when the closing price is greater than the upper bounds of all bands. Again, this does not include the green "Mean" line //Strategy Two (Neutral) //Buy when the closing price is less than the bounds of 3-4 out of the 4 bands. //Sell when the closing price is greater than the bounds of 3-4 out of the 4 bands. //This means that you execute trades even if the closing price is still within one band. //You'll still execute orders even if the closing price is outside of all bands //Strategy Three (Least Safe/Fast) //Buy when the closing price is less than the bounds of 2-4 out of the 4 bands. //Sell when the closing price is greater than the bounds of 2-4 out of the 4 bands. //This means that you execute trades even if the closing price is still within two bands. //You'll still execute orders even if the closing price is outside of all bands //You'll still execute orders even if the closing price is outside of 3 of 4 bands
Chỉ báo Pine Script®
của liable_ox
ADX Strategy (original)ADX Strategy Description: Generates a long entry signal when the Average Directional Index (ADX) value is greater than the trendlevel and the close is greater than the filter value, and/or generates a short entry signal when the ADX value is greater than the trendlevel and the close is less than the filter value. The Average Directional Index evaluates the strength of a current trend. The ADX is an oscillator that fluctuates between 0 and 100. Values below 20 indicate a weak trend, values above 40 indicate a strong trend. The direction of the trend is not measured by this indicator. As usual, the script features signal filtering/generation and a rough estimate of its performance.
Chỉ báo Pine Script®
của capissimo
5
Custom Screener with Alerts V2 [QuantNomad]TradingView just recently announced the alert() function that allows you to create dynamic alerts from both strategies and studies. So I decided to update custom screener I published before. It was based on alerts from orders in strategies, that was the only way to create dynamic alerts in PineScript at that point. With the alert() function code become cleaner and more readable. It works for up to 40 symbols at the same time. You can create an alert from it easily by selecting screener name from the list and then selecting "Any alert() function call". No additional configuration is required, message and alert on close I set up in the code. I created as an example a screener that tracks both overbought (RSI > 70) and oversold stocks (RSI < 30). To create your own screener you have to change only screenerFunc(). By design it should output 2 values: cond - True/False Boolean variable. Should this instrument be displayed in the screener? value - Additional numeric value you can display in your screener. I display RSI level for selected stocks for example. Link to the old screener: Disclaimer Please remember that past performance may not be indicative of future results. Due to various factors, including changing market conditions, the strategy may no longer perform as good as in historical backtesting. This post and the script don’t provide any financial advice.
Chỉ báo Pine Script®
của QuantNomad
29
Caco Maia's Double break out A setup created and used by Caco Maia — Brazilian trader with over 40 years experience. It is based on the simultaneous crossing of the price with 8 and 20 moving averages, filtered by TRIX and Stochastic indicators. How to use: Wait for the signal bar to close. Observe the context of the chart and direction of the trend. For example: do not follow the signal with the moving averages are pointing to the opposite direction of the trade/signal. Better if used with other indicators to confirm the trade entry. --------------------- Setup do duplo rompimento do Caco Maia. Indica o rompimento simultâneo do preço com as médias móveis de 8 e 20, filtrado pelo TRIX e Estocástico. Como usar: Espere o fechamento da barra com o sinal. Observe o contexto do gráfico e a direção da tendência. Por exemplo: não inicie o trade se as média móveis estão apontando para a direção oposta ao sinal. Melhor se usado com outros indicadores para confirmar a entrada no trade.
Chỉ báo Pine Script®
của Agulhada
6
Didi's TrendChanges the background according to the DMI trend. Based on the way the infamous Brazilian trader with over 40 years experience, Master Didi Aguiar reads the Directional Movement Index — one indicators in his setup. It's read this way: Only trade on the direction of the trend. Start the trade when accelerating: Blue = Long trend Bright Blue = Long trend, accelerating Purple = Short trend Bright Purple = Short trend, accelerating Change from bright to dark color = ADX's bounce, the first signal to exit the trade. Nor coloured background = no trend. Use other indicators to confirm your trades. Not recommended for color blind people :) ----------------------------------------- Indicador que muda a cor do fundo de acordo com a tendencia. É baseado na maneira que Didi Aguiar lê o DMI e o ADX . Lê-se assim: Fundo azul = Tendencia de compra Fundo roxo = Tendencia de venda Cor mais saturada (vibrante) = Tendencia acelerante Passou de cor mais clara para mais escura = Kick do ADX Sem coloração de fundo = Sem tendencia Não é indicado para pessoas que sofrem de daltonismo.
Chỉ báo Pine Script®
của Agulhada
4
`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.
Chỉ báo Pine Script®
của PineCoders
61