เริ่มกันเลย

ค้นหาในสคริปต์สำหรับ "backtesting"

Hurst ExponentMy first try to implement Full Hurst Exponent. The Hurst exponent is used as a measure of long-term memory of time series. It relates to the autocorrelations of the time series and the rate at which these decrease as the lag between pairs of values increases The Hurst exponent is referred to as the "index of dependence" or "index of long-range dependence". It quantifies the relative tendency of a time series either to regress strongly to the mean or to cluster in a direction. In short, depending on the value you can spot the trending / reversing market. Values 0.5 to 1 - market trending Values 0 to 0.5 - market tend to mean revert Hurst Exponent is computed using Rescaled range (R/S) analysis. I split the lookback period (N) in the number of shorter samples (for ex. N/2, N/4, N/8, etc.). Then I calculate rescaled range for each sample size. The Hurst exponent is estimated by fitting the power law. Basically finding the slope of log(samples_size) to log(RS). You can choose lookback and sample sizes yourself. Max 8 possible at the moment, if you want to use less use 0 in inputs. It's pretty computational intensive, so I added an input so you can limit from what date you want it to be calculated. If you hit the time limit in PineScript - limit the history you're using for calculations. #################### Disclaimer Please remember that past performance may not be indicative of future results. Due to various factors, including changing market conditions, the strategy may no longer perform as good as in historical backtesting. This post and the script don’t provide any financial advice.
อินดิเคเตอร์ Pine Script®
โดย QuantNomad
11
Custom Screener with Alerts V2 [QuantNomad]TradingView just recently announced the alert() function that allows you to create dynamic alerts from both strategies and studies. So I decided to update custom screener I published before. It was based on alerts from orders in strategies, that was the only way to create dynamic alerts in PineScript at that point. With the alert() function code become cleaner and more readable. It works for up to 40 symbols at the same time. You can create an alert from it easily by selecting screener name from the list and then selecting "Any alert() function call". No additional configuration is required, message and alert on close I set up in the code. I created as an example a screener that tracks both overbought (RSI > 70) and oversold stocks (RSI < 30). To create your own screener you have to change only screenerFunc(). By design it should output 2 values: cond - True/False Boolean variable. Should this instrument be displayed in the screener? value - Additional numeric value you can display in your screener. I display RSI level for selected stocks for example. Link to the old screener: Disclaimer Please remember that past performance may not be indicative of future results. Due to various factors, including changing market conditions, the strategy may no longer perform as good as in historical backtesting. This post and the script don’t provide any financial advice.
อินดิเคเตอร์ Pine Script®
โดย QuantNomad
29
Simple Hurst Exponent [QuantNomad]This is a simplified version of the Hurst Exponent indicator. In the meantime, I'm working on the full version. It's computationally intensive, so it's a challenge to squeeze it to PineScript limits. It will require some time to optimize it, so I decided to publish a simplified version for now. The Hurst exponent is used as a measure of long-term memory of time series. It relates to the autocorrelations of the time series, and the rate at which these decrease as the lag between pairs of values increases The Hurst exponent is referred to as the "index of dependence" or "index of long-range dependence". It quantifies the relative tendency of a time series either to regress strongly to the mean or to cluster in a direction. In short depend on value you can spot trending / reversing market. Values 0.5 to 1 - market trending Values 0 to 0.5 - market tend to mean revert #################### Disclaimer Please remember that past performance may not be indicative of future results. Due to various factors, including changing market conditions, the strategy may no longer perform as good as in historical backtesting. This post and the script don’t provide any financial advice.
อินดิเคเตอร์ Pine Script®
โดย QuantNomad
4
MA Divergences StrategyThis is the Strategy version of the Study I published. It is a Moving Average that can be applied to any plot to plot divergences on any oscillator, as well as perform backtesting. You'll need a REALLY good oscillator to perform live trades using this alone, but I think it is a valuable tool and had the Strategy hanging around and for some reason didn't upload it yet. So here it is. Turn Length to 1 to follow the oscillator without lag. Turn Length up if you are getting too many false signals or tweak the original oscillator settings.
กลยุทธ์ Pine Script®
โดย burgercrisis
`security()` revisited [PineCoders]NOTE The non-repainting technique in this publication that relies on bar states is now deprecated, as we have identified inconsistencies that undermine its credibility as a universal solution. The outputs that use the technique are still available for reference in this publication. However, we do not endorse its usage. See this publication for more information about the current best practices for requesting HTF data and why they work. █  OVERVIEW This script presents a new function to help coders use security() in both repainting and non-repainting modes. We revisit this often misunderstood and misused function, and explain its behavior in different contexts, in the hope of dispelling some of the coder lure surrounding it. The function is incredibly powerful, yet misused, it can become a dangerous WMD and an instrument of deception, for both coders and traders. We will discuss:  • How to use our new `f_security()` function.  • The behavior of Pine code and security() on the three very different types of bars that make up any chart.  • Why what you see on a chart is a simulation, and should be taken with a grain of salt.  • Why we are presenting a new version of a function handling security() calls.  • Other topics of interest to coders using higher timeframe (HTF) data. █  WARNING We have tried to deliver a function that is simple to use and will, in non-repainting mode, produce reliable results for both experienced and novice coders. If you are a novice coder, stick to our recommendations to avoid getting into trouble, and DO NOT change our `f_security()` function when using it. Use `false` as the function's last argument and refrain from using your script at smaller timeframes than the chart's. To call our function to fetch a non-repainting value of close from the 1D timeframe, use: f_security(_sym, _res, _src, _rep) => security(_sym, _res, _src ) previousDayClose = f_security(syminfo.tickerid, "D", close, false) If that's all you're interested in, you are done. If you choose to ignore our recommendation and use the function in repainting mode by changing the `false` in there for `true`, we sincerely hope you read the rest of our ramblings before you do so, to understand the consequences of your choice. Let's now have a look at what security() is showing you. There is a lot to cover, so buckle up! But before we dig in, one last thing. What is a chart? A chart is a graphic representation of events that occur in markets. As any representation, it is not reality, but rather a model of reality. As Scott Page eloquently states in The Model Thinker : "All models are wrong; many are useful". Having in mind that both chart bars and plots on our charts are imperfect and incomplete renderings of what actually occurred in realtime markets puts us coders in a place from where we can better understand the nature of, and the causes underlying the inevitable compromises necessary to build the data series our code uses, and print chart bars. Traders or coders complaining that charts do not reflect reality act like someone who would complain that the word "dog" is not a real dog. Let's recognize that we are dealing with models here, and try to understand them the best we can. Sure, models can be improved; TradingView is constantly improving the quality of the information displayed on charts, but charts nevertheless remain mere translations. Plots of data fetched through security() being modelized renderings of what occurs at higher timeframes, coders will build more useful and reliable tools for both themselves and traders if they endeavor to perfect their understanding of the abstractions they are working with. We hope this publication helps you in this pursuit. █  FEATURES This script's "Inputs" tab has four settings:  • Repaint : Determines whether the functions will use their repainting or non-repainting mode.   Note that the setting will not affect the behavior of the yellow plot, as it always repaints.  • Source : The source fetched by the security() calls.  • Timeframe : The timeframe used for the security() calls. If it is lower than the chart's timeframe, a warning appears.  • Show timeframe reminder : Displays a reminder of the timeframe after the last bar. █  THE CHART The chart shows two different pieces of information and we want to discuss other topics in this section, so we will be covering:  A — The type of chart bars we are looking at, indicated by the colored band at the top.  B — The plots resulting of calling security() with the close price in different ways.  C — Points of interest on the chart. A — Chart bars The colored band at the top shows the three types of bars that any chart on a live market will print. It is critical for coders to understand the important distinctions between each type of bar:  1 — Gray : Historical bars, which are bars that were already closed when the script was run on them.  2 — Red : Elapsed realtime bars, i.e., realtime bars that have run their course and closed.    The state of script calculations showing on those bars is that of the last time they were made, when the realtime bar closed.  3 — Green : The realtime bar. Only the rightmost bar on the chart can be the realtime bar at any given time, and only when the chart's market is active. Refer to the Pine User Manual's Execution model page for a more detailed explanation of these types of bars. B — Plots The chart shows the result of letting our 5sec chart run for a few minutes with the following settings: "Repaint" = "On" (the default is "Off"), "Source" = `close` and "Timeframe" = 1min. The five lines plotted are the following. They have progressively thinner widths:  1 — Yellow : A normal, repainting security() call.  2 — Silver : Our recommended security() function.  3 — Fuchsia : Our recommended way of achieving the same result as our security() function, for cases when the source used is a function returning a tuple.  4 — White : The method we previously recommended in our MTF Selection Framework , which uses two distinct security() calls.  5 — Black : A lame attempt at fooling traders that MUST be avoided. All lines except the first one in yellow will vary depending on the "Repaint" setting in the script's inputs. The first plot does not change because, contrary to all other plots, it contains no conditional code to adapt to repainting/no-repainting modes; it is a simple security() call showing its default behavior. C — Points of interest on the chart Historical bars do not show actual repainting behavior To appreciate what a repainting security()  call will plot in realtime, one must look at the realtime bar and at elapsed realtime bars, the bars where the top line is green or red on the chart at the top of this page. There you can see how the plots go up and down, following the close value of each successive chart bar making up a single bar of the higher timeframe. You would see the same behavior in "Replay" mode. In the realtime bar, the movement of repainting plots will vary with the source you are fetching: open will not move after a new timeframe opens, low and high will change when a new low or high are found, close will follow the last feed update. If you are fetching a value calculated by a function, it may also change on each update. Now notice how different the plots are on historical bars. There, the plot shows the close of the previously completed timeframe for the whole duration of the current timeframe, until on its last bar the price updates to the current timeframe's close when it is confirmed (if the timeframe's last bar is missing, the plot will only update on the next timeframe's first bar). That last bar is the only one showing where the plot would end if that timeframe's bars had elapsed in realtime. If one doesn't understand this, one cannot properly visualize how his script will calculate in realtime when using repainting. Additionally, as published scripts typically show charts where the script has only run on historical bars, they are, in fact, misleading traders who will naturally assume the script will behave the same way on realtime bars. Non-repainting plots are more accurate on historical bars Now consider this chart, where we are using the same settings as on the chart used to publish this script, except that we have turned "Repainting" off this time: The yellow line here is our reference, repainting line, so although repainting is turned off, it is still repainting, as expected. Because repainting is now off, however, plots on historical bars show the previous timeframe's close until the first bar of a new timeframe, at which point the plot updates. This correctly reflects the behavior of the script in the realtime bar, where because we are offsetting the series by one, we are always showing the previously calculated—and thus confirmed—higher timeframe value. This means that in realtime, we will only get the previous timeframe's values one bar after the timeframe's last bar has elapsed, at the open of the first bar of a new timeframe. Historical and elapsed realtime bars will not actually show this nuance because they reflect the state of calculations made on their close , but we can see the plot update on that bar nonetheless. ► This more accurate representation on historical bars of what will happen in the realtime bar is one of the two key reasons why using non-repainting data is preferable.    The other is that in realtime, your script will be using more reliable data and behave more consistently. Misleading plots Valiant attempts by coders to show non-repainting, higher timeframe data updating earlier than on our chart are futile. If updates occur one bar earlier because coders use the repainting version of the function, then so be it, but they must then also accept that their historical bars are not displaying information that is as accurate. Not informing script users of this is to mislead them. Coders should also be aware that if they choose to use repainting data in realtime, they are sacrificing reliability to speed and may be running a strategy that behaves very differently from the one they backtested, thus invalidating their tests. When, however, coders make what are supposed to be non-repainting plots plot artificially early on historical bars, as in examples "c4" and "c5" of our script, they would want us to believe they have achieved the miracle of time travel. Our understanding of the current state of science dictates that for now, this is impossible. Using such techniques in scripts is plainly misleading, and public scripts using them will be moderated. We are coding trading tools here—not video games. Elementary ethics prescribe that we should not mislead traders, even if it means not being able to show sexy plots. As the great Feynman said: You should not fool the layman when you're talking as a scientist. You can readily appreciate the fantasy plot of "c4", the thinnest line in black, by comparing its supposedly non-repainting behavior between historical bars and realtime bars. After updating—by miracle—as early as the wide yellow line that is repainting, it suddenly moves in a more realistic place when the script is running in realtime, in synch with our non-repainting lines. The "c5" version does not plot on the chart, but it displays in the Data Window. It is even worse than "c4" in that it also updates magically early on historical bars, but goes on to evaluate like the repainting yellow line in realtime, except one bar late. Data Window The Data Window shows the values of the chart's plots, then the values of both the inside and outside offsets used in our calculations, so you can see them change bar by bar. Notice their differences between historical and elapsed realtime bars, and the realtime bar itself. If you do not know about the Data Window, have a look at this essential tool for Pine coders in the Pine User Manual's page on Debugging . The conditional expressions used to calculate the offsets may seem tortuous but their objective is quite simple. When repainting is on, we use this form, so with no offset on all bars: security(ticker, i_timeframe, i_source ) // which is equivalent to: security(ticker, i_timeframe, i_source) When repainting is off, we use two different and inverted offsets on historical bars and the realtime bar: // Historical bars: security(ticker, i_timeframe, i_source ) // Realtime bar (and thus, elapsed realtime bars): security(ticker, i_timeframe, i_source ) The offsets in the first line show how we prevent repainting on historical bars without the need for the `lookahead` parameter. We use the value of the function call on the chart's previous bar. Since values between the repainting and non-repainting versions only differ on the timeframe's last bar, we can use the previous value so that the update only occurs on the timeframe's first bar, as it will in realtime when not repainting. In the realtime bar, we use the second call, where the offsets are inverted. This is because if we used the first call in realtime, we would be fetching the value of the repainting function on the previous bar, so the close of the last bar. What we want, instead, is the data from the previous, higher timeframe bar , which has elapsed and is confirmed, and thus will not change throughout realtime bars, except on the first constituent chart bar belonging to a new higher timeframe. After the offsets, the Data Window shows values for the `barstate.*` variables we use in our calculations. █  NOTES Why are we revisiting security()  ? For four reasons:  1 — We were seeing coders misuse our `f_secureSecurity()` function presented in How to avoid repainting when using security() .    Some novice coders were modifying the offset used with the history-referencing operator in the function, making it zero instead of one,    which to our horror, caused look-ahead bias when used with `lookahead = barmerge.lookahead_on`.    We wanted to present a safer function which avoids introducing the dreaded "lookahead" in the scripts of unsuspecting coders.  2 — The popularity of security() in screener-type scripts where coders need to use the full 40 calls allowed per script made us want to propose    a solid method of allowing coders to offer a repainting/no-repainting choice to their script users with only one security() call.  3 — We wanted to explain why some alternatives we see circulating are inadequate and produce misleading behavior.  4 — Our previous publication on security() focused on how to avoid repainting, yet many other considerations worthy of attention are not related to repainting. Handling tuples When sending function calls that return tuples with security() , our `f_security()` function will not work because Pine does not allow us to use the history-referencing operator with tuple return values. The solution is to integrate the inside offset to your function's arguments, use it to offset the results the function is returning, and then add the outside offset in a reassignment of the tuple variables, after security() returns its values to the script, as we do in our "c2" example. Does it repaint? We're pretty sure Wilder was not asked very often if RSI repainted. Why? Because it wasn't in fashion—and largely unnecessary—to ask that sort of question in the 80's. Many traders back then used daily charts only, and indicator values were calculated at the day's close, so everybody knew what they were getting. Additionally, indicator values were calculated by generally reputable outfits or traders themselves, so data was pretty reliable. Today, almost anybody can write a simple indicator, and the programming languages used to write them are complex enough for some coders lacking the caution, know-how or ethics of the best professional coders, to get in over their heads and produce code that does not work the way they think it does. As we hope to have clearly demonstrated, traders do have legitimate cause to ask if MTF scripts repaint or not when authors do not specify it in their script's description. ► We recommend that authors always use our `f_security()` with `false` as the last argument to avoid repainting when fetching data dependent on OHLCV information. This is the only way to obtain reliable HTF data. If you want to offer users a choice, make non-repainting mode the default, so that if users choose repainting, it will be their responsibility. Non-repainting security() calls are also the only way for scripts to show historical behavior that matches the script's realtime behavior, so you are not misleading traders. Additionally, non-repainting HTF data is the only way that non-repainting alerts can be configured on MTF scripts, as users of MTF scripts cannot prevent their alerts from repainting by simply configuring them to trigger on the bar's close. Data feeds A chart at one timeframe is made up of multiple feeds that mesh seamlessly to form one chart. Historical bars can use one feed, and the realtime bar another, which brokers/exchanges can sometimes update retroactively so that elapsed realtime bars will reappear with very slight modifications when the browser's tab is refreshed. Intraday and daily chart prices also very often originate from different feeds supplied by brokers/exchanges. That is why security() calls at higher timeframes may be using a completely different feed than the chart, and explains why the daily high value, for example, can vary between timeframes. Volume information can also vary considerably between intraday and daily feeds in markets like stocks, because more volume information becomes available at the end of day. It is thus expected behavior—and not a bug—to see data variations between timeframes. Another point to keep in mind concerning feeds it that when you are using a repainting security() plot in realtime, you will sometimes see discrepancies between its plot and the realtime bars. An artefact revealing these inconsistencies can be seen when security() plots sometimes skip a realtime chart bar during periods of high market activity. This occurs because of races between the chart and the security() feeds, which are being monitored by independent, concurrent processes. A blue arrow on the chart indicates such an occurrence. This is another cause of repainting, where realtime bar-building logic can produce different outcomes on one closing price. It is also another argument supporting our recommendation to use non-repainting data. Alternatives There is an alternative to using security() in some conditions. If all you need are OHLC prices of a higher timeframe, you can use a technique like the one Duyck demonstrates in his security free MTF example - JD script. It has the great advantage of displaying actual repainting values on historical bars, which mimic the code's behavior in the realtime bar—or at least on elapsed realtime bars, contrary to a repainting security() plot. It has the disadvantage of using the current chart's TF data feed prices, whereas higher timeframe data feeds may contain different and more reliable prices when they are compiled at the end of the day. In its current state, it also does not allow for a repainting/no-repainting choice. When `lookahead` is useful When retrieving non-price data, or in special cases, for experiments, it can be useful to use `lookahead`. One example is our Backtesting on Non-Standard Charts: Caution! script where we are fetching prices of standard chart bars from non-standard charts. Warning users Normal use of security() dictates that it only be used at timeframes equal to or higher than the chart's. To prevent users from inadvertently using your script in contexts where it will not produce expected behavior, it is good practice to warn them when their chart is on a higher timeframe than the one in the script's "Timeframe" field. Our `f_tfReminderAndErrorCheck()` function in this script does that. It can also print a reminder of the higher timeframe. It uses one security() call. Intrabar timeframes security() is not supported by TradingView when used with timeframes lower than the chart's. While it is still possible to use security() at intrabar timeframes, it then behaves differently. If no care is taken to send a function specifically written to handle the successive intrabars, security() will return the value of the last intrabar in the chart's timeframe, so the last 1H bar in the current 1D bar, if called at "60" from a "D" chart timeframe. If you are an advanced coder, see our FAQ entry on the techniques involved in processing intrabar timeframes. Using intrabar timeframes comes with important limitations, which you must understand and explain to traders if you choose to make scripts using the technique available to others. Special care should also be taken to thoroughly test this type of script. Novice coders should refrain from getting involved in this. █  TERMINOLOGY Timeframe Timeframe , interval and resolution are all being used to name the concept of timeframe. We have, in the past, used "timeframe" and "resolution" more or less interchangeably. Recently, members from the Pine and PineCoders team have decided to settle on "timeframe", so from hereon we will be sticking to that term. Multi-timeframe (MTF) Some coders use "multi-timeframe" or "MTF" to name what are in fact "multi-period" calculations, as when they use MAs of progressively longer periods. We consider that a misleading use of "multi-timeframe", which should be reserved for code using calculations actually made from another timeframe's context and using security() , safe for scripts like Duyck's one mentioned earlier, or TradingView's Relative  Volume  at  Time , which use a user-selected timeframe as an anchor to reset calculations. Calculations made at the chart's timeframe by varying the period of MAs or other rolling window calculations should be called "multi-period", and "MTF-anchored" could be used for scripts that reset calculations on timeframe boundaries. Colophon Our script was written using the PineCoders Coding Conventions for Pine . The description was formatted using the techniques explained in the How We Write and Format Script Descriptions PineCoders publication. Snippets were lifted from our MTF Selection Framework , then massaged to create the `f_tfReminderAndErrorCheck()` function. █  THANKS Thanks to apozdnyakov for his help with the innards of security() . Thanks to bmistiaen for proofreading our description. Look first. Then leap.
อินดิเคเตอร์ Pine Script®
โดย PineCoders
61
CHOP Zone Entry Strategy + DMI/PSAR ExitThis is a Strategy with associated visual indicators and Long/Short and Reverse/Close Position Alerts for the Choppiness Index (CHOP) . It is used to determine if the market is choppy (trading sideways) or not choppy (trading within a trend in either direction). CHOP is not directional, so a DMI script was ported into this strategy to allow for trend confirmation and direction determination; it consists of an Average Directional Index (ADX) , Plus Directional Indicator (+DI) and Minus Directional Indicator (-DI) . In addition, a Parabolic SAR is also included to act as a trailing stop during any strong trends. Development Notes --------------------------- This indicator, and most of the descriptions below, were derived largely from the TradingView reference manual. Feedback and suggestions for improvement are more than welcome, as well are recommended Input settings and best practices for use. www.tradingview.com www.tradingview.com www.tradingview.com Recommend using the below DMI and PSAR indicators in conjunction with this script to fully visualize and understand how entry and exit conditions are chosen. Variable inputs should correlate between the scripts for uniformity and visual compatibility. THANKS to LazyBear and his Momentum Squeeze script for helping me quickly develop a momentum state model for coloring the Chop line by trend. Strategy Description --------------------------- CHOP produces values that determine whether the market is choppy or trending . The closer the value is to 100 , the higher the choppiness levels , while the closer it is to 0 , the stronger the market is trending . Territories for both levels, and their associated upper and lower thresholds, are popularly defined using the Fibonacci Retracements, 61.8 and 38.2. Basic Use --------------------------- CHOP is often used to confirm the market condition to help you stay out of sideways markets and only enter when there is movement or imminent explosions. When readings are above the upper threshold, continued sideways movement may be expected, while readings below the lower threshold are typically indicative of a continuing trend. It is also used to anticipate upcoming trendiness changes, with the general belief that extended periods of consolidation (sideways movement) are followed by extended periods of strong, trending, directional movement, and vice versa. One limitation in this index is that you must be cautious in deciding whether the range or trend will likely continue, or if it will reverse. Confidence in price action and trend is higher when two or more indicators are in agreement -- while this strategy combines CHOP with both DMI and PSAR, we would still recommend pairing with other indicators to determine entry or exit trade opportunities. Recommend also choosing 'Once Per Bar Close' when creating alerts. Inputs --------------------------- Strategy Direction - an option to only trade Short, Long, Both, or only in the direction of the Trend (Follow Trend is the Default). Sensitivity - an incremental variable to test whether the past n candles are in the same trend state before triggering a delayed long or short alert (1 is the Default). Can help filter out noise and reduces active alerts. Show Chop Index - two visual styles are provided for user preference, a visible Chop line with a background overlay, or a compact column and label only view. Chop Lookback Period - the time period to be used in calculating CHOP (14 is the Default). Chop Offset - changing this number will move the CHOP either forwards or backwards relative to the current market (0 is the Default). Smooth Chop Line and Length - if enabled, the entered time period will be used in calculating a smooth average of the index (Enabled and 4 are the Defaults). Color Line to Trend Direction - toggles whether the index line is colored to visually depict the current trend direction (Enabled is the Default). Color Background - toggles the visibility of a background color based on the index state (Enabled is the Default). Enable DMI Option - if enabled, then entry will be confirmed by and dependent on the ADX Key Level, with any close or reversal confirmed by both ADX and +/-DI to determine whether there is a strong trend present or not (Enabled is the Default). ADX Smoothing - the time period to be used in calculating the ADX which has a smoothing component (14 is the Default). DI Length - the time period to be used in calculating the DI (14 is the Default). ADX Key Level - any trade with the ADX above the key level is a strong indicator that it is trending (23 to 25 is the suggested setting). Enable PSAR Option - enables trailing stop loss orders (Enabled is the Default). PSAR Start - the starting value for the Acceleration Force (0.015 is our chosen Default, 0.02 is more common). PSAR Increment - the increment in which the Acceleration Force will move (0.001 is our chosen Default, 0.02 is more common). PSAR Max Value - the maximum value of the Acceleration Factor (0.2 is the Default). Color Candles Option - an option to transpose the CHOP condition levels to the main candle bars. Note that the outer red and green border will still be distinguished by whether each individual candle is bearish or bullish during the specified timeframe. Note too that if both DMI and PSAR are deselected, then close determinations will default to a CHOP reversal strategy (e.g., close long when below 38.2 and close short when above 61.8). Though if either DMI or PSAR are enabled, then the CHOP reversal for close determination will automatically be disabled. Indicator Visuals --------------------------- For the candle colors, black indicates tight chop (45 to 55), yellow is loose chop (38.2 to 45 and 55 to 61.8), dark purple is trending down (< 38.2), and dark blue is trending up (> 61.8). The background color has additional shades to differentiate a wider range of more levels… • < 30 is dark purple • 30 to 38.2 is purple • 38.2 to 45 is light purple • 45 to 55 is black • 55 to 61.8 is light blue • 61.8 to 70 is blue • > 70 is dark blue Long, Short, Close, and Reverse labels are plotted on the Chop line, which itself can be colored based on the trend. The chop line can also be hidden for a clean and compact, columnar view, which is my preferred option (see example image below). Visual cues are intended to improve analysis and decrease interpretation time during trading, as well as to aid in understanding the purpose of this strategy and how its inclusion can benefit a comprehensive trading plan. DMI and Trend Strength --------------------------- To analyze trend strength, the focus should be on the ADX line and not the +DI or -DI lines.  An ADX reading above 25 indicates a strong trend , while a reading below 20 indicates a weak or non-existent trend .  A reading between those two values would be considered indeterminable. Though what is truly a strong trend or a weak trend depends on the financial instrument being examined; historical analysis can assist in determining appropriate values. DMI exits trade when ADX is below the user selected key level (e.g., default is 25) and when the +/- DI lines cross (e.g., -DI > +DI exits long position and +DI > -DI exits short position). PSAR and Trailing Stop --------------------------- PSAR is a time and price based indicator that excels at measuring direction and duration, though not the actual strength of a trend, which is why we use this in conjunction with DMI. It is also included in this script as a trailing stop option to maximize gains during strong trends and to mitigate any false ADX strengthening signals. This creates a parabola that is located below the candle during a Bullish trend and above during a Bearish trend. A buy or reversal is signaled when the price crosses above or below the Parabolic SAR. Long/Short Entry --------------------------- 1. CHOP must be over 61.8 (long) or under 38.2 (short). 2. If DMI is enabled, then the ADX signal line must be above the user selected Key Level (default is 25). 3. If Sensitivity is selected, then that past candle must meet the criteria in step 1, as well as all the intermediate candles in between. 4. If "Follow Trend" is selected and PSAR is enabled, then a long position can only open when the momentum and PSAR are in an uptrend, or short when both are in a downtrend, to include all intermediate candles if the Sensitivity option is set on a past candle. Close/Reverse --------------------------- 1. If DMI is enabled, then a close flag will be raised when the ADX signal drops below the Key Level (of 25), and -DI crosses over +DI (if long), or +DI crosses over -DI (if short). 2. If PSAR is enabled, then a close flag will be raised when the current trend state is opposite the last state. 3. If both DMI and PSAR are disabled, then a close flag will be raised if the Chop line drops under 38.2 (if long) or goes over 61.8 (if short). 4. If a Long or Short Entry is triggered on the same candle as any of the above close flags, then the position will be reversed, else the position will be closed. Strategy Alerts --------------------------- 1. Long Entry 2. Short Entry 3. Reverse 4. Close The provided backtest result is based on a position sizing of 10% equity with 100k initial capital. When testing SPX, disabling the DMI performed the best, but EURUSD performed poorly without it enabled, and TSLA had a small reduction in net profit. Timeframe likewise differed between commodities with TSLA performing best at 30M, SPX at 15M, and EURUSD at 4H. I do not plan on using this as a standalone strategy, but I also was expecting better results with the inclusion of EMI and PSAR to compliment the CHOP. Key elements of this script will likely be included in future, more holistic strategies. Disclaimer --------------------------- Past performance may not be indicative of future results. Due to various factors, including changing market conditions, the strategy may no longer perform as well as in historical backtesting. This post and the script are not intended to provide any financial advice. Trade at your own risk. No known repainting, though there may be if an offset is introduced in the Inputs. I did my best not to code any other variables that repaint, but cannot fully attest to this fact.
กลยุทธ์ Pine Script®
โดย IronCasper
4
[blackcat] L2 Ehlers Rocket RSI IndicatorLevel: 2 Background John F. Ehlers introuced Rocket RSI Indicator in May, 2018. Function In “RocketRSI—A Solid Propellant For Your Rocket Science Trading” in May, 2018, John Ehlers introduces a new take on the classic RSI indicator originally developed by J. Welles Wilder. Ehlers begins by introducing a new version of the RSI based on a simple accumulation of up and down closes rather than averages. To this he applies a Fisher transform. He tells us that the resultant output is statistically significant spikes that indicate cyclic turning points with precision. With this indicator, overbought and oversold conditions are clear: ## Oversold Entry Condition: Indicator crosses value (RocketRSI crosses over -2.00) ## Overbought Exit Condition: Indicator crosses value (RocketRSI crosses under 2.00) Note the used “crosses under 2.00” for the exit condition, rather than “crosses above 2.00.” This lets the winning positions ride further, and resulted in a better overall return in backtesting. Key Signal RocketRSI --> Ehlers Rocket RSI Indicator fast line Trigger --> Ehlers Rocket RSI Indicator 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 90th script for Blackcat1402 John F. Ehlers Week publication. Readme In real life, I am a prolific inventor. I have successfully applied for more than 60 international and regional patents in the past 12 years. But in the past two years or so, I have tried to transfer my creativity to the development of trading strategies. Tradingview is the ideal platform for me. I am selecting and contributing some of the hundreds of scripts to publish in Tradingview community. Welcome everyone to interact with me to discuss these interesting pine scripts. The scripts posted are categorized into 5 levels according to my efforts or manhours put into these works. Level 1 : interesting script snippets or distinctive improvement from classic indicators or strategy. Level 1 scripts can usually appear in more complex indicators as a function module or element. Level 2 : composite indicator/strategy. By selecting or combining several independent or dependent functions or sub indicators in proper way, the composite script exhibits a resonance phenomenon which can filter out noise or fake trading signal to enhance trading confidence level. Level 3 : comprehensive indicator/strategy. They are simple trading systems based on my strategies. They are commonly containing several or all of entry signal, close signal, stop loss, take profit, re-entry, risk management, and position sizing techniques. Even some interesting fundamental and mass psychological aspects are incorporated. Level 4 : script snippets or functions that do not disclose source code. Interesting element that can reveal market laws and work as raw material for indicators and strategies. If you find Level 1~2 scripts are helpful, Level 4 is a private version that took me far more efforts to develop. Level 5 : indicator/strategy that do not disclose source code. private version of Level 3 script with my accumulated script processing skills or a large number of custom functions. I had a private function library built in past two years. Level 5 scripts use many of them to achieve private trading strategy.
อินดิเคเตอร์ Pine Script®
โดย blackcat1402
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.
อินดิเคเตอร์ Pine Script®
โดย DrCatherineHalsey
17
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.
อินดิเคเตอร์ Pine Script®
โดย DrCatherineHalsey
13
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.
อินดิเคเตอร์ Pine Script®
โดย DrCatherineHalsey
12
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.
อินดิเคเตอร์ Pine Script®
โดย DrCatherineHalsey
13
QuantNomad - Heikin-Ashi PSAR AlertsUsing this script you can create alerts for my Heikin-Ashi PSAR Strategy: When creating alerts use "Once Per Bar Close" in parameters. #################### Disclaimer Please remember that past performance may not be indicative of future results. Due to various factors, including changing market conditions, the strategy may no longer perform as good as in historical backtesting. This post and the script don’t provide any financial advice.
อินดิเคเตอร์ Pine Script®
โดย QuantNomad
6
QuantNomad - Heikin-Ashi PSAR StrategyContinue experimenting with different combinations of strategies. Here is the PSAR Strategy calculated based on HA candles. HA is already calculated inside the script, do not apply it to HA candles. Strategy is calculated based on 25% equity invested with 0.1% commission. #################### Disclaimer Please remember that past performance may not be indicative of future results. Due to various factors, including changing market conditions, the strategy may no longer perform as good as in historical backtesting. This post and the script don’t provide any financial advice.
กลยุทธ์ Pine Script®
โดย QuantNomad
21
ATR Parabolic SAR Strategy [QuantNomad]I created a version of Parabolic SAR when I accelerate it not based on the difference from the extreme point but based on current ATR. So the idea is that for a more volatile market it should move faster. Performance is calculated based on 25% equity invested and 0.1% commission. What do you think about it? Does it make sense to do something like that? Do you have in mind other ways I can accelerate it when the market starts to be more volatile? Disclaimer Please remember that past performance may not be indicative of future results. Due to various factors, including changing market conditions, the strategy may no longer perform as good as in historical backtesting. This post and the script don’t provide any financial advice.
กลยุทธ์ Pine Script®
โดย QuantNomad
22
Custom Screener with Alerts [QuantNomad]Some time ago I published an example of simple custom screener in PineScript: The only thing this screener did is created a dynamic label with screener output. Recently TradingView announced alerts from the strategy with the possibility to add custom messages to alerts. So using it I was able to create a bit more advanced screener which sends results as alert messages. With tools like Alertatron, you can easily redirect them to Telegram if you want. It works for 40 symbols (limitation of the number of security calls). To create your own screener you need to change only screenerFunc. The logic of this function is very simple, it outputs value you want to display in screener and condition based on which your screener should filter your stocks. To create alerts for this screener create an alert from strategy and use {{strategy.order.alert_message}} as alert message. Do you know now how to make this screener better? Let me know. Disclaimer Please remember that past performance may not be indicative of future results. Due to various factors, including changing market conditions, the strategy may no longer perform as good as in historical backtesting. This post and the script don’t provide any financial advice.
กลยุทธ์ Pine Script®
โดย QuantNomad
72
Schaff Trend Cycle + Double MAThis strategy uses two different moving averages to determine a trend. It opens a position on a pullback from a trend. Conditions for buy signal are: ►Crossover out of Shaff Trend Cycle's extreme levels ►The price is above its short period exponential moving average. ►A short period exponential moving average is above a long period exponential moving average. *Conditions for sell are the opposite. All in all, I don't think it needs to be on your chart but it can be optimized and even successful on some timeframes. Shaff Trend Cycle solution was provided by @everget, I converted his script to Pine v.4, added exponential averages and created an algorithm for backtesting.
กลยุทธ์ Pine Script®
โดย OrcChieftain
1
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!
กลยุทธ์ Pine Script®
โดย LonesomeTheBlue
62
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
กลยุทธ์ Pine Script®
โดย Bitduke
3
expected range STRATEGYThis is the strategy version of "expected range STUDY". The buy and sell signals are generated with the study version, but what is displayed on the chart is different. Here, the PnL of each trade is shown on the chart, as well as the peak profit point of each trade up till the present. Black areas represent take profit and waiting for the next trade to start. Green = long. Red = short. Set to take profit at 53% and stoploss is set to -7%. Having a stoploss trigger does not put a black area on the chart. For the XBTUSD 2 hour chart, but use it however you like on whatever chart for backtesting. Enjoy. Don't get rekt. A good backtest doesn't mean a good forward test. Use at your own risk.
กลยุทธ์ Pine Script®
โดย Jomy
9
expected range STUDYThis is an indicator that measures how much price movement (low to high) we've seen in a set of 1 bar back, 2 bars back, 3 bars back, 5 bars back, 8 bars back using the Fibonacci sequence up to 89 bars back, and then measures how low or high within each range we are, sort of like giving a rating of 0 for sitting on the lower Bollinger Band and a rating of 100 for sitting on the higher Bollinger band. It combines all the data and weights the data by the historical strength of signal from each length of bands. It's been tuned to a 2 hour XBTUSD chart, but it could be used on other things and other timeframes too. Some tweaking would be needed, though. The final result works more like a trend following indictor than and indicator that tries to pick an exact trend reversal point. However, you're free to use it how you want. Frequently you get a nice red or green spike up showing you when the bottom or top is in, but sometimes those spikes are just the start of an extended down move or up move. On the chart, a buy (long) signal is generated when the green line crosses up above the orange line. To make it extra clear the background is green when you should be long. A sell (short) signal is generated with the red line crosses up above the yellow line. The background will be red when you should be short. If the background is black, it's indicating a profit of over 53% was taken and it's waiting for another trade to start. Up to you to take profit or keep riding your trade. For XBTUSD trades, a full take profit on any trade exceeding 53% gains works nice (on 1x leverage) and a stoploss of -7% works quite nicely too. One could use this on up to 2x leverage but I wouldn't recommend going much higher. Have fun. Trade carefully. Don't get rekt. I will release the "expected range STRATEGY" to go along with this so you can do your own backtesting. Disclaimer: I haven't tested the alerts, but they should work. Use at your own risk.
อินดิเคเตอร์ Pine Script®
โดย Jomy
1