Şimdi başlat

Komut dosyalarını "市值60亿的股票" için ara

[expiremental] moving figures - RDSI Hi, I give you an experimental 'indicator', which is used here to plot the red RDSI against the green RDSI, it has nothing to do with values, it just shows if one is bigger than the other, and this in a unique way. You can choose if each minute another figure emerges, or you can pick 1 of the 60 figures. Each second the figure will move (just fun, or perhaps useful for other Pine coders) You can play around a bit with height and position of the Y-axis, or radius. The 'adjustment' is present because it didn't always was plotted (x became - sometimes) Normally it would not happen, but I left it there for now. The 'non RDSI related' checkbox can be used if you just want a figure that animates you through some waiting - boring periods, not related to the RDSI, just figures that move :) To be concluded, this is just humbly made, perhaps to inspire some of the great Pine coders out there! Cheers! Some figures:
Pine Script® göstergesi
fikira tarafından
6
Flunki T-WAP minus MA Oscillator Yo, Possible the last of these for now, and mostly for the sake of completeness.. This is.. Another simple oscillator that show the difference in price between a selectable timeframe TWAP and a Moving Average of that TWAP This is shown as a histogram. Use numeric TWAP values for minutes (30, 60 ,720 whatever) and D, 3D, W, M for higher values There is also a global timeframe which will set the timeframe for a global alternate timeframe (instead of current chart resolution) On top of that is a Moving Average of the histogram value, shown as a blue / red line with an option to highlight this MA crossing zero, and an option to colour bars to this line. The major difference between this Oscillator, and the other script (Flunki VWAP minus MA Oscillator) (I treid to insert a link but it's invisible so it would seem, anyway.. ) is that VWAP is usually calculated daily, so there is a sharp move upon the daily close, as VWAP starts a new day. Using TWAP this does not occur, so gives smoother transitions ; also the timeframe for TWAP is selectable for additional wap fun. Simple idea : Code open Enjoy !
Pine Script® göstergesi
syrinxflunki tarafından
7
Flunki TWAP minus MTF TWAP Oscillator Heys, Herewith a another simple oscillator that show the difference in price between a selectable timeframe TWAP and another alternative selectable timeframe TWAP This is shown as a histogram. Use numeric TWAP values for minutes (30, 60 ,720 whatever) and D, 3D, W, M for higher values There is also a global timeframe which will set the timeframe for a global alternate timeframe (instead of current chart resolution) On top of that is a Moving Average of the histogram value, shown as a blue / red line with an option to highlight this MA crossing zero, and an option to colour bars to this line. Simple idea : Code open Enjoy !
Pine Script® göstergesi
syrinxflunki tarafından
4
[blackcat] L1 Swing Reversal IndicatorLevel: 1 Background Many asked me about swing reversal indicators. There are many but less of them can guarantee high win rate. Because market is complex, the reversals can be nested together, which means sub level reversals will be contained in higher level waves. This can be well explained by Elloit wave theory. Function Here it is a simple moving average based swing reversal indicator as an example for many others to improve it. Although it simple, it could be very powerful to dedicated trading pairs in specific time frame. One can adjust N1~N4 as SMA peiords from short to long to customized this indicator or even by trying different moving average types to enhance its accuracy. Key Signal N1~N4 --> SMA look back periods OB --> Overbought Threshold OS --> Oversold Threshold Pros and Cons Simpe but powerful. More feedbacks are appreciated. Remarks Easy to be customized or integrated to your trading system. Readme In real life, I am a prolific inventor. I have successfully applied for more than 60 international and regional patents in the past 12 years. But in the past two years or so, I have tried to transfer my creativity to the development of trading strategies. Tradingview is the ideal platform for me. I am selecting and contributing some of the hundreds of scripts to publish in Tradingview community. Welcome everyone to interact with me to discuss these interesting pine scripts. The scripts posted are categorized into 5 levels according to my efforts or manhours put into these works. Level 1 : interesting script snippets or distinctive improvement from classic indicators or strategy. Level 1 scripts can usually appear in more complex indicators as a function module or element. Level 2 : composite indicator/strategy. By selecting or combining several independent or dependent functions or sub indicators in proper way, the composite script exhibits a resonance phenomenon which can filter out noise or fake trading signal to enhance trading confidence level. Level 3 : comprehensive indicator/strategy. They are simple trading systems based on my strategies. They are commonly containing several or all of entry signal, close signal, stop loss, take profit, re-entry, risk management, and position sizing techniques. Even some interesting fundamental and mass psychological aspects are incorporated. Level 4 : script snippets or functions that do not disclose source code. Interesting element that can reveal market laws and work as raw material for indicators and strategies. If you find Level 1~2 scripts are helpful, Level 4 is a private version that took me far more efforts to develop. Level 5 : indicator/strategy that do not disclose source code. private version of Level 3 script with my accumulated script processing skills or a large number of custom functions. I had a private function library built in past two years. Level 5 scripts use many of them to achieve private trading strategy.
Pine Script® göstergesi
blackcat1402 tarafından
10
[blackcat] L1 Enhanced Awesome OscillatorLevel: 1 Background The awesome oscillator is just that, an oscillator by Bill Williams. In contrast to the slow stochastics, which ranges from +100 to -100, the fantastic oscillator is limitless. On the surface, one might think that the fantastic oscillator is made up of a complicated algorithm developed by a Whiz Kid from M.I.T. You will be surprised to learn that the indicator is a basic calculation of two simple moving averages. I made some improvements on it by introducing some novel moving average functions and choppiness index as L1 Enhanced Awesome Oscillator. Function Yellow bars for bull and fuchsia bars for bear with candles. Buying and selling signal is provided. Divergence signal is provided. Choppiness index is used as a green background color, which indicates trends when it under green color. The choppiness index is used to filter out entry signals. Key Signal yellow candle --> bull fuchsia candle --> bear yellow DIV label --> bottom divergence fuchsia DIV label --> top divergence red SELL label --> short entry green BUY label --> long entry Remarks Feedbacks are appreciated. Readme In real life, I am a prolific inventor. I have successfully applied for more than 60 international and regional patents in the past 12 years. But in the past two years or so, I have tried to transfer my creativity to the development of trading strategies. Tradingview is the ideal platform for me. I am selecting and contributing some of the hundreds of scripts to publish in Tradingview community. Welcome everyone to interact with me to discuss these interesting pine scripts. The scripts posted are categorized into 5 levels according to my efforts or manhours put into these works. Level 1 : interesting script snippets or distinctive improvement from classic indicators or strategy. Level 1 scripts can usually appear in more complex indicators as a function module or element. Level 2 : composite indicator/strategy. By selecting or combining several independent or dependent functions or sub indicators in proper way, the composite script exhibits a resonance phenomenon which can filter out noise or fake trading signal to enhance trading confidence level. Level 3 : comprehensive indicator/strategy. They are simple trading systems based on my strategies. They are commonly containing several or all of entry signal, close signal, stop loss, take profit, re-entry, risk management, and position sizing techniques. Even some interesting fundamental and mass psychological aspects are incorporated. Level 4 : script snippets or functions that do not disclose source code. Interesting element that can reveal market laws and work as raw material for indicators and strategies. If you find Level 1~2 scripts are helpful, Level 4 is a private version that took me far more efforts to develop. Level 5 : indicator/strategy that do not disclose source code. private version of Level 3 script with my accumulated script processing skills or a large number of custom functions. I had a private function library built in past two years. Level 5 scripts use many of them to achieve private trading strategy.
Pine Script® göstergesi
blackcat1402 tarafından
15
Gann RetracementThe indicator is based on W. D. Gann's method of retracement studies. Gann looked at stock retracement action in terms of Halves (1/2), Thirds (1/3, 2/3), Fifths (1/5, 2/5, 3/5, and 4/5) and more importantly the Eighths (1/8, 2/8, 3/8, 4/8, 5/8, 6/8, and 7/8). Needless to say, {2, 3, 5, 8} are the only Fibonacci numbers between 1 to 10. These ratios can easily be visualized in the form of division of a Circle as follows : Divide the circle in 12 equal parts of 30 degree each to produce the Thirds : 30 x 4 = 120 is 1/3 of 360 30 x 8 = 240 is 2/3 of 360 The 30 degree retracement captures fundamental geometric shapes like a regular Triangle (120-240-360), a Square (90-180-270-360), and a regular Hexagon (60-120-180-240-300-360) inscribed inside of the circle. Now, divide the circle in 10 equal parts of 36 degree each to produce the Fifths : 36 x 2 = 72 is 1/5 of 360 36 x 4 = 144 is 2/5 of 360 36 x 6 = 216 is 3/5 of 360 36 x 8 = 288 is 4/5 of 360 where, (72-144-216-288-360) is a regular Pentagon. Finally, divide the circle in 8 equal parts of 45 degree each to produce the Eighths : 45 x 1 = 45 is 1/8 of 360 45 x 2 = 90 is 2/8 of 360 45 x 3 = 135 is 3/8 of 360 45 x 4 = 180 is 4/8 of 360 45 x 5 = 225 is 5/8 of 360 45 x 6 = 270 is 6/8 of 360 45 x 7 = 315 is 7/8 of 360 where, (45-90-135-180-225-270-315-360) is a regular Octagon. How to Use this indicator ? The indicator generates Gann retracement levels between any two significant price points, such as a high and a low. Input : Swing High (significant high price point, such as a top) Swing Low (significant low price point, such as a bottom) Degree (degree of retracement) Output : Gann retracement levels (color coded as follows) : Swing High and Swing Low (BLUE) 50% retracement (ORANGE) Retracements between Swing Low and 50% level (RED) Retracements between 50% level and Swing High (LIME)
Pine Script® göstergesi
MoneyNaad tarafından
4
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ç
Pine Script® göstergesi
KivancOzbilgic tarafından
47
Trend Following TriggerThis is a basic trend following system that using 5, 13, 34 EMAs cross-overs as triggers. The 5,13 EMA pair is tracking the short-term momentum , when 5 EMA crosses over 13 EMA up or down, the script will develop a bullish "fast pivot" point or "FP" , which can be used as the first entry of a position. The 13, 34 EMA pair is tracking the mid-term trend , when the 13 EMA crosses over 34 EMA up or down, the script will develop a bullish "slow pivot" point or "SP" , which can be used as the second entry of a position. And the exit would be when a bearish "Slow Pivot" is created. Note that the basic assumption of trend following is that you should trade with the trend, not against the trend. Thus I added the 50, 60 MA pair, as well as 200, 220 MA pair for long-term trend reference, which is an idea that I learned from the Vegas Tunneling Trading System. Example,
Pine Script® göstergesi
Riverhorse tarafından
Percentage S&RThis indicator can be used to provide "hidden" Support and Resistance levels, which can be useful for profit-taking and stop-loss levels on swing trades. The middle white line is the midpoint of the range of the previous 60 candles. The grey lines above equal the midpoint line +5%, +10%, +15% and +20%. The grey lines below equal the midpoint line -5%, -10%, -15% and -20%. This indicator is similar to a Moving Average Envelope, but without the lag. Doesn't work as well on the extreme low or high time frames. 1 hour - Daily charts seem to be best.
Pine Script® göstergesi
C-Barkley tarafından
1
Volume Info from Lower Time FramesHello Traders, We are now able to get info from lower time frames, Many Thanks to Pine Team .This script gets volume info from lower time frames and give alert if there is extreme volumes on last X lower time frame candles (if last X volumes are higher than volume moving average). so that if you set alerts on different securities then you will be able get alert if there is extreme volume moves and you can check the chart immediately. The options: Timeframe in Seconds : you can set lower time frames in seconds. by default it's 5 seconds. if you set it 60 then it will show 1min volumes, if you set it 1 then it will show 1 seconds volumes MA Length : The script draws simple moving average using this length info. by default it's 20. Number of Bars to Check for Alert : by default it's 5. meaning that if last 5 candles is greater than moving average and if you set alert then you get the alert "Extreme Volume" Other options are for colors and line width. As you can see in following example, chart time frame is 1 hour and the script shows volume info of 5 seconds candles: Enjoy!
Pine Script® göstergesi
LonesomeTheBlue tarafından
35
Matrix Library (Linear Algebra, incl Multiple Linear Regression)What's this all about? Ever since 1D arrays were added to Pine Script, many wonderful new opportunities have opened up. There has been a few implementations of matrices and matrix math (most notably by TradingView-user tbiktag in his recent Moving Regression script: ). However, so far, no comprehensive libraries for matrix math and linear algebra has been developed. This script aims to change that. I'm not math expert, but I like learning new things, so I took it upon myself to relearn linear algebra these past few months, and create a matrix math library for Pine Script. The goal with the library was to make a comprehensive collection of functions that can be used to perform as many of the standard operations on matrices as possible, and to implement functions to solve systems of linear equations. The library implements matrices using arrays, and many standard functions to manipulate these matrices have been added as well. The main purpose of the library is to give users the ability to solve systems of linear equations (useful for Multiple Linear Regression with K number of independent variables for example), but it can also be used to simulate 2D arrays for any purpose. So how do I use this thing? Personally, what I do with my private Pine Script libraries is I keep them stored as text-files in a Libraries folder, and I copy and paste them into my code when I need them. This library is quite large, so I have made sure to use brackets in comments to easily hide any part of the code. This helps with big libraries like this one. The parts of this script that you need to copy are labeled "MathLib", "ArrayLib", and "MatrixLib". The matrix library is dependent on the functions from these other two libraries, but they are stripped down to only include the functions used by the MatrixLib library. When you have the code in your script (pasted somewhere below the "study()" call), you can create a matrix by calling one of the constructor functions. All functions in this library start with "matrix_", and all constructors start with either "create" or "copy". I suggest you read through the code though. The functions have very descriptive names, and a short description of what each function does is included in a header comment directly above it. The functions generally come in the following order: Constructors: These are used to create matrices (empy with no rows or columns, set shape filled with 0s, from a time series or an array, and so on). Getters and setters: These are used to get data from a matrix (like the value of an element or a full row or column). Matrix manipulations: These functions manipulate the matrix in some way (for example, functions to append columns or rows to a matrix). Matrix operations: These are the matrix operations. They include things like basic math operations for two indices, to transposing a matrix. Decompositions and solvers: Next up are functions to solve systems of linear equations. These include LU and QR decomposition and solvers, and functions for calculating the pseudo-inverse or inverse of a matrix. Multiple Linear Regression: Lastly, we find an implementation of a multiple linear regression, including all the standard statistics one can expect to find in most statistical software packages. Are there any working examples of how to use the library? Yes, at the very end of the script, there is an example that plots the predictions from a multiple linear regression with two independent (explanatory) X variables, regressing the chart data (the Y variable) on these X variables. You can look at this code to see a real-world example of how to use the code in this library. Are there any limitations? There are no hard limiations, but the matrices uses arrays, so the number of elements can never exceed the number of elements supported by Pine Script (minus 2, since two elements are used internally by the library to store row and column count). Some of the operations do use a lot of resources though, and as a result, some things can not be done without timing out. This can vary from time to time as well, as this is primarily dependent on the available resources from the Pine Script servers. For instance, the multiple linear regression cannot be used with a lookback window above 10 or 12 most of the time, if the statistics are reported. If no statistics are reported (and therefore not calculated), the lookback window can usually be extended to around 60-80 bars before the servers time out the execution. Hopefully the dev-team at TradingView sees this script and find ways to implement this functionality diretly into Pine Script, as that would speed up many of the operations and make things like MLR (multiple linear regression) possible on a bigger lookback window. Some parting words This library has taken a few months to write, and I have taken all the steps I can think of to test it for bugs. Some may have slipped through anyway, so please let me know if you find any, and I'll try my best to fix them when I have time to do so. This library is intended to help the community. Therefore, I am releasing the library as open source, in the hopes that people may improving on it, or using it in their own work. If you do make something cool with this, or if you find ways to improve the code, please let me know in the comments.
Pine Script® göstergesi
lejmer tarafından
21
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
Pine Script® göstergesi
xxattaxx tarafından
24
RSI Classic Strategy (by Coinrule)One of the questions hobbyist traders more often ask is: what is the perfect trading indicator? Every indicator is just a tool, so its efficiency is proportional to your ability to read its signals and translate them into an actionable trading strategy. The RSI is likely the most flexible and easy to use among the technical indicators. This trading strategy tries to catch short-term swings on the coins of your choice with a simple yet profitable setup. Buy when the RSI is lower than 30 (you can adjust it to 35 in times of steep uptrend). Sell when the RSI is greater than 65 (the target may range between 60 and 75 depending on the volatility of the coin). Note that the buy signal comes when the indicator crosses below 30 and not when it crosses above 30 as it happens on the built-in RSI strategy on Tradingview. The present script overperforms the built-in strategy, even adding trading fees and using a lower amount of capital for each trade (30%). That means that the system can deliver higher net-profits with lower risk levels. A typical example of market conditions where this strategy works perfectly is as follows. The first initial breakout indicates that a new leg up in the trend may start. Bitcoin starts to trade within a range which you can identify when it reaches the point 3. That is the perfect time to start the rule because - trading within a channel anticipates possible swings up and down - the trend is on the upside, providing low downside risk in buying the dips. This strategy works well with selected coins of your choice, and it's a great fit on leverage exchanges like Binance Futures. If you prefer to run it across all available coins on the market, instead, you may choose an optimized version.
Pine Script® stratejisi
Coinrule tarafından
6
New Map For TradersUsing previous principles, This setup plots 60 moving averages on the chart. The averages are colored using a normalized oscillation technique (FFT). To achieve the same display as above, put the same indicator twice and set the 'osx' parameter of one to 0 and the other to 2. Feel free to play with the 'mul' parameter in ranges between 1-90. Most useful ranges will be 4-16 in my opinion. Leave me a message if you'd like to explore the behaviors of the fractal dimension further ;)
Pine Script® göstergesi
Spectrum101 tarafından
6
Initial Balance Markets Time ZonesThe below script is based on Initial Balance. Initial Balance is based on the highest and lowest points of Price Action (PA) within the first 60 minutes of trading. There is so much information available online, reference Initial Balance, that I have not provided a reference. Most indicators I have seen have been solely based on UTC 0000 Initial Balance. My aim with this indicator was to be able to visualize how other time zones market openings Initial Balance affect PA. The three market openings I chose to code in are: London 0800 to 0900 New York 1430 to 1530 Asia 0000 to 0100 Within the script I have given the user the option to select to see with a green or red background when PA is above all zones Initial Balance high (green) or PA is below all zones Initial Balance low (red). Alerts are also coded in, to prompt the user that PA has gone above or below as per above. The Initial Balance high and lows also offer another form of areas of confluence. Below are some examples of IB in action: LTC NULS UNFI DEXE
Pine Script® göstergesi
Frien_dd-DisDev tarafından
9
RSI-Last-3-ExtremaThis script indicates when the current Relative Strength Index of the last 8 closes is beyond a level from center oscillation which signals the equity is likely to reverse course. When it is the lowest RSI reading of the prior 3 readings and below 25, a green vertical bar will appear signaling a potential BUY point. Likewise, the highest reading of the prior 3 RSI readings and above 75 will signal a vertical red bar or SELL signal. The bar has to have a final close price for the signal to be active. Reversal could take a few more bars to occur depending on the timeframe and equity symbol. You will be able to find many charts that have this signal perfectly finding the top or bottom of a significant trend. It successfully indicates profitable reversal around 80% of the time. So far, It is 85% accurate or better in determining downtrend start points on the Daily, 120, 60, 30 Minute charts according to the study of more than 10,000 occurrences. It is 86% accurate on the 30 Minute chart. This is another tool I use in finding or confirming potential price action. Hope you find it useful. To add this, favorite the script by clicking "Add to your Favorite Indicators" at the top of the code portion below. On your top tool bar is an "fx" button with a downward arrow to the right of it. Click on the downward arrow/caret and scroll down to "RSI-Last-3-Extrema". Click on this title and it should add to the bottom of your current chart. If you do not see BUY (green vertical bars) or SELL (red vertical bars) right away, try other charts and timeframes.
Pine Script® göstergesi
StockSignaler tarafından
2
`security()` revisited [PineCoders]NOTE The non-repainting technique in this publication that relies on bar states is now deprecated, as we have identified inconsistencies that undermine its credibility as a universal solution. The outputs that use the technique are still available for reference in this publication. However, we do not endorse its usage. See this publication for more information about the current best practices for requesting HTF data and why they work. █  OVERVIEW This script presents a new function to help coders use security() in both repainting and non-repainting modes. We revisit this often misunderstood and misused function, and explain its behavior in different contexts, in the hope of dispelling some of the coder lure surrounding it. The function is incredibly powerful, yet misused, it can become a dangerous WMD and an instrument of deception, for both coders and traders. We will discuss:  • How to use our new `f_security()` function.  • The behavior of Pine code and security() on the three very different types of bars that make up any chart.  • Why what you see on a chart is a simulation, and should be taken with a grain of salt.  • Why we are presenting a new version of a function handling security() calls.  • Other topics of interest to coders using higher timeframe (HTF) data. █  WARNING We have tried to deliver a function that is simple to use and will, in non-repainting mode, produce reliable results for both experienced and novice coders. If you are a novice coder, stick to our recommendations to avoid getting into trouble, and DO NOT change our `f_security()` function when using it. Use `false` as the function's last argument and refrain from using your script at smaller timeframes than the chart's. To call our function to fetch a non-repainting value of close from the 1D timeframe, use: f_security(_sym, _res, _src, _rep) => security(_sym, _res, _src ) previousDayClose = f_security(syminfo.tickerid, "D", close, false) If that's all you're interested in, you are done. If you choose to ignore our recommendation and use the function in repainting mode by changing the `false` in there for `true`, we sincerely hope you read the rest of our ramblings before you do so, to understand the consequences of your choice. Let's now have a look at what security() is showing you. There is a lot to cover, so buckle up! But before we dig in, one last thing. What is a chart? A chart is a graphic representation of events that occur in markets. As any representation, it is not reality, but rather a model of reality. As Scott Page eloquently states in The Model Thinker : "All models are wrong; many are useful". Having in mind that both chart bars and plots on our charts are imperfect and incomplete renderings of what actually occurred in realtime markets puts us coders in a place from where we can better understand the nature of, and the causes underlying the inevitable compromises necessary to build the data series our code uses, and print chart bars. Traders or coders complaining that charts do not reflect reality act like someone who would complain that the word "dog" is not a real dog. Let's recognize that we are dealing with models here, and try to understand them the best we can. Sure, models can be improved; TradingView is constantly improving the quality of the information displayed on charts, but charts nevertheless remain mere translations. Plots of data fetched through security() being modelized renderings of what occurs at higher timeframes, coders will build more useful and reliable tools for both themselves and traders if they endeavor to perfect their understanding of the abstractions they are working with. We hope this publication helps you in this pursuit. █  FEATURES This script's "Inputs" tab has four settings:  • Repaint : Determines whether the functions will use their repainting or non-repainting mode.   Note that the setting will not affect the behavior of the yellow plot, as it always repaints.  • Source : The source fetched by the security() calls.  • Timeframe : The timeframe used for the security() calls. If it is lower than the chart's timeframe, a warning appears.  • Show timeframe reminder : Displays a reminder of the timeframe after the last bar. █  THE CHART The chart shows two different pieces of information and we want to discuss other topics in this section, so we will be covering:  A — The type of chart bars we are looking at, indicated by the colored band at the top.  B — The plots resulting of calling security() with the close price in different ways.  C — Points of interest on the chart. A — Chart bars The colored band at the top shows the three types of bars that any chart on a live market will print. It is critical for coders to understand the important distinctions between each type of bar:  1 — Gray : Historical bars, which are bars that were already closed when the script was run on them.  2 — Red : Elapsed realtime bars, i.e., realtime bars that have run their course and closed.    The state of script calculations showing on those bars is that of the last time they were made, when the realtime bar closed.  3 — Green : The realtime bar. Only the rightmost bar on the chart can be the realtime bar at any given time, and only when the chart's market is active. Refer to the Pine User Manual's Execution model page for a more detailed explanation of these types of bars. B — Plots The chart shows the result of letting our 5sec chart run for a few minutes with the following settings: "Repaint" = "On" (the default is "Off"), "Source" = `close` and "Timeframe" = 1min. The five lines plotted are the following. They have progressively thinner widths:  1 — Yellow : A normal, repainting security() call.  2 — Silver : Our recommended security() function.  3 — Fuchsia : Our recommended way of achieving the same result as our security() function, for cases when the source used is a function returning a tuple.  4 — White : The method we previously recommended in our MTF Selection Framework , which uses two distinct security() calls.  5 — Black : A lame attempt at fooling traders that MUST be avoided. All lines except the first one in yellow will vary depending on the "Repaint" setting in the script's inputs. The first plot does not change because, contrary to all other plots, it contains no conditional code to adapt to repainting/no-repainting modes; it is a simple security() call showing its default behavior. C — Points of interest on the chart Historical bars do not show actual repainting behavior To appreciate what a repainting security()  call will plot in realtime, one must look at the realtime bar and at elapsed realtime bars, the bars where the top line is green or red on the chart at the top of this page. There you can see how the plots go up and down, following the close value of each successive chart bar making up a single bar of the higher timeframe. You would see the same behavior in "Replay" mode. In the realtime bar, the movement of repainting plots will vary with the source you are fetching: open will not move after a new timeframe opens, low and high will change when a new low or high are found, close will follow the last feed update. If you are fetching a value calculated by a function, it may also change on each update. Now notice how different the plots are on historical bars. There, the plot shows the close of the previously completed timeframe for the whole duration of the current timeframe, until on its last bar the price updates to the current timeframe's close when it is confirmed (if the timeframe's last bar is missing, the plot will only update on the next timeframe's first bar). That last bar is the only one showing where the plot would end if that timeframe's bars had elapsed in realtime. If one doesn't understand this, one cannot properly visualize how his script will calculate in realtime when using repainting. Additionally, as published scripts typically show charts where the script has only run on historical bars, they are, in fact, misleading traders who will naturally assume the script will behave the same way on realtime bars. Non-repainting plots are more accurate on historical bars Now consider this chart, where we are using the same settings as on the chart used to publish this script, except that we have turned "Repainting" off this time: The yellow line here is our reference, repainting line, so although repainting is turned off, it is still repainting, as expected. Because repainting is now off, however, plots on historical bars show the previous timeframe's close until the first bar of a new timeframe, at which point the plot updates. This correctly reflects the behavior of the script in the realtime bar, where because we are offsetting the series by one, we are always showing the previously calculated—and thus confirmed—higher timeframe value. This means that in realtime, we will only get the previous timeframe's values one bar after the timeframe's last bar has elapsed, at the open of the first bar of a new timeframe. Historical and elapsed realtime bars will not actually show this nuance because they reflect the state of calculations made on their close , but we can see the plot update on that bar nonetheless. ► This more accurate representation on historical bars of what will happen in the realtime bar is one of the two key reasons why using non-repainting data is preferable.    The other is that in realtime, your script will be using more reliable data and behave more consistently. Misleading plots Valiant attempts by coders to show non-repainting, higher timeframe data updating earlier than on our chart are futile. If updates occur one bar earlier because coders use the repainting version of the function, then so be it, but they must then also accept that their historical bars are not displaying information that is as accurate. Not informing script users of this is to mislead them. Coders should also be aware that if they choose to use repainting data in realtime, they are sacrificing reliability to speed and may be running a strategy that behaves very differently from the one they backtested, thus invalidating their tests. When, however, coders make what are supposed to be non-repainting plots plot artificially early on historical bars, as in examples "c4" and "c5" of our script, they would want us to believe they have achieved the miracle of time travel. Our understanding of the current state of science dictates that for now, this is impossible. Using such techniques in scripts is plainly misleading, and public scripts using them will be moderated. We are coding trading tools here—not video games. Elementary ethics prescribe that we should not mislead traders, even if it means not being able to show sexy plots. As the great Feynman said: You should not fool the layman when you're talking as a scientist. You can readily appreciate the fantasy plot of "c4", the thinnest line in black, by comparing its supposedly non-repainting behavior between historical bars and realtime bars. After updating—by miracle—as early as the wide yellow line that is repainting, it suddenly moves in a more realistic place when the script is running in realtime, in synch with our non-repainting lines. The "c5" version does not plot on the chart, but it displays in the Data Window. It is even worse than "c4" in that it also updates magically early on historical bars, but goes on to evaluate like the repainting yellow line in realtime, except one bar late. Data Window The Data Window shows the values of the chart's plots, then the values of both the inside and outside offsets used in our calculations, so you can see them change bar by bar. Notice their differences between historical and elapsed realtime bars, and the realtime bar itself. If you do not know about the Data Window, have a look at this essential tool for Pine coders in the Pine User Manual's page on Debugging . The conditional expressions used to calculate the offsets may seem tortuous but their objective is quite simple. When repainting is on, we use this form, so with no offset on all bars: security(ticker, i_timeframe, i_source ) // which is equivalent to: security(ticker, i_timeframe, i_source) When repainting is off, we use two different and inverted offsets on historical bars and the realtime bar: // Historical bars: security(ticker, i_timeframe, i_source ) // Realtime bar (and thus, elapsed realtime bars): security(ticker, i_timeframe, i_source ) The offsets in the first line show how we prevent repainting on historical bars without the need for the `lookahead` parameter. We use the value of the function call on the chart's previous bar. Since values between the repainting and non-repainting versions only differ on the timeframe's last bar, we can use the previous value so that the update only occurs on the timeframe's first bar, as it will in realtime when not repainting. In the realtime bar, we use the second call, where the offsets are inverted. This is because if we used the first call in realtime, we would be fetching the value of the repainting function on the previous bar, so the close of the last bar. What we want, instead, is the data from the previous, higher timeframe bar , which has elapsed and is confirmed, and thus will not change throughout realtime bars, except on the first constituent chart bar belonging to a new higher timeframe. After the offsets, the Data Window shows values for the `barstate.*` variables we use in our calculations. █  NOTES Why are we revisiting security()  ? For four reasons:  1 — We were seeing coders misuse our `f_secureSecurity()` function presented in How to avoid repainting when using security() .    Some novice coders were modifying the offset used with the history-referencing operator in the function, making it zero instead of one,    which to our horror, caused look-ahead bias when used with `lookahead = barmerge.lookahead_on`.    We wanted to present a safer function which avoids introducing the dreaded "lookahead" in the scripts of unsuspecting coders.  2 — The popularity of security() in screener-type scripts where coders need to use the full 40 calls allowed per script made us want to propose    a solid method of allowing coders to offer a repainting/no-repainting choice to their script users with only one security() call.  3 — We wanted to explain why some alternatives we see circulating are inadequate and produce misleading behavior.  4 — Our previous publication on security() focused on how to avoid repainting, yet many other considerations worthy of attention are not related to repainting. Handling tuples When sending function calls that return tuples with security() , our `f_security()` function will not work because Pine does not allow us to use the history-referencing operator with tuple return values. The solution is to integrate the inside offset to your function's arguments, use it to offset the results the function is returning, and then add the outside offset in a reassignment of the tuple variables, after security() returns its values to the script, as we do in our "c2" example. Does it repaint? We're pretty sure Wilder was not asked very often if RSI repainted. Why? Because it wasn't in fashion—and largely unnecessary—to ask that sort of question in the 80's. Many traders back then used daily charts only, and indicator values were calculated at the day's close, so everybody knew what they were getting. Additionally, indicator values were calculated by generally reputable outfits or traders themselves, so data was pretty reliable. Today, almost anybody can write a simple indicator, and the programming languages used to write them are complex enough for some coders lacking the caution, know-how or ethics of the best professional coders, to get in over their heads and produce code that does not work the way they think it does. As we hope to have clearly demonstrated, traders do have legitimate cause to ask if MTF scripts repaint or not when authors do not specify it in their script's description. ► We recommend that authors always use our `f_security()` with `false` as the last argument to avoid repainting when fetching data dependent on OHLCV information. This is the only way to obtain reliable HTF data. If you want to offer users a choice, make non-repainting mode the default, so that if users choose repainting, it will be their responsibility. Non-repainting security() calls are also the only way for scripts to show historical behavior that matches the script's realtime behavior, so you are not misleading traders. Additionally, non-repainting HTF data is the only way that non-repainting alerts can be configured on MTF scripts, as users of MTF scripts cannot prevent their alerts from repainting by simply configuring them to trigger on the bar's close. Data feeds A chart at one timeframe is made up of multiple feeds that mesh seamlessly to form one chart. Historical bars can use one feed, and the realtime bar another, which brokers/exchanges can sometimes update retroactively so that elapsed realtime bars will reappear with very slight modifications when the browser's tab is refreshed. Intraday and daily chart prices also very often originate from different feeds supplied by brokers/exchanges. That is why security() calls at higher timeframes may be using a completely different feed than the chart, and explains why the daily high value, for example, can vary between timeframes. Volume information can also vary considerably between intraday and daily feeds in markets like stocks, because more volume information becomes available at the end of day. It is thus expected behavior—and not a bug—to see data variations between timeframes. Another point to keep in mind concerning feeds it that when you are using a repainting security() plot in realtime, you will sometimes see discrepancies between its plot and the realtime bars. An artefact revealing these inconsistencies can be seen when security() plots sometimes skip a realtime chart bar during periods of high market activity. This occurs because of races between the chart and the security() feeds, which are being monitored by independent, concurrent processes. A blue arrow on the chart indicates such an occurrence. This is another cause of repainting, where realtime bar-building logic can produce different outcomes on one closing price. It is also another argument supporting our recommendation to use non-repainting data. Alternatives There is an alternative to using security() in some conditions. If all you need are OHLC prices of a higher timeframe, you can use a technique like the one Duyck demonstrates in his security free MTF example - JD script. It has the great advantage of displaying actual repainting values on historical bars, which mimic the code's behavior in the realtime bar—or at least on elapsed realtime bars, contrary to a repainting security() plot. It has the disadvantage of using the current chart's TF data feed prices, whereas higher timeframe data feeds may contain different and more reliable prices when they are compiled at the end of the day. In its current state, it also does not allow for a repainting/no-repainting choice. When `lookahead` is useful When retrieving non-price data, or in special cases, for experiments, it can be useful to use `lookahead`. One example is our Backtesting on Non-Standard Charts: Caution! script where we are fetching prices of standard chart bars from non-standard charts. Warning users Normal use of security() dictates that it only be used at timeframes equal to or higher than the chart's. To prevent users from inadvertently using your script in contexts where it will not produce expected behavior, it is good practice to warn them when their chart is on a higher timeframe than the one in the script's "Timeframe" field. Our `f_tfReminderAndErrorCheck()` function in this script does that. It can also print a reminder of the higher timeframe. It uses one security() call. Intrabar timeframes security() is not supported by TradingView when used with timeframes lower than the chart's. While it is still possible to use security() at intrabar timeframes, it then behaves differently. If no care is taken to send a function specifically written to handle the successive intrabars, security() will return the value of the last intrabar in the chart's timeframe, so the last 1H bar in the current 1D bar, if called at "60" from a "D" chart timeframe. If you are an advanced coder, see our FAQ entry on the techniques involved in processing intrabar timeframes. Using intrabar timeframes comes with important limitations, which you must understand and explain to traders if you choose to make scripts using the technique available to others. Special care should also be taken to thoroughly test this type of script. Novice coders should refrain from getting involved in this. █  TERMINOLOGY Timeframe Timeframe , interval and resolution are all being used to name the concept of timeframe. We have, in the past, used "timeframe" and "resolution" more or less interchangeably. Recently, members from the Pine and PineCoders team have decided to settle on "timeframe", so from hereon we will be sticking to that term. Multi-timeframe (MTF) Some coders use "multi-timeframe" or "MTF" to name what are in fact "multi-period" calculations, as when they use MAs of progressively longer periods. We consider that a misleading use of "multi-timeframe", which should be reserved for code using calculations actually made from another timeframe's context and using security() , safe for scripts like Duyck's one mentioned earlier, or TradingView's Relative  Volume  at  Time , which use a user-selected timeframe as an anchor to reset calculations. Calculations made at the chart's timeframe by varying the period of MAs or other rolling window calculations should be called "multi-period", and "MTF-anchored" could be used for scripts that reset calculations on timeframe boundaries. Colophon Our script was written using the PineCoders Coding Conventions for Pine . The description was formatted using the techniques explained in the How We Write and Format Script Descriptions PineCoders publication. Snippets were lifted from our MTF Selection Framework , then massaged to create the `f_tfReminderAndErrorCheck()` function. █  THANKS Thanks to apozdnyakov for his help with the innards of security() . Thanks to bmistiaen for proofreading our description. Look first. Then leap.
Pine Script® göstergesi
PineCoders tarafından
60