ACD - Layers 1 & 2An implementation of layers 1 & 2 of ACD strategy of Mark Fisher, based on the book "The Logical Trader".
This implementation contains:
- OR lines
- A lines
- C lines
- Daily pivot range
- N days pivot range
- Customizable trading session
Strategy summary (This implementation):
There is 3 main concepts, each of which represented as two price levels.
1) OR (Opening Range) is the range of the first bar of the day. In other words, it's just "high - low" of the first resolution (usually 15min.) bar of the day. So, OR lines (Aqua color) visualize this range for each trading session.
As stated by Mark Fisher in his book, this range is meant to be a statistically significant range such that when price breaks the range in one direction, This is UNUSUAL to infiltrate it again AND break through the other side. So we can consider it as a potential enter signal (long or short).
2) A lines (Blue color) are drawn above and below OR lines with difference of 10% 0f 10 days ATR. The ATR period and the A multiplier (usually 10%) is customizable.
3) C lines (Gray color) are drawn above and below OR lines at 15% of 10 Days ATR difference. These lines help detecting AND confirming that UNUSUAL situation.
These concepts form the layer 1, which you can spot potential opportunities with it.
There is also two ranges to show support and resistance levels based on price action of previous days. Pivot ranges are rolling ranges that calculated and last for each day separately. They only differ in calculation period - the first one is daily (yellow color area) and the other one (red color area) is customizable, but is usually 3 or 5 days.
Each range consists of two price levels, valid for the current trading session. One of theme is HL2 , and the other one is "HLC3 + abs(HLC3 - HL2 )".
These two ranges, "Daily pivot range" and "N days pivot range", form the layer 2, which you can see them as two dynamic support/resistance ranges - one for daily, and the other for N days. They help filtering opportunities spotted from layer 1.
There is 2 more layers in the ACD strategy, which is omitted in this free implementation.
在腳本中搜尋"daily"
`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.
Indices Sector SigmaSpikes█ OVERVIEW
“The benchmark Dow Jones Industrial Average is off nearly 300 points as of midday today...”
“So what? Is that a lot or a little? Should we care?”
-Adam H Grimes-
This screener aims to provide Bird-Eye view across sector indices, to find which sector is having significant or 'out-of-norm' move in either direction.
The significance of the move is measured based on Sigma Spikes, a method proposed by Adam H. Grimes, where Standard Deviation of returns used as a baseline.
*You can google his blog or read his book, got some gold in there, especially on how he use indicators for trading
█ Understanding Sigma Spikes
As described by Grimes, moves in markets are only meaningful when we consider what “normal” is for that market.
Without that baseline, the daily change number, and even the percent change on the day doesn’t really mean much.
To overcome that problem, Sigma Spikes, as a measure of volatility, attempt to put todays change in price (aka return) in context of the standard deviation of 20 days daily's return.
Refer chart below:
1. The blue bars refer to each days return
2. The orange line is 1 time standard deviation of past 20days daily's return (today not included)
3. The red line is 2 time standard deviation of past 20days daily's return (today not included)
Using the ratio of today's return over the Std Deviation, determining your threshold (1,2,3,etc) will be the key that tells if today's move is significant or not.
*Threshold referring to times standard deviation, and different market may require different threshold.
*20 Days period are based on the Lookback Period, adjustable from user input window.
█ Features
- Scan up to 13 symbols at a time (Bursa (MYX) indices are defaulted, but you may change to any symbols/index from the user input setting)
█ Limitation
- Due to multiple use of security() function required to call other symbols, expect the screener to be slow at certain times
- Custom Timeframe currently accept only Daily and Weekly. I'll try to include lower timeframe in the next update
█ Disclaimer
Past performance is not an indicator of future results.
My opinions and research are my own and do not constitute financial advice in any way whatsoever.
Nothing published by me constitutes an investment recommendation, nor should any data or Content published by me be relied upon for any investment/trading activities.
I strongly recommends that you perform your own independent research and/or speak with a qualified investment professional before making any financial decisions.
Any ideas to further improve this indicator are welcome :)
Multi RSI based on Timeframe
This code has been inherited from " 3 RSI Multi Timeframe Inception" by pranjalchaubey and enhanced/modified to include 2 more RSI indicators. The RSIs considered are 15 minutes, 1 Hour, Daily, Weekly and Monthly displayed based on chart time frame.
The number of RSI indicators displayed is context dependant or time frame based, as below,
15min, hourly and daily RSIs are displayed on 15 mins or hourly charts, often used for Intraday trading,
Daily, Weekly and Monthly RSIs are displayed for Daily charts / Swing trading and
Weekly and Monthly RSIs for Weekly time frame / Positional trades.
Derived moving averagesBITSTAMP:BTCUSD
This indicator shows five derived moving averages based on a daily simple moving average (daily MA).
The derived moving averages are projected along the daily MA on which they are based on the chart.
The period of the daily MA, and the percentages by which the derived moving averages are removed from the daily MA are adjustable.
The derived moving averages are shown both above and below the daily MA.
The derived moving averages act as support and resistance .
This indicator can be used for a wide array of markets.
As far as I know this indicator can be used for stocks, cryptocurrencies, futures , Forex and bond yields.
It only works on hourly time frames.
10ema Basic Swing Trade StrategySTRATEGY INGREDIENTS
* DAILY chart
* 10 ema on daily
* 50 ema on daily
STRATEGY RECIPE SUMMARY
Wait for a CLOSE BELOW the 10 ema on the daily chart ...YESTERDAY. Wait for a CLOSE ABOVE the 10ema TODAY...ensure the price action is ABOVE the 50 ema on the daily chart ...buy at the close if the green arrow indicator is shown. Be sure to get your order filled BEFORE the market closes -- if you are using directional options...b/c you know, the options market doesn't have after hours.
BE AWARE of your own risk tolerance...step stops at appropriate levels...Take responsibility for your own trades. BACKTEST this strategy before using a LIVE MONEY TRADING ACCOUNT.
MTF SMA on specific timeframe(5M-4H)Japanese below. 日本語の説明は下記
This is multi time frame simple moving average that is shown only on the specific timeframe; 5M, 15M, 30M, 1H, 4H.
Problem of conventional MTF moving average is that MTF MA is sometimes annoying especially when you look at upper timeframe such as daily chart and/or weekly chart.
e.g. You set 20 MA of 4 hour chart into 1 hour chart, however, when you look at daily chart, daily chart also shows 20MA of 4 hour chart which is unnecessary.
This is why I have developed this MTF SMA indicator shown only on the timeframe from 5M to 4 hour.
With this indicator, even if you set MA of upper timeframe(such as 4 hour) into Lower timeframe, that MA will not be shown on above daily chart.
You can customize adding or removing below code;
timeframe.period == “X”? security(syminfo.tickerid, res, sma(src, ma_len))
X is the timeframe that you would add/remove from the indicator.
——————————————————————————————
特定の時間軸にのみ表示されるマルチタイムフレーム移動平均線のインジケーターです。
従来のマルチタイムフレーム移動平均線の問題点は、上位足に切り替えた時にもマルチタイムフレーム移動平均線の設定が表示され、チャートが見にくくなる点でした。
例: 4時間足の20MAをマルチタイムフレーム移動平均線としてセットしたとします。この場合、1時間足などの下位足で4時間足の20MAが表示されることになりますが、同時に日足や週足といった上位足チャートを見る時にも、この4時間足の20MAが表示されてしまいます。
このインジケーターでは、従来のマルチタイムフレーム移動平均線と同様に、設定元となる上位足の時間軸(4時間、日足など)を選択し、期間とソースを設定することができる一方で、表示されるのは5分足、15分足、30分足,1時間足、4時間足のみとなります。
スクリプトのMAの取得部分に以下コードを追加することで、必要な時間軸を追加・削除することが可能です。
timeframe.period == “X”? security(syminfo.tickerid, res, sma(src, ma_len))
Xは表示したい時間軸です。4時間足チャートからこのインジケーターを削除したい場合は
timeframe.period == “240”? security(syminfo.tickerid, res, sma(src, ma_len))
を削除してください。
Bitcoin Block Height (Total Blocks)Bitcoin Block Height by RagingRocketBull 2020
Version 1.0
Differences between versions are listed below:
ver 1.0: compare QUANDL Difficulty vs Blockchain Difficulty sources, get total error estimate
ver 2.0: compare QUANDL Hash Rate vs Blockchain Hash Rate sources, get total error estimate
ver 3.0: Total Blocks estimate using different methods
--------------------------------
This indicator estimates Bitcoin Block Height (Total Blocks) using Difficulty and Hash Rate in the most accurate way possible, since
QUANDL doesn't provide a direct source for Bitcoin Block Height (neither QUANDL:BCHAIN, nor QUANDL:BITCOINWATCH/MINING).
Bitcoin Block Height can be used in other calculations, for instance, to estimate the next date of Bitcoin Halving.
Using this indicator I demonstrate:
- that QUANDL data is not accurate and differ from Blockchain source data (industry standard), but still can be used in calculations
- how to plot a series of data points from an external csv source and compare it with another source
- how to accurately estimate Bitcoin Block Height
Features:
- compare QUANDL Difficulty source (EOD, D1) with external Blockchain Difficulty csv source (EOD, D1, embedded)
- show/hide Quandl/Blockchain Difficulty curves
- show/hide Blockchain Difficulty candles
- show/hide differences (aqua vertical lines)
- show/hide time gaps (green vertical lines)
- count source differences within data range only or for the whole history
- multiply both sources by alpha to match before comparing
- floor/round both matched sources when comparing
- Blockchain Difficulty offset to align sequences, bars > 0
- count time gaps and missing bars (as result of time gaps)
WARNING:
- This indicator hits the max 1000 vars limit, adding more plots/vars/data points is not possible
- Both QUANDL/Blockchain provide daily EOD data and must be plotted on a daily D1 chart otherwise results will be incorrect
- current chart must not have any time gaps inside the range (time gaps outside the range don't affect the calculation). Time gaps check is provided.
Otherwise hardcoded Blockchain series will be shifted forward on gaps and the whole sequence become truncated at the end => data comparison/total blocks estimate will be incorrect
Examples of valid charts that can run this indicator: COINBASE:BTCUSD,D1 (has 8 time gaps, 34 missing bars outside the range), QUANDL:BCHAIN/DIFF,D1 (has no gaps)
Usage:
- Description of output plot values from left to right:
- c_shifted - 4x blockchain plotcandles ohlc, green/black (default na)
- diff - QUANDL Difficulty
- c_shifted - Blockchain Difficulty with offset
- QUANDL Difficulty multiplied by alpha and rounded
- Blockchain Difficulty multiplied by alpha and rounded
- is_different, bool - cur bar's source values are different (1) or not (0)
- count, number of differences
- bars, total number of bars/data points in the range
- QUANDL daily blocks
- Blockchain daily blocks
- QUANDL total blocks
- Blockchain total blocks
- total_error - difference between total_blocks estimated using both sources as of cur bar, blocks
- number_of_gaps - number of time gaps on a chart
- missing_bars - number of missing bars as result of time gaps on a chart
- Color coding:
- Blue - QUANDL data
- Red - Blockchain data
- Black - Is Different
- Aqua - number of differences
- Green - number of time gaps
- by default the indicator will show lots of vertical aqua lines, 138 differences, 928 bars, total error -370 blocks
- to compare the best match of the 2 sources shift Blockchain source 1 bar into the future by setting Blockchain Difficulty offset = 1, leave alpha = 0.01 =>
this results in no vertical aqua lines, 0 differences, total_error = 0 blocks
if you move the mouse inside the range some bars will show total_error = 1 blocks => total_error <= 1 blocks
- now uncheck Round Difficulty Values flag => some filled aqua areas, 218 differences.
- now set alpha = 1 (use raw source values) instead of 0.01 => lots of filled aqua areas, 871 differences.
although there are many differences this still doesn't affect the total_blocks estimate provided Difficulty offset = 1
Methodology:
To estimate Bitcoin Block Height we need 3 steps, each step has its own version:
- Step 1: Compare QUANDL Difficulty vs Blockchain Difficulty sources and estimate error based on differences
- Step 2: Compare QUANDL Hash Rate vs Blockchain Hash Rate sources and estimate error based on differences
- Step 3: Estimate Bitcoin Block Height (Total Blocks) using different methods in the most accurate way possible
QUANDL doesn't provide block time data, but we can calculate it using the Hash Rate approximation formula:
estimated Hash rate/sec H = 2^32 * D / T, where D - Difficulty, T - block time, sec
1. block time (T) can be derived from the formula, since we already know Difficulty (D) and Hash Rate (H) from QUANDL
2. using block time (T) we can estimate daily blocks as daily time / block time
3. block height (total blocks) = cumulative sum of daily blocks of all bars on the chart (that's why having no gaps is important)
Notes:
- This code uses Pinescript v3 compatibility framework
- hash rate is in THash/s, although QUANDL falsely states in description GHash/s! THash = 1000 GHash
- you can't read files, can only embed/hardcode raw data in script
- both QUANDL and Blockchain sources have no gaps
- QUANDL and Blockchain series are different in the following ways:
- all QUANDL data is already shifted 1 bar into the future, i.e. prev day's value is shown as cur day's value => Blockchain data must be shifted 1 bar forward to match
- all QUANDL diff data > 1 bn (10^12) are truncated and have last 1-2 digits as zeros, unlike Blockchain data => must multiply both values by 0.01 and floor/round the results
- QUANDL sometimes rounds, other times truncates those 1-2 last zero digits to get the 3rd last digit => must use both floor/round
- you can only shift sequences forward into the future (right), not back into the past (left) using positive offset => only Blockchain source can be shifted
- since total_blocks is already a cumulative sum of all prev values on each bar, total_error must be simple delta, can't be also int(cum()) or incremental
- all Blockchain values and total_error are na outside the range - move you mouse cursor on the last bar/inside the range to see them
TLDR, ver 1.0 Conclusion:
QUANDL/Blockchain Difficulty source differences don't affect total blocks estimate, total error <= 1 block with avg 150 blocks/day is negligible
Both QUANDL/Blockchain Difficulty sources are equally valid and can be used in calculations. QUANDL is a relatively good stand in for Blockchain industry standard data.
Links:
QUANDL difficulty source: www.quandl.com
QUANDL hash rate source: www.quandl.com
Blockchain difficulty source (export data as csv): www.blockchain.com
RVC-Trade-With-Pivot-LevelsHow to Use PIVOT Levels for Trading
Always remember ->: *Trade with trend*
About script:
1. Daily and Weekly close above Pivot Level.
-- Sentiment is highly positive. Pivot Level acts as strong support.
2. Daily Close above Pivot and Weekly Close Below Pivot
-- Sentiment is positive.Weekly Pivot Level may act as strong resistance.
3. Daily close below Pivot and weekly close above Pivot
-- Sentiment is negative but weekly Pivot Level can acts as strong support.
4. Daily and Weekly Close below Pivot Level
-- Sentiment is highly Negative. Pivot Level acts as strong resistance.
BUY/SELL -- ENTRY
BUY ABOVE 23.6% UPWARD
IF Trend is positive and price cross and sustains above 23.6%(R1) upside, then it will be entry from BUY perspective.
If R1 is entry, R2/R3/R4/R5 ... will be targets.
SELL Below 23.6% Downward
IF Trend is negative and price cross and sustains below 23.6%(S1) downside, then it will be entry from SELL perspective.
If S1 is Sell side entry, S2/S3/S4/S5 will be targets.
Before taking ENTRY on BUY or SELL Side, please know your risk levels, Stop Loss and trade EXECUTION process.
Finally:
My view is my view and remains with me only. Once you accept it and trade it, it becomes your view. So credit or blame all yours.:)
Ultimate Moving Averages (SMA & EMA)Welcome to the Ultimate Moving Average indicator.
Never again spend time looking for EMA / SMA indicators when you can have them all in this single indicator.
Options include :
Daily Chart: Classic Golden / Death Cross - 50/D and 200/D SMA
Daily Chart: 3-day Golden / Death Cross - 150/D and 600/D SMA
Daily Chart: 140/D SMA
Daily Chart: 700/D SMA
Daily Chart: 1458/D SMA
Daily Chart: Golden Ratio Multiplier
Any Chart: Scalping
9 SMA
10 SMA
20 SMA
21 SMA
30 SMA
34 SMA
50 SMA
80 SMA
100 SMA
200 SMA
8 EMA
10 EMA
13 EMA
20 EMA
21 EMA
26 EMA
30 EMA
34 EMA
50 EMA
55 EMA
80 EMA
89 EMA
100 EMA
200 EMA
FIB vs HLThis script show the relation bettwen daily fib seen in red =upper and blue=lower to daily candles upper and lower
since there is slight variation how both calculated we can see that when daily fib is lower then the low candles daily low then there is a good chance for a buy trend
and vice versa in oposite direction
so it just a nice idea that need further verification
All past LevelsContains all past levels that we need
1. Previous Monthly High
2. Previous Monthly Low
3. Previous Weekly High
4. Previous Weekly Low
5. Previous Daily High
6. Previous Daily Low
7. Previous Monthly Range Average (PMH+PML)/2
8. Previous WeeklyRange Average (PWH+PWL)/2
9. Previous Daily Range Average (PDH+PDL)/2
10. Monthly Open
11. Weekly Open
12. Daily Open
EMA Strategy v_1 by.JanS.This Strategy use in 1 hour and daily graph.
Long Strategy;
The strategy is if the EMA_5 cross over EMA_10 in 1 hour chart, it is long opportunity. Now check the price on daily chart.
If the EMA_5 cross over EMA_10 in daily chart, long more!!.
Short Strategy;
If the EMA_5 cross under EMA_10 in 1 hour chart, it is a short opportunity. Now check the price on daily chart.
If the EMA_5 cross under EMA_10 in daily chart, short more!!
This is my first pine editor code. I am new at coding.
Double RSIThis is double RSI script which plots one time frame higher RSI along with the current time frame i.e
For Weekly chart it display Weekly and Monthly RSI
For Daily chart it display Daily and Weekly RSI
For Intraday chart it display Intraday and Daily RSI.
Usage:
If Daily RSI is above 60 and weekly above 40 and moving up then stock is in a good uptrend look for buying when Daily takes support at 60. Usually First test of Daily produces a good entry for subsequent entries probability decreases.
For Downtrend look for Daily RSI below 40 and weekly below 60.
Stochastic binary option styleUsing Time Frames For Trend – You can also use different time frames to determine trends with stochastic. To do this you will need to use two different time frame charts, I like to use the weekly/daily or daily/hourly combination depending on the asset. Weekly/daily works well with stocks and indices while I prefer the shorter time frame for currency and commodities. This is how it works; stochastic on the longer term chart sets trend, stochastic on the shorter term chart gives the signal. If, on the weekly chart, stochastic is pointing up then you would trade bullish signals on the daily charts. Or if using the daily/hourly combo the stochastic on the daily would set trend while signals would come from the hourly chart.
Green color bar and background means k is > d, the crowd is bullish (trend is bullish, a bullish crossover is happened), red is the contrary (bears are the leaders)
Credit to Michael Hodges
Ultimate Moving Average Package (17 MA's)Included is the:
VWAP
Current time frame 10 EMA
Current time frame 20 EMA
Current time frame 50 EMA
Current time frame 10 SMA
Current time frame 20 SMA
Current time frame 50 SMA
Daily 10 EMA
Daily 20 EMA
Daily 50 EMA
Daily 50 SMA
Daily 100 SMA
Daily 200 SMA
Weekly 100 SMA
Weekly 200 SMA
Monthly 100 SMA
Monthly 200 SMA
All Daily/Weekly/Monthly MA's can be seen on intraday charts. Current time frame MA's change depending on your time frame. Obviously you dont need all 17 on your chart but you can pick the ones you like and disable the rest.
ATR based Pivots mcbwHey everyone this is an exciting new script I have prepared for you.
I was reading an old forex bulletin article some time ago when I came across this: solar.murty.net (or you can download the full bulletin with lots of other good articles here: www.forexfactory.com).
You can already buy this for metatrader (www.mql5.com) so I figured to make it for free for tradingview.
This bulletin suggested that you can reasonably predict daily volatility by adding or subtracting multiples of the daily ATR to the daily opening. Using this you can choose multiples to use as price targets and alternatively as stop losses. For example, if you already have a sense of market direction you can buy at market open place a stop loss at - 1 daily ATR and a profit target at + 3 ATRs for a risk to reward ratio of 3. If you are looking for smaller/quicker moves with a ratio of 3 you can have a stop loss at -0.25 ATR and a take profit at +0.75 ATR.
Alternatively this article also suggests to use this method to catch volatility breakouts. If price is higher than the + 1 ATR area then you can safely assume it will be going to the +2 ATR area so you can put a buy stop at + 1 ATR with a profit target at + 2 ATR with a stop loss at +0.5 ATR to catch a volatility breakout with a risk to reward ratio of 2!
Even further there are methods that you can use with ATRs of multiple window sizes, for example by opening two copies of this indicator and measuring recent volatility with a 1 week window and long term volatility within a 1 month window. If the short term volatility is crossing the long term volatility then there is a high probability chance that even more price movement will occur.
However I have found that this method is good for more than daily volatility , it can also be used to measure weekly volatility , and monthly volatility and use these multiples as good long term price targets.
To select if you want daily, weekly, or monthly values of the ATR of volatility you're using go to the settings and click on the options in the "Opening period". The default window of the ATR here is 14 periods, but you can change this if you want to in "ATR period". Most importantly you are able to select which multiples of the ATR you would like to use in the settings in "ATR multiple 1" which is the green line, "ATR multiple 2" which is the blue line, and "ATR multiple 3" which is the purple line. You can select any values you want to put in these, the choice of 0.25, 0.5, and 1 is not special, some people use fibonacci numbers here or simply 0.33, 0.66, and 0.99.
Repainting issue: This script uses the daily value of the Average True Range (ATR), which measures the volatility that is happening today. If price becomes more volatile then the value of the ATR can increase throughout the day, but it can never decrease. What this means is that the ATR based pivots are able to expand away from the opening price, which should not affect the trades that you take based on these areas. If you base your take profit on one of these ATR multiples and the daily volatility increase this means that your take profit area will be closer to your entry than the ATR multiple. Meaning that your trades will be more conservative.
While this all may sound very technical it is super intuitive, throw this on your chart and play around with it :)
Happy trading!
Pivot Point Monthly - bitcoin by Simon-RoseMonthly Version:
I have written 3 Indicators because i couldn't find what i was looking for in the library, so you can turn each one on and off individually for better visibility.
This are Daily, Weekly and Monthly Pivot Points with their Resistance and Support Points
and also on the Daily with the range between them.
I will also publish some Ideas to show you how to use them if you are not familiar with the traditional pivot points strategy already.
Unlike the usually 3 support & resistances i added 4 of them, specifically for trading bitcoin (on traditional markets this level of volatility usually never gets touched)
Here you can see which lines are what for reference, as the Feature to label lines is missing in Pinescript (if you have a workaround pls tell me ;) )
This is the basic calculation used :
PP = (xHigh+xLow+xClose) / 3
R1 = vPP+(vPP-Low)
R2 = vPP + (High - Low)
R3 = xHigh + 2 * (vPP - Low)
R4 = xHigh + 3 * (vPP - Low)
S1 = vPP-(High - vPP)
S2 = vPP - (High - Low)
S3 = xLow - 2 * (High - PP)
S4 = xLow - 3 * (High - PP)
If you have any questions or suggestions pls write me :)
Happy trading
Cheers
Daily Version:
Weekly Version:
Pivot Points Weekly - bitcoin by Simon-RoseWeekly Version:
I have written 3 Indicators because i couldn't find what i was looking for in the library, so you can turn each one on and off individually for better visibility.
This are Daily, Weekly and Monthly Pivot Points with their Resistance and Support Points
and also on the Daily with the range between them.
I will also publish some Ideas to show you how to use them if you are not familiar with the traditional pivot points strategy already.
Unlike the usually 3 support & resistances i added 4 of them, specifically for trading bitcoin (on traditional markets this level of volatility usually never gets touched)
Here you can see which lines are what for reference, as the Feature to label lines is missing in Pinescript (if you have a workaround pls tell me ;) )
This is the basic calculation used :
PP = (xHigh+xLow+xClose) / 3
R1 = vPP+(vPP-Low)
R2 = vPP + (High - Low)
R3 = xHigh + 2 * (vPP - Low)
R4 = xHigh + 3 * (vPP - Low)
S1 = vPP-(High - vPP)
S2 = vPP - (High - Low)
S3 = xLow - 2 * (High - PP)
S4 = xLow - 3 * (High - PP)
If you have any questions or suggestions pls write me :)
Happy trading
Cheers
Daily Version:
Monthly Version:
Overlay Higher Timeframe EMA 10Plot the daily and weekly EMA 10 on any timeframe.
The Daily EMA 10 is useful for helping a trader decide whether the price is overextended without switching back to the daily timeframe and losing focus. It will change colour to indicate which order the EMA 10 and EMA 20 is in.
The Weekly EMA 10 is useful for helping a trader decide whether to take a trade based on long term momentum. If it is over the current price then the market has more momentum to the downside and if it is under then the market has more momentum to the upside. It will also change colour depending on which order the EMA 10 and EMA 20 is in. The weekly is often forgotten in trade planning.
You can switch the Daily and the Weekly on and off independently and change styles if you wish.
Volumeweighted macd leader with bb squeezethis indicator is very useful for stocks or crytpto especialy 3d and weekly charts
daily shows good too but if u re a daily trader use it if not dont use it coz 4h and daily is noisy some when there is no trend
thats why weekly and 3d is good because it ll give u accurate signal and trend reversals
this is not my script just a combination of lazybear squeeze momentum, macdleader and volume weighted macd of kivanc
i merge them so it also shows bb squeeze on zero line and settings name is median
macd leader is 2 differen color above zero line and below zero line
above zero line if macd leader is green its buy signal and trend is up
if blue it meand no trend or trend reversal so sell or wait if u use 4h or daily but 3d and weekly it means sell
below zero line macd leader color is red and means that there is downtrend and do not buy
when 3d or weekly turns blue on macd leader it means trend reversal about the start
good with heiken ashi candles
DO NOT FORGET THIS IS NOT PERFECT INDICATOR FOR SHORT TERM, PREFER IT 3D AND WEEKLY FR BETTER RESULTS
Awesome Moving AveragesThis script allows you to add up to four simple and exponential moving averages the the chart instead of adding 4 simple moving averages and 4 exponential moving averages individually.
The stronger lines are SMA's and the thinner lines are EMA's.
White - "1st SMA" and "1st EMA"
Green - "2nd SMA" and "2nd EMA"
Blue - "3rd SMA" and "3rd EMA"
Red - "4th SMA" and "4th EMA"
You can modify which moving averages are visible on the chart and also modify the period of the moving averages.
There are four periods which you can edit - each period applies to a pair of moving averages (a pair of SMA and EMA). For example: "1st MA Length" option applies to "1st SMA" and "1st EMA" etc.
ibb.co
In addition to that Awesome Moving Averages script allows you to keep the daily moving averages resolution on intraday charts.
For example - here we have only "1st SMA" and "1st EMA" enabled and we are viewing a daily chart:
Now if we have "Keep Daily MA Resolution On Intraday Periods" option enabled we would see the daily moving averages (SMA and EMA) on intraday periods. Here we are viewing a 4h chart:
If you disable this option you would see the moving averages on intraday charts with the intraday MA lengths as you expect:
"Visible MA's On Intraday Periods" option allows you to choose which MA's you would like to be visible on intraday charts if the "Keep Daily MA Resolution On Intraday Periods" option is enabled.
If you have any thoughts or ideas on how to improve the "Awesome Moving Averages" script then let me know!
4hr chart Moving Average Ribbon in daysUse this for the 4hr chart view.
Adapted from the MMAR standard so that I can see daily MA/SMA's directly from the 4hr chart. regular counts included and day counts shown in titles.
I use this with the 50ma, 14 daily, 30 daily, 50 daily, 100 & 200 daily active, the rest disabled.
Enjoy.
