立即開始

在腳本中搜尋"如何用wind搜索股票的发行价和份数"

Oscillator Workbench — Chart [LucF]█  OVERVIEW This indicator uses an on-chart visual framework to help traders with the interpretation of any oscillator's behavior. The advantage of using this tool is that you do not need to know all the ins and outs of a particular oscillator such as RSI, CCI, Stochastic, etc. Your choice of oscillator and settings in this indicator will change its visuals, which allows you to evaluate different configurations in the context of how the workbench models oscillator behavior. My hope is that by using the workbench, you may come up with an oscillator selection and settings that produce visual cues you find useful in your trading. The workbench works on any symbol and timeframe. It uses the same presentation engine as my Delta ​Volume Channels indicator; those already familiar with it will feel right at home here. █  CONCEPTS Oscillators An oscillator is any signal that moves up and down a centerline. The centerline value is often zero or 50. Because the range of oscillator values is different than that of the symbol prices we look at on our charts, it is usually impossible to display an oscillator on the chart, so we typically put oscillators in a separate pane where they live in their own space. Each oscillator has its own profile and properties that dictate its behavior and interpretation. Oscillators can be bounded , meaning their values oscillate between fixed values such as 0 to 100 or +1 to -1, or unbounded when their maximum and minimum values are undefined. Oscillator weight How do you display an oscillator's value on a chart showing prices when both values are not on the same scale? The method I use here converts the oscillator's value into a percentage that is used to weigh a reference line. The weight of the oscillator is calculated by maintaining its highest and lowest value above and below its centerline since the beginning of the chart's history. The oscillator's relative position in either of those spaces is then converted to a percentage, yielding a positive or negative value depending on whether the oscillator is above or below its centerline. This method works equally well with bounded and unbounded oscillators. Oscillator Channel The ​​oscillator channel is the space between two moving averages: the reference line and a weighted version of that line. The reference line is a moving average of a type, source and length which you select. The weighted line uses the same settings, but it averages the oscillator-weighted price source. The weight applied to the source of the reference line can also include the relative size of the bar's ​volume in relation to previous bars. The effect of this is that the oscillator's weight on bars with higher total ​volume will carry greater weight than those with lesser ​volume. The ​oscillator channel can be in one of four states, each having its corresponding color:  • Bull (teal): The weighted line is above the reference line.  • Strong bull (lime): The bull condition is fulfilled and the bar's close is above the reference line and both the reference and the weighted lines are rising.  • Bear (maroon): The weighted line is below the reference line.  • Strong bear (pink): The bear condition is fulfilled and the bar's close is below the reference line and both the reference and the weighted lines are falling. Divergences In the context of this indicator, a divergence is any bar where the slope of the reference line does not match that of the weighted line. No directional bias is assigned to divergences when they occur. You can also choose to define divergences as differences in polarity between the oscillator's slope and the polarity of close-to-close values. This indicator's divergences are designed to identify transition levels. They have no polarity; their ​bullish/​bearish bias is determined by the behavior of price relative to the divergence channel after the divergence channel is built. Divergence Channel The divergence channel is the space between two levels (by default, the bar's low and high ) saved when divergences occur. When price has breached a channel and a new divergence occurs, a new channel is created. Until that new channel is breached, bars where additional divergences occur will expand the channel's levels if the bar's price points are outside the channel. Price breaches of the divergence channel will change its state. Divergence channels can be in one of five different states:  • Bull (teal): Price has breached the channel to the upside.  • Strong bull (lime): The bull condition is fulfilled and the ​oscillator channel is in the strong bull state.  • Bear (maroon): Price has breached the channel to the downside.  • Strong bear (pink): The bear condition is fulfilled and the ​oscillator channel is in the strong bear state.  • Neutral (gray): The channel has not been breached. █  HOW TO USE THE INDICATOR Load the indicator on an active chart (see here if you don't know how). The default configuration displays:  • The Divergence channel's levels.  • Bar colors using the state of the ​oscillator channel. The default settings use:  • RSI as the oscillator, using the close source and a length of 20 bars.  • An Arnaud-Legoux moving average on the close and a length of 20 bars as the reference line.  • The weighted version of the reference line uses only the oscillator's weight, i.e., without the relative ​volume's weight.   The weighted line is capped to three standard deviations of the reference.  • The divergence channel's levels are determined using the high and low of the bars where divergences occur.   Breaches of the channel require a bar's low to move above the top of the channel, and the bar's high to move below the channel's bottom. No markers appear on the chart; if you want to create alerts from this script, you will need first to define the conditions that will trigger the markers, then create the alert, which will trigger on those same conditions. To learn more about how to use this indicator, you must understand the concepts it uses and the information it displays, which requires reading this description. There are no videos to explain it. █  FEATURES The script's inputs are divided in five sections: "Oscillator", "Oscillator channel", "Divergence channel", "Bar Coloring" and "Marker/Alert Conditions". Oscillator This is where you configure the oscillator you want to study. Thirty oscillators are available to choose from, but you can also use an oscillator from another indicator that is on your chart, if you want. When you select an external indicator's plot as the oscillator, you must also specify the value of its centerline. Oscillator Channel Here, you control the visibility and colors of the reference line, its weighted version, and the oscillator channel between them. You also specify what type of moving average you want to use as a reference line, its source and its length. This acts as the ​oscillator channel's baseline. The weighted line is also a moving average of the same type and length as the reference line, except that it will be calculated from the weighted version of the source used in the reference line. By default, the weighted line is capped to three standard deviations of the reference line. You can change that value, and also elect to cap using a multiple of ATR instead. The cap provides a mechanism to control how far the weighted line swings from the reference line. This section is also where you can enable the relative ​volume component of the weight. Divergence Channel This is where you control the appearance of the divergence channel and the key price values used in determining the channel's levels and breaching conditions. These choices have an impact on the behavior of the channel. More generous level prices like the default low and high selection will produce more conservative channels, as will the default choice for breach prices. In this section, you can also enable a mode where an attempt is made to estimate the channel's bias before price breaches the channel. When it is enabled, successive increases/decreases of the channel's top and bottom levels are counted as new divergences occur. When one count is greater than the other, a bull/bear bias is inferred from it. You can also change the detection mode of divergences, and choose to display a mark above or below bars where divergences occur. Bar Coloring You specify here:  • The method used to color chart bars, if you choose to do so.  • If you want to hollow out the bodies of bars where ​volume has not increased since the last bar. Marker/Alert Conditions Here, you specify the conditions that will trigger up or down markers. The trigger conditions can include a combination of state transitions of the ​oscillator and the divergence channels. The triggering conditions can be filtered using a variety of conditions. Configuring the marker conditions is necessary before creating an alert from this script, as the alert will use the marker conditions to trigger. Realtime values will repaint, as is usually the case with oscillators, but markers only appear on bar closes, so they will not repaint. Keep in mind, when looking at markers on historical bars, that they are positioned on the bar when it closes — NOT when it opens. Raw values The raw values calculated by this script can be inspected using the Data Window, including the oscillator's value and the weights. █  INTERPRETATION Except when mentioned otherwise, this section's charts use the indicator's default settings, with different visual components turned on or off. The aim of the ​ oscillator channel is to provide a visual representation of an oscillator's general behavior. The simplest characteristic of the channel is its bull/bear state, determined by whether the weighted line is above or below the reference line. One can then distinguish between its bull and strong bull states, as transitions from strong bull to bull states will generally happen when trends are losing steam. While one should not infer a reversal from such transitions, they can be a good place to tighten stops. Only time will tell if a reversal will occur. One or more divergences will often occur before reversals. This shows the oscillator channel, with the reference line and the thicker, weighted line: The nature of the divergence channel 's design makes it particularly adept at identifying consolidation areas if its settings are kept on the conservative side. The divergence channel will also reveal transition areas. A gray divergence channel should usually be considered a no-trade zone. More adventurous traders can use the oscillator ​ channel to orient their trade entries if they accept the risk of trading in a neutral divergence channel, which by definition will not have been breached by price. This show only the divergence channels: This chart shows divergence channels and their levels, and colors bars on divergences and on the state of the oscillator channel, which is not visible on the chart: If your charts are already busy with other stuff you want to hold on to, you could consider using only the chart bar coloring component of this indicator. Here we only color bars using the combined state of the oscillator and divergence channel, and we do not color the bodies of bars where ​volume has not increased. Note that my chart's settings do not color the candle bodies: At its simplest, one way to use this indicator would be to look for overlaps of the strong bull/bear colors in both the ​oscillator channel and a divergence channel, as these identify points where price is breaching the divergence channel when the oscillator's state is consistent with the direction of the breach. Tip One way to use the Workbench is to combine it with my Delta ​Volume Channels indicator. If both indicators use the same MA as a reference line, you can display its delta ​volume channel instead of the oscillator channel. This chart shows such a setup. The Workbench displays its divergence levels, the weighted reference line using the default ​RSI oscillator, and colors bars on divergences. The ​DV Channels indicator only displays its delta ​volume channel, which uses the same MA as the workbench for its baseline. This way you can ascertain the ​volume delta situation in contrast with the visuals of the Workbench: █  LIMITATIONS  • For some of the oscillators, assumptions are made concerning their different parameters when they are more complex than just a source and length.   See the `oscCalc()` function in this indicator's code for all the details, and ask me in a comment if you can't find the information you need.  • When an oscillator using ​volume is selected and no ​volume information is available for the chart's symbol, an error will occur.  • The method I use to convert an oscillator's value into a percentage is fragile in the early history of datasets   because of the nascent expression of the oscillator's range during those early bars. █  NOTES Working with this workbench This indicator is called a workbench for a reason; it is designed for traders interested in exploring its behavior with different oscillators and settings, in the hope they can come up with a setup that suits their trading methodology. I cannot tell you which setup is the best because its setup should be compatible with your trading methodology, which may require faster or slower transitions, thus different configurations of the settings affecting the calculations of the divergence channels. For Pine Script™ Coders  • This script uses the new overload of the fill() function which now makes it possible to do vertical gradients in Pine. I use it for both channels displayed by this script.  • I use the new arguments for plot() 's `display` parameter to control where the script plots some of its values,   namely those I only want to appear in the script's status line and in the Data Window.  • I used my ta library for some of the oscillator calculations and helper functions.  • I also used TradingView's ta library for other oscillator calculations.  • I wrote my script using the revised recommendations in the Style Guide from the Pine v5 User Manual.
Pine Script®指標
由LucF提供
86
Nadaraya-Watson: Rational Quadratic Kernel (Non-Repainting)What is Nadaraya–Watson Regression? Nadaraya–Watson Regression is a type of Kernel Regression, which is a non-parametric method for estimating the curve of best fit for a dataset. Unlike Linear Regression or Polynomial Regression, Kernel Regression does not assume any underlying distribution of the data. For estimation, it uses a kernel function, which is a weighting function that assigns a weight to each data point based on how close it is to the current point. The computed weights are then used to calculate the weighted average of the data points. How is this different from using a Moving Average? A Simple Moving Average is actually a special type of Kernel Regression that uses a Uniform (Retangular) Kernel function. This means that all data points in the specified lookback window are weighted equally. In contrast, the Rational Quadratic Kernel function used in this indicator assigns a higher weight to data points that are closer to the current point. This means that the indicator will react more quickly to changes in the data. Why use the Rational Quadratic Kernel over the Gaussian Kernel? The Gaussian Kernel is one of the most commonly used Kernel functions and is used extensively in many Machine Learning algorithms due to its general applicability across a wide variety of datasets. The Rational Quadratic Kernel can be thought of as a Gaussian Kernel on steroids; it is equivalent to adding together many Gaussian Kernels of differing length scales. This allows the user even more freedom to tune the indicator to their specific needs. The formula for the Rational Quadratic function is: K(x, x') = (1 + ||x - x'||^2 / (2 * alpha * h^2))^(-alpha) where x and x' data are points, alpha is a hyperparameter that controls the smoothness (i.e. overall "wiggle") of the curve, and h is the band length of the kernel. Does this Indicator Repaint? No, this indicator has been intentionally designed to NOT repaint. This means that once a bar has closed, the indicator will never change the values in its plot. This is useful for backtesting and for trading strategies that require a non-repainting indicator. Settings: Bandwidth. This is the number of bars that the indicator will use as a lookback window. Relative Weighting Parameter. The alpha parameter for the Rational Quadratic Kernel function. This is a hyperparameter that controls the smoothness of the curve. A lower value of alpha will result in a smoother, more stretched-out curve, while a lower value will result in a more wiggly curve with a tighter fit to the data. As this parameter approaches 0, the longer time frames will exert more influence on the estimation, and as it approaches infinity, the curve will become identical to the one produced by the Gaussian Kernel. Color Smoothing. Toggles the mechanism for coloring the estimation plot between rate of change and cross over modes.
Pine Script®指標
由jdehorty提供
56
Ehlers Two-Pole Predictor [Loxx]Ehlers Two-Pole Predictor is a new indicator by John Ehlers . The translation of this indicator into PineScript™ is a collaborative effort between @cheatcountry and I. The following is an excerpt from "PREDICTION" , by John Ehlers Niels Bohr said “Prediction is very difficult, especially if it’s about the future.”. Actually, prediction is pretty easy in the context of technical analysis . All you have to do is to assume the market will behave in the immediate future just as it has behaved in the immediate past. In this article we will explore several different techniques that put the philosophy into practice. LINEAR EXTRAPOLATION Linear extrapolation takes the philosophical approach quite literally. Linear extrapolation simply takes the difference of the last two bars and adds that difference to the value of the last bar to form the prediction for the next bar. The prediction is extended further into the future by taking the last predicted value as real data and repeating the process of adding the most recent difference to it. The process can be repeated over and over to extend the prediction even further. Linear extrapolation is an FIR filter, meaning it depends only on the data input rather than on a previously computed value. Since the output of an FIR filter depends only on delayed input data, the resulting lag is somewhat like the delay of water coming out the end of a hose after it supplied at the input. Linear extrapolation has a negative group delay at the longer cycle periods of the spectrum, which means water comes out the end of the hose before it is applied at the input. Of course the analogy breaks down, but it is fun to think of it that way. As shown in Figure 1, the actual group delay varies across the spectrum. For frequency components less than .167 (i.e. a period of 6 bars) the group delay is negative, meaning the filter is predictive. However, the filter has a positive group delay for cycle components whose periods are shorter than 6 bars. Figure 1 Here’s the practical ramification of the group delay: Suppose we are projecting the prediction 5 bars into the future. This is fine as long as the market is continued to trend up in the same direction. But, when we get a reversal, the prediction continues upward for 5 bars after the reversal. That is, the prediction fails just when you need it the most. An interesting phenomenon is that, regardless of how far the extrapolation extends into the future, the prediction will always cross the signal at the same spot along the time axis. The result is that the prediction will have an overshoot. The amplitude of the overshoot is a function of how far the extrapolation has been carried into the future. But the overshoot gives us an opportunity to make a useful prediction at the cyclic turning point of band limited signals (i.e. oscillators having a zero mean). If we reduce the overshoot by reducing the gain of the prediction, we then also move the crossing of the prediction and the original signal into the future. Since the group delay varies across the spectrum, the effect will be less effective for the shorter cycles in the data. Nonetheless, the technique is effective for both discretionary trading and automated trading in the majority of cases. EXPLORING THE CODE Before we predict, we need to create a band limited indicator from which to make the prediction. I have selected a “roofing filter” consisting of a High Pass Filter followed by a Low Pass Filter. The tunable parameter of the High Pass Filter is HPPeriod. Think of it as a “stone wall filter” where cycle period components longer than HPPeriod are completely rejected and cycle period components shorter than HPPeriod are passed without attenuation. If HPPeriod is set to be a large number (e.g. 250) the indicator will tend to look more like a trending indicator. If HPPeriod is set to be a smaller number (e.g. 20) the indicator will look more like a cycling indicator. The Low Pass Filter is a Hann Windowed FIR filter whose tunable parameter is LPPeriod. Think of it as a “stone wall filter” where cycle period components shorter than LPPeriod are completely rejected and cycle period components longer than LPPeriod are passed without attenuation. The purpose of the Low Pass filter is to smooth the signal. Thus, the combination of these two filters forms a “roofing filter”, named Filt, that passes spectrum components between LPPeriod and HPPeriod. Since working into the future is not allowed in EasyLanguage variables, we need to convert the Filt variable to the data array XX. The data array is first filled with real data out to “Length”. I selected Length = 10 simply to have a convenient starting point for the prediction. The next block of code is the prediction into the future. It is easiest to understand if we consider the case where count = 0. Then, in English, the next value of the data array is equal to the current value of the data array plus the difference between the current value and the previous value. That makes the prediction one bar into the future. The process is repeated for each value of count until predictions up to 10 bars in the future are contained in the data array. Next, the selected prediction is converted from the data array to the variable “Prediction”. Filt is plotted in Red and Prediction is plotted in yellow. The Predict Extrapolation indicator is shown below for the Emini S&P Futures contract using the default input parameters. Filt is plotted in red and Predict is plotted in yellow. The crossings of the Predict and Filt lines provide reliable buy and sell timing signals. There is some overshoot for the shorter cycle periods, for example in February and March 2021, but the only effect is a late timing signal. Further reducing the gain and/or reducing the BarsFwd inputs would provide better timing signals during this period. Figure 2. Predict Extrapolation Provides Reliable Timing Signals I have experimented with other FIR filters for predictions, but found none that had a significant advantage over linear extrapolation. MESA MESA is an acronym for Maximum Entropy Spectral Analysis. Conceptually, it removes spectral components until the residual is left with maximum entropy. It does this by forming an all-pole filter whose order is determined by the selected number of coefficients. It maximally addresses the data within the selected window and ignores all other data. Its resolution is determined only by the number of filter coefficients selected. Since the resulting filter is an IIR filter, a prediction can be formed simply by convolving the filter coefficients with the data. MESA is one of the few, if not the only way to practically determine the coefficients of a higher order IIR filter. Discussion of MESA is beyond the scope of this article. TWO POLE IIR FILTER While the coefficients of a higher order IIR filter are difficult to compute without MESA, it is a relatively simple matter to compute the coefficients of a two pole IIR filter. (Skip this paragraph if you don’t care about DSP) We can locate the conjugate pole positions parametrically in the Z plane in polar coordinates. Let the radius be QQ and the principal angle be 360 / P2Period. The first order component is 2*QQ*Cosine(360 / P2Period) and the second order component is just QQ2. Therefore, the transfer response becomes: H(z) = 1 / (1 - 2*QQ*Cosine(360 / P2Period)*Z-1 + QQ2*Z-2) By mixing notation we can easily convert the transfer response to code. Output / Input = 1 / (1 - 2*QQ*Cosine(360 / P2Period)* + QQ2* ) Output - 2*QQ*Cosine(360 / P2Period)*Output + QQ2*Output = Input Output = Input + 2*QQ*Cosine(360 / P2Period)*Output - QQ2*Output The Two Pole Predictor starts by computing the same “roofing filter” design as described for the Linear Extrapolation Predictor. The HPPeriod and LPPeriod inputs adjust the roofing filter to obtain the desired appearance of an indicator. Since EasyLanguage variables cannot be extended into the future, the prediction process starts by loading the XX data array with indicator data up to the value of Length. I selected Length = 10 simply to have a convenient place from which to start the prediction. The coefficients are computed parametrically from the conjugate pole positions and are normalized to their sum so the IIR filter will have unity gain at zero frequency. The prediction is formed by convolving the IIR filter coefficients with the historical data. It is easiest to see for the case where count = 0. This is the initial prediction. In this case the new value of the XX array is formed by successively summing the product of each filter coefficient with its respective historical data sample. This process is significantly different from linear extrapolation because second order curvature is introduced into the prediction rather than being strictly linear. Further, the prediction is adaptive to market conditions because the degree of curvature depends on recent historical data. The prediction in the data array is converted to a variable by selecting the BarsFwd value. The prediction is then plotted in yellow, and is compared to the indicator plotted in red. The Predict 2 Pole indicator is shown above being applied to the Emini S&P Futures contract for most of 2021. The default parameters for the roofing filter and predictor were used. By comparison to the Linear Extrapolation prediction of Figure 2, the Predict 2 Pole indicator has a more consistent prediction. For example, there is little or no overshoot in February or March while still giving good predictions in April and May. Input parameters can be varied to adjust the appearance of the prediction. You will find that the indicator is relatively insensitive to the BarsFwd input. The P2Period parameter primarily controls the gain of the prediction and the QQ parameter primarily controls the amount of prediction lead during trending sections of the indicator. TAKEAWAYS 1. A more or less universal band limited “roofing filter” indicator was used to demonstrate the predictors. The HPPeriod input parameter is used to control whether the indicator looks more like a trend indicator or more like a cycle indicator. The LPPeriod input parameter is used to control the smoothness of the indicator. 2. A linear extrapolation predictor is formed by adding the difference of the two most recent data bars to the value of the last data bar. The result is considered to be a real data point and the process is repeated to extend the prediction into the future. This is an FIR filter having a one bar negative group delay at zero frequency, but the group delay is not constant across the spectrum. This variable group delay causes the linear extrapolation prediction to be inconsistent across a range of market conditions. 3. The degree of prediction by linear extrapolation can be controlled by varying the gain of the prediction to reduce the overshoot to be about the same amplitude as the peak swing of the indicator. 4. I was unable to experimentally derive a higher order FIR filter predictor that had advantages over the simple linear extrapolation predictor. 5. A Two Pole IIR predictor can be created by parametrically locating the conjugate pole positions. 6. The Two Pole predictor is a second order filter, which allows curvature into the prediction, thus mitigating overshoot. Further, the curvature is adaptive because the prediction depends on previously computed prediction values. 7. The Two Pole predictor is more consistent over a range of market conditions. ADDITIONS Loxx's Expanded source types: Library for expanded source types: Explanation for expanded source types: Three different signal types: 1) Prediction/Filter crosses; 2) Prediction middle crosses; and, 3) Filter middle crosses. Bar coloring to color trend. Signals, both Long and Short. Alerts, both Long and Short.
Pine Script®指標
由loxx提供
4
Normalized, Variety, Fast Fourier Transform Explorer [Loxx]Normalized, Variety, Fast Fourier Transform Explorer demonstrates Real, Cosine, and Sine Fast Fourier Transform algorithms. This indicator can be used as a rule of thumb but shouldn't be used in trading. What is the Discrete Fourier Transform? In mathematics, the discrete Fourier transform (DFT) converts a finite sequence of equally-spaced samples of a function into a same-length sequence of equally-spaced samples of the discrete-time Fourier transform (DTFT), which is a complex-valued function of frequency. The interval at which the DTFT is sampled is the reciprocal of the duration of the input sequence. An inverse DFT is a Fourier series, using the DTFT samples as coefficients of complex sinusoids at the corresponding DTFT frequencies. It has the same sample-values as the original input sequence. The DFT is therefore said to be a frequency domain representation of the original input sequence. If the original sequence spans all the non-zero values of a function, its DTFT is continuous (and periodic), and the DFT provides discrete samples of one cycle. If the original sequence is one cycle of a periodic function, the DFT provides all the non-zero values of one DTFT cycle. What is the Complex Fast Fourier Transform? The complex Fast Fourier Transform algorithm transforms N real or complex numbers into another N complex numbers. The complex FFT transforms a real or complex signal x in the time domain into a complex two-sided spectrum X in the frequency domain. You must remember that zero frequency corresponds to n = 0, positive frequencies 0 < f < f_c correspond to values 1 ≤ n ≤ N/2 −1, while negative frequencies −fc < f < 0 correspond to N/2 +1 ≤ n ≤ N −1. The value n = N/2 corresponds to both f = f_c and f = −f_c. f_c is the critical or Nyquist frequency with f_c = 1/(2*T) or half the sampling frequency. The first harmonic X corresponds to the frequency 1/(N*T). The complex FFT requires the list of values (resolution, or N) to be a power 2. If the input size if not a power of 2, then the input data will be padded with zeros to fit the size of the closest power of 2 upward. What is Real-Fast Fourier Transform? Has conditions similar to the complex Fast Fourier Transform value, except that the input data must be purely real. If the time series data has the basic type complex64, only the real parts of the complex numbers are used for the calculation. The imaginary parts are silently discarded. What is the Real-Fast Fourier Transform? In many applications, the input data for the DFT are purely real, in which case the outputs satisfy the symmetry X(N-k)=X(k) and efficient FFT algorithms have been designed for this situation (see e.g. Sorensen, 1987). One approach consists of taking an ordinary algorithm (e.g. Cooley–Tukey) and removing the redundant parts of the computation, saving roughly a factor of two in time and memory. Alternatively, it is possible to express an even-length real-input DFT as a complex DFT of half the length (whose real and imaginary parts are the even/odd elements of the original real data), followed by O(N) post-processing operations. It was once believed that real-input DFTs could be more efficiently computed by means of the discrete Hartley transform (DHT), but it was subsequently argued that a specialized real-input DFT algorithm (FFT) can typically be found that requires fewer operations than the corresponding DHT algorithm (FHT) for the same number of inputs. Bruun's algorithm (above) is another method that was initially proposed to take advantage of real inputs, but it has not proved popular. There are further FFT specializations for the cases of real data that have even/odd symmetry, in which case one can gain another factor of roughly two in time and memory and the DFT becomes the discrete cosine/sine transform(s) (DCT/DST). Instead of directly modifying an FFT algorithm for these cases, DCTs/DSTs can also be computed via FFTs of real data combined with O(N) pre- and post-processing. What is the Discrete Cosine Transform? A discrete cosine transform ( DCT ) expresses a finite sequence of data points in terms of a sum of cosine functions oscillating at different frequencies. The DCT , first proposed by Nasir Ahmed in 1972, is a widely used transformation technique in signal processing and data compression. It is used in most digital media, including digital images (such as JPEG and HEIF, where small high-frequency components can be discarded), digital video (such as MPEG and H.26x), digital audio (such as Dolby Digital, MP3 and AAC ), digital television (such as SDTV, HDTV and VOD ), digital radio (such as AAC+ and DAB+), and speech coding (such as AAC-LD, Siren and Opus). DCTs are also important to numerous other applications in science and engineering, such as digital signal processing, telecommunication devices, reducing network bandwidth usage, and spectral methods for the numerical solution of partial differential equations. The use of cosine rather than sine functions is critical for compression, since it turns out (as described below) that fewer cosine functions are needed to approximate a typical signal, whereas for differential equations the cosines express a particular choice of boundary conditions. In particular, a DCT is a Fourier-related transform similar to the discrete Fourier transform (DFT), but using only real numbers. The DCTs are generally related to Fourier Series coefficients of a periodically and symmetrically extended sequence whereas DFTs are related to Fourier Series coefficients of only periodically extended sequences. DCTs are equivalent to DFTs of roughly twice the length, operating on real data with even symmetry (since the Fourier transform of a real and even function is real and even), whereas in some variants the input and/or output data are shifted by half a sample. There are eight standard DCT variants, of which four are common. The most common variant of discrete cosine transform is the type-II DCT , which is often called simply "the DCT". This was the original DCT as first proposed by Ahmed. Its inverse, the type-III DCT , is correspondingly often called simply "the inverse DCT" or "the IDCT". Two related transforms are the discrete sine transform ( DST ), which is equivalent to a DFT of real and odd functions, and the modified discrete cosine transform (MDCT), which is based on a DCT of overlapping data. Multidimensional DCTs ( MD DCTs) are developed to extend the concept of DCT to MD signals. There are several algorithms to compute MD DCT . A variety of fast algorithms have been developed to reduce the computational complexity of implementing DCT . One of these is the integer DCT (IntDCT), an integer approximation of the standard DCT ,: ix, xiii, 1, 141–304  used in several ISO /IEC and ITU-T international standards. What is the Discrete Sine Transform? In mathematics, the discrete sine transform (DST) is a Fourier-related transform similar to the discrete Fourier transform (DFT), but using a purely real matrix. It is equivalent to the imaginary parts of a DFT of roughly twice the length, operating on real data with odd symmetry (since the Fourier transform of a real and odd function is imaginary and odd), where in some variants the input and/or output data are shifted by half a sample. A family of transforms composed of sine and sine hyperbolic functions exists. These transforms are made based on the natural vibration of thin square plates with different boundary conditions. The DST is related to the discrete cosine transform (DCT), which is equivalent to a DFT of real and even functions. See the DCT article for a general discussion of how the boundary conditions relate the various DCT and DST types. Generally, the DST is derived from the DCT by replacing the Neumann condition at x=0 with a Dirichlet condition. Both the DCT and the DST were described by Nasir Ahmed T. Natarajan and K.R. Rao in 1974. The type-I DST (DST-I) was later described by Anil K. Jain in 1976, and the type-II DST (DST-II) was then described by H.B. Kekra and J.K. Solanka in 1978. Notable settings windowper = period for calculation, restricted to powers of 2: "16", "32", "64", "128", "256", "512", "1024", "2048", this reason for this is FFT is an algorithm that computes DFT (Discrete Fourier Transform) in a fast way, generally in 𝑂(𝑁⋅log2(𝑁)) instead of 𝑂(𝑁2). To achieve this the input matrix has to be a power of 2 but many FFT algorithm can handle any size of input since the matrix can be zero-padded. For our purposes here, we stick to powers of 2 to keep this fast and neat. read more about this here: Cooley–Tukey FFT algorithm SS = smoothing count, this smoothing happens after the first FCT regular pass. this zeros out frequencies from the previously calculated values above SS count. the lower this number, the smoother the output, it works opposite from other smoothing periods Fmin1 = zeroes out frequencies not passing this test for min value Fmax1 = zeroes out frequencies not passing this test for max value barsback = moves the window backward Inverse = whether or not you wish to invert the FFT after first pass calculation Related indicators Real-Fast Fourier Transform of Price Oscillator STD-Stepped Fast Cosine Transform Moving Average Real-Fast Fourier Transform of Price w/ Linear Regression Variety RSI of Fast Discrete Cosine Transform Additional reading A Fast Computational Algorithm for the Discrete Cosine Transform by Chen et al. Practical Fast 1-D DCT Algorithms With 11 Multiplications by Loeffler et al. Cooley–Tukey FFT algorithm Ahmed, Nasir (January 1991). "How I Came Up With the Discrete Cosine Transform". Digital Signal Processing. 1 (1): 4–5. doi:10.1016/1051-2004(91)90086-Z. DCT-History - How I Came Up With The Discrete Cosine Transform Comparative Analysis for Discrete Sine Transform as a suitable method for noise estimation
Pine Script®指標
由loxx提供
3
Levinson-Durbin Autocorrelation Extrapolation of Price [Loxx]Levinson-Durbin Autocorrelation Extrapolation of Price is an indicator that uses the Levinson recursion or Levinson–Durbin recursion algorithm to predict price moves. This method is commonly used in speech modeling and prediction engines. What is Levinson recursion or Levinson–Durbin recursion? Is a linear algebra prediction analysis that is performed once per bar using the autocorrelation method with a within a specified asymmetric window. The autocorrelation coefficients of the window are computed and converted to LP coefficients using the Levinson algorithm. The LP coefficients are then transformed to line spectrum pairs for quantization and interpolation. The interpolated quantized and unquantized filters are converted back to the LP filter coefficients to construct the synthesis and weighting filters for each bar. Data inputs Source Settings: -Loxx's Expanded Source Types. You typically use "open" since open has already closed on the current active bar LastBar - bar where to start the prediction PastBars - how many bars back to model LPOrder - order of linear prediction model; 0 to 1 FutBars - how many bars you want to forward predict Things to know Normally, a simple moving average is caculated on source data. I've expanded this to 38 different averaging methods using Loxx's Moving Avreages. This indicator repaints Included Bar color muting Further reading Implementing the Levinson-Durbin Algorithm on the StarCore™ SC140/SC1400 Cores LevinsonDurbin_G729 Algorithm, Calculates LP coefficients from the autocorrelation coefficients. Intel® Integrated Performance Primitives for Intel® Architecture Reference Manual
Pine Script®指標
由loxx提供
5
Lower TimeFrame Mini Candle[rsu]Lower Timeframe mini Candle It is used to display the candle chart status of the small period 30m and 5m period through One Chart in the large period (day, or 8h, Week), The period and window offset of the left and right windows can be set to suit your desktop resolution requirements. Alert Alert can be added to trigger when the stock price touches 200ma, please set the alert in the Day period. It will trigger the alert at both 5m and 30m period.
Pine Script®指標
由rsu9111提供
2
DominantCycleCollection of Dominant Cycle estimators. Length adaptation used in the Adaptive Moving Averages and the Adaptive Oscillators try to follow price movements and accelerate/decelerate accordingly (usually quite rapidly with a huge range). Cycle estimators, on the other hand, try to measure the cycle period of the current market, which does not reflect price movement or the rate of change (the rate of change may also differ depending on the cycle phase, but the cycle period itself usually changes slowly). This collection may become encyclopaedic, so if you have any working cycle estimator, drop me a line in the comments below. Suggestions are welcome. Currently included estimators are based on the work of John F. Ehlers mamaPeriod(src, dynLow, dynHigh) MESA Adaptation - MAMA Cycle   Parameters:      src : Series to use      dynLow : Lower bound for the dynamic length      dynHigh : Upper bound for the dynamic length   Returns: Calculated period Based on MESA Adaptive Moving Average by John F. Ehlers Performs Hilbert Transform Homodyne Discriminator cycle measurement Unlike MAMA Alpha function (in LengthAdaptation library), this does not compute phase rate of change Introduced in the September 2001 issue of Stocks and Commodities Inspired by the @everget implementation: Inspired by the @anoojpatel implementation: paPeriod(src, dynLow, dynHigh, preHP, preSS, preHP) Pearson Autocorrelation   Parameters:      src : Series to use      dynLow : Lower bound for the dynamic length      dynHigh : Upper bound for the dynamic length      preHP : Use High Pass prefilter (default)      preSS : Use Super Smoother prefilter (default)      preHP : Use Hann Windowing prefilter   Returns: Calculated period Based on Pearson Autocorrelation Periodogram by John F. Ehlers Introduced in the September 2016 issue of Stocks and Commodities Inspired by the @blackcat1402 implementation: Inspired by the @rumpypumpydumpy implementation: Corrected many errors, and made small speed optimizations, so this could be the best implementation to date (still slow, though, so may revisit in future) High Pass and Super Smoother prefilters are used in the original implementation dftPeriod(src, dynLow, dynHigh, preHP, preSS, preHP) Discrete Fourier Transform   Parameters:      src : Series to use      dynLow : Lower bound for the dynamic length      dynHigh : Upper bound for the dynamic length      preHP : Use High Pass prefilter (default)      preSS : Use Super Smoother prefilter (default)      preHP : Use Hann Windowing prefilter   Returns: Calculated period Based on Spectrum from Discrete Fourier Transform by John F. Ehlers Inspired by the @blackcat1402 implementation: High Pass, Super Smoother and Hann Windowing prefilters are used in the original implementation phasePeriod(src, dynLow, dynHigh, preHP, preSS, preHP) Phase Accumulation   Parameters:      src : Series to use      dynLow : Lower bound for the dynamic length      dynHigh : Upper bound for the dynamic length      preHP : Use High Pass prefilter (default)      preSS : Use Super Smoother prefilter (default)      preHP : Use Hamm Windowing prefilter   Returns: Calculated period Based on Dominant Cycle from Phase Accumulation by John F. Ehlers High Pass and Super Smoother prefilters are used in the original implementation doAdapt(type, src, len, dynLow, dynHigh, chandeSDLen, chandeSmooth, chandePower, preHP, preSS, preHP) Execute a particular Length Adaptation or Dominant Cycle Estimator from the list   Parameters:      type : Length Adaptation or Dominant Cycle Estimator type to use      src : Series to use      len : Reference lookback length      dynLow : Lower bound for the dynamic length      dynHigh : Upper bound for the dynamic length      chandeSDLen : Lookback length of Standard deviation for Chande's Dynamic Length      chandeSmooth : Smoothing length of Standard deviation for Chande's Dynamic Length      chandePower : Exponent of the length adaptation for Chande's Dynamic Length (lower is smaller variation)      preHP : Use High Pass prefilter for the Estimators that support it (default)      preSS : Use Super Smoother prefilter for the Estimators that support it (default)      preHP : Use Hann Windowing prefilter for the Estimators that support it   Returns: Calculated period (float, not limited) doEstimate(type, src, dynLow, dynHigh, preHP, preSS, preHP) Execute a particular Dominant Cycle Estimator from the list   Parameters:      type : Dominant Cycle Estimator type to use      src : Series to use      dynLow : Lower bound for the dynamic length      dynHigh : Upper bound for the dynamic length      preHP : Use High Pass prefilter for the Estimators that support it (default)      preSS : Use Super Smoother prefilter for the Estimators that support it (default)      preHP : Use Hann Windowing prefilter for the Estimators that support it   Returns: Calculated period (float, not limited)
Pine Script®腳本庫
由lastguru提供
6
Weighted Standard Deviation BandsLinearly weighted standard deviations over linearly weighted mean. The rationale of the study can be deduced from my latest publications where I go deeper into explaining the benefits of linear weighting, but in short, I can remind that by using linear weighting we are able to increase the information gain by communicating the sequential nature of time series to the calculations via linear weighting. Note, that multiplier parameters can take both negative and positive values resulting in ability to have, for example, 1st and 6th weighted standard deviations higher than the weighted mean. Despite the modification of the classic standard deviation formula, I assume that mathematical qualities of standard deviation will hold due to the fact we can alternately weight the window itself, and then apply the classic standard deviation over the weighted window. In both cases, the results will be the same. Aight that was too formal, but your short strangles should be happy Here is it, for you
Pine Script®指標
由gorx1提供
2
Volatility Percentile🎲 Volatility is an important measure to be included in trading plan and strategy. Strategies have varied outcome based on volatility of the instruments in hand. For example, 🚩 Trend following strategies work better on low volatility instruments and reversal patterns work better in high volatility instruments. It is also important for us to understand the median volatility of an instrument before applying particular strategy strategy on them. 🚩 Different instrument will have different volatility range. For instance crypto currencies have higher volatility whereas major currency pairs have lower volatility with respect to their price. It is also important for us to understand if the current volatility of the instrument is relatively higher or lower based on the historical values. This indicator is created to study and understand more about volatility of the instruments. ⬜ Process ▶ Volatility metric used here is ATR as percentage of price. Other things such as bollinger bandwidth etc can also be used with few changes. ▶ We use array based counters to count ATR values in different range. For example, if we are measuring ATR range based on precision 2, we will use array containing 10000 values all initially set to 0 which act as 10000 buckets to hold counters of different range. But, based on the ATR percentage range, they will be incremented. Let's say, if atr percent is 2, then 200th element of the array is increased by 1. ▶ When we do this for every bar, we have array of counters which has the division on how many bars had what range of atr percent. ▶ Using this array, we can calculate how many bars had atr percent more than current value, how many had less than current value, and how many bars in history has same atr percent as current value. ▶ With these information, we can calculate the percentile of atr percentage value. We can also plot a detailed table mentioning what percentile each range map to. ⬜ Settings ▶ ATR Parameters - this include Moving average type and Length for atr calculation. ▶ Rounding type refers to rounding ATR percentage value before we put into certain bucket. For example, if ATR percentage 2.7, round or ceil will make it 3, whereas floor will make it 2 which may fall into different buckets based on the precision selected. ▶ Precision refers to how much detailed the range should be. If precision set to 0, then we get array of 100 to collect the range where each value will represent a range of 1%. Similarly precision of 1 will lead to array of 1000 with each item representing range of 0.1. Default value used is 2 which is also the max precision possible in this script. This means, we use array of 10000 to track the range and percentile of the ATR. ▶ Display Settings - Inverse when applied track percentile with respect to lowest value of ATR instead of high. By default this is set to false. Other two options allow users to enable stats table. When detailed stats are enabled, ATR Percentile as plot is hidden. ▶ Table Settings - Allows users to select set size and coloring options. ▶ Indicator Time Window - Allow users to select particular timeframe instead of all available bars to run the study. By default windows are disabled. Users can chose start and end time individually. Indicator display components can be described as below:
Pine Script®指標
由Trendoscope提供
9
tickerTracker MFI OscillatorDid you ever want to have a neat indicator window in line with your chart showing a different ticker? tickerTracker is a Money Flow Index (MFI) oscillator. The Money Flow Index (MFI) is a technical oscillator that uses price and volume for identifying overbought or oversold conditions in an asset. More or less, everything is connected in the market. The tickerTracker lets you see what is happening with another ticker that you have connected a correlation between them. For my example here, I'm using COIN in the main chart with the tickerTracker displaying BTC, QQQ and COIN Money Flow Index (MFI) in its window. As the end user, you can customize the colors, the length input and the ticker. Like any other indicator, the shorter length input, the more quickly responsive and the longer the length input, the smoother curve print. Default Values: MFI Length = 13 Chart ticker = white SPY = white QQQ = blue IWM = yellow DIA = orange BTC/USD = yellow ETH/USD = green SOL/USD = purple ADA/USD = red Do your own due diligence, your risk is 100% your responsibility. This is for educational and entertainment purposes only. You win some or you learn some. Consider being charitable with some of your profit to help humankind. Good luck and happy trading friends... *3x lucky 7s of trading* 7pt Trading compass: Price action, entry/exit Volume average/direction Trend, patterns, momentum Newsworthy current events Revenue Earnings Balance sheet 7 Common mistakes: +5% portfolio trades, capital risk management Beware of analyst's motives Emotions & Opinions FOMO : bad timing, the market is ruthless, be shrewd Lack of planning & discipline Forgetting restraint Obdurate repetitive errors, no adaptation 7 Important tools: Trading View app!, Brokerage UI Accurate indicators & settings Wide screen monitor/s Trading log (pencil & graph paper) Big, organized desk Reading books, playing chess Sorted watch-list Checkout my indicators: Fibonacci VIP - volume Fibonacci MA7 - price pi RSI - trend momentum TTC - trend channel AlertiT - notification tickerTracker - MFI Oscillator www.tradingview.com
Pine Script®指標
由Options360提供
2
Auto Phivots PP S/R Log /Lin V2 [DM]Greetings, I cover version two since the code has had great changes. This script has two time frames with a separate symbol from the main window. Alerts for the two different configurable time frames. Van use for a big ranges or small and Log Scales. The colors, extensions, thickness, style of the lines and the labels are completely configurable. With a few small adjustments it can be used in a separate window with another symbol Enjoy BigfOOts
Pine Script®指標
由dgmoon提供
4
TFO + ATR Strategy with Trailing Stop LossThis strategy is an experiment to learn what happens when The Trend Flex Oscillator (by Dr. John Ehlers) is used in conjunction with a volatility indicator like ATR. It was designed with cryptocurrency trading in mind. The way I coded this experiment makes it unsuitable for bear market conditions. When applied to a bull market, this trend-following strategy will open long positions when oversold price action appear to be reversing. It will typically close a position within a few days unless it gets caught in a bear market, in which case it holds on for dear life. I have tried to make back-testing very simple, but you should never trust it. It's merely and interesting tool for adjusting the many parameters that I've made editable in the configuration window. Those values include the ATR and TFO parameters, as well as setting a trailing stop loss. When closing a position, the strategy can optionally be told to ignore the trend analysis and only obey the trailing stop loss value. I've made an attempt to allow the user to define the minimum profit necessary to allow the strategy to close all all positions. In my observations, the 2H candlestick charts seem to produce the best results, although the parameters of the strategy could theoretically be adjusted to suit other time periods. In summary... This strategy has a bias for HODL (Holds on to Losses) meaning that it provides NO STOP LOSS protection! Also note that the default behavior is designed for up to 15 open long orders, and executes one order to close them all at once. Opening a long position is predicated on The Trend Flex Oscillator (TFO) rising after being oversold, and ATR above a certain volatility threshold. Closing a long is handled either by TFO showing overbought while above a certain ATR level, or the Trailing Stop Loss. Pick one or both. If the strategy is allowed to sell before a Trailing Stop Loss is triggered, you can set a "must exceed %". Do not mistake this for a stop loss. Short positions are not supported in this version. Back-testing should NEVER be considered an accurate representation of actual trading results. // portions © allanster (date window code) // portions © Dr. John Ehlers (Trend Flex Oscillator) This code is provided for educational purposes only. The results of this strategy should not be considered investment advice. The user of this script acknowledges that it can result in serious financial loss when used as a trading tool
Pine Script®策略
由Chart0bserver提供
1
Scanner/Screener of Over 40 Coins Per Script I am very scatter-brained by nature and sporadic in my thought processes but if these benefit the community and ya'll ask for more perhaps I will get better and even out a tad....probably not....but you never know. Firstly, allow me to apologize to all the vet/more sophisticated coders out there whose eyes and brains might just be overly taxed due to my poor coding structure. Im just getting started for the first time in ANY sort of coding...so cut me a little slack. Also, if anyone sees any mistakes or the functionality is not as I proclaimed, PLEASE do let me know. In these past 12mo of me learning my 1st coding language (Pinescript) I would say that I have been intently focused on creating all types/sorts of scanners/screeners. Ive always hoped to be a benefit to the community as I was always SO grateful to those who have come before me that have led me to the little bit of progress I have made with Pinescript. This script is not necessarily something that should be traded with as it is just a thrown together example showing a scanner/screener whose results produce plot outputs (ie, Rate of Change / oscillators as well / etc) and how they can be used in the alert system so that only 1 alert has to be set per iteration of the script but more importantly how to use/scan/screen with over 40 coins per script. My intent is not to trick anyone here. So to be PERFECTLY CLEAR, more than 40 coins CAN in fact be screened/scanned from one script (here I am doing all of KUCOIN's Margin Coins...72 total I look at)...BUT...(heres the catch) it must be added to the chart however many times EQUAL to the amount of "sets" you have in your script. (Heres the limitation by TV) There cannot be more than 40 coins in each "set". The less coins you have per set, the quicker the script will startup and run, thus, the quicker alerts will be received if automating the process. Though, if you only have the free plan and can only have MAX 3 indicators per chart then the MAX you can screen at a time is 120 coins if you use 40 coins per set. So, this is the first one I would like to introduce. For this one your screener/scanner must be using some sort of plots as output that is being screened for. (original inspiration of ALL my variations mainly come from @QuantNomad, @daveatt, and @LonesomeTheBlue (and a few others I may be forgetting at the moment). Thanks for the inspiration through countless publications that ya'll have created for us in the community. Some of my variations are more complex/elegant than others but there are MANY very different ones that I would like to share with the community. If you leave a comment and wonder why I have not responded but did so to every comment around yours...see if you are one of the individuals in this next few sentences...and if you are then perhaps someone else would like to waste their time responding to your comment...but basically, if you don't want to spend the time helping yourself by reading the title, description section, AND the comments section (at least scanning them) then I am MOST DEFINITELY not going to help you down your path of destruction that is most likely soon to be your blown-up trading account. I was called a "masochist" after asking for guidance on if its worth the headache to publish anything on TV bc there will NO DOUBT be comments that'll make me wish I didn't (ie. someone CLEARLY not reading the description (or seemingly even the title sometimes) bc they make a comment that has been explicitly addressed, or someone asking to rebuild the code compatible for another charting software or whatnot, or how about those asking if it repaints (this one is almost always addressed in the comments section but I can understand this question more than others as Im only 1 yr into learning any sort of coding for the first time in the beginning I saw people ask on EVERY script about if it repainted and it was worrisome at the lest (esp bc I didn't even understand what it was not so long ago, or my favorite...what TF it works best on...these people CLEARLY need not be trading yet if your still asking questions as such...Ill end it there). Point being, Ive got some truly VERY useful scripts that I want to share and as long as these people don't make me regret doing so in the beginning, then whats mine...will soon be yours. Though, I will take a little time between the releases. YOU GUYS (TV and its community) ARE AWESOME (most of you anyways ;) MUCH LOVE, ChasinAlts (1) INPUTS Here is where the "sets" come in. I am looking at all of KUCOIN's Margin Coins (72 of them at least) so am splitting them up into 3 sets/iterations and a copy of the script must be added equal to amount of "sets" you have here. This is the ONLY workaround I have found to be able to scan/screen with more than 40 coins per script (due to TV's limitation of 40 Security Calls per script) ***So for everyone saying it's impossible scan more than 40 Coins per scipt...it' MOST DEFINITELY possible....BUT ONLY by adding this script multiple times on the chart and selecting 1 of each of the "sets" in the script settings via the chart window. To save the much needed room you must push each iteration of the script into 1 window and merging the scales of each into 1 scale(ie. "Scale A") within the settings of the script name on the chart(3 horizontal dots) (2) FUNCTION (2.1) COLORIDs This is just to set up all my Colors of plots which are being matched with their respective labels. I have a diff color for each of the 72 coins Im plotting so Im telling the function, "depending on which set of coins I select...give me this color out of the colors I input later into the function" (2.2) TICKERID CONSTRUCTION I construct the tickerID this way so that the labels on my plots have only the Coin's name vs the label having the (Exchange Name):(Coin Name)(Base Pair Name). If you are using more than 1 Base pair (ie. XRP/BTC and XRP/USDT and XRP/ETH) OR more than 1 Exchange OR want your plots to show MORE THAN just the Trading Coin's name, then the tickerID MUST BE constructed differently (2.3) SECURITY CALL & PLOT OUTPUT VARIABLES If using a Higher Time Frame in Security Call then it MUST BE adjusted to permit or dissallow repainting if you so wish (BEYOND THE SCOPE OF THIS PUBLICATION so Do Your Own Researh). If your MAIN LOGIC is more complex than simply using a TV built-in function), THEN it MUST BE built into its own function outside of this function and called on within the "expression" slot of this Security Call OR can also be built into this function and called on in the "expression" slot of this Security call (BEYOND THE SCOPE OF THIS PUB SO DYOR). FURTHERMORE...when you are using a series(ie high/low/close/open/hl2/etc) / bar_index / time / etc that will be specific to the Coin/tickerID, then they MUST BE explicitly used within the "expression" slot of the Security Function when calling on your Main Logic or else it will pull the series/time/bar_index/etc from the Coin that the Chart is presently on (BEYOND THE SCOPE OF THIS PUB SO DYOR) (2.4) PLOT LABEL This is the Plot's Label that will be next to the end of the plot on the LAST bar_index. ***Notice in the "text" slot of the label I have "_coin" (without the quotes obviously)...this is where have JUST the Coin's name comes into effect on the label vs the (Exchange Name):(Coin Name)(Base Pair Name) which looks MUCH cleaner (2.5) ALERT LOGIC / ALERT LABEL Your alert logic need not be as complex as this... I just wanted to create a decent enough timing for this system and wanted to simply print the labels displaying which coin produced the alert at the same time the alerts would go off. Alert is set up to Trigger Bullish when the ROC is below the Threshold and _chg > _chg X=length of bars inputted in "Rising/Falling Length" setting and vise versa for Bearish Alerts. If _chg plot only goes past threshold for a VERY few amount of bars NOT providing enough time for initial Alert to trigger, then alert/label triggers on crossing of threshold back towards 0(zero). ONLY 1 alert needs to be set per script to be able to scan ALL 72 of the coins as I have them in this script. Timing of Alert is inline with the name label printed past the thresholds. (3) VARIABLES FROM MAIN FUNCTION This is the tuple of the Main Function that outputs the variables from 3 lines up to be able to plot the lines and color them according to the colors on the labels. *** As of now, we CANNOT plot from within the function so MUST BE done this way to produce the variables and colors needed. The plots are the ONLY thing in this script that cannot be executed from within the function (4) LINE PLOTS ALL output variables from our Main Function are used here for the line plots
Pine Script®指標
由A_Traders_Edge提供
11
TASC 2021.12 Directional Movement w/Hann█  OVERVIEW Presented here is code for the "Directional Movement w/Hann" indicator originally conceived by John ​Ehlers. The code is also published in the December 2021 issue of Trader's Tips by Technical Analysis of Stocks & ​Commodities (TASC) magazine. Ehlers continues here his exploration of the application of Hann windowing to conventional trading indicators. █  FEATURES The rolling length can be modified in the script's inputs, as well as the width of the line. █  NOTES Calculations The calculation starts with the classic definition of PlusDM and MinusDM. These directional movements are summed in an exponential moving average (EMA). Then, this EMA is further smoothed in a finite impulse response (FIR) filter using Hann window coefficients over the calculation period. Background The DMI and ADX indicators were designed by J. Welles Wilder and presented in his "New Concepts in Technical Trading Systems" book published in 1978. Join TradingView!
Pine Script®指標
由PineCodersTASC提供
7
Ehlers Deviation Scaled Super Smoother [CC]The Deviation Scaled Super Smoother was created by John Ehlers and this is an excellent moving average that changes direction very quickly and can keep up with the current underlying trend. This indicator works by applying a Hann Windowed Moving Average to the stock's momentum and scaling that by the Root Mean Square and then using that value in the input for a Super Smoother . I have included strong buy and sell signals in addition to normal ones so lighter colors are normal signals and darker colors are strong ones. Buy when the line turns green and sell when it turns red. Let me know if there are any other scripts you would like to see me publish!
Pine Script®指標
由cheatcountry提供
7
Augmented Dickey–Fuller (ADF) mean reversion testThe augmented Dickey-Fuller test (ADF) is a statistical test for the tendency of a price series sample to mean revert . The current price of a mean-reverting series may tell us something about the next move (as opposed, for example, to a geometric Brownian motion). Thus, the ADF test allows us to spot market inefficiencies and potentially exploit this information in a trading strategy. Mathematically, the mean reversion property means that the price change in the next time period is proportional to the difference between the average price and the current price. The purpose of the ADF test is to check if this proportionality constant is zero. Accordingly, the ADF test statistic is defined as the estimated proportionality constant divided by the corresponding standard error. In this script, the ADF test is applied in a rolling window with a user-defined lookback length. The calculated values ​​of the ADF test statistic are plotted as a time series. The more negative the test statistic, the stronger the rejection of the hypothesis that there is no mean reversion. If the calculated test statistic is less than the critical value calculated at a certain confidence level (90%, 95%, or 99%), then the hypothesis of a mean reversion is accepted (strictly speaking, the opposite hypothesis is rejected). Input parameters: Source - The source of the time series being tested. Length - The number of points in the rolling lookback window. The larger sample length makes the ADF test results more reliable. Maximum lag - The maximum lag included in the test, that defines the order of an autoregressive process being implied in the model. Generally, a non-zero lag allows taking into account the serial correlation of price changes. When dealing with price data, a good starting point is lag 0 or lag 1. Confidence level - The probability level at which the critical value of the ADF test statistic is calculated. If the test statistic is below the critical value, it is concluded that the sample of the price series is mean-reverting. Confidence level is calculated based on MacKinnon (2010) . Show Infobox - If True, the results calculated for the last price bar are displayed in a table on the left. More formal background: Formally, the ADF test is a test for a unit root in an autoregressive process. The model implemented in this script involves a non-zero constant and zero time trend. The zero lag corresponds to the simple case of the AR(1) process, while higher order autoregressive processes AR(p) can be approached by setting the maximum lag of p. The null hypothesis is that there is a unit root, with the alternative that there is no unit root. The presence of unit roots in an autoregressive time series is characteristic for a non-stationary process. Thus, if there is no unit root, the time series sample can be concluded to be stationary, i.e., manifesting the mean-reverting property. A few more comments: It should be noted that the ADF test tells us only about the properties of the price series now and in the past. It does not directly say whether the mean-reverting behavior will retain in the future. The ADF test results don't directly reveal the direction of the next price move. It only tells wether or not a mean-reverting trading strategy can be potentially applicable at the given moment of time. The ADF test is related to another statistical test, the Hurst exponent. The latter is available on TradingView as implemented by balipour , QuantNomad and DonovanWall . The ADF test statistics is a negative number. However, it can take positive values, which usually corresponds to trending markets (even though there is no statistical test for this case). Rigorously, the hypothesis about the mean reversion is accepted at a given confidence level when the value of the test statistic is below the critical value. However, for practical trading applications, the values which are low enough - but still a bit higher than the critical one - can be still used in making decisions. Examples: The VIX volatility index is known to exhibit mean reversion properties (volatility spikes tend to fade out quickly). Accordingly, the statistics of the ADF test tend to stay below the critical value of 90% for long time periods. The opposite case is presented by BTCUSD. During the same time range, the bitcoin price showed strong momentum - the moves away from the mean did not follow by the counter-move immediately, even vice versa. This is reflected by the ADF test statistic that consistently stayed above the critical value (and even above 0). Thus, using a mean reversion strategy would likely lead to losses.
Pine Script®指標
由tbtkg提供
47
[blackcat] L1 Fibonacci VWAP RSI IndicatorLevel: 1 Background Ingo Bucher proposed "Fibonacci RSI" in March,2003. It describes the advantages of considering Fibonacci retracement levels for use with the classic RSI indicator. Bucher reviews six charts, each displaying Fibonacci retracement levels for the RSI associated with each chart. The pine code given here will allow you to automatically recreate these charts for any security available in Tradingview. BTW, i enhanced it by changing RSI into VWAP RSI with hl2. Function For this Fib VWAP RSI indicator, it also applicable for original Bucher's fib concept. Bucher calculated his retracement levels by picking the RSI high and low for a given time window. In his examples, these were generally six months to a year's worth of data. Once the high and low were picked, he calculated retracement levels based on the well-known Fibonacci numbers (23.6%, 38.2%, 50%, 61.8%). This script here does the same thing. I use a "LookbackLength" (default: 400 bars), which represents a sliding data window that is used to determine the VWAP RSI high and low. The second input value controls the VWAP RSI period (default: 14 bars). The next three inputs select the retracement levels. A total of eight different lines need to be drawn: the RSI itself, the 50% line, two retracements above the 50% point, two retracements below, and the zero and 100% lines. Pine script will create four plotlines per indicator, so I advise inserting the Fibonacci RSI twice. The first time it is inserted, leave the PlotRSI input with its default value, true. True tells pine script to plot the VWAP RSI itself. The second copy should have the input "Plot RSI" set to false. This will put the 50% line on your chart. Inputs LookbackLength --> Look Back Length. RSILength --> RSI Length. Fib1 and Fib2 --> Fibonacci lengths. Key Signal RawVWAPRSI --> Raw VWAP RSI output signal Remarks This is a Level 1 free and open source indicator. Feedbacks are appreciated.
Pine Script®指標
由blackcat1402提供
3
Nadaraya-Watson Smoothers [LuxAlgo]The following tool smoothes the price data using various methods derived from the Nadaraya-Watson estimator, a simple Kernel regression method. This method makes use of the Gaussian kernel as a weighting function. Users have the option to use a non-repainting as well as a repainting method, see the USAGE section for more information. 🔶 USAGE 🔹 Non Repainting When Repainting Smoothing is disabled the returned indicator acts similarly to a regular causal moving average. This result could be described as an "endpoint Nadaraya-Watson estimator". Unlike a regular moving average whose degree of smoothness is commonly determined by the length of its calculation window, the degree of smoothness of the proposed indicator is determined by the bandwidth setting, with a higher value returning smoother results. In the above chart, a bandwidth value of 50 is used. An increasing value of the smoother is indicative of an uptrend, while a decreasing value is indicative of a downtrend. 🔹 Repainting Non-causal smoothing methods have found low support from technical analysts because they tend to repaint. Yet, they can provide powerful insights such as estimating underlying trends in the price as well as seeing how far prices deviate from them. They can also make drawing certain patterns easier and can help see underlying structures in the price more clearly. Using higher bandwidth values allows for estimating longer-term trends in the price. Triangular labels highlight points where the direction of the estimator change. This allows for the identification of tops and bottoms in the underlying trend which can be compared to the actual price tops and bottoms. Note that multiple labels can appear in real time, highlighting real-time changes in the estimator's direction. The most recent label on a series of labels is the first to appear. This can eventually be useful for the real-time predictive application of the estimator. However, it is not a usage we particularly recommend. 🔶 DETAILS The Nadaraya-Watson estimator can be described as a series of weighted averages using a specific normalized kernel as a weighting function. For each point of the estimator at time t , the peak of the kernel is located at time t , as such the highest weights are attributed to values neighboring the price located at time t . A lower bandwidth value would contribute toward a more important weighting of the price at a precise point and would as such less smooth results. In the case where our bandwidth is so small that the resulting kernel is just an impulse, we would get the raw price back. However, when the bandwidth is sufficiently large, prices would be weighted similarly, thus resulting in a result closer to the price mean. It can be interesting to note that due to the nature of the estimator and its weighting procedure, real-time results would not deviate drastically for points in the estimator near the center of the calculation window. 🔶 SETTINGS Bandwidth : controls the bandwidth of the Gaussian kernel, with higher values returning smoother results. Src : Input source of the kernel regression. Repainting Smoothing : Determine if the smoothing method should repaint or not. If disabled the "endpoint Nadaraya-Watson estimator" is returned.
Pine Script®指標
由LuxAlgo提供
256
Trend ExplorerAre we in a bull or a bear market? From the technical analysis point of view, the answer is "It depends". It depends from the parameters of your indicator, the timeframe of the pair you are looking and the volatility of that specific market you are looking to. After I experimented with various trending indicators I decided to develop a framework that potentially could "embed" already existing logic from well known indicators (e.g. Supertrend OTT etc.). The most important part is that I managed to abstract that logic away and experiment even further to produce some more robust, market and timeframe resolution agnostic results. While at the same time I was able to switch between market and timeframe resolution specific configuration to take some decision. Finally, I decided to share this code with you folks! Developed this indicator "Trend Explorer" in an effort to make the aforementioned abstraction of all those trending indicators. The goal is to enable the user to explore and combine different approaches in order to create a more robust and market general/specific, timeframe resolution invariant/fluctuating and volatility auto/manual adjusted indicator according to his needs. The logic behind the abstraction is fairly simple. The trending indicator consists of two boundary lines the "bull trend low boundary" (green) and the "bear trend high boundary" (red). The indicator also has a control line (orange). Every time the control line crosses a boundary there is a trend reversal! The boundary lines are defined by the thresholds. To be more precise, boundaries are pulled upwards by thresholds (blue) during a bull market and downwards during a bear market. I challenge the user to experiment with the different ways of calculating the thresholds and the control. I am open to suggestions that might improve and extend the possibilities of this indicator. Any feedback, comments, general thoughts or bug reports are welcome. Why did I chose those defaults? For threshold calculation I chose MINMAX which calculates the local minimum and maximum using a sliding window. As far as I know it is not used in any existing trending indicator, but it seems reasonable for a trader to search for local min and max to make a decision. The width of the sliding window a.k.a the "period to remember" the local min and max is 30 days by default, just because I believe that for regular people it is a reasonable period of time to forget too. Also, compared to the SUBADD method MINMAX does not seem to lag behind, especially when using averages in the SUBADD mode. Moreover, I consider MINMAX to be more general than the margins used by the SUBADD since margins should be configured based on the underlying market volatility. For a source of min and max I chose the low and high values just because they are timeframe resolution invariant, meaning that they have the same (not exactly due to number precision and rounding, but very close) results for a single pair whether you use "4 hour" or "1 day" time interval! Another popular choice might be (close, close) since many traders wait for the daily candle to close in order to discard outliers. However, this approach is not resolution invariant and it depends from the time interval the user has selected. Do you have any interesting trending indicator you would like to see how it performs in this framework logic? Let me know! Do you have in mind any variation of Control or Thresholds calculation you would like to test? Please describe it in the comments below so I can add it in my implementation for you! Did you find any other bug or you experienced any strange behavior? PM me with a description of the bug, the trading pair the timeframe resolution the exact time (candle) and all the necessary configurations for this indicator so I can reproduce it on my machine! Please enjoy with caution, Jason
Pine Script®指標
由jason5480提供
12
Using `varip` variables [PineCoders]█  OVERVIEW The new varip keyword in Pine can be used to declare variables that escape the rollback process, which is explained in the Pine User Manual's page on the execution model . This publication explains how Pine coders can use variables declared with varip to implement logic that was impossible to code in Pine before, such as timing events during the realtime bar, or keeping track of sequences of events that occur during successive realtime updates. We present code that allows you to calculate for how much time a given condition is true during a realtime bar, and show how this can be used to generate alerts. █  WARNINGS 1. varip is an ​advanced feature which should only be used by coders already familiar with Pine's execution model and bar states . 2. Because varip only affects the behavior of your code in the realtime bar, it follows that backtest results on strategies built using logic based on varip will be meaningless,   as varip behavior cannot be simulated on historical bars. This also entails that plots on historical bars will not be able to reproduce the script's behavior in realtime. 3. Authors publishing scripts that behave differently in realtime and on historical bars should imperatively explain this to traders. █  CONCEPTS Escaping the rollback process Whereas scripts only execute once at the close of historical bars, when a script is running in realtime, it executes every time the chart's feed detects a price or volume update. At every realtime update, Pine's runtime normally resets the values of a script's variables to their last committed value, i.e., the value they held when the previous bar closed. This is generally handy, as each realtime script execution starts from a known state, which simplifies script logic. Sometimes, however, script logic requires code to be able to save states between different executions in the realtime bar. Declaring variables with varip now makes that possible. The "ip" in varip stands for "intrabar persist". Let's look at the following code, which does not use varip : //@version=4 study("") int updateNo = na if barstate.isnew updateNo := 1 else updateNo := updateNo + 1 plot(updateNo, style = plot.style_circles) On historical bars, barstate.isnew is always true, so the plot shows a value of "1". On realtime bars, barstate.isnew is only true when the script first executes on the bar's opening. The plot will then briefly display "1" until subsequent executions occur. On the next executions during the realtime bar, the second branch of the if statement is executed because barstate.isnew is no longer true. Since `updateNo` is initialized to `na` at each execution, the `updateNo + 1` expression yields `na`, so nothing is plotted on further realtime executions of the script. If we now use varip to declare the `updateNo` variable, the script behaves very differently: //@version=4 study("") varip int updateNo = na if barstate.isnew updateNo := 1 else updateNo := updateNo + 1 plot(updateNo, style = plot.style_circles) The difference now is that `updateNo` tracks the number of realtime updates that occur on each realtime bar. This can happen because the varip declaration allows the value of `updateNo` to be preserved between realtime updates; it is no longer rolled back at each realtime execution of the script. The test on barstate.isnew allows us to reset the update count when a new realtime bar comes in. █  OUR SCRIPT Let's move on to our script. It has three parts:  — Part 1 demonstrates how to generate alerts on timed conditions.  — Part 2 calculates the average of realtime update prices using a varip array.  — Part 3 presents a function to calculate the up/down/neutral volume by looking at price and volume variations between realtime bar updates. Something we could not do in Pine before varip was to time the duration for which a condition is continuously true in the realtime bar. This was not possible because we could not save the beginning time of the first occurrence of the true condition. One use case for this is a strategy where the system modeler wants to exit before the end of the realtime bar, but only if the exit condition occurs for a specific amount of time. One can thus design a strategy running on a 1H timeframe but able to exit if the exit condition persists for 15 minutes, for example. REMINDER: Using such logic in strategies will make backtesting their complete logic impossible, and backtest results useless, as historical behavior will not match the strategy's behavior in realtime, just as using `calc_on_every_tick = true` will do. Using `calc_on_every_tick = true` is necessary, by the way, when using varip in a strategy, as you want the strategy to run like a study in realtime, i.e., executing on each price or volume update. Our script presents an `f_secondsSince(_cond, _resetCond)` function to calculate the time for which a condition is continuously true during, or even across multiple realtime bars. It only works in realtime. The abundant comments in the script hopefully provide enough information to understand the details of what it's doing. If you have questions, feel free to ask in the Comments section. Features The script's inputs allow you to:  • Specify the number of seconds the tested conditions must last before an alert is triggered (the default is 20 seconds).  • Determine if you want the duration to reset on new realtime bars.  • Require the direction of alerts (up or down) to alternate, which minimizes the number of alerts the script generates. The inputs showcase the new `tooltip` parameter, which allows additional information to be displayed for each input by hovering over the "i" icon next to it. The script only displays useful information on realtime bars. This information includes:  • The MA against which the current price is compared to determine the bull or bear conditions.  • A dash which prints on the chart when the bull or bear condition is true.  • An up or down triangle that prints when an alert is generated. The triangle will only appear on the update where the alert is triggered,   and unless that happens to be on the last execution of the realtime bar, it will not persist on the chart.  • The log of all triggered alerts to the right of the realtime bar.  • A gray square on top of the elapsed realtime bars where one or more alerts were generated. The square's tooltip displays the alert log for that bar.  • A yellow dot corresponding to the average price of all realtime bar updates, which is calculated using a varip array in "Part 2" of the script.  • Various key values in the Data Window for each parts of the script. Note that the directional volume information calculated in Part 3 of the script is not plotted on the chart—only in the Data Window. Using the script You can try running the script on an open market with a 30sec timeframe. Because the default settings reset the duration on new realtime bars and require a 20 second delay, a reasonable amount of alerts will trigger. Creating an alert on the script You can create a script alert on the script. Keep in mind that when you create an alert from this script, the duration calculated by the instance of the script running the alert will not necessarily match that of the instance running on your chart, as both started their calculations at different times. Note that we use alert.freq_all in our alert() calls, so that alerts will trigger on all instances where the associated condition is met. If your alert is being paused because it reaches the maximum of 15 triggers in 3 minutes, you can configure the script's inputs so that up/down alerts must alternate. Also keep in mind that alerts run a distinct instance of your script on different servers, so discrepancies between the behavior of scripts running on charts and alerts can occur, especially if they trigger very often. Challenges Events detected in realtime using variables declared with varip can be transient and not leave visible traces at the close of the realtime bar, as is the case with our script, which can trigger multiple alerts during the same realtime bar, when the script's inputs allow for this. In such cases, elapsed realtime bars will be of no use in detecting past realtime bar events unless dedicated code is used to save traces of events, as we do with our alert log in this script, which we display as a tooltip on elapsed realtime bars. █  NOTES Realtime updates We have no control over when realtime updates occur. A realtime bar can open, and then no realtime updates can occur until the open of the next realtime bar. The time between updates can vary considerably. Past values There is no mechanism to refer to past values of a varip variable across realtime executions in the same bar. Using the history-referencing operator will, as usual, return the variable's committed value on previous bars. If you want to preserve past values of a varip variable, they must be saved in other variables or in an array . Resetting variables Because varip variables not only preserve their values across realtime updates, but also across bars, you will typically need to plan conditions that will at some point reset their values to a known state. Testing on barstate.isnew , as we do, is a good way to achieve that. Repainting The fact that a script uses varip does not make it necessarily repainting. A script could conceivably use varip to calculate values saved when the realtime bar closes, and then use confirmed values of those calculations from the previous bar to trigger alerts or display plots, avoiding repaint. timenow resolution Although the variable is expressed in milliseconds it has an actual resolution of seconds, so it only increments in multiples of 1000 milliseconds. Warn script users When using varip to implement logic that cannot be replicated on historical bars, it's really important to explain this to traders in published script descriptions, even if you publish open-source. Remember that most TradingViewers do not know Pine. New Pine features used in this script This script uses three new Pine features:  • varip  • The `tooltip` parameter in input() .  • The new += assignment operator. See these also: -= , *= , /= and %= . Example scripts These are other scripts by PineCoders that use varip :  • Tick Delta Volume , by RicadoSantos .  • Tick Chart and Volume Info from Lower Time Frames by LonesomeTheBlue . Thanks Thanks to the PineCoders who helped improve this publication—especially to bmistiaen . Look first. Then leap.
Pine Script®指標
由PineCoders提供
24
Robust Channel [tbiktag]Introducing the Robust Channel indicator. This indicator is based on a remarkable property of robust statistics , namely, the resistance​ to the presence of data points that deviate significantly from the established trend (generally speaking, outliers ). Being outlier-resistant, the Robust Channel indicator “remembers” a pre-existing trend and thus exhibits a very peculiar "lag" in case of a sharp price change. This allows high-confidence identification of such price actions as a trend reversal, range break, pullback, etc. In the case of trending and range-bound market conditions, the price remains within the channel most of the time, fluctuating around the central line. Technical details The central line is calculated using the repeated median slope algorithm. For each data point in a lookback window of a user-specified Length , this method calculates the median slope of the lines that connect that point to all other points inside the window. The overall median of these median slopes is then calculated and used as an estimate of the trend slope. The algorithm is very efficient as it uses an on-the-fly procedure to update the array containing the slopes (new data pushed - old data removed). The outer line is then calculated as the central line plus the Length -period standard deviation of the price data multiplied by a user-defined Channel Width Factor . The inner line is defined analogously below the central line. Usage As a stand-alone indicator, the Robust Channel can be applied similarly to the Bollinger Bands and the Keltner Channel: A close above the outer line can be interpreted as a bullish signal and a close below the inner line as a bearish signal. Likewise, a return to the channel from below after a break may serve as a bullish signal, while a return from above may indicate bearish sentiment. Robust Channel can be also used to confirm chart patterns such as double tops and double bottoms. If you like this indicator, feel free to leave your feedback in the comments below!
Pine Script®指標
由tbtkg提供
14