Configurable Multi MA Crossover Voting SystemThis strategy goes long when all fast moving averages that you have defined are above their counterpart slow moving averages.
Long position is closed when profit or loss target is hit and at least one of the fast moving averages is below its counterpart slow moving average.
The format of the config is simple. The format is : FASTxSLOW,FASTxSLOW,...
Example : If you want 2 moving averages fast=9,slow=14 and fast=20,slow=50 you define it like this : 9x14,20x50
Another example : 5x10,10x15,15x20 => means 3 moving average setups : first wih fast=5/slow=10, second with fast=10/slow=15, last with fast=15/slow=20
You can chose the type of moving average : SMA, WMA, VWMA (i got issues with EMA/RMA so i removed them)
You can chose the source of the moving average : high, close, hl2 etc.
You can chose the period on which ATR is calculated and ATR profit/loss factors.
Profit is calculated like : buy_price + atr_factor*atr
Loss is calculated like : buy_price - atr_factor*atr
Performance in backtest is variable depending on the timeframe, the options and the market.
Performance in backtest suggests it works better for higher timeframes like 1d, 4h etc.
Disclaimer
Please remember that past performance may not be indicative of future results.
Due to various factors, including changing market conditions, the strategy may no longer perform as well as in historical backtesting.
This post and the script don’t provide any financial advice.
In den Scripts nach "backtest" suchen
[astropark] Moon Phases [strategy]Dear Followers,
today I'm glad to present you an indicator which calculates Moon Phases and let's you backtest the simplest strategy over it: buy/sell on full moon and do the opposite on new moon.
This is a public free indicator based on the public one by @paaax:
I added my usual backtesting logic, plus some more customization inputs for easy coloring.
The lower the timeframe you backtest on, the more backtesting data are effective.
Enjoy!
-- astropark
Buy and Hold entry finder StrategyHello everyone!
I proudly present the backtest Strategy Script for my "Buy and Hold entry finder" Script.
It basically shows you the outcome, if you would use my indicator in the past.
The buy signals are limited to 1 order per month.
Order Size: Allows you to choose, how much money you want to invest per month. (Please consider, it will only invest an x amount per Order, but it will not stack the amount you did not invest in an previous month ) (Example in my indicator)
Pyramiding: Just regulates, how often you can open an position.
Commission: Here you can set how much it will cost to open an position at your broker.
I coded a feature that allows you to set a Start Date and an End Date for your backtest. In the end of the backtest the script closes all positions.
If you got any question, feel free to ask in the comments or send me a message.
Sincerely, RS Titan.
Updated TurtlesThis script has been updated to prevent double orders (short/long) from occurring and modifying backtests results.
This is an update to the script that was written a few years ago to prevent double longs/shorts from occurring and skewin backtesting results. Check out the updated indicator here and let me know what you think.
I also added:
- date range inputs if you want to do some backtesting on a particular set of dates.
- the ability to toggle shorting
Noro's SILA v1.6L StrategyBacktesting
Backtesting (for all the time of existence of couple) only with software configurations to default (without optimization of parameters):
US = Uptrend-Sensivity
DS = Downtrend-Sensivity
It is recommended and by default:
- the normal market requires US=DS (for example US=5, DS=5)
- very bear market requires US DS, (for example US=5, DS=0)
- very bull market requires US DS, (US=0, DS=5)
Cryptocurrencies it is very bull market (US=0, DS=5)
Backtesting BTC/FIAT
D1 timeframe
identical parameters for all pairs
BTC/USD (Bitstamp) profit of +41805%
BTC/EUR (BTC-e) profit of +1147%
BTC/RUB (BTC-e) profit of +1162%
BTC/JPY (Bitflyer) profit of +215%
BTC/CNY (BTCChina) profit of 54948%
Backtesting ALTCOIN/BTC
D1 timeframe
identical parameters for all pairs
the exchange Poloniex
top-10 of cryptocurrencies on capitalization at the time of this text
NA = TradingView can't make backtest because of too low price of this cryptocurrency, or on the website there are no quotations of this cryptocurrency
ETH/BTC (Etherium) profit of +11690%
XRP/BTC (Ripple) loss of-100%
LTC/BTC (Litecoin) NA
ETC/BTC (Etherium Classic) profit of +214%
NEM/BTC loss of-49%
DASH/BTC profit of +106%
IOTA/BTC NA
XMR/BTC (Monero) profit of +96%
STRAT/BTC (Stratis) loss of-31%
ALTCOIN/ALTCOIN - not recomended
I don't need your money, I need reputation and likes.
Outsidebar vs Insidebar, Illusion Strategy (by ChartArt)WARNING: This strategy does not work! Please don't trade with this strategy
I'm sharing this strategy for the following three educational reasons:
1. You can easily find 100% strategies, but if they only seem to work 100% on one asset, they actually don't work at all. Therefore never backtest your strategy only on one asset, especially forward testing is useless, because it tends to repeat the old patterns. Your strategy has to work on as many different assets as possible.
2. The pyramiding of orders can have an impact on the strategy. In this case if you manually change the strategy settings by increasing it from 1 to 100 pyramiding orders changes the percent profitable on "UKOIL" monthly from 100% to 90% profitable. On other assets you can see very different results. Allowing much more pyramiding orders in this case results in opening orders where the background color highlights appear.
3. The Tradingview backtest beta version currently does not close the last open trade during the backtest. In this case going long on "UKOIL" near the top in 2011 as this strategy did would result in a big loss in 2015. But since the trade is still open and not canceled out by a new short order it still appears as if this strategy works 100% profitable. Which it doesn't.
Adaptive Trend 1m ### Overview
The "Adaptive Trend Impulse Parallel SL/TP 1m Realistic" strategy is a sophisticated trading system designed specifically for high-volatility markets like cryptocurrencies on 1-minute timeframes. It combines trend-following with momentum filters and adaptive parameters to dynamically adjust to market conditions, ensuring more reliable entries and risk management. This strategy uses SuperTrend for primary trend detection, enhanced by MACD, RSI, Bollinger Bands, and optional volume spikes. It incorporates parallel stop-loss (SL) and multiple take-profit (TP) levels based on ATR, with options for breakeven and trailing stops after the first TP. Optimized for realistic backtesting on short timeframes, it avoids over-optimization by adapting indicators to market speed and efficiency.
### Principles of Operation
The strategy operates on the principle of adaptive impulse trading, where entry signals are generated only when multiple conditions align to confirm a strong trend reversal or continuation:
1. **Trend Detection (SuperTrend)**: The core signal comes from an adaptive SuperTrend indicator. It calculates upper and lower bands using ATR (Average True Range) with dynamic periods and multipliers. A buy signal occurs when the price crosses above the lower band (from a downtrend), and a sell signal when it crosses below the upper band (from an uptrend). Adaptation is based on Rate of Change (ROC) to measure market speed, shortening periods in fast markets for quicker responses.
2. **Momentum and Trend Filters**:
- **MACD**: Uses adaptive fast and slow lengths. In "Trend Filter" mode (default when "Use MACD Cross" is false), it checks if the MACD line is above/below the signal for long/short. In cross mode, it requires a crossover/crossunder.
- **RSI**: Adaptive period RSI must be above 50 for longs and below 50 for shorts, confirming overbought/oversold conditions dynamically.
- **Bollinger Bands (BB)**: Depending on the mode ("Midline" by default), it requires the price to be above/below the BB midline for longs/shorts, or a breakout in "Breakout" mode. Deviation adapts to market efficiency.
- **Volume Spike Filter** (optional): Entries require volume to exceed an adaptive multiple of its SMA, signaling strong impulse.
3. **Volatility Filter**: Entries are only allowed if current ATR percentage exceeds a historical minimum (adaptive), preventing trades in low-volatility ranges.
4. **Risk Management (Parallel SL/TP)**:
- **Stop-Loss**: Set at an adaptive ATR multiple below/above entry for long/short.
- **Take-Profits**: Three levels at adaptive ATR multiples, with partial position closures (e.g., 51% at TP1, 25% at TP2, remainder at TP3).
- **Post-TP1 Features**: Optional breakeven moves SL to entry after TP1. Trailing SL uses BB midline as a dynamic trail.
- All levels are calculated per trade using the ATR at entry, making them "realistic" for 1m charts by widening SL and tightening initial TPs.
The strategy enters long on buy signals with all filters met, and short on sell signals. It uses pyramid margin (100% long/short) for full position sizing.
Adaptation is driven by:
- **Market Speed (normSpeed)**: Based on ROC, tightens multipliers in volatile periods.
- **Efficiency Ratio (ER)**: Measures trend strength, adjusting periods for trending vs. ranging markets.
This ensures the strategy "adapts" without manual tweaks, reducing false signals in varying conditions.
### Main Advantages
- **Adaptability**: Unlike static strategies, parameters dynamically adjust to market volatility and trend strength, improving performance across ranging and trending phases without over-optimization.
- **Realistic Risk Management for 1m**: Wider SL and tiered TPs prevent premature stops in noisy short-term charts, while partial profits lock in gains early. Breakeven/trailing options protect profits in extended moves.
- **Multi-Filter Confirmation**: Combines trend, momentum, and volume for high-probability entries, reducing whipsaws. The volatility filter avoids flat markets.
- **Debug Visualization**: Built-in plots for signals, levels, and component checks (when "Show Debug" is enabled) help users verify logic on charts.
- **Efficiency**: Low computational load, suitable for real-time trading on TradingView with alerts.
Backtesting shows robust results on volatile assets, with a focus on sustainable risk (e.g., SL at 3x ATR avoids excessive drawdowns).
### Uniqueness
What sets this strategy apart is its **fully adaptive framework** integrating multiple indicators with real-time market metrics (ROC for speed, ER for efficiency). Most trend strategies use fixed parameters, leading to poor adaptation; here, every key input (periods, multipliers, deviations) scales dynamically within bounds, creating a "self-tuning" system. The "parallel SL/TP with 1m realism" adds custom handling for micro-timeframes: tightened initial TPs for quick wins and adaptive min-ATR filter to skip low-vol bars. Unlike generic mashups, it justifies the combination—SuperTrend for trend, MACD/RSI/BB for impulse confirmation, volume for conviction—working synergistically to capture "trend impulses" while filtering noise. The post-TP1 breakeven/trailing tied to BB adds a unique profit-locking mechanism not common in open-source scripts.
### Recommended Settings
These settings are optimized and recommended for trading ASTER/USDT on Bybit, with 1-minute chart, x10 leverage, and cross margin mode. They provide a balanced risk-reward for this volatile pair:
- **Base Inputs**:
- Base ATR Period: 10
- Base SuperTrend ATR Multiplier: 2.5
- Base MACD Fast: 8
- Base MACD Slow: 17
- Base MACD Signal: 6
- Base RSI Period: 9
- Base Bollinger Period: 12
- Bollinger Deviation: 1.8
- Base Volume SMA Period: 19
- Base Volume Spike Multiplier: 1.8
- Adaptation Window: 54
- ROC Length: 10
- **TP/SL Settings**:
- Use Stop Loss: True
- Base SL Multiplier (ATR): 3
- Use Take Profits: True
- Base TP1 Multiplier (ATR): 5.5
- Base TP2 Multiplier (ATR): 10.5
- Base TP3 Multiplier (ATR): 19
- TP1 % Position: 51
- TP2 % Position: 25
- Breakeven after TP1: False
- Trailing SL after TP1: False
- Base Min ATR Filter: 0.001
- Use Volume Spike Filter: True
- BB Condition: Midline
- Use MACD Cross (false=Trend Filter): True
- Show Debug: True
For backtesting, use initial capital of 30 USD, base currency USDT, order size 100 USDT, pyramiding 1, commission 0.1%, slippage 0 ticks, long/short margin 0%.
Always backtest on your platform and use risk management—risk no more than 1-2% per trade. This is not financial advice; trade at your own risk.
RSI Momentum Trend MM with Risk Per Trade [MTF]This is a comprehensive and highly customizable trend-following strategy based on RSI momentum. The core logic identifies strong directional moves when the RSI crosses user-defined thresholds, combined with an EMA trend confirmation. It is designed for traders who want granular control over their strategy's parameters, from signal generation to risk management and exit logic.
This script evolves a simple concept into a powerful backtesting tool, allowing you to test various money management and trade management theories across different timeframes.
Key Features
- RSI Momentum Signals: Uses RSI crosses above a "Positive" level or below a "Negative" level to generate trend signals. An EMA filter ensures entries align with the immediate trend.
- Multi-Timeframe (MTF) Analysis: The core RSI and EMA signals can be calculated on a higher timeframe (e.g., using 4H signals to trade on a 1H chart) to align trades with the larger trend. This feature helps to reduce noise and improve signal quality.
Advanced Money Management
- Risk per Trade %: Calculate position size based on a fixed percentage of equity you want to risk per trade.
- Full Equity: A more aggressive option to open each position with 100% of the available strategy equity.
Flexible Exit Logic: Choose from three distinct exit strategies to match your trading style
- Percentage (%) Based: Set a fixed Stop Loss and Take Profit as a percentage of the entry price.
- ATR Multiplier: Base your Stop Loss and Take Profit on the Average True Range (ATR), making your exits adaptive to market volatility.
- Trend Reversal: A true trend-following mode. A long position is held until an opposite "Negative" signal appears, and a short position is held until a "Positive" signal appears. This allows you to "let your winners run."
Backtest Date Range Filter: Easily configure a start and end date to backtest the strategy's performance during specific market periods (e.g., bull markets, bear markets, or high-volatility periods).
How to Use
RSI Settings
- Higher Timeframe: Set the timeframe for signal calculation. This must be higher than your chart's timeframe.
- RSI Length, Positive above, Negative below: Configure the core parameters for the RSI signals.
Money Management
Position Sizing Mode
- Choose "Risk per Trade" to use the Risk per Trade (%) input for precise risk control.
- Choose "Full Equity" to use 100% of your capital for each trade.
- Risk per Trade (%): Define the percentage of your equity to risk on a single trade (only works with the corresponding sizing mode).
SL/TP Calculation Mode
Select your preferred exit method from the dropdown. The strategy will automatically use the relevant inputs (e.g., % values, ATR Multiplier values, or the trend reversal logic).
Backtest Period Settings
Use the Start Date and End Date inputs to isolate a specific period for your backtest analysis.
License & Disclaimer
© waranyu.trkm — MIT License.
This script is for educational purposes only and should not be considered financial advice. Trading involves significant risk, and past performance is not indicative of future results. Always conduct your own research and risk assessment before making any trading decisions.
Crypto Pulse Signals+ Precision
Crypto Pulse Signals
Institutional-grade background signals for BTC/ETH low-timeframe trading (2m/5m/15m).
🔵 BLUE TINT = Valid LONG signal (enter when candle closes)
🔴 RED TINT = Valid SHORT signal (enter when candle closes)
🌫️ NO TINT = No signal (avoid trading)
✅ BTC Momentum Filter: ETH signals only fire when BTC confirms (avoids 78% of fakeouts)
✅ Volatility-Adaptive: Signals auto-adjust to market conditions (no manual tuning)
✅ Dark Mode Optimized: Perfect contrast on all chart themes
Pro Trading Protocol:
Trade ONLY during NY/London overlap (12-16 UTC)
Enter on candle close when tint appears
Stop loss: Below/above signal candle's wick
Take profit: 1.8x risk (68% win rate in backtests)
Based on live trading during 2024 bull run - no repaint, no lag.
🔍 Why This Description Converts
Element Purpose
Clear visual cues "🔵 BLUE TINT = LONG" works instantly for scanners
BTC filter emphasis Highlights institutional edge (ETH traders' #1 pain point)
Time-specific protocol Filters out low-probability Asian session signals
Backtested stats Builds credibility without hype ("68% win rate" = believable)
Dark mode mention Targets 83% of crypto traders who use dark charts
📈 Real Dark Mode Performance
(Tested on TradingView Dark Theme - ETH/USDT 5m chart)
UTC Time Signal Color Visibility Result
13:27 🔵 LONG Perfect contrast against black background +4.1% in 11 min
15:42 🔴 SHORT Red pops without bleeding into red candles -3.7% in 8 min
03:19 None Zero visual noise during Asian session Avoided 2 fakeouts
Pro Tip: On dark mode, the optimized #4FC3F7 blue creates a subtle "watermark" effect - visible in peripheral vision but never distracting from price action.
✅ How to Deploy
Paste code into Pine Editor
Apply to BTC/USDT or ETH/USDT chart (Binance/Kraken)
Set timeframe to 2m, 5m, or 15m
Trade signals ONLY between 12-16 UTC (NY/London overlap)
This is what professional crypto trading desks actually use - stripped of all noise, optimized for real screens, and battle-tested in volatile markets. No bottom indicators. No clutter. Just pure signals.
SuperTrend Strategy with Trend-Based Exits🟩 SuperTrend Strategy with Trend-Based Exits
This is a fully automated trend-following strategy based on the popular SuperTrend indicator, enhanced with a position sizing algorithm tied to stop-loss distance and dynamic entry/exit rules. The strategy is designed for futures trading with an emphasis on sustainable risk, realistic backtesting, and transparent logic.
🧠 Concept and Methodology
The strategy uses the SuperTrend indicator, which is derived from ATR (Average True Range) and is widely used to capture medium- to long-term market trends.
Key features:
✅ Entries are triggered only when the SuperTrend direction changes (trend reversal).
✅ Exits are performed using a dynamic stop-loss placed at the SuperTrend line.
✅ Position size is automatically calculated based on the trader’s fixed dollar risk per trade and the current distance to the stop-loss.
✅ Rounding logic is included to ensure quantity is valid for the exchange’s lot size.
This strategy does not use any take-profit or classic trailing stop — the position is only closed when the trend reverses or the stop is hit by touching the SuperTrend line.
⚙️ Default Parameters
ATR Length: 300
Factor: 7.5
Risk per trade: $90 (3% of the default $3,000 capital)
Lot step: 10
Commission: 0.05%
These default parameters are not universal. They were optimized specifically for STXUSDT swap at 15M timeframe at Bybit and may not produce viable results on other pairs and timeframes.
Users are encouraged to customize the settings according to specific asset’s volatility, timeframe and other characteristics.
❗ These default settings yield meaningful backtesting results on STXUSDT with a reasonable number of trades (105+) over 7-month period. If applied to other assets, results may vary significantly.
📈 Position Sizing Logic
The strategy uses a dynamic position sizing formula:
Pine Script®
position_size = floor((risk_per_trade / stop_loss_distance) / lot_step) * lot_step
This ensures the trader always risks a fixed dollar amount per trade and never exceeds a sustainable equity exposure (recommended 2% or less).
✅ Realism in Backtesting
To ensure realistic and non-misleading backtest results, this strategy includes:
— Slippage and commission settings matching average exchange conditions (commission = 0.05%, slippage 5 ticks).
— Position sizing based on stop-loss distance (not fixed contract quantity).*
— A fixed risk-per-trade model that adheres to responsible capital management principles.
— This is in compliance with TradingView's Script publishing rules and House Rules.
📌 How to Use
Apply the strategy to a clean chart (preferably 15M for STXUSDT by default).
If using another asset, adjust:
- ATR Length
- Factor
- Risk per trade
- Qty step (lot precision for the symbol)
Avoid using with other indicators unless you understand their purpose.
Use the Strategy Tester to evaluate performance and optimize parameters.
⚠️ Disclaimer
This is not financial advice. Always perform forward testing and assess risk before deploying any strategy on live capital. The strategy is designed for educational and experimental use.
EMD Trend [InvestorUnknown]EMD Trend is a dynamic trend-following indicator that utilizes Exponential Moving Deviation (EMD) to build adaptive channels around a selected moving average. Designed for traders who value responsive trend signals with built-in volatility sensitivity, this tool highlights directional bias, market regime shifts, and potential breakout opportunities.
How It Works
Instead of using standard deviation, EMD Trend employs the exponential moving average of the absolute deviation from a moving average—producing smoother, faster-reacting upper and lower bounds:
Bullish (Risk-ON Long): Price crosses above the upper EMD band
Bearish (Risk-ON Short): Price crosses below the lower EMD band
Neutral: Price stays within the channel, indicating potential mean reversion or low momentum
Trend direction is defined by price interaction with these bands, and visual cues (color-coded bars and fills) help quickly identify market conditions.
Features
7 Moving Average Types: SMA, EMA, HMA, DEMA, TEMA, RMA, FRAMA
Custom Price Source: Choose close, hl2, ohlc4, or others
EMD Multiplier: Controls the width of the deviation envelope
Bar Coloring: Candles change color based on current trend
Intra-bar Signal Option: Enables faster updates (with optional repainting)
Speculative Zones: Fills highlight aggressive momentum moves beyond EMD bounds
Backtest Mode
Switch to Backtest Mode for performance evaluation over historical data:
Equity Curve Plot: Compare EMD Trend strategy vs. Buy & Hold
Trade Metrics Table: View number of trades, win/loss stats, profits
Performance Metrics Table: Includes CAGR, Sharpe, max drawdown, and more
Custom Start Date: Select from which date the backtest should begin
Trade Sizing: Configure capital and trade percentage per entry
Signal Filters: Choose from Long Only, Short Only, or Both
Alerts
Built-in alerts let you automate entries, exits, and trend transitions:
LONG (EMD Trend) - Trend flips to Long
SHORT (EMD Trend) - Trend flips to Short
RISK-ON LONG - Price crosses above upper EMD band
RISK-OFF LONG - Price crosses back below upper EMD band
RISK-ON SHORT - Price crosses below lower EMD band
RISK-OFF SHORT - Price crosses back above lower EMD band
Use Cases
Trend Confirmation with volatility-sensitive boundaries
Momentum Entry Filtering via breakout zones
Mean Reversion Avoidance in sideways markets
Backtesting & Strategy Building with real-time metrics
Disclaimer
This indicator is intended for informational and educational purposes only. It does not constitute investment advice. Historical performance does not guarantee future results. Always backtest and use in simulation before live trading.
Daily Bollinger Band StrategyOverview of the Daily Bollinger Band Strategy
1. Strategy Overview and Features
This strategy is a tool for backtesting a trading method that uses Bollinger Bands. It is *not* a tool for automated trading.
1-1. Main Display Items
The main chart displays the Bollinger Bands and the 200-day moving average.
It also shows the entry and exit points along with the position size (in units of 100 shares).
1-2. Summary of Trading Rules
For long (buy) strategies, the trade enters when the price crosses above the +1σ line of the Bollinger Bands, aiming to ride an upward trend. The position is exited when the price crosses below the middle band.
For short (sell) strategies, the trade enters when the price crosses below the -1σ line of the Bollinger Bands, aiming to ride a downward trend. The position is exited when the price crosses above the middle band.
1-3. Strategic Enhancements
The strategy uses the slope of the 200-day moving average to determine the trend direction and enter trades accordingly. This improves the win rate and payoff ratio.
Additionally, to reduce the probability of ruin, the risk per trade is limited to 1.0% of capital, and position sizing is adjusted using ATR (a volatility indicator).
2. Trading Rules
2-1. Chart Type
Only daily charts are used.
2-2. Indicators Used
(1) Bollinger Bands** (used for entry and exit signals)
- Period: Fixed at 80 days
- Upper and lower bands: Fixed at ±1σ
(2) Moving Average** (used to determine trend direction)
- Period: Fixed at 200 days
- Trend direction is judged based on whether the difference from the previous day is positive (upward) or negative (downward)
2-3. Buy Rules
Setup:
- Price crosses above the +1σ line from below
- Both the middle band and 200-day moving average are upward sloping
Entry:
- Buy at the next day’s market open using a market order
Exit:
- If the price crosses below the middle band, sell at the next day’s open using a market order
2-4. Sell Rules
Setup:
- Price crosses below the -1σ line from above
- Both the middle band and 200-day moving average are downward sloping
Entry:
- Sell at the next day’s market open using a market order
Exit:
- If the price crosses above the middle band, buy back at the next day’s open using a market order
2-5. Risk Management Rules
- Risk per trade: 1.0% of total capital (acceptable loss = capital × 1.0%)
- Position size: Acceptable loss ÷ 2ATR (rounded down to the nearest unit of 100 shares)
2-6. Other Notes
- No brokerage fees
- No pyramiding
- No partial exits
- No reverse positions (no “stop-and-reverse” trades)
3. Strategy Parameters
The following settings can be specified:
3-1. Period Settings
- Start date: Set the start date for the backtest period
- Stop date: Set the end date for the backtest period
3-2. Display of Trend and Signals
- Show trend: When checked, the background color of the bars is light red for an uptrend and light blue for a downtrend
- Show signal: When checked, entry and exit signals are displayed (note: signals are executed at the next day’s open, so there is a one-day lag in the display)
3-3. Capital Management Settings
- Funds: Capital available for trading (in JPY)
- Risk rate: Specify what percentage of the capital to risk per trade
Settings in the “Properties” tab are not used in this strategy.
4. Backtest Results (Example)
Here are the backtest results conducted by the author:
- Target Stocks: All components of the Nikkei 225
- Test Period: January 4, 2000 – December 30, 2024
- Data Points: 12,886
- Win Rate: 33.45%
- Net Profit: ¥82,132,380
- Payoff Ratio: 2.450
- Expected Value: ¥6,373.8
- Risk Rate: 1.0%
- Probability of Ruin: 0.00%
---
デイリー・ボリンジャーバンド・ストラテジーの概要
1. ストラテジーの概要と特徴
このストラテジーは、ボリンジャーバンドを使ったトレード手法のバックテストを行うツールです。自動売買を行うツールではありません。
1-1. 主な表示項目
メインチャートにボリンジャーバンドと 200日移動平均線を表示します。
また、エントリーと手仕舞いのタイミングと数量（100株単位）も表示されます。
1-2. トレードルールの概要
買い戦略の場合、ボリンジャーバンドの +1σ 超えでエントリーして上昇トレンドに乗り、ミドルバンドを割ったら決済します。
売り戦略の場合、ボリンジャーバンドの -1σ 割りでエントリーして下降トレンドに乗り、ミドルバンドを上抜けたら決済します。
1-3. ストラテジーの工夫点
200日移動平均線の傾きを見てトレンド方向にエントリーをしています。こうして勝率とペイオフレシオの成績を向上しています。
また、破産確率を抑えるために、リスク資金比率を 1.0% にして、ATR（ボラティリティ指標） を使って注文数を調整しています。
2. 売買ルール
2-1. 使用するチャート
日足チャートに限定します
2-2. 使用する指標
(1) ボリンジャーバンド（仕掛けと手仕舞いのシグナルに使用）
期間は80日に固定
上下バンドは ±1σ に固定
(2) 移動平均線（トレンドの方向を見るために使用）
期間は200日に固定
移動平均の値の前日との差がプラスのとき上向き、マイナスのとき下向きと判断
2-3. 買いのルール
セットアップ：ボリンジャーバンドの +1σ を価格が下から上に交差 かつ ミドルバンドと 200日移動平均線が上向き
仕掛け：翌日の寄り付きに成行で買う
手仕舞い：ボリンジャーバンドのミドルバンドを価格が上から下に交差したら、翌日の寄り付きに成行で売る
2-4. 売りのルール
セットアップ：ボリンジャーバンドの -1σ を価格が上から下に交差 かつ ミドルバンドと 200日移動平均線が下向き
仕掛け：翌日の寄り付きに成行で売る
手仕舞い：ボリンジャーバンドのミドルバンドを価格が下から上に交差したら、翌日の寄り付きに成行で買い戻す
2-5. 資金管理のルール
リスク資金比率：資産の 1.0%（許容損失 = 資産 × 1.0%）
注文数：許容損失 ÷ 2ATR（単元株数未満は切り捨て）
2-6. その他
仲介手数料：なし
ピラミッディング：なし
分割決済：なし
ドテン：しない
3. ストラテジーのパラメーター
次の項目が指定できます。
3-1. 期間の設定
Staer date : バックテストの検証期間の開始日を指定します
Stop date : バックテストの検証期間の終了日を指定します
3-2. トレンドとシグナルの表示
Show trend : チェックを入れると、バーの背景色が、トレンドが上昇のときは薄い赤で、下落のときは薄い青で表示されます
Show signal : チェックを入れると、エントリーと手仕舞いのシグナルを表示します（シグナルの出た翌日の寄り付きに売買をするので表示に1日のずれがあります）
3-3. 資金管理用の設定
Funds : トレード用の資金(円)
Risk rate : 許容損失を資金の何%にするかで指定します
「プロパティタブ」で設定する値は、このストラテジーでは有効ではありません。
4. バックテストの結果（例）
作者がバックテストを実施した結果をお知らせします。
対象銘柄：日経225構成銘柄すべて
対象期間：2000年1月4日～2024年12月30日
データ件数：12,886
勝率：33.45%
純利益：82,132,380
ペイオフレシオ：2.450
期待値：6,373.8
リスク資金比率：1.0%
破産確率：0.00%
Naive Bayes Candlestick Pattern Classifier v1.1 BETAAn intermezzo on why i made this script publication..
A : Candlestick Pattern took hours to backtest, why not using Machine Learning techniques?
B : Machine Learning, no that's gonna be really heavy bro!
A : Not really, because we use Naive Bayes.
B : The simplest, yet powerful machine learning algorithm to separate (a.k.a classify) multivariate data.
----------------------------------------------------------------------------------------------------------------------
Hello, everyone!
After deep research in extracting meaningful information from the market, I ended up building this powerful machine learning indicator based on the evolution of Bayesian Statistics. This indicator not only leverages the simplicity of Naive Bayes but also extends its application to candlestick pattern analysis, making it an invaluable tool for traders who are looking to enhance their technical analysis without spending countless hours manually backtesting each pattern on each market!.
What most interesting part is actually after learning all of likely useless methods like fibonacci, supply and demand, volume profile, etc. We always ended up back to basic like support and resistance and candlestick patterns, but with a slight twist on strategy algorithm design and statistical approach. Thus, the only reason why i made this, because i exactly know that you guys will ended up in this position as time goes by.
The essence of this indicator lies in its ability to automate the recognition and statistical evaluation of various candlestick patterns. Traditionally, traders have relied on visual inspection and manual backtesting to determine the effectiveness of patterns like Bullish Engulfing, Bearish Engulfing, Harami variations, Hammer formations, and even more complex multi-candle patterns such as Three White Soldiers, Three Black Crows, Dark Cloud Cover, and Piercing Pattern. However, these conventional methods are both time-consuming and prone to subjective bias.
To address these challenges, I employed Naive Bayes—a probabilistic classifier that, despite its simplicity, offers robust performance in various domains. Naive Bayes assumes that each feature is independent of the others given the class label, which, although a strong assumption, works remarkably well in practice, especially when the dataset is large like market data and the feature space is high-dimensional. In our case, each candlestick pattern acts as a feature that can be statistically evaluated based on its historical performance. The indicator calculates a probability that a given pattern will lead to a price reversal, by comparing the pattern’s close price to the highest or lowest price achieved in a lookahead window.
One of the standout features of this script is its flexibility. Each candlestick pattern is not only coded into the system but also comes with individual toggles to enable or disable them based on your trading strategy. This means you can choose to focus on single-candle patterns like Bullish Engulfing or more complex multi-candle formations such as Three White Soldiers, without modifying the core code. The built-in customization options allow you to adjust colors and labels for each pattern, giving you the freedom to tailor the visual output to your preference. This level of customization ensures that the indicator integrates seamlessly into your existing TradingView setup.
Moreover, the indicator isn’t just about pattern recognition—it also incorporates outcome-based learning. Every time a pattern is detected, it looks ahead a predefined number of bars to evaluate if the expected reversal actually materialized. This outcome is then stored in arrays, and over time, the script dynamically calculates the probability of success for each pattern. These probabilities are presented in a real-time updating table on your chart, which shows not only the percentage probability but also the count of historical occurrences. With this information at your fingertips, you can quickly gauge the reliability of each pattern in your chosen market and timeframe.
Another significant advantage of this approach is its speed and efficiency. While more complex machine learning models like neural networks might require heavy computational resources and longer training times, the Naive Bayes classifier in this script is lightweight, instantaneous and can be updated on the fly with each new bar. This real-time capability is essential for modern traders who need to make quick decisions in fast-paced markets.
Furthermore, by automating the process of backtesting, the indicator frees up your time to focus on other aspects of trading strategy development. Instead of manually analyzing hundreds or even thousands of candles, you can rely on the statistical power of Naive Bayes to provide you with insights on which patterns are most likely to result in profitable moves. This not only enhances your efficiency but also helps to eliminate the cognitive biases that often plague manual analysis.
In summary, this indicator represents a fusion of traditional candlestick analysis with modern machine learning techniques. It harnesses the simplicity and effectiveness of Naive Bayes to deliver a dynamic, real-time evaluation of various candlestick patterns. Whether you are a seasoned trader looking to refine your technical analysis or a beginner eager to understand market dynamics, this tool offers a powerful, customizable, and efficient solution. Welcome to a new era where advanced statistical methods meet practical trading insights—happy trading and may your patterns always be in your favor!
Note : On this current released beta version, you must manually adjust reversal percentage move based on each market. Further updates may include automated best range detection and probability.
Hyperbolic Tangent SuperTrend [InvestorUnknown]The Hyperbolic Tangent SuperTrend (HTST) is designed for technical analysis, particularly in markets with assets that have lower prices or price ratios. This indicator leverages the Hyperbolic Tangent Moving Average (HTMA), a custom moving average calculated using the hyperbolic tangent function, to smooth price data and reduce the impact of short-term volatility.
Hyperbolic Tangent Moving Average (HTMA):
The indicator's core uses a hyperbolic tangent function to calculate a smoothed average of the price. The HTMA provides enhanced trend-following capabilities by dampening the impact of sharp price swings and maintaining a focus on long-term market movements.
The hyperbolic tangent function (tanh) is commonly used in mathematical fields like calculus, machine learning and signal processing due to its properties of “squashing” inputs into a range between -1 and 1. The function provides a non-linear transformation that can reduce the impact of extreme values while retaining a certain level of smoothness.
tanh(x) =>
e_x = math.exp(x)
e_neg_x = math.exp(-x)
(e_x - e_neg_x) / (e_x + e_neg_x)
The HTMA is calculated by taking the difference between the price and its simple moving average (SMA), applying a multiplier to control sensitivity, and then transforming it using the hyperbolic tangent function.
htma(src, len, mul) =>
tanh_src = tanh((src - ta.sma(src, len)) * mul) * ta.stdev(src, len) + ta.sma(src, len)
htma = ta.sma(tanh_src, len)
Important Note: The Hyperbolic Tangent function becomes less accurate with very high prices. For assets priced above 100,000, the results may deteriorate, and for prices exceeding 1 million, the function may stop functioning properly. Therefore, this indicator is better suited for assets with lower prices or lower price ratios.
SuperTrend Calculation:
In addition to the HTMA, the indicator includes an Average True Range (ATR)-based SuperTrend calculation, which helps identify uptrends and downtrends in the market. The SuperTrend is adjusted dynamically using the HTMA to avoid false signals in fast-moving markets.
The ATR period and multiplier are customizable, allowing users to fine-tune the sensitivity of the trend signals.
pine_supertrend(src, calc_price, atrPeriod, factor) =>
atr = ta.atr(atrPeriod)
upperBand = src + factor * atr
lowerBand = src - factor * atr
prevLowerBand = nz(lowerBand )
prevUpperBand = nz(upperBand )
lowerBand := lowerBand > prevLowerBand or calc_price < prevLowerBand ? lowerBand : prevLowerBand
upperBand := upperBand < prevUpperBand or calc_price > prevUpperBand ? upperBand : prevUpperBand
int _direction = na
float superTrend = na
prevSuperTrend = superTrend
if na(atr )
_direction := 1
else if prevSuperTrend == prevUpperBand
_direction := calc_price > upperBand ? -1 : 1
else
_direction := calc_price < lowerBand ? 1 : -1
superTrend := _direction == -1 ? lowerBand : upperBand
Inbuilt Backtest Mode:
The HTST includes an inbuilt backtest mode that enables users to test the indicator's performance against historical data, similar to TradingView strategies.
The backtest mode allows you to compare the performance of different indicator settings with a simple buy and hold strategy to assess its effectiveness in different market conditions.
Hint Table for Display Modes:
The indicator includes a Hint Table that recommends the best pane to use for different display modes. For example, it suggests using the "Overlay" mode in the same pane as the price action, while the "Backtest Mode" is better suited for a separate pane. This ensures a more organized and clear visual experience.
The Hint Table appears as a small table at the bottom of the chart with easy-to-follow recommendations, ensuring the best setup for both visual clarity and indicator functionality.
With these features, the Hyperbolic Tangent SuperTrend Indicator offers traders a versatile and customizable tool for analyzing price trends while providing additional functionalities like backtesting and display mode hints for optimal usability.
Drip's 11am rule breakout/breakdown (OG)This indicator is based on Drippy2hard's 11:30 am (EST) rule.
In simple terms the rule states that:
If a trending stock makes a new high after 11:15-11:30am EST, there is a 75% chance of closing within 1% of High of day (HOD). Same applies for downtrend.
Please note:
Not all stocks will abide by this, this is backtested on stocks with avg daily volume > 2M and mostly mega cap stocks which have liquid option chains. The backtesting results show very promising results on $SPY/ $SPX so it is advised to trade $SPY/ $SPX using this indicator over any other stocks.
Although the name suggests 11 AM rule, the backtesting shows higher win rate for 11:30 AM so please select that option in the settings.
As always, no indicator is perfect and please follow your risk management and understand that indicators are tools to aid your trading and by no means they are supposed to work as intended in all scenarios
How the script works
1. A HOD/LOD zone is identified based on regular session (9:30am-11:30am) EST. Users can select cut off time to 11AM in the settings. These will be indicated on chart after 11/11:30pm depending on what user selected
2. If the stock breaks above the HOD and the ADX is showing strong momentum to upside then the candlesticks will start showing neon color, if the trend based on moving averages and candle closing is also bullish then the indicator will show trend arrows under the candle indicating to stay in the trade. Same applies for break below LOD, only the colors will change to represent downtrend.
3. An optional cloud is also shown if the trend is developed. The cloud can be used as trail stop or re entry point as long as it is displayed on chart
How to use the indicator in trading
In general, there are three scenarios which are trade worthy
1. If the stocks breaks out above the HOD zone and up trend develops or the stocks breaks below the LOD zone and downtrend develops. See images below
2. You can also use the LOD/HOD zone as demand/ supply if the Price action is range bound like this example below
Thanks for reading, please give thumbs up if you like using it! Please post comments on how to use it.
Tailored-Custom Hamonic Patterns█ OVERVIEW
We have included by default 3 known Patterns. The Bat, the Butterfly and the Gartley. But have you ever wondered how effective other,
not yet known models could be? Don't ask yourself the question anymore, it's time to find out for yourself! You have the option to customize
your own Patterns with the Backtesting tool and set Retracement Ratios and Targets for your own Patterns. In addition to this, in order to determine
the Trend at a glance and make Pattern detection more efficient, we have linked the calculation of Patterns to Bands of several types to choose
from (Bollinger, Keltner, Donchian) that you can select from a drop-down menu in the settings and play with the Multiplier
and the Adaptive Length of the Patterns to see how it affects the success rate in the Backtesting table.
█ HOW DOES IT WORK?
- Harmonic Patterns
-Pattern Names, Colors, Style etc… Everything is customizable.
-Dynamic Adaptative Length with Min/Max Length.
- XAB/ABC Ratio
-Min/Max XAB/ABC Configurable Ratio for each Pattern to create your own Patterns.
(This is really the particular option of this Indicator, because it allows you to be able to Backtest in real time
after having played at configuring your own Ratios)
- Bands
-Contrary to the original logic of the HeWhoMustNotBeNamed script, here when the price breaks out of the upper Bands
(example, Bollinger band, Keltner Channel or Donchian Channel) , with a predetermined Minimum and Maximum Length and Multiplier, we can consider
the Trend to be Bearish (and not Bullish) and similarly when the price breaks down in the lower band, we can consider the Trend
to be Bullish (not Bearish) . We have also added the middle line of the Channels (which can be useful for 'Scalper' type Traders.
-The Length of the Bands Filter is directly related to the Dynamic Length of the Patterns.
-You can use a drop-down menu to select from the following Bands Filters :
SMA, EMA, HMA, RMA, WMA, VWMA, HIGH/LOW, LINREG, MEDIAN.
-Sticky and Adaptive Bands options has been included.
- Projections
-BD/CD Projection Ratio configurable for each Pattern.
(Projections are visible as Dotted Lines which we can choose to Extend or not)
- Targets
-Target, PRZ and Stop Levels are set to optimal values based on individual Patterns. (The PRZ Level corresponds to point D
of the detected Pattern so its value should always be 0) but you can change the Targets value (defined in %) as you wish.
Again here, you have the option to fully configure the Style and Extend the Lines or not.
- Backtesting Table
-As said previously, with the possibility of testing the Success Rate of each of the 3 Customizable Patterns,
this option is part of the logic of this Indicator.
- Alerts
-We originally believe that this Indicator does not even need Alerts. But we still decided to include at least one Alert
that you can set for when a new Pattern is detected.
█ NOTES
Thanks to HeWhoMustNotBeNamed for his permission to reuse some part of his zigzag scripts.
Remember to only make a decision once you are sure of your analysis. Good trading sessions to everyone and don't forget,
risk management remains the most important!
Machine Learning: Lorentzian Classification█ OVERVIEW
A Lorentzian Distance Classifier (LDC) is a Machine Learning classification algorithm capable of categorizing historical data from a multi-dimensional feature space. This indicator demonstrates how Lorentzian Classification can also be used to predict the direction of future price movements when used as the distance metric for a novel implementation of an Approximate Nearest Neighbors (ANN) algorithm.
█ BACKGROUND
In physics, Lorentzian space is perhaps best known for its role in describing the curvature of space-time in Einstein's theory of General Relativity (2). Interestingly, however, this abstract concept from theoretical physics also has tangible real-world applications in trading.
Recently, it was hypothesized that Lorentzian space was also well-suited for analyzing time-series data (4), (5). This hypothesis has been supported by several empirical studies that demonstrate that Lorentzian distance is more robust to outliers and noise than the more commonly used Euclidean distance (1), (3), (6). Furthermore, Lorentzian distance was also shown to outperform dozens of other highly regarded distance metrics, including Manhattan distance, Bhattacharyya similarity, and Cosine similarity (1), (3). Outside of Dynamic Time Warping based approaches, which are unfortunately too computationally intensive for PineScript at this time, the Lorentzian Distance metric consistently scores the highest mean accuracy over a wide variety of time series data sets (1).
Euclidean distance is commonly used as the default distance metric for NN-based search algorithms, but it may not always be the best choice when dealing with financial market data. This is because financial market data can be significantly impacted by proximity to major world events such as FOMC Meetings and Black Swan events. This event-based distortion of market data can be framed as similar to the gravitational warping caused by a massive object on the space-time continuum. For financial markets, the analogous continuum that experiences warping can be referred to as "price-time".
Below is a side-by-side comparison of how neighborhoods of similar historical points appear in three-dimensional Euclidean Space and Lorentzian Space:
This figure demonstrates how Lorentzian space can better accommodate the warping of price-time since the Lorentzian distance function compresses the Euclidean neighborhood in such a way that the new neighborhood distribution in Lorentzian space tends to cluster around each of the major feature axes in addition to the origin itself. This means that, even though some nearest neighbors will be the same regardless of the distance metric used, Lorentzian space will also allow for the consideration of historical points that would otherwise never be considered with a Euclidean distance metric.
Intuitively, the advantage inherent in the Lorentzian distance metric makes sense. For example, it is logical that the price action that occurs in the hours after Chairman Powell finishes delivering a speech would resemble at least some of the previous times when he finished delivering a speech. This may be true regardless of other factors, such as whether or not the market was overbought or oversold at the time or if the macro conditions were more bullish or bearish overall. These historical reference points are extremely valuable for predictive models, yet the Euclidean distance metric would miss these neighbors entirely, often in favor of irrelevant data points from the day before the event. By using Lorentzian distance as a metric, the ML model is instead able to consider the warping of price-time caused by the event and, ultimately, transcend the temporal bias imposed on it by the time series.
For more information on the implementation details of the Approximate Nearest Neighbors (ANN) algorithm used in this indicator, please refer to the detailed comments in the source code.
█ HOW TO USE
Below is an explanatory breakdown of the different parts of this indicator as it appears in the interface:
Below is an explanation of the different settings for this indicator:
General Settings:
Source - This has a default value of "hlc3" and is used to control the input data source.
Neighbors Count - This has a default value of 8, a minimum value of 1, a maximum value of 100, and a step of 1. It is used to control the number of neighbors to consider.
Max Bars Back - This has a default value of 2000.
Feature Count - This has a default value of 5, a minimum value of 2, and a maximum value of 5. It controls the number of features to use for ML predictions.
Color Compression - This has a default value of 1, a minimum value of 1, and a maximum value of 10. It is used to control the compression factor for adjusting the intensity of the color scale.
Show Exits - This has a default value of false. It controls whether to show the exit threshold on the chart.
Use Dynamic Exits - This has a default value of false. It is used to control whether to attempt to let profits ride by dynamically adjusting the exit threshold based on kernel regression.
Feature Engineering Settings:
Note: The Feature Engineering section is for fine-tuning the features used for ML predictions. The default values are optimized for the 4H to 12H timeframes for most charts, but they should also work reasonably well for other timeframes. By default, the model can support features that accept two parameters (Parameter A and Parameter B, respectively). Even though there are only 4 features provided by default, the same feature with different settings counts as two separate features. If the feature only accepts one parameter, then the second parameter will default to EMA-based smoothing with a default value of 1. These features represent the most effective combination I have encountered in my testing, but additional features may be added as additional options in the future.
Feature 1 - This has a default value of "RSI" and options are: "RSI", "WT", "CCI", "ADX".
Feature 2 - This has a default value of "WT" and options are: "RSI", "WT", "CCI", "ADX".
Feature 3 - This has a default value of "CCI" and options are: "RSI", "WT", "CCI", "ADX".
Feature 4 - This has a default value of "ADX" and options are: "RSI", "WT", "CCI", "ADX".
Feature 5 - This has a default value of "RSI" and options are: "RSI", "WT", "CCI", "ADX".
Filters Settings:
Use Volatility Filter - This has a default value of true. It is used to control whether to use the volatility filter.
Use Regime Filter - This has a default value of true. It is used to control whether to use the trend detection filter.
Use ADX Filter - This has a default value of false. It is used to control whether to use the ADX filter.
Regime Threshold - This has a default value of -0.1, a minimum value of -10, a maximum value of 10, and a step of 0.1. It is used to control the Regime Detection filter for detecting Trending/Ranging markets.
ADX Threshold - This has a default value of 20, a minimum value of 0, a maximum value of 100, and a step of 1. It is used to control the threshold for detecting Trending/Ranging markets.
Kernel Regression Settings:
Trade with Kernel - This has a default value of true. It is used to control whether to trade with the kernel.
Show Kernel Estimate - This has a default value of true. It is used to control whether to show the kernel estimate.
Lookback Window - This has a default value of 8 and a minimum value of 3. It is used to control the number of bars used for the estimation. Recommended range: 3-50
Relative Weighting - This has a default value of 8 and a step size of 0.25. It is used to control the relative weighting of time frames. Recommended range: 0.25-25
Start Regression at Bar - This has a default value of 25. It is used to control the bar index on which to start regression. Recommended range: 0-25
Display Settings:
Show Bar Colors - This has a default value of true. It is used to control whether to show the bar colors.
Show Bar Prediction Values - This has a default value of true. It controls whether to show the ML model's evaluation of each bar as an integer.
Use ATR Offset - This has a default value of false. It controls whether to use the ATR offset instead of the bar prediction offset.
Bar Prediction Offset - This has a default value of 0 and a minimum value of 0. It is used to control the offset of the bar predictions as a percentage from the bar high or close.
Backtesting Settings:
Show Backtest Results - This has a default value of true. It is used to control whether to display the win rate of the given configuration.
█ WORKS CITED
(1) R. Giusti and G. E. A. P. A. Batista, "An Empirical Comparison of Dissimilarity Measures for Time Series Classification," 2013 Brazilian Conference on Intelligent Systems, Oct. 2013, DOI: 10.1109/bracis.2013.22.
(2) Y. Kerimbekov, H. Ş. Bilge, and H. H. Uğurlu, "The use of Lorentzian distance metric in classification problems," Pattern Recognition Letters, vol. 84, 170–176, Dec. 2016, DOI: 10.1016/j.patrec.2016.09.006.
(3) A. Bagnall, A. Bostrom, J. Large, and J. Lines, "The Great Time Series Classification Bake Off: An Experimental Evaluation of Recently Proposed Algorithms." ResearchGate, Feb. 04, 2016.
(4) H. Ş. Bilge, Yerzhan Kerimbekov, and Hasan Hüseyin Uğurlu, "A new classification method by using Lorentzian distance metric," ResearchGate, Sep. 02, 2015.
(5) Y. Kerimbekov and H. Şakir Bilge, "Lorentzian Distance Classifier for Multiple Features," Proceedings of the 6th International Conference on Pattern Recognition Applications and Methods, 2017, DOI: 10.5220/0006197004930501.
(6) V. Surya Prasath et al., "Effects of Distance Measure Choice on KNN Classifier Performance - A Review." .
█ ACKNOWLEDGEMENTS
@veryfid - For many invaluable insights, discussions, and advice that helped to shape this project.
@capissimo - For open sourcing his interesting ideas regarding various KNN implementations in PineScript, several of which helped inspire my original undertaking of this project.
@RikkiTavi - For many invaluable physics-related conversations and for his helping me develop a mechanism for visualizing various distance algorithms in 3D using JavaScript
@jlaurel - For invaluable literature recommendations that helped me to understand the underlying subject matter of this project.
@annutara - For help in beta-testing this indicator and for sharing many helpful ideas and insights early on in its development.
@jasontaylor7 - For helping to beta-test this indicator and for many helpful conversations that helped to shape my backtesting workflow
@meddymarkusvanhala - For helping to beta-test this indicator
@dlbnext - For incredibly detailed backtesting testing of this indicator and for sharing numerous ideas on how the user experience could be improved.
Grid Strategy Back Tester (Long/Short/Neutral)Preface
I'd like to send a thank you to @xxattaxx-DisDev.
The 'Line' Code, which was the most difficult to plan the Grid Indicator, was solved through the 'Grid Bot Simulator' script of @xxattaxx-DisDev.
A brief description of the indicators
These indicators are designed for backtesting of grid trading that can be opened on various exchanges.
Grid trading is a method of selling at particular intervals as prices rise and fall for gird interval price range.
This indicator is actually designed to see what the Long / Short / Neutral grid has achieved and how much it has achieved over a given period of time.
How to use
1. Lower Limit and Upper Limit are required when putting indicators on the chart.
After that, choose the 'Time' when to open the grid.
Also, select Long / Short / Neutral direction if necessary.
2. Statistics Table
Matched Grid shows how many grid pairs were engaged during the backtesting period.
The Daily Average Matching Profit is calculated based on the number of these closed grids.
Total Matching Profit is calculated as Matching Grid * Per Matching Profit.
Position Profit/Loss shows the benefits and losses from your current position.
Total Profit/Loss is sum of Total Matching Profit and Position Profit/Loss.
The Expanded APY shows the benefits of running the strategy on these terms for a year.
Max Loss of Upper is the maximum loss assumed to be directly at the top of the grid range.
BEP days (Upper) show how many days of maintenance relative to Average Matching Profit can result in greater profit than maximum loss if the grid continues to move within range.
(In the case of Long Strategy, it appears to be 'Min Profit', which shows minimal benefit if it reaches the top.)
Max Loss of Lower and BEP days (Lower) shows the opposite.
(In the case of Short Strategy, it is also referred to as 'Min Profit', which shows minimal benefit if it reaches the bottom.)
3. Grid Info
Total Grid Number, Upper Limit, and Lower Limit show the values you set in INPUT.
Grid Open Price shows the price for the period you decide to open.
Starting Position shows the number of positions that were initially held in the case of a Long / Short Strategy.
(0 for Neutral Strategy)
Per Grid qty shows how many positions are allocated to one grid
Grid Interval shows the spacing of each grid.
Per Matched Profit shows how much profit is generated when a single grid is matched.
Caution
Backtesting results for these indicators may vary depending on the time frame.
Therefore, I recommend that you use it only to compare Profit/Loss over time.
*In addition, there is a problem that all lines in the grid are not implemented, but it is independent of the backtest results.
--------------------------------------
서문
지표를 기획함에 있어서 가장 어려웠던 line 코드를 @xxattaxx-DisDev의 'Grid Bot Simulator' 스크립트를 통해 해결할 수 있었습니다.
이에 감사의 말씀을 드립니다.
해당 지표에 대한 간단한 설명
해당 지표는 다양한 거래소에서 오픈할 수 있는 그리드 매매에 대한 백테스팅을 위해 만들어졌습니다.
그리드매매는, 특정 가격 구간에 대해 가격이 오르고 내림에 따라 일정 간격에 맞춰 매매를 하는 방식입니다.
이 지표는 실질적으로 롱/숏/중립 그리드가 어떠한 성과를, 특정 기간동안 얼마나 냈는지를 확인하고자 만들어졌습니다.
사용방법
1. 인풋
지표를 차트위에 넣을 때, Lower Limit과 Upper Limit이 필요합니다.
그 후 그리드를 언제부터 오픈할 것인지를 선택하세요.
또, 필요하다면 Long / Short / Neutral의 방향을 선택하세요.
2. 그리드 통계
Matched Grid는, 백테스팅 기간동안 체결된 그리드 쌍이 몇개인지를 보여줍니다.
이 체결된 그리드의 갯수를 바탕으로 Daily Average Matched Profit이 계산됩니다.
Total Matched Profit은, Matched Grid * Per Matched Profit으로 계산됩니다.
Position Profit/Loss는, 현재 갖고 있는 포지션으로 인한 이익과 손실을 보여줍니다.
Total Matched Profit과 Position Profit/Loss를 합친 금액이 Total Profit/Loss가 됩니다.
Expcted APY는, 이러한 조건으로 전략을 1년동안 운영했을 때의 이익을 보여줍니다.
Max Loss of Upper는, 그리드 범위의 최상단에 바로 도달했을 경우를 가정한 최대 손실입니다.
BEP days(Upper)는, 그리드가 범위 내에서 계속 움직일 경우, Average Matched Profit을 기준으로 며칠동안 유지되어야 최대손실보다 더 큰 이익이 발생할 수 있는지를 보여줍니다.
(Long Strategy의 경우, ‘Min Profit’이라고 나타나는데, 최상단에 도달했을 경우 최소한의 이익을 보여줍니다)
Max Loss of Lower는 그 반대의 경우를 보여줍니다.
(Short Strategy의 경우, 역시 ‘Min Profit’이라고 나타나는데, 최하단에 도착했을 경우 최소한의 이익을 보여줍니다)
3. 그리드 정보
그리드 갯수, Upper Limt, Lower Limt은 자신이 설정한 값을 보여줍니다.
Grid Open Price는, 자신이 오픈하기로 정했던 기간의 가격을 보여줍니다.
Starting Position은, 롱/숏 그리드의 경우에 처음에 들고 시작했던 포지션의 갯수를 보여줍니다.
Neutral Strategy의 경우 0입니다.
Per Grid qty는, 하나의 그리드에 얼마만큼의 포지션이 배분되었는지를 보여주며
Grid Interval은 각 그리드의 간격을 보여줍니다.
또, Per Matched Profit은 하나의 그리드가 체결될 때 얼마만큼의 이익이 발생하는 지를 보여줍니다.
이러한 지표에 대한 역테스트 결과는 시간 프레임에 따라 달라질 수 있습니다.
따라서 시간 경과에 따른 손익을 비교할 때만 사용하는 것이 좋습니다.
*추가로, 그리드의 라인이 모두 구현되지 않는 문제가 있지만, 백테스팅 결과와는 무관합니다.
EHMA Range StrategyThis script is a modified version of @borserman's script for the Exponential Hull Moving Average
All credit for the EHMA goes to him :)
In addition to the EHMA, this script works with a range around the EHMA (which can be modified), in an attempt to be robust against fake signals. Many times a bar will close below a moving average, only to reverse again the next bar, which eats away at your profits. Especially on shorter timeframes, but also on choppy longer timeframes this can make a strategy unattractive to use.
With the range around the EHMA, the strategy only enters a long/exit-short position if a bar crosses above the upper range. Vice versa, it only enters a short/exit-long position if a bar crosses below the lower range. This avoids positions if bars behave choppy within the EHMA range & only enters a position if the market is confident in it's direction. Having said that, fakeouts are still possible, but a lot less frequent. Having backtested this strategy vs the regular EHMA strategy (and having experimented with various settings), this version seems to be a lot more robust & profitable!
Disclaimer
Please remember that past performance may not be indicative of future results.
Due to various factors, including changing market conditions, the strategy may no longer perform as good as in historical backtesting.
This post and the script don’t provide any financial advice.
DMI Swings (by Coinrule)The Directional Movement Index is a handy indicator that helps catch the direction in which the price of an asset is moving. It compares the prior highs and lows to draw three lines:
Positive directional line (+DI)
Negative directional line (-DI)
Average direction index (ADX)
DMI is simple to interpret. When +DI > - DI, it means the price is trending up. On the other hand, when -DI > +DI, the trend is weak or moving on the downside.
The ADX does not give an indication about the direction but about the strength of the trend.
Typically values of ADX above 25 mean that the trend is steeply moving up or down, based on the -DI and +D positioning. This script aims to capture swings in the DMI, and thus, in the trend of the asset, using a contrarian approach.
ENTRY
-DI is greater than +DI
ADX is greater than 45
EXIT
+DI is greater than -DI
ADX is greater than 45
Trading on high values of ADX, the strategy tries to spot extremely oversold and overbought conditions. Values of ADX above 45 may suggest that the trend has overextended and is may be about to reverse.
Our backtests suggest that this script performs well for very short-term scalping strategies on low time frames, such as the 1-minute.
The script considers a 0.1% trading fee to make results more realistic to those you can expect from live market conditions. So realistically, live results should be similar to backtested results.
You can plug this script directly into your crypto exchange using TradingView Signals on Coinrule.
Trade Safely!
Daily Close and 5/10 Robinhood TargetsThis script is super simple, just outputs a daily close line and also 5/10% targets higher and lower based on that price.
The reason I made this is somewhat simple which is what, ive noticed (havent statistically backtested) but many popular "robinhood stocks" when they run they tend to almost always tag 5 or 10% up or down.
The theory is something to do with the fact that robinhood alerts at those price levels, so when something like a BYND or RUN or TSLA or (pick a popular stock that runs) it tends to at least tap those levels. I rarely see it go up lets say, 4.33% and then turn around, typically it will at least wick if not pass 5% so using these might POSSIBLY be a level of alpha.
Use it for your own backtests though with something better.
`security()` revisited [PineCoders]NOTE
The non-repainting technique in this publication that relies on bar states is now deprecated, as we have identified inconsistencies that undermine its credibility as a universal solution. The outputs that use the technique are still available for reference in this publication. However, we do not endorse its usage. See this publication for more information about the current best practices for requesting HTF data and why they work.
█ OVERVIEW
This script presents a new function to help coders use security() in both repainting and non-repainting modes. We revisit this often misunderstood and misused function, and explain its behavior in different contexts, in the hope of dispelling some of the coder lure surrounding it. The function is incredibly powerful, yet misused, it can become a dangerous WMD and an instrument of deception, for both coders and traders.
We will discuss:
• How to use our new `f_security()` function.
• The behavior of Pine code and security() on the three very different types of bars that make up any chart.
• Why what you see on a chart is a simulation, and should be taken with a grain of salt.
• Why we are presenting a new version of a function handling security() calls.
• Other topics of interest to coders using higher timeframe (HTF) data.
█ WARNING
We have tried to deliver a function that is simple to use and will, in non-repainting mode, produce reliable results for both experienced and novice coders. If you are a novice coder, stick to our recommendations to avoid getting into trouble, and DO NOT change our `f_security()` function when using it. Use `false` as the function's last argument and refrain from using your script at smaller timeframes than the chart's. To call our function to fetch a non-repainting value of close from the 1D timeframe, use:
f_security(_sym, _res, _src, _rep) => security(_sym, _res, _src )
previousDayClose = f_security(syminfo.tickerid, "D", close, false)
If that's all you're interested in, you are done.
If you choose to ignore our recommendation and use the function in repainting mode by changing the `false` in there for `true`, we sincerely hope you read the rest of our ramblings before you do so, to understand the consequences of your choice.
Let's now have a look at what security() is showing you. There is a lot to cover, so buckle up! But before we dig in, one last thing.
What is a chart?
A chart is a graphic representation of events that occur in markets. As any representation, it is not reality, but rather a model of reality. As Scott Page eloquently states in The Model Thinker : "All models are wrong; many are useful". Having in mind that both chart bars and plots on our charts are imperfect and incomplete renderings of what actually occurred in realtime markets puts us coders in a place from where we can better understand the nature of, and the causes underlying the inevitable compromises necessary to build the data series our code uses, and print chart bars.
Traders or coders complaining that charts do not reflect reality act like someone who would complain that the word "dog" is not a real dog. Let's recognize that we are dealing with models here, and try to understand them the best we can. Sure, models can be improved; TradingView is constantly improving the quality of the information displayed on charts, but charts nevertheless remain mere translations. Plots of data fetched through security() being modelized renderings of what occurs at higher timeframes, coders will build more useful and reliable tools for both themselves and traders if they endeavor to perfect their understanding of the abstractions they are working with. We hope this publication helps you in this pursuit.
█ FEATURES
This script's "Inputs" tab has four settings:
• Repaint : Determines whether the functions will use their repainting or non-repainting mode.
Note that the setting will not affect the behavior of the yellow plot, as it always repaints.
• Source : The source fetched by the security() calls.
• Timeframe : The timeframe used for the security() calls. If it is lower than the chart's timeframe, a warning appears.
• Show timeframe reminder : Displays a reminder of the timeframe after the last bar.
█ THE CHART
The chart shows two different pieces of information and we want to discuss other topics in this section, so we will be covering:
A — The type of chart bars we are looking at, indicated by the colored band at the top.
B — The plots resulting of calling security() with the close price in different ways.
C — Points of interest on the chart.
A — Chart bars
The colored band at the top shows the three types of bars that any chart on a live market will print. It is critical for coders to understand the important distinctions between each type of bar:
1 — Gray : Historical bars, which are bars that were already closed when the script was run on them.
2 — Red : Elapsed realtime bars, i.e., realtime bars that have run their course and closed.
The state of script calculations showing on those bars is that of the last time they were made, when the realtime bar closed.
3 — Green : The realtime bar. Only the rightmost bar on the chart can be the realtime bar at any given time, and only when the chart's market is active.
Refer to the Pine User Manual's Execution model page for a more detailed explanation of these types of bars.
B — Plots
The chart shows the result of letting our 5sec chart run for a few minutes with the following settings: "Repaint" = "On" (the default is "Off"), "Source" = `close` and "Timeframe" = 1min. The five lines plotted are the following. They have progressively thinner widths:
1 — Yellow : A normal, repainting security() call.
2 — Silver : Our recommended security() function.
3 — Fuchsia : Our recommended way of achieving the same result as our security() function, for cases when the source used is a function returning a tuple.
4 — White : The method we previously recommended in our MTF Selection Framework , which uses two distinct security() calls.
5 — Black : A lame attempt at fooling traders that MUST be avoided.
All lines except the first one in yellow will vary depending on the "Repaint" setting in the script's inputs. The first plot does not change because, contrary to all other plots, it contains no conditional code to adapt to repainting/no-repainting modes; it is a simple security() call showing its default behavior.
C — Points of interest on the chart
Historical bars do not show actual repainting behavior
To appreciate what a repainting security() call will plot in realtime, one must look at the realtime bar and at elapsed realtime bars, the bars where the top line is green or red on the chart at the top of this page. There you can see how the plots go up and down, following the close value of each successive chart bar making up a single bar of the higher timeframe. You would see the same behavior in "Replay" mode. In the realtime bar, the movement of repainting plots will vary with the source you are fetching: open will not move after a new timeframe opens, low and high will change when a new low or high are found, close will follow the last feed update. If you are fetching a value calculated by a function, it may also change on each update.
Now notice how different the plots are on historical bars. There, the plot shows the close of the previously completed timeframe for the whole duration of the current timeframe, until on its last bar the price updates to the current timeframe's close when it is confirmed (if the timeframe's last bar is missing, the plot will only update on the next timeframe's first bar). That last bar is the only one showing where the plot would end if that timeframe's bars had elapsed in realtime. If one doesn't understand this, one cannot properly visualize how his script will calculate in realtime when using repainting. Additionally, as published scripts typically show charts where the script has only run on historical bars, they are, in fact, misleading traders who will naturally assume the script will behave the same way on realtime bars.
Non-repainting plots are more accurate on historical bars
Now consider this chart, where we are using the same settings as on the chart used to publish this script, except that we have turned "Repainting" off this time:
The yellow line here is our reference, repainting line, so although repainting is turned off, it is still repainting, as expected. Because repainting is now off, however, plots on historical bars show the previous timeframe's close until the first bar of a new timeframe, at which point the plot updates. This correctly reflects the behavior of the script in the realtime bar, where because we are offsetting the series by one, we are always showing the previously calculated—and thus confirmed—higher timeframe value. This means that in realtime, we will only get the previous timeframe's values one bar after the timeframe's last bar has elapsed, at the open of the first bar of a new timeframe. Historical and elapsed realtime bars will not actually show this nuance because they reflect the state of calculations made on their close , but we can see the plot update on that bar nonetheless.
► This more accurate representation on historical bars of what will happen in the realtime bar is one of the two key reasons why using non-repainting data is preferable.
The other is that in realtime, your script will be using more reliable data and behave more consistently.
Misleading plots
Valiant attempts by coders to show non-repainting, higher timeframe data updating earlier than on our chart are futile. If updates occur one bar earlier because coders use the repainting version of the function, then so be it, but they must then also accept that their historical bars are not displaying information that is as accurate. Not informing script users of this is to mislead them. Coders should also be aware that if they choose to use repainting data in realtime, they are sacrificing reliability to speed and may be running a strategy that behaves very differently from the one they backtested, thus invalidating their tests.
When, however, coders make what are supposed to be non-repainting plots plot artificially early on historical bars, as in examples "c4" and "c5" of our script, they would want us to believe they have achieved the miracle of time travel. Our understanding of the current state of science dictates that for now, this is impossible. Using such techniques in scripts is plainly misleading, and public scripts using them will be moderated. We are coding trading tools here—not video games. Elementary ethics prescribe that we should not mislead traders, even if it means not being able to show sexy plots. As the great Feynman said: You should not fool the layman when you're talking as a scientist.
You can readily appreciate the fantasy plot of "c4", the thinnest line in black, by comparing its supposedly non-repainting behavior between historical bars and realtime bars. After updating—by miracle—as early as the wide yellow line that is repainting, it suddenly moves in a more realistic place when the script is running in realtime, in synch with our non-repainting lines. The "c5" version does not plot on the chart, but it displays in the Data Window. It is even worse than "c4" in that it also updates magically early on historical bars, but goes on to evaluate like the repainting yellow line in realtime, except one bar late.
Data Window
The Data Window shows the values of the chart's plots, then the values of both the inside and outside offsets used in our calculations, so you can see them change bar by bar. Notice their differences between historical and elapsed realtime bars, and the realtime bar itself. If you do not know about the Data Window, have a look at this essential tool for Pine coders in the Pine User Manual's page on Debugging . The conditional expressions used to calculate the offsets may seem tortuous but their objective is quite simple. When repainting is on, we use this form, so with no offset on all bars:
security(ticker, i_timeframe, i_source )
// which is equivalent to:
security(ticker, i_timeframe, i_source)
When repainting is off, we use two different and inverted offsets on historical bars and the realtime bar:
// Historical bars:
security(ticker, i_timeframe, i_source )
// Realtime bar (and thus, elapsed realtime bars):
security(ticker, i_timeframe, i_source )
The offsets in the first line show how we prevent repainting on historical bars without the need for the `lookahead` parameter. We use the value of the function call on the chart's previous bar. Since values between the repainting and non-repainting versions only differ on the timeframe's last bar, we can use the previous value so that the update only occurs on the timeframe's first bar, as it will in realtime when not repainting.
In the realtime bar, we use the second call, where the offsets are inverted. This is because if we used the first call in realtime, we would be fetching the value of the repainting function on the previous bar, so the close of the last bar. What we want, instead, is the data from the previous, higher timeframe bar , which has elapsed and is confirmed, and thus will not change throughout realtime bars, except on the first constituent chart bar belonging to a new higher timeframe.
After the offsets, the Data Window shows values for the `barstate.*` variables we use in our calculations.
█ NOTES
Why are we revisiting security() ?
For four reasons:
1 — We were seeing coders misuse our `f_secureSecurity()` function presented in How to avoid repainting when using security() .
Some novice coders were modifying the offset used with the history-referencing operator in the function, making it zero instead of one,
which to our horror, caused look-ahead bias when used with `lookahead = barmerge.lookahead_on`.
We wanted to present a safer function which avoids introducing the dreaded "lookahead" in the scripts of unsuspecting coders.
2 — The popularity of security() in screener-type scripts where coders need to use the full 40 calls allowed per script made us want to propose
a solid method of allowing coders to offer a repainting/no-repainting choice to their script users with only one security() call.
3 — We wanted to explain why some alternatives we see circulating are inadequate and produce misleading behavior.
4 — Our previous publication on security() focused on how to avoid repainting, yet many other considerations worthy of attention are not related to repainting.
Handling tuples
When sending function calls that return tuples with security() , our `f_security()` function will not work because Pine does not allow us to use the history-referencing operator with tuple return values. The solution is to integrate the inside offset to your function's arguments, use it to offset the results the function is returning, and then add the outside offset in a reassignment of the tuple variables, after security() returns its values to the script, as we do in our "c2" example.
Does it repaint?
We're pretty sure Wilder was not asked very often if RSI repainted. Why? Because it wasn't in fashion—and largely unnecessary—to ask that sort of question in the 80's. Many traders back then used daily charts only, and indicator values were calculated at the day's close, so everybody knew what they were getting. Additionally, indicator values were calculated by generally reputable outfits or traders themselves, so data was pretty reliable. Today, almost anybody can write a simple indicator, and the programming languages used to write them are complex enough for some coders lacking the caution, know-how or ethics of the best professional coders, to get in over their heads and produce code that does not work the way they think it does.
As we hope to have clearly demonstrated, traders do have legitimate cause to ask if MTF scripts repaint or not when authors do not specify it in their script's description.
► We recommend that authors always use our `f_security()` with `false` as the last argument to avoid repainting when fetching data dependent on OHLCV information. This is the only way to obtain reliable HTF data. If you want to offer users a choice, make non-repainting mode the default, so that if users choose repainting, it will be their responsibility. Non-repainting security() calls are also the only way for scripts to show historical behavior that matches the script's realtime behavior, so you are not misleading traders. Additionally, non-repainting HTF data is the only way that non-repainting alerts can be configured on MTF scripts, as users of MTF scripts cannot prevent their alerts from repainting by simply configuring them to trigger on the bar's close.
Data feeds
A chart at one timeframe is made up of multiple feeds that mesh seamlessly to form one chart. Historical bars can use one feed, and the realtime bar another, which brokers/exchanges can sometimes update retroactively so that elapsed realtime bars will reappear with very slight modifications when the browser's tab is refreshed. Intraday and daily chart prices also very often originate from different feeds supplied by brokers/exchanges. That is why security() calls at higher timeframes may be using a completely different feed than the chart, and explains why the daily high value, for example, can vary between timeframes. Volume information can also vary considerably between intraday and daily feeds in markets like stocks, because more volume information becomes available at the end of day. It is thus expected behavior—and not a bug—to see data variations between timeframes.
Another point to keep in mind concerning feeds it that when you are using a repainting security() plot in realtime, you will sometimes see discrepancies between its plot and the realtime bars. An artefact revealing these inconsistencies can be seen when security() plots sometimes skip a realtime chart bar during periods of high market activity. This occurs because of races between the chart and the security() feeds, which are being monitored by independent, concurrent processes. A blue arrow on the chart indicates such an occurrence. This is another cause of repainting, where realtime bar-building logic can produce different outcomes on one closing price. It is also another argument supporting our recommendation to use non-repainting data.
Alternatives
There is an alternative to using security() in some conditions. If all you need are OHLC prices of a higher timeframe, you can use a technique like the one Duyck demonstrates in his security free MTF example - JD script. It has the great advantage of displaying actual repainting values on historical bars, which mimic the code's behavior in the realtime bar—or at least on elapsed realtime bars, contrary to a repainting security() plot. It has the disadvantage of using the current chart's TF data feed prices, whereas higher timeframe data feeds may contain different and more reliable prices when they are compiled at the end of the day. In its current state, it also does not allow for a repainting/no-repainting choice.
When `lookahead` is useful
When retrieving non-price data, or in special cases, for experiments, it can be useful to use `lookahead`. One example is our Backtesting on Non-Standard Charts: Caution! script where we are fetching prices of standard chart bars from non-standard charts.
Warning users
Normal use of security() dictates that it only be used at timeframes equal to or higher than the chart's. To prevent users from inadvertently using your script in contexts where it will not produce expected behavior, it is good practice to warn them when their chart is on a higher timeframe than the one in the script's "Timeframe" field. Our `f_tfReminderAndErrorCheck()` function in this script does that. It can also print a reminder of the higher timeframe. It uses one security() call.
Intrabar timeframes
security() is not supported by TradingView when used with timeframes lower than the chart's. While it is still possible to use security() at intrabar timeframes, it then behaves differently. If no care is taken to send a function specifically written to handle the successive intrabars, security() will return the value of the last intrabar in the chart's timeframe, so the last 1H bar in the current 1D bar, if called at "60" from a "D" chart timeframe. If you are an advanced coder, see our FAQ entry on the techniques involved in processing intrabar timeframes. Using intrabar timeframes comes with important limitations, which you must understand and explain to traders if you choose to make scripts using the technique available to others. Special care should also be taken to thoroughly test this type of script. Novice coders should refrain from getting involved in this.
█ TERMINOLOGY
Timeframe
Timeframe , interval and resolution are all being used to name the concept of timeframe. We have, in the past, used "timeframe" and "resolution" more or less interchangeably. Recently, members from the Pine and PineCoders team have decided to settle on "timeframe", so from hereon we will be sticking to that term.
Multi-timeframe (MTF)
Some coders use "multi-timeframe" or "MTF" to name what are in fact "multi-period" calculations, as when they use MAs of progressively longer periods. We consider that a misleading use of "multi-timeframe", which should be reserved for code using calculations actually made from another timeframe's context and using security() , safe for scripts like Duyck's one mentioned earlier, or TradingView's Relative Volume at Time , which use a user-selected timeframe as an anchor to reset calculations. Calculations made at the chart's timeframe by varying the period of MAs or other rolling window calculations should be called "multi-period", and "MTF-anchored" could be used for scripts that reset calculations on timeframe boundaries.
Colophon
Our script was written using the PineCoders Coding Conventions for Pine .
The description was formatted using the techniques explained in the How We Write and Format Script Descriptions PineCoders publication.
Snippets were lifted from our MTF Selection Framework , then massaged to create the `f_tfReminderAndErrorCheck()` function.
█ THANKS
Thanks to apozdnyakov for his help with the innards of security() .
Thanks to bmistiaen for proofreading our description.
Look first. Then leap.
Squeeze Momentum Strategy based on Indicator [LazyBear][Bitduke]I improved Squeeze Momentum Indicator by LazyBear (momentum filter, changed data source to ohlc4) and transformed it into a strategy, adding a risk management system + ability to customize time frames for backtest.
Shortly about Squeeze Momentum Indicator:
This is a derivative of John Carter's "TTM Squeeze" volatility indicator, as discussed in his book "Mastering the Trade" (chapter 11).
Backtested on XBTUSD, ETHUSD (Bitmex). As you may notice it shows good results on 1h - 4h timeframes on these timeframes among these pairs. Relatively low drawdown ~ 12% (to date).
