Polyphase MACD (PMACD)The Polyphase MACD (PMACD) uses polyphase decimation to create a continuous estimate of higher timeframe MACD behavior. The number of phases represents the timeframe multiplier - for example, 3 phases approximates a 3x higher timeframe.
Traditional higher timeframe MACD indicators update only when each higher timeframe bar completes, creating stepped signals that can miss intermediate price action. The PMACD addresses this by maintaining multiple phase-shifted MACD calculations and combining them with appropriate anti-aliasing filters. This approach eliminates the discrete jumps typically seen in higher timeframe indicators, though the resulting signal may sometimes deviate from the true higher timeframe values due to its estimative nature.
The indicator processes price data through parallel phase calculations, each analyzing a different time-offset subset of the data. These phases are filtered and combined to prevent aliasing artifacts that occur in simple timeframe conversions. The result is a smooth, continuous signal that begins providing meaningful values immediately, without requiring a warm-up period of higher timeframe bars.
The PMACD maintains the standard MACD components - the MACD line (fast MA - slow MA), signal line, and histogram - while providing a more continuous view of higher timeframe momentum. Users can select between EMA and SMA calculations for both the oscillator and signal components, with all calculations benefiting from the same polyphase processing technique.
Pine
FUNCTION: Limited Historical Data WorkaroundFUNCTION: Limited Historical Data Workaround
If you are working with bitcoin weekly charts, or any other ticker with a low amount of price history this function may help you out. For example you want to apply indicators to some shitcoin that just launched? This can help you.
It can be frustrating to use certain built-ins since they will only give an output once the full lookback length is available. This function allows you to avoid that situation and start plotting things with almost no history whatsoever!
In this example code we do it by utilizing a replacement for the built in pine SMA function. This function allows us to pass a series instead of just a simple int to the length variable of the SMA. This can be achieved with all the pine built ins and I believe @pinecoders has a publication already detailing many of them with full coded examples.
Then we replace the length of the SMA with the custom history function. It checks to see if the current bar index is less than the length of the function. Then if it is, it changes the length to the bar index allowing us to get plots and series earlier than otherwise possible.
PSv5 Color Magic and Chart Theme SimulatorKEEP YOUR COINS FOLKS! I DON'T NEED THEM, DON'T WANT THEM. Many other talented authors on TV deserve them.
INTRODUCTION:
This is my "PSv5 Color Magic and Chart Theme Simulator" displayed using Pine Script version 5.0. The purpose of this PSv5 colorcator is to show vivid colors that are most suitable in my opinion for modifying or developing Pine scripts. Whether you are new to Pine or an experienced Pine poet, this should aid you in developing indicators with stunning color from the provided color list that is easily copied and pasted into any novel script you should possess. Whichever colors you choose, and how, is up to your imagination's capacity.
COMMENTARY:
I have a thesis. Pine essentially is a gigantor calculator with a lot of programmable bells and whistles to perform intense analytics. Zillions of numbers per day are blended up into another cornucopia of numbers to analyze. The thing is, ALL of those numbers are moot unless we can informatively portray them in various colorized forms with unique methods to point out significant numeric events. By graphically displaying them with specific modes of operation, only then do these numbers truly make any sense to us and become quantitatively beneficial.
I have to admit... I hate numbers. I never really liked them, even before I knew what an ema() was. Some days I almost can't stand them, and on occasion I feel they deserve to be flushed down the toilet at times. However, I'm a stickler for a proper gauge of measurements. Numbers are a mental burden, but they do have "purpose and meaning". That's where COLOR comes in! By applying color in specific ways in varying dynamic forms, we can generate smarter visual aids from these numerics. Numbers can be "transformed" into something colorful it wasn't before, into a tool, like a hammer. But we don't need a hammer, we need an impressive jack hammer for BIG problem solving that we could never achieve in the not to distant past.
As time goes on, we analytically measure more, and more, and more each year. It's necessary to our continual evolution. That's one significant difference between us and cave men, and the pertinent reason why we are quickly evolving as a species, while animals haven't. Humankind is gifted to enumerate very well AND blessed to see in color. We use it for innumerable things in the technological present for purpose and pleasure. Day in and day out, we take color for granted, because it's every where we can look. The fact is, color is the most important apparatus in humankind's existence EVER. We wouldn't have survived this far without it.
By utilizing color to it's grand potential, greater advancements can be attained while simultaneously being enjoyed visually. Once color is transformed from it's numeric origins into applicable tools, we can enjoy the style, elegance, and QUALITATIVE nature of the indication that can be forged. Quantities can't reveal all. Color on the other hand has a handy "quality" factor to it, often revealing things we can't ordinarily recognize. When high quality tools provide us with obtained goals, that's when we will realize how magical color truly is, always has been, and shall always be.
The future emerging economies and future financial vessels of people around the globe are going to be dependent on the secured construction of intelligent applications with a rock solid color foundation, not just math alone. I have no doubt about that. I can envision that with my eyes closed. To make an informed choice, it should be charted or graphed somehow prior to a final executive decision to trade. Going back to abysmal black and white with double decimal points placed next to cartoons within extinction doomed newspapers is not a viable option any more.
OBSERVATIONS AND UTILITY:
One thing you will notice is the code is very dense. Looks almost hideous right? Well, the variable naming is lengthy, but it's purpose is to be self explanatory, even for those who don't know how to program, YET. I'm simply not a notation enthusiast. My main intention was to provide clearly identifiable variables from their origin of assignment to their intended destination of use, clearly visible for anyone visiting. The empowerment of well versed words that are easier to understand, is a close rival to the prominent influence color has.
Secondly, I'm displaying hline() and label.new() as prime candidates to exemplify by demonstration how the "Power of Color" can be embraced with the "Power of Pine". Color in Pine has been extensively upgraded to serve novel purposes to accomplish next generation indicators that do and WILL come to exist. New functions included with PSv5 are color.rgb(), color.from_gradient(), color.r(), color.g(), color.b(), and color.t() to accompany color.new() in our mutual TV adventures. Keep in mind, the extreme agility of color also extends to line.new(), the "entirely new" linefill.new(), table.new(), bgcolor() and every other function that may utilize color.
There's a wide range of adjustability in Settings to make selections to see how they perform on different backgrounds, with their size and form. As you curiously toy with those, you're going to notice how some jump out like laser beams while others don't. Things that aren't visually appealing, still have very viable purposes, even if they don't stand out in the crowd. Often, that's preferable. The important thing is that when pertinent information relative to indication is crucial, you can program it with distinction from an assortment of a potential 1.67 million colors that can be created in Pine. "These" are my chosen favorite few, and I hope you adopt them.
PURPOSES:
For those of you who are new to Pine Script, this also may help you understand color hex/rgb and how it is utilized in Pine in a most effective manner. The most skilled of programmers can garner perks as well. There is countless examples of code diversity present here that are applicable in other scripts with adequate mutation. Any member has the freedom use any of this code in this script any way they see fit. It's specifically intended for all. There is absolutely no need for accreditation for any of this code reuse ever, in the present case. Don't worry about, I'm not.
The color_tostring() will be most valuable in troubleshooting color when using color.rgb() and becoming adept with it. I'm not going to be able to use color.rgb() without it. Chameleon indicators of the polychromatic variety are most likely going to be fine tuned with color_tostring() divulging it's results to label.new() or even table.new() maybe. One the best virtues of this script in chart, is when you hover over the generated labels, there's a hidden gift for those who truly wish to learn the intricate mechanics of diverse color in Pine. Settings has informative tooltips too.
AFTERTHOUGHTS:
Colors are most vibrant on the "Black Chart" which is the default, but it doesn't currently exist as a chart theme. With the extreme luminous intensity of LCDs in millicandela( mcd ), you may notice "Light" charts may saturate the colors making charts challenging to analyze. Because of this, I personally use "Dark Charts" and design my indicators specifically for these. I hope this provides inspiration for the future developers who are contemplating the creation of next generation indicators and how color may enhance their usefulness.
When available time provides itself, I will consider your inquiries, thoughts, and concepts presented below in the comments section, should you have any questions or comments regarding this indicator. When my indicators achieve more prevalent use by TV members , I may implement more ideas when they present themselves as worthy additions. Have a profitable future everyone!
RKs Notepad++ Pine Script V5█ OVERVIEW
After reading all the new names and renames that Pine Script V5 brought to us, I knew that my old Notepad++ User Defined Language (UDL) would need a big update, so I decided to do a complete remake using the same Dark color scheme theme of the Pine Editor.
Then, I create a Notepad++ Theme and the Auto-Completion file with the Parameter hints for every built-in function to make everything look nicer
█ IMPORTANT
This is not an indicator!!
These are 3 XML files to copy and paste inside the Notepad++ folder.
You can use any Notepad Software to create the XML files.
The main Notepad++ folder is normally on %AppData%\Notepad++\
To avoid mistakes, always make a Backup of your files before anything.
█ INSTALLATION
Just follow these steps:
1. open a New Document File;
2. Copy everything between ↓↓↓ and ↑↑↑ symbols to this new document;
3. Remove the "//" of every single line;
4. Save each document with the correct name in the right folder;
5. Restart the Notepad++
█ NOTES:
If you have some problem installing, ask me, and I will try to help you.
But, in any case, here is the link to these files on my GitHub:
Indicator PanelHello All,
This script shows Indicator panel in a Table. Table.new() is a new feature and released today! Thanks a lot to Pine Team to add this new great feature! This new feature is a game changer!
The script shows indicator values for each symbol and changes background color of each cell by using current and last values of the indicators for each symbol. if current value is greater than last value then backgroung color is green, if lower than last value then red, if they are equals then gray.
You can choose the indicators to display. Number of columns in the table is dynamic and is changed by number of the indicators.
You can choose 5 different Symbols, 6 Indicators and 2 Simple or Exponential Moving averages, you can set type of moving averages and the lengths. You can also set the lengths for each Indicators.
Indicators:
- RSI
- MACD ( MACD and Signal and Histogram )
- DMI ( +DI and -DI + and ADX )
- CCI
- MFI
- Momentum
- MA with Length 50 (length can be set)
- MA with Length 200 (length can be set)
In this example RSI, MACD and MA 200 were chosen, you can see how table size changes dynamically:
Enjoy!
ChangeTrend [kingthies_]% X Change Over Y Amount of Time
AKA "ChangeTrend"
Published by user Eric Thies on 9/3/2020
Description
Relatively simple script that is measuring the performance of the input over the previous y # bars.
The EMA appears to make troughs and peaks easy to see coming / look at as they happen.
Interpretation:
Orange Histogram Represents the immediate % Change
Yellow Histogram represents the overall trend of such as an SMA of the same Y # of bars.
Cheers,
Barssince Context TestThis is just published for visibility as a public service until the Pine devs are able to fix or document this behavior. The barssince() function returns different values when inside a conditional context. As long as it can be documented (and relied upon), this could be a pretty cool feature, but right now this is now how I read the help documentation to describe the function's intended behavior.
Anyway, in the script you'll see that test and test2 agree on red bars, but on green bars test gets a much lower value, which was pretty shocking to me until I traced down this particular cause within my larger script.
Market EKGShort Summary
This indicator takes the differences in the previous 4 period OHLC inputs, and compares them to the previously closed candle input. The difference is then placed into an oscillator that when all four inputs are scrolled back on, shows an EKG appearing oscillator / volatility measure for traders to use on indexes, tickers and markets that do not allow typical volume based indicators.
Full Summary
Named for its similar appearance to an EKG medical chart, this script takes the difference in relative averages of previous periods in a trend , and compares it to the most recent period input. This can be used as a price based volatility measure, useful in markets that may be limited by no valume measures or other indexes where volatility is useful to meeasure but will not allow volume initializations.
Steps taken
Taking Previous Period OHLC
Taking Previous 3 Periods OHLC Avgs
Difference Between #1 & #2 (Comparing most recent confirmation to relative trend
Plot Results
This RSI Script is intended for public use and can be shared / implemented as needed
Questions? I do not monitor my TradingView inbox. See email address in signature at the bottom of this page for contact information.
Use this script and its calculations as needed! No permission required.
Cheers,
RSI Divergence (Pine v4)Summary
Script highlights the divergences in RSI worth taking notice of. By comparing current envionment to relative sample we can see more than
the standard divergences that many catch through analysis. This framework aims to remove the bias or noise many see when looking for any supporting
evidence to their given emotion on a market.
Step-by-Step Walkthrough
Calculates RSI
Sets Divergence Framework
-------> a. Defining variable values, mandatory in Pine 4)
-------> b. Identify Divergences --> "If bar with lowest / highest is current bar, use it's value"
Compare high of current bar being examined with previous bar's high --> "If curr bar high is higher than the max bar high in the lookback window range"
Finds pivot point with at least 2 right candles with lower value
Finds pivot point with at least 2 right candles with lower value
Plot
Set Alerts
This RSI Script is intended for public use and can be shared / implemented as needed
Questions? I do not monitor my TradingView inbox. See email address in signature at the bottom of this page for contact information.
4K Notepad++ UDL Add-on for Pine Script v4.0FIRST OF ALL, THIS NOT AN INDICATOR! This is in XML format as a "utilitarian developer tool add-on" for Notepad++ editor for viewing Pine Script on 4K screens, but 4K isn't REQUIRED to use this.
For all Notepad++ enthusiasts out there utilizing Pine Script, I present a UDL(User Defined Language)... for Notepad++... for Pine Script v4.0... on 4K LCDs.
This is only for a dark background in Notepad++ editor, FYI. I would also like to mention, I used a 42" 4K LCD at this time of initial publication.
NOTICE: Please be sure to strip the "//" from this code on every line where the XML is commented with Pine Script comment operators(//) before saving to drive as an XML(*.xml) file. This may be done easily within the Pine Editor using ' CTRL + / ' after a click/drag selection of the bulk XML code. Pine Script commenting will then be stripped out of the XML following after the beginning/closing tags and .
The entire section below entitled "Notepad++ UDL INSTALLATION INSTRUCTIONS" is not required for importation into Notepad++. These are just HOW TOs concerning export/configuration in Notepad++ in the XML comments , and will be ignored if it's included during the import procedure, no worries.
I will update this as PSv4.0 evolves and time provides itself to me. Any anomalies discovered, please respectfully contact me privately via TV chat to discuss any ideas/concerns.
With all that aforementioned said, I believe this will be very useful to Pine Script developers who use Notepad++ editor in tandem with Pine Editor, further unleashing the "Power of Pine" on this planet.
NOTICE: Copy pasting bandits who may be having nefarious thoughts, DO NOT attempt this, because this may violate Tradingview's terms, conditions and/or house rules. "WE" are always watching the TV community vigilantly for mischievous behaviors and actions that exploit well intended authors for the purpose of unscrupulously increasing brownie points in reputation scores. Hiding behind a "protected" wall may not protect you from investigation and account penalization by TV staff. Be respectful, and don't just throw a meaningless feature in there branding it as "your" gizmo. Fair enough? Alrighty then... I firmly believe in "innovating" future state-of-the-art indicators, and please contact me if you wish to do so.
The comments section below is solely just for commenting and other remarks, ideas, compliments, etc... regarding only this indicator, not others. When available time provides itself, I will consider your inquiries, thoughts, and concepts presented below in the comments section if you do have any questions or comments regarding this indicator. When my indicators achieve more prevalent use by TV members, I may implement more ideas when they present themselves as worthy additions. As always, "Like" it if you simply just like it with a proper thumbs up, and also return to my scripts list occasionally for additional postings. Have a profitable future everyone!
How to avoid repainting when using security() - PineCoders FAQNOTE
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.
This indicator shows how to avoid repainting when using the security() function to retrieve information from higher timeframes.
What do we mean by repainting?
Repainting is used to describe three different things, in what we’ve seen in TV members comments on indicators:
1. An indicator showing results that change during the realtime bar, whether the script is using the security() function or not, e.g., a Buy signal that goes on and then off, or a plot that changes values.
2. An indicator that uses future data not yet available on historical bars.
3. An indicator that uses a negative offset= parameter when plotting in order to plot information on past bars.
The repainting types we will be discussing here are the first two types, as the third one is intentional—sometimes even intentionally misleading when unscrupulous script writers want their strategy to look better than it is.
Let’s be clear about one thing: repainting is not caused by a bug ; it is caused by the different context between historical bars and the realtime bar, and script coders or users not taking the necessary precautions to prevent it.
Why should repainting be avoided?
Repainting matters because it affects the behavior of Pine scripts in the realtime bar, where the action happens and counts, because that is when traders (or our systems) take decisions where odds must be in our favor.
Repainting also matters because if you test a strategy on historical bars using only OHLC values, and then run that same code on the realtime bar with more than OHLC information, scripts not properly written or misconfigured alerts will alter the strategy’s behavior. At that point, you will not be running the same strategy you tested, and this invalidates your test results , which were run while not having the additional price information that is available in the realtime bar.
The realtime bar on your charts is only one bar, but it is a very important bar. Coding proper strategies and indicators on TV requires that you understand the variations in script behavior and how information available to the script varies between when the script is running on historical and realtime bars.
How does repainting occur?
Repainting happens because of something all traders instinctively crave: more information. Contrary to trader lure, more information is not always better. In the realtime bar, all TV indicators (a.k.a. studies ) execute every time price changes (i.e. every tick ). TV strategies will also behave the same way if they use the calc_on_every_tick = true parameter in their strategy() declaration statement (the parameter’s default value is false ). Pine coders must decide if they want their code to use the realtime price information as it comes in, or wait for the realtime bar to close before using the same OHLC values for that bar that would be used on historical bars.
Strategy modelers often assume that using realtime price information as it comes in the realtime bar will always improve their results. This is incorrect. More information does not necessarily improve performance because it almost always entails more noise. The extra information may or may not improve results; one cannot know until the code is run in realtime for enough time to provide data that can be analyzed and from which somewhat reliable conclusions can be derived. In any case, as was stated before, it is critical to understand that if your strategy is taking decisions on realtime tick data, you are NOT running the same strategy you tested on historical bars with OHLC values only.
How do we avoid repainting?
It comes down to using reliable information and properly configuring alerts, if you use them. Here are the main considerations:
1. If your code is using security() calls, use the syntax we propose to obtain reliable data from higher timeframes.
2. If your script is a strategy, do not use the calc_on_every_tick = true parameter unless your strategy uses previous bar information to calculate.
3. If your script is a study and is using current timeframe information that is compared to values obtained from a higher timeframe, even if you can rely on reliable higher timeframe information because you are correctly using the security() function, you still need to ensure the realtime bar’s information you use (a cross of current close over a higher timeframe MA, for example) is consistent with your backtest methodology, i.e. that your script calculates on the close of the realtime bar. If your system is using alerts, the simplest solution is to configure alerts to trigger Once Per Bar Close . If you are not using alerts, the best solution is to use information from the preceding bar. When using previous bar information, alerts can be configured to trigger Once Per Bar safely.
What does this indicator do?
It shows results for 9 different ways of using the security() function and illustrates the simplest and most effective way to avoid repainting, i.e. using security() as in the example above. To show the indicator’s lines the most clearly, price on the chart is shown with a black line rather than candlesticks. This indicator also shows how misusing security() produces repainting. All combinations of using a 0 or 1 offset to reference the series used in the security() , as well as all combinations of values for the gaps= and lookahead= parameters are shown.
The close in the call labeled “BEST” means that once security has reached the upper timeframe (1 day in our case), it will fetch the previous day’s value.
The gaps= parameter is not specified as it is off by default and that is what we need. This ensures that the value returned by security() will not contain na values on any of our chart’s bars.
The lookahead security() to use the last available value for the higher timeframe bar we are using (the previous day, in our case). This ensures that security() will return the value at the end of the higher timeframe, even if it has not occurred yet. In our case, this has no negative impact since we are requesting the previous day’s value, with has already closed.
The indicator’s Settings/Inputs allow you to set:
- The higher timeframe security() calls will use
- The source security() calls will use
- If you want identifying labels printed on the lines that have no gaps (the lines containing gaps are plotted using very thick lines that appear as horizontal blocks of one bar in length)
For the lines to be plotted, you need to be on a smaller timeframe than the one used for the security() calls.
Comments in the code explain what’s going on.
Look first. Then leap.
Dragon-Bot - Default ScriptDragon-Script is a framework to make it as easy as possible to test your own strategies and set alerts for external execution bots. This is the alerts version of the script.
The script has many features build in, like:
1) A ping/pong mechanism between longs and shorts
2) A stop-loss
3) Trailing Stops with several ways to calculate them.
4) 2 different ways to flip from long to short.
The script is divided into several parts.
The first part of the script is used to set all the variables. You should normally never change the first part except for the comments at the top.
The second part of the script is the part where you initialise all your indicators. Several indicators can be found on Tradingview and on other sites. Please keep in mind that all the variable names used in the indicator should be unique. (all the … = … parts)
The third part of the script, is the most important part of the script. Here you can create the entry and exit points.
Let’s look at the OPENLONG function to explain this part: The first variables are all the possible entries; These are longentry1 till longentry5. You can add many more if you like.
The variables are all initialised as being false. This way the script can set a value to true if an entry happens.
The if function is the actual logic: You could say “if this is true” then (the line below the if function) longentry1 := (becomes) true.
In this case we have said: “if this is true” then (the line below the if function) longentry1 := (becomes) true when the current close is larger than the close that is 1 back.
The last part is the makelong_funct. This part says that if any of the entries are true, the whole function is true.
The last part of the script is the actual execution. Here the alerts are plotted and the back test strategies are opened and closed.
We hope you guys like it and all feedback is welcome!
Security() Correction - Realtime vs. Historical BarsProblem
Pine's implementation of the security() function behaves differently in realtime vs. historical bars. Specifically, for historical bars, calling security() for a time frame (TF) larger/slower than the current chart's TF will return information about the last completed bar of the higher TF. However, for realtime bars (i.e. if you allow the chart to continue to plot in realtime), security() returns information about the presently in-progress bar of the higher TF. Clearly, this leads to discontinuity that is arbitrarily dependent upon when the user last loaded or refreshed the chart.
Solution
Fortunately, after understanding the problem, solving it is trivial: use security() normally for historical bars, but switch to explicitly requesting prior candle bars once the indicator is operating on realtime bars. I leave the source open here for any to use as they see fit. For testing, I include an input to allow switching back and forth between standard and corrected behavior.
Figure 1 displays the standard behavior we see in security() calls, and Figure 2 displays the behavior after my correction:
Figure 1: Typical security() behavior in Pine
Figure 2: Corrected security() behavior, forcing historical and realtime bars to refer to the same higher TF bar offset.
I publish this mostly as a reminder to myself, so I will not forget and then have to figure it out again next time it comes up in my scripting.
V21: Initial release.
TRADING VIEW INDICATOR - PINE TUTORIAL 5After a long gap, I have written the 5th tutorial for the pine script. You can find the others below, if you read through all of these you should be good to do your own writing.
This script mimics the Trading View Indicator . For example this one below.
www.tradingview.com
It shows the net result of the 28 indicator, either as buy or sell. I have worked hard to make sure it matches the trading view results but I am not in hundred percent agreement with tradingView on SMA, EMA and Ichimoku indicator.
There are many commented plots because I needed to check separately if each indicator is working correctly.
Someone else wrote this code but they did not make it public. It took me about 3 weeks to write this and to be honest it could be cleaner and better commented.
If you find any mistake please let me know. I hope it will be useful in your learning.
Pine Script Tutorial #2In this second tutorial we build upon the previous tutorial. We add color shading for each different day and highlight Wednesday.
The idea here is to manually count if on Wednesdays close is bigger then open.
Hope it helps.
Feel free to comment.
MartinMystere
"Smoothed" CandlesHi!
This new functions plotbar and plotcandle are amazing! Just look at this smoothed candles here)))
Higher Resolution Bars on Intraday ChartHi everybody!
With new plotbar and plotcandle functions you may plot somewhat "stretched" daily bars over intraday chart. Enjoy!
