Short Swing Bearish MACD Cross (By Coinrule)This strategy is oriented towards shorting during downside moves, whilst ensuring the asset is trading in a higher timeframe downtrend, and exiting after further downside.
This script can work well on coins you are planning to hodl for long-term and works especially well whilst using an automated bot that can execute your trades for you. It allows you to hedge your investment by allocating a % of your coins to trade with, whilst not risking your entire holding. This mitigates unrealised losses from hodling as it provides additional cash from the profits made. You can then choose to hodl this cash, or use it to reinvest when the market reaches attractive buying levels. Alternatively, you can use this when trading contracts on futures markets where there is no need to already own the underlying asset prior to shorting it.
ENTRY
This script utilises the MACD indicator accompanied by the Exponential Moving Average (EMA) 450 to enter trades. The MACD is a trend following momentum indicator and provides identification of short-term trend direction. In this variation it utilises the 11-period as the fast and 26-period as the slow length EMAs, with signal smoothing set at 9.
The EMA 450 is used as additional confirmation to prevent the script from shorting when price is above this long-term moving average. Once price is above the EMA 450 the script will not open any shorts - preventing the rule from attempting to short uptrends. Due to this, this strategy is ideal for setting and forgetting.
The script will enter trades based on two conditions:
1) When the MACD signals a bearish cross. This occurs when the EMA 11 crosses below the EMA 26 within the MACD signalling the start of a potential downtrend.
2) Price has closed below the EMA 450. Price closing below this long-term EMA signals that the asset is in a sustained downtrend. Price breaking above this could indicate a bullish strength in which shorting would not be profitable.
EXIT
This script utilises a set take-profit and stop-loss from the entry of the trade. The take profit is set at 8% and the stop loss of 4%, providing a risk reward ratio of 2. This indicates the script will be profitable if it has a win ratio greater than 33%.
Take-Profit Exit: -8% price decrease from entry price.
OR
Stop-Loss Exit: +4% price increase from entry price.
Based on backtesting results across a selection of assets, the 45-minute and 1-hour timeframes are the best for this strategy.
The strategy assumes each order is using 30% of the available coins to make the results more realistic and to simulate you only ran this strategy on 30% of your holdings. A trading fee of 0.1% is also taken into account and is aligned to the base fee applied on Binance.
The backtesting data was recorded from December 1st 2021, just as the market was beginning its downtrend. We therefore recommend analysing the market conditions prior to utilising this strategy as it operates best on weak coins during downtrends and bearish conditions, however the EMA 450 condition should mitigate entries during bullish market conditions.
在腳本中搜尋"backtesting"
Oversold RSI with tight SL Strategy (by Coinrule)This is one of the best strategies that can be used to get familiar with technical indicators and start to include them in your trading bot rules.
ENTRY
1. This trading system uses the RSI ( Relative Strength Index ) to anticipate good points to enter positions. RSI is a technical indicator frequently used in trading. It works by measuring the speed and change of price movements to determine whether a coin is oversold (indicating a good entry point) or overbought (indicating a point of exit/entry for a short position). The RSI oscillates between 0 and 100 and is traditionally considered overbought when over 70 and oversold when below 30.
2. To pick the right moment to buy, the strategy enters a trade when the RSI falls below 30 indicating the coin is oversold and primed for a trend reversal.
EXIT
The strategy then exits the position when the price appreciates 7% from the point of entry. The position also maintains a tight stop-loss and closes the position if the price depreciates 1% from the entry price. The idea behind this is to cut your losing trades fast and let your winners ride.
The best time frame for this strategy based on our backtesting data is the daily. Shorter time frames can also work well on certain coins, however in our experience, the daily works best. Feel free to experiment with this script and test it on a variety of your coins! With our backtesting data a trading fee of 0.1% is taken into account. The fee is aligned to the base fee applied on Binance, which is the largest cryptocurrency exchange by volume. In the example shown, this strategy made a handsome net profit of 39.31% on Chainlink with 61.54% of trades being profitable.
EMA bands + leledc + bollinger bands trend following strategy v2The basics:
In its simplest form, this strategy is a positional trend following strategy which enters long when price breaks out above "middle" EMA bands and closes or flips short when price breaks down below "middle" EMA bands. The top and bottom of the middle EMA bands are calculated from the EMA of candle highs and lows, respectively.
The idea is that entering trades on breakouts of the high EMAs and low EMAs rather than the typical EMA based on candle closes gives a bit more confirmation of trend strength and minimizes getting chopped up. To further reduce getting chopped up, the strategy defaults to close on crossing the opposite EMA band (ie. long on break above high EMA middle band and close below low EMA middle band).
This strategy works on all markets on all timeframes, but as a trend following strategy it works best on markets prone to trending such as crypto and tech stocks. On lower timeframes, longer EMAs tend to work best (I've found good results on EMA lengths even has high up to 1000), while 4H charts and above tend to work better with EMA lengths 21 and below.
As an added filter to confirm the trend, a second EMA can be used. Inputting a slower EMA filter can ensure trades are entered in accordance with longer term trends, inputting a faster EMA filter can act as confirmation of breakout strength.
Bar coloring can be enabled to quickly visually identify a trend's direction for confluence with other indicators or strategies.
The goods:
Waiting for the trend to flip before closing a trade (especially when a longer base EMA is used) often leaves money on the table. This script combines a number of ways to identify when a trend is exhausted for backtesting the best early exits.
"Delayed bars inside middle bands" - When a number of candle's in a row open and close between the middle EMA bands, it could be a sign the trend is weak, or that the breakout was not the start of a new trend. Selecting this will close out positions after a number of bars has passed
"Leledc bars" - Originally introduced by glaz, this is a price action indicator that highlights a candle after a number of bars in a row close the same direction and result in greatest high/low over a period. It often triggers when a strong trend has paused before further continuation, or it marks the end of a trend. To mitigate closing on false Leledc signals, this strategy has two options: 1. Introducing requirement for increased volume on the Leledc bars can help filter out Leledc signals that happen mid trend. 2. Closing after a number of Leledc bars appear after position opens. These two options work great in isolation but don't perform well together in my testing.
"Bollinger Bands exhaustion bars" - These bars are highlighted when price closes back inside the Bollinger Bands and RSI is within specified overbought/sold zones. The idea is that a trend is overextended when price trades beyond the Bollinger Bands. When price closes back inside the bands it's likely due for mean reversion back to the base EMA in which this strategy will ideally re-enter a position. Since the added RSI requirements often make this indicator too strict to trigger a large enough sample size to backtest, I've found it best to use "non-standard" settings for both the bands and the RSI as seen in the default settings.
"Buy/Sell zones" - Similar to the idea behind using Bollinger Bands exhaustion bars as a closing signal. Instead of calculating off of standard deviations, the Buy/Sell zones are calculated off multiples of the middle EMA bands. When trading beyond these zones and subsequently failing back inside, price may be due for mean reversion back to the base EMA. No RSI filter is used for Buy/Sell zones.
If any early close conditions are selected, it's often worth enabling trade re-entry on "middle EMA band bounce". Instead of waiting for a candle to close back inside the middle EMA bands, this feature will re-enter position on only a wick back into the middle bands as will sometimes happen when the trend is strong.
Any and all of the early close conditions can be combined. Experimenting with these, I've found can result in less net profit but higher win-rates and sharpe ratios as less time is spent in trades.
The deadly:
The trend is your friend. But wouldn't it be nice to catch the trends early? In ranging markets (or when using slower base EMAs in this strategy), waiting for confirmation of a breakout of the EMA bands at best will cause you to miss half the move, at worst will result in getting consistently chopped up. Enabling "counter-trend" trades on this strategy will allow the strategy to enter positions on the opposite side of the EMA bands on either a Leledc bar or Bollinger Bands exhaustion bar. There is a filter requiring either a high/low (for Leledc) or open (for BB bars) outside the selected inner or outer Buy/Sell zone. There are also a number of different close conditions for the counter-trend trades to experiment with and backtest.
There are two ways I've found best to use counter-trend trades
1. Mean reverting scalp trades when a trend is clearly overextended. Selecting from the first 5 counter-trend closing conditions on the dropdown list will usually close the trades out quickly, with less profit but less risk.
2. Trying to catch trends early. Selecting any of the close conditions below the first 5 can cause the strategy to behave as if it's entering into a new trend (from the wrong side).
This feature can be deadly effective in profiting from every move price makes, or deadly to the strategy's PnL if not set correctly. Since counter-trend trades open opposite the middle bands, a stop-loss is recommended to reduce risk. If stop-losses for counter-trend trades are disabled, the strategy will hold a position open often until liquidation in a trending market if th trade is offsides. Note that using a slower base EMA makes counter-trend stop-losses even more necessary as it can reduce the effectiveness of the Buy/Sell zone filter for opening the trades as price can spend a long time trending outside the zones. If faster EMAs (34 and below) are used with "Inner" Buy/Zone filter selected, the first few closing conditions will often trigger almost immediately closing the trade at a loss.
The niche:
I've added a feature to default into longs or shorts. Enabling these with other features (aside from the basic long/short on EMA middle band breakout) tends to break the strategy one way or another. Enabling default long works to simulate trying to acquire more of the asset rather than the base currency. Enabling default short can have positive results for those high FDV, high inflation coins that go down-only for months at a time. Otherwise, I use default short as a hedge for coins that I hold and stake spot. I gain the utility and APR of staking while reducing the risk of holding the underlying asset by maintaining a net neutral position *most* of the time.
Disclaimer:
This script is intended for experimenting and backtesting different strategies around EMA bands. Use this script for your live trading at your own risk. I am a rookie coder, as such there may be errors in the code that cause the strategy to behave not as intended. As far as I can tell it doesn't repaint, but I cannot guarantee that it does not. That being said if there's any question, improvements, or errors you've found, drop a comment below!
GRID SPOT TRADING ALGORITHM - GRID BOT TRADING STRATEGYGRID SPOT TRADING ALGORITHM : LONG ONLY STRATEGY OPEN SOURCE
This is a long only strategy for spot assets.
HOW IT WORKS
Grid trading is a trading strategy where an investor creates a so-called "price grid". The basic idea of the strategy is to repeatedly buy at the pre-specified price and then wait for the price to rise above that level and then sell the position (and vice versa with shorting or hedging).
FEATURES
Grids: This algorithm has a total of 10 grids.
Take profit: The trader can increase or decrease the distance between the grids from the User Interface panel, the distance between one grid and another represents the take profit.
Management: The algorithm buys 10% of the capital every time the price breaks down a grid and sells during a rise to the next higher grid. The initial capital is invested in 10 sizes which represent 10% of the capital per trade.
Stop Loss: The algorithm knows no stop loss as long as it is not activated from the User Interface panel. By activating the stop loss from the User Interface panel the algorithm will insert a close condition on all trades which will be calculated from the last lower grid.
Trades: Trades are opened only if the price is within the grid. If the market leaves the grid the algorithm will not buy new positions or sell new positions.
Optimal market conditions: The favorable market for this algorithm is the sideways market.
LIMITATIONS OF THE MODEL
The trader must take into account that this is a static model. It only works perfectly well if the market is in a sideways phase and incurs heavy losses if the market takes a downward trend. The model is unusable for an uptrend. The trader must therefore carefully analyze the market where he intends to use this strategy, making sure that the price is in a sideways phase.
USES
Indispensable research and backtesting tool for those using bots for their investments. The algorithm produces a backtesting of the strategy for past history. It is used by professional traders to understand if this strategy has been profitable on a market and what parameters to use for bots using this strategy (Kucoin, Binance etc.).
If you would like to develop your own algorithm with customized conditions based on a grid strategy, please contact us.
If you need help in using this tool, please contact us without hesitation.
[astropark] Moon Phases [strategy]Dear Followers,
today I'm glad to present you an indicator which calculates Moon Phases and let's you backtest the simplest strategy over it: buy/sell on full moon and do the opposite on new moon.
This is a public free indicator based on the public one by @paaax:
I added my usual backtesting logic, plus some more customization inputs for easy coloring.
The lower the timeframe you backtest on, the more backtesting data are effective.
Enjoy!
-- astropark
MACD Long StratFirst script I've written, but the concept is pretty simple. This uses the MACD with settings fast_SMA = 6 and slow SMA=16 and uses the distance between the 2 (histogram) to look for potential trend reversals to flag potential entries for Long trades. It waits for the confirmation looking backward 2 x timeframes (to reduce false calls slightly). You can adjust it to open / close quicker (1 timeframe instread of 2) but backtesting shows 2 timeframe delay is best to avoid false signals.
The script suggests Long entry points based on this criteria and uses the converse (reducing histogram / SMA difference delayed by 2 timeframes) to suggest exit or trade close points for downward reversal. It was originally written looking at 1m scalps but backtesting shows this is even more effective on higher timeframes (1D).
Delta-RSI Strategy (with filters)Delta-RSI Strategy (with filters):
This is a version of the Delta-RSI Oscillator strategy with several criteria available to filter entry and exit signals. This script is also suitable for backtesting over a user-defined period and offers several risk management options (take profit and stop loss).
Since the publication of the Delta-RSI Oscillator script, I have been asked many times to make it compatible with the Strategy Tester and add filtering criteria to minimize "false" signals. This version covers many of these requests. Feel free to insert your favorite D-RSI parameters and play around!
ABOUT DELTA-RSI
Delta-RSI represents a smoothed time derivative of the RSI designed as a momentum indicator (see links below):
INPUT DESCTIPTION
MODEL PARAMETERS
Polynomial Order : The order of local polynomial used to interpolate the relative strength index (RSI).
Length : The length of the lookback frame where local regression is applied.
RSI Length : The timeframe of RSI used as input.
Signal Length : The signal line is a EMA of the D-RSI time series. This input parameter defines the EMA length.
ALLOWED ENTRIES
The strategy can include long entries, short entries or both.
ENTRY AND EXIT CONDITIONS
Zero-crossing : bullish trade signal triggered when D-RSI crosses zero from negative to positive values (bearish otherwise)
Signal Line Crossing : bullish trade signal triggered when D-RSI crosses from below to above the signal line (bearish otherwise)
Direction Change : bullish trade signal triggered when D-RSI was negative and starts ascending (bearish otherwise)
APPLY FILTERS TO
The filters (described below) can be applied to long entry, short entry and exit signals.
RELATIVE VOLUME FILTER
When activated, the D-RSI-driven entries and exits will be triggered only if the current volume is greater than N times the average over the last M bars.
VOLATILITY FILTER
When activated, the D-RSI-driven entries and exits will be triggered only if the N-period average true range, ATR, is greater than the M-period ATR. If N < M, this condition implies increasing volatility.
OVERBOUGHT/OVERSOLD FILTER
When activated, the D-RSI-driven entries and exits will be triggered only if the value of 14-period RSI is in the range between N and M.
STOP LOSS/TAKE PROFIT
Fixed and trailing stop loss as well as take profit options are available.
FIXED BACKTESTING START/END DATES
If the checkboxes are not checked, the strategy will backtest all available price bars.
`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.
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.
User-Inputed Time Range & FibsGreetings 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 User-Inputed Time Range & Fibs.
The idea behind this script is to record the Range Highs and Lows of a User Defined Period, and plot potential Targets based on either Fibonacci Extensions or a Multiple of the Range Size. I created this originally for use with the US Session Initial Balance(From 9:30-10:30AM EST), however it can be set to any time period.
What is Initial Balance? In simple words, Initial Balance (IB) is the price data, which are formed during the first hour of a trading session. Activity of traders forms the so-called Initial Balance at this time. This concept was introduced for the first time by Peter Steidlmayer when he presented the market profile to traders(atas.net).
The IB is monitored as a break-out area for Range Extension traders. The IB High is also seen as an area of resistance and the IB Low as an area of support until it is broken(www.mypivots.com).
As a note, depending on the Time Zone you are in, you may need to manually add or subtract from the Timed Range to match the desired Time. For example in NY Eastern Time, I have to use 8:30-9:30AM to Capture the 9:30-10-30AM IB for ES and NQ. Similarly, I must use 14:30-15:30PM to Capture the 9:30-10-30AM IB for BTC. You will need to make adjustments based on the Time Zone you are located in.
I wanted to give a Special Thanks to @PineCoders for the Custom Rounding Function from Backtesting/Trading Engine--> (), Pinecoders.com for help with Tracking the Highs/Lows--> (www.pinecoders.com), and @TradeChartist for allowing me to use some of the code for the Fibonacci Extensions from his script here--> ().
If you like User-Inputed Time Range & Fibs, be sure to Like, Follow, and if you have any questions, don't be afraid to drop a comment below.
Price PredictorGreetings 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 Price Predictor.
How To Use Price Predictor
Price Predictor acquires potential targets by measuring the Average Change of Price from a user-defined resolution, from Open to Open. By default, the Resolution is set to 1 Day, however you can play around with Weekly, Monthly, etc. When a new resolution period begins, Price Predictor will automatically adjust based on the new Average Change of Price.
Due to the avoidance of Security() in this script, you may have to play around with the Timeframe that you use it in to ensure that you have enough bars on your chart to process the User-Defined Resolution.
The first Target Zone represents Target 5 of my other script, Trade Manager()(Given that you set the Target Multiple and Default Threshold Inputs as the same in each script), and is the most likely to be hit before the end of the resolution period.
In addition to a User-Defined Resolution, you also have the option of using a Custom Price to define Target Zones, however I'd recommend using my other script, Trade Manager(), if the volatility of the Instrument isn't too high.
I wanted to give a Special Thanks to @Pinecoders for the Custom RoundToTick Function from The Backtesting/Trading Engine --> (
If you like Price Predictor, be sure to Like, Follow, and if you have any questions, don't be afraid to drop a comment below.
Trade ManagerGreetings 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 Trade Manager.
How To Use Trade Manager
Trade Manager acquires potential targets by measuring the Average Change of Price from a user-defined resolution, from Open to Open. By default, the Resolution is set to 1 Day, however you can play around with Weekly, Monthly, etc. When a new resolution period begins, Trade Manager will automatically adjust its Targets based on the new Average Change of Price.
Due to the avoidance of Security() in this script, you may have to play around with the Timeframe that you use it in to ensure that you have enough bars on your chart to process the User-Defined Resolution.
The idea behind Trade Manager is quite simple yet can be quite powerful at the same time. Consider a Daily Candle for example. You can clearly see how a vast amount of price movement can be encapsulated within it, sometimes in both directions. By measuring the Average Change of Price per day(From Open to Open), we can use this Average to build targets off of. Defining a small Threshold above and below the Open Price of the Daily Candle allows you to set Limit Orders at these levels with predefined Targets. Then, the use of the custom Trailing Stop and Break Even helps to secure profits without giving too much back to the market, all while managing your risk.
Within the Settings of Trade Manager, you have the option to alter the logic of whether Break-Even is set after the first Target or second Target is hit.
In addition to using a User-Defined Resolution Period, you can also input a Custom Price into the settings of Trade Manager and allow the Targets, Trailing Stop, and Break Even to be calculated from the Custom Price.
I wanted to give a Special Thanks to @PineCoders for the Custom RoundToTick Function from The Backtesting/Trading Engine --> ()
As a note, there are times where price will break out very strongly from the Limit Price, sometimes crossing the Stop and Limit Price on the same bar. When this happens, it is difficult for Pine to determine which occurred first intra-bar, and as a result, it does not record a new position. In these instances, I'd recommend adjusting the Default Stop Multiple so it is below the bar.
If you like Trade Manager, be sure to Like, Follow, and if you have any questions, don't be afraid to drop a comment below.
Ichimoku systemThis script is to get backtesting results of ichimoku Cloud system .
>> tick buying only to watch backtesting results of buying trades ony other wise untick to see both buy and sell trade results (for intraday timeframe)
Tell me if you have any suggestions u i will try to include them in coming updates
Pivot Point SuperTrend [Backtest]Hello All,
This is backtesting result of following indicator/strategy. I didn't work on adding other indicators. maybe in the future I can try to combine this with other indicators.
You can visit following link to see "Pivot Point SuperTrend" . by using this backtesting tool, you can test&find better options
There is option "Use Center Line to Close Entry for 50%" . by default it's not enabled. if you enable this option, pivot point center line may push you to close your entry for 50% (can be used as early stoploss/take profit line if you think it's risky)
Enjoy!
Stochastic Pop and Drop by Jake Bernstein v1 [Bitduke]I found a simple strategy by Jake Bernstein, modified it a little and created a strategy with Risk Management System (SL+TP); After that I test it on the different cryptocurrency pairs.
About the Indicator
Basically it's the strategy of 2 indicators: Stochastic Oscillator to define the bias and Average Directional Index to confirm it.
One again, It uses Stochastic Oscillator to define the trading bias. In particular, the trading bias was deemed bullish when the weekly 14-period Stochastic Oscillator was above some default value (in him paper - 50) and rising and vice versa.
Once the trading bias is established, Steckler used the Average Directional Index (ADX) to define a slowdown in the trend. ADX measures the strength of the trend and a move below 20 signals a weak trend.
Modifications
I didn't implement Average Directional Index (ADX) and test just different sources for data, oscillator periods and different levels in relation to the crypto market.
So, it shows good results with two tight thresholds at 55 and 45 level.
The bar chart below the defining the bullish and bearish periods (green and red) and gives a signal to enter the trade (purple bars).
Backtesting
Backtested on XBTUSD , BTCPERP (FTX) pairs. You may notice it shows good results on 3h timeframe.
Relatively low drawdown
~ 10% (from 2019 to date) FTX
~ 22% (4 years from 2016) Bitmex
I backtested on the different altcoin pairs as well, but the results were just not good.
Relatively good results were shown by some index pairs from the FTX exchange ( FTX:SHITPERP ), but I think there is a few data for backtesting to be asure in them.
Bitmex 3h (2017 - 2020) :
i.imgur.com
FTX 3h (2019 - 2020):
i.imgur.com
Possible Improvements
- Regarding trading algorithm it would be good to check with strategy with ADX somehow. Maybe for the better entries
- As for Risk Management system, it can be improved by adding trailing stop to the strategy.
Link: school.stockcharts.com
NoNonsense Forex - high timeframe trading absurd NON-REPAINTINGSome time ago I bumped into NoNonsense Forex - pretty good-looking course with well-designed videos, reasonable rules, etc. Nice explanatory videos, not selling anything, building indicators-only strategy. But there was one thing that really annoyed me - it was supposed to work only on Daily timeframe. What is the point in trading such high timeframe, if decisions changing market direction are playing out within 1 minute? What is the point in evaluating trades from 1994 if we are 25 years later?
Anyway, I have developed this strategy, which is:
- non-repainting
- not using trailing-stop
- not using any other known TradingView backtest bugs
And I'm showing it as an example of OVERFITTING. Backtesting results look absurd: 100% profitable. But if you change any of the many parameters in the Settings popup, they will turn into disaster. It means, the rules of this strategy are very fragile. Don't trade this! Remember about backtesting rule #1: past results do not guarantee success in the future.
I'm giving this strategy out with the source code. Feel free to do anything you want with it. But if you find parameters or modifications on, which allow profitable trading on lower timeframes, don't be shy, let me know :)
*********
Forex / Indices / Commodities traders who want to start AUTO-TRADING might want to take a look at "TradingConnector", which allows no-latency trades execution from TradingView to MT4/MT5.
Visual RSI [LucF]Visual RSI offers a different way of looking at RSI by providing a composite representation of 9 different RSI-generated components. Instead of focusing on one line only, this approach blends multiple sources to provide the viewer with a larger context RSI-based picture.
For those who don’t want to read
• Green in bullish (>50) zone is the most bullish.
• Red in bullish zone doesn’t necessarily mean bearish—it just means bullish strength is weakening. It may be just a pause before a reprise or exhaustion signalling a reversal—impossible to tell.
• The same in inverse applies to the bearish zone (<50).
For those who want to understand
The nine components making up Visual RSI are:
• a current timeframe RSI
• a higher timeframe RSI
• the delta between these two RSI lines
• for each of these three basic components, two independent Bollinger band: one calculated for the bullish section of the scale (>50) and a separate one calculated for the lower bearish region.
Dual BBs
In my view, RSI’s position with regards to the centerline is much more important than its position in extreme areas. Why? Because the building block of RSI is the ratio of the averages of up/down moves during the RSI period. When the average of ups is greater, RSI is > 50. So while a rising signal starting from 20 let’s say, indicates that the rate of change is increasing, only when it crosses 50 can we say that sentiment balance has truly become bullish, and this information is more reliable than the signal being at a level corresponding to whatever estimate we make of what constitutes an extreme value. In my landscape, the general balance of a ratio provides more valuable information than the ratio’s exact value.
The idea behind the dual BBs is to provide independent tracking information for both halves of the indicator’s space, which I find more useful than the normal method of simply adding a multiple of the standard deviation on both sides of the mean. With dual BBs, the upper BB will never go lower than the indicator’s centerline, and the lower BB will never go higher. The upper BB focuses on upper-bound volatility when the signal is bearish, and the lower BB focuses on downside volatility when the signal is bearish.
The functions used to calculate the independent BBs are reusable on other signals if a centerline can be defined for them. A clamping percentage is implemented, so that when a BB line is hugging the centerline it clamps to it. This helps in providing earlier signals when they use the BB line states.
Providing context to RSI
What RSI measures indirectly is the balance in the rate of change—or the speed of price movement, but not its instant value, otherwise RSI would be even noisier. More precisely, RSI represents the relative strength of the up/down movement in the last n bars of RSI’s length, with 14 often used because that’s what Wilder proposed (Visual RSI’s defaults are 20 for the current timeframe and 40 for the higher timeframe). At every bar, a new value is added to the equation and an old value carrying equal weight is dropped, so a large dropped off value will have more impact on RSI’s value if the new bar’s move is small. This accounts for some of RSI’s speed in identifying exhaustion after important moves, but almost for some of its noise.
Visual RSI is the result of trying to drown RSI’s noise in the context of other informational streams, while simultaneously providing even faster information than RSI alone, by giving more visual weight to the delta between the current and higher timeframe RSI’s.
How to read Visual RSI
The default settings show all 9 basic components as green/red areas of intensities varying with their importance. The most intense colors are reserved for the delta RSI and the BBs have the lightest intensities. The individual lines of components are intentionally difficult to distinguish so that focus is first on the general picture, including the all-important six-state background, and then on the delta RSI.
One entry setup could be reversals in a larger trend context, so low pivots of the delta in a fully bullish context (a green background in the upper section of the indicator), and inversely, high pivots in a fully bearish context (a red background in the lower section of the indicator).
Please resist the common misconception, when interpreting RSI, that a reversal in the signal will necessarily lead to a reversal in price. Each trend has its rhythm. Only machine-generated price action can progress regularly. It’s normal for trends to take a breather for some time before they continue or reverse, as traders driving the trend experience emotional fatigue and gradual fear. RSI reversals merely signify that such a breather has occurred—nothing more. Only the larger context can provide information that can situate that pause and put more meaningful odds on it having more probability of continuing in one direction or the other. This is the reasoning behind the setup just described.
Features
• All components can be hidden, displayed as a simple line, a uniformly colored fill, or a green/red fill (the default).
• The background can be colored using 9 different methods, including 3 six-state methods using the rising/falling BB lines of the 3 basic components. These six states allow for bullish/bearish/neutral sentiment in both the upper and lower regions of the indicator. A bearish (dark red) background in the bullish (>50) section of the indicator represents decreasing bullishness. A bearish (slightly brighter red) in the bearish (<50) section of the indicator means incresingly bearish sentiment. The six-state backgrounds allow for neutral (no color) sentiment when no compelling signs can be found to conclude anything with meaningful odds. The default background uses the six-state method on the higher timeframe RSI’s BBs because I find it the most useful, as it represents the largest—and slowest—context sentiment among all the indicator’s components.
• A thin status bar in the top part of the indicator also allows selection of the same 9 methods to color it. The default is a triple-state system using the rising/falling characteristics of the current timeframe RSI’s BBs to provide a short-term counterbalance to the long-term background.
• Three different markers can be configured using approximately 70 permutations each, each filtered by 20 different filter permutations. When modification of the relevant parameters in the script’s Settings/Settings/Parameters section is added, possibilities are almost endless. If the generated signals are then fed into the PineCoders Engine and combined with the Engine’s own options, the permutations go up another order of magnitude, and changes to any setting can be instantly evaluated using the Engine’s backtesting results.
• Five simple filters can be combined. They are additive. They include volume-related conditions and a chandelier, which I find useful because both volume and volatility (the chandelier using highs/lows and ATR) are sensible complementary sources to RSI’s momentum information. The filter’s state can be shown as a thin line at the bottom of the indicator.
• Alerts can be configured using any of the marker/filter combinations mentioned. As usual, once your markers/filters are set up the way you want, create your alert from the chart/timeframe you want the alert to run on and be sure to use the “Once Per Bar Close” triggering condition. Use an alert message that will remind you of which combination of markers were used when creating the alert.
• A plot providing entry signals for the PineCoders Backtesting & Trading Engine is supplied. It will use whichever marker/filter configuration is active to generate signals.
• All higher timeframe information is non-repainting. Higher timeframe lines can be smoothed (the default). The selection of the higher timeframe can be made using 3 different methods:
1. By steps (if current timeframe <= 1 minute: 60 min, <= 60 min: 1D, <= 6H: 3D, <= 1D: 1W, <=1W: 1M, >1W: 12M)
2. By a user-defined multiple of the current timeframe
3. Using a fixed timeframe
Thanks to:
• Alex Orekhov aka @everget for the chandelier code.
• @RicardoSantos who through a small remark early on, unknowingly put me on the track of eliminating noise through visual crowding.
• The brilliant guys in the PineCoders Pro room for your knowledge, limitless creativity and constant companionship.
WOW no repainting and no security() call! 100% real results!If you couldn't tell by the title, this is a joke lmao.
TV has an awful backtesting engine and I just wanted to prove this with a super simple script.
We buy when close > open
and sell when close < open.
That's it.
There is also some risk management and trade closing when we reach a certain drawdown, but wait!
TradingView doesn't know what equity drawdown is because they don't use tick data or any lower timeframe data! Wowow!
Ps - all tickdata for Forex & CFD historical data is free from Dukascopy if you want to perform your own backtesting ;)
Dukascopy Data
Enjoy
-DasanC
Multiple Moving Averages Alerts ScriptAlerts script that has triggers on multiple moving average crossovers so that profit is maximised, it also has an optional control moving average, enabled by default, that when active will stop trading when the price (first ma) is below the control moving average.
Source code is open so that others can use and modify
Click Below for Backtesting version:
Disclaimers, not an expert, not intended to be financial advise.
Biffy
Two Bar Break Line Alerts R1.0 by JustUncleLThis indicator with default settings is designed for BINARY OPTIONS trading. The indicator can also be used for Forex trading with some setting changes. The script shows Two Bar Pullback Break lines and alerts when those Break lines are Touched (broken) creating a short term momentum entry condition.
For a Bullish Break (Green Up Arrow) to occur: first must have two (or three) consecutive bear (red) candles which is followed by a bull (green) candle creating a pivot point. The breakout occurs then the High of the current Bull (green) exceeds the highest point of the previous two (or three) pivotal bear candles. The green channel Line shows where the current Bullish BreakOut occurs.
For a Bearish Break (Red Down Arrow) to occur: first must have two (or three) consecutive bull (green) candles which is followed by a bear (red) candle creating a pivot point. The breakout occurs when the Low of the current Bear (red) drops below the lowest point of the previous two (or three) pivotal Bull candles. The red channel Line shows where the current Bearish BreakOut occurs.
The break Line Arrows can optionally be filtered by the Coloured MA (enabled by default), a longer term directional MA (disabled by default) and/or a MACD condition (enabled by default) as a momentum filter.
You can optionally select three Bar break lines instead of two. The three bar break lines are actually equivalent to Guppy's Three Bar Count Back Line method for trade entries (see Guppy's video reference below).
Included in this indicator is an ability to display some basic Binary Option statistics, when enabled (enabled by default) it shows Successful Bars in Yellow and failed Bars in Black and the last Nine numbers on the script title line represent the Binary option Statistics in order:
%ITM rate
Total orders
Successful Orders
Failed Orders
Total candles tested
Candles per Day
Trades per Day
Max Consecutive Wins
Max Consecutive Losses
You can start the Binary Option statistics from a specific Date, which is handy for checking more recent history.
HINTS:
BINARY OPTIONS trading: use 5min, 15m, 1hr or even Daily charts. Trade after the price touches one of the Breakout lines and the Arrow first appears. Wait for the price to come back from Break Line by 1 or 2 pips, the alert arrow must stay on and candle change to black, then take Binary trade expiry End of Candle. If price pull back and arrow turns off, don't trade this candle, move on you probably don't have momentum, there will be plenty of other trigger events. The backtesting results are good with ITM rates 65% to 72% on many currency pairs, commodities and indices. Realtime trading has confirmed the backtesting results and they could even be bettered, provided you are selective on which signals to trade (strong MACD support etc), that you are patient and disciplined to this trading method.
FOREX trading: the default settings should work with scalping. For longer term trades try with settings change to a more standard MACD filter or slower to catch the longer term momentum swings and the idea would be to trade the first Break Line alert that occurs after a decent Pullback in the direction of the trend. Setting the SL to just above/below the Pivot High/Low and set target to two or three times SL.
References:
"Fundamentals of Price Action Trading for Forex, Stocks, Options and Futures" video:
www.youtube.com
Other videos by "basecamptrading" on Naked Trading.
"Taking Profits in Today's Market by Daryl Guppy" video:
www.youtube.com
Updated TurtlesThis script has been updated to prevent double orders (short/long) from occurring and modifying backtests results.
This is an update to the script that was written a few years ago to prevent double longs/shorts from occurring and skewin backtesting results. Check out the updated indicator here and let me know what you think.
I also added:
- date range inputs if you want to do some backtesting on a particular set of dates.
- the ability to toggle shorting
Adding some essential components to a prebuilt RSI strategyThis is more to be used as a blank_slate for any strategy build adding more effective backtesting with a period selector and inputs like TS, TP, SL that can all be used as plots for alerts.
It has the BackTest Component created by Pbergden
It also includes the standard long/short with trailing stop, take profit, stop loss and margin call.
Here is a video using the blank_slate to add in the built-in RSI Strategy.
youtu.be
We hope this brings good results and helps speed things up for everyone.
CM Stochastic POP Method 2-Jake Bernstein_V1Yesterday Jake Bernstein authorized me to post his updated results with the Stochastic Pop Trading System he developed many years ago.
You can take a look at the Original System with Updated Settings at
This indicator is a different set of rules Jake mentioned in the PDF he allowed me to post.
To view the PDF use this link:
dl.dropboxusercontent.com
Today we’re releasing the version described in the PDF that uses the StochK values of 55, 50, and 45. The rules are discussed in the PDF but here is a simple breakdown:
Enter Long when StochK is below 50 and Crosses Above 55
Exit Long on Cross Below 55
Enter Short when StochK is Above 50 and crosses Below 45
Exit Short on Cross Above 45
Two Important Items to understand about this method:
To code the rules Precisely we need a function that will be available when Strategy Capabilities are released on TradingView.
There is one of Jakes Profit Maximizing Strategies that needs to be integrated with this code…which again we need the Strategy based Function that will be coming soon.
To Compare this system to the Stochastic Pop Method 1 System shown yesterday at I used the same Symbol and dates for you to compare…but remember to give this Method 2 System a Fair Look/Evaluation…we need the Soon To Be Released…TradingView Strategy Capabilities.
BackTesting Results Example: EUR-USD Daily Chart Since 01/01/2005
Strategy 1 – Stochastic Pop Method 2 System:
Go Long When Stochasticis below 50 and Crosses Above 55. Go Short When Stochastic is above 50 and Crosses Below 45. Exit Long/Short When Stochastic has a Reverse Cross of Entry Value.
Results:
Total Trades = 151
Profit = 40,758 Pips
Win% = 37.1%
Profit Factor = 1.26
Avg Trade = 270 Pips Profit
***Most Consecutive Wins = 4 ... Most Consecutive Losses = 7
Strategy 2:
Rules - Proprietary Optimization Jake Will Teach. Only Added 1 Additional Exit Rule.
Results:
Total Trades = 151
Profit = 60.305 Pips
Win% = 37.1%
Profit Factor = 1.38
Avg Trade = 399 Pips Profit
***Most Consecutive Wins = 4 ... Most Consecutive Losses = 7
Indicator Includes:
-Ability to Color Candles (CheckBox In Inputs Tab)
Green = Long Trade
Blue = No Trade
Red = Short Trade
Jake Bernstein will be a contributor on TradingView when Backtesting/Strategies are released. Jake is one of the Top Trading System Developers in the world with 45+ years experience and he is going to teach TradingView.com’s community how to create Trading Systems and how to Optimize the correct way.
Link To PDF:
dl.dropboxusercontent.com
Link to Original Version of Indicator with Updated Settings.
