Business Cycle Indicators (Normalized)This script aggregates and normalizes several key economic indicators to provide a comprehensive view of the business cycle and overall market conditions. By combining these indicators into a single, normalized average line, the script helps identify overarching trends and shifts in the economy, aiding in more informed trading and investment decisions.
Included Indicators:
Inverted National Financial Conditions Index (NFCI):
Symbol: FRED:NFCI
Measures financial stress in the markets. An inverted NFCI aligns higher values with positive financial conditions.
Inverted Net Percentage of Banks Tightening Lending Standards (DRTSCIS):
Symbol: FRED:DRTSCIS
Reflects changes in bank lending practices. Inverting this indicator means higher values indicate easing lending standards, which is generally positive for economic growth.
HYG Close Price (iShares High Yield Corporate Bond ETF):
Symbol: AMEX:HYG
Represents the performance of high-yield corporate bonds, providing insight into credit market conditions.
Inverted High-Yield Credit Spread (BAMLH0A0HYM2):
Symbol: FRED:BAMLH0A0HYM2
Measures the spread between high-yield bonds and risk-free securities. A narrower (inverted) spread indicates better market conditions.
Manufacturing/Non-Manufacturing New Orders Ratio:
Symbols: ECONOMICS:USMNO (Manufacturing), ECONOMICS:USNMNO (Non-Manufacturing)
Compares manufacturing to non-manufacturing new orders to gauge shifts in economic activity.
US PMI (Purchasing Managers' Index):
Symbol: ECONOMICS:USBCOI
An indicator of the economic health of the manufacturing sector.
10-Year Inflation Breakeven (T10YIE):
Symbol: FRED:T10YIE
Represents market expectations of inflation over the next ten years.
Inverted 10-Year Real Yield (DFII10):
Symbol: FRED:DFII10
Reflects the real yield on 10-year Treasury Inflation-Protected Securities (TIPS). Inverted to align higher values with positive economic sentiment.
Copper/Gold Ratio:
Symbols: CAPITALCOM:COPPER (Copper), TVC:GOLD (Gold)
Compares the prices of copper and gold, often used as a barometer for global economic activity.
Features:
Normalized Indicators: Each indicator is normalized to a 0-100 scale to facilitate direct comparison, regardless of their original units or scales.
Normalized Average Line: Calculates and plots the average of all available normalized indicators, providing a single line that represents the combined economic signals.
Customizable Display:
Show Individual Indicators: Option to display individual normalized indicators for detailed analysis.
Show Normalized Average Line: Option to display the normalized average line for a consolidated view.
Dynamic Labeling: Displays the latest value of the normalized average directly on the chart for quick reference.
How to Use:
Adding the Script:
Apply the script to a chart in TradingView using a timeframe that aligns with the frequency of the economic data (daily or weekly recommended).
Customization:
Show Normalized Average Line: Enabled by default to display the combined indicator.
Show Individual Indicators: Enable this option in the script settings to display all individual normalized indicators.
Interpretation:
Normalized Scale (0-100): Higher values generally indicate stronger economic conditions, while lower values may suggest weakening conditions.
Trend Analysis: Use the normalized average line to identify trends and potential turning points in the business cycle.
Notes:
Data Availability: Ensure you have access to all the data sources used in the script. Some data feeds may require specific TradingView subscriptions.
Indicator Limitations: Economic indicators are subject to revisions and may not reflect real-time market conditions.
No Investment Advice: This script is a tool for analysis and should not be considered as financial advice. Always conduct your own research before making investment decisions.
Cari skrip untuk "THE SCRIPT"
[SGM GARCH Volatility]I'm excited to share with you a Pine Script™ that I developed to analyze GARCH (Generalized Autoregressive Conditional Heteroskedasticity) volatility. This script allows you to calculate and plot GARCH volatility on TradingView. Let's see together how it works!
Introduction
Volatility is a key concept in finance that measures the variation in prices of a financial asset. The GARCH model is a statistical method that predicts future volatility based on past volatilities and prediction residuals (errors).
Indicator settings
We define several parameters for our indicator:
length = input.int(20, title="Length")
p = input.int(1, title="Lag order (p)")
q = input.int(1, title="Degree of moving average (q)")
cluster_value = input(0.2,title="cluster value")
length: The period used for the calculations, default 20.
p: The order of the delay for the GARCH model.
q: The degree of the moving average for the GARCH model.
cluster_value: A threshold value used to color the graph.
Calculation of logarithmic returns
We calculate logarithmic returns to capture price changes:
logReturns = math.log(close) - math.log(close )
Initializing arrays
We initialize arrays to store residuals and volatilities:
var float residuals = array.new_float(length, 0)
var float volatilities = array.new_float(length, 0)
We add the new logarithmic returns to the tables and keep their size constant:
array.unshift(residuals, logReturns)
if (array.size(residuals) > length)
array.pop(residuals)
We then calculate the mean and variance of the residuals:
meanResidual = array.avg(residuals)
varianceResidual = array.stdev(residuals, meanResidual)
volatility = math.sqrt(varianceResidual)
We update the volatility table with the new value:
array.unshift(volatilities, volatility)
if (array.size(volatilities) > length)
array.pop(volatilities)
GARCH volatility is calculated from accumulated data:
var float garchVolatility = na
if (array.size(volatilities) >= length and array.size(residuals) >= length)
alpha = 0.1 // Alpha coefficient
beta = 0.85 // Beta coefficient
omega = 0.01 // Omega constant
sumVolatility = 0.0
for i = 0 to p-1
sumVolatility := sumVolatility + beta * math.pow(array.get(volatilities, i), 2)
sumResiduals = 0.0
for j = 0 to q-1
sumResiduals := sumResiduals + alpha * math.pow(array.get(residuals, j), 2)
garchVolatility := math.sqrt(omega + sumVolatility + sumResiduals)
Plot GARCH volatility
We finally plot the GARCH volatility on the chart and add horizontal lines for easier visual analysis:
plt = plot(garchVolatility, title="GARCH Volatility", color=color.rgb(33, 149, 243, 100))
h1 = hline(0.1)
h2 = plot(cluster_value)
h3 = hline(0.3)
colorGarch = garchVolatility > cluster_value ? color.red: color.green
fill(plt, h2, color = colorGarch)
colorGarch: Determines the fill color based on the comparison between garchVolatility and cluster_value.
Using the script in your trading
Incorporating this Pine Script™ into your trading strategy can provide you with a better understanding of market volatility and help you make more informed decisions. Here are some ways to use this script:
Identification of periods of high volatility:
When the GARCH volatility is greater than the cluster value (cluster_value), it indicates a period of high volatility. Traders can use this information to avoid taking large positions or to adjust their risk management strategies.
Anticipation of price movements:
An increase in volatility can often precede significant price movements. By monitoring GARCH volatility spikes, traders can prepare for potential market reversals or accelerations.
Optimization of entry and exit points:
By using GARCH volatility, traders can better identify favorable times to enter or exit a position. For example, entering a position when volatility begins to decrease after a peak can be an effective strategy.
Adjustment of stops and objectives:
Since volatility is an indicator of the magnitude of price fluctuations, traders can adjust their stop-loss and take-profit orders accordingly. Periods of high volatility may require wider stops to avoid being exited from a position prematurely.
That's it for the detailed explanation of this Pine Script™ script. Don’t hesitate to use it, adapt it to your needs and share your feedback! Happy analysis and trading everyone!
dashboard MTF,EMA User Guide: Dashboard MTF EMA
Script Installation:
Copy the script code.
Go to the script window (Pine Editor) on TradingView.
Paste the code into the script window.
Save the script.
Adding the Script to the Chart:
Return to your chart on TradingView.
Look for the script in the list of available scripts.
Add the script to the chart.
Interpreting the Table:
On the right side of the chart, you will see a table labeled "EMA" with arrows.
The rows correspond to different timeframes: 5 minutes (5M), 15 minutes (15M), 1 hour (1H), 4 hours (4H), and 1 day (1D).
Understanding the Arrows:
Each row of the table has two columns: "EMA" and an arrow.
"EMA" indicates the trend of the Exponential Moving Average (EMA) for the specified period.
The arrow indicates the direction of the trend: ▲ for bullish, ▼ for bearish.
Table Colors:
The colors of the table reflect the current trend based on the comparison between fast and slow EMAs.
Blue (▲) indicates a bullish trend.
Red (▼) indicates a bearish trend.
Table Theme:
The table has a dark (Dark) or light (Light) theme according to your preference.
The background, frame, and colors are adjusted based on the selected theme.
Usage:
Use the table as a quick indicator of trends on different timeframes.
The arrows help you quickly identify trends without navigating between different time units.
Designed to simplify analysis and avoid cluttering the chart with multiple indicators.
Сoncentrated Market Maker Strategy by oxowlConcentrated Market Maker Strategy by oxowl. This script plots an upper and lower bound for liquidity provision, and checks for rebalancing conditions. It also includes alert conditions for when the price crosses the upper or lower bounds.
Here's an overview of the script:
It defines the input parameters: liquidity range percentage, rebalance frequency in minutes, and minimum trade size in assets.
It calculates the upper and lower bounds for liquidity provision based on the liquidity range percentage.
It initializes variables for the last rebalance time and price.
It defines a rebalance condition based on the frequency and current price within the specified range.
If the rebalance condition is met, it updates the last rebalance time and price.
It plots the upper and lower bounds on the chart as lines and adds price labels for both bounds.
It defines alert conditions for when the price crosses the upper or lower bounds.
Finally, it creates alert conditions with appropriate messages for when the price crosses the upper or lower bounds.
Concentrated liquidity is a concept often used in decentralized finance (DeFi) market-making strategies. It allows liquidity providers (LPs) to focus their liquidity within a specific price range, rather than across the entire price curve. Using an indicator with concentrated liquidity can offer several advantages:
Increased capital efficiency: Concentrated liquidity allows LPs to allocate their capital within a narrower price range. This means that the same amount of capital can generate more significant price impact and potentially higher returns compared to providing liquidity across a broader range.
Customized risk exposure: LPs can choose the price range they feel most comfortable with, allowing them to better manage their risk exposure. By selecting a range based on their market outlook, they can optimize their positions to maximize potential returns.
Adaptive strategies: Indicators that support concentrated liquidity can help traders adapt their strategies based on market conditions. For example, they can choose to provide liquidity around a stable price range during low-volatility periods or adjust their range when market conditions change.
To continue integrating this script into your trading strategy, follow these steps:
Import the script into your TradingView account. Navigate to the Pine editor, paste the code, and save it as a new script.
Apply the indicator to a trading pair chart. You can customize the input parameters (liquidity range percentage, rebalance frequency, and minimum trade size) based on your preferences and risk tolerance.
Set alerts for when the price crosses the upper or lower bounds. This will notify you when it's time to take action, such as adding or removing liquidity, or rebalancing your position.
Monitor the performance of your strategy over time. Adjust the input parameters as needed to optimize your returns and manage risk effectively.
(Optional) Integrate the script with a trading bot or automation platform. If you're using an API-based trading solution, you can incorporate the logic and conditions from the script into your bot's algorithm to automate the process of providing concentrated liquidity and rebalancing your positions.
Remember that no strategy is foolproof, and past performance is not indicative of future results. Always exercise caution when trading and carefully consider your risk tolerance.
[@btc_charlie] Trader XO Macro Trend ScannerWhat is this script?
This script has two main functions focusing on EMAs (Exponential Moving Average) and Stochastic RSI.
EMAs
EMAs are typically used to give a view of bullish / bearish momentum. When the shorter EMA (calculated off more recent price action) crosses, or is above, the slower moving EMA (calculated off a longer period of price action), it suggests that the market is in an uptrend. This can be an indication to either go long on said asset, or that it is more preferable to take long setups over short setups. Invalidation on long setups is usually found via price action (e.g. previous lows) or simply waiting for an EMA cross in the opposite direction (i.e. shorter EMA crosses under longer term EMA).
This is not a perfect system for trade entry or exit, but it does give a good indication of market trends. The settings for the EMAs can be changed based on user inputs, and by default the candles are coloured based on the crosses to make it more visual. The default settings are based on “Trader XO’s” settings who is an exceptional swing trader.
RSI
Stochastic RSI is a separate indicator that has been added to this script. RSI measures Relative Strength (RSI = Relative Strength Index). When RSI is <20 it is considered oversold, and when >80 it is overbought. These conditions suggests that momentum is very strong in the direction of the trend.
If there is a divergence between the price (e.g. price is creating higher highs, and stoch RSI is creating lower highs) it suggests the strength of the trend is weakening. Whilst this script does not highlight divergences, what it does highlight is when the shorter term RSI (K) crosses over D (the average of last 3 periods). This can give an indication that the trend is losing strength.
Combination
The EMAs indicate when trend shifts (bullish or bearish).
The RSI indicates when the trend is losing momentum.
The combination of the two can be used to suggest when to prefer a directional bias, and subsequently shift in anticipation of a trend reversal.
Note that no signal is 100% accurate and an interpretation of market conditions and price action will need to be overlayed to
Why is it different to others?
I have not found other scripts that are available in this way visually including alerts when Stoch RSI crosses over/under the extremes; or the mid points.
Whilst these indicators are default, the combination of them and how they are presented is not and makes use of the TradingView colouring functionalities.
What are the features?
Customise the variables (averages) used in the script.
Display as one EMA or two EMAs (the crossing ones).
Alerts on EMA crosses.
Alerts on Stoch RSI crosses - slow/fast, upper, lower areas.
- Currently set on the chart to show alerts when Stoch RSI is above 80, then falls below 80 (and colours it red).
Customisable colours.
What are the best conditions for this?
It is designed for high timeframe charts and analysis in crypto, since crypto tends to trend.
It can however be used for lower timeframes.
Disclaimer/Notes:
I have noticed several videos appearing suggesting that this is a "100% win rate indicator" .
NO indicator has 100% win rate.
An indicator is an *indicator* that is all.
Please use responsibly and let me know if there are any mods or updates you would like to see.
Strategy BackTest Display Statistics - TraderHalaiThis script was born out of my quest to be able to display strategy back test statistics on charts to allow for easier backtesting on devices that do not natively support backtest engine (such as mobile phones, when I am backtesting from away from my computer). There are already a few good ones on TradingView, but most / many are too complicated for my needs.
Found an excellent display backtest engine by 'The Art of Trading'. This script is a snippet of his hard work, with some very minor tweaks and changes. Much respect to the original author.
Full credit to the original author of this script. It can be found here: www.tradingview.com
I decided to modify the script by simplifying it down and make it easier to integrate into existing strategies, using simple copy and paste, by relying on existing tradingview strategy backtester inputs. I have also added 3 additional performance metrics:
- Max Run Up
- Average Win per trade
- Average Loss per trade
As this is a work in progress, I will look to add in more performance metrics in future, as I further develop this script.
Feel free to use this display panel in your scripts and strategies.
Thanks and enjoy :)
logLibrary "log"
Logging library for easily displaying debug, info, warn, error and critical messages.
No real need to explain why you might want to use this library! I'm sure you've all experienced the frustration of trying to understand the data state of your scripts... so, enjoy! More on it's way...
(Don't forget to check the helpers in the script and the useful tips below)
Some Useful Tips
By default the log console persists between bars (for history) and bars and ticks (for realtime).
Sometimes it is useful to clear the log after each candle or tick (assuming we are using the above helpers):
```
log_print(clear = true) // starts afresh on every bar and tick (excludes historical bars but good realtime tick analysis)
log_print(clear = barstate.isnew) // clears the log at the start of each bar (again, excludes historical but good realtime candle analysis)
```
It is also useful to be able to selectively understand the state of data at specific points or times within a script:
```
if log.once()
debug('useful variable', my_var) // this log only gets written once, upon first execution of this statement
if log.only(5)
debug3(a, b, c) // these variables are only logged the first five times this statement is executed
log_print(clear = false) // clear must be false and you should not write other logs on every bar, or the above will be lost
```
Final tip. If you want to view ONLY log entries of a particular level, then negate the constant:
```
log_print(level = -LOG_DEBUG)
```
Detailed Interface
once() Restrict execution to only happen once. Usage: if assert.once()\n happens_once()
Returns: bool, true on first execution within scope, false subsequently
only(repeat) Restrict execution to happen a set number of times. Usage: if assert.only(5)\n happens_five_times()
Parameters:
repeat : int, the number of times to return true
Returns: bool, true for the set number of times within scope, false subsequently
init() Initialises the log array
Returns: string , tuple based array to contain all pending log entries (__LOG)
clear(msgs) Clears the log array
Parameters:
msgs : string , the current collection of unfiltered and unprocessed logs (__LOG)
trace(msgs, msg) Writes a trace message to the log console
Parameters:
msgs : string , the current collection of unfiltered and unprocessed logs (__LOG)
msg : string, the trace message to write to the log
debug(msgs, msg) Writes a debug message to the log console
Parameters:
msgs : string , the current collection of unfiltered and unprocessed logs (__LOG)
msg : string, the debug message to write to the log
info(msgs, msg) Writes an info message to the log console
Parameters:
msgs : string , the current collection of unfiltered and unprocessed logs (__LOG)
msg : string, the info message to write to the log
warn(msgs, msg) Writes a warning message to the log console
Parameters:
msgs : string , the current collection of unfiltered and unprocessed logs (__LOG)
msg : string, the warn message to write to the log
error(msgs, msg) Writes an error message to the log console
Parameters:
msgs : string , the current collection of unfiltered and unprocessed logs (__LOG)
msg : string, the error message to write to the log
fatal(msgs, msg) Writes a critical message to the log console
Parameters:
msgs : string , the current collection of unfiltered and unprocessed logs (__LOG)
msg : string, the fatal message to write to the log
log(msgs, level, msg) Write a log message to the log console with a custom level
Parameters:
msgs : string , the current collection of unfiltered and unprocessed logs (__LOG)
level : ing, the logging level to assign to the message
msg : string, the log message to write to the log
severity(msgs) Checks the unprocessed log messages and returns the highest present level
Parameters:
msgs : string , the current collection of unfiltered and unprocessed logs (__LOG)
Returns: int, the highest level found within the unfiltered logs
print(msgs, level, clear, rows, text_size, position) Prints all log messages to the screen
Parameters:
msgs : string , the current collection of unfiltered and unprocessed logs (__LOG)
level : int, the minimum required log level of each message to be displayed
clear : bool, clear the printed log console after each render (useful with realtime when set to barstate.isconfirmed)
rows : int, the number of rows to display in the log console
text_size : string, the text size of the log console (global size vars)
position : string, the position of the log console (global position vars)
unittest_log(case) Log module unit tests, for inclusion in parent script test suite. Usage: log.unittest_log(__ASSERTS)
Parameters:
case : string , the current test case and array of previous unit tests (__ASSERTS)
unittest(verbose) Run the log module unit tests as a stand alone. Usage: log.unittest()
Parameters:
verbose : bool, optionally disable the full report to only display failures
assertLibrary "assert"
Production ready assertions and auto-reporting for unit testing pine scripts.
This library was born from the need to maintain production level stability and catch regressions / bugs early and fast. I hope this help you trust your pine scripts too. More libraries and tools on their way... please follow for more.
Please see the script for helpers to copy into your own scripts as well as examples at the bottom of the library unit testing itself.
Quick Reference
```
case = assert.init()
new_case(case, 'Asserts for floats and ints')
assert.equal(a, b, case, 'a == b')
assert.not_equal(a, b, case, 'a != b')
assert.nan(a, case, 'a == na')
assert.not_nan(a, case, 'a != na')
assert.is_in(a, b, case, 'a in b ')
assert.is_not_in(a, b, case, 'a not in b ')
assert.array_equal(a, b, case, 'a == b ')
new_case(case, 'Asserts for ints only')
assert.int_in(a, b, case, 'a in b ')
assert.int_not_in(a, b, case, 'a not in b ')
assert.int_array_equal(a, b, case, 'a == b ')
new_case(case, 'Asserts for bools only')
assert.is_true(a, case, 'a == true')
assert.is_false(a, case, 'a == false')
assert.bool_equal(a, b, case, 'a == b')
assert.bool_not_equal(a, b, case, 'a != b')
assert.bool_nan(a, case, 'a == na')
assert.bool_not_nan(a, case, 'a != na')
assert.bool_array_equal(a, b, case, 'a == b ')
new_case(case, 'Asserts for strings only')
assert.str_equal(a, b, case, 'a == b')
assert.str_not_equal(a, b, case, 'a != b')
assert.str_nan(a, case, 'a == na')
assert.str_not_nan(a, case, 'a != na')
assert.str_in(a, b, case, 'a in b ')
assert.str_not_in(a, b, case, 'a not in b ')
assert.str_array_equal(a, b, case, 'a == b ')
assert.report(case)
```
Detailed Interface
once() Restrict execution to only happen once. Usage: if assert.once()\n happens_once()
Returns: bool, true on first execution within scope, false subsequently
init() Initialises the asserts array
Returns: string , tuple based array containing all unit test results and current case details (__ASSERTS)
equal(a, b, case, name) Numeric assert equal. Usage: assert.equal(1, 1, case, 'one == one')
Parameters:
a : float, numeric value "a" to compare equal to "b"
b : float, numeric value "b" to compare equal to "a"
case : string , the current test case and array of previous unit tests (__ASSERTS)
name : string, the current unit test name, if undefined the test index of the current case is used
Returns: bool, true if the assertion passes, false otherwise
not_equal(a, b, case, name) Numeric assert not equal. Usage: assert.not_equal(1, 2, case, 'one != two')
Parameters:
a : float, numeric value "a" to compare not equal "b"
b : float, numeric value "b" to compare not equal "a"
case : string , the current test case and array of previous unit tests (__ASSERTS)
name : string, the current unit test name, if undefined the test index of the current case is used
Returns: bool, true if the assertion passes, false otherwise
nan(a, case, name) Numeric assert is NaN. Usage: assert.nan(float(na), case, 'number is NaN')
Parameters:
a : float, numeric value "a" to check is NaN
case : string , the current test case and array of previous unit tests (__ASSERTS)
name : string, the current unit test name, if undefined the test index of the current case is used
Returns: bool, true if the assertion passes, false otherwise
not_nan(a, case, name) Numeric assert is not NaN. Usage: assert.not_nan(1, case, 'number is not NaN')
Parameters:
a : float, numeric value "a" to check is not NaN
case : string , the current test case and array of previous unit tests (__ASSERTS)
name : string, the current unit test name, if undefined the test index of the current case is used
Returns: bool, true if the assertion passes, false otherwise
is_in(a, b, case, name) Numeric assert value in float array. Usage: assert.is_in(1, array.from(1.0), case, '1 is in ')
Parameters:
a : float, numeric value "a" to check is in array "b"
b : float , array "b" to check contains "a"
case : string , the current test case and array of previous unit tests (__ASSERTS)
name : string, the current unit test name, if undefined the test index of the current case is used
Returns: bool, true if the assertion passes, false otherwise
is_not_in(a, b, case, name) Numeric assert value not in float array. Usage: assert.is_not_in(2, array.from(1.0), case, '2 is not in ')
Parameters:
a : float, numeric value "a" to check is not in array "b"
b : float , array "b" to check does not contain "a"
case : string , the current test case and array of previous unit tests (__ASSERTS)
name : string, the current unit test name, if undefined the test index of the current case is used
Returns: bool, true if the assertion passes, false otherwise
array_equal(a, b, case, name) Float assert arrays are equal. Usage: assert.array_equal(array.from(1.0), array.from(1.0), case, ' == ')
Parameters:
a : float , array "a" to check is identical to array "b"
b : float , array "b" to check is identical to array "a"
case : string , the current test case and array of previous unit tests (__ASSERTS)
name : string, the current unit test name, if undefined the test index of the current case is used
Returns: bool, true if the assertion passes, false otherwise
int_in(a, b, case, name) Integer assert value in integer array. Usage: assert.int_in(1, array.from(1), case, '1 is in ')
Parameters:
a : int, value "a" to check is in array "b"
b : int , array "b" to check contains "a"
case : string , the current test case and array of previous unit tests (__ASSERTS)
name : string, the current unit test name, if undefined the test index of the current case is used
Returns: bool, true if the assertion passes, false otherwise
int_not_in(a, b, case, name) Integer assert value not in integer array. Usage: assert.int_not_in(2, array.from(1), case, '2 is not in ')
Parameters:
a : int, value "a" to check is not in array "b"
b : int , array "b" to check does not contain "a"
case : string , the current test case and array of previous unit tests (__ASSERTS)
name : string, the current unit test name, if undefined the test index of the current case is used
Returns: bool, true if the assertion passes, false otherwise
int_array_equal(a, b, case, name) Integer assert arrays are equal. Usage: assert.int_array_equal(array.from(1), array.from(1), case, ' == ')
Parameters:
a : int , array "a" to check is identical to array "b"
b : int , array "b" to check is identical to array "a"
case : string , the current test case and array of previous unit tests (__ASSERTS)
name : string, the current unit test name, if undefined the test index of the current case is used
Returns: bool, true if the assertion passes, false otherwise
is_true(a, case, name) Boolean assert is true. Usage: assert.is_true(true, case, 'is true')
Parameters:
a : bool, value "a" to check is true
case : string , the current test case and array of previous unit tests (__ASSERTS)
name : string, the current unit test name, if undefined the test index of the current case is used
Returns: bool, true if the assertion passes, false otherwise
is_false(a, case, name) Boolean assert is false. Usage: assert.is_false(false, case, 'is false')
Parameters:
a : bool, value "a" to check is false
case : string , the current test case and array of previous unit tests (__ASSERTS)
name : string, the current unit test name, if undefined the test index of the current case is used
Returns: bool, true if the assertion passes, false otherwise
bool_equal(a, b, case, name) Boolean assert equal. Usage: assert.bool_equal(true, true, case, 'true == true')
Parameters:
a : bool, value "a" to compare equal to "b"
b : bool, value "b" to compare equal to "a"
case : string , the current test case and array of previous unit tests (__ASSERTS)
name : string, the current unit test name, if undefined the test index of the current case is used
Returns: bool, true if the assertion passes, false otherwise
bool_not_equal(a, b, case, name) Boolean assert not equal. Usage: assert.bool_not_equal(true, false, case, 'true != false')
Parameters:
a : bool, value "a" to compare not equal "b"
b : bool, value "b" to compare not equal "a"
case : string , the current test case and array of previous unit tests (__ASSERTS)
name : string, the current unit test name, if undefined the test index of the current case is used
Returns: bool, true if the assertion passes, false otherwise
bool_nan(a, case, name) Boolean assert is NaN. Usage: assert.bool_nan(bool(na), case, 'bool is NaN')
Parameters:
a : bool, value "a" to check is NaN
case : string , the current test case and array of previous unit tests (__ASSERTS)
name : string, the current unit test name, if undefined the test index of the current case is used
Returns: bool, true if the assertion passes, false otherwise
bool_not_nan(a, case, name) Boolean assert is not NaN. Usage: assert.bool_not_nan(true, case, 'bool is not NaN')
Parameters:
a : bool, value "a" to check is not NaN
case : string , the current test case and array of previous unit tests (__ASSERTS)
name : string, the current unit test name, if undefined the test index of the current case is used
Returns: bool, true if the assertion passes, false otherwise
bool_array_equal(a, b, case, name) Boolean assert arrays are equal. Usage: assert.bool_array_equal(array.from(true), array.from(true), case, ' == ')
Parameters:
a : bool , array "a" to check is identical to array "b"
b : bool , array "b" to check is identical to array "a"
case : string , the current test case and array of previous unit tests (__ASSERTS)
name : string, the current unit test name, if undefined the test index of the current case is used
Returns: bool, true if the assertion passes, false otherwise
str_equal(a, b, case, name) String assert equal. Usage: assert.str_equal('hi', 'hi', case, '"hi" == "hi"')
Parameters:
a : string, value "a" to compare equal to "b"
b : string, value "b" to compare equal to "a"
case : string , the current test case and array of previous unit tests (__ASSERTS)
name : string, the current unit test name, if undefined the test index of the current case is used
Returns: bool, true if the assertion passes, false otherwise
str_not_equal(a, b, case, name) String assert not equal. Usage: assert.str_not_equal('hi', 'bye', case, '"hi" != "bye"')
Parameters:
a : string, value "a" to compare not equal "b"
b : string, value "b" to compare not equal "a"
case : string , the current test case and array of previous unit tests (__ASSERTS)
name : string, the current unit test name, if undefined the test index of the current case is used
Returns: bool, true if the assertion passes, false otherwise
str_nan(a, case, name) String assert is NaN. Usage: assert.str_nan(string(na), case, 'string is NaN')
Parameters:
a : string, value "a" to check is NaN
case : string , the current test case and array of previous unit tests (__ASSERTS)
name : string, the current unit test name, if undefined the test index of the current case is used
Returns: bool, true if the assertion passes, false otherwise
str_not_nan(a, case, name) String assert is not NaN. Usage: assert.str_not_nan('hi', case', 'string is not NaN')
Parameters:
a : string, value "a" to check is not NaN
case : string , the current test case and array of previous unit tests (__ASSERTS)
name : string, the current unit test name, if undefined the test index of the current case is used
Returns: bool, true if the assertion passes, false otherwise
str_in(a, b, case, name) String assert value in string array. Usage: assert.str_in('hi', array.from('hi'), case, '"hi" in ')
Parameters:
a : string, value "a" to check is in array "b"
b : string , array "b" to check contains "a"
case : string , the current test case and array of previous unit tests (__ASSERTS)
name : string, the current unit test name, if undefined the test index of the current case is used
Returns: bool, true if the assertion passes, false otherwise
str_not_in(a, b, case, name) String assert value not in string array. Usage: assert.str_in('hi', array.from('bye'), case, '"hi" in ')
Parameters:
a : string, value "a" to check is not in array "b"
b : string , array "b" to check does not contain "a"
case : string , the current test case and array of previous unit tests (__ASSERTS)
name : string, the current unit test name, if undefined the test index of the current case is used
Returns: bool, true if the assertion passes, false otherwise
str_array_equal(a, b, case, name) String assert arrays are equal. Usage: assert.str_array_equal(array.from('hi'), array.from('hi'), case, ' == ')
Parameters:
a : string , array "a" to check is identical to array "b"
b : string , array "b" to check is identical to array "a"
case : string , the current test case and array of previous unit tests (__ASSERTS)
name : string, the current unit test name, if undefined the test index of the current case is used
Returns: bool, true if the assertion passes, false otherwise
new_case(case, name) Assign a new test case name, for the next set of unit tests. Usage: assert.new_case(case, 'My tests')
Parameters:
case : string , the current test case and array of previous unit tests (__ASSERTS)
name : string, the case name for the next suite of tests
clear(case) Clear all stored unit tests from all cases. Usage: assert.clear(case)
Parameters:
case : string , the current test case and array of previous unit tests (__ASSERTS)
revert(case) Revert the previous unit test. Usage: = assert.revert(case)
Parameters:
case : string , the current test case and array of previous unit tests (__ASSERTS)
Returns: , tuple containing the msg and result of the reverted test
passed(case, revert) Check if the last unit test has passed. Usage: bool success = assert.passed(case)
Parameters:
case : string , the current test case and array of previous unit tests (__ASSERTS)
revert : bool, optionally revert the test
Returns: bool, true only if the test passed
failed(case, revert) Check if the last unit test has failed. Usage: bool failure = assert.failed(case)
Parameters:
case : string , the current test case and array of previous unit tests (__ASSERTS)
revert : bool, optionally revert the test
Returns: bool, true only if the test failed
report(case, verbose) Report the outcome of unit tests that fail. Usage: bool passed = assert.report(case)
Parameters:
case : string , the current test case and array of previous unit tests (__ASSERTS)
verbose : bool, optionally display full report that includes the outcome of all tests
Returns: bool, true only if all tests passed
unittest_assert(case) Assert module unit tests, for inclusion in parent script test suite. Usage: assert.unittest_assert(__ASSERTS)
Parameters:
case : string , the current test case and array of previous unit tests (__ASSERTS)
unittest(verbose) Run the assert module unit tests as a stand alone. Usage: assert.unittest()
Parameters:
verbose : bool, optionally toggle report to display the outcome of all unit tests
Barholle eMA and RSI Movement TestThis is a test that offers insight into whether and asset is heading into bullish or bearish territory.
This indicator/test offers insight into the Exponential Moving Average's velocity and acceleration as well as the Stochastic RSI's velocity, acceleration and jerk. Included is a 'Stochastic Difference' and 'Stochastic Growth' indicators (commented out) that measure the difference between K and D in the Stoch RSI as well as the rate of it's change. This test is all about crossovers - the best leading indicator is a downward cross of the eMA velocity over the eMA acceleration, indicating a drop in price in the current or next bar.
The lines or importance have been set to -2 and 5, but these should be adjusted to suit your preferences. These numbers were chosen in order to try and create some kind of threshold after which action might be suggested. Backtesting is highly recommended so you can see how the test does and does not work. It is super powerful, but it is not omniscient - its an RSI and eMA derivative, past success does not necessarily dictate future success.
Please look at the code for several more plots you can use of derivatives and other ideas explore but commented out for greater legibility of the graph. Commenting and commenting (or uncommenting all and just disabling some in the settings) and comparing the graphs and crossovers is a useful exercise. To that end, one last concept - the MARSI - a combined moving averages and RSI measurement - was abandoned because it didn't appear to indicate anything of use, however you may find crossovers or patterns with it comparing it to other graphs, so it was left in but commented.
Please take a look at the comments and all the math and indicators 'left on the cutting room floor' in the script. Maybe you'll find a gem in the redux version of this script.
Outreach regarding the script, patterns noticed and full-on stealing of the script are all permitted. Many elements of this script were nabbed from other scripts - thank you to a community of coders who put it all out there.
EMA TrendThe purpose of this script is to identify price trends based on EMAs. The relative position of price to specific EMAs and the position of certain EMAs towards each other are used to determine the trend direction. The script is intended for investors as a tool to define a basis for further evaluation. I do not use the script as a signal generator and would not recommend doing so without the help of additional indicators.
How to work with the script
The major (or long term) trend direction is determined by the 144 EMA much in the same way as the 200 MA is used in other systems. If the price is above the 144 EMA we are in a long term uptrend, below we are in a long term downtrend. This is to be taken with a grain of salt though. The 144 EMA is considerably shorter than the 200 SMA and is more prone to the price fluctuating around it during periods without a strong long term trend. I recommend using this as a confirmation for the short term trend.
The short term trend is derived from the position and slope of the price, the 21 EMA and the 55 EMA. If the price is above the 21 EMA, the 21 above the 55 EMA, both EMAs are sloping upwards and the distance between the two is increasing, we are talking about an uptrend (and vice versa for a downtrend). This is visualized by the color of the fill between the 144 EMA and close price. Green for uptrend, red for downtrend and no color for an undetermined trend.
The EMAs used are: 21 , 34 , 55 , 89 , 144 , 233 . Most of the EMAs are at 50 transparency to appear less dominant. For orientation, the 144 EMA is bright green to indicate its general importance for the trend determination, and the 55 EMAs is not transparent mainly to be able to identify positioning when the EMAs are close together.
Base time frame EMA
The 144 EMA is plotted twice where one is fixed to the daily time frame (can be configured) to be able to have the 144 on different timeframes during analysis. I find this very useful to keep the focus on my main time frame while analyzing trend on lower or higher time frames. This can also be turned off.
Configurability
This script is less configurable than I generally like with my other scripts. The reason is that the title attribute of the plots is not dynamic, and I use the data window often to get exact values from the script to determine buy targets for pullbacks and other things. Hence, I prefer not to have random names (or no names) in there to save mental capacity. If this ever becomes available, I'll gladly add this to this script. Till then, I encourage you to take the script and adjust it to your own needs. It should be simple enough even if you are just starting out in pine.
Dynamic Customizable 50% Line & Daily High/Low + True Day OpenA Unique Indicator for Precise Market-Level Analysis
This indicator is a fully integrated solution that automates complex market-level calculations and visualizations, offering traders a tool that goes beyond the functionality of existing open-source alternatives. By seamlessly combining several trading concepts into a single script, it delivers efficiency, accuracy, and customization that cater to both novice and professional traders.
Key Features: A Breakdown of What Makes It Unique
1. Adaptive Daily Highs and Lows
Automatically detects and plots daily high and low levels based on the selected time frame, dynamically updating in real time.
Features session-based adjustments, allowing traders to focus on levels that matter for specific trading sessions (e.g., London, New York).
Fully customizable styling, visibility, and alerts tailored to each trader’s preferences.
How It Works:
The indicator calculates daily high and low levels directly from price data, integrating session-specific time offsets to account for global trading hours. These levels provide traders with clear visual markers for key liquidity zones.
2. Automated ICT 50% Range Line
A pioneering implementation of ICT’s mid-range concept, this feature dynamically calculates and displays the midpoint of the daily range.
Offers traders a visual guide to identify premium and discount zones, aiding in determining market bias and potential trade setups.
How It Works:
The script calculates the range between the day’s high and low, dividing it by two to generate the midline. This line updates in real-time, ensuring that traders always see the most current premium and discount levels as price action evolves.
3. Dynamic Market Open Levels
Plots session opens (e.g., Asia, London, New York) and the True Day Open to provide actionable reference points for intra-day trading strategies.
Enhances precision in identifying liquidity shifts and aligning trades with institutional price movements.
How It Works:
The indicator uses predefined session times to calculate and display the opening levels for key trading sessions. It dynamically adjusts for time zones, ensuring accuracy regardless of the trader’s location.
4. Custom Watermark for Enhanced Visualization
Includes an optional watermark feature that allows users to display custom text on their charts.
Ideal for personalization, branding, or highlighting session notes without disrupting the clarity of the chart.
Why This Indicator Stands Out
First-to-Market Automation:
While the ICT 50% range line is a widely recognized concept, this is the first script to automate its calculation, combining it with other pivotal trading levels in a single tool.
All-in-One Functionality:
Unlike open-source alternatives that focus on individual features, this script integrates daily highs/lows, mid-range levels, session opens, and customizable watermarks into one cohesive system. The consolidation reduces the need for multiple indicators and ensures a clean, efficient chart setup.
Dynamic Customization:
Every feature can be adjusted to align with a trader’s strategy, time zone, or aesthetic preferences. This level of adaptability is unmatched in existing tools.
Proprietary Logic:
The indicator’s underlying calculations are built from scratch, leveraging advanced programming techniques to ensure accuracy and reliability. These proprietary methods differentiate it from similar open-source scripts.
How to Use This Indicator
Apply the Indicator:
Add it to your TradingView chart from the library.
Configure Settings:
Use the intuitive settings panel to adjust plotted levels, colors, styles, and visibility. Tailor the indicator to your trading strategy.
Incorporate into Analysis:
Combine the plotted levels with your preferred trading approach to identify liquidity zones, establish market bias, and pinpoint potential reversals or entries.
Stay Focused:
With all key levels automated and updated in real time, traders can focus on execution rather than manual plotting.
Originality and Justification for Closed Source
This script is closed-source due to its unique combination of features and proprietary logic that automates complex trading concepts like the ICT 50% range line and session-specific levels. Open-source alternatives lack this level of integration and customization, making this indicator a valuable and original contribution to the TradingView ecosystem.
What Sets It Apart from Open-Source Scripts?
Unlike open-source tools, this indicator doesn’t just replicate individual features—it enhances and integrates them into a seamless, all-in-one solution that offers traders a more efficient and effective way to analyze the market.
Advanced Volume-Driven Breakout SignalsThe "Advanced Volume-Driven Breakout Signals" indicator is a cutting-edge tool designed to help traders identify high-potential trading opportunities through sophisticated volume analysis techniques. This indicator integrates volume flow analysis, moving averages, and Relative Volume (RVOL) to provide a comprehensive view of market conditions, going beyond traditional Volume Spread Analysis (VSA) methods.
Key Features:
Volume Flow Analysis: Distinguishes bullish and bearish volume flows with distinct colors, making it easier to visualize market sentiment and potential breakout points.
Volume Flow Moving Averages: Calculates moving averages for volume using various methods (SMA, EMA, WMA, HMA, VWMA), accommodating different trading strategies. This includes settings for adjusting the type of moving average and its period, as well as thresholds for high, medium, and low volume levels.
Volume Spikes Detection: Identifies significant volume spikes based on user-defined multipliers and moving averages, highlighting unusual trading activity.
Volume MA Cloud Settings: Computes general moving averages of volume to track trends and detect deviations. This feature includes options to select different moving average types and adjust thresholds for detecting high volume activity.
Relative Volume (RVOL): Measures current volume relative to historical averages, triggering signals when RVOL exceeds predefined thresholds, indicating notable changes in trading activity.
Entry Conditions: Provides clear long and short entry signals based on combined volume flow conditions and RVOL, offering actionable trading opportunities.
Volume Visualization:
— Bullish Volume Flow: Light and dark green bars indicate bullish volume flow.
— Bearish Volume Flow: Light and dark red bars denote bearish volume flow.
— High Volume Bars: Highlighted in yellow, and extreme volume bars in orange for additional context. These bars are plotted for visual aid and do not directly influence trade signals, focusing instead on the quality and strength of the volume flow.
Alerts: Allows users to create alert notifications for long and short entry signals when the criteria are met, enabling traders to respond promptly to trading opportunities.
Usage:
Overlay: Apply the indicator directly to your price chart to visualise real-time signals and volume conditions.
Customisable: Adjust settings for moving averages, RVOL, and other parameters to match your trading strategy and preferences.
Comparison to VSA Scripts: The "Advanced Volume-Driven Breakout Signals" indicator extends beyond traditional VSA scripts by incorporating a wider range of analytical features. While VSA primarily focuses on volume spread patterns and price action, this indicator offers enhanced functionality with advanced RVOL metrics, customizable moving averages, and detailed volume spike detection, making it a more versatile tool for identifying breakout opportunities and managing trades. It is particularly effective when used alongside key levels and order blocks.
Acknowledgements: Special thanks to @oh92 and @goofoffgoose for their invaluable scripts, which served as inspiration in the development of this advanced trading indicator.
Notes: The script is continually evolving, with ongoing refinements aimed at enhancing accuracy and performance.
Black-Scholes option price model & delta hedge strategyBlack-Scholes Option Pricing Model Strategy
The strategy is based on the Black-Scholes option pricing model and allows the calculation of option prices, various option metrics (the Greeks), and the creation of synthetic positions through delta hedging.
ATTENTION!
Trading derivative financial instruments involves high risks. The author of the strategy is not responsible for your financial results! The strategy is not self-sufficient for generating profit! It is created exclusively for constructing a synthetic derivative financial instrument. Also, there might be errors in the script, so use it at your own risk! I would appreciate it if you point out any mistakes in the comments! I would be even more grateful if you send the corrected code!
Application Scope
This strategy can be used for delta hedging short positions in sold options. For example, suppose you sold a call option on Bitcoin on the Deribit exchange with a strike price of $60,000 and an expiration date of September 27, 2024. Using this script, you can create a delta hedge to protect against the risk of loss in the option position if the price of Bitcoin rises.
Another example: Suppose you use staking of altcoins in your strategies, for which options are not available. By using this strategy, you can hedge the risk of a price drop (Put option). In this case, you won't lose money if the underlying asset price increases, unlike with a short futures position.
Another example: You received an airdrop, but your tokens will not be fully unlocked soon. Using this script, you can fully hedge your position and preserve their dollar value by the time the tokens are fully unlocked. And you won't fear the underlying asset price increasing, as the loss in the event of a price rise is limited to the option premium you will pay if you rebalance the portfolio.
Of course, this script can also be used for simple directional trading of momentum and mean reversion strategies!
Key Features and Input Parameters
1. Option settings:
- Style of option: "European vanilla", "Binary", "Asian geometric".
- Type of option: "Call" (bet on the rise) or "Put" (bet on the fall).
- Strike price: the option contract price.
- Expiration: the expiry date and time of the option contract.
2. Market statistic settings:
- Type of price source: open, high, low, close, hl2, hlc3, ohlc4, hlcc4 (using hl2, hlc3, ohlc4, hlcc4 allows smoothing the price in more volatile series).
- Risk-free return symbol: the risk-free rate for the market where the underlying asset is traded. For the cryptocurrency market, the return on the funding rate arbitrage strategy is accepted (a special function is written for its calculation based on the Premium Price).
- Volatility calculation model: realized (standard deviation over a moving period), implied (e.g., DVOL or VIX), or custom (you can specify a specific number in the field below). For the cryptocurrency market, the calculation of implied volatility is implemented based on the product of the realized volatility ratio of the considered asset and Bitcoin to the Bitcoin implied volatility index.
- User implied volatility: fixed implied volatility (used if "Custom" is selected in the "Volatility Calculation Method").
3. Display settings:
- Choose metric: what to display on the indicator scale – the price of the underlying asset, the option price, volatility, or Greeks (all are available).
- Measure: bps (basis points), percent. This parameter allows choosing the unit of measurement for the displayed metric (for all except the Greeks).
4. Trading settings:
- Hedge model: None (do not trade, default), Simple (just open a position for the full volume when the strike price is crossed), Synthetic option (creating a synthetic option based on the Black-Scholes model).
- Position side: Long, Short.
- Position size: the number of units of the underlying asset needed to create the option.
- Strategy start time: the moment in time after which the strategy will start working to create a synthetic option.
- Delta hedge interval: the interval in minutes for rebalancing the portfolio. For example, a value of 5 corresponds to rebalancing the portfolio every 5 minutes.
Post scriptum
My strategy based on the SegaRKO model. Many thanks to the author! Unfortunately, I don't have enough reputation points to include a link to the author in the description. You can find the original model via the link in the code, as well as through the search indicators on the charts by entering the name: "Black-Scholes Option Pricing Model". I have significantly improved the model: the calculation of volatility, risk-free rate and time value of the option have been reworked. The code performance has also been significantly optimized. And the most significant change is the execution, with which you can now trade using this script.
Dynamic Cycle Oscillator [Quantigenics]This script is designed to navigate through the ebbs and flows of financial markets. At its core, this script is a sophisticated yet user-friendly tool that helps you identify potential market turning points and trend continuations.
How It Works:
The script operates by plotting two distinct lines and a central histogram that collectively form a band structure: a center line and two outer boundaries, indicating overbought and oversold conditions. The lines are calculated based on a blend of exponential moving averages, which are then refined by a root mean square (RMS) over a specified number of bars to establish the cyclic envelope.
The input parameters:
Fast and Slow Periods:
These determine the sensitivity of the script. Shorter periods react quicker to price changes, while longer periods offer a smoother view.
RMS Length:
This parameter controls the range of the cyclic envelope, influencing the trigger levels for trading signals.
Using the Script:
On your chart, you’ll notice how the Dynamic Cycle Oscillator’s lines and histogram weave through the price action. Here’s how to interpret the movements.
Breakouts and Continuations:
Buy Signal: Consider a long position when the histogram crosses above the upper boundary. This suggests a possible strong bullish run.
Sell Signal: Consider a short position when the histogram crosses below the lower boundary. This suggests a possible strong bearish run.
Reversals:
Buy Signal: Consider a long position when the histogram crosses above the lower boundary. This suggests an oversold market turning bullish.
Sell Signal: Consider a short position when the histogram crosses below the upper boundary. This implies an overbought market turning bearish.
The script’s real-time analysis can serve as a robust addition to your trading strategy, offering clarity in choppy markets and an edge in trend-following systems.
Thanks! Hope you enjoy!
Triple MA HTF Indicator - Dynamic SmoothingThe indicator version of the "Triple MA HTF Strategy - Dynamic Smoothing" strategy script. In summary the indicator consist of 3 higher time frame moving averages. In which the highest timeframe is used for confirmation on the trend (filter). Moving average 1 and 2 are used to enter and exit the trade (crossover / crossunder). The main principle is to detect momentum when the faster MA 1 crosses the slower MA 2 and only trade with the trend (MA3). The dynamic smoothing in the code makes the indicator suitable to trade on lower tramecharts. The indicator script comes with the following features:
options for different types of MA.
options to choose from different timeframes & select # bars of that timeframe to calculate the MA value.
visualizations of the MA using Dynamic Smoothing calculations on lower timecharts. Note that the chart opened should be lower than the selected timeframes in the configurations.
Alerts for entry long, shorts and exits.
For more details on the script and possibility for backtesting the Triple MA HTF indicator I refer to my earlier published strategy script:
Buy Sell Volume SeparateDescription:
The script is designed to provide traders with a unique and comprehensive analysis of trading volume dynamics. Unlike existing scripts, the script offers a distinct advantage by presenting both buy and sell volumes on separate scales, simplifying trading decisions.
Key Features:
1. Dual Volume Scales: The script provides two separate volume scales, one for buy volumes and another for sell volumes. This separation allows to easily distinguish between buying and selling pressure, aiding in more precise trade entries and exits.
2. Clear and Intuitive Chart: The script ensures that the chart it generates is clean and easy to understand. The buy and sell volumes are color-coded for clarity, and you can quickly identify significant volume spikes and trends.
How to Use:
1. Adding the Script: To use the script, simply add it to your TradingView chart.
2. Interpreting Buy and Sell Volumes: On the chart, you will see two separate volume scales—one for buy volumes and one for sell volumes. Green bars represent buying pressure, while red bars indicate selling pressure. Pay attention to the relative strengths and patterns of these bars to gauge market sentiment.
3. Informed Trading Decisions: Armed with insights into both buy and sell volumes, you can make more informed trading decisions. Look for divergences, patterns, or significant volume spikes to identify potential entry and exit points.
Risk Management and Positionsize - MACD exampleMastering Risk Management
Risk management is the cornerstone of successful trading, and it's often the difference between turning a profit and suffering a loss. In light of its importance, I share a risk management tool which you can use for your trading strategies. The script not only assists in position sizing but also comes with built-in technical features that help in market timing. Let's delve into the nitty-gritty details.
Input Parameter: MarginFactor
One of the key features of the script is the MarginFactor input parameter. This element lets you control the portion of your equity used for placing each trade. A MarginFactor of -0.5 means 50% of your total equity will be deployed in placing the position size. Although Tradingview has a built-in option to adjust position sizing in a same way, I personally prefer to have the logic in my pinecode script. The main reason is userexperience in managing and testing different settings for different charts, timeframes and instruments (with the same strategy).
Stoploss and MarginFactor
If your strategy has a 4% stop-loss, you can choose to use only 50% of your equity by setting the MarginFactor to -0.5. In this case, you are effectively risking only 2% of your total capital per trade, which aligns well with the widely-accepted rule of thumb suggesting a 1-2% risk per trade. Similar if your stoploss is only 1% you can choose to change the MarginFactor to 1, resulting in a positionsize of 200% of your equity. The total risk would be again 2% per trade if your stoploss is set to 1%.
Max Drawdown and MarginFactor
Your MarginFactor setting can also be aligned with the maximum drawdown of your strategy, seen during a backtested period of 2-3 years. For example, if the max drawdown is 15%, you could calibrate your MarginFactor accordingly to limit your risk exposure.
Option to Toggle Number of Contracts
The script offers the option to toggle between using a percentage of equity for position sizing or specifying a fixed number of contracts. Utilizing a percentage of equity might yield unrealistic backtest results, especially over longer periods. This occurs because as the capital grows, the absolute position size also increases, potentially inflating the accumulated returns generated by the backtester. On the other hand, setting a fixed number of contracts as your position size offers a more stable and realistic ROI over the backtested period, as it removes the compounding effect on position sizes.
Key Features Strategy
MACD High Time Frame Entry and Exit Logic
The strategy employs a high time frame MACD (Moving Average Convergence Divergence) to make entry and exit decisions. You can easily adjust the timeframe settings and MACD settings in the inputsection to trade on lower timeframes. For more information on the HTF MACD with dynamic smoothing see:
Moving Average High Time Frame Filter
To reduce market 'noise', the strategy incorporates a high time frame moving average filter. This ensures that the trades are aligned with the dominant market trend (trading the trend). In the inputsection traders can easily switch between different type of moving averages. For more information about this HTF filter see:
Dynamic Smoothing
The script includes a feature for dynamic smoothing. The script contains The timeframeToMinutes(tf) function to convert any given time frame into its equivalent in minutes. For example, a daily (D) time frame is converted into 1440 minutes, a weekly (W) into 10,080 minutes, and so forth. Next the smoothing factor is calculated by dividing the minutes of the higher time frame by those of the current time frame. Finally, the script applies a Simple Moving Average (SMA) over the MACD, SIGNAL, and HIST values, MA filter using the dynamically calculated smoothing factor.
User Convenience: One of the major benefits is that traders don't need to manually adjust the smoothing factor when switching between different time frames. The script does this dynamically.
Visual Consistency: Dynamic smoothing helps traders to more accurately visualize and interpret HTF indicators when trading on lower time frames.
Time Frame Restriction: It's crucial to note that the operational time frame should always be lower than the time frame selected in the input sections for dynamic smoothing to function as intended.
By incorporating this dynamic smoothing logic, the script offers traders a nuanced yet straightforward way to adapt High Time Frame indicators for lower time frame trading, enhancing both adaptability and user experience.
Limitations: Exit Strategy
It's crucial to note that the script comes with a simplified exit strategy, devoid of features like a stop-loss, trailing stop-loss or multiple take profits. This means that while the script focuses on entries and risk management, it might result in higher losses if market conditions unexpectedly turn unfavorable.
Conclusion
Effective risk management is pivotal for trading success, and this TradingView script is designed to give you a better idea how to implement positions sizing with your preferred strategy. However, it's essential to note that this tool should not be considered financial advice. Always perform your due diligence and consult with financial advisors before making any trading decisions.
Feel free to use this risk management tool as building block in your trading scripts, Happy Trading!
Hikkake Hunter 2.0This script serves as a successor to a previous script I wrote for identifying Hikkakes nearly two years ago.
The old version has been preserved here:
█ OVERVIEW
This script is a rework of an old script that identified the Hikkake candlestick pattern. While this pattern is not usually considered a part of the standard candlestick patterns set, I found a lot of value when finding a solution to identifying it. A Hikkake pattern is a 3-candle pattern where a middle candle is nested in between the range of the prior candle, and a candle that follows has a higher high and a higher low (bearish setup) or a lower high and a lower low (bullish setup). What makes this pattern unique is the "confirmation" status of the pattern; within 3 candles of this pattern's appearance, there must be a candle that closes above the high (bullish setup) or below the low (bearish setup) of the second candle. Additional flexibility has been added which allows the user to specify the number of candles (up to 5) that the pattern may have to confirm after its appearance.
█ CONCEPTS
This script will cover concepts mainly focusing on candlestick analysis, price analysis (with higher timeframes), and statistical analysis. I believe there is also educational value presented with the use of user-defined-types (UDTs) in accomplishing these concepts that I hope others will find useful.
Candlestick Analysis - Identification and confirmation of the patterns in the deprecated script were clunky and inefficient. While the previous script required the use of 6 candles to perform the confirmations of patterns (restricted solely to identifying patterns that confirmed in 3 candles or less), this script only requires 3 candles to identify and process patterns by utilizing a UDT representing a 'pattern object'. An object representing a pattern will be created when it has been identified, and fields within that object will be set for processing by the functions it is passed to. Pattern objects are held by a var array (values within the array persist between bars) and will be removed from this array once they have been confirmed or non-confirmed.
This is a significant deviation from the previous script's methods, as it prevents unnecessary re-evaluations of the confirmation status of patterns (i.e. Hikkakes confirmed on the first candle will no longer need to be checked for confirmations on the second or third; a pitfall of the deprecated version which required multiple booleans tracking prior confirmation statuses). This deviation is also what provides the flexibility in changing the number of candles that can pass before a pattern is deemed non-confirmed.
As multiple patterns can be confirmed simultaneously, this script uses another UDT representing a linked-list reduction of the pattern object used to process it. This liked-list object will then be used for Price Analysis.
Price Analysis - This script employs the use of a UDT which contains all the returns of confirmed patterns. The user specifies how many candles ahead of the confirmed pattern to calculate its return, as well as where this calculation begins. There are two settings: FROM APPEARANCE and FROM CONFIRMATION (default). Price differences are calculated from the open of the candle immediately following the candle which had confirmed the pattern to the close of the candle X candles ahead (default 10). ( SEE FEATURES )
Because of how Pine functions, this calculation necessitates a lookback on prior candles to identify when a pattern had been confirmed. This is accomplished with the following pseudo-code:
if not na(confirmed linked-list )
for all confirmed in list
GET MATRIX PLACEMENT
offset = FROM CONFIRMATION ? 0 : # of candles to confirm
openAtFind = open
percent return = ((close - openAtFind) / openAtFind) * 100
ADD percent return TO UDT IN MATRIX
All return UDTs are held in a matrix which breaks up these patterns into specific groups covered in the next section.
Higher Timeframes - This script makes a request.security call to a higher timeframe in order to identify a price range which breaks up these patterns into groups based on the 'partition' they had appeared in. The default values for this partitioning will break up the chart into three sections: upper, middle, and lower. The upper section represents the highest 20% of the yearly trading range that an asset has experienced. The lower section represents the trading range within a third (33%) of the yearly low. And the middle section represents the yearly high-low range between these two partitions.
The matrix containing all return UDTs will have these returns split up based on the number of candles required to confirm the pattern as well as the partition the pattern had appeared in. The underlying rationale is that patterns may perform better or worse at different parts of an asset's trading range.
Statistical Analysis - Once a pattern has been confirmed, the matrix containing all return UDTs will be queried to check if a 'returnArray' object has been created for that specific pattern. If not, one will be initialized and a confirmed linked-list object will be created that contains information pertinent to the matrix position of this object.
This matrix contains the returns of both the Bullish and Bearish Hikkake patterns, separated by the number of candles needed to confirm them, and by the partitions they had appeared in. For the standard 3 candles to confirm, this means the matrix will contain 18 elements (dependent on the number of candles allowed for confirmations; its size will range from 12 to 30).
When the required number of candles for Price Analysis passes, a percent return is calculated and added to the returnArray contained in the matrix at the location derived from the confirmed linked-list object's values. The return is added, and all values in the returnArray are updated using Pine's built in array.___ functions. This returnArray object contains the array of all returns, its size, its average, the median, the standard deviation of returns, and a separate 3-integer array which holds values that correspond to the types of returns experienced by this pattern (negative, neutral, and positive)*.
After a pattern has been confirmed, this script will place the partition and all of the aforementioned stats values (plus a 95% confidence interval of expected returns) related to that pattern onto the tooltip of the label that identifies it. This allows users to scroll over the label of a confirmed pattern to gauge its prior performance under specific conditions. The percent return of the specific pattern identified will later be placed onto the label tooltip as well. ( SEE LIMITATIONS )
The stats portion of this script also plays a significant role in how patterns are presented when using the Adaptive Coloring mode described in FEATURES .
*These values are incremented based on user-input related to what constitutes a 'negative' or 'positive' return. Default values would place any return by a pattern between -3% and 3% in the 'neutral' category, and values exceeding either end will be placed in the 'negative' or 'positive' categories.
█ FEATURES
This script contains numerous inputs for modifying its behavior and how patterns are presented/processed, separated into 5 groups.
Confirmation Setting - The most important input for this script's functioning. This input is a 'confirm=true' input and must be set by the user before the script is applied to the chart. It sets the number of candles that a pattern has to confirm once it has been identified.
Alert Settings - This group of booleans sets which types of alerts will fire during the scripts execution on the chart. If enabled, the four alerts will trigger when: a pattern has been identified, a pattern has been confirmed, a pattern has been non-confirmed, and show the return for that confirmed pattern in an alert. Because this script uses the 'alert' function and not 'alertcondition', these must be enabled before 'any alert() function call' is set in TradingView's 'alerts' settings.
Partition Settings - This group of inputs are responsible for creating (and viewing) the partitions that breaks the returns of the patterns identified up into their respective groups. The user may set the resolution to grab the range from, the length back of this resolution the partitions get their values from, the thresholds which breaks the partitions up into their groups, and modify the visibility (if they're shown, the colors, opacity) of these partitions.
Stats Settings - These inputs will drastically alter how patterns are presented and the resulting information derived from them after their appearance. Because of this section's importance, some of these inputs will be described in more detail.
P/L Sample Length - Defines the number of candles after the starting point to grab values from in the % return calculation for that pattern.
P/L Starting Point - Defines the starting point where the P/L calculation will take place. 'FROM APPEARANCE' will set the starting point at the candle immediately following the pattern's appearance. 'FROM CONFIRMATION' will place the starting point immediately following the candle which had confirmed the pattern. ( SEE LIMITATIONS )
Min Returns Needed - Sets how many times a specific pattern must appear (both by number of candles needed to confirm and by partition) before the statistics for that pattern are displayed onto the tooltip (and for gradient coloration in Adaptive Coloring mode).
Enable Adaptive Coloring - Changes the coloration of the patterns based on the bullish/bearishness of the specified Gradient Reference value of that pattern compared to the Return Tolerance values OR the minimum and maximum values of that specified Gradient Reference value contained in the matrix of all returns. This creates a color from a gradient using the user-specified colors and alters how many of the patterns may appear if prior performance is taken into account.
Gradient Reference - Defines which stats measure of returns will be used in the gradient color generation. The two settings are 'AVG' and 'MEDIAN'.
Hard Limit - This boolean sets whether the Return Tolerance values will not be replaced by values that exceed them from the matrix of returns in color gradient generation. This changes the scale of the gradient where any Gradient Reference values of patterns that exceed these tolerances will be colored the full bullish or bearish gradient colors, and anything in between them will be given a color from the gradient.
Visibility Settings - This last section includes all settings associated with the overall visibility of patterns found with this script. This includes the position of the labels and their colors (+ pattern colors without Adaptive Coloring being enabled), and showing patterns that were non-confirmed.
Most of these inputs in the script have these kinds of descriptions to what they do provided by their tooltips.
█ HOW TO USE
I attempted to make this script much easier to use in terms of analyzing the patterns and displaying the information to the user. The previous script would have the user go to the 'data window' side bar on TradingView to view the returns of a pattern after they had specified which pattern to analyze through the settings, needlessly convoluted. This aim at simplicity was achieved through the use of UDTs and specific code-design.
To use, simply apply the indicator to a chart, set the number of candles (between 2 and 5) for confirming this specific pattern and adjust the many settings described above at your leisure.
█ LIMITATIONS
Disclaimer - This is a tool created with the hopes of helping identify a specific pattern and provide an informative view about the performance of that pattern. Previous performance is not indicative of future results. None of this constitutes any form of financial advice, *use at your own risk*.
Statistical Analysis - This script assumes that all patterns will yield a NORMAL DISTRIBUTION regarding their returns which may not be reflective of reality. I personally have limited experience within the field of statistics apart from a few high school/college courses and make no guarantees that the calculation of the 95% confidence interval is correct. Please review the source code to verify for yourself that this interval calculation is correct (Function Name: f_DisplayStatsOnLabel).
P/L Starting Point - Because of when the object related to the confirmation status of a pattern is created (specifically the linked-list object) setting the 'P/L Starting Point' to 'FROM APPEARANCE' will yield the results of that P/L calculation at the same time as 'FROM CONFIRMATION'.
█ EXAMPLES
Default Settings:
Partition Background (default):
Partition Background (Resolution D : Length 30):
Adaptive Coloration:
Show Non-Confirmed:
Trend Line Adam Moradi v1 (Tutorial Content)
The Pine Script strategy that plots pivot points and trend lines on a chart. The strategy allows the user to specify the period for calculating pivot points and the number of pivot points to be used for generating trend lines. The user can also specify different colors for the up and down trend lines.
The script starts by defining the input parameters for the strategy and then calculates the pivot high and pivot low values using the pivothigh() and pivotlow() functions. It then stores the pivot points in two arrays called trend_top_values and trend_bottom_values. The script also has two arrays called trend_top_position and trend_bottom_position which store the positions of the pivot points.
The script then defines a function called add_to_array() which takes in three arguments: apointer1, apointer2, and val. This function adds val to the beginning of the array pointed to by apointer1, and adds bar_index to the beginning of the array pointed to by apointer2. It then removes the last element from both arrays.
The script then checks if a pivot high or pivot low value has been calculated, and if so, it adds the value and its position to the appropriate arrays using the add_to_array() function.
Next, the script defines two arrays called bottom_lines and top_lines which will be used to store trend lines. It also defines a variable called starttime which is set to the current time.
The script then enters a loop to calculate and plot the trend lines. It first deletes any existing trend lines from the chart. It then enters two nested loops which iterate over the pivot points stored in the trend_bottom_values and trend_top_values arrays. For each pair of pivot points, the script calculates the slope of the line connecting them and checks if the line is a valid trend line by iterating over the price bars between the two pivot points and checking if the line is above or below the close price of each bar. If the line is found to be a valid trend line, it is plotted on the chart using the line.new() function.
Finally, the script colors the trend lines using the colors specified by the user.
Tutorial Content
'PivotPointNumber' is an input parameter for the script that specifies the number of pivot points to consider when calculating the trend lines. The value of 'PivotPointNumber' is set by the user when they configure the script. It is used to determine the size of the arrays that store the values and positions of the pivot points, as well as the number of pivot points to loop through when calculating the trend lines.
'up_trend_color' is an input parameter for the script that specifies the color to use for drawing the trend lines that are determined to be upward trends. The value of 'up_trend_color' is set by the user when they configure the script and is passed to the color parameter of the line.new() function when drawing the upward trend lines. It determines the visual appearance of the upward trend lines on the chart.
'down_trend_color' is an input parameter for the script that specifies the color to use for drawing the trend lines that are determined to be downward trends. The value of 'down_trend_color' is set by the user when they configure the script and is passed to the color parameter of the line.new() function when drawing the downward trend lines. It determines the visual appearance of the downward trend lines on the chart.
'pivothigh' is a variable in the script that stores the value of the pivot high point. It is calculated using the pivothigh() function, which returns the highest high over a specified number of bars. The value of 'pivothigh' is used in the calculation of the trend lines.
'pivotlow' is a variable in the script that stores the value of the pivot low point. It is calculated using the pivotlow() function, which returns the lowest low over a specified number of bars. The value of 'pivotlow' is used in the calculation of the trend lines.
'trend_top_values' is an array in the script that stores the values of the pivot points that are determined to be at the top of the trend. These are the pivot points that are used to calculate the upward trend lines.
'trend_top_position' is an array in the script that stores the positions (i.e., bar indices) of the pivot points that are stored in the 'trend_top_values' array. These positions correspond to the locations of the pivot points on the chart.
'trend_bottom_values' is an array in the script that stores the values of the pivot points that are determined to be at the bottom of the trend. These are the pivot points that are used to calculate the downward trend lines.
'trend_bottom_position' is an array in the script that stores the positions (i.e., bar indices) of the pivot points that are stored in the 'trend_bottom_values' array. These positions correspond to the locations of the pivot points on the chart.
apointer1 and apointer2 are variables used in the add_to_array() function, which is defined in the script. They are both pointers to arrays, meaning that they hold the memory addresses of the arrays rather than the arrays themselves. They are used to manipulate the arrays by adding new elements to the beginning of the arrays and removing elements from the end of the arrays.
apointer1 is a pointer to an array of floating-point values, while apointer2 is a pointer to an array of integers. The specific arrays that they point to depend on the arguments passed to the add_to_array() function when it is called. For example, if add_to_array(trend_top_values, trend_top_posisiton, pivothigh) is called, then apointer1 would point to the tval array and apointer2 would point to the tpos array.
'bottom_lines' (short for "Bottom Lines") is an array in the script that stores the line objects for the downward trend lines that are drawn on the chart. Each element of the array corresponds to a different trend line.
'top_lines' (short for "Top Lines") is an array in the script that stores the line objects for the upward trend lines that are drawn on the chart. Each element of the array corresponds to a different trend line.
Both 'bottom_lines' and 'top_lines' are arrays of type "line", which is a data type in PineScript that represents a line drawn on a chart. The line objects are created using the line.new() function and are used to draw the trend lines on the chart. The variables are used to store the line objects so that they can be manipulated and deleted later in the script.
Loops
maxline is a variable in the script that specifies the maximum number of trend lines that can be drawn on the chart. It is used to determine the size of the bottom_lines and top_lines arrays, which store the line objects for the trend lines.
The value of maxline is set to 3 at the beginning of the script, meaning that at most 3 trend lines can be drawn on the chart at a time. This value can be changed by the user if desired by modifying the assignment statement "maxline = 3".
'count_line_low' (short for "Count Line Low") is a variable in the script that keeps track of the number of downward trend lines that have been drawn on the chart. It is used to ensure that the maximum number of trend lines (as specified by the maxline variable) is not exceeded.
'count_line_high' (short for "Count Line High") is a variable in the script that keeps track of the number of upward trend lines that have been drawn on the chart. It is used to ensure that the maximum number of trend lines (as specified by the maxline variable) is not exceeded.
Both 'count_line_low' and 'count_line_high' are initialized to 0 at the beginning of the script and are incremented each time a new trend line is drawn. If either variable exceeds the value of maxline, then no more trend lines are drawn.
'pivot1', 'up_val1', 'up_val2', up1, and up2 are variables used in the loop that calculates the downward trend lines in the script. They are used to store intermediate values during the calculation process.
'pivot1' is a loop variable that is used to iterate through the pivot points (stored in the trend_bottom_values and trend_bottom_position arrays) that are being considered for use in the trend line calculation.
'up_val1' and 'up_val2' are variables that store the values of the pivot points that are used to calculate the downward trend line.
up1 and up2 are variables that store the positions (i.e., bar indices) of the pivot points that are stored in 'up_val1' and 'up_val2', respectively. These positions correspond to the locations of the pivot points on the chart.
'value1' and 'value2' are variables that are used to store the values of the pivot points that are being compared in the loop that calculates the trend lines in the script. They are used to determine whether a trend line can be drawn between the two pivot points.
For example, if 'value1' is the value of a pivot point at the top of the trend and 'value2' is the value of a pivot point at the bottom of the trend, then a trend line can be drawn between the two points if 'value1' is greater than 'value2'. The values of 'value1' and 'value2' are used in the calculation of the slope and intercept of the trend line.
'position1' and 'position2' are variables that are used to store the positions (i.e., bar indices) of the pivot points that are being compared in the loop that calculates the trend lines in the script. They are used to determine the distance between the pivot points, which is necessary for calculating the slope of the trend line.
For example, if 'position1' is the position of a pivot point at the top of the trend and 'position2' is the position of a pivot point at the bottom of the trend, then the distance between the two points is given by 'position1' - 'position2'. This distance is used in the calculation of the slope of the trend line.
'different', 'high_line', 'low_location', 'low_value', and 'valid' are variables that are used in the loop that calculates the downward trend lines in the script. They are used to store intermediate values during the calculation process.
'different' is a variable that stores the slope of the downward trend line being calculated. It is calculated as the difference in value between the two pivot points (stored in up_val1 and up_val2) divided by the distance between the pivot points (calculated using their positions, stored in up1 and up2).
'high_line' is a variable that stores the current value of the trend line being calculated at a given point in the loop. It is initialized to the value of the second pivot point (stored in up_val2) and is updated on each iteration of the loop using the value of different.
'low_location' is a variable that stores the position (i.e., bar_index) on the chart of the point where the trend line being calculated first touches the low price. It is initialized to the position of the second pivot point (stored in up2) and is updated on each iteration of the loop if the trend line touches a lower low.
'low_value' is a variable that stores the value of the trend line at the point where it first touches the low price. It is initialized to the value of the second pivot point (stored in up_val2) and is updated on each iteration of the loop if the trend line touches a lower low.
'valid' is a Boolean variable that is used to indicate whether the trend line being calculated is valid. It is initialized to true and is set to false if the trend line does not pass through all the lows between the pivot points. If valid is still true after the loop has completed, then the trend line is considered valid and is drawn on the chart.
d_value1, d_value2, d_position1, and d_position2 are variables that are used in the loop that calculates the upward trend lines in the script. They are used to store intermediate values during the calculation process.
d_value1 and d_value2 are variables that store the values of the pivot points that are used to calculate the upward trend line.
d_position1 and d_position2 are variables that store the positions (i.e., bar indices) of the pivot points that are stored in d_value1 and d_value2, respectively. These positions correspond to the locations of the pivot points on the chart.
The variables d_value1, d_value2, d_position1, and d_position2 have the same function as the variables uv1, uv2, up1, and up2, respectively, but for the calculation of the upward trend lines rather than the downward trend lines. They are used in a similar way to store intermediate values during the calculation process.
thank you.
Stoch/RSI with EMA50 Cross & HHLLA hybrid but simple indicator that plots 4 strategies in one pane .
1) RSI Indicator
2) Stoch RSI
3) EMA50 Cross (To determine direction in current timeframe)
4) Higher Highs & Lower Lows to analyze the trend and break of trend
The relative strength index (RSI) is a momentum indicator used in technical analysis. It is displayed as an oscillator (a line graph) on a scale of zero to 100. When the RSI indicator crosses 30 on the RSI chart, it is a bullish sign and when it crosses 70, it is a bearish sign.
The Stochastic RSI (StochRSI) is also a momentum indicator used in technical analysis. It is displayed as an oscillator (a line graph) on a scale of zero to 100. When the StochRSI indicator crosses 20 on the RSI chart, it is a bullish sign and when it crosses 80, it is a bearish sign.
The EMA50Cross denotes two cases in the script:
a) A crossover of CMP on the EMA50 is highlighted by a green bar signals a possible bullish trend
b) A crossunder of CMP on the EMA50 is highlighted by a red bar signals a possible bearish trend
The HHLL is denoted by mneumonics HH, HL,LH, LL. A combination of HHs and HLs denotes a uptrend while the combination of LLs and LHs denoted a downtrend
The current script should be used in confluence of other trading strategies and not in isolation.
Scenario 1:
If a EMA50Cross over bar (GREEN) is highlighted with the StochRSI below 20 and the given script is plotting HHs and HLs, we are most likely in a bullish trend for the given timeframe and a long can be initiated in confluence with other trading strategies used by the user. The RSI signal may now be utilized to determine a good range of entry/exit.
Scenario 2:
If a EMA50Cross under bar (RED) is highlighted with the StochRSI above 80 and the given script is plotting LLs and LHs, we are most likely in a bearish trend for the given timeframe and a short can be initiated in confluence with other trading strategies used by the user. The RSI signal may now be utilized to determine a good range of entry/exit.
Disclaimer:
The current script should be used in confluence with other trading strategies and not in isolation. The scripts works best on 4H and 1D Timeframes and should be used with caution on lower timeframes.
This indicator is not intended to give exact entry or exit points for a trade but to provide a general idea of the trend & determine a good range for entering or exiting the trade. Please DYOR
Credit & References:
This script uses the default technical analysis reference library provided by PineScript (denoted as ta)
MTFindicatorsQuite recently TradingView added the possibility to create and use Libraries in PineScript. With this feature PineScript became higher quality of coding language overnight. Libraries enable splitting your code into multiple files, providing easier access to code reusability.
I was working on a script which included 3000 lines of code, which was recompiling 1:30 min, and recalculating over 1 minute as well. So I split it into 2 parts: main part + library containing "main logic", which I reuse in variety of scripts, but don't change too often. Result? Now recompilation of my main script takes 10 and recalculation 8 seconds!!!. I instantly fell in love with libraries.
Having said that, and being dedicated hater of security() calls, I have decided to publish a library of MTF indicators created with my own approach: "dig into formula". I have explained reasons for such approach in desription to this script:
So this library script will be a set of indicators reaching to higher timeframes. Just include one line at the beginning of the script you are creating:
import Peter_O/MTFindicators/1 as LIB
and then somewhere is the code add this line:
rsimtf=LIB.rsi_mtf(close,5,14)
All of a sudden you have access to rsimtf from 5x higher timeframe without any hassle :)
I start with RSI MTF, next ones will be ADX, Stochastic and some more. I will update this library with them here as well. Feel free to request particular indicators in comments. Maybe PSAR? Maybe Bollinger Bands?
Exponential MA Channel, Daily Timeframe (Crypto)Moving averages are some of the most common tools for traders. Some of the most widely used ones are simple moving averages (e.g. 20SMA, 50 SMA, 100 SMA, 200SMA,...). There are endless combinations of moving averages that can be used. I prefer to use exponential moving averages because they react more quickly to price data (essentially they filter back through the data over a discrete number of timesteps, with more recent history receiving the highest weighting in the final calculation).
This script uses a combination of the 21EMA, 53 EMA, and 100EMA. The idea of this script is to provide insight into when an asset might be close to a local top/bottom by monitoring price within the middle channel (yellow, blue, and orange lines), as well as identifying longer timeframe opportunities to buy/sell by examining the upper (green) and lower (red) bands. Disclaimer: this is not a guarantee that if price enters a region, that it will be a top or bottom, it is simply an indicator to get an idea based on price history.
As far as I know, this particular combination of exponential moving averages has not yet been published. I do not have an infinite amount of time to check through the entire library of published scripts. If someone else has already done this, I was unaware. Numerical computations were performed on ETHBTC price data in order to find the coefficients used in this script. Essentially, each EMA has a multiplier of either 1, a fraction of 1, or a number larger than 1 (these are the numbers in the script being multiplied by 'out1', 'out2', 'out3'; feel free to change these and see how this changes the indicator). I have found it to be useful for myself, and hope other people can tinker with this idea. My only wish is to allow other people to use this starting point to explore for themselves. I hope that I am allowed to publish this script without it being taken down so that others can freely use it.
Recommendations: although this was fit specifically for ETHBTC, it appears useful for many crypto pairs, specifically alt-BTC pairs and crypto-USD pairs. For example, I have found it useful for BTCUSD, ETHUSD, LINKUSD, LINKBTC, ETHBTC, ADABTC, etc. Only use on the DAILY timeframe.
How to use Leverage and Margin in PineScriptEn route to being absolutely the best and most complete trading platform out there, TradingView has just closed 2 gaps in their PineScript language.
It is now possible to create and backtest a strategy for trading with leverage.
Backtester now produces Margin Calls - so recognizes mid-trade drawdown and if it is too big for the broker to maintain your trade, some part of if will be instantly closed.
New additions were announced in official blogpost , but it lacked code examples, so I have decided to publish this script. Having said that - this is purely educational stuff.
█ LEVERAGE
Let's start with the Leverage. I will discuss this assuming we are always entering trades with some percentage of our equity balance (default_qty_type = strategy.percent_of_equity), not fixed order quantity.
If you want to trade with 1:1 leverage (so no leverage) and enter a trade with all money in your trading account, then first line of your strategy script must include this parameter:
default_qty_value = 100 // which stands for 100%
Now, if you want to trade with 30:1 leverage, you need to multipy the quantity by 30x, so you'd get 30 x 100 = 3000:
default_qty_value = 3000 // which stands for 3000%
And you can play around with this value as you wish, so if you want to enter each trade with 10% equity on 15:1 leverage you'd get default_qty_value = 150.
That's easy. Of course you can modify this quantity value not only in the script, but also afterwards in Script Settings popup, "Properties" tab.
█ MARGIN
Second newly released feature is Margin calculation together with Margin Calls. If the market goes against your trades and your trading account cannot maintain mid-trade drawdown - those trades will be closed in full or partly. Also, if your trading account cannot afford to open more trades (pyramiding those trades), Margin mechanism will prevent them from being entered.
I will not go into details about how Margin calculation works, it was all explainged in above mentioned blogpost and documentation .
All you need to do is to add two parameters to the opening line of your script:
margin_long = 1./30*50, margin_short = 1./30*50
Whereas "30" is a leverage scale as in 30:1, and "50" stands for 50% of Margin required by your broker. Personally the Required Margin number I've met most often is 50%, so I'm using value 50 here, but there are literally 1000+ brokers in this world and this is individual decision by each of them, so you'd better ask yourself.
--------------------
Please note, that if you ever encounter a strategy which triggers Margin Call at least once, then it is probably a very bad strategy. Margin Call is a last resort, last security measure - all the risks should be calculated by the strategy algorithm before it is ever hit. So if you see a Margin Call being triggred, then something is wrong with risk management of the strategy. Therefore - don't use it!
