Auto Phivots PP S/R Log /Lin V2 [DM]Greetings, I cover version two since the code has had great changes.
This script has two time frames with a separate symbol from the main window.
Alerts for the two different configurable time frames.
Van use for a big ranges or small and Log Scales.
The colors, extensions, thickness, style of the lines and the labels are completely configurable.
With a few small adjustments it can be used in a separate window with another symbol
Enjoy BigfOOts
Cari dalam skrip untuk "如何用wind搜索股票的发行价和份数"
TFO + ATR Strategy with Trailing Stop LossThis strategy is an experiment to learn what happens when The Trend Flex Oscillator (by Dr. John Ehlers) is used in conjunction with a volatility indicator like ATR. It was designed with cryptocurrency trading in mind.
The way I coded this experiment makes it unsuitable for bear market conditions.
When applied to a bull market, this trend-following strategy will open long positions when oversold price action appear to be reversing. It will typically close a position within a few days unless it gets caught in a bear market, in which case it holds on for dear life. I have tried to make back-testing very simple, but you should never trust it. It's merely and interesting tool for adjusting the many parameters that I've made editable in the configuration window. Those values include the ATR and TFO parameters, as well as setting a trailing stop loss. When closing a position, the strategy can optionally be told to ignore the trend analysis and only obey the trailing stop loss value. I've made an attempt to allow the user to define the minimum profit necessary to allow the strategy to close all all positions. In my observations, the 2H candlestick charts seem to produce the best results, although the parameters of the strategy could theoretically be adjusted to suit other time periods.
In summary...
This strategy has a bias for HODL (Holds on to Losses) meaning that it provides NO STOP LOSS protection!
Also note that the default behavior is designed for up to 15 open long orders, and executes one order to close them all at once.
Opening a long position is predicated on The Trend Flex Oscillator (TFO) rising after being oversold, and ATR above a certain volatility threshold.
Closing a long is handled either by TFO showing overbought while above a certain ATR level, or the Trailing Stop Loss. Pick one or both.
If the strategy is allowed to sell before a Trailing Stop Loss is triggered, you can set a "must exceed %". Do not mistake this for a stop loss.
Short positions are not supported in this version. Back-testing should NEVER be considered an accurate representation of actual trading results.
// portions © allanster (date window code)
// portions © Dr. John Ehlers (Trend Flex Oscillator)
This code is provided for educational purposes only. The results of this strategy should not be considered investment advice.
The user of this script acknowledges that it can result in serious financial loss when used as a trading tool
Scanner/Screener of Over 40 Coins Per Script I am very scatter-brained by nature and sporadic in my thought processes but if these benefit the community and ya'll ask for more perhaps I will get better and even out a tad....probably not....but you never know. Firstly, allow me to apologize to all the vet/more sophisticated coders out there whose eyes and brains might just be overly taxed due to my poor coding structure. Im just getting started for the first time in ANY sort of coding...so cut me a little slack. Also, if anyone sees any mistakes or the functionality is not as I proclaimed, PLEASE do let me know. In these past 12mo of me learning my 1st coding language (Pinescript) I would say that I have been intently focused on creating all types/sorts of scanners/screeners. Ive always hoped to be a benefit to the community as I was always SO grateful to those who have come before me that have led me to the little bit of progress I have made with Pinescript. This script is not necessarily something that should be traded with as it is just a thrown together example showing a scanner/screener whose results produce plot outputs (ie, Rate of Change / oscillators as well / etc) and how they can be used in the alert system so that only 1 alert has to be set per iteration of the script but more importantly how to use/scan/screen with over 40 coins per script. My intent is not to trick anyone here. So to be PERFECTLY CLEAR, more than 40 coins CAN in fact be screened/scanned from one script (here I am doing all of KUCOIN's Margin Coins...72 total I look at)...BUT...(heres the catch) it must be added to the chart however many times EQUAL to the amount of "sets" you have in your script. (Heres the limitation by TV) There cannot be more than 40 coins in each "set". The less coins you have per set, the quicker the script will startup and run, thus, the quicker alerts will be received if automating the process. Though, if you only have the free plan and can only have MAX 3 indicators per chart then the MAX you can screen at a time is 120 coins if you use 40 coins per set. So, this is the first one I would like to introduce. For this one your screener/scanner must be using some sort of plots as output that is being screened for. (original inspiration of ALL my variations mainly come from @QuantNomad, @daveatt, and @LonesomeTheBlue (and a few others I may be forgetting at the moment). Thanks for the inspiration through countless publications that ya'll have created for us in the community.
Some of my variations are more complex/elegant than others but there are MANY very different ones that I would like to share with the community. If you leave a comment and wonder why I have not responded but did so to every comment around yours...see if you are one of the individuals in this next few sentences...and if you are then perhaps someone else would like to waste their time responding to your comment...but basically, if you don't want to spend the time helping yourself by reading the title, description section, AND the comments section (at least scanning them) then I am MOST DEFINITELY not going to help you down your path of destruction that is most likely soon to be your blown-up trading account. I was called a "masochist" after asking for guidance on if its worth the headache to publish anything on TV bc there will NO DOUBT be comments that'll make me wish I didn't (ie. someone CLEARLY not reading the description (or seemingly even the title sometimes) bc they make a comment that has been explicitly addressed, or someone asking to rebuild the code compatible for another charting software or whatnot, or how about those asking if it repaints (this one is almost always addressed in the comments section but I can understand this question more than others as Im only 1 yr into learning any sort of coding for the first time in the beginning I saw people ask on EVERY script about if it repainted and it was worrisome at the lest (esp bc I didn't even understand what it was not so long ago, or my favorite...what TF it works best on...these people CLEARLY need not be trading yet if your still asking questions as such...Ill end it there). Point being, Ive got some truly VERY useful scripts that I want to share and as long as these people don't make me regret doing so in the beginning, then whats mine...will soon be yours. Though, I will take a little time between the releases.
YOU GUYS (TV and its community) ARE AWESOME (most of you anyways ;)
MUCH LOVE,
ChasinAlts
(1) INPUTS
Here is where the "sets" come in. I am looking at all of KUCOIN's Margin Coins (72 of them at least) so am splitting them up into 3 sets/iterations and a copy of the script must be added equal to amount of "sets" you have here. This is the ONLY workaround I have found to be able to scan/screen with more than 40 coins per script (due to TV's limitation of 40 Security Calls per script) ***So for everyone saying it's impossible scan more than 40 Coins per scipt...it' MOST DEFINITELY possible....BUT ONLY by adding this script multiple times on the chart and selecting 1 of each of the "sets" in the script settings via the chart window. To save the much needed room you must push each iteration of the script into 1 window and merging the scales of each into 1 scale(ie. "Scale A") within the settings of the script name on the chart(3 horizontal dots)
(2) FUNCTION
(2.1) COLORIDs
This is just to set up all my Colors of plots which are being matched with their respective labels. I have a diff color for each of the 72 coins Im plotting so Im telling the function, "depending on which set of coins I select...give me this color out of the colors I input later into the function"
(2.2) TICKERID CONSTRUCTION
I construct the tickerID this way so that the labels on my plots have only the Coin's name vs the label having the (Exchange Name):(Coin Name)(Base Pair Name). If you are using more than 1 Base pair (ie. XRP/BTC and XRP/USDT and XRP/ETH) OR more than 1 Exchange OR want your plots to show MORE THAN just the Trading Coin's name, then the tickerID MUST BE constructed differently
(2.3) SECURITY CALL & PLOT OUTPUT VARIABLES
If using a Higher Time Frame in Security Call then it MUST BE adjusted to permit or dissallow repainting if you so wish (BEYOND THE SCOPE OF THIS PUBLICATION so Do Your Own Researh). If your MAIN LOGIC is more complex than simply using a TV built-in function), THEN it MUST BE built into its own function outside of this function and called on within the "expression" slot of this Security Call OR can also be built into this function and called on in the "expression" slot of this Security call (BEYOND THE SCOPE OF THIS PUB SO DYOR). FURTHERMORE...when you are using a series(ie high/low/close/open/hl2/etc) / bar_index / time / etc that will be specific to the Coin/tickerID, then they MUST BE explicitly used within the "expression" slot of the Security Function when calling on your Main Logic or else it will pull the series/time/bar_index/etc from the Coin that the Chart is presently on (BEYOND THE SCOPE OF THIS PUB SO DYOR)
(2.4) PLOT LABEL
This is the Plot's Label that will be next to the end of the plot on the LAST bar_index. ***Notice in the "text" slot of the label I have "_coin" (without the quotes obviously)...this is where have JUST the Coin's name comes into effect on the label vs the (Exchange Name):(Coin Name)(Base Pair Name) which looks MUCH cleaner
(2.5) ALERT LOGIC / ALERT LABEL
Your alert logic need not be as complex as this... I just wanted to create a decent enough timing for this system and wanted to simply print the labels displaying which coin produced the alert at the same time the alerts would go off. Alert is set up to Trigger Bullish when the ROC is below the Threshold and _chg > _chg X=length of bars inputted in "Rising/Falling Length" setting and vise versa for Bearish Alerts. If _chg plot only goes past threshold for a VERY few amount of bars NOT providing enough time for initial Alert to trigger, then alert/label triggers on crossing of threshold back towards 0(zero). ONLY 1 alert needs to be set per script to be able to scan ALL 72 of the coins as I have them in this script. Timing of Alert is inline with the name label printed past the thresholds.
(3) VARIABLES FROM MAIN FUNCTION
This is the tuple of the Main Function that outputs the variables from 3 lines up to be able to plot the lines and color them according to the colors on the labels. *** As of now, we CANNOT plot from within the function so MUST BE done this way to produce the variables and colors needed. The plots are the ONLY thing in this script that cannot be executed from within the function
(4) LINE PLOTS
ALL output variables from our Main Function are used here for the line plots
TASC 2021.12 Directional Movement w/Hann█ OVERVIEW
Presented here is code for the "Directional Movement w/Hann" indicator originally conceived by John Ehlers. The code is also published in the December 2021 issue of Trader's Tips by Technical Analysis of Stocks & Commodities (TASC) magazine.
Ehlers continues here his exploration of the application of Hann windowing to conventional trading indicators.
█ FEATURES
The rolling length can be modified in the script's inputs, as well as the width of the line.
█ NOTES
Calculations
The calculation starts with the classic definition of PlusDM and MinusDM. These directional movements are summed in an exponential moving average (EMA). Then, this EMA is further smoothed in a finite impulse response (FIR) filter using Hann window coefficients over the calculation period.
Background
The DMI and ADX indicators were designed by J. Welles Wilder and presented in his "New Concepts in Technical Trading Systems" book published in 1978.
Join TradingView!
Ehlers Deviation Scaled Super Smoother [CC]The Deviation Scaled Super Smoother was created by John Ehlers and this is an excellent moving average that changes direction very quickly and can keep up with the current underlying trend. This indicator works by applying a Hann Windowed Moving Average to the stock's momentum and scaling that by the Root Mean Square and then using that value in the input for a Super Smoother . I have included strong buy and sell signals in addition to normal ones so lighter colors are normal signals and darker colors are strong ones. Buy when the line turns green and sell when it turns red.
Let me know if there are any other scripts you would like to see me publish!
Augmented Dickey–Fuller (ADF) mean reversion testThe augmented Dickey-Fuller test (ADF) is a statistical test for the tendency of a price series sample to mean revert .
The current price of a mean-reverting series may tell us something about the next move (as opposed, for example, to a geometric Brownian motion). Thus, the ADF test allows us to spot market inefficiencies and potentially exploit this information in a trading strategy.
Mathematically, the mean reversion property means that the price change in the next time period is proportional to the difference between the average price and the current price. The purpose of the ADF test is to check if this proportionality constant is zero. Accordingly, the ADF test statistic is defined as the estimated proportionality constant divided by the corresponding standard error.
In this script, the ADF test is applied in a rolling window with a user-defined lookback length. The calculated values of the ADF test statistic are plotted as a time series. The more negative the test statistic, the stronger the rejection of the hypothesis that there is no mean reversion. If the calculated test statistic is less than the critical value calculated at a certain confidence level (90%, 95%, or 99%), then the hypothesis of a mean reversion is accepted (strictly speaking, the opposite hypothesis is rejected).
Input parameters:
Source - The source of the time series being tested.
Length - The number of points in the rolling lookback window. The larger sample length makes the ADF test results more reliable.
Maximum lag - The maximum lag included in the test, that defines the order of an autoregressive process being implied in the model. Generally, a non-zero lag allows taking into account the serial correlation of price changes. When dealing with price data, a good starting point is lag 0 or lag 1.
Confidence level - The probability level at which the critical value of the ADF test statistic is calculated. If the test statistic is below the critical value, it is concluded that the sample of the price series is mean-reverting. Confidence level is calculated based on MacKinnon (2010) .
Show Infobox - If True, the results calculated for the last price bar are displayed in a table on the left.
More formal background:
Formally, the ADF test is a test for a unit root in an autoregressive process. The model implemented in this script involves a non-zero constant and zero time trend. The zero lag corresponds to the simple case of the AR(1) process, while higher order autoregressive processes AR(p) can be approached by setting the maximum lag of p. The null hypothesis is that there is a unit root, with the alternative that there is no unit root. The presence of unit roots in an autoregressive time series is characteristic for a non-stationary process. Thus, if there is no unit root, the time series sample can be concluded to be stationary, i.e., manifesting the mean-reverting property.
A few more comments:
It should be noted that the ADF test tells us only about the properties of the price series now and in the past. It does not directly say whether the mean-reverting behavior will retain in the future.
The ADF test results don't directly reveal the direction of the next price move. It only tells wether or not a mean-reverting trading strategy can be potentially applicable at the given moment of time.
The ADF test is related to another statistical test, the Hurst exponent. The latter is available on TradingView as implemented by balipour , QuantNomad and DonovanWall .
The ADF test statistics is a negative number. However, it can take positive values, which usually corresponds to trending markets (even though there is no statistical test for this case).
Rigorously, the hypothesis about the mean reversion is accepted at a given confidence level when the value of the test statistic is below the critical value. However, for practical trading applications, the values which are low enough - but still a bit higher than the critical one - can be still used in making decisions.
Examples:
The VIX volatility index is known to exhibit mean reversion properties (volatility spikes tend to fade out quickly). Accordingly, the statistics of the ADF test tend to stay below the critical value of 90% for long time periods.
The opposite case is presented by BTCUSD. During the same time range, the bitcoin price showed strong momentum - the moves away from the mean did not follow by the counter-move immediately, even vice versa. This is reflected by the ADF test statistic that consistently stayed above the critical value (and even above 0). Thus, using a mean reversion strategy would likely lead to losses.
[blackcat] L1 Fibonacci VWAP RSI IndicatorLevel: 1
Background
Ingo Bucher proposed "Fibonacci RSI" in March,2003. It describes the advantages of considering Fibonacci retracement levels for use with the classic RSI indicator. Bucher reviews six charts, each displaying Fibonacci retracement levels for the RSI associated with each chart. The pine code given here will allow you to automatically recreate these charts for any security available in Tradingview. BTW, i enhanced it by changing RSI into VWAP RSI with hl2.
Function
For this Fib VWAP RSI indicator, it also applicable for original Bucher's fib concept. Bucher calculated his retracement levels by picking the RSI high and low for a given time window. In his examples, these were generally six months to a year's worth of data. Once the high and low were picked, he calculated retracement levels based on the well-known Fibonacci numbers (23.6%, 38.2%, 50%, 61.8%). This script here does the same thing. I use a "LookbackLength" (default: 400 bars), which represents a sliding data window that is used to determine the VWAP RSI high and low. The second input value controls the VWAP RSI period (default: 14 bars). The next three inputs select the retracement levels.
A total of eight different lines need to be drawn: the RSI itself, the 50% line, two retracements above the 50% point, two retracements below, and the zero and 100% lines. Pine script will create four plotlines per indicator, so I advise inserting the Fibonacci RSI twice. The first time it is inserted, leave the PlotRSI input with its default value, true. True tells pine script to plot the VWAP RSI itself. The second copy should have the input "Plot RSI" set to false. This will put the 50% line on your chart.
Inputs
LookbackLength --> Look Back Length.
RSILength --> RSI Length.
Fib1 and Fib2 --> Fibonacci lengths.
Key Signal
RawVWAPRSI --> Raw VWAP RSI output signal
Remarks
This is a Level 1 free and open source indicator.
Feedbacks are appreciated.
Nadaraya-Watson Smoothers [LuxAlgo]The following tool smoothes the price data using various methods derived from the Nadaraya-Watson estimator, a simple Kernel regression method. This method makes use of the Gaussian kernel as a weighting function.
Users have the option to use a non-repainting as well as a repainting method, see the USAGE section for more information.
🔶 USAGE
🔹 Non Repainting
When Repainting Smoothing is disabled the returned indicator acts similarly to a regular causal moving average. This result could be described as an "endpoint Nadaraya-Watson estimator".
Unlike a regular moving average whose degree of smoothness is commonly determined by the length of its calculation window, the degree of smoothness of the proposed indicator is determined by the bandwidth setting, with a higher value returning smoother results.
In the above chart, a bandwidth value of 50 is used. An increasing value of the smoother is indicative of an uptrend, while a decreasing value is indicative of a downtrend.
🔹 Repainting
Non-causal smoothing methods have found low support from technical analysts because they tend to repaint. Yet, they can provide powerful insights such as estimating underlying trends in the price as well as seeing how far prices deviate from them. They can also make drawing certain patterns easier and can help see underlying structures in the price more clearly.
Using higher bandwidth values allows for estimating longer-term trends in the price.
Triangular labels highlight points where the direction of the estimator change. This allows for the identification of tops and bottoms in the underlying trend which can be compared to the actual price tops and bottoms.
Note that multiple labels can appear in real time, highlighting real-time changes in the estimator's direction. The most recent label on a series of labels is the first to appear. This can eventually be useful for the real-time predictive application of the estimator. However, it is not a usage we particularly recommend.
🔶 DETAILS
The Nadaraya-Watson estimator can be described as a series of weighted averages using a specific normalized kernel as a weighting function. For each point of the estimator at time t , the peak of the kernel is located at time t , as such the highest weights are attributed to values neighboring the price located at time t .
A lower bandwidth value would contribute toward a more important weighting of the price at a precise point and would as such less smooth results. In the case where our bandwidth is so small that the resulting kernel is just an impulse, we would get the raw price back.
However, when the bandwidth is sufficiently large, prices would be weighted similarly, thus resulting in a result closer to the price mean.
It can be interesting to note that due to the nature of the estimator and its weighting procedure, real-time results would not deviate drastically for points in the estimator near the center of the calculation window.
🔶 SETTINGS
Bandwidth : controls the bandwidth of the Gaussian kernel, with higher values returning smoother results.
Src : Input source of the kernel regression.
Repainting Smoothing : Determine if the smoothing method should repaint or not. If disabled the "endpoint Nadaraya-Watson estimator" is returned.
Trend ExplorerAre we in a bull or a bear market?
From the technical analysis point of view, the answer is "It depends". It depends from the parameters of your indicator, the timeframe of the pair you are looking and the volatility of that specific market you are looking to.
After I experimented with various trending indicators I decided to develop a framework that potentially could "embed" already existing logic from well known indicators (e.g. Supertrend OTT etc.).
The most important part is that I managed to abstract that logic away and experiment even further to produce some more robust, market and timeframe resolution agnostic results. While at the same time I was able to switch between market and timeframe resolution specific configuration to take some decision.
Finally, I decided to share this code with you folks! Developed this indicator "Trend Explorer" in an effort to make the aforementioned abstraction of all those trending indicators.
The goal is to enable the user to explore and combine different approaches in order to create a more robust and market general/specific, timeframe resolution invariant/fluctuating and volatility auto/manual adjusted indicator according to his needs.
The logic behind the abstraction is fairly simple. The trending indicator consists of two boundary lines the "bull trend low boundary" (green) and the "bear trend high boundary" (red). The indicator also has a control line (orange). Every time the control line crosses a boundary there is a trend reversal! The boundary lines are defined by the thresholds. To be more precise, boundaries are pulled upwards by thresholds (blue) during a bull market and downwards during a bear market. I challenge the user to experiment with the different ways of calculating the thresholds and the control. I am open to suggestions that might improve and extend the possibilities of this indicator. Any feedback, comments, general thoughts or bug reports are welcome.
Why did I chose those defaults?
For threshold calculation I chose MINMAX which calculates the local minimum and maximum using a sliding window. As far as I know it is not used in any existing trending indicator, but it seems reasonable for a trader to search for local min and max to make a decision. The width of the sliding window a.k.a the "period to remember" the local min and max is 30 days by default, just because I believe that for regular people it is a reasonable period of time to forget too.
Also, compared to the SUBADD method MINMAX does not seem to lag behind, especially when using averages in the SUBADD mode. Moreover, I consider MINMAX to be more general than the margins used by the SUBADD since margins should be configured based on the underlying market volatility.
For a source of min and max I chose the low and high values just because they are timeframe resolution invariant, meaning that they have the same (not exactly due to number precision and rounding, but very close) results for a single pair whether you use "4 hour" or "1 day" time interval! Another popular choice might be (close, close) since many traders wait for the daily candle to close in order to discard outliers. However, this approach is not resolution invariant and it depends from the time interval the user has selected.
Do you have any interesting trending indicator you would like to see how it performs in this framework logic? Let me know!
Do you have in mind any variation of Control or Thresholds calculation you would like to test? Please describe it in the comments below so I can add it in my implementation for you!
Did you find any other bug or you experienced any strange behavior? PM me with a description of the bug, the trading pair the timeframe resolution the exact time (candle) and all the necessary configurations for this indicator so I can reproduce it on my machine!
Please enjoy with caution,
Jason
Using `varip` variables [PineCoders]█ OVERVIEW
The new varip keyword in Pine can be used to declare variables that escape the rollback process, which is explained in the Pine User Manual's page on the execution model . This publication explains how Pine coders can use variables declared with varip to implement logic that was impossible to code in Pine before, such as timing events during the realtime bar, or keeping track of sequences of events that occur during successive realtime updates. We present code that allows you to calculate for how much time a given condition is true during a realtime bar, and show how this can be used to generate alerts.
█ WARNINGS
1. varip is an advanced feature which should only be used by coders already familiar with Pine's execution model and bar states .
2. Because varip only affects the behavior of your code in the realtime bar, it follows that backtest results on strategies built using logic based on varip will be meaningless,
as varip behavior cannot be simulated on historical bars. This also entails that plots on historical bars will not be able to reproduce the script's behavior in realtime.
3. Authors publishing scripts that behave differently in realtime and on historical bars should imperatively explain this to traders.
█ CONCEPTS
Escaping the rollback process
Whereas scripts only execute once at the close of historical bars, when a script is running in realtime, it executes every time the chart's feed detects a price or volume update. At every realtime update, Pine's runtime normally resets the values of a script's variables to their last committed value, i.e., the value they held when the previous bar closed. This is generally handy, as each realtime script execution starts from a known state, which simplifies script logic.
Sometimes, however, script logic requires code to be able to save states between different executions in the realtime bar. Declaring variables with varip now makes that possible. The "ip" in varip stands for "intrabar persist".
Let's look at the following code, which does not use varip :
//@version=4
study("")
int updateNo = na
if barstate.isnew
updateNo := 1
else
updateNo := updateNo + 1
plot(updateNo, style = plot.style_circles)
On historical bars, barstate.isnew is always true, so the plot shows a value of "1". On realtime bars, barstate.isnew is only true when the script first executes on the bar's opening. The plot will then briefly display "1" until subsequent executions occur. On the next executions during the realtime bar, the second branch of the if statement is executed because barstate.isnew is no longer true. Since `updateNo` is initialized to `na` at each execution, the `updateNo + 1` expression yields `na`, so nothing is plotted on further realtime executions of the script.
If we now use varip to declare the `updateNo` variable, the script behaves very differently:
//@version=4
study("")
varip int updateNo = na
if barstate.isnew
updateNo := 1
else
updateNo := updateNo + 1
plot(updateNo, style = plot.style_circles)
The difference now is that `updateNo` tracks the number of realtime updates that occur on each realtime bar. This can happen because the varip declaration allows the value of `updateNo` to be preserved between realtime updates; it is no longer rolled back at each realtime execution of the script. The test on barstate.isnew allows us to reset the update count when a new realtime bar comes in.
█ OUR SCRIPT
Let's move on to our script. It has three parts:
— Part 1 demonstrates how to generate alerts on timed conditions.
— Part 2 calculates the average of realtime update prices using a varip array.
— Part 3 presents a function to calculate the up/down/neutral volume by looking at price and volume variations between realtime bar updates.
Something we could not do in Pine before varip was to time the duration for which a condition is continuously true in the realtime bar. This was not possible because we could not save the beginning time of the first occurrence of the true condition.
One use case for this is a strategy where the system modeler wants to exit before the end of the realtime bar, but only if the exit condition occurs for a specific amount of time. One can thus design a strategy running on a 1H timeframe but able to exit if the exit condition persists for 15 minutes, for example. REMINDER: Using such logic in strategies will make backtesting their complete logic impossible, and backtest results useless, as historical behavior will not match the strategy's behavior in realtime, just as using `calc_on_every_tick = true` will do. Using `calc_on_every_tick = true` is necessary, by the way, when using varip in a strategy, as you want the strategy to run like a study in realtime, i.e., executing on each price or volume update.
Our script presents an `f_secondsSince(_cond, _resetCond)` function to calculate the time for which a condition is continuously true during, or even across multiple realtime bars. It only works in realtime. The abundant comments in the script hopefully provide enough information to understand the details of what it's doing. If you have questions, feel free to ask in the Comments section.
Features
The script's inputs allow you to:
• Specify the number of seconds the tested conditions must last before an alert is triggered (the default is 20 seconds).
• Determine if you want the duration to reset on new realtime bars.
• Require the direction of alerts (up or down) to alternate, which minimizes the number of alerts the script generates.
The inputs showcase the new `tooltip` parameter, which allows additional information to be displayed for each input by hovering over the "i" icon next to it.
The script only displays useful information on realtime bars. This information includes:
• The MA against which the current price is compared to determine the bull or bear conditions.
• A dash which prints on the chart when the bull or bear condition is true.
• An up or down triangle that prints when an alert is generated. The triangle will only appear on the update where the alert is triggered,
and unless that happens to be on the last execution of the realtime bar, it will not persist on the chart.
• The log of all triggered alerts to the right of the realtime bar.
• A gray square on top of the elapsed realtime bars where one or more alerts were generated. The square's tooltip displays the alert log for that bar.
• A yellow dot corresponding to the average price of all realtime bar updates, which is calculated using a varip array in "Part 2" of the script.
• Various key values in the Data Window for each parts of the script.
Note that the directional volume information calculated in Part 3 of the script is not plotted on the chart—only in the Data Window.
Using the script
You can try running the script on an open market with a 30sec timeframe. Because the default settings reset the duration on new realtime bars and require a 20 second delay, a reasonable amount of alerts will trigger.
Creating an alert on the script
You can create a script alert on the script. Keep in mind that when you create an alert from this script, the duration calculated by the instance of the script running the alert will not necessarily match that of the instance running on your chart, as both started their calculations at different times. Note that we use alert.freq_all in our alert() calls, so that alerts will trigger on all instances where the associated condition is met. If your alert is being paused because it reaches the maximum of 15 triggers in 3 minutes, you can configure the script's inputs so that up/down alerts must alternate. Also keep in mind that alerts run a distinct instance of your script on different servers, so discrepancies between the behavior of scripts running on charts and alerts can occur, especially if they trigger very often.
Challenges
Events detected in realtime using variables declared with varip can be transient and not leave visible traces at the close of the realtime bar, as is the case with our script, which can trigger multiple alerts during the same realtime bar, when the script's inputs allow for this. In such cases, elapsed realtime bars will be of no use in detecting past realtime bar events unless dedicated code is used to save traces of events, as we do with our alert log in this script, which we display as a tooltip on elapsed realtime bars.
█ NOTES
Realtime updates
We have no control over when realtime updates occur. A realtime bar can open, and then no realtime updates can occur until the open of the next realtime bar. The time between updates can vary considerably.
Past values
There is no mechanism to refer to past values of a varip variable across realtime executions in the same bar. Using the history-referencing operator will, as usual, return the variable's committed value on previous bars. If you want to preserve past values of a varip variable, they must be saved in other variables or in an array .
Resetting variables
Because varip variables not only preserve their values across realtime updates, but also across bars, you will typically need to plan conditions that will at some point reset their values to a known state. Testing on barstate.isnew , as we do, is a good way to achieve that.
Repainting
The fact that a script uses varip does not make it necessarily repainting. A script could conceivably use varip to calculate values saved when the realtime bar closes, and then use confirmed values of those calculations from the previous bar to trigger alerts or display plots, avoiding repaint.
timenow resolution
Although the variable is expressed in milliseconds it has an actual resolution of seconds, so it only increments in multiples of 1000 milliseconds.
Warn script users
When using varip to implement logic that cannot be replicated on historical bars, it's really important to explain this to traders in published script descriptions, even if you publish open-source. Remember that most TradingViewers do not know Pine.
New Pine features used in this script
This script uses three new Pine features:
• varip
• The `tooltip` parameter in input() .
• The new += assignment operator. See these also: -= , *= , /= and %= .
Example scripts
These are other scripts by PineCoders that use varip :
• Tick Delta Volume , by RicadoSantos .
• Tick Chart and Volume Info from Lower Time Frames by LonesomeTheBlue .
Thanks
Thanks to the PineCoders who helped improve this publication—especially to bmistiaen .
Look first. Then leap.
Robust Channel [tbiktag]Introducing the Robust Channel indicator.
This indicator is based on a remarkable property of robust statistics , namely, the resistance to the presence of data points that deviate significantly from the established trend (generally speaking, outliers ). Being outlier-resistant, the Robust Channel indicator “remembers” a pre-existing trend and thus exhibits a very peculiar "lag" in case of a sharp price change. This allows high-confidence identification of such price actions as a trend reversal, range break, pullback, etc.
In the case of trending and range-bound market conditions, the price remains within the channel most of the time, fluctuating around the central line.
Technical details
The central line is calculated using the repeated median slope algorithm. For each data point in a lookback window of a user-specified Length , this method calculates the median slope of the lines that connect that point to all other points inside the window. The overall median of these median slopes is then calculated and used as an estimate of the trend slope. The algorithm is very efficient as it uses an on-the-fly procedure to update the array containing the slopes (new data pushed - old data removed).
The outer line is then calculated as the central line plus the Length -period standard deviation of the price data multiplied by a user-defined Channel Width Factor . The inner line is defined analogously below the central line.
Usage
As a stand-alone indicator, the Robust Channel can be applied similarly to the Bollinger Bands and the Keltner Channel:
A close above the outer line can be interpreted as a bullish signal and a close below the inner line as a bearish signal.
Likewise, a return to the channel from below after a break may serve as a bullish signal, while a return from above may indicate bearish sentiment.
Robust Channel can be also used to confirm chart patterns such as double tops and double bottoms.
If you like this indicator, feel free to leave your feedback in the comments below!
[blackcat] L2 Ehlers DFT-Adapted RSILevel: 2
Background
John F. Ehlers introuced his DFT-ADAPTED RELATIVE STRENGTH INDEX (RSI) in Jan, 2007.
Function
In "Fourier Transform For Traders" in Jan, 2007, John Ehlers presented an interesting technique of improving the resolution of spectral analysis that could be used to effectively measure market cycles. Better resolution is obtained by a surprisingly simple modification of the discrete Fourier transform. John Ehlers suggests using the discrete Fourier transform (DFT) to tune indicators. Here, I demonstrate this by building a DFT-adapted relative strength index (RSI) strategy.
Rather than display the RSI for a single cycle length across the entire chart, Ehlers DFT adaptive RSI value reflects the DFT-calculated dominant cycle length RSI. If the dominant cycle changes from 14 to 18 bars, the RSI length parameter changes accordingly. Computationally, this requires the strategy to continuously update values for all possible RSI cycle lengths via a "for" loop and array.
In details, a full-featured formula that implements a high-pass filter (HP) and a six-tap low-pass finite impulse response (FIR) filter on input, then does discrete Fourier transform calculations. I has taken liberty of adding extra parameters so the user can modify the analysis window length and the high-pass filter cutoff frequency in real time using the parameters window. Once the suite of possible RSI values is calculated, we use the DFT to select the relevant RSI for the current bar. The strategy then trades according to J. Welles Wilder's original rules for the RSI.
Key Signal
fastline--> DFT-ADAPTED RELATIVE STRENGTH INDEX (RSI) fast line
slowline--> DFT-ADAPTED RELATIVE STRENGTH INDEX (RSI) slow line
Pros and Cons
100% John F. Ehlers definition translation, even variable names are the same. This help readers who would like to use pine to read his book.
Remarks
The 71th script for Blackcat1402 John F. Ehlers Week publication.
Based on original work of Ehlers, I added ALMA smoothing on DFT-adapted relative strength index (RSI) so that clearer trend can be observed.
Readme
In real life, I am a prolific inventor. I have successfully applied for more than 60 international and regional patents in the past 12 years. But in the past two years or so, I have tried to transfer my creativity to the development of trading strategies. Tradingview is the ideal platform for me. I am selecting and contributing some of the hundreds of scripts to publish in Tradingview community. Welcome everyone to interact with me to discuss these interesting pine scripts.
The scripts posted are categorized into 5 levels according to my efforts or manhours put into these works.
Level 1 : interesting script snippets or distinctive improvement from classic indicators or strategy. Level 1 scripts can usually appear in more complex indicators as a function module or element.
Level 2 : composite indicator/strategy. By selecting or combining several independent or dependent functions or sub indicators in proper way, the composite script exhibits a resonance phenomenon which can filter out noise or fake trading signal to enhance trading confidence level.
Level 3 : comprehensive indicator/strategy. They are simple trading systems based on my strategies. They are commonly containing several or all of entry signal, close signal, stop loss, take profit, re-entry, risk management, and position sizing techniques. Even some interesting fundamental and mass psychological aspects are incorporated.
Level 4 : script snippets or functions that do not disclose source code. Interesting element that can reveal market laws and work as raw material for indicators and strategies. If you find Level 1~2 scripts are helpful, Level 4 is a private version that took me far more efforts to develop.
Level 5 : indicator/strategy that do not disclose source code. private version of Level 3 script with my accumulated script processing skills or a large number of custom functions. I had a private function library built in past two years. Level 5 scripts use many of them to achieve private trading strategy.
Daily GAP StatsI did not write the script from scratch but rather started editing code of an existing one. The original code came from a script called GAP DETECTOR by @Asch-
First up: I am a trader, not a programmer and therefore my code most likely is inefficient. If someone with more expertise would like to help and optimize it - feel free to get in touch, I am always happy to learn some new tricks. :)
This script does 2 things:
- It shows daily gaps stats based on user inputs
- It shows color coded labels on gap days with additional information in tooltips ( important: make sure to read 'known issues/limitations' at the end )
User Inputs
==========
Although the input dialog is pretty straight forward, I do a quick rundown:
- Length: max lookback time
- Gap Direction: self explanatory
- Show All Gaps | Cont Only | Reversal Only | Off:
This refers to the way labels are displayed on gap days (again: make sure to read known issues/limitations!)
- Show All Gaps: does what it says
- Cont Only: only shows gaps where price continued in the gap direction. If you filter for gap ups and chose 'Cont only' you will only see labels on gap days where price closed above the open (and vice versa if you scan for gap downs).
- Reversal Only: you will only see labels for closes below the open on gap up days (and the opposite on gap down days)
- Off: self explanatory
- Gap Measure in ATR/PCT: self explanatory, ATR is calculated over a 10d period
- Gap Size (Abs Values): no negative values allowed here. If you filter for gap downs and enter 3 it means it will show gaps where the stock fell more than 3 ATR/PCT on the open.
- RVOL Factor: along with significant gaps should come significant volume. RVOL = volume of the gap day / 20d average volume
- Viewing Options: Placing the stats label in the window is a bit tricky (see knonw issues/limitations) and I was not sure which way I liked better. See for yourself what works best for you.
Known Isusses/Limitations:
=======================
- Positioning of the stats table:
As to my knowledge, Tradingview only allows label positioning relative to price and not relative to the chart window. I tried to always display the gap stats table in the upper right corner, using 52wk high as y-coordinate. This works ok most of the time, but is not pretty. If anybody has some fancy way to tag the label in a fixed position, please get in touch.
- Max number of labels per script:
TradingView has a limitation that allows a maxium of ~50 labels per script. If there are more labels, TradingView will automatically cut the oldest ones, without any notification. I have found this behaviour to be rather inconsistent - sometimes it'll dump labels even if there are a lot fewer than 50. Hopefully TradingView will drop this limitation at one point in the future.
Important: The inconsistent display of the gap day labels has NO INFLUENCE on the calculations in the gap stats table - the count and the calculations are complete and correct!
sDEFI Synthetix ExchangeTradingView allows combining/summing up to a maximum of only 10 tickers in its search field. Their support staff suggested I could combine up to 40 by using Pine Script, so here it is, for a specific 'basket' of crypto tokens.
This study displays the combination of price history for Synthetix Exchange’s sDEFI index.
Tokens included in the index are COMP, MKR, KNC, SNX, ZRX, REP, LEND, REN, LRC, BNT, BAL and UMA. You will see the prices only go back as far as July 31st 2020, which is when the most recent of the compilation (UMA) started its trading history on TradingView. (The study can only display prices for days that *all* the tickers were trading.)
The price history will display as a study, below an existing chart. You will need to resize the windows, to see this study at a larger size. (Grab the window border and move it up, once you have added this study to a chart)
Unfortunately you will not be able to interact with it like a normal chart, i.e. drawing trendlines, adding moving averages, notes or annotations, etc.
May I suggest you send a support request to TradingView, asking for them to allow us to enter more than 10 (perhaps up to 40) tickers with + symbol between them, in the search field, which gives a ‘proper’ chart to analyse?
Please note that when publishing this script, I was required to choose a category from a list that does not contain a relevant category. Given that I had to choose something from the list to proceed, I used 'Support and Resistance', since chartists can see S and R levels by looking at this study.
I trust this study is useful for you sDEFI traders.
SCANNER SCREENER ANALYSIS SIGNAL EXPLORER DASHBOARDNew Buy signal: light green color
New Sell signal: light red color
Bullish dark green condition
Brearish dark red condition
Set your trend strategy in settings.
You can watch 20 pair in one indicator. Add more indicator panel and move same window and watch more signals in the same window. Set X axis cordinates 0-25-50-75-100-125-150-175-200 etc.for not overlap
You can add your favorite stocks, fx, crypto and analys for buy and sell signal.
When change the time frame new signal show on your selected time frame
it shows profit and signal price.
Look and review my other amazing indicator. It is best on TVs.
For Access and try my other best quality indicators till 7 days, message me. You can monthly subscribe my scripts my google play app on my profile or sent (30 USD) btc my bitcoin adress.
SMA Sell SignalThis is a basic visual showing a sell-signal based on two simple moving averages, intended for daily chart on individual stocks. Two plots show the percent gap of the closing price from the 50d and 10d simple moving averages. A threshold is set for 20% above the 50d and 2% below the 10d.
The sell signal is determined when a stock rises 20% above the 50d simple moving average, and then drops 2% below the 10d moving average within a 10 day window. The moving average, thresholds and window are all configurable.
The sell signal often aligns to an MACD sell signal, however this visualizes the more specific rule as described above.
Nth Order Differencing Oscillator Perform higher order differencing through convolution, the result is equivalent to cascading N momentum oscillators of periods P :
mom(mom(mom(mom(x,P)...,P)
Settings
length - Period of the oscillator, indicate the lag to use (equivalent to the period in a momentum oscillator)
order - Differencing order, indicate how many times differencing is performed (number of times a momentum oscillator is cascaded)
src - Input of the indicator
Usage
Differencing consists in subtracting an input to a previous input, this is what the momentum oscillator performs. This is often done in order to remove longer-term variations in the price. Differencing also induces a 90-degree phase shift for all sinusoids in a signal, this is why oscillators can have this leading effect, as such higher differencing can sometimes help have a faster and more visible lead.
In red the indicator with period 50 and differencing order 2, below a momentum oscillator of the same period.
It is important to note that differencing is an operation that increases noise, in fact, you might have seen some oscillators use the median price hl2 instead of the closing price, this is because the median price contains less noise than the closing price, as such more differencing require a smoother input.
Here both the sma and the oscillator period are equal to 20 with a differencing order of 5.
In time series analysis the order of differencing is chosen depending on the order of integration, more simply put we should choose a differencing order that responds to the question: "How many time should I differentiate my time series so that the result is stationary?", for stocks prices this differencing order should be 1.
Technically speaking differencing orders higher than 3 might be overkill, as higher orders return noisier outputs that might no longer be representative of the original input.
here a period of 14 with differencing order of 20 is used, we can see more periodic results but they are not really representative of the closing prices.
Details
Simple differencing is actually achieved thought convolution, if we take a first-order difference x - x(1) , we can see that this is equivalent to 1*x + -1*x(1) , the coefficients are 1 and -1, for the momentum oscillator the difference is that the coefficients include 0 values. So we only need a function generating the coefficients of our Nth order difference oscillator, in order to get them lets analyze the impulse response of a cascaded change function.
Here 5 change function are cascaded, the coefficients are: (1,-5,10,-10,5,-1)
If you look at these coefficients and the ones of higher/lower order differences we can deduce various things
The impulse response is symmetric
The first coefficient is always 1 and the last always -1
The number of coefficients increase with higher differencing orders
The sign of the current coefficient is different from the sign of the previous one
From the shape of the impulse response, we can deduce that the coefficients of an Nth order differencing operator is a windowed series of 1,-1,1...,-1 , and that's actually the case, for an Nth order differencing operator the values of this window are given by the Nth row of the Pascal triangle.
There are various ways to get the values in the row of the Pascal triangle, one involving using the combination formula, however, we can do it way faster by using the recursive formula used in line number 13. Now that we have our coefficients we only need to separate them with 0 values and that's all.
Conclusion
We can see that oscillators are noisier than the original input signal, this is can be a desired effect in order to make lagging indicators more reactive, but it can also be overlooked due to the results appearing leading the price or just looking more predictable, however, we should note that higher-order differencing does not provide a consistent nor reliable solution toward minimizing lag, nor does classical oscillators.
The indicator is not useful, but if for some reason you require a lot of differencing operations to be done and don't want to use consecutive change or mom functions, then this script might results useful to you.
Backtesting on Non-Standard Charts: Caution! - PineCoders FAQMuch confusion exists in the TradingView community about backtesting on non-standard charts. This script tries to shed some light on the subject in the hope that traders make better use of those chart types.
Non-standard charts are:
Heikin Ashi (HA)
Renko
Kagi
Point & Figure
Range
These chart types are called non-standard because they all transform market prices into synthetic views of price action. Some focus on price movement and disregard time. Others like HA use the same division of bars into fixed time intervals but calculate artificial open, high, low and close (OHLC) values.
Non-standard chart types can provide traders with alternative ways of interpreting price action, but they are not designed to test strategies or run automated traded systems where results depend on the ability to enter and exit trades at precise price levels at specific times, whether orders are issued manually or algorithmically. Ironically, the same characteristics that make non-standard chart types interesting from an analytical point of view also make them ill-suited to trade execution. Why? Because of the dislocation that a synthetic view of price action creates between its non-standard chart prices and real market prices at any given point in time. Switching from a non-standard chart price point into the market always entails a translation of time/price dimensions that results in uncertainty—and uncertainty concerning the level or the time at which orders are executed is detrimental to all strategies.
The delta between the chart’s price when an order is issued (which is assumed to be the expected price) and the price at which that order is filled is called slippage . When working from normal chart types, slippage can be caused by one or more of the following conditions:
• Time delay between order submission and execution. During this delay the market may move normally or be subject to large orders from other traders that will cause large moves of the bid/ask levels.
• Lack of bids for a market sell or lack of asks for a market buy at the current price level.
• Spread taken by middlemen in the order execution process.
• Any other event that changes the expected fill price.
When a market order is submitted, matching engines attempt to fill at the best possible price at the exchange. TradingView strategies usually fill market orders at the opening price of the next candle. A non-standard chart type can produce misleading results because the open of the next candle may or may not correspond to the real market price at that time. This creates artificial and often beneficial slippage that would not exist on standard charts.
Consider an HA chart. The open for each candle is the average of the previous HA bar’s open and close prices. The open of the HA candle is a synthetic value, but the real market open at the time the new HA candle begins on the chart is the unrelated, regular open at the chart interval. The HA open will often be lower on long entries and higher on short entries, resulting in unrealistically advantageous fills.
Another example is a Renko chart. A Renko chart is a type of chart that only measures price movement. The purpose of a Renko chart is to cluster price action into regular intervals, which consequently removes the time element. Because Trading View does not provide tick data as a price source, it relies on chart interval close values to construct Renko bricks. As a consequence, a new brick is constructed only when the interval close penetrates one or more brick thresholds. When a new brick starts on the chart, it is because the previous interval’s close was above or below the next brick threshold. The open price of the next brick will likely not represent the current price at the time this new brick begins, so correctly simulating an order is impossible.
Some traders have argued with us that backtesting and trading off HA charts and other non-standard charts is useful, and so we have written this script to show traders what happens when order fills from backtesting on non-standard charts are compared to real-world fills at market prices.
Let’s review how TV backtesting works. TV backtesting uses a broker emulator to execute orders. When an order is executed by the broker emulator on historical bars, the price used for the fill is either the close of the order’s submission bar or, more often, the open of the next. The broker emulator only has access to the chart’s prices, and so it uses those prices to fill orders. When backtesting is run on a non-standard chart type, orders are filled at non-standard prices, and so backtesting results are non-standard—i.e., as unrealistic as the prices appearing on non-standard charts. This is not a bug; where else is the broker emulator going to fetch prices than from the chart?
This script is a strategy that you can run on either standard or non-standard chart types. It is meant to help traders understand the differences between backtests run on both types of charts. For every backtest, a label at the end of the chart shows two global net profit results for the strategy:
• The net profits (in currency) calculated by TV backtesting with orders filled at the chart’s prices.
• The net profits (in currency) calculated from the same orders, but filled at market prices (fetched through security() calls from the underlying real market prices) instead of the chart’s prices.
If you run the script on a non-standard chart, the top result in the label will be the result you would normally get from the TV backtesting results window. The bottom result will show you a more realistic result because it is calculated from real market fills.
If you run the script on a normal chart type (bars, candles, hollow candles, line, area or baseline) you will see the same result for both net profit numbers since both are run on the same real market prices. You will sometimes see slight discrepancies due to occasional differences between chart prices and the corresponding information fetched through security() calls.
Features
• Results shown in the Data Window (third icon from the top right of your chart) are:
— Cumulative results
— For each order execution bar on the chart, the chart and market previous and current fills, and the trade results calculated from both chart and market fills.
• You can choose between 2 different strategies, both elementary.
• You can use HA prices for the calculations determining entry/exit conditions. You can use this to see how a strategy calculated from HA values can run on a normal chart. You will notice that such strategies will not produce the same results as the real market results generated from HA charts. This is due to the different environment backtesting is running on where for example, position sizes for entries on the same bar will be calculated differently because HA and standard chart close prices differ.
• You can choose repainting/non-repainting signals.
• You can show MAs, entry/exit markers and market fill levels.
• You can show candles built from the underlying market prices.
• You can color the background for occurrences where an order is filled at a different real market price than the chart’s price.
Notes
• On some non-standard chart types you will not obtain any results. This is sometimes due to how certain types of non-standard types work, and sometimes because the script will not emit orders if no underlying market information is detected.
• The script illustrates how those who want to use HA values to calculate conditions can do so from a standard chart. They will then be getting orders emitted on HA conditions but filled at more realistic prices because their strategy can run on a standard chart.
• On some non-standard chart types you will see market results surpass chart results. While this may seem interesting, our way of looking at it is that it points to how unreliable non-standard chart backtesting is, and why it should be avoided.
• In order not to extend an already long description, we do not discuss the particulars of executing orders on the realtime bar when using non-standard charts. Unless you understand the minute details of what’s going on in the realtime bar on a particular non-standard chart type, we recommend staying away from this.
• Some traders ask us: Why does TradingView allow backtesting on non-standard chart types if it produces unrealistic results? That’s somewhat like asking a hammer manufacturer why it makes hammers if hammers can hurt you. We believe it’s a trader’s responsibility to understand the tools he is using.
Takeaways
• Non-standard charts are not bad per se, but they can be badly used.
• TV backtesting on non-standard charts is not broken and doesn’t require fixing. Traders asking for a fix are in dire need of learning more about trading. We recommend they stop trading until they understand why.
• Stay away from—even better, report—any vendor presenting you with strategies running on non-standard charts and implying they are showing reliable results.
• If you don’t understand everything we discussed, don’t use non-standard charts at all.
• Study carefully how non-standard charts are built and the inevitable compromises used in calculating them so you can understand their limitations.
Thanks to @allanster and @mortdiggiddy for their help in editing this description.
Look first. Then leap.
%G OscillatorIntroduction
Rescaling often involve bringing a series of values in a certain range, there have been many rescaling methods proposed in technical analysis such as the stochastic oscillator, relative strength index or the William %R to name a few. Rescaling the price allow the user to see when the security is overbought or oversold, in the case of the stochastic oscillator it can also determine the price position relative to the highest and lowest price over a user defined period window.
Computing highest and lowest over a certain period window involve calculating what is called a rolling maximum/minimum, those calculations have tried to be efficient but they can still remain relatively complex. This is why i propose a similar rescaling indicator that don't use rolling maximum/minimum for its calculation, the indicator can be interpreted like the stochastic oscillator since they are similar.
The Indicator
The indicator is based on the current price position relative to past observations, for example, if the indicator is equal to 80, this mean that the current price is greater than 80% of the k past observations, where k = 1, 2, 3...length .
The indicator offer many benefits such as a custom rescaling range, unlike the stochastic oscillator this step is directly integrated in the core calculations of the indicator, this can be done by changing the code in line 7 :
a = src > src ? Max : Min
where Max should be the maximum value of the indicator and Min the minimum value, therefore the indicator would lay in a range of (Max,Min).
here the indicator is in a range of (5,2), this mean that :
a = src > src ? 5 : 2
Conclusion
I proposed an alternative to the stochastic oscillator. Both indicators return similar results, advantages of the proposed indicators are its simple calculation and its ability to return custom ranges. I hope it find its use in the community.
Thanks for reading !
Klinger Safety ZonesThis indicator is based on the Klinger Volume Oscillator, or KVO. The KVO is pretty cool since it can track long-term changes in money flow (both into and out of a market), as well as respond and predict short term price fluctuations.
The Klinger Oscillator determines the direction (or trend) of money flow based on the high, low, and closing price of the security. It then compares all three values (HLC/3) to the previous period’s values to determine how volume should be factored into the KVO. If the current period’s price is greater than that of the previous period, then volume is added. It is subtracted, however, if the price is less than the previous period. This utilization of volume is what makes it an accurate tracker of money flow and a valuable confirmation indicator. This value is often called volume force or the “trend” line.
A fast and slow EMA of the volume force are then calculated. The fast EMA has a smaller window length, while the slow EMA has a larger window. Traders can adjust the lengths of each EMA in the input option menu, but we chose the standard 55 and 34 period lengths as the default settings. We are finally left with the actual KVO value after subtracting the slow EMA from the fast EMA.
The Klinger Oscillator uses a signal line similar to the MACD and many other indicators. The default length for it is 13, but that length can also be adjusted in the input menu. A shorter length will result in more responsiveness but possibly more false signals and whipsaws.
The Chart and Interpretation:
The histogram shows the KVO series. Remember, since the Oscillator represents the difference between the fast and slow EMA, the KVO is bullish when it is greater than zero and bearish when it is less than zero.
When the KVO is greater than zero, the background on the chart is green, meaning that the trend is bullish and traders should look to go long. On the flip side, the background is red when the KVO is less than zero meaning traders should look to go short.
The aqua line plotted on top of the histogram is the signal line.
Here is a quick summary of the histogram colors:
(if KVO > 0 and KVO > signal)
then (color = teal)
if (KVO > 0 and KVO < signal)
then (color = lime)
if (KVO < 0 and KVO < signal)
then (color = red)
if (KVO < 0 and KVO > signal)
then (color = pink)
Users can choose to have the candles change color to match the KVO histogram color by adjusting the setting in the input menu.
~Happy (and safe) trading~
Well Rounded Moving AverageIntroduction
There are tons of filters, way to many, and some of them are redundant in the sense they produce the same results as others. The task to find an optimal filter is still a big challenge among technical analysis and engineering, a good filter is the Kalman filter who is one of the more precise filters out there. The optimal filter theorem state that : The optimal estimator has the form of a linear observer , this in short mean that an optimal filter must use measurements of the inputs and outputs, and this is what does the Kalman filter. I have tried myself to Kalman filters with more or less success as well as understanding optimality by studying Linear–quadratic–Gaussian control, i failed to get a complete understanding of those subjects but today i present a moving average filter (WRMA) constructed with all the knowledge i have in control theory and who aim to provide a very well response to market price, this mean low lag for fast decision timing and low overshoots for better precision.
Construction
An good filter must use information about its output, this is what exponential smoothing is about, simple exponential smoothing (EMA) is close to a simple moving average and can be defined as :
output = output(1) + α(input - output(1))
where α (alpha) is a smoothing constant, typically equal to 2/(Period+1) for the EMA.
This approach can be further developed by introducing more smoothing constants and output control (See double/triple exponential smoothing - alpha-beta filter) .
The moving average i propose will use only one smoothing constant, and is described as follow :
a = nz(a ) + alpha*nz(A )
b = nz(b ) + alpha*nz(B )
y = ema(a + b,p1)
A = src - y
B = src - ema(y,p2)
The filter is divided into two components a and b (more terms can add more control/effects if chosen well) , a adjust itself to the output error and is responsive while b is independent of the output and is mainly smoother, adding those components together create an output y , A is the output error and B is the error of an exponential moving average.
Comparison
There are a lot of low-lag filters out there, but the overshoots they induce in order to reduce lag is not a great effect. The first comparison is with a least square moving average, a moving average who fit a line in a price window of period length .
Lsma in blue and WRMA in red with both length = 100 . The lsma is a bit smoother but induce terrible overshoots
ZLMA in blue and WRMA in red with both length = 100 . The lag difference between each moving average is really low while VWRMA is way more precise.
Hull MA in blue and WRMA in red with both length = 100 . The Hull MA have similar overshoots than the LSMA.
Reduced overshoots moving average (ROMA) in blue and WRMA in red with both length = 100 . ROMA is an indicator i have made to reduce the overshoots of a LSMA, but at the end WRMA still reduce way more the overshoots while being smoother and having similar lag.
I have added a smoother version, just activate the extra smooth option in the indicator settings window. Here the result with length = 200 :
This result is a little bit similar to a 2 order Butterworth filter. Our filter have more overshoots which in this case could be useful to reduce the error with edges since other low pass filters tend to smooth their amplitude thus reducing edge estimation precision.
Conclusions
I have presented a well rounded filter in term of smoothness/stability and reactivity. Try to add more terms to have different results, you could maybe end up with interesting results, if its the case share them with the community :)
As for control theory i have seen neural networks integrated to Kalman flters which leaded to great accuracy, AI is everywhere and promise to be a game a changer in real time data smoothing. So i asked myself if it was possible for a neural networks to develop pinescript indicators, if yes then i could be replaced by AI ? Brrr how frightening.
Thanks for reading :)
FX Meter ScriptA while ago, we wrote* about the usefulness of using a currency strength meter and how you can build one from scratch.
See here: www.globalprime.com.au
Now we've taken this little project to the next level by visually spotting, via color signals in a dashboard and alerts, when a potential new trend might be developing in a currency pair.
*It's critical that you first read that article before you jump into reading this one or else you could get easily lost.
The script gives a trigger every time two currencies show diverging flows via opposing moving average slopes.
The signals originate from a first chart where currency indexes can be found, calculated through a formula, in various thin lines. Then a moving average to each currency index is applied so that it can smooth out the lines (what I call Micro moving averages – thicker lines -) and is usually a 4-5 period MA, with the key input to pay attention being the slope. One can perform their own tests on what works best for their particular trading style. The smaller the period in the moving average, the more responsive to changes in biases but the downside is that you will get a greater number of false moves. In the windows below the 1st chart, the stochRSI is calculated for each currency index (these values originate from the currency index and not from the applied MA). By default, a 25-period is applied to both RSI and Stoch length.
A 2nd chart that looks at the same logic is also accounted for to build this script, but instead of checking the micro trend, it applies a 25MA to the currency index, so it looks at what I call the slope of the macro trend. In this case, by default, a 125-period is applied to both RSI and Stoch length.
We had in mind to transition from just eye-balling and monitoring these charts manually to build a script via Tradingview that makes calculations real time (whenever the change in the moving average slope first occurs, and not when the bar/line closes), so that one can decide whether or not its a signal worth trading as part of a new trend emerging. Note, this is not so much a signal-triggering indicator but rather a tool to constantly be on the lookout monitoring what currencies might start to develop trends.
The actual script consists of a dashboard with different colored rectangles being triggered depending on the quality of the signal.
We will be happy to discuss it further with anyone who is interested in exploiting all the benefits that it can offer.
The way you add the script into your Tradingview chart is by first copy everything in the txt file. Then go to Pine editor (bottom middle-left) in your tradingview chart, delete everything there, then Paste the script. Then click Add to Chart (top right of the pine editor).
Note, you should add via the Anchored Text function the following list of pairs below, in this alphabetic order, on the right-hand side of the chart, as demonstrated above:
AUDCAD
AUDJPY
AUDNZD
AUDUSD
CADJPY
EURAUD
EURJPY
EURCAD
EURNZD
EURGBP
EURUSD
GBPAUD
GBPCAD
GBPJPY
GBPNZD
GBPUSD
NZDCAD
NZDJPY
NZDUSD
USDCAD
USDJPY
There are only 2 rules for the script to trigger a signal (see below). However, as I will elaborate further down, there are up to 6 different colors we can grade a signal
RULE 1 -> 2 moving averages, which are a calculation applied to a currency index as shown in the micro trend above, exhibit slopes in the opposite direction.
RULE 2 -> The Stoch RSI cannot be in overbought conditions if the slope of the moving average points higher or in oversold if the slope points lower.
Note 1: Even if the chart is a 60m timeframe by default (can be changed to any timeframe(, one gets the signal the moment the change of slope is identified, which means the indicator monitors changes in price tick by tick, and not on a candle close, otherwise one would get the trigger too late.
As an example of the highest-graded signal triggering (in green), a few hours ago we were given the visual cue that GBPCAD was experiencing a change of behavior. If we crosscheck the time the green-colored trigger was given with the actual GBPCAD chart, this is what we can observe. The pair is 30p higher since the trigger.
HOW TO SETUP ALERTS
One can easily setup a notification window each time the above rules are met, for example, if the EUR MA slope changes to bullish, and the AUD MA slope changes to bearish, and none of the 2 currency index values corresponding to these 2 moving averages (EUR and AUD) show a stoch RSI in overbought (above 80) in the case of the EUR, or oversold (below 20) in the case of the AUD, then the notification pop up would show a customized line: Long EURAUD
Note 1: Recording the slope of the macro moving average, which is usually a 25period MA applied to the currency index, is not included as part of the rules to trigger a signal, but it is taken into account to grade the quality of each signal.
Note 2: I recommend each signal to be triggered once or if you prefer, simply monitor the chart visually on the change of colors via the dashboard. The calculation resets and can appear again the moment that the slope changes to the opposite direction, so it’s a very dynamic indicator that will alert you the second a pair of currencies starts trending.
Note 3: When the signal is triggered, the indicator draws a colored rectangle. Each signal notification should be colored based on the following logic below.
LOGIC TO QUALIFY SIGNALS
-> Any long micro position with Macro MA in full agreement (ie/ Long EURAUD, Macro EUR up, Macro AUD down) is highlighted with green color
-> Any long micro position with macro moving averages in partial agreement (for example Long EURAUD, Macro EUR up AUD up) is highlighted with blue color
-> Any long micro position with macro moving averages in full disagreement (for example Long EURAUD, Macro EUR down AUD up) is highlighted with magenta color
-> Any short micro position with macro moving averages in full agreement (for example Short EURAUD, Macro EUR down AUD up) is highlighted with red color
-> Any short micro position with macro moving averages in partial agreement (for example Short EURAUD, Macro EUR up AUD up) is highlighted with orange color
-> Any short micro position with macro moving averages in full disagreement (for example Short EURAUD, Macro EUR up AUD down) is highlighted with purple color
PARAMETERS IN THE SCRIPT SETTINGS
Overbought/oversold: One can modify the stoch RSI level from which the indicator considers the value to be in overbought or oversold conditions. As a rule of thumb, consider 20/30 for oversold and 70/80 for oversold.
Slopes micro/macro MAs: One can edit the slope of the micro MA period (rule of thumb 4-5) and the macro MA (by default 25).
Value StochRSI: The default inputs are K 3, D 3, RSI Length 25, Stoch Length 25 for the micro and 125 period for the macro.
Change colors: One can edit the assigned colors in the signals dashboard.
Timeframe applied: The indicator has the flexibility to be applied to any timeframe, not just the 60m by default. Simply change the timeframe temporality.
CURRENCY INDEXES FORMULAS
It is the responsibility of the user to keep the values of the indexes updated. Find a recent sample below, as per values in early April. What this means is that at least once a week, in order to not let the values outdated, you should update the script with the latest valuations in the denominator.
NZD INDEX -> FX_IDC:NZDAUD/0.96+FX:NZDJPY/75.81+FX:NZDUSD/0.68+FX_IDC:NZDEUR/0.6+FX_IDC:NZDGBP/0.52+FX:NZDCHF/0.69+FX:NZDCAD/0.9
EUR INDEX -> FX:EURUSD/1.13+FX:EURJPY/125.5+FX:EURGBP/0.87+FX:EURCHF/1.135+FX:EURCAD/1.49+FX:EURNZD/1.655+FX:EURAUD/1.59
JPY INDEX -> 1/(FX:USDJPY/110.5+FX:EURJPY/125.5+FX:AUDJPY/79+FX:NZDJPY/75.5+FX:GBPJPY/144.5+FX:CHFJPY/110.5+FX:CADJPY/84)
USD INDEX -> FX_IDC:USDEUR/0.88+FX:USDJPY/110.5+FX_IDC:USDGBP/0.77+FX:USDCHF+FX:USDCAD/1.315+FX_IDC:USDNZD/1.46+FX_IDC:USDAUD/1.4
CAD INDEX-> FX_IDC:CADAUD/1.07+FX_IDC:CADNZD/1.11+FX:CADJPY/84.27+FX_IDC:CADUSD/0.76+FX_IDC:CADEUR/0.67+FX:CADCHF/0.76+FX_IDC:CADGBP/0.58
GBP INDEX -> FX:GBPAUD/1.83+FX:GBPNZD/1.91+FX:GBPJPY/144.5+FX_IDC:GBPEUR/1.15+FX:GBPCHF/1.31+FX:GBPUSD/1.31+FX:GBPCAD/1.71
Remember, I have provided a manual on how to build a currency strength meter. That’s what you will need to do first if you want to obtain the actual currency indexes other than just the indicator, which is just the visual cue to get you alerted when the slopes turn.
Once you’ve created your indexes via tradingview, you then apply a moving average to each index. Then apply the stochrsi 25 period to each index. For the macro trend, I make the same calculations, but the period of the MA is 25 instead of 4, while the stoch rsi is 125 periods vs 25 periods.
FINAL NOTE
This is a tool that should be interpreted as visual assistance, via the dashboard, to get that first cue when opposing micro slopes via the FX meter occur. However, you still need to check the technical context of the pair (levels marked, proj reached, etc.) but that first cue is a major time saver to constantly spot what's trending in FX. The permutations u can play with, as part of this script, are significant. You can tweak the timeframes you use, the periods of the moving averages, etc. I find the micro and macro trend combos when either a green or red signals is triggered the most reliable, with positions to be exploited via 15m and hourly under the right technical context.
Reverse Engineered RSI - Key Levels + MTFThis indicator overlays 5 Reverse Engineered RSI (RERSI) levels on your main chart window.
The RERSI was first developed by Giorgos Siligardos in the June 2003 issue of Stocks and Commodities Magazine. HPotter provided the initial implementation - from which this script is derived - so all credit to them (see: ).
In simple terms, RERSI plots lines on the price chart that reflect levels of the RSI . E.g. if you set up a RERSI line at a level of 50, then price will touch that line when the standard RSI indicator reads 50. Hopefully that makes sense, but compare the two if it doesn't.
Why is the RERSI useful if it's just plotting RSI values? Well, it simplifies things, and enables you to get a clearer picture of trend direction, RSI support and resistance levels, RSI trading signals, and it keeps your chart window uncluttered.
I've set up 5 RERSI lines to be plotted: Overbought and Oversold Levels, a Middle Level (generally leave this at 50), and then Down/Up Trend Lines. The latter two are loosely based on the work of Constance Brown (and they in turn were influenced by Andrew Brown), who posited that RSI doesn't breach certain levels during trends (e.g. 40-50 is often a support level during an uptrend).
Play around with the levels, and the RSI Length, to see how your particular market reacts, and where key levels may lie. Remember, this isn't meant as a stand-alone system (although I think there's potential to use it as such, especially with price action trading - which I guess wouldn't make it stand-alone then!!), and works best with confirmation from other sources.
Oh, and there's MTF capability, because I think that's useful for all indicators.
Any queries, please let me know.
Cheers,
RJR
