Começar

Indicadores e estratégias

Linear Correlation OscillatorYou don't need loops to get the rolling correlation between an input series and a linear sequence of values, this can be obtained from the normalized difference between a WMA and an SMA of the input series. The closed-form solutions for the moving average and standard deviation of a linear sequence can be easily calculated, while the same rolling statistics for the input series can be computed using cumulative sums. All these concepts were introduced in previous indicators posts long ago. This approach can allow to efficiently compute the rolling R-Squared of a linear regression, as well as its SSE. Using the rolling correlation as a trend indicator is often attributed to John Ehlers with the correlation trend indicator (Correlation As A Trend Indicator), but the applications of this precise method can be traced back quite a while ago by a wide variety of users, in fact, the LSMA can be computed using this precise indicator. You can see an example where the correlation oscillator appears below:
Indicador Pine Script™
por alexgrover
4
`security()` revisited [PineCoders]NOTE The non-repainting technique in this publication that relies on bar states is now deprecated, as we have identified inconsistencies that undermine its credibility as a universal solution. The outputs that use the technique are still available for reference in this publication. However, we do not endorse its usage. See this publication for more information about the current best practices for requesting HTF data and why they work. █  OVERVIEW This script presents a new function to help coders use security() in both repainting and non-repainting modes. We revisit this often misunderstood and misused function, and explain its behavior in different contexts, in the hope of dispelling some of the coder lure surrounding it. The function is incredibly powerful, yet misused, it can become a dangerous WMD and an instrument of deception, for both coders and traders. We will discuss:  • How to use our new `f_security()` function.  • The behavior of Pine code and security() on the three very different types of bars that make up any chart.  • Why what you see on a chart is a simulation, and should be taken with a grain of salt.  • Why we are presenting a new version of a function handling security() calls.  • Other topics of interest to coders using higher timeframe (HTF) data. █  WARNING We have tried to deliver a function that is simple to use and will, in non-repainting mode, produce reliable results for both experienced and novice coders. If you are a novice coder, stick to our recommendations to avoid getting into trouble, and DO NOT change our `f_security()` function when using it. Use `false` as the function's last argument and refrain from using your script at smaller timeframes than the chart's. To call our function to fetch a non-repainting value of close from the 1D timeframe, use: f_security(_sym, _res, _src, _rep) => security(_sym, _res, _src ) previousDayClose = f_security(syminfo.tickerid, "D", close, false) If that's all you're interested in, you are done. If you choose to ignore our recommendation and use the function in repainting mode by changing the `false` in there for `true`, we sincerely hope you read the rest of our ramblings before you do so, to understand the consequences of your choice. Let's now have a look at what security() is showing you. There is a lot to cover, so buckle up! But before we dig in, one last thing. What is a chart? A chart is a graphic representation of events that occur in markets. As any representation, it is not reality, but rather a model of reality. As Scott Page eloquently states in The Model Thinker : "All models are wrong; many are useful". Having in mind that both chart bars and plots on our charts are imperfect and incomplete renderings of what actually occurred in realtime markets puts us coders in a place from where we can better understand the nature of, and the causes underlying the inevitable compromises necessary to build the data series our code uses, and print chart bars. Traders or coders complaining that charts do not reflect reality act like someone who would complain that the word "dog" is not a real dog. Let's recognize that we are dealing with models here, and try to understand them the best we can. Sure, models can be improved; TradingView is constantly improving the quality of the information displayed on charts, but charts nevertheless remain mere translations. Plots of data fetched through security() being modelized renderings of what occurs at higher timeframes, coders will build more useful and reliable tools for both themselves and traders if they endeavor to perfect their understanding of the abstractions they are working with. We hope this publication helps you in this pursuit. █  FEATURES This script's "Inputs" tab has four settings:  • Repaint : Determines whether the functions will use their repainting or non-repainting mode.   Note that the setting will not affect the behavior of the yellow plot, as it always repaints.  • Source : The source fetched by the security() calls.  • Timeframe : The timeframe used for the security() calls. If it is lower than the chart's timeframe, a warning appears.  • Show timeframe reminder : Displays a reminder of the timeframe after the last bar. █  THE CHART The chart shows two different pieces of information and we want to discuss other topics in this section, so we will be covering:  A — The type of chart bars we are looking at, indicated by the colored band at the top.  B — The plots resulting of calling security() with the close price in different ways.  C — Points of interest on the chart. A — Chart bars The colored band at the top shows the three types of bars that any chart on a live market will print. It is critical for coders to understand the important distinctions between each type of bar:  1 — Gray : Historical bars, which are bars that were already closed when the script was run on them.  2 — Red : Elapsed realtime bars, i.e., realtime bars that have run their course and closed.    The state of script calculations showing on those bars is that of the last time they were made, when the realtime bar closed.  3 — Green : The realtime bar. Only the rightmost bar on the chart can be the realtime bar at any given time, and only when the chart's market is active. Refer to the Pine User Manual's Execution model page for a more detailed explanation of these types of bars. B — Plots The chart shows the result of letting our 5sec chart run for a few minutes with the following settings: "Repaint" = "On" (the default is "Off"), "Source" = `close` and "Timeframe" = 1min. The five lines plotted are the following. They have progressively thinner widths:  1 — Yellow : A normal, repainting security() call.  2 — Silver : Our recommended security() function.  3 — Fuchsia : Our recommended way of achieving the same result as our security() function, for cases when the source used is a function returning a tuple.  4 — White : The method we previously recommended in our MTF Selection Framework , which uses two distinct security() calls.  5 — Black : A lame attempt at fooling traders that MUST be avoided. All lines except the first one in yellow will vary depending on the "Repaint" setting in the script's inputs. The first plot does not change because, contrary to all other plots, it contains no conditional code to adapt to repainting/no-repainting modes; it is a simple security() call showing its default behavior. C — Points of interest on the chart Historical bars do not show actual repainting behavior To appreciate what a repainting security()  call will plot in realtime, one must look at the realtime bar and at elapsed realtime bars, the bars where the top line is green or red on the chart at the top of this page. There you can see how the plots go up and down, following the close value of each successive chart bar making up a single bar of the higher timeframe. You would see the same behavior in "Replay" mode. In the realtime bar, the movement of repainting plots will vary with the source you are fetching: open will not move after a new timeframe opens, low and high will change when a new low or high are found, close will follow the last feed update. If you are fetching a value calculated by a function, it may also change on each update. Now notice how different the plots are on historical bars. There, the plot shows the close of the previously completed timeframe for the whole duration of the current timeframe, until on its last bar the price updates to the current timeframe's close when it is confirmed (if the timeframe's last bar is missing, the plot will only update on the next timeframe's first bar). That last bar is the only one showing where the plot would end if that timeframe's bars had elapsed in realtime. If one doesn't understand this, one cannot properly visualize how his script will calculate in realtime when using repainting. Additionally, as published scripts typically show charts where the script has only run on historical bars, they are, in fact, misleading traders who will naturally assume the script will behave the same way on realtime bars. Non-repainting plots are more accurate on historical bars Now consider this chart, where we are using the same settings as on the chart used to publish this script, except that we have turned "Repainting" off this time: The yellow line here is our reference, repainting line, so although repainting is turned off, it is still repainting, as expected. Because repainting is now off, however, plots on historical bars show the previous timeframe's close until the first bar of a new timeframe, at which point the plot updates. This correctly reflects the behavior of the script in the realtime bar, where because we are offsetting the series by one, we are always showing the previously calculated—and thus confirmed—higher timeframe value. This means that in realtime, we will only get the previous timeframe's values one bar after the timeframe's last bar has elapsed, at the open of the first bar of a new timeframe. Historical and elapsed realtime bars will not actually show this nuance because they reflect the state of calculations made on their close , but we can see the plot update on that bar nonetheless. ► This more accurate representation on historical bars of what will happen in the realtime bar is one of the two key reasons why using non-repainting data is preferable.    The other is that in realtime, your script will be using more reliable data and behave more consistently. Misleading plots Valiant attempts by coders to show non-repainting, higher timeframe data updating earlier than on our chart are futile. If updates occur one bar earlier because coders use the repainting version of the function, then so be it, but they must then also accept that their historical bars are not displaying information that is as accurate. Not informing script users of this is to mislead them. Coders should also be aware that if they choose to use repainting data in realtime, they are sacrificing reliability to speed and may be running a strategy that behaves very differently from the one they backtested, thus invalidating their tests. When, however, coders make what are supposed to be non-repainting plots plot artificially early on historical bars, as in examples "c4" and "c5" of our script, they would want us to believe they have achieved the miracle of time travel. Our understanding of the current state of science dictates that for now, this is impossible. Using such techniques in scripts is plainly misleading, and public scripts using them will be moderated. We are coding trading tools here—not video games. Elementary ethics prescribe that we should not mislead traders, even if it means not being able to show sexy plots. As the great Feynman said: You should not fool the layman when you're talking as a scientist. You can readily appreciate the fantasy plot of "c4", the thinnest line in black, by comparing its supposedly non-repainting behavior between historical bars and realtime bars. After updating—by miracle—as early as the wide yellow line that is repainting, it suddenly moves in a more realistic place when the script is running in realtime, in synch with our non-repainting lines. The "c5" version does not plot on the chart, but it displays in the Data Window. It is even worse than "c4" in that it also updates magically early on historical bars, but goes on to evaluate like the repainting yellow line in realtime, except one bar late. Data Window The Data Window shows the values of the chart's plots, then the values of both the inside and outside offsets used in our calculations, so you can see them change bar by bar. Notice their differences between historical and elapsed realtime bars, and the realtime bar itself. If you do not know about the Data Window, have a look at this essential tool for Pine coders in the Pine User Manual's page on Debugging . The conditional expressions used to calculate the offsets may seem tortuous but their objective is quite simple. When repainting is on, we use this form, so with no offset on all bars: security(ticker, i_timeframe, i_source ) // which is equivalent to: security(ticker, i_timeframe, i_source) When repainting is off, we use two different and inverted offsets on historical bars and the realtime bar: // Historical bars: security(ticker, i_timeframe, i_source ) // Realtime bar (and thus, elapsed realtime bars): security(ticker, i_timeframe, i_source ) The offsets in the first line show how we prevent repainting on historical bars without the need for the `lookahead` parameter. We use the value of the function call on the chart's previous bar. Since values between the repainting and non-repainting versions only differ on the timeframe's last bar, we can use the previous value so that the update only occurs on the timeframe's first bar, as it will in realtime when not repainting. In the realtime bar, we use the second call, where the offsets are inverted. This is because if we used the first call in realtime, we would be fetching the value of the repainting function on the previous bar, so the close of the last bar. What we want, instead, is the data from the previous, higher timeframe bar , which has elapsed and is confirmed, and thus will not change throughout realtime bars, except on the first constituent chart bar belonging to a new higher timeframe. After the offsets, the Data Window shows values for the `barstate.*` variables we use in our calculations. █  NOTES Why are we revisiting security()  ? For four reasons:  1 — We were seeing coders misuse our `f_secureSecurity()` function presented in How to avoid repainting when using security() .    Some novice coders were modifying the offset used with the history-referencing operator in the function, making it zero instead of one,    which to our horror, caused look-ahead bias when used with `lookahead = barmerge.lookahead_on`.    We wanted to present a safer function which avoids introducing the dreaded "lookahead" in the scripts of unsuspecting coders.  2 — The popularity of security() in screener-type scripts where coders need to use the full 40 calls allowed per script made us want to propose    a solid method of allowing coders to offer a repainting/no-repainting choice to their script users with only one security() call.  3 — We wanted to explain why some alternatives we see circulating are inadequate and produce misleading behavior.  4 — Our previous publication on security() focused on how to avoid repainting, yet many other considerations worthy of attention are not related to repainting. Handling tuples When sending function calls that return tuples with security() , our `f_security()` function will not work because Pine does not allow us to use the history-referencing operator with tuple return values. The solution is to integrate the inside offset to your function's arguments, use it to offset the results the function is returning, and then add the outside offset in a reassignment of the tuple variables, after security() returns its values to the script, as we do in our "c2" example. Does it repaint? We're pretty sure Wilder was not asked very often if RSI repainted. Why? Because it wasn't in fashion—and largely unnecessary—to ask that sort of question in the 80's. Many traders back then used daily charts only, and indicator values were calculated at the day's close, so everybody knew what they were getting. Additionally, indicator values were calculated by generally reputable outfits or traders themselves, so data was pretty reliable. Today, almost anybody can write a simple indicator, and the programming languages used to write them are complex enough for some coders lacking the caution, know-how or ethics of the best professional coders, to get in over their heads and produce code that does not work the way they think it does. As we hope to have clearly demonstrated, traders do have legitimate cause to ask if MTF scripts repaint or not when authors do not specify it in their script's description. ► We recommend that authors always use our `f_security()` with `false` as the last argument to avoid repainting when fetching data dependent on OHLCV information. This is the only way to obtain reliable HTF data. If you want to offer users a choice, make non-repainting mode the default, so that if users choose repainting, it will be their responsibility. Non-repainting security() calls are also the only way for scripts to show historical behavior that matches the script's realtime behavior, so you are not misleading traders. Additionally, non-repainting HTF data is the only way that non-repainting alerts can be configured on MTF scripts, as users of MTF scripts cannot prevent their alerts from repainting by simply configuring them to trigger on the bar's close. Data feeds A chart at one timeframe is made up of multiple feeds that mesh seamlessly to form one chart. Historical bars can use one feed, and the realtime bar another, which brokers/exchanges can sometimes update retroactively so that elapsed realtime bars will reappear with very slight modifications when the browser's tab is refreshed. Intraday and daily chart prices also very often originate from different feeds supplied by brokers/exchanges. That is why security() calls at higher timeframes may be using a completely different feed than the chart, and explains why the daily high value, for example, can vary between timeframes. Volume information can also vary considerably between intraday and daily feeds in markets like stocks, because more volume information becomes available at the end of day. It is thus expected behavior—and not a bug—to see data variations between timeframes. Another point to keep in mind concerning feeds it that when you are using a repainting security() plot in realtime, you will sometimes see discrepancies between its plot and the realtime bars. An artefact revealing these inconsistencies can be seen when security() plots sometimes skip a realtime chart bar during periods of high market activity. This occurs because of races between the chart and the security() feeds, which are being monitored by independent, concurrent processes. A blue arrow on the chart indicates such an occurrence. This is another cause of repainting, where realtime bar-building logic can produce different outcomes on one closing price. It is also another argument supporting our recommendation to use non-repainting data. Alternatives There is an alternative to using security() in some conditions. If all you need are OHLC prices of a higher timeframe, you can use a technique like the one Duyck demonstrates in his security free MTF example - JD script. It has the great advantage of displaying actual repainting values on historical bars, which mimic the code's behavior in the realtime bar—or at least on elapsed realtime bars, contrary to a repainting security() plot. It has the disadvantage of using the current chart's TF data feed prices, whereas higher timeframe data feeds may contain different and more reliable prices when they are compiled at the end of the day. In its current state, it also does not allow for a repainting/no-repainting choice. When `lookahead` is useful When retrieving non-price data, or in special cases, for experiments, it can be useful to use `lookahead`. One example is our Backtesting on Non-Standard Charts: Caution! script where we are fetching prices of standard chart bars from non-standard charts. Warning users Normal use of security() dictates that it only be used at timeframes equal to or higher than the chart's. To prevent users from inadvertently using your script in contexts where it will not produce expected behavior, it is good practice to warn them when their chart is on a higher timeframe than the one in the script's "Timeframe" field. Our `f_tfReminderAndErrorCheck()` function in this script does that. It can also print a reminder of the higher timeframe. It uses one security() call. Intrabar timeframes security() is not supported by TradingView when used with timeframes lower than the chart's. While it is still possible to use security() at intrabar timeframes, it then behaves differently. If no care is taken to send a function specifically written to handle the successive intrabars, security() will return the value of the last intrabar in the chart's timeframe, so the last 1H bar in the current 1D bar, if called at "60" from a "D" chart timeframe. If you are an advanced coder, see our FAQ entry on the techniques involved in processing intrabar timeframes. Using intrabar timeframes comes with important limitations, which you must understand and explain to traders if you choose to make scripts using the technique available to others. Special care should also be taken to thoroughly test this type of script. Novice coders should refrain from getting involved in this. █  TERMINOLOGY Timeframe Timeframe , interval and resolution are all being used to name the concept of timeframe. We have, in the past, used "timeframe" and "resolution" more or less interchangeably. Recently, members from the Pine and PineCoders team have decided to settle on "timeframe", so from hereon we will be sticking to that term. Multi-timeframe (MTF) Some coders use "multi-timeframe" or "MTF" to name what are in fact "multi-period" calculations, as when they use MAs of progressively longer periods. We consider that a misleading use of "multi-timeframe", which should be reserved for code using calculations actually made from another timeframe's context and using security() , safe for scripts like Duyck's one mentioned earlier, or TradingView's Relative  Volume  at  Time , which use a user-selected timeframe as an anchor to reset calculations. Calculations made at the chart's timeframe by varying the period of MAs or other rolling window calculations should be called "multi-period", and "MTF-anchored" could be used for scripts that reset calculations on timeframe boundaries. Colophon Our script was written using the PineCoders Coding Conventions for Pine . The description was formatted using the techniques explained in the How We Write and Format Script Descriptions PineCoders publication. Snippets were lifted from our MTF Selection Framework , then massaged to create the `f_tfReminderAndErrorCheck()` function. █  THANKS Thanks to apozdnyakov for his help with the innards of security() . Thanks to bmistiaen for proofreading our description. Look first. Then leap.
Indicador Pine Script™
por PineCoders
60
Nick Rypock Trailing Reverse (NRTR)This indicator was invented in 2001 by Konstantin Kopyrkin. The name "Nick Rypock" is derived from his surname reading in the opposite direction: Kopyrkin -> Kopyr Kin -> Kin Kopyr -> Nik Rypok The idea of the indicator is similar to the Chandelier Exit, but doesn't involve ATR component and uses a percentage instead. A dynamic price channel is used to calculate the NRTR. The calculations involve only those prices that are included in the current trend and exclude the extremes related to the previous trend. The indicator is always at the same distance (in percent) from the extremes reached by prices (below the maximum peak for the current uptrend, above the minimum bottom for the current downtrend).
Indicador Pine Script™
por everget
136
Machine Learning: Logistic RegressionMulti-timeframe Strategy based on Logistic Regression algorithm Description: This strategy uses a classic machine learning algorithm that came from statistics - Logistic Regression (LR). The first and most important thing about logistic regression is that it is not a 'Regression' but a 'Classification' algorithm. The name itself is somewhat misleading. Regression gives a continuous numeric output but most of the time we need the output in classes (i.e. categorical, discrete). For example, we want to classify emails into “spam” or 'not spam', classify treatment into “success” or 'failure', classify statement into “right” or 'wrong', classify election data into 'fraudulent vote' or 'non-fraudulent vote', classify market move into 'long' or 'short' and so on. These are the examples of logistic regression having a binary output (also called dichotomous). You can also think of logistic regression as a special case of linear regression when the outcome variable is categorical, where we are using log of odds as dependent variable. In simple words, it predicts the probability of occurrence of an event by fitting data to a logit function. Basically, the theory behind Logistic Regression is very similar to the one from Linear Regression, where we seek to draw a best-fitting line over data points, but in Logistic Regression, we don’t directly fit a straight line to our data like in linear regression. Instead, we fit a S shaped curve, called Sigmoid, to our observations, that best SEPARATES data points. Technically speaking, the main goal of building the model is to find the parameters (weights) using gradient descent. In this script the LR algorithm is retrained on each new bar trying to classify it into one of the two categories. This is done via the logistic_regression function by updating the weights w in the loop that continues for iterations number of times. In the end the weights are passed through the sigmoid function, yielding a prediction. Mind that some assets require to modify the script's input parameters. For instance, when used with BTCUSD and USDJPY, the 'Normalization Lookback' parameter should be set down to 4 (2,...,5..), and optionally the 'Use Price Data for Signal Generation?' parameter should be checked. The defaults were tested with EURUSD. Note: TradingViews's playback feature helps to see this strategy in action. Warning: Signals ARE repainting. Style tags: Trend Following, Trend Analysis Asset class: Equities, Futures, ETFs, Currencies and Commodities Dataset: FX Minutes/Hours/Days
Indicador Pine Script™
por capissimo
112
VolumeHeatmap | Experimental Version of Marketorders MatrixDear all, I wish a Happy New Year! The last time I tried to developing a Volume Heatmap, that the Marketorders made. With the currently version I achieve my skills for that and I present it for everyone - some bugs I cannot solve today. It also possible to see the POC - also the dynamic of volume developing: The background for that is to find the pricelevel with the most volume - this is for valuetrading always the target. If someone find it useful or have question - let me know! Kind regards NXT2017
Indicador Pine Script™
por NXT2017
96
Relative Volume at Time█  OVERVIEW This indicator calculates relative volume, which is the ratio of present volume over an average of past volume. It offers two calculation modes, both using a time reference as an anchor.                                          █  CONCEPTS Calculation modes The simplest way to calculate relative volume is by using the ratio of a bar's volume over a simple moving average of the last n volume values. This indicator uses one of two, more subtle ways to calculate both values of the relative volume ratio: current volume:past volume . The two calculations modes are:  1 — Cumulate from Beginning of TF to Current Bar where:     current volume = the cumulative volume since the beginning of the timeframe unit, and     past volume = the mean of volume during that same relative period of time in the past n timeframe units.  2 — Point-to-Point Bars at Same Offset from Beginning of TF where:     current volume = the volume on a single chart bar, and     past volume = the mean of volume values from that same relative bar in time from the past n timeframe units. Timeframe units Timeframe units can be defined in three different ways:  1 — Using Auto-steps, where the timeframe unit automatically adjusts to the timeframe used on the chart:     — A 1 min timeframe unit will be used on 1sec charts,     — 1H will be used for charts at 1min and less,     — 1D will be used for other intraday chart timeframes,     — 1W will be used for 1D charts,     — 1M will be used for charts at less than 1M,     — 1Y will be used for charts at greater or equal than 1M.  2 — As a fixed timeframe that you define.  3 — By time of day (for intraday chart timeframes only), which you also define. If you use non-intraday chart timeframes in this mode, the indicator will switch to Auto-steps. Relative Relativity A relative volume value of 1.0 indicates that current volume is equal to the mean of past volume , but how can we determine what constitutes a high relative volume value? The traditional way is to settle for an arbitrary threshold, with 2.0 often used to indicate that relative volume is worthy of attention. We wanted to provide traders with a contextual method of calculating threshold values, so in addition to the conventional fixed threshold value, this indicator includes two methods of calculating a threshold channel on past relative volume values:  1 — Using the standard deviation of relative volume over a fixed lookback.  2 — Using the highs/lows of relative volume over a variable lookback. Channels calculated on relative volume provide meta-relativity, if you will, as they are relative values of relative volume. █  FEATURES Controls in the "Display" section of inputs determine what is visible in the indicator's pane. The next "Settings" section is where you configure the parameters used in the calculations. The "Column Coloring Conditions" section controls the color of the columns, which you will see in three of the five display modes available. Whether columns are plotted or not, the coloring conditions also determine when markers appear, if you have chosen to show the markers in the "Display" section. The presence of markers is what triggers the alerts configured on this indicator. Finally, the "Colors" section of inputs allows you to control the color of the indicator's visual components. Display Five display modes are available:  • Current Volume Columns : shows columns of current volume , with past volume displayed as an outlined column.  • Relative Volume Columns : shows relative volume as a column.  • Relative Volume Columns With Average : shows relative volume as a column, with the average of relative volume.  • Directional Relative Volume Average : shows a line calculated using the average of +/- values of relative volume.   The positive value of relative volume is used on up bars; its negative value on down bars.  • Relative Volume Average : shows the average of relative volume. A Hull moving average is used to calculate the average used in the three last display modes. You can also control the display of:  • The value or relative volume, when in the first three display modes. Only the last 500 values will be shown.  • Timeframe transitions, shown in the background.  • A reminder of the active timeframe unit, which appears to the right of the indicator's last bar.  • The threshold used, which can be a fixed value or a channel, as determined in the next "Settings" section of inputs.  • Up/Down markers, which appear on transitions of the color of the volume columns (determined by coloring conditions), which in turn control when alerts are triggered.  • Conditions of high volatility. Settings Use this section of inputs to change:  • Calculation mode : this is where you select one of this indicator's two calculation modes for current volume and past volume , as explained in the "Concepts" section.  • Past Volume Lookback in TF units : the quantity of timeframe units used in the calculation of past volume .  • Define Timeframes Units Using : the mode used to determine what one timeframe unit is. Note that when using a fixed timeframe, it must be higher than the chart's timeframe.   Also, note that time of day timeframe units only work on intraday chart timeframes.  • Threshold Mode : Five different modes can be selected:    — Fixed Value : You can define the value using the "Fixed Threshold" field below. The default value is 2.0.    — Standard Deviation Channel From Fixed Lookback : This is a channel calculated using the simple moving average of relative volume     (so not the Hull moving average used elsewhere in the indicator), plus/minus the standard deviation multiplied by a user-defined factor.     The lookback used is the value of the "Channel Lookback" field. Its default is 100.    — High/Low Channel From Beginning of TF : in this mode, the High/Low values reset at the beginning of each timeframe unit.    — High/Low Channel From Beginning of Past Volume Lookback : in this mode, the High/Low values start from the farthest point back where we are calculating past volume ,     which is determined by the combination of timeframe units and the "Past Volume Lookback in TF units" value.    — High/Low Channel From Fixed Lookback : In this mode the lookback is fixed. You can define the value using the "Channel Lookback" field. The default value is 100.  • Period of RelVol Moving Average : the period of the Hull moving average used in the "Directional Relative Volume Average" and the "Relative Volume Average".  • High Volatility is defined using fast and slow ATR periods, so this represents the volatility of price.   Volatility is considered to be high when the fast ATR value is greater than its slow value. Volatility can be used as a filter in the column coloring conditions. Column Coloring Conditions  • Eight different conditions can be turned on or off to determine the color of the volume columns. All "ON" conditions must be met to determine a high/low state of relative volume,   or, in the case of directional relative volume, a bull/bear state.  • A volatility state can also be used to filter the conditions.  • When the coloring conditions and the filter do not allow for a high/low state to be determined, the neutral color is used.  • Transitions of the color of the volume columns determined by coloring conditions are used to plot the up/down markers, which in turn control when alerts are triggered. Colors  • You can define your own colors for all of the oscillator's plots.  • The default colors will perform well on light or dark chart backgrounds. Alerts  • An alert can be defined for the script. The alert will trigger whenever an up/down marker appears in the indicator's display.   The particular combination of coloring conditions and the display settings for up/down markers when you create the alert will determine which conditions trigger the alert.   After alerts are created, subsequent changes to the conditions controlling the display of markers will not affect existing alerts.  • By configuring the script's inputs in different ways before you create your alerts, you can create multiple, functionally distinct alerts from this script.   When creating multiple alerts, it is useful to include in the alert's message a reminder of the particular conditions you used for each alert.  • As is usually the case, alerts triggering "Once Per Bar Close" will prevent repainting. Error messages Error messages will appear at the end of the chart upon the following conditions:  • When the combination of the timeframe units used and the "Past Volume Lookback in TF units" value create a lookback that is greater than 5000 bars.   The lookback will then be recalculated to a value such that a runtime error does not occur.  • If the chart's timeframe is higher than the timeframe units. This error cannot occur when using Auto-steps to calculate timeframe units.  • If relative volume cannot be calculated, for example, when no volume data is available for the chart's symbol.  • When the threshold of relative volume is configured to be visible but the indicator's scale does not allow it to be visible (in "Current Volume Columns" display mode). █  NOTES For traders The chart shown here uses the following display modes: "Current Volume Columns", "Relative Volume Columns With Average", "Directional Relative Volume Average" and "Relative Volume Average". The last one also shows the threshold channel in standard deviation mode, and the TF Unit reminder to the right, in red. Volume, like price, is a value with a market-dependent scale. The only valid reference for volume being its past values, any improvement in the way past volume is calculated thus represents a potential opportunity to traders. Relative volume calculated as it is here can help traders extract useful information from markets in many circumstances, markets with cyclical volume such as Forex being one, obvious case. The relative nature of the values calculated by this indicator also make it a natural fit for cross-market and cross-sector analysis, or to identify behavioral changes in the different futures contracts of the same market. Relative volume can also be put to more exotic uses, such as in evaluating changes in the popularity of exchanges. Relative volume alone has no directional bias. While higher relative volume values always indicate higher trading activity, that activity does not necessarily translate into significant price movement. In a tightly fought battle between buyers and sellers, you could theoretically have very large volume for many bars, with no change whatsoever in bid/ask prices. This of course, is unlikely to happen in reality, and so traders are justified in considering high relative volume values as indicating periods where more attention is required, because imbalances in the strength of buying/selling power during high-volume trading periods can amplify price variations, providing traders with the generally useful gift of volatility. Be sure to give the "Directional Relative Volume Average" a try. Contrary to the always-positive ratio widely used in this indicator, the "Directional Relative Volume Average" produces a value able to determine a bullish/bearish bias for relative volume. Note that realtime bars must be complete for the relative volume value to be confirmed. Values calculated on historical or elapsed realtime bars will not recalculate unless historical volume data changes. Finally, as with all indicators using volume information, keep in mind that some exchanges/brokers supply different feeds for intraday and daily data, and the volume data on both feeds can sometimes vary quite a bit. For coders 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. Bits and pieces of code were lifted from the MTF Selection Framework and the MTF Oscillator Framework , also by PineCoders. █  THANKS Thanks to dgtrd for suggesting to add the channel using standard deviation. Thanks to adolgov for helpful suggestions on calculations and visuals. Look first. Then leap.
Indicador Pine Script™
por TradingView
52
Waindrops [Makit0]█  OVERALL Plot waindrops (custom volume profiles) on user defined periods, for each period you get high and low, it slices each period in half to get independent vwap, volume profile and the volume traded per price at each half. It works on intraday charts only, up to 720m (12H). It can plot balanced or unbalanced waindrops, and volume profiles up to 24H sessions. As example you can setup unbalanced periods to get independent volume profiles for the overnight and cash sessions on the futures market, or 24H periods to get the full session volume profile of EURUSD The purpose of this indicator is twofold: 1 — from a Chartist point of view, to have an indicator which displays the volume in a more readable way 2 — from a Pine Coder point of view, to have an example of use for two very powerful tools on Pine Script:    • the recently updated drawing limit to 500 (from 50)    • the recently ability to use drawings arrays (lines and labels) If you are new to Pine Script and you are learning how to code, I hope you read all the code and comments on this indicator, all is designed for you, the variables and functions names, the sometimes too big explanations, the overall structure of the code, all is intended as an example on how to code in Pine Script a specific indicator from a very good specification in form of white paper If you wanna learn Pine Script form scratch just start HERE In case you have any kind of problem with Pine Script please use some of the awesome resources at our disposal: USRMAN , REFMAN , AWESOMENESS , MAGIC █  FEATURES Waindrops are a different way of seeing the volume and price plotted in a chart, its a volume profile indicator where you can see the volume of each price level plotted as a vertical histogram for each half of a custom period. By default the period is 60 so it plots an independent volume profile each 30m You can think of each waindrop as an user defined candlestick or bar with four key values:  • high of the period  • low of the period  • left vwap (volume weighted average price of the first half period)  • right vwap (volume weighted average price of the second half period) The waindrop can have 3 different colors (configurable by the user):  • GREEN: when the right vwap is higher than the left vwap (bullish sentiment )  • RED: when the right vwap is lower than the left vwap (bearish sentiment )  • BLUE: when the right vwap is equal than the left vwap ( neutral sentiment ) KEY FEATURES  • Help menu  • Custom periods  • Central bars  • Left/Right VWAPs  • Custom central bars and vwaps: color and pixels  • Highly configurable volume histogram: execution window, ticks, pixels, color, update frequency and fine tuning the neutral meaning  • Volume labels with custom size and color  • Tracking price dot to be able to see the current price when you hide your default candlesticks or bars █  SETTINGS Click here or set any impar period to see the HELP INFO : show the HELP INFO, if it is activated the indicator will not plot PERIOD SIZE (max 2880 min) : waindrop size in minutes, default 60, max 2880 to allow the first half of a 48H period as a full session volume profile BARS : show the central and vwap bars, default true    Central bars : show the central bars, default true    VWAP bars : show the left and right vwap bars, default true    Bars pixels : width of the bars in pixels, default 2    Bars color mode : bars color behavior    • BARS : gets the color from the 'Bars color' option on the settings panel    • HISTOGRAM : gets the color from the Bearish/Bullish/Neutral Histogram color options from the settings panel    Bars color : color for the central and vwap bars, default white HISTOGRAM show the volume histogram, default true    Execution window (x24H) : last 24H periods where the volume funcionality will be plotted, default 5    Ticks per bar (max 50) : width in ticks of each histogram bar, default 2    Updates per period : number of times the histogram will update    • ONE : update at the last bar of the period    • TWO : update at the last bar of each half period    • FOUR : slice the period in 4 quarters and updates at the last bar of each of them    • EACH BAR : updates at the close of each bar    Pixels per bar : width in pixels of each histogram bar, default 4    Neutral Treshold (ticks) : delta in ticks between left and right vwaps to identify a waindrop as neutral, default 0    Bearish Histogram color : histogram color when right vwap is lower than left vwap, default red    Bullish Histogram color : histogram color when right vwap is higher than left vwap, default green    Neutral Histogram color : histogram color when the delta between right and left vwaps is equal or lower than the Neutral treshold, default blue VOLUME LABELS : show volume labels    Volume labels color : color for the volume labels, default white    Volume Labels size : text size for the volume labels, choose between AUTO, TINY, SMALL, NORMAL or LARGE, default TINY TRACK PRICE : show a yellow ball tracking the last price, default true █  LIMITS This indicator only works on intraday charts (minutes only) up to 12H (720m), the lower chart timeframe you can use is 1m This indicator needs price, time and volume to work, it will not work on an index (there is no volume), the execution will not be allowed The histogram (volume profile) can be plotted on 24H sessions as limit but you can plot several 24H sessions █  ERRORS AND PERFORMANCE Depending on the choosed settings, the script performance will be highly affected and it will experience errors Two of the more common errors it can throw are:  • Calculation takes too long to execute  • Loop takes too long The indicator performance is highly related to the underlying volatility (tick wise), the script takes each candlestick or bar and for each tick in it stores the price and volume, if the ticker in your chart has thousands and thousands of ticks per bar the indicator will throw an error for sure, it can not calculate in time such amount of ticks. What all of that means? Simply put, this will throw error on the BITCOIN pair BTCUSD (high volatility with tick size 0.01) because it has too many ticks per bar, but lucky you it will work just fine on the futures contract BTC1! (tick size 5) because it has a lot less ticks per bar There are some options you can fine tune to boost the script performance, the more demanding option in terms of resources consumption is Updates per period , by default is maxed out so lowering this setting will improve the performance in a high way. If you wanna know more about how to improve the script performance, read the HELP INFO accessible from the settings panel █  HOW-TO SETUP The basic parameters to adjust are Period size , Ticks per bar and Pixels per bar  • Period size is the main setting, defines the waindrop size, to get a better looking histogram set bigger period and smaller chart timeframe  • Ticks per bar is the tricky one, adjust it differently for each underlying (ticker) volatility wise, for some you will need a low value, for others a high one.    To get a more accurate histogram set it as lower as you can (min value is 1)  • Pixels per bar allows you to adjust the width of each histogram bar, with it you can adjust the blank space between them or allow overlaping You must play with these three parameters until you obtain the desired histogram: smoother, sharper, etc... These are some of the different kind of charts you can setup thru the settings:  • Balanced Waindrops (default): charts with waindrops where the two halfs are of same size.    This is the default chart, just select a period (30m, 60m, 120m, 240m, pick your poison), adjust the histogram ticks and pixels and watch  • Unbalanced Waindrops: chart with waindrops where the two halfs are of different sizes.    Do you trade futures and want to plot a waindrop with the first half for the overnight session and the second half for the cash session? you got it;    just adjust the period to 1860 for any CME ticker (like ES1! for example) adjust the histogram ticks and pixels and watch  • Full Session Volume Profile: chart with waindrops where only the first half plots.    Do you use Volume profile to analize the market? Lucky you, now you can trick this one to plot it, just try a period of 780 on SPY, 2760 on ES1!, or 2880 on EURUSD    remember to adjust the histogram ticks and pixels for each underlying  • Only Bars: charts with only central and vwap bars plotted, simply deactivate the histogram and volume labels  • Only Histogram: charts with only the histogram plotted (volume profile charts), simply deactivate the bars and volume labels  • Only Volume: charts with only the raw volume numbers plotted, simply deactivate the bars and histogram If you wanna know more about custom full session periods for different asset classes, read the HELP INFO accessible from the settings panel EXAMPLES Full Session Volume Profile on MES 5m chart: Full Session Unbalanced Waindrop on MNQ 2m chart (left side Overnight session, right side Cash Session): The following examples will have the exact same charts but on four different tickers representing a futures contract, a forex pair, an etf and a stock. We are doing this to be able to see the different parameters we need for plotting the same kind of chart on different assets The chart composition is as follows:  • Left side: Volume Labels chart (period 10)  • Upper Right side: Waindrops (period 60)  • Lower Right side: Full Session Volume Profile The first example will specify the main parameters, the rest of the charts will have only the differences MES :  • Left: Period size: 10, Bars: uncheck, Histogram: uncheck, Execution window: 1, Ticks per bar: 2, Updates per period: EACH BAR,    Pixels per bar: 4, Volume labels: check, Track price: check  • Upper Right: Period size: 60, Bars: check, Bars color mode: HISTOGRAM, Histogram: check, Execution window: 2, Ticks per bar: 2,    Updates per period: EACH BAR, Pixels per bar: 4, Volume labels: uncheck, Track price: check  • Lower Right: Period size: 2760, Bars: uncheck, Histogram: check, Execution window: 1, Ticks per bar: 1, Updates per period: EACH BAR,    Pixels per bar: 2, Volume labels: uncheck, Track price: check EURUSD :  • Upper Right: Ticks per bar: 10  • Lower Right: Period size: 2880, Ticks per bar: 1, Pixels per bar: 1 SPY :  • Left: Ticks per bar: 3  • Upper Right: Ticks per bar: 5, Pixels per bar: 3  • Lower Right: Period size: 780, Ticks per bar: 2, Pixels per bar: 2 AAPL :  • Left: Ticks per bar: 2  • Upper Right: Ticks per bar: 6, Pixels per bar: 3  • Lower Right: Period size: 780, Ticks per bar: 1, Pixels per bar: 2 █  THANKS TO PineCoders for all they do, all the tools and help they provide and their involvement in making a better community scarf for the idea of coding a waindrops like indicator, I did not know something like that existed at all All the Pine Coders, Pine Pros and Pine Wizards, people who share their work and knowledge for the sake of it and helping others, I'm very grateful indeed I'm learning at each step of the way from you all, thanks for this awesome community; Opensource and shared knowledge: this is the way! (said with canned voice from inside my helmet :D) █  NOTE This description was formatted following THIS guidelines ═════════════════════════════════════════════════════════════════════════ I sincerely hope you enjoy reading and using this work as much as I enjoyed developing it :D GOOD LUCK AND HAPPY TRADING!
Indicador Pine Script™
por makit0
107
Moving RegressionMoving Regression is a generalization of moving average and polynomial regression. The procedure approximates a specified number of prior data points with a polynomial function of a user-defined degree. Then, polynomial interpolation of the last data point is used to construct a Moving Regression time series. Application: Moving Regression allows one to smooth noise on the analyzed chart, assess momentum, confirm trends, and establish areas of support and resistance. In addition, it can be used as a simple stand-alone forecasting method to identify trend direction and trend​ reversal points. When the local polynomial is predicted to move up in the next time step, the color of the Moving Regression curve will be green. Otherwise, the color of the curve is red. This function is (de)activated using the Predict Trend Direction flag. Selecting the ​model parameters: The effects of the moving window Length and the Local Polynomial Degree are confounded. This allows for​ finding the optimal trade-off between noise (variance) and lag (bias). Higher Length and lower Polynomial Degree (such as 1, i.e. linear), will result in "smoother" time series but at the cost of greater lag. Increasing the Polynomial​ Degree to, for example, 2 (squared) while maintaining the Length will diminish the lag and thus compromise the noise-lag tradeoff. Relation to other methods: When the degree of the local polynomial is set to 0 (i.e., fitting data to a constant level), the Moving Regression time series exactly matches the Simple Moving Average of the same length.
Indicador Pine Script™
por tbiktag
16
Linear Regression ChannelHello Traders, There are several nice Linear Regression Channel scripts in the Public Library. and I tried to make one with some extra features too. This one can check if the Price breaks the channel and it shows where is was broken. Also it checks the momentum of the channel and shows it's increasing/decreasing/equal in a label, shape of the label also changes. The line colors change according to direction. using the options, you can; - Set the Source (Close, HL2 etc) - Set the Channel length - Set Deviation - Change Up/Down Line colors - Show/hide broken channels - Change line width meaning of arrows: ⇑ : Uptrend and moment incresing ⇗ : Uptrend and moment decreasing ⇓ : Downtrend and moment incresing ⇘ : Downtrend and moment decreasing ⇒ : No trend An example for how color of lines, arrow direction and shape of label change. Enjoy!
Indicador Pine Script™
por LonesomeTheBlue
124
ProjectionGreetings Traders! I have decided to release a few scripts as open-source as I'm sure others can benefit from them and perhaps make them better.(Be sure to check my Profile for the other scripts as well: www.tradingview.com). This one is called Projection. Projection is based off the same Principle as some of my other scripts, such as Trade Manager() and Price Predictor(). I use a simple concept using line.new() to define some potential Price Projections. From the Settings of the Indicator, you can access a couple different Pre-Set options. Wide Parabola: Skinny Parabola: Straight Triangle: ZigZag1: ZigZag2: I wanted to give a Special Thanks to @Pinecoders for the custom RoundToTick Function from Backtesting/Trading Engine --> () If you like Projection, be sure to Like, Follow, and if you have any questions, don't be afraid to drop a comment below.
Indicador Pine Script™
por DrCatherineHalsey
17
Let it snow... [QuantNomad]It's almost the end of 2020. If you don't have any snow outside but still you want some Christmas mood - feel free to use my indicator. TradingView added a possibility to use up to 500 labels, so I decided to create something fun and completely useless. Snowflakes suppose to fall nicely, but labels are not regularly updated by TradingView. If you know how to make it better - let me know ) For the best experience use Dark Theme and play the "Let it snow" song ) Merry Christmas & Happy New Year!
Indicador Pine Script™
por QuantNomad
5
Machine Learning: kNN-based StrategykNN-based Strategy (FX and Crypto) Description: This strategy uses a classic machine learning algorithm - k Nearest Neighbours (kNN) - to let you find a prediction for the next (tomorrow's, next month's, etc.) market move. Being an unsupervised machine learning algorithm, kNN is one of the most simple learning algorithms. To do a prediction of the next market move, the kNN algorithm uses the historic data, collected in 3 arrays - feature1, feature2 and directions, - and finds the k-nearest neighbours of the current indicator(s) values. The two dimensional kNN algorithm just has a look on what has happened in the past when the two indicators had a similar level. It then looks at the k nearest neighbours, sees their state and thus classifies the current point. The kNN algorithm offers a framework to test all kinds of indicators easily to see if they have got any *predictive value*. One can easily add cog, wpr and others. Note: TradingViews's playback feature helps to see this strategy in action. Warning: Signals ARE repainting. Style tags: Trend Following, Trend Analysis Asset class: Equities, Futures, ETFs, Currencies and Commodities Dataset: FX Minutes/Hours+++/Days
Indicador Pine Script™
por capissimo
148
Indices Sector SigmaSpikes█ OVERVIEW “The benchmark Dow Jones Industrial Average is off nearly 300 points as of midday today...” “So what? Is that a lot or a little? Should we care?” -Adam H Grimes- This screener aims to provide Bird-Eye view across sector indices, to find which sector is having significant or 'out-of-norm' move in either direction. The significance of the move is measured based on Sigma Spikes, a method proposed by Adam H. Grimes, where Standard Deviation of returns used as a baseline. *You can google his blog or read his book, got some gold in there, especially on how he use indicators for trading █ Understanding Sigma Spikes As described by Grimes, moves in markets are only meaningful when we consider what “normal” is for that market. Without that baseline, the daily change number, and even the percent change on the day doesn’t really mean much. To overcome that problem, Sigma Spikes, as a measure of volatility, attempt to put todays change in price (aka return) in context of the standard deviation of 20 days daily's return. Refer chart below: 1. The blue bars refer to each days return 2. The orange line is 1 time standard deviation of past 20days daily's return (today not included) 3. The red line is 2 time standard deviation of past 20days daily's return (today not included) Using the ratio of today's return over the Std Deviation, determining your threshold (1,2,3,etc) will be the key that tells if today's move is significant or not. *Threshold referring to times standard deviation, and different market may require different threshold. *20 Days period are based on the Lookback Period, adjustable from user input window. █ Features - Scan up to 13 symbols at a time (Bursa (MYX) indices are defaulted, but you may change to any symbols/index from the user input setting) █ Limitation - Due to multiple use of security() function required to call other symbols, expect the screener to be slow at certain times - Custom Timeframe currently accept only Daily and Weekly. I'll try to include lower timeframe in the next update █ Disclaimer Past performance is not an indicator of future results. My opinions and research are my own and do not constitute financial advice in any way whatsoever. Nothing published by me constitutes an investment recommendation, nor should any data or Content published by me be relied upon for any investment/trading activities. I strongly recommends that you perform your own independent research and/or speak with a qualified investment professional before making any financial decisions. Any ideas to further improve this indicator are welcome :)
Indicador Pine Script™
por fareidzulkifli
18
Black-Scholes Options Pricing ModelThis is an updated version of my "Black-Scholes Model and Greeks for European Options" indicator, that i previously published. I decided to make this updated version open-source, so people can tweak and improve it. The Black-Scholes model is a mathematical model used for pricing options. From this model you can derive the theoretical fair value of an options contract. Additionally, you can derive various risk parameters called Greeks. This indicator includes three types of data: Theoretical Option Price (blue), the Greeks (green), and implied volatility (red); their values are presented in that order. 1) Theoretical Option Price: This first value gives only the theoretical fair value of an option with a given strike based on the Black-Scholes framework. Remember this is a model and does not reflect actual option prices, just the theoretical price based on the Black-Scholes model and its parameters and assumptions. 2)Greeks (all of the Greeks included in this indicator are listed below): a)Delta is the rate of change of the theoretical option price with respect to the change in the underlying's price. This can also be used to approximate the probability of your option expiring in the money. For example, if you have an option with a delta of 0.62, then it has about a 62% chance of expiring in-the-money. This number runs from 0 to 1 for Calls, and 0 to -1 for Puts. b)Gamma is the rate of change of delta with respect to the change in the underlying's price. c)Theta, aka "time decay", is the rate of change in the theoretical option price with respect to the change in time. Theta tells you how much an option will lose its value day by day. d) Vega is the rate of change in the theoretical option price with respect to change in implied volatility . e)Rho is the rate of change in the theoretical option price with respect to change in the risk-free rate. Rho is rarely used because it is the parameter that options are least effected by, it is more useful for longer term options, like LEAPs. f)Vanna is the sensitivity of delta to changes in implied volatility . Vanna is useful for checking the effectiveness of delta-hedged and vega-hedged portfolios. g)Charm, aka "delta decay", is the instantaneous rate of change of delta over time. Charm is useful for monitoring delta-hedged positions. h)Vomma measures the sensitivity of vega to changes in implied volatility . i)Veta measures the rate of change in vega with respect to time. j)Vera measures the rate of change of rho with respect to implied volatility . k)Speed measures the rate of change in gamma with respect to changes in the underlying's price. Speed can be used when evaluating delta-hedged and gamma hedged portfolios. l)Zomma measures the rate of change in gamma with respect to changes in implied volatility . Zomma can be used to evaluate the effectiveness of a gamma-hedged portfolio. m)Color, aka "gamma decay", measures the rate of change of gamma over time. This can also be used to evaluate the effectiveness of a gamma-hedged portfolio. n)Ultima measures the rate of change in vomma with respect to implied volatility . o)Probability of Touch, is not a Greek, but a metric that I included, which tells you the probability of price touching your strike price before expiry. 3) Implied Volatility: This is the market's forecast of future volatility . Implied volatility is directionless, it cannot be used to forecast future direction. All it tells you is the forecast for future volatility. How to use this indicator: 1st. Input the strike price of your option. If you input a strike that is more than 3 standard deviations away from the current price, the model will return a value of n/a. 2nd. Input the current risk-free rate.(Including this is optional, because the risk-free rate is so small, you can just leave this number at zero.) 3rd. Input the time until expiry. You can enter this in terms of days, hours, and minutes. 4th.Input the chart time frame you are using in terms of minutes. For example if you're using the 1min time frame input 1, 4 hr time frame input 480, daily time frame input 1440, etc. 5th. Pick what style of option you want data for, European Vanilla or Binary. 6th. Pick what type of option you want data for, Long Call or Long Put. 7th . Finally, pick which Greek you want displayed from the drop-down list. *Remember the Option price presented, and the Greeks presented, are theoretical in nature, and not based upon actual option prices. Also, remember the Black-Scholes model is just a model based upon various parameters, it is not an actual representation of reality, only a theoretical one. *Note 1. If you choose binary, only data for Long Binary Calls will be presented. All of the Greeks for Long Binary Calls are available, except for rho and vera because they are negligible. *Note 2. Unlike vanilla european options, the delta of a binary option cannot be used to approximate the probability of the option expiring in-the-money. For binary options, if you want to approximate the probability of the binary option expiring in-the-money, use the price. The price of a binary option can be used to approximate its probability of expiring in-the-money. So if a binary option has a price of $40, then it has approximately a 40% chance of expiring in-the-money. *Note 3. As time goes on you will have to update the expiry, this model does not do that automatically. So for example, if you originally have an option with 30 days to expiry, tomorrow you would have to manually update that to 29 days, then the next day manually update the expiry to 28, and so on and so forth. There are various formulas that you can use to calculate the Greeks. I specifically chose the formulations included in this indicator because the Greeks that it presents are the closest to actual options data. I compared the Greeks given by this indicator to brokerage option data on a variety of asset classes from equity index future options to FX options and more. Because the indicator does not use actual option prices, its Greeks do not match the brokerage data exactly, but are close enough. I may try to make future updates that include data for Long Binary Puts, American Options, Asian Options, etc.
Indicador Pine Script™
por SegaRKO
22
Screener - Mean Reversion Channel█ OVERVIEW This is Screener script for Mean Reversion Channel Indicator █ Description & How To Use The screener works by scanning through up to 40 symbols and list down symbols that are currently within Overbought/Oversold Zone as defined by Mean Reversion Channel indicator. The Overbought/Oversold Zone are further categorized and sorted by: Strong : Indicated by "(Strong)" next to the symbol name Normal : Indicated by the absence of "(Strong)" or "(Weak)" next to the symbol name Weak : Indicated by "(Weak)" next to the symbol name Notes: Refer to chart above to see how the Zone are categorized. Notes: If the screener displays "Nothing Interesting". It simply means none of the screened assets are within the Overbought/Oversold Zone. █ Features - Scan up to 40 symbols at a time (By default, no asset is define. Once configured all the symbols you required, remember to save as default to save you from pain of configuring it again in the future) - Options to scan by zones - Custom Timeframe █ Limitation Due to multiple use of security() function required to call other symbols, expect the screener to be slow at certain times █ Disclaimer Past performance is not an indicator of future results. My opinions and research are my own and do not constitute financial advice in any way whatsoever. Nothing published by me constitutes an investment recommendation, nor should any data or Content published by me be relied upon for any investment/trading activities. I strongly recommends that you perform your own independent research and/or speak with a qualified investment professional before making any financial decisions. Any ideas to further improve this indicator are welcome :) Credit: QuantNomad for his script idea on custom screener
Indicador Pine Script™
por fareidzulkifli
61
Divergence for Many Indicators v4Hello Traders, Here is my new year gift for the community, Digergence for Many Indicators v4 . I tried to make it modular and readable as much as I can. Thanks to Pine Team for improving Pine Platform all the time! How it works? - On each candle it checks divergences between current and any of last 16 Pivot Points for the indicators. - it search divergence on choisen indicators => RSI , MACD , MACD Histogram, Stochastic , CCI , Momentum, OBV, VWMACD, CMF and any External Indicator ! - it checks following divergences for 16 pivot points that is in last 100 bars for each Indicator. --> Regular Positive Digergences --> Regular Negative Digergences --> Hidden Positive Digergences --> Hidden Negative Digergences - for positive divergences first it checks if closing price is higher than last closing price and indicator value is higher than perious value, then start searching divergence - for negative divergences first it checks if closing price is lower than last closing price and indicator value is lower than perious value, then start searching divergence Some Options: Pivot Period: you set Pivot Period as you wish. you can see Pivot Points using "Show Pivot Points" option Source for Pivot Points: you can use Close or High/Low as source Divergence Type: you can choose Divergence type to be shown => "Regular", "Hidden", "Regular/Hidden" Show Indicator Names: you have different options to show indicator names => "Full", "First Letter", "Don't Show" Show Divergence Number: option to see number of indicators which has Divergence Show Only Last Divergence : if you enable this option then it shows only last Positive and Negative Divergences you can include any External Indicator to see if there is divergence - enable "Check External Indicator" - and then choose External indicator name in the list, "External Indicator" - External indicator name is shown as Extrn - related external indicator must be added before enabling this option Coloring, line width and line style options for different type of divergences. Following Alerts added: - Positive Regular Divergence Detected - Negative Regular Divergence Detected - Positive Hidden Divergence Detected - Negative Hidden Divergence Detected Now lets see some examples: Hidden Divergences: Regular and Hidden Divergences together: Showing first letters of indicators: You can see only the number of indicators which has divergence: You can see only divergence lines without indicators names and numbers: option to used different label/line/text colors: You have option to see only last divergences: You can change Pivot Period, in following example Pivot Period = 15: You can use Close or High/Low as Source for Divergence You can include external indicators and get divergences on it: Wish you all a happy new year! Enjoy!
Indicador Pine Script™
por LonesomeTheBlue
666
Daily Play Ace SpectrumSo the idea of the Daily Play Ace Spectrum is to extend the Ace Spectrum . By exposing more parameters, making a variation of the Ace Spectrum which is more configurable. The idea is this makes the Daily Play Ace Spectrum more suitable for use on shorter (hourly and minute) time scales. These specific parameters exposed still maintain the original form of the original Ace Spectrum, but loosen up the hard coded assumptions of the original indicator. By exposing more parameters this now makes the Daily Ace Spectrum more sensitive to input. Meaning the parameters you choose are important and will set the characteristic reaction of the indicator to the series you give it. This presents a trade-off, the simplicity of the original indicator is sacrificed. But what's gained is a more comprehensive indicator that now needs more careful parameter adjustment . Related to the Ace Spectrum:
Indicador Pine Script™
por sheganinans
10
MTF Oscillator Framework [PineCoders]This framework allows Pine coders to quickly build a complete multi-timeframe oscillator from any calculation producing values around a centerline, whether the values are bounded or not. Insert your calculation in the script and you have a ready-to-publish MTF Oscillator offering a plethora of presentation options and features. █  HOW TO USE THE FRAMEWORK 1 — Insert your calculation in the `f_signal()` function at the top of the "Helper Functions" section of the script. 2 — Change the script's name in the `study()` declaration statement and the `alertcondition()` text in the last part of the "Plots" section. 3 — Adapt the default value used to initialize the CENTERLINE constant in the script's "Constants" section. 4 — If you want to publish the script, copy/paste the following description in your new publication's description and replace the "OVERVIEW" section with a description of your calculations. 5 — Voilà! ═════════════════════════════════════════════════════════════════════════ █  OVERVIEW This oscillator calculates a directional value of True Range. When a bar is up, the positive value of True Range is used. A negative value is used when the bar is down. When there is no movement during the bar, a zero value is generated, even if True Range is different than zero. Because the unit of measure of True Range is price, the oscillator is unbounded (it does not have fixed upper/lower bounds). True Range can be used as a metric for volatility, but by using a signed value, this oscillator will show the directional bias of progressively increasing/decreasing volatility, which can make it more useful than an always positive value of True Range. The True Range calculation appeared for the first time in J. Welles Wilder's New Concepts in Technical Trading Systems book published in 1978. Wilder's objective was to provide a reliable measure of the effective movement—or range—between two bars, to measure volatility. True Range is also the building block used to calculate ATR (Average True Range), which calculates the average of True Range values over a given period using the `rma` averaging method—the same used in the calculation of another of Wilder's remarkable creations: RSI. █  CONCEPTS This oscillator's design stems from a few key concepts. Relative Levels Other than the centerline, relative rather than absolute levels are used to identify levels of interest. Accordingly, no fixed levels correspond to overbought/oversold conditions. Relative levels of interest are identified using:  • A Donchian channel (historical highs/lows).  • The oscillator's position relative to higher timeframe values.  • Oscillator levels following points in time where a divergence is identified. Higher timeframes Two progressively higher timeframes are used to calculate larger-context values for the oscillator. The rationale underlying the use of timeframes higher than the chart's is that, while they change less frequently than the values calculated at the chart's resolution, they are more meaningful because more work (trader activity) is required to calculate them. Combining the immediacy of values calculated at the chart's resolution to higher timeframe values achieves a compromise between responsiveness and reliability. Divergences as points of interest rather than directional clues A very simple interpretation of what constitutes a divergence is used. A divergence is defined as a discrepancy between any bar's direction and the direction of the signal line on that same bar. No attempt is made to attribute a directional bias to divergences when they occur. Instead, the oscillator's level is saved and subsequent movement of the oscillator relative to the saved level is what determines the bullish/bearish state of the oscillator. Conservative coloring scheme Several additive coloring conditions allow the bull/bear coloring of the oscillator's main line to be restricted to specific areas meeting all the selected conditions. The concept is built on the premise that most of the time, an oscillator's value should be viewed as mere noise, and that somewhat like price, it only occasionally conveys actionable information. █  FEATURES Plots  • Three lines can be plotted. They are named Main line , Line 2 and Line 3 . You decide which calculation to use for each line:    • The oscillator's value at the chart's resolution.    • The oscillator's value at a medium timeframe higher than the chart's resolution.    • The oscillator's value at the highest timeframe.    • An aggregate line calculated using a weighed average of the three previous lines (see the Aggregate Weights section of Inputs to configure the weights).  • The coloring conditions, divergence levels and the Hi/Lo channel always apply to the Main line, whichever calculation you decide to use for it.  • The color of lines 2 and 3 are fixed but can be set in the "Colors" section of Inputs.  • You can change the thickness of each line.  • When the aggregate line is displayed, higher timeframe values are only used in its calculation when they become available in the chart's history,   otherwise the aggregate line would appear much later on the chart. To indicate when each higher timeframe value becomes available,   a small label appears near the centerline.  • Divergences can be shown as small dots on the centerline.  • Divergence levels can be shown. The level and fill are determined by the oscillator's position relative to the last saved divergence level.  • Bull/bear markers can be displayed. They occur whenever a new bull/bear state is determined by the "Main Line Coloring Conditions".  • The Hi/Lo (Donchian) channel can be displayed, and its period defined.  • The background can display the state of any one of 11 different conditions.  • The resolutions used for the higher timeframes can be displayed to the right of the last bar's value.  • Four key values are always displayed in the Data Window (fourth icon down to the right of your chart):   oscillator values for the chart, medium and highest timeframes, and the oscillator's instant value before it is averaged. Main Line Coloring Conditions  • Nine different conditions can be selected to determine the bull/bear coloring of the main line. All conditions set to "ON" must be met to determine the bull/bear state.  • A volatility state can also be used to filter the conditions.  • When the coloring conditions and the filter do not allow for a bull/bear state to be determined, the neutral color is used. Signal  • Seven different averages can be used to calculate the average of the oscillator's value.  • The average's period can be set. A period of one will show the instant value of the oscillator,   provided you don't use linear regression or the Hull MA as they do not work with a period of one.  • An external signal can be used as the oscillator's instant value. If an already averaged external value is used, set the period to one in this indicator.  • For the cases where an external signal is used, a centerline value can be set. Higher Timeframes  • The two higher timeframes are named Medium timeframe and Highest timeframe . They can be determined using one of three methods:   • Auto-steps: the higher timeframes are determined using the chart's resolution. If the chart uses a seconds resolution, for example,    the medium and highest resolutions will be 15 and 60 minutes.   • Multiples: the timeframes are calculated using a multiple of the chart's resolution, which you can set.   • Fixed: the set timeframes do not change with the chart's resolution. Repainting  • Repainting can be controlled separately for the chart's value and the higher timeframe values.  • The default is a repainting chart value and non-repainting higher timeframe values. The Aggregate line will thus repaint by default,   as it uses the chart's value along with the higher timeframes values. Aggregate Weights  • The weight of each component of the Aggregate line can be set.  • The default is equal weights for the three components, meaning that the chart's value accounts for one third of the weight in the Aggregate. High Volatility  • This provides control over the volatility filter used in the Main line's coloring conditions and the background display.  • Volatility is determined to be high when the short-term ATR is greater than the long-term ATR. Colors  • You can define your own colors for all of the oscillator's plots.  • The default colors will perform well on both white and black chart backgrounds. Alerts  • An alert can be defined for the script. The alert will trigger whenever a bull/bear marker appears in the indicator's display.   The particular combination of coloring conditions and the display of bull/bear markers when you create the alert will thus determine when the alert triggers.   Once the alerts are created, subsequent changes to the conditions controlling the display of markers will not affect the existing alert(s).  • You can create multiple alerts from this script, each triggering on different conditions. Backtesting & Trading Engine Signal Line  • An invisible plot named "BTE Signal" is provided. It can be used as an entry signal when connected to the PineCoders Backtesting & Trading Engine as an external input.   It will generate an entry whenever a marker is displayed. Look first. Then leap.
Indicador Pine Script™
por PineCoders
17
Moving Average EntanglementThis script uses the gap in moving averages standardized to the average true range to determine entry and exit points. The red line represents the current percentage of ATR that is deemed "The Dead Zone" - a move that is too small to be reliable. The histogram represents the gap between moving averages. When the histogram is above the red line, it confirms a breakout move. The dashed line an be used as a secondary filter and is a moving average of the histogram. When Standard Deviation mode is on, a third line is displayed, which represents how many standard Deviations the current histogram bar represents, and can be also used as a filter.
Indicador Pine Script™
por jwammo12
24