Регистрация

Поиск скриптов по запросу "文华财经tick价格"

Smoothed Heikin Ashi Trend on Chart - TraderHalai BACKTESTSmoothed Heikin Ashi Trend on chart - Backtest This is a backtest of the Smoothed Heikin Ashi Trend indicator, which computes the reverse candle close price required to flip a Heikin Ashi trend from red to green and vice versa. The original indicator can be found in the scripts section of my profile. This particular back test uses this indicator with a Trend following paradigm with a percentage-based stop loss. 

Note, that backtesting performance is not always indicative of future performance, but it does provide some basis for further development and walk-forward / live testing.

Testing was performed on Bitcoin , as this is a primary target market for me to use this kind of strategy. Sample Backtesting results as of 10th June 2022: Backtesting parameters:
 Position size: 10% of equity
 Long stop: 1% below entry
 Short stop: 1% above entry Repainting: Off
 Smoothing: SMA Period: 10
 8 Hour: Number of Trades: 1046

 Gross Return: 249.27 % CAGR Return: 14.04 % 
Max Drawdown: 7.9 % Win percentage: 28.01 % 
Profit Factor (Expectancy): 2.019 
 Average Loss: 0.33 % 
 Average Win: 1.69 %
 Average Time for Loss: 1 day
 Average Time for Win: 5.33 days 

 1 Day:

 Number of Trades: 429

 Gross Return: 458.4 % CAGR Return: 15.76 %
 Max Drawdown: 6.37 % 
Profit Factor (Expectancy): 2.804 
Average Loss: 0.8 % 
 Average Win: 7.2 % Average Time for Loss: 3 days
 Average Time for Win: 16 days


 5 Day: Number of Trades: 69

 Gross Return: 1614.9 % CAGR Return: 26.7 %
 Max Drawdown: 5.7 % 
Profit Factor (Expectancy): 10.451 
Average Loss: 3.64 % 
Average Win: 81.17 %
 Average Time for Loss: 15 days
 Average Time for Win: 85 days Analysis: The strategy is typical amongst trend following strategies with a less regular win rate, but where profits are more significant than losses. Most of the losses are in sideways, low volatility markets. This strategy performs better on higher timeframes, where it shows a positive expectancy of the strategy.

 The average win was positively impacted by Bitcoin’s earlier smaller market cap, as the percentage wins earlier were higher.

 Overall the strategy shows potential for further development and may be suitable for walk-forward testing and out of sample analysis to be considered for a demo trading account. Note in an actual trading setup, you may wish to use this with volatility filters, combined with support resistance zones for a better setup. As always, this post/indicator/strategy is not financial advice, and please do your due diligence before trading this live. Original indicator links: On chart version - Oscillator version - Update - 27/06/2022 Unfortunately, It appears that the original script had been taken down due to auto-moderation because of concerns with no slippage / commission. I have since adjusted the backtest, and re-uploaded to include the following to address these concerns, and show that I am genuinely trying to give back to the community and not mislead anyone: 1) Include commission of 0.1% - to match Binance's maker fees prior to moving to a fee-less model. 2) Include slippage of 10 ticks (This is a realistic slippage figure from searching online for most crypto exchanges) 3) Adjust account balance to 10,000 - since most of us are not millionaires. The rest of the backtesting parameters are comparable to previous results: Backtesting parameters:
 Initial capital: 10000 dollars Position size: 10% of equity
 Long stop: 2% below entry
 Short stop: 2% above entry Repainting: Off
 Smoothing: SMA Period: 10
 Slippage: 10 ticks Commission: 0.1% This script still remains to shows viability / profitablity on higher term timeframes (with slightly higher drawdown), and I have included the backtest report below to document my findings: 8 Hour: Number of Trades: 1082

 Gross Return: 233.02% CAGR Return: 14.04 % 
Max Drawdown: 7.9 % Win percentage: 25.6% 
Profit Factor (Expectancy): 1.627 Average Loss: 0.46 % 
 Average Win: 2.18 %
 Average Time for Loss: 1.33 day
 Average Time for Win: 7.33 days Once again, please do your own research and due dillegence before trading this live. This post is for education and information purposes only, and should not be taken as financial advice.
Стратегия Pine Script®
от TraderHalai
4
Nasdaq or US Composite Total VolumeBecause no NASDAQ composite index or NYSE composite index provide data volume, this script intends to use the NASDAQ Composite total volume index, index ticker : TVOLQ, or the NYSE Composite total volume index, index ticker : TVOL, as a classical volume indicator on chart. How tu use : in the input tab choose youe prefered SMA lenght and the volume' index ticker you want to display. TVOLQ for the NASDAQ Composite total volume or TVOL for the NYSE Composite total volume. On chart, choose to display the indicator in a new pane.
Индикатор Pine Script®
от TraderBotA
6
5 Minute Scalping StrategyTaking entrys based on the 1 minute timeframe MACD only taking longs when all emas are in the correct order and there is a bigger than usual MACD downtick and the RSI is above 51 only taking shorts when all emas are in the opposite order and there is a bigger than usual uptick on the MACD and the RSI is bellow 49 bigger than usual ticks are defined by bollinger bands around the Macd and the ticks have to be higher than 35 and lower than -10 you can change whatever setting you like to make the strategy more profitible. pls share when you find a more profitible setting than me the stoploss doesnt work correct if it would be hit in the same candle you enter the trade. pls share when you have a solution for this the stratagy is profitible when i backtested it for the last month, but i dont know how it will play out in the future, so you enter the signals at your own risk
Стратегия Pine Script®
от Coachman0912
2
SymMatrixTableSimple Example Table for Displaying Price, RSI, Volume of multiple Tickers on selected Timeframe Displays Price, RSI and Volume of 3 Tickers and Timeframe selected by user input Conditional Table Cell coloring Price color green if > than previous candle close and red if < previous candle close RSI color green if < 30 and red if > 70 (RSI14 by default) Volume color green if above average volume and red if less than that (SMA20 volume by default) Can turn on/off whole table, header columns, row indices, or select individual columns or rows to show/hide // Example Mixed Type Matrix To Table // access the simple example script by uncommenting the code at the end Basically I wanted to have the headers and indices as strings and the rest of the matrix for the table body as floats, then conditional coloring on the table cells And also the functionality to turn rows and columns on/off from table through checkboxes of user input Before I was storing each of the values separately in arrays that didn't have a centralized way of controlling table structure so now the structure is : - string header array, string index array - float matrix for table body - color matrix with bool conditions for coloring table cells - bool checkboxes for controlling table display
Индикатор Pine Script®
от machdragon
3
Runners & Laggers (scanner)Firstly, seems to me this may only work with crypto but I know nothing about the other sectors so i could be wrong. I was trying to think up a good way to find moving coins(other than by volume bc theres holes in the results when using it this way). Thought this was an interesting concept so decided to publish it as I've seen no others like it (though i did not extensively search for it. We need to start with a little Tradingview(TV) common knowledge. When there is no update of trades/volume in a candle TV does not print the candle. So when looking at (let's say) a 1 second chart, if the coin being observed by the user has no update from a trade in the time of that 1 sec candle it is skipped over. This means that a coin with a ton of volume might fill an entire 60 seconds with 60 candles and conversely with a low volume coin there could be as little as 0 1-second candles. BUT even for normally low volume coins, when a pump is beginning with the coin it could literally go from 0 1-second candles within a minute to 60 1-second candles within the next minute. ***NOTE: This DOES NOT show ANY information if the coin is going up or down but rather that a LOT more trading volume is occurring than normal.*** What this script does is scans (via request.security feature) up to 40 coins at a time and counts how many candles are printed within a user set timespan calculated in minute. 1 candle print per incremented timeframe that the chart is on. ie. if the chart is a 1 min chart it counts how many 1 min candles are printed. So, (as is in the captured image for the script) if you wanted to count how many 5 second candles are printed for each coin in 1 min then you would have to put the charts timeframe on 5sec and the setting titled 'Window of TIME(in minutes) to count bars' as 1.0 (which bc it's in minutes 1.0m = 60sec and bc 60s / 5s = 12 there would be 12 possible values that each coin can be at depending on how many bars are counted within that 1min/60sec. *** I will update to show an image of what I'm talking about here. Now, the exchange I'm scanning here is Kucoin's Margin Coins. There are 170 something coins total but I removed a few i didn't care for to make it a round 40 coins per set (there being 4 sets of 40 coins total=160 coins being scanned). To scan all 4 sets the indicator must be added 4 times to the chart and a different 'set' selected for each iteration of the script on the chart. Free users can only scan 3 at the most. All others can scan all 4 sets. In the script you can change the exchange and coins as necessary. If there done so and there are not 40 coins total just put '' '' in the extra coins spots that are not filled and the script will skip over these blankly filled spots. The suffix (traded pair) for the tickerID on all Kucoin's Margin Coin's is USDT so that's what i have inputted in the main function on line 46 (will need to be changed if that differs from the coins you want to scan. Next in the line of settings is 'Window of TIME(in minutes) to count bars' which has already been discussed. Following that is the setting "Table Shows" which the results are all in a table and the table will present the coins that have either "Passed" or "Failed" depending on which you choose. The next setting determines what passes or fails. If there are 12 possible rows for the coins to be in (as described above) then this setting is the "Pass/Fail Cutoff" level. So if you want to show all the coins that are in rows 11 and 12 (as in the image at top) then 11 should be selected here. At this point you will see all the coins that have a lot of volume in them. Finding coin names in the table that are usually not with a ton of volume will present your present movers. NOTE: coins like BTC and ETH will almost always be in these levels so it does not indicate anything different from the norm of these coins. Last setting is the ability to show the table on the main window or not. Hope you enjoy and find use in it. BTW this screener format is the same as the others I have published. If you like, check those out too. If you find difficulty using then refer to those as well as they have additional info in them on how to use the scanner and its format. Lastly, in the script is the ability to print the plots and labels but I commented them out bc its really just a jumbled mess. In the commented out sections there is a Random Color Function (provided by @hewhomustnotbenamed which was developed on the basis of Function-HSL-color by @RicardoSantos. All right, peace brothers....and sisters. **** Also, I see how the "levels" could be confusing so I will put them into a % format soon (probably not today) so that the "Pass/Fail Cutoff" can be in % format so that if "passed" is chosen and 50% is chosen (in the new setting that will be changed) then it'll show you all the coins that have more than 50% of the bars printed within the time window chosen. Goodluck in all your trading adventures. ChasinAlts out.
Индикатор Pine Script®
от A_Traders_Edge
3
ChikouLibrary "Chikou" This library contains Chikou Filter function to enhances functionality of Chikou-Span from Ichimoku Cloud using a simple trend filter. Chikou is basically close value of ticker offset to close and it is a good for indicating if close value has crossed potential Support/Resistance zone from past. Chikou is usually used with 26 period. Chikou filter uses a lookback length calculated from provided lookback percentage and checks if trend was bullish or bearish within that lookback period. Bullish : Trend is bullish if Chikou span is above high values of all candles within defined lookback period. Bull color shows bullish trend . Bearish : Trend is bearish if Chikou span is below low values of all candles within defined lookback period. This is indicated by Bearish color. Reversal / Choppiness : Reversal color indicates that Chikou are swinging around candles within defined lookback period which is an indication of consolidation or trend reversal. chikou(src, len, perc, _high, _low, bull_col, bear_col, r_col) Chikou Filter for Ichimoku Cloud with Color and Signal Output   Parameters:      src : Price Source (better to use (OHLC4+high+low/3 instead of default close value)      len : Chikou Legth (displaced source value)      perc : Percentage lookback period for Chikou Filter with defined how much candels of total length should be considered for backward filteration      _high : Ticker High Value      _low : Ticker Low Value      bull_col : Color to be returned if source value is greater than all candels within provided lookback percentage.      bear_col : Color to be returned if source value is lower than all candels within provided lookback percentage.      r_col : Color to be returned if source value is swinging around candles within defined lookback period which is an indication of consolidation or trend reversal.   Returns: Color based on trend. 'bull_col' if trend is bullish, 'bear_col' if trend is bearish. 'r_col' if no prominent trend. Integer Signal is also returned as 1 for Bullish, -1 for Bearish and 0 for no prominent trend.
Библиотека Pine Script®
от MightyZinger
2
TS_FFALibrary "TS_FFA" Splits the ticker and generates best configs for FP and PP splitter(x) Splits the ticker and found the configuration regarding to name.   Parameters:     _x: ticker   Returns: Fib and Profit percent values - Splitter had been added. - USDTPERP coins on Binance had been added - timeFrameMultiplier() timeframe multiplier had been added to the library - timeframe period value fixed - Changed timezone multiplier - Changed VWMA Percent values
Библиотека Pine Script®
от emreyavuz84
Relative Strength Screener V2 - Top 100 volume leadersNew and improved strength heatmap for the top 100 volume leaders in the S&P. Coded in a workaround to the 40 request.security limitation that currently exists in Pine. Added the ability to input the number of columns (time frames) you wish to display. For 3 time frame analysis, add the indicator to your chart 3 times. Change the number of columns to 3 for each of these indicators. Specify the column and time frame for each one (example, 5 minute for column 1, 1 hour for column 2 and Daily chart for column 3). It will automatically resize the columns/tables to properly display the output. This provides a sort of "Strength Heatmap" for the top 100 stocks in the S&P. To achieve this, make a copy of the indicator and substitute lines 68-105 with the following premade watchlists : Make a copy 1 - FIrst 38 volume leaders in the S&P s01 = input.symbol('AAPL', group = 'Symbols', inline = 's01') s02 = input.symbol('ABBV', group = 'Symbols', inline = 's02') s03 = input.symbol('ABT', group = 'Symbols', inline = 's03') s04 = input.symbol('ACN', group = 'Symbols', inline = 's04') s05 = input.symbol('AEP', group = 'Symbols', inline = 's05') s06 = input.symbol('AIG', group = 'Symbols', inline = 's06') s07 = input.symbol('AMAT', group = 'Symbols', inline = 's07') s08 = input.symbol('AMD', group = 'Symbols', inline = 's08') s09 = input.symbol('APA', group = 'Symbols', inline = 's09') s10 = input.symbol('ATVI', group = 'Symbols', inline = 's10') s11 = input.symbol('AXP', group = 'Symbols', inline = 's11') s12 = input.symbol('BA', group = 'Symbols', inline = 's12') s13 = input.symbol('BBWI', group = 'Symbols', inline = 's13') s14 = input.symbol('BBY', group = 'Symbols', inline = 's14') s15 = input.symbol('BK', group = 'Symbols', inline = 's15') s16 = input.symbol('BMY', group = 'Symbols', inline = 's16') s17 = input.symbol('BRK.B', group = 'Symbols', inline = 's17') s18 = input.symbol('C', group = 'Symbols', inline = 's18') s19 = input.symbol('CAT', group = 'Symbols', inline = 's19') s20 = input.symbol('CCL', group = 'Symbols', inline = 's20') s21 = input.symbol('CFG', group = 'Symbols', inline = 's21') s22 = input.symbol('CL', group = 'Symbols', inline = 's22') s23 = input.symbol('CNC', group = 'Symbols', inline = 's23') s24 = input.symbol('COF', group = 'Symbols', inline = 's24') s25 = input.symbol('COP', group = 'Symbols', inline = 's25') s26 = input.symbol('COST', group = 'Symbols', inline = 's26') s27 = input.symbol('CRM', group = 'Symbols', inline = 's27') s28 = input.symbol('CVS', group = 'Symbols', inline = 's28') s29 = input.symbol('CVX', group = 'Symbols', inline = 's29') s30 = input.symbol('DAL', group = 'Symbols', inline = 's30') s31 = input.symbol('DIS', group = 'Symbols', inline = 's31') s32 = input.symbol('DISCA', group = 'Symbols', inline = 's32') s33 = input.symbol('DISCK', group = 'Symbols', inline = 's33') s34 = input.symbol('DISH', group = 'Symbols', inline = 's34') s35 = input.symbol('DLTR', group = 'Symbols', inline = 's35') s36 = input.symbol('DOW', group = 'Symbols', inline = 's36') s37 = input.symbol('DVN', group = 'Symbols', inline = 's37') s38 = input.symbol('EBAY', group = 'Symbols', inline = 's38') Make a copy 2 - Tickers 39 to 76 s01 = input.symbol('EOG', group = 'Symbols', inline = 's01') s02 = input.symbol('F', group = 'Symbols', inline = 's02') s03 = input.symbol('FB', group = 'Symbols', inline = 's03') s04 = input.symbol('FCX', group = 'Symbols', inline = 's04') s05 = input.symbol('FIS', group = 'Symbols', inline = 's05') s06 = input.symbol('GE', group = 'Symbols', inline = 's06') s07 = input.symbol('GIS', group = 'Symbols', inline = 's07') s08 = input.symbol('GM', group = 'Symbols', inline = 's08') s09 = input.symbol('GS', group = 'Symbols', inline = 's09') s10 = input.symbol('HD', group = 'Symbols', inline = 's10') s11 = input.symbol('IBM', group = 'Symbols', inline = 's11') s12 = input.symbol('INTC', group = 'Symbols', inline = 's12') s13 = input.symbol('JNJ', group = 'Symbols', inline = 's13') s14 = input.symbol('JPM', group = 'Symbols', inline = 's14') s15 = input.symbol('KR', group = 'Symbols', inline = 's15') s16 = input.symbol('LUV', group = 'Symbols', inline = 's16') s17 = input.symbol('LVS', group = 'Symbols', inline = 's17') s18 = input.symbol('MA', group = 'Symbols', inline = 's18') s19 = input.symbol('MCD', group = 'Symbols', inline = 's19') s20 = input.symbol('MCHP', group = 'Symbols', inline = 's20') s21 = input.symbol('MDT', group = 'Symbols', inline = 's21') s22 = input.symbol('MET', group = 'Symbols', inline = 's22') s23 = input.symbol('MGM', group = 'Symbols', inline = 's23') s24 = input.symbol('MOS', group = 'Symbols', inline = 's24') s25 = input.symbol('MPC', group = 'Symbols', inline = 's25') s26 = input.symbol('MRK', group = 'Symbols', inline = 's26') s27 = input.symbol('MRNA', group = 'Symbols', inline = 's27') s28 = input.symbol('MS', group = 'Symbols', inline = 's28') s29 = input.symbol('MSFT', group = 'Symbols', inline = 's29') s30 = input.symbol('MU', group = 'Symbols', inline = 's30') s31 = input.symbol('NCLH', group = 'Symbols', inline = 's31') s32 = input.symbol('NEE', group = 'Symbols', inline = 's32') s33 = input.symbol('NEM', group = 'Symbols', inline = 's33') s34 = input.symbol('NFLX', group = 'Symbols', inline = 's34') s35 = input.symbol('NKE', group = 'Symbols', inline = 's35') s36 = input.symbol('NVDA', group = 'Symbols', inline = 's36') s37 = input.symbol('ORCL', group = 'Symbols', inline = 's37') s38 = input.symbol('OXY', group = 'Symbols', inline = 's38') Make a copy 3 - tickers 77 to 114 s01 = input.symbol('PENN', group = 'Symbols', inline = 's01') s02 = input.symbol('PEP', group = 'Symbols', inline = 's02') s03 = input.symbol('PFE', group = 'Symbols', inline = 's03') s04 = input.symbol('PG', group = 'Symbols', inline = 's04') s05 = input.symbol('PM', group = 'Symbols', inline = 's05') s06 = input.symbol('PYPL', group = 'Symbols', inline = 's06') s07 = input.symbol('QCOM', group = 'Symbols', inline = 's07') s08 = input.symbol('RTX', group = 'Symbols', inline = 's08') s09 = input.symbol('SBUX', group = 'Symbols', inline = 's09') s10 = input.symbol('SCHW', group = 'Symbols', inline = 's10') s11 = input.symbol('SLB', group = 'Symbols', inline = 's11') s12 = input.symbol('SYF', group = 'Symbols', inline = 's12') s13 = input.symbol('T', group = 'Symbols', inline = 's13') s14 = input.symbol('TFC', group = 'Symbols', inline = 's14') s15 = input.symbol('TGT', group = 'Symbols', inline = 's15') s16 = input.symbol('TJX', group = 'Symbols', inline = 's16') s17 = input.symbol('TMUS', group = 'Symbols', inline = 's17') s18 = input.symbol('TSLA', group = 'Symbols', inline = 's18') s19 = input.symbol('TWTR', group = 'Symbols', inline = 's19') s20 = input.symbol('TXN', group = 'Symbols', inline = 's20') s21 = input.symbol('UAL', group = 'Symbols', inline = 's21') s22 = input.symbol('UNH', group = 'Symbols', inline = 's22') s23 = input.symbol('V', group = 'Symbols', inline = 's23') s24 = input.symbol('VIAC', group = 'Symbols', inline = 's24') s25 = input.symbol('WBA', group = 'Symbols', inline = 's25') s26 = input.symbol('WFC', group = 'Symbols', inline = 's26') s27 = input.symbol('WMT', group = 'Symbols', inline = 's27') s28 = input.symbol('WYNN', group = 'Symbols', inline = 's28') s29 = input.symbol('XOM', group = 'Symbols', inline = 's29') s30 = input.symbol('SPY', group = 'Symbols', inline = 's30') s31 = input.symbol('SPY', group = 'Symbols', inline = 's31') s32 = input.symbol('SPY', group = 'Symbols', inline = 's32') s33 = input.symbol('SPY', group = 'Symbols', inline = 's33') s34 = input.symbol('SPY', group = 'Symbols', inline = 's34') s35 = input.symbol('SPY', group = 'Symbols', inline = 's35') s36 = input.symbol('SPY', group = 'Symbols', inline = 's36') s37 = input.symbol('SPY', group = 'Symbols', inline = 's37') s38 = input.symbol('SPY', group = 'Symbols', inline = 's38')
Индикатор Pine Script®
от soosh_
7
Supertraders ATR-RangeThis script calculates the ATR 5 periods daily of previous day and various percentages (5%, 7,5% and 10%) of it that we use to evaluate a possibility to try a break-in of a level. This percentages are expressed in points, ticks and a value in dollars for every contract. Questo script calcola l'ATR daily 5 periodi del giorno precedente. Calcola anche varie percentuali di esso, in particolare 5%, 7,5% e 10%, utily per verificare lo sforamento in caso di break-in di un livello. Questi valori sono espressi in punti, ticks e valore in dollaro per contratto.
Индикатор Pine Script®
от fabrimele
1
cacheLibrary "cache" A simple cache library to store key value pairs. Fed up of injecting and returning so many values all the time? Want to separate your code and keep it clean? Need to make an expensive calculation and use the results in numerous places? Want to throttle calculations or persist random values across bars or ticks? Then you've come to the right place. Or not! Up to you, I don't mind either way... ;) Check the helpers and unit tests in the script for further detail. Detailed Interface init(persistant) Initialises the syncronised cache key and value arrays   Parameters:      persistant : bool, toggles data persistance between bars and ticks   Returns: [string , float ], a tuple of both arrays set(keys, values, key, value) Sets a value into the cache   Parameters:      keys : string , the array of cache keys      values : float , the array of cache values      key : string, the cache key to create or update      value : float, the value to set has(keys, values, key) Checks if the cache has a key   Parameters:      keys : string , the array of cache keys      values : float , the array of cache values      key : string, the cache key to check   Returns: bool, true only if the key is found get(keys, values, key) Gets a keys value from the cache   Parameters:      keys : string , the array of cache keys      values : float , the array of cache values      key : string, the cache key to get   Returns: float, the stored value remove(keys, values, key) Removes a key and value from the cache   Parameters:      keys : string , the array of cache keys      values : float , the array of cache values      key : string, the cache key to remove count() Counts how many key value pairs in the cache   Returns: int, the total number of pairs loop(keys, values) Returns true for each value in the cache (use as the while loop expression)   Parameters:      keys : string , the array of cache keys      values : float , the array of cache values next(keys, values) Returns each key value pair on successive calls (use in the while loop)   Parameters:      keys : string , the array of cache keys      values : float , the array of cache values   Returns: , tuple of each key value pair clear(keys, values) Clears all key value pairs from the cache   Parameters:      keys : string , the array of cache keys      values : float , the array of cache values unittest_cache(case) Cache module unit tests, for inclusion in parent script test suite. Usage: log.unittest_cache(__ASSERTS)   Parameters:      case : string , the current test case and array of previous unit tests (__ASSERTS) unittest(verbose) Run the cache module unit tests as a stand alone. Usage: cache.unittest()   Parameters:      verbose : bool, optionally disable the full report to only display failures
Библиотека Pine Script®
от GeoffHammond
3
bursamalaysianonshariahLibrary "bursamalaysianonshariah" List of non-Shariah stock for Bursa Malaysia as of Oct 2021 No parameter required status() will return 1 if ticker in the list, 0 if ticker not in the list and 2 if ticker not from Bursa Malaysia Example usage : //@version=5 indicator("My Script", overlay = true) import BURSATRENDBANDCHART/bursamalaysianonshariah/1 as b bgcolor(status() == 1 ? color.new(color.red, 90) : status() == 0 ? color.new(color.green, 90) : color.new(color.blue, 90)) Special thanks to wmsafwan RozaniGhani-RG
Библиотека Pine Script®
от BURSATRENDBANDCHART
15
Elder Impulse System + ATR BandsDisregard the above chart, I am not sure why it isn't showing the one I want, which is linked below: This is as far as I can tell the closest representation to Dr. Alexander Elder's updated "Elder Impulse System" that has added ATR-volatility bands up to 3x deviations from price. I got the idea from watching this recent video (www.youtube.com) of Dr. Elder reviewing some recent trades and noticed he had updated his system from his original books. The Impulse System colour coding was inspired by AstralLoverFlow and LazyBear. ATR Bands are pre-programmed Keltner Channels with some modifications such as filing in the ATR Zones with user-selected colour bands and modifying the ATR value to better suit the volatility of the market being traded. The script has several components, which I will detail below: Exponential Moving Averages: 1) A 13-period EMA that is used as a staple in all of Dr. Elder's technical analysis. He uses this EMA as the basis for all of his indicators and why it is included here. 2) A 26-period EMA which can be used as a base-line of sorts to filter when to go long or when to go short. For instance, price over the 26-EMA, price is strong and the rally upwards is likely to continue, underneath it, price is weak and likely to continue downwards for a time. Volatility Bands: By definition these are nothing more than 3 separate Keltner Channels of a 13-period EMA each set to one additional multiplier from the moving average. This gives us a 1x, 2x, and 3x multiplier of average volatility from the 13-period EMA based on a 14-period Average True Range (ATR) reading. The ATR was chosen as it accommodates price gaps and also is the standard formula calculation in TradingView. The values of the bands cannot be adjusted but the colour coding of them can be. Elder Impulse System: These colour-coded bars show you the strength and direction of the current chart resolution, calculated by the slope of a 13-period EMA and the slope of a MACD histogram. These are used not as a buying or selling recommendation alone but as trend filters, as per Dr. Elder's own description of them. Green Bars = The 13-period EMA is sloping positively and the MACD histogram is rising compared to previous bars. The trader should only consider buying/long opportunities when a green bar is most recent. Red Bars = The 13-period EMA is sloping negatively and the MACD histogram is falling compared to previous bars. The trader should only consider selling/short opportunities when a red bar is most recent. Blue Bars = The 13-period EMA and the MACD histogram are not aligned. One of the indicators is sloping opposite to the other indicator. These are known as indecision bars and are typically seen near the end of a previously established trend. The trader can choose to wait for either a green or red bar to shape their trading bias if they are more risk-averse while a counter-trend trader may decide to try opening a position against the currently-established trend. How To Trade the System: This system is unique in that it is so versatile and will fit the styles of many traders, be it trend following traders (generally the original Elder Impulse System design) or mean-reversion/counter-trend trading (the original Keltner Channel design). None of the examples below or in the chart above are financial advice and are just there for demonstration purposes only. 1) The most basic signal given would be the moving average cross up or down. A cross of the 13-EMA over the 26-EMA signals upward trend strength and the trader could look for buying opportunities. Conversely, the 13-EMA under the 26-EMA shows downward trend strength and the trader could look for selling opportunities. 2) Following the Elder Impulse system in conjunction with the EMAs. Look for long opportunities when a green bar is printed and price is over both of the 13- and 26-period EMAs. Look for short opportunities when a red bar is printed and price is below both of the 13- and 26-period EMAs. Keep in mind this does not necessarily need a moving average cross to be viable, a green or red bar over both EMAs is a valid signal in this system, usually. Examine price more closely for better entry signals when a blue bar is printed and price is either above or below both EMAs if you are a trend trader. This is how Dr. Elder originally intended the system to be used in conjunction with his famous Triple Screen Trading System. I am not going into detail here as it is a deep subject but I would suggest an interested trader to examine this Triple Screen System further as it is widely accepted as a strong strategy. 3) Mean Reversion and Counter-Trend Trading. Dr. Elder mentions that the zone between the two EMAs is called the Value Zone. A mean reversion trader could look for buying opportunities if price has generally been in an uptrend and falls back to value, conversely, they could look for shorting opportunities if price has generally been in a downtrend and rises back to value. These are your very basic pull backs found in trends that create your higher lows in an uptrend or your lower highs in a downtrend. A mean reversion/scalper trader may also look to use the upper and lower most ATR bands as an indication of price being overbought or oversold and could look to enter a counter-trend trade here once a blue indecision bar is printed and to ride that move back down to the Value Zone. Taking Profits and Risk Management This system again is very versatile and will fit a wide range of trading styles. It has built in take profit levels and risk management depending on your style of trading. 1a) In original Triple Screen Trading (and the original Elder Impulse system), a trader was to place a buy order one tick above a newly printed green bar with a stop loss one tick below the most recent 2-day low, and vice-versa for red bars on short selling. as long as other criteria were met, that I will not go into. It is all over YouTube and in his books and on Investopedia if you want more information. The general idea is to continue the trend in the direction if price is strong and you are bought into that move with a close stop, or if price falls back a little bit, you can get in at a better price. This would be a system typically better suited to a scalper. 1b) The updated risk management according to the above video is to place a stop loss at least 2ATR away from price. These bands already have calculated these values so a trader can place a stop one tick below the 2 or even 3ATR zones depending on their risk appetite. This is assuming you have already received a strong buy signal based on the system you follow. This would be a system typically better suited to a trend-trader. 2a) Taking profits if you are a trend trader has several possibilities. The first, as Dr. Elder suggests, is to place a price target 2ATR values away from your entry giving you approximately a 1:1 risk-reward ratio. 2b) The second possibility if the trade is successful is to ride the trend upwards until a blue bar is printed, suggesting indecision in the market. A modified version of this that could let a winning trade run longer is to wait for the price to close under the 13-EMA in fast markets, or close under the 26-EMA in slightly slower markets to maximize potential winnings. 2c) A scalper trader may wish to have a target at either the value zone if they are playing an extended buy/short back to the mean, or if they are being at the mean, to sell or cover when price extends back out to the 2x or 3x zone. 3) Trend traders can additionally use the ATR zones as a sort of safety guidelines for entering a trade. Anything within the 1ATR zone is typically a safer entry as the market is less volatile at this time. Entering when price has gone into the 2ATR zone is signaled as a strong momentum move and can signal a stronger move in the direction of the current closing bar. While not always the case, it is suggested by Dr. Elder to not enter trend trades at the 3ATR zone as this is where you will be likely looking for a counter-trend retracement back to value and a trader entering here in the direction of the trade has a higher chance of being stopped out or not getting in at the best possible price.
Индикатор Pine Script®
от christoefert
12
Yield Curve Inversion IndicatorIntroduction The last time (as of this publishing) that this indicator detected an inverted interest rate yield curve was on February 20th, 2020 at 12:30pm EST, the afternoon before the S&P500 began one of its largest crashes in US history. The vast majority of major economic recessions since the 1950's have been preceded by an interest rate yield curve inversion. I created this indicator originally as an input to study the impacts of more conservative risk management on quantitative trading strategies following a yield curve inversion event. It is being shared with the community as a quick indicator to check to see the comparative status of short term and long term interest rates, and as an indicator where you can easily check to see if we are experiencing an inverted yield curve in real-time. Background of the significance of an inverted yield curve: "What an inverted yield curve really means is that most investors believe that short-term interest rates are going to fall sharply at some point in the future. As a practical matter, recessions usually cause interest rates to fall. Historically, inversions of the yield curve have preceded recessions in the U.S. Due to this historical correlation, the yield curve is often seen as a way to predict the turning points of the business cycle. When the yield curve inverts, short-term interest rates become higher than long-term rates. This type of yield curve is the rarest of the three main curve types and is considered to be a predictor of economic recession. Because of the rarity of yield curve inversions, they typically draw attention from all parts of the financial world." (www.investopedia.com) Settings and Usage This indicator pulls in pricing data from tickers that represent short term and long term interest rates, and compares them. The red line represents short term interest rates, and the green line represents long term interest rates. When the red line is above the green line, it indicates that we are experiencing a yield curve inversion. Small blue crosses also appear on the bottom of the indicator during an inversion to further highlight the event visually. This indicator pulls in the same information on the same two interest rate tickers regardless of what chart it is applied to. Other Thoughts This script uses the f_secureSecurity function as a best practice. For those that are versed in PineScript, code from this indicator could be adapted to be applied to an interest rate chart that allows custom alerts to be created the moment that there is an inverted interest rate yield curve.
Индикатор Pine Script®
от TradeAutomation
[BCT] Can BTC be predicted or is it purely random?Variance Ratio**This indicator can be applied to the ticker of your choice (not just BTC)** Markets are said to be "efficient". An efficient market is by definition unpredictable - no matter the amount of ML, computation, or indicators thrown at it. In particular, in an efficient market, TA will not be of help. An illustration of efficient markets is the WSJ's longstanding monkey vs. human contest:Blindfolded Monkey Beats Humans With Stock Picks, granted there are several flaws to it. BTC is a relatively new market. New markets are typically highly inefficient (easier to make money) and become more and more efficient over time (harder to make money). How much more efficient is BTC becoming? We apply the Variance Ratio method and apply it to BTC. BACKGROUND ON THE VARIANCE RATIO METHOD Based on 1988 MacKinlay's seminal paper "Stock Market Prices do not Follow a Random Walk", the idea is to exploit a phenomenon called "variance scaling". For those keen on looking into the math, the short version of it is under the assumption of iid (random walk) we have the following: H0: Var(Sum(returns over K bars))=Sum(Var(returns over 1 bar))=k*Var(return over 1 bar) We look to reject or not H0 depending on the observations. In this script, we compare the variance of the (log) returns for the chart selected between: (1) The (average) variance over k bars (call this Vk) (2) The (average) variance over 1 bar (call this V1) H0 simply says that Vk=k*V1 if the stock follows a random walk. We compute the Variance Ratio VR(k)=Variance(returns over k bar)/(Sum(Var(returns over 1 bar)))-1 We then compute the associated Z-score which we chart out for a configurable k number of bars. HOW TO INTERPRET THE CHART The line drawn is the Z-Score for VR(k). It represents the number of standard deviations of VR(k) from 0 - the further out, the less random. - If the line is close / hovers around 0, the ticker appears to follow a random walk (i.e. may not be predictable) - If the line is consistently > 2 or <-2, the ticker likely does not follow a random walk (i.e. may have predictable features) - If the line is positive, it means that the Variance on the k bars is larger than the variance on 1 bar (more variance on longer timeframes) - If the line is negative, it means that the Variance on the k bars is smaller than the variance on 1 bar (more variance on smaller timeframes) USE CASES - Identify timeframes where you won't be able to make money - Identify whether a stock cannot be predicted (forget about TA, indicators etc. -- a random walk is not predictable) - Identify whether a stock is becoming less and less predictable (Z-score amplitude will decrease over time) FEATURES - select the number of K bar to compare vs. 1 bar (default = 16) - ideally a power of 2 but any other number will work. The chart is based off this selection - select the lookback period for the analysis (500 bars by default) - select the source to analyze (default = close, but you may select other inputs to calculate the returns from) - results form the statistical tests on different K's in the table on the right/bottom side of the chart (H0 rejected = not random walk; H0 not rejected = it essentially looks rather random and we can't conclude that it's not a random walk) COMMENTARY ON BTC - It appears BTC's absolute value of the ZScore on the Variance Ratio is declining year after year - corroborating an increasingly efficient market as new participants join. - However, we can still detect a fair amount of potential inefficiency using this simple test. As usual, this is not investment advice. DYOR. With love, 🐵BCT🐵
Индикатор Pine Script®
от THE_REAL_BCT
2
Triple EMA StrategyThis is my first ever script so any suggestions, recommendations or improvement ideas welcome! This strategy is an implementation of a standard three exponential moving averages strategy (defaults: EMA1=5, EMA2=20 and EMA3=50 candles). Trades are executed if EMA1 crosses above/below EMA2 and they are both above/below EMA3. In addition, the close of the current candle must be above/below the previous one by at least the number of ticks you specify in the "buffer" parameter (default 150 ticks). This additional check eliminates many bad trades. There is also a trailing stoploss which comes into play once the price has gone above/below its initial value which it then follows the price with to ensure the trade closes at the highest possible price. I find this strategy works best on a 15 minute chart but feel free to play around and fine tune the various parameters. If you find a good setup that returns decent profits, I'd be keen to hear it!
Стратегия Pine Script®
от IndoPilot
`security()` revisited [PineCoders]NOTE The non-repainting technique in this publication that relies on bar states is now deprecated, as we have identified inconsistencies that undermine its credibility as a universal solution. The outputs that use the technique are still available for reference in this publication. However, we do not endorse its usage. See this publication for more information about the current best practices for requesting HTF data and why they work. █  OVERVIEW This script presents a new function to help coders use security() in both repainting and non-repainting modes. We revisit this often misunderstood and misused function, and explain its behavior in different contexts, in the hope of dispelling some of the coder lure surrounding it. The function is incredibly powerful, yet misused, it can become a dangerous WMD and an instrument of deception, for both coders and traders. We will discuss:  • How to use our new `f_security()` function.  • The behavior of Pine code and security() on the three very different types of bars that make up any chart.  • Why what you see on a chart is a simulation, and should be taken with a grain of salt.  • Why we are presenting a new version of a function handling security() calls.  • Other topics of interest to coders using higher timeframe (HTF) data. █  WARNING We have tried to deliver a function that is simple to use and will, in non-repainting mode, produce reliable results for both experienced and novice coders. If you are a novice coder, stick to our recommendations to avoid getting into trouble, and DO NOT change our `f_security()` function when using it. Use `false` as the function's last argument and refrain from using your script at smaller timeframes than the chart's. To call our function to fetch a non-repainting value of close from the 1D timeframe, use: f_security(_sym, _res, _src, _rep) => security(_sym, _res, _src ) previousDayClose = f_security(syminfo.tickerid, "D", close, false) If that's all you're interested in, you are done. If you choose to ignore our recommendation and use the function in repainting mode by changing the `false` in there for `true`, we sincerely hope you read the rest of our ramblings before you do so, to understand the consequences of your choice. Let's now have a look at what security() is showing you. There is a lot to cover, so buckle up! But before we dig in, one last thing. What is a chart? A chart is a graphic representation of events that occur in markets. As any representation, it is not reality, but rather a model of reality. As Scott Page eloquently states in The Model Thinker : "All models are wrong; many are useful". Having in mind that both chart bars and plots on our charts are imperfect and incomplete renderings of what actually occurred in realtime markets puts us coders in a place from where we can better understand the nature of, and the causes underlying the inevitable compromises necessary to build the data series our code uses, and print chart bars. Traders or coders complaining that charts do not reflect reality act like someone who would complain that the word "dog" is not a real dog. Let's recognize that we are dealing with models here, and try to understand them the best we can. Sure, models can be improved; TradingView is constantly improving the quality of the information displayed on charts, but charts nevertheless remain mere translations. Plots of data fetched through security() being modelized renderings of what occurs at higher timeframes, coders will build more useful and reliable tools for both themselves and traders if they endeavor to perfect their understanding of the abstractions they are working with. We hope this publication helps you in this pursuit. █  FEATURES This script's "Inputs" tab has four settings:  • Repaint : Determines whether the functions will use their repainting or non-repainting mode.   Note that the setting will not affect the behavior of the yellow plot, as it always repaints.  • Source : The source fetched by the security() calls.  • Timeframe : The timeframe used for the security() calls. If it is lower than the chart's timeframe, a warning appears.  • Show timeframe reminder : Displays a reminder of the timeframe after the last bar. █  THE CHART The chart shows two different pieces of information and we want to discuss other topics in this section, so we will be covering:  A — The type of chart bars we are looking at, indicated by the colored band at the top.  B — The plots resulting of calling security() with the close price in different ways.  C — Points of interest on the chart. A — Chart bars The colored band at the top shows the three types of bars that any chart on a live market will print. It is critical for coders to understand the important distinctions between each type of bar:  1 — Gray : Historical bars, which are bars that were already closed when the script was run on them.  2 — Red : Elapsed realtime bars, i.e., realtime bars that have run their course and closed.    The state of script calculations showing on those bars is that of the last time they were made, when the realtime bar closed.  3 — Green : The realtime bar. Only the rightmost bar on the chart can be the realtime bar at any given time, and only when the chart's market is active. Refer to the Pine User Manual's Execution model page for a more detailed explanation of these types of bars. B — Plots The chart shows the result of letting our 5sec chart run for a few minutes with the following settings: "Repaint" = "On" (the default is "Off"), "Source" = `close` and "Timeframe" = 1min. The five lines plotted are the following. They have progressively thinner widths:  1 — Yellow : A normal, repainting security() call.  2 — Silver : Our recommended security() function.  3 — Fuchsia : Our recommended way of achieving the same result as our security() function, for cases when the source used is a function returning a tuple.  4 — White : The method we previously recommended in our MTF Selection Framework , which uses two distinct security() calls.  5 — Black : A lame attempt at fooling traders that MUST be avoided. All lines except the first one in yellow will vary depending on the "Repaint" setting in the script's inputs. The first plot does not change because, contrary to all other plots, it contains no conditional code to adapt to repainting/no-repainting modes; it is a simple security() call showing its default behavior. C — Points of interest on the chart Historical bars do not show actual repainting behavior To appreciate what a repainting security()  call will plot in realtime, one must look at the realtime bar and at elapsed realtime bars, the bars where the top line is green or red on the chart at the top of this page. There you can see how the plots go up and down, following the close value of each successive chart bar making up a single bar of the higher timeframe. You would see the same behavior in "Replay" mode. In the realtime bar, the movement of repainting plots will vary with the source you are fetching: open will not move after a new timeframe opens, low and high will change when a new low or high are found, close will follow the last feed update. If you are fetching a value calculated by a function, it may also change on each update. Now notice how different the plots are on historical bars. There, the plot shows the close of the previously completed timeframe for the whole duration of the current timeframe, until on its last bar the price updates to the current timeframe's close when it is confirmed (if the timeframe's last bar is missing, the plot will only update on the next timeframe's first bar). That last bar is the only one showing where the plot would end if that timeframe's bars had elapsed in realtime. If one doesn't understand this, one cannot properly visualize how his script will calculate in realtime when using repainting. Additionally, as published scripts typically show charts where the script has only run on historical bars, they are, in fact, misleading traders who will naturally assume the script will behave the same way on realtime bars. Non-repainting plots are more accurate on historical bars Now consider this chart, where we are using the same settings as on the chart used to publish this script, except that we have turned "Repainting" off this time: The yellow line here is our reference, repainting line, so although repainting is turned off, it is still repainting, as expected. Because repainting is now off, however, plots on historical bars show the previous timeframe's close until the first bar of a new timeframe, at which point the plot updates. This correctly reflects the behavior of the script in the realtime bar, where because we are offsetting the series by one, we are always showing the previously calculated—and thus confirmed—higher timeframe value. This means that in realtime, we will only get the previous timeframe's values one bar after the timeframe's last bar has elapsed, at the open of the first bar of a new timeframe. Historical and elapsed realtime bars will not actually show this nuance because they reflect the state of calculations made on their close , but we can see the plot update on that bar nonetheless. ► This more accurate representation on historical bars of what will happen in the realtime bar is one of the two key reasons why using non-repainting data is preferable.    The other is that in realtime, your script will be using more reliable data and behave more consistently. Misleading plots Valiant attempts by coders to show non-repainting, higher timeframe data updating earlier than on our chart are futile. If updates occur one bar earlier because coders use the repainting version of the function, then so be it, but they must then also accept that their historical bars are not displaying information that is as accurate. Not informing script users of this is to mislead them. Coders should also be aware that if they choose to use repainting data in realtime, they are sacrificing reliability to speed and may be running a strategy that behaves very differently from the one they backtested, thus invalidating their tests. When, however, coders make what are supposed to be non-repainting plots plot artificially early on historical bars, as in examples "c4" and "c5" of our script, they would want us to believe they have achieved the miracle of time travel. Our understanding of the current state of science dictates that for now, this is impossible. Using such techniques in scripts is plainly misleading, and public scripts using them will be moderated. We are coding trading tools here—not video games. Elementary ethics prescribe that we should not mislead traders, even if it means not being able to show sexy plots. As the great Feynman said: You should not fool the layman when you're talking as a scientist. You can readily appreciate the fantasy plot of "c4", the thinnest line in black, by comparing its supposedly non-repainting behavior between historical bars and realtime bars. After updating—by miracle—as early as the wide yellow line that is repainting, it suddenly moves in a more realistic place when the script is running in realtime, in synch with our non-repainting lines. The "c5" version does not plot on the chart, but it displays in the Data Window. It is even worse than "c4" in that it also updates magically early on historical bars, but goes on to evaluate like the repainting yellow line in realtime, except one bar late. Data Window The Data Window shows the values of the chart's plots, then the values of both the inside and outside offsets used in our calculations, so you can see them change bar by bar. Notice their differences between historical and elapsed realtime bars, and the realtime bar itself. If you do not know about the Data Window, have a look at this essential tool for Pine coders in the Pine User Manual's page on Debugging . The conditional expressions used to calculate the offsets may seem tortuous but their objective is quite simple. When repainting is on, we use this form, so with no offset on all bars: security(ticker, i_timeframe, i_source ) // which is equivalent to: security(ticker, i_timeframe, i_source) When repainting is off, we use two different and inverted offsets on historical bars and the realtime bar: // Historical bars: security(ticker, i_timeframe, i_source ) // Realtime bar (and thus, elapsed realtime bars): security(ticker, i_timeframe, i_source ) The offsets in the first line show how we prevent repainting on historical bars without the need for the `lookahead` parameter. We use the value of the function call on the chart's previous bar. Since values between the repainting and non-repainting versions only differ on the timeframe's last bar, we can use the previous value so that the update only occurs on the timeframe's first bar, as it will in realtime when not repainting. In the realtime bar, we use the second call, where the offsets are inverted. This is because if we used the first call in realtime, we would be fetching the value of the repainting function on the previous bar, so the close of the last bar. What we want, instead, is the data from the previous, higher timeframe bar , which has elapsed and is confirmed, and thus will not change throughout realtime bars, except on the first constituent chart bar belonging to a new higher timeframe. After the offsets, the Data Window shows values for the `barstate.*` variables we use in our calculations. █  NOTES Why are we revisiting security()  ? For four reasons:  1 — We were seeing coders misuse our `f_secureSecurity()` function presented in How to avoid repainting when using security() .    Some novice coders were modifying the offset used with the history-referencing operator in the function, making it zero instead of one,    which to our horror, caused look-ahead bias when used with `lookahead = barmerge.lookahead_on`.    We wanted to present a safer function which avoids introducing the dreaded "lookahead" in the scripts of unsuspecting coders.  2 — The popularity of security() in screener-type scripts where coders need to use the full 40 calls allowed per script made us want to propose    a solid method of allowing coders to offer a repainting/no-repainting choice to their script users with only one security() call.  3 — We wanted to explain why some alternatives we see circulating are inadequate and produce misleading behavior.  4 — Our previous publication on security() focused on how to avoid repainting, yet many other considerations worthy of attention are not related to repainting. Handling tuples When sending function calls that return tuples with security() , our `f_security()` function will not work because Pine does not allow us to use the history-referencing operator with tuple return values. The solution is to integrate the inside offset to your function's arguments, use it to offset the results the function is returning, and then add the outside offset in a reassignment of the tuple variables, after security() returns its values to the script, as we do in our "c2" example. Does it repaint? We're pretty sure Wilder was not asked very often if RSI repainted. Why? Because it wasn't in fashion—and largely unnecessary—to ask that sort of question in the 80's. Many traders back then used daily charts only, and indicator values were calculated at the day's close, so everybody knew what they were getting. Additionally, indicator values were calculated by generally reputable outfits or traders themselves, so data was pretty reliable. Today, almost anybody can write a simple indicator, and the programming languages used to write them are complex enough for some coders lacking the caution, know-how or ethics of the best professional coders, to get in over their heads and produce code that does not work the way they think it does. As we hope to have clearly demonstrated, traders do have legitimate cause to ask if MTF scripts repaint or not when authors do not specify it in their script's description. ► We recommend that authors always use our `f_security()` with `false` as the last argument to avoid repainting when fetching data dependent on OHLCV information. This is the only way to obtain reliable HTF data. If you want to offer users a choice, make non-repainting mode the default, so that if users choose repainting, it will be their responsibility. Non-repainting security() calls are also the only way for scripts to show historical behavior that matches the script's realtime behavior, so you are not misleading traders. Additionally, non-repainting HTF data is the only way that non-repainting alerts can be configured on MTF scripts, as users of MTF scripts cannot prevent their alerts from repainting by simply configuring them to trigger on the bar's close. Data feeds A chart at one timeframe is made up of multiple feeds that mesh seamlessly to form one chart. Historical bars can use one feed, and the realtime bar another, which brokers/exchanges can sometimes update retroactively so that elapsed realtime bars will reappear with very slight modifications when the browser's tab is refreshed. Intraday and daily chart prices also very often originate from different feeds supplied by brokers/exchanges. That is why security() calls at higher timeframes may be using a completely different feed than the chart, and explains why the daily high value, for example, can vary between timeframes. Volume information can also vary considerably between intraday and daily feeds in markets like stocks, because more volume information becomes available at the end of day. It is thus expected behavior—and not a bug—to see data variations between timeframes. Another point to keep in mind concerning feeds it that when you are using a repainting security() plot in realtime, you will sometimes see discrepancies between its plot and the realtime bars. An artefact revealing these inconsistencies can be seen when security() plots sometimes skip a realtime chart bar during periods of high market activity. This occurs because of races between the chart and the security() feeds, which are being monitored by independent, concurrent processes. A blue arrow on the chart indicates such an occurrence. This is another cause of repainting, where realtime bar-building logic can produce different outcomes on one closing price. It is also another argument supporting our recommendation to use non-repainting data. Alternatives There is an alternative to using security() in some conditions. If all you need are OHLC prices of a higher timeframe, you can use a technique like the one Duyck demonstrates in his security free MTF example - JD script. It has the great advantage of displaying actual repainting values on historical bars, which mimic the code's behavior in the realtime bar—or at least on elapsed realtime bars, contrary to a repainting security() plot. It has the disadvantage of using the current chart's TF data feed prices, whereas higher timeframe data feeds may contain different and more reliable prices when they are compiled at the end of the day. In its current state, it also does not allow for a repainting/no-repainting choice. When `lookahead` is useful When retrieving non-price data, or in special cases, for experiments, it can be useful to use `lookahead`. One example is our Backtesting on Non-Standard Charts: Caution! script where we are fetching prices of standard chart bars from non-standard charts. Warning users Normal use of security() dictates that it only be used at timeframes equal to or higher than the chart's. To prevent users from inadvertently using your script in contexts where it will not produce expected behavior, it is good practice to warn them when their chart is on a higher timeframe than the one in the script's "Timeframe" field. Our `f_tfReminderAndErrorCheck()` function in this script does that. It can also print a reminder of the higher timeframe. It uses one security() call. Intrabar timeframes security() is not supported by TradingView when used with timeframes lower than the chart's. While it is still possible to use security() at intrabar timeframes, it then behaves differently. If no care is taken to send a function specifically written to handle the successive intrabars, security() will return the value of the last intrabar in the chart's timeframe, so the last 1H bar in the current 1D bar, if called at "60" from a "D" chart timeframe. If you are an advanced coder, see our FAQ entry on the techniques involved in processing intrabar timeframes. Using intrabar timeframes comes with important limitations, which you must understand and explain to traders if you choose to make scripts using the technique available to others. Special care should also be taken to thoroughly test this type of script. Novice coders should refrain from getting involved in this. █  TERMINOLOGY Timeframe Timeframe , interval and resolution are all being used to name the concept of timeframe. We have, in the past, used "timeframe" and "resolution" more or less interchangeably. Recently, members from the Pine and PineCoders team have decided to settle on "timeframe", so from hereon we will be sticking to that term. Multi-timeframe (MTF) Some coders use "multi-timeframe" or "MTF" to name what are in fact "multi-period" calculations, as when they use MAs of progressively longer periods. We consider that a misleading use of "multi-timeframe", which should be reserved for code using calculations actually made from another timeframe's context and using security() , safe for scripts like Duyck's one mentioned earlier, or TradingView's Relative  Volume  at  Time , which use a user-selected timeframe as an anchor to reset calculations. Calculations made at the chart's timeframe by varying the period of MAs or other rolling window calculations should be called "multi-period", and "MTF-anchored" could be used for scripts that reset calculations on timeframe boundaries. Colophon Our script was written using the PineCoders Coding Conventions for Pine . The description was formatted using the techniques explained in the How We Write and Format Script Descriptions PineCoders publication. Snippets were lifted from our MTF Selection Framework , then massaged to create the `f_tfReminderAndErrorCheck()` function. █  THANKS Thanks to apozdnyakov for his help with the innards of security() . Thanks to bmistiaen for proofreading our description. Look first. Then leap.
Индикатор Pine Script®
от PineCoders
61