`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.
Tìm kiếm tập lệnh với "文华财经tick价格"
Bull Call Spread Entry StrategyThis strategy script uses the "Spread Entry Strength" overlay indicator script I designed to show entry timing optimized for an Option Bull
Call Spread.
As for this strategy...
The defaults for the strategy itself are as follows:
Period for strategy: 1/1/18 to 12/1/2021. This can be changed to a different period using the settings.
Condition for entry:
Bull Spread Entry Strength >= "Overlay Signal Strength Level"
Limit entry is used, price must be <= close when signaled
Entry occurs by next day or the order is cancelled
Condition for exit (uses a timed exit):
Bars passed since order entry >= 30 (6 weeks..~42 calendar days)
Thursday (day before "option" expiration date... assuming weekly options exist)
All of the user settings from the overlay are pulled into this for customization purposes. Details of the actual Spread Entry Strength overlay are as follows (copied from my shared indicator):
2 background shadings will occur:
The background will shade blue if the ticker is prime for a Bullish Call spread.
The background will shade purple if the the ticker is prime for a Bearish Put spread.
In theory, if the SE Strength is at one of the extremes of the Bear or Bull side, then a spread is prime for entry.
To calculate this, 8 conditions receive a 1 or zero dependent on whether the condition is true (1) or false (0), and then all of those are summed. The primary gist of the strength comes from Nishant's book, or my interpretation thereof, with some additives that limits what I need to review (such as condition 8 below.)
The 8 Bull Conditions are:
1) Bollinger Bands are outside of the Keltner Channels
2) ADX is trending up
3) RSI is trending up
4) -DI is trending down
5) RSI is under 30
6) Price is below the lower Keltner Channel
7) Price is between the lower Bollinger Band and the Bollinger basis.
8) Price at one point within the last 5 bars was below the lower Bollinger Band
The 8 Bear Conditions are the inverse conditions (except the first):
1) Bollinger Bands are outside of the Keltner Channels
2) ADX is trending down
3) RSI is trending down
4) +DI is trending up
5) RSI is over 70
6) Price is above the upper Keltner Channel
7) Price is between the upper Bollinger Band and the Bollinger basis.
8) Price at one point within the last 5 bars was above the upper Bollinger Band
There is a "market noise" filter that will filter out shading when another market move is considered, i.e. if you don't want to see the potential trade when QQQ moves more than 1% then do the following in the settings:
Check "Market Filter"
Enter QQQ in the "Market Ticker To Use"
Enter 1 in the "Market Too Hot Level"
Press Ok
Obviously, the same holds true for the "Market Too Cool Filter."
Second release notes:
Overlay Signal Strength Level - You can set your own "level" for the overlay in the settings, instead of having to change the script code itself. I have the default set to 6. A lower number shows more overlays, a higher number shows fewer (i.e. more conditions have been met.).
Provide Narrative (Troubleshooting) - Narrative label created with several outputs that will show after the last bar. This narrative needs to be turned on in the settings, as the default is "off" ... unchecked.
Remove Strength Indicator When Squeezed - when checked no overlays will be produced regardless of "scoring." Default is off.
Show Squeezes (Will Override Indicator When Concurrent) - overlays an orange background when the ticker is in a squeeze. I am still working on the accuracy here, but it's usable. This will override the strength indicator as well. This needs to be turned on, if you want it.
Short SMA Period - period used to calculate the short SMA, used in the narrative only, at this point in time.
Medium SMA Period - period used to calculate the medium SMA, used in the narrative only, at this point in time.
Long SMA Period - period used to calculate the medium SMA, used in the narrative only, at this point in time.
Outside of the settings... a few calculation adjustments here and there have occurred and some color shading adjustments to allow for the adjustable level setting.
Examples of Rolling Average Using Automated AnchoringIn this study, I present a method to expose NaN values to development environment.
This exposure allows NaN values to be used by methods in scripts.
I also show how to use values, even NaN values, as anchors from which statistics can be computed from.
I demonstrate how to do this with constants and variables in methods for computing the cumulative/rolling average of a series.
I also show how to calculate the cumulative/rolling average from the start of a ticker series using the aforementioned methods.
Each method has a description on how some of their parts work as well as their constraints.
Method #1 - Can only be used for computing the rolling average on the ticker series.
Method #2 - The simple moving average from the Pine Script reference.
- Can be used to calculate the rolling average of the ticker series and number values of a series.
- This method seems to cause an error when there are many bars in the series.
Method #3 - The most versatile method due to the use of computing the rolling average using an array.
- Timeout will occur when computing the rolling average of an entire ticker series which is long.
- Timeout has not occurred when computing a rolling average of a series from NaN or non-NaN anchor points even when the series is long.
This is an attempt to get around the constraints of the built-in sma(source, length) function in which length cannot be dynamically adjusted.
Other Pine Script functions have that constraint which we can get around by defining our own functions.
Spread Entry StrengthThis is an overlay indicator showing a strong potential for entry into an option spread trade.
2 background shadings will occur:
The background will shade blue if the ticker is prime for a Bullish Call spread.
The background will shade purple if the the ticker is prime for a Bearish Put spread.
In theory, if the SE Strength is at one of the extremes of the Bear or Bull side, then a spread is prime for entry.
To calculate this, 8 conditions receive a 1 or zero dependent on whether the condition is true (1) or false (0), and then all of those are summed. The primary gist of the strength comes from Nishant's book, or my interpretation thereof, with some additives that limits what I need to review (such as condition 8 below.)
The 8 Bull Conditions are:
1) Bollinger Bands are outside of the Keltner Channels
2) ADX is trending up
3) RSI is trending up
4) -DI is trending down
5) RSI is under 30
6) Price is below the lower Keltner Channel
7) Price is between the lower Bollinger Band and the Bollinger basis.
8) Price at one point within the last 5 bars was below the lower Bollinger Band
The 8 Bear Conditions are the inverse conditions (except the first):
1) Bollinger Bands are outside of the Keltner Channels
2) ADX is trending down
3) RSI is trending down
4) +DI is trending up
5) RSI is over 70
6) Price is above the upper Keltner Channel
7) Price is between the upper Bollinger Band and the Bollinger basis.
8) Price at one point within the last 5 bars was above the upper Bollinger Band
There is a "market noise" filter that will filter out shading when another market move is considered, i.e. if you don't want to see the potential trade when QQQ moves more than 1% then do the following in the settings:
Check "Market Filter"
Enter QQQ in the "Market Ticker To Use"
Enter 1 in the "Market Too Hot Level"
Press Ok
Obviously, the same holds true for the "Market Too Cool Filter."
Arbitrage BR STOCK / USA STOCKThis Indicator was made to show the BRL difference between an Stock in Brazil's B3 and it's respective ADR traded in the USA.
By default, it will show the spread between PETR4 and it's ADR PBR.A using the USD-BRL pair from Forex.
You can personalize this indicator to any Stock of your preference, and also change to any USD-BRL pair negotiated that you want. You'll have the following options to do so:
B3's Stock Ticker -> Ticker negotiated at B3.
USA's Stock Ticker -> The respective ADR of the first option.
ADR's Multiplicative Factor -> How many B3's Stocks are equivallent to the USA Stock (found at the name of the ADR on Trade View).
BRL/USD Market of Preference -> Which market you want to use to transform the price of the ADR from USD to BRL.
Dollar Divisor -> The BRL must be equivallent to 1 Dollar for the script to work. So, if you want to use a USD/BRL market that does not represent this relation, you must divide it by some number to do so. For example, if you want to use B3's DOLFUT, than you must set this parameter to 1000 (because the points show at B3's DOLFUT are the amount of BRL equivallent to 1000 Dollars). Also, if you are using a market that trades Dollar equivalent to 1 BRL (Globex's 6LFUT, for example), then set this parameter to 0.
Timeframe -> Recommended to be the same of the chart to better visualisation.
Data structure map[string, float]The script shows a workaround for map in pine-script via drawings.
There are few restrictions with them:
1. The size of the map cannot be more that amount of allowed drawings (about 40 by now)
2. Because the map shares the space of drawings throughout the whole script, using drawings with the map must be careful, with handly creating and removing of each drawing, because otherwise pine's garbage collector might break the stack. I'd recommend not using more drawings with the map.
3. setters and getters must be called on every bar, because of implementation of functions in pine there are inner serieses, which must be updated on every bar. So wherever you have a setter or getter in the code - it must be called on every bar. But if it's just an update, then you should pass 'false' as a param of the funtion.
The script shows a way to work with the map: filling it with some tickers and values for each of it and then plot the value if the symbol on the chart equals to one of the tickers in the map.
And there are some examples of updating of the value and removing of the item from the map.
Elder ray ( Bull power and bear power combined )Elder-ray is an indicator named for its similarity to x-rays.
It shows the structure of bullish and bearish
power below the surface of the markets. Elder-ray combines a trend-
following moving average with two oscillators to show when to enter
and exit long or short positions.
A moving average reflects the average consensus of value. The high of
each bar reflects the maximum power of bulls during that bar. The low of
each bar marks the maximum power of bears during that bar.
Elder-ray works by comparing the power of bulls and bears during each
bar with the average consensus of value. Bull Power reflects the maximum
power of bulls relative to the average consensus, and Bear Power the max-
imum power of bears relative to that consensus.
When the high of a bar is above the EMA, Bull Power is positive. When
the entire bar sinks below the EMA, which happens during severe de-
clines, Bull Power becomes negative. When the low of a bar is below the
EMA, Bear Power is negative. When the entire bar rises above the EMA,
which happens during wild rallies, Bear Power becomes positive.
The slope of a moving average identifies the current trend of the mar-
ket. When it rises, it shows that the crowd is becoming more bullish; it is
a good time to be long. When it falls, it shows that the crowd is becoming
more bearish; it is a good time to be short. Prices keep getting away from
a moving average but snap back to it, as if pulled by a rubber band. Bull
Power and Bear Power show the length of that rubber band. Knowing the
“Buy low, sell high” sounds good, but traders and investors seem to have
been more comfortable buying Lucent above 70 than below 7. Perhaps they
are not as rational as the efficient market theorists would like us to believe?
Elder-ray gives rational traders a glimpse into what is going on below the sur-
face of the market.
When the trend, identified by the 22-day EMA, is down and bulls are
under water, the rallies back to the surface mark shorting opportunities
normal height of Bull or Bear Power reveals how far prices are likely to get
away from their moving average before returning. Elder-ray offers one of
the best insights into where to take profits—at a distance away from the
moving average that equals the average Bull Power or Bear Power.
Elder-ray gives buy signals in uptrends when Bear Power turns nega-
tive and then ticks up. A negative Bear Power means that the bar is strad-
dling the EMA, with its low below the average consensus of value. Waiting
for Bear Power to turn negative forces you to buy value rather than chase
runaway moves. The actual buy signal is given by an uptick of Bear Power,
which shows that bears are starting to lose their grip and the uptrend is
about to resume. Take profits at the upper channel line or when a trend-
following indicator stops rising. Profits may be greater if you ride the
uptrend to its conclusion, but taking profits at the upper channel line is
more reliable.
Elder-ray gives shorting signals in downtrends when Bull Power turns
positive and then ticks down. We can identify the downtrend by a declin-
ing daily or weekly EMA. A positive Bull Power shows that the bar is strad-
dling the EMA, with its high above the average consensus of value.
Waiting for Bull Power to turn positive before shorting forces you to sell
at or above value instead of chasing waterfall declines. The actual short-
ing signal is given by a downtick of Bull Power, which shows that bulls
are starting to slip and the downtrend is about to resume. Once short, take
profits at the lower channel line or when the trend-following indicator
stops falling, depending on your style.
FREE TRADINGVIEW FOR TIMEFRAMESWhen doing i.e the 3 minute timeframe turn on the closest timeframe available for you or the candles and wicks will be fucked up.
So if you're doing the 5 hour timeframe candles turn on the 4hr chart on your main chart.
To View the candles in full screen double click the windows with the candlesticks
If you don't have TradingView premium and want to look at custom timeframes you can use this.
For the ticker/coin/pair you want to show enter it like this:
For stocks, only the ticker i.e: MSFT, APPL
For Crypto, "Exchange:ticker" i.e: BITFINEX:BTCUSD, BINANCE:AGIBTC, BITMEX:ADAM19
When setting up the timeframe write i.e:
For minutes/hourly: 5, 240 (4 hour), 360 (6 hour)
For daily/weekly/monthly: 1D, 2W, 3M
When doing i.e the 3 minute timeframe turn on the closest timeframe available for you or the candles and wicks will be fucked up.
So if you're doing the 5 hour timeframe candles turn on the 4hr chart on your main chart.
RSI MTF by PeterOThis is my take on reaching Higher TimeFrame charts, what is usually helpful when determining the trend. On the example of RSI.
So imagine you want to check RSI from higher timeframe. 15x higher for example. There are 3 ways to do it.
1. security(tickerid,"15",rsi(close,14))
DON'T!!! I strongly advise against this method. Security() function is buggy in PineScript, leads to so-called "repainting" issues. Repainting is caused by creating leak from future data and leads to abnormally fantastic strategy backtest results like the one in Open Close Cross Strategy. Theoretically speaking if security() used correctly - with Pine version3 and barmerge.lookahead_off - you should encounter no repainting, but I could swear I saw scripts repaint even with security() implemented properly.
Even assuming security() implemented correctly will not repaint - it will create delay in your script. I'm using "15" multiplier in my example, and this means, I have to wait for 15 candles to close to produce indicators value. If a strong move happens in the meantime, I'm blind, because I have to wait anyway.
So for your own security, stay away from security() at all times.
2. rsi(close,14*15)
This will produce RSI plot with no delay, but a very flattened one. RSI will move between 45 and 45, never even reaching 30 or 70 levels. So pretty useless.
3. Dig-in-the-formula way.
Doing a bit more math produces RSI line, which is not delayed, not repainting and moving in full 0-100 RSI range. Actually - looking almost identical to the one from the higher timeframe. Which was the goal of this script.
Godmode 4.0.2 [Supply/Demand]First off, a huge thank you to the following people:
LEGION:
LazyBear: www.tradingview.com
xSilas: www.tradingview.com
Ni6HTH4awK: www.tradingview.com
sco77m4r7and:
SNOW_CITY: www.tradingview.com
oh92: www.tradingview.com
alexgrover: www.tradingview.com
cI8DH: www.tradingview.com
DonovanWall: www.tradingview.com
shtcoinr: www.tradingview.com
This is the third iteration of Godmode. This time I borrowed the method used by shtcoinr to render supply/demand, resistance and support zones. The idea here is to input the appropriate benchmark tickerid to the asset class you're trading and to paint zones according to the price activity of the selected tickerid. This works very well trying to paint meaningful zones against noisy stocks, currencies, commodities etc. Use a correlation coefficient to determine the best benchmark for your asset class.
Want to Learn?
If you'd like the opportunity to learn Pine but you have difficulty finding resources to guide you, take a look at this rudimentary list: docs.google.com
The list will be updated in the future as more people share the resources that have helped, or continue to help, them. Follow me on Twitter to keep up-to-date with the growing list of resources.
Suggestions or Questions?
Don't even kinda hesitate to forward them to me. My (metaphorical) door is always open.
Heikin Ashi AlgorithmThis indicator can be added on any type of chart (including Heikin Ashi chart). There is a little trick with the tickerid, read details in comments.
Relative Estimated Price REP by KIVANÇ fr3762Relative Estimated Price (REP) Indicator shows the estimated price calculated if the tickerid made the same value changes (in %) during a certain period.
The default value of the lookback period is 50.
In the given XRPUSD chart you can see that XRPUSD has a value of 0.26480 and the RPC indicator shows the value of 0.38099.
This means that XRP would be 0.38099USD if it was fully made the same percentage moves with BTC , we can say that XRP is RELATIVELY cheap according to BTC price moves.
Conversely XRP would be RELATIVELY expensive if the last value of REP was lower then current XRP price.
users can choose the relative base price in calculation of REP between 1-5 which are:
1=BTCUSD, 2=ETHUSD, 3=EURTRY(Euro/Turkish Lira), 4=USDTRY (Dollar/Turkish Lira), 5=BIST100 (Istanbul Stock Exchange)
I personally advise you to use this indicator for daily charts in Tradingview to have more accurate estimated prices because of the website's calculation.
Developed by KIVANÇ
Mayer Multiple @ Current PriceThough this script is by me, the original idea comes from a podcast I heard where Trace Mayer talks about how he does crypto valuation. It is based on current price against the 200 day moving average. This indicator script will simply plot that value as a label overlayed on your trading view chart. Best long term results occur when acquiring BTC when the multiple is 2.4 or less. For more info, google "mayer multiple" This script/indicator is strictly for educational purposes. It is not exclusive to bitcoin.
To get the best look out of your charts I make the following changes.
1.Apply the indicator to your chart.
2. In the tools palette of trading view, when looking at a chart, click "Show Objects Tree" the icon displayed above the trash can.
In the objects tree panel, click the preferences icon for "Mayer Multiple @ Current Price"
Switch "scale" to "scale Left"
3. Then for your chart preferences (right click on chart background and select "Properties", and be sure the following are checked on the "Scales" tab
Left Axis
Right Axis
Indicator Last Value
Indicator Labels
Screenshots are not allowed in this view, so I can't post screenshots, but the view above is what it should look like when you are done.
For anyone who wants to see the code, here is the code of the script:
Use at will, and at your own risk.
//@version=3
// Created By Timothy Luce, inspired by Trace Mayer's 200 Day SMA cryptocurrency valuation method
study("Mayer Multiple @ Current Price", overlay=true)
currentPrice = close
currentDay = security(tickerid, "D", sma(close, 200))
mayerMultiple = currentPrice/currentDay
plot(mayerMultiple, color=#00ffaa, transp=100)
If you want to change the color, change this line: #00ffaa
Accumulation/Distribution Percentage (ADP) [Cyrus c|:D]Accumulation/Distribution Percentage ( ADP ) is used to measure money flow similar to Chaikin Money Flow ( CMF ) and Money Flow. It is the range-bound version of my previous indicator ADMF. This indicator can be used for analyzing momentum, buy/sell pressure, and overbought/oversold conditions. I believe that this indicator is more accurate than CMF and MFI (I will publish a TA about it one day!).
What to look for:
- When this indicator moves up, it means buy pressure is increasing and the other way around for sell pressure. Crossing 0 means that trend has changed in the given period (it is best to look for confirmation of buy/sell pressure in larger TFs)
- Overbought above 40 and oversold below -40 (these numbers vary depending on the security. Look for historical levels to determine overbought and oversold conditions of each security)
- Regular divergence shows that momentum of a trend is declining. Hidden divergence implies continuation of a trend. The non-bound mode should be more accurate for identifying divergence.
- Failure swings can detect potential reversals.
Please read Relative Strength Index and Money Flow for more information and similar disclaimers.
Recommendations:
- hlc3 (AKA typical price) as input source might be better than "close" as it captures more information. If you use hlc3 as a source, then change the chart type to line and set hlc3 as the source for identifying divergence.
- Use hybrid tickers e.g.(BITFINEX:BTCUSD+COINBASE:BTCUSD+BITSTAMP:BTCUSD)/3. Volume-based indicators are susceptible to wash trading/volume printing and hybrid tickers mitigate this issue.
- In non-bound mode, small TFs with longer length should be more accurate than larger TFs with standard length (same is true for many other indicators)
Background:
I have developed 4 indicators based on a simple but elegant concept of A/D ratio. A/D ratio is equal to (current close - previous close)/True Range (when there are no price gaps, True Range = High - Low)
1) What you see on ADV indicator as darker green and red is equal to A/D ratio x volume.
2) ADL indicator shows the summation of ADV
3) ADMF (or ADP in non-bound mode) shows Moving Average of ADV
4) ADP shows relative accumulation strength which is calculated as RMA (accumulations)/RMA(accumulation + distribution). ADP equation is based on RSI equation which is RMA(gains)/RMA(gains + losses). That is why these two indicators look quite similar.
PS: Please leave a like if you find these indicators useful. I am working on improvements on these and other indicators. I am trying my best to keep them as simple as possible. Please let me know in the comments if you want me to make future indicators even simpler.
--------
Complementary indicators based on the same concept:
ADL: a replacement for Chaikin's Accum/Dist, On Balance Volume, and Price Volume Trend
ADV: a replacement for regular volume indicator
ADP also has a scaled RSI and ADMF built in (ie ADMF is obsolete).
CMYK XIAM OPEN◊ Introduction
This is project XIAM, a work in progress.
Recently i came across the repainting problem.
Since then i haven't seen any bot-code that makes > 5% profit in two weeks with 0.25% fees/trade.
People who make good bots either bluff or don't share the code.
they let you rent it.
I aim to understand, learn it, write it myself. And share my findings with whoever shares with me.
◊ Origin
Based on RMI (RSI with momentum) and SMA, and values derived from those.
◊ Usage
Currently an investigative script.
◊ Theoretical Approaches
Philosophy α :: Cleansignal
:: Cleaning up the signal, from irregularities that cause unpredictable results.
Merging available tickers of a pair into one.
Merging available tickers of different coins into one in the correct proportion. (eg. Crypto market cap)
Removing Jitter, and smoothing signal without delay.
Philosophy β :: Rythmic
:: Syncing into the rythm's, to never miss the que, and trade on every theoretical low/high
Searching Amplitude, Period, Phase Shift, Frequency's of the carrier waves.
Marking Acrivity/inactivity of the carrier waves.
Partial Fractal repetition asses-able with above data?
Philosophy γ :: consequential
:: Seeking for Indicatory events and causal relations
Probability / reward.
Confirmation and culmination.
...
◊ Community
Wanna share your findings ? or need help resolving a problem ?
CMYK :: discord.gg
AUTOTVIEW :: discordapp.com
BTC CorrelationA simple script to display how correlated the current ticker is to Bitcoin.
Inputs are the number of bars to check correlation for (default 10) and the the ticker to use for BTC comparison (default is BITFINEX:BTCUSD)
Values of 1 are highly correlated (i.e. bitcoin moves up, so does your current ticker), values of -1 are inversely correlated (i.e. bitcoin moves up, your current ticker moves down).
See: www.babypips.com for some more details on correlation
Price relation viewer - add percent change of two symbols (BETA)This script is very much beta!
This is a simple script to visualize how two symbols move in relation to each other. For example if the underlying symbol is a 2x Gold ETF (meaning the ticker moves at 2x the spot price of gold---if gold goes up 3% this ticker should go up 6%) and the comparison symbol is an 2x inverse gold ETF (at gold up 3% this should move down 6%). If these ETFs were 100% accurate at tracking the price of gold then this tool would report a value of zero at all times.
Day 1
Ticker - $10
Comparison - $10
Day 2
Ticker - $12
Comp - $11
This tool value - |20%| + -|10%| = 10%
It uses a short simple moving average to smooth things out a bit (see inputs). It is important to keep your axis scale in mind when using this! Two symbols that are always near zero mean they are offsetting each other very well but the value displayed might range from 0 to 0.005, but the graphed area can make it look extreme if autoscaled.
This is a tool with very specific uses : comparing how one digital currency moves in relation to bitcoin's price, comparing how gold moves in relation to silver, etc.
Multi-Timeframe VWAPShows the Daily, Weekly, Monthly, Quarterly, and Yearly VWAP.
Also shows the previous closing VWAP, which is usually very near the HLC3 standard pivot for the previous time frame. i.e. The previous daily VWAP closing price is usually near the current Daily Pivot. Tickers interact well with the previous Daily and Weekly closing VWAP.
Enabling the STDEV bands shows 3 separate standard deviation levels, defaulted at 1, 2, and 3. The lookback period for the bands is always changing with each new bar, since the standard deviation is calculated from the current bar to the beginning of the period. This is different from bollinger bands, as the lookback is constant (usually 20 periods is the textbook default).
The STDEV bands interval of interest can be changed from Day (D), Week (W), Month (M), Quarter (Q), Year (Y).
Tickers tend to bounce very well on Daily, Weekly, and Yearly VWAP (Yes... Year). Use this code and observe the Year VWAP on several major symbols through the past few years and eyes will be opened.
Free Strategy #08 (Combo of #01 and #02) (ES / SPY)This strategy was designed to be traded on daily data on the ES and SPY—the strategy was originally developed for NinjaTrader, which displays daily ES data based on RTH hours instead of 24 hours (1440 minute) like TradingView does, so we are presenting the results on the SPY until we figure out how to overcome this hurdle.
The strategy combines the two ideas from strategy #01 and strategy #02 .
Strategy #08
Quantity 100
Slippage: 2 ticks
Commission: 4.95 per order
Net Profit: 26,044.60
Max Drawdown: 3,947.60
Buy and Hold (Custom)
Quantity 100
Slippage: 2 ticks
Commission: 4.95 per order
Entry Long: 1993-02-01 @ 43.99
Exit Long: 2017-07-28 @ 246.34
Net Profit: 20,225.10
Max Drawdown: 9,042.00
Free Strategy #02 (ES / SPY)This strategy was designed to be traded on daily data on the ES and SPY—the strategy was originally developed for NinjaTrader, which displays daily ES data based on RTH hours instead of 24 hours (1440 minute) like TradingView does, so we are presenting the results on the SPY until we figure out how to overcome this hurdle.
Strategy #02
Quantity 100
Slippage: 2 ticks
Commission: 4.95 per order
Net Profit: 10,118.30
Max Drawdown: 4.037.60
Buy and Hold (Custom)
Quantity 100
Slippage: 2 ticks
Commission: 4.95 per order
Entry Long: 1993-02-01 @ 43.99
Exit Long: 2017-07-28 @ 246.34
Net Profit: 20,225.10
Max Drawdown: 9,042.00
True Strength Indicator MTFHere is an example of a script showing a multi-time frame of TSI.
Chart below compares FX EURUSD Daily TSI to 1H TSI
Here is an updated version
study("True Strength Indicator MTF", shorttitle="TSI MTF")
resCustom = input(title="Timeframe", type=resolution, defval="60" )
long = input(title="Long Length", type=integer, defval=25)
short = input(title="Short Length", type=integer, defval=13)
signal = input(title="Signal Length", type=integer, defval=13)
price = close
double_smooth(src, long, short) =>
fist_smooth = ema(src, long)
ema(fist_smooth, short)
pc = change(price)
double_smoothed_pc = double_smooth(pc, long, short)
double_smoothed_abs_pc = double_smooth(abs(pc), long, short)
tsi_value = 100 * (double_smoothed_pc / double_smoothed_abs_pc)
tsi = security(tickerid, resCustom,tsi_value)
plot(tsi, color=black)
plot(ema(tsi, signal), color=red)
hline(0, title="Zero")
Algo + Trendlines :: Medium PeriodThis indicator helps me to avoid overlooking Trendlines / Algolines. So far it doesn't search explicitly for Algolines (I don't consider volume at all), but it's definitely now already not horribly bad.
These are meant to be used on logarithmic charts btw! The lines would be displayed wrong on linear charts.
The biggest challenge is that there are some technical restrictions in TradingView, f. e. a script stops executing if a for-loop would take longer than 0.5 sec.
So in order to circumvent this and still be able to consider as many candles from the past as possible, I've created multiple versions for different purposes that I use like this:
Algo + Trendlines :: Medium Period : This script looks for "temporary highs / lows" (meaning the bar before and after has lower highs / lows) on the daily chart, connects them and shows the 5 ones that are the closest to the current price (=most relevant). This one is good to find trendlines more thoroughly, but only up to 4 years ago.
Algo + Trendlines :: Long Period : This version looks instead at the weekly charts for "temporary highs / lows" and finds out which days caused these highs / lows and connects them, Taking data from the weekly chart means fewer data points to check whether a trendline is broken, which allows to detect trendlines from up to 12 years ago! Therefore it misses some trendlines. Personally I prefer this one with "Only Confirmed" set to true to really show only the most relevant lines. This means at least 3 candle highs / lows touched the line. These are more likely stronger resistance / support lines compared to those that have been touched only twice.
Very important: sometimes you might see dotted lines that suddenly stop after a few months (after 100 bars to be precise). This indicates you need to zoom further out for TradingView to be able to load the full line. Unfortunately TradingView doesn't render lines if the starting point was too long ago, so this is my workaround. This is also the script's biggest advantage: showing you lines that you might have missed otherwise since the starting bars were outside of the screen, and required you to scroll f. e back to 2015..
One more thing to know:
Weak colored line = only 2 "collision" points with candle highs/lows (= not confirmed)
Usual colored line = 3+ "collision" points (= confirmed)
Make sure to move this indicator above the ticker in the Object Tree, so that it is drawn on top of the ticker's candles!
More infos: www.reddit.com
Algo + Trendlines :: Long PeriodThis indicator helps me to avoid overlooking Trendlines / Algolines. So far it doesn't search explicitly for Algolines (I don't consider volume at all), but it's definitely now already not horribly bad.
These are meant to be used on logarithmic charts btw! The lines would be displayed wrong on linear charts.
The biggest challenge is that there are some technical restrictions in TradingView, f. e. a script stops executing if a for-loop would take longer than 0.5 sec.
So in order to circumvent this and still be able to consider as many candles from the past as possible, I've created multiple versions for different purposes that I use like this:
Algo + Trendlines :: Medium Period : This script looks for "temporary highs / lows" (meaning the bar before and after has lower highs / lows) on the daily chart, connects them and shows the 5 ones that are the closest to the current price (=most relevant). This one is good to find trendlines more thoroughly, but only up to 4 years ago.
Algo + Trendlines :: Long Period : This version looks instead at the weekly charts for "temporary highs / lows" and finds out which days caused these highs / lows and connects them, Taking data from the weekly chart means fewer data points to check whether a trendline is broken, which allows to detect trendlines from up to 12 years ago! Therefore it misses some trendlines. Personally I prefer this one with "Only Confirmed" set to true to really show only the most relevant lines. This means at least 3 candle highs / lows touched the line. These are more likely stronger resistance / support lines compared to those that have been touched only twice.
Very important: sometimes you might see dotted lines that suddenly stop after a few months (after 100 bars to be precise). This indicates you need to zoom further out for TradingView to be able to load the full line. Unfortunately TradingView doesn't render lines if the starting point was too long ago, so this is my workaround. This is also the script's biggest advantage: showing you lines that you might have missed otherwise since the starting bars were outside of the screen, and required you to scroll f. e back to 2015..
One more thing to know:
Weak colored line = only 2 "collision" points with candle highs/lows (= not confirmed)
Usual colored line = 3+ "collision" points (= confirmed)
Make sure to move this indicator above the ticker in the Object Tree, so that it is drawn on top of the ticker's candles!
More infos: www.reddit.com