Library "MarketStructure" This library contains functions for identifying Lows and Highs in a rule-based way, and deriving useful information from them.
f_simpleLowHigh() This function finds Local Lows and Highs, but NOT in order. A Local High is any candle that has its Low taken out on close by a subsequent candle (and vice-versa for Local Lows). The Local High does NOT have to be the candle with the highest High out of recent candles. It does NOT have to be a Williams High. It is not necessarily a swing high or a reversal or anything else. It doesn't have to be "the" high, so don't be confused. By the rules, Local Lows and Highs must alternate. In this function they do not, so I'm calling them Simple Lows and Highs. Simple Highs and Lows, by the above definition, can be useful for entries and stops. Because I intend to use them for stops, I want them all, not just the ones that alternate in strict order. @param - there are no parameters. The function uses the chart OHLC. @Returns boolean values for whether this bar confirms a Simple Low/High, and ints for the bar_index of that Low/High.
f_localLowHigh() This function finds Local Lows and Highs, in order. A Local High is any candle that has its Low taken out on close by a subsequent candle (and vice-versa for Local Lows). The Local High does NOT have to be the candle with the highest High out of recent candles. It does NOT have to be a Williams High. It is not necessarily a swing high or a reversal or anything else. By the rules, Local Lows and Highs must alternate, and in this function they do. @param - there are no parameters. The function uses the chart OHLC. @Returns boolean values for whether this bar confirms a Local Low/High, and ints for the bar_index of that Low/High.
f_enhancedSimpleLowHigh() This function finds Local Lows and Highs, but NOT in order. A Local High is any candle that has its Low taken out on close by a subsequent candle (and vice-versa for Local Lows). The Local High does NOT have to be the candle with the highest High out of recent candles. It does NOT have to be a Williams High. It is not necessarily a swing high or a reversal or anything else. By the rules, Local Lows and Highs must alternate. In this function they do not, so I'm calling them Simple Lows and Highs. Simple Highs and Lows, by the above definition, can be useful for entries and stops. Because I intend to use them for trailing stops, I want them all, not just the ones that alternate in strict order. The difference between this function and f_simpleLowHigh() is that it also tracks the lowest/highest recent level. This level can be useful for trailing stops. In effect, these are like more "normal" highs and lows that you would pick by eye, but confirmed faster in many cases than by waiting for the low/high of that particular candle to be taken out on close, because they are instead confirmed by ANY subsequent candle having its low/high exceeded. Hence, I call these Enhanced Simple Lows/Highs. The levels are taken from the extreme highs/lows, but the bar indexes are given for the candles that were actually used to confirm the Low/High. This is by design, because it might be misleading to label the extreme, since we didn't use that candle to confirm the Low/High.. @param - there are no parameters. The function uses the chart OHLC. @Returns - boolean values for whether this bar confirms an Enhanced Simple Low/High ints for the bar_index of that Low/High floats for the values of the recent high/low levels floats for the trailing high/low levels (for debug/post-processing) bools for market structure bias
f_trueLowHigh() This function finds True Lows and Highs. A True High is the candle with the highest recent high, which then has its low taken out on close by a subsequent candle (and vice-versa for True Lows). The difference between this and an Enhanced High is that confirmation requires not just any Simple High, but confirmation of the very candle that has the highest high. Because of this, confirmation is often later, and multiple Simple Highs and Lows can develop within ranges formed by a single big candle without any of them being confirmed. This is by design. A True High looks like the intuitive "real high" when you look at the chart. True Lows and Highs must alternate. @param - there are no parameters. The function uses the chart OHLC. @Returns - boolean values for whether this bar confirms an Enhanced Simple Low/High ints for the bar_index of that Low/High floats for the values of the recent high/low levels floats for the trailing high/low levels (for debug/post-processing) bools for market structure bias
Added the following parameters: _high (float): - the bar high price. Defaults to the chart high. _low (float): - the bar low price. Defaults to the chart low. _close (float): - the bar close price. Defaults to the chart close.
This allows you to supply custom OHLC values, for example, from a security() call to force a standard ticker.
發布通知
⋅
v3 Fixes the case where a Low comes the very next candle after a High or vice-versa.
發布通知
⋅
v4 Fixed a bug where in some cases pivots could be missed of the candle highs or lows kept increasing.
發布通知
⋅
V5 Fixed an issue where the timeblock method of plotting a label in the future does not work if you plot it in the past. As part of this fix, added label helper function and cleaned up superfluous variables for each exported function. I spent ages looking for the problem in the structure logic, but it wasn't there! Anyway, I left some of the debug that I used to examine the functions in the script, just commented out, for the interest of new Pine coders.
發布通知
⋅
v6
Updated: f_trueLowHigh(_high, _low, _close)
Fixed an issue where the wrong candle could be identified as the True Low if the lowest candle low occurred while the previous True High was waiting to be confirmed by a candle close, or vice-versa for True Highs. This is basically THE main edge case with trying to implement rule-based alternating Highs and Lows: you can only confirm a High after a confirmed Low, but you have to start looking for it before that in order not to miss any. I solved it here (touch wood) using arrays. When I wrote my first market structure indicator, arrays were not available in Pine. You could perhaps do it with simple lines instead, but the solution occurred to me with arrays so here we are. Hopefully, this logic should be robust. Changes are tagged:
// 🟩 V6
發布通知
⋅
v7 Updated all functions to remove a typo of
close
instead of
_close
This typo meant that the library worked fine on the current chart symbol, but could NOT be used for another symbol by passing in its high, low, and close. Now it can. 🤞
How are you making use of these definitions? Is it to just define the structure or is there a component of this that provides a signal as well? It seems like you would be able to use them to get a general sense of direction. But maybe there's more to it than that?
SimpleCryptoLife
⋅
@kurtsmock, That, sir, is up to the consuming script 😉 I just wanted to provide the rule-defined highs and lows as a library, because I hadn't seen that done before. I have an old script, True Market Structure, that shows some options of how you can make use of True Lows and Highs for bias or signals. And as you know, my TrailingStops library uses the output of f_enhancedSimpleLowHigh() to construct trailing stops. My mentor says "Market structure first, always!", so that's why I spent so much time on it.
kurtsmock
⋅
@SimpleCryptoLife, Its the same for me. I am coming to essentially the same conclusions. However, I'm not looking at things in terms of "market structure" (I use a different system for what I call market structure), but rather I'm looking at information being provided candle by candle. My saying is "The bars to the left are good for context, but you can only make or lose money on the current bar"
One thing I might offer as food for thought regarding True Highs and True Lows and market structure: The market is either in a trend or in a trading range. When thinking purely in terms of bull/bear as it is in the `trueBackGroundColour` condition, you get false positive bull/bear signals. What I'm seeing is that false positives that trigger bull/bear bgcolor transitions are generally trading ranges. Additionally, a chart rarely goes from one trend straight into another. The pattern is most typically {Trend -> Trading Range -> Trend} I might suggest then that reframing the code in this way.
if trueBearish{1} and trueBullish
neutral
else if trueBullish{1} and trueBearish
neutral
else if neutral and (trueBullish or trueBearish)
trueBullish ? trueBullish : trueBearish
The idea behind this obviously being create conditions to account for the truth of the matter that markets typically oscillate between {trend -> trading range} and not {trend -> opposite trend}. I much appreciate you sharing this library. It's definitely giving me some things to think about as I am developing a new system.
SimpleCryptoLife
⋅
@kurtsmock, I agree, there is definitely a "neutral" or trading range and not just bullish and bearish. This library doesn't really intend to interpret market structure, just pass it on; perhaps it was a step too far to include the background at all. In my old True Market Structure script I did try to interpret ranges. In what I'm working on now, I define market structure in terms of a pivot where strong momentum was reversed. I find these are more useful in terms of excluding ranges (where perhaps one should really be identifying them explicitly) and identifying trend changes. Although, everything can be faked out. I can see you've written some complicated stuff that many people find useful. Thanks for taking the time to share your thoughts.
SimpleCryptoLife
⋅
@kurtsmock, Oh and I came to exactly the same conclusion that neutral should come between bullish and bearish. But these days I define neutral as a tentative continuation of the previous bias, with different criteria for confirming a true change in direction - essentially, a grey zone where we deal with false breakouts, if that makes sense.
kurtsmock
⋅
@SimpleCryptoLife, Awesome stuff man. We'll stay in touch. I wish you all the best in your trading!
kurtsmock
⋅
@kurtsmock, Oh and I submitted a ticket on that offset issue with the plotchar(), plotshape(), and plot() functions, where if you have a dynamic series the offset doesn't work, even though it says "series offset" in the docs... seems they don't intend to fix it but rather are going to deprecate dynamic offsets for those functions. That was the last I heard anyway. For series offsets, looks like labels will be our only option. =/
SimpleCryptoLife
⋅
@kurtsmock, Oh man. That's an annoying restriction!
kurtsmock
⋅
@SimpleCryptoLife, For sure. I thought I was the problem when I was writing my alternating pivots script. I musta spent 6 hours trying to figure out a way to make it work.. all for naught. :sobs: