Sessioni Colorate come ScreenshotPre-Market and Post-Market Session Highlighter (US)
This script highlights the Pre-Market and Post-Market trading sessions for US stocks and indices by coloring the background directly on the chart.
Time zone: UTC
• Pre-Market: 09:00 – 13:30 UTC
• Regular Session: 13:30 – 20:00 UTC (not highlighted)
• Post-Market: 20:00 – 00:00 UTC
Useful for identifying price behavior outside regular trading hours.
Cari dalam skrip untuk "20日线角度大于0的股票"
EMA Crossover with DiamondsGreen diamond when 20 exponential moving average crosses over 50 exponential moving average, and shows a red diamond when 50 moving average crosses over 20 exponential moving average
Exponential Moving Averages📘 Exponential Moving Averages – Clean & Focused Trend Tool
This script displays five Exponential Moving Averages (EMAs) — 10, 20, 50, 100, and 200 — that are commonly used by professional traders to identify short-, medium-, and long-term trend directions. It offers a simple, no-setup-needed solution for visualizing market momentum and price structure on any timeframe.
🧠 Why This Script Was Created
Previously, many users faced confusion with built-in moving average scripts, where they had to manually change the type to EMA from the default SMA (Simple Moving Average). This extra step was unintuitive for newer users and could lead to misinterpretation of signals.
To solve this, we’ve created a dedicated script that only plots Exponential Moving Averages — no configuration needed. EMAs are more responsive to price changes and widely used in real-world trading setups, especially for intraday and swing strategies.
🔍 How It Works
EMA 10 & 20 – Detect short-term momentum shifts.
EMA 50 & 100 – Help visualize medium-term trend strength.
EMA 200 – Tracks long-term trend direction and institutional positioning.
Each EMA is plotted with distinct colors and line thickness to make trend tracking fast and intuitive.
⚙️ How to Use
Use across any timeframe (5m, 1H, 1D, etc.).
Watch for crossovers between shorter and longer EMAs.
Observe price interaction with EMAs as dynamic support/resistance levels.
Combine with other tools like RSI, volume, or price action patterns for confirmation.
🌟 What Makes It Unique
No settings confusion: Always uses EMA — no manual adjustments needed.
Multiple EMAs in one: Avoid clutter by combining essential levels in a clean overlay.
Practical by design: Built for traders who prefer responsive, real-time trend signals.
📈 Smart Alert System — EMA/MA/Volume/SMC AlertsHere's a detailed description of your custom TradingView **Pine Script v6**:
---
### 📌 **Title**: Smart Alert System — Webhook Ready (with EMA, MA, Volume, and SMC)
This script is designed to **monitor price behavior**, detect important **technical analysis events**, and **send real-time alerts via webhook to a Telegram bot**.
---
## 🔧 SETTINGS
| Setting | Description |
| ----------------------- | ------------------------------------------------------------------------------ |
| `volumeSpikeMultiplier` | Multiplier to determine a volume spike compared to the 20-bar average volume |
| `testAlert` | If `true`, sends a test alert when the indicator is first applied to the chart |
---
## 🔍 COMPONENT BREAKDOWN
### 1. **EMA & MA Calculations**
These indicators are calculated and plotted on the chart:
* **EMAs**: 13, 25, 30, 200 — used for trend and touch detection
* **MAs**: 100, 300 — used for break and retest detection
```pinescript
ema_13 = ta.ema(close, 13)
ema_200 = ta.ema(close, 200)
ma_100 = ta.sma(close, 100)
```
---
### 2. **📈 Volume Spike Detection**
* A volume spike is identified when the current bar's volume is **2x (default)** greater than the 20-period average.
* A red triangle is plotted above such candles.
* A **JSON alert** is triggered.
```pinescript
volSpike = volume > avgVol * volumeSpikeMultiplier
```
---
### 3. **📊 EMA Touch Alerts**
* The script checks if the current close is:
* Within 0.1% of an EMA value **OR**
* Has crossed above/below it.
* If so, it sends an alert with the EMA name.
```pinescript
touch(val, crossed) =>
math.abs(close - val) / val < 0.001 or crossed
```
---
### 4. **📉 MA Break and Retest Alerts**
* A **break** is when price falls **below** a moving average.
* A **retest** is when price climbs **above** the same average after breaking below.
```pinescript
breakBelow(ma) => close > ma and close < ma
```
---
### 5. 🧠 **SMC Alerts (Break of Structure \ & Change of Character \ )**
These follow **Smart Money Concepts (SMC)**. The script identifies:
* **BOS**: New higher high in uptrend or lower low in downtrend
* **CHOCH**: Opposite of trend, e.g. lower low in uptrend or higher high in downtrend
```pinescript
bos = (high > high ) and (low > low ) and (low > low )
choch = (low < low ) and (high < high ) and (high < high )
```
---
### 6. 🧪 Dummy Test Alert (1-time fire)
* Sends a `"✅ Test Alert Fired"` to verify setup
* Executes **once only** after adding the indicator
```pinescript
var bool sentTest = false
if testAlert and not sentTest
```
---
### 7. 🚀 Alert Delivery (Webhook JSON)
All alerts are sent as a JSON payload that looks like this:
```json
{
"pair": "BTCUSD",
"event": "🔺 Volume Spike",
"timeframe": "15",
"timestamp": "2024-06-29T12:00:00Z",
"volume": "654000"
}
```
This format makes it compatible with your **Telegram webhook server**.
---
### 🔔 Alerts You Can Create in TradingView
* Set **Webhook URL** to your `https://xxxx.ngrok-free.app/tradingview-webhook`
* Use alert condition: `"Any alert()`" — because all logic is internal.
* Select **"Webhook URL"** and leave the message body blank.
---
### 🛠️ Use Cases
* Notify yourself on **EMA interaction**
* Detect **trend shifts or retests**
* Spot **volume-based market interest**
* Get real-time **BOS/CHOCH alerts** for Smart Money strategies
* Alert through **Telegram using your Node.js webhook server**
---
Would you like me to break down the full Pine Script block-by-block as well?
terils indicatorsVWAP
Yesterday’s High and Low
Today’s High and Low
EMAs (20, 50, 100, 200)
VWAP
Yesterday’s High and Low
Today’s High and Low
EMAs (20, 50, 100, 200)
VWAP + HL + EMAsVWAP
Yesterday’s High and Low
Today’s High and Low
EMAs (20, 50, 100, 200)
VWAP
Yesterday’s High and Low
Today’s High and Low
EMAs (20, 50, 100, 200)
Multi-Timeframe EMA Overlay [Smoothed Approximation]in.tradingview.com This indicator displays Exponential Moving Averages (EMAs) from multiple timeframes (5m, 15m, 1H, 4H, 1D) on a single chart, regardless of your current timeframe.
HOW IT WORKS
You choose a base EMA length (e.g., 20).
The script calculates equivalent lengths for other timeframes (e.g., for a 1H EMA while on a 1-minute chart: 20 × 60 = 1200 length).
These adjusted EMAs are then computed and plotted — giving a continuous, smooth curve rather than a stepped line.
KEY FEATURES
🟪 5m, 🟦 15m, 🟩 1H, 🟧 4H, 🟥 1D EMAs.
🧠 Smooth approximation — good for visual trend tracking without step lag.
🎛️ Toggle visibility for each timeframe EMA independently.
📈 Uses
Trend Confirmation:
Aligning short-term trades with higher timeframe trends (e.g., go long only when 15m & 1H EMAs are trending up).
Confluence Zones:
Price action near multiple EMA levels from different timeframes can indicate strong support/resistance zones.
Entry Filters:
Avoid trades against dominant higher timeframe trends.
Example: On a 5m chart, only go long if price > 1H EMA.
Reversal Watch:
EMA convergence or crossovers across timeframes can signal potential trend shifts.
Trading Tools🎯 Trading Tools – Your All-in-One Market Analysis Solution
Developed by Marcelo Ulisses Sobreiro Ribeiro, Trading Tools is a powerful, multi-functional indicator that combines essential trading features into a single, streamlined tool. Perfect for traders who want clear, precise market opportunities across any asset or timeframe.
🔥 Key Features:
📊 Smart Moving Averages
Customizable setup for up to 5 MAs (EMA, SMA, WMA).
Color-coded fills between MAs to highlight trends (bullish/bearish).
Dynamic 20-period MA (color shifts with trend).
Alerts for crossovers and trend changes.
🕒 Killzones (High-Liquidity Sessions)
Visual highlights for key trading sessions: Asia, London, NY AM, NY Lunch, and NY PM.
Customizable colors and transparency.
Drawing limit to avoid chart clutter.
📅 Time-Based Markers
Day-of-week labels (option to hide weekends).
Day separators (customizable style).
🎨 Rule-Based Candle Coloring
Expanded True Range (large candles).
Inside Bars.
123 Pattern (Mark Crisp).
Bullish/Bearish Engulfing.
Price of Closing Reversal (PFR).
Market Strength.
Overbought/Oversold (RSI & Stochastic).
⚖️ Imbalance Detector (FVG, OG, VI)
Fair Value Gaps (FVG).
Opening Gaps (OG).
Volume Imbalance (VI).
🔄 Stochastic Cross & Valid Pullbacks
Stochastic crossover signals (up/down arrows).
Valid pullback alerts.
📈 Dynamic Support & Resistance
Previous day’s high/low (PDH/PDL).
Automatic pivot detection (significant highs/lows).
⚙️ Full Customization
Adjust timeframe limits, timezone, label size, and colors.
Control how many drawings are kept on the chart.
🚨 Built-in Alerts
Alerts for 20-period MA, PFR, Pullbacks, and more!
📌 Why Use Trading Tools?
All-in-one solution: No need for multiple indicators.
Intuitive visuals: Colors and markers simplify setup identification.
Adaptable: Works on any asset (forex, stocks, crypto).
🔹 Perfect for traders who want efficiency and clarity in their analysis!
Ticker Pulse Meter + Fear EKG StrategyDescription
The Ticker Pulse Meter + Fear EKG Strategy is a technical analysis tool designed to identify potential entry and exit points for long positions based on price action relative to historical ranges. It combines two proprietary indicators: the Ticker Pulse Meter (TPM), which measures price positioning within short- and long-term ranges, and the Fear EKG, a VIX-inspired oscillator that detects extreme market conditions. The strategy is non-repainting, ensuring signals are generated only on confirmed bars to avoid false positives. Visual enhancements, such as optional moving averages and Bollinger Bands, provide additional context but are not core to the strategy's logic. This script is suitable for traders seeking a systematic approach to capturing momentum and mean-reversion opportunities.
How It Works
The strategy evaluates price action using two key metrics:
Ticker Pulse Meter (TPM): Measures the current price's position within short- and long-term price ranges to identify momentum or overextension.
Fear EKG: Detects extreme selling pressure (akin to "irrational selling") by analyzing price behavior relative to historical lows, inspired by volatility-based oscillators.
Entry signals are generated when specific conditions align, indicating potential buying opportunities. Exits are triggered based on predefined thresholds or partial position closures to manage risk. The strategy supports customizable lookback periods, thresholds, and exit percentages, allowing flexibility across different markets and timeframes. Visual cues, such as entry/exit dots and a position table, enhance usability, while optional overlays like moving averages and Bollinger Bands provide additional chart context.
Calculation Overview
Price Range Calculations:
Short-Term Range: Uses the lowest low (min_price_short) and highest high (max_price_short) over a user-defined short lookback period (lookback_short, default 50 bars).
Long-Term Range: Uses the lowest low (min_price_long) and highest high (max_price_long) over a user-defined long lookback period (lookback_long, default 200 bars).
Percentage Metrics:
pct_above_short: Percentage of the current close above the short-term range.
pct_above_long: Percentage of the current close above the long-term range.
Combined metrics (pct_above_long_above_short, pct_below_long_below_short) normalize price action for signal generation.
Signal Generation:
Long Entry (TPM): Triggered when pct_above_long_above_short crosses above a user-defined threshold (entryThresholdhigh, default 20) and pct_below_long_below_short is below a low threshold (entryThresholdlow, default 40).
Long Entry (Fear EKG): Triggered when pct_below_long_below_short crosses under an extreme threshold (orangeEntryThreshold, default 95), indicating potential oversold conditions.
Long Exit: Triggered when pct_above_long_above_short crosses under a profit-taking level (profitTake, default 95). Partial exits are supported via a user-defined percentage (exitAmt, default 50%).
Non-Repainting Logic: Signals are calculated using data from the previous bar ( ) and only plotted on confirmed bars (barstate.isconfirmed), ensuring reliability.
Visual Enhancements:
Optional moving averages (SMA, EMA, WMA, VWMA, or SMMA) and Bollinger Bands can be enabled for trend context.
A position table displays real-time metrics, including open positions, Fear EKG, and Ticker Pulse values.
Background highlights mark periods of high selling pressure.
Entry Rules
Long Entry:
TPM Signal: Occurs when the price shows strength relative to both short- and long-term ranges, as defined by pct_above_long_above_short crossing above entryThresholdhigh and pct_below_long_below_short below entryThresholdlow.
Fear EKG Signal: Triggered by extreme selling pressure, when pct_below_long_below_short crosses under orangeEntryThreshold. This signal is optional and can be toggled via enable_yellow_signals.
Entries are executed only on confirmed bars to prevent repainting.
Exit Rules
Long Exit: Triggered when pct_above_long_above_short crosses under profitTake.
Partial exits are supported, with the strategy closing a user-defined percentage of the position (exitAmt) up to four times per position (exit_count limit).
Exits can be disabled or adjusted via enable_short_signal and exitPercentage settings.
Inputs
Backtest Start Date: Defines the start of the backtesting period (default: Jan 1, 2017).
Lookback Periods: Short (lookback_short, default 50) and long (lookback_long, default 200) periods for range calculations.
Resolution: Timeframe for price data (default: Daily).
Entry/Exit Thresholds:
entryThresholdhigh (default 20): Threshold for TPM entry.
entryThresholdlow (default 40): Secondary condition for TPM entry.
orangeEntryThreshold (default 95): Threshold for Fear EKG entry.
profitTake (default 95): Exit threshold.
exitAmt (default 50%): Percentage of position to exit.
Visual Options: Toggle for moving averages and Bollinger Bands, with customizable types and lengths.
Notes
The strategy is designed to work across various timeframes and assets, with data sourced from user-selected resolutions (i_res).
Alerts are included for long entry and exit signals, facilitating integration with TradingView's alert system.
The script avoids repainting by using confirmed bar data and shifted calculations ( ).
Visual elements (e.g., SMA, Bollinger Bands) are inspired by standard Pine Script practices and are optional, not integral to the core logic.
Usage
Apply the script to a chart, adjust input settings to suit your trading style, and use the visual cues (entry/exit dots, position table) to monitor signals. Enable alerts for real-time notifications.
Designed to work best on Daily timeframe.
Super PerformanceThe "Super Performance" script is a custom indicator written in Pine Script (version 6) for use on the TradingView platform. Its main purpose is to visually compare the performance of a selected stock or index against a benchmark index (default: NIFTYMIDSML400) over various timeframes, and to display sector-wise performance rankings in a clear, tabular format.
Key Features:
Customizable Display:
Users can toggle between dark and light color themes, enable or disable extended data columns, and choose between a compact "Mini Mode" or a full-featured table view. Table positions and sizes are also configurable for both stock and sector tables.
Performance Calculation:
The script calculates percentage price changes for the selected stock and the benchmark index over multiple periods: 1, 5, 10, 20, 50, and 200 days. It then checks if the stock is outperforming the index for each period.
Conviction Score:
For each period where the stock outperforms the index, a "conviction score" is incremented. This score is mapped to qualitative labels such as "Super solid," "Solid," "Good," etc., and is color-coded for quick visual interpretation.
Sector Performance Table:
The script tracks 19 sector indices (e.g., REALTY, IT, PHARMA, AUTO, ENERGY) and calculates their performance over 1, 5, 10, 20, and 60-day periods. It then ranks the top 5 performing sectors for each timeframe and displays them in a sector performance table.
Visual Output:
Two tables are constructed:
Stock Performance Table: Shows the stock's returns, index returns, outperformance markers (✔/✖), and the difference for each period, along with the overall conviction score.
Sector Performance Table: Ranks and displays the top 5 sectors for each timeframe, with color-coded performance values for easy comparison.
Top 5 Sector Performancehe indicator creates a table showing:
Top 5 performing sectors for 3 timeframes: 1-day, 10-day, and 20-day periods
Performance data including sector name and percentage change
Color-coded results: Green (positive), Red (negative), Gray ("N/A" for missing data)
Key Features
Table Structure:
Columns: Rank | 1-Day | 10-Day | 20-Day
Rows: Top 5 sectors for each timeframe
Header: Dark gray background with white text
Rows: Alternating dark gray shades for readability
LVN/HVN Auto Detection [PhenLabs]📊 PhenLabs - LVN/HVN Auto Detection
Version: PineScript™ v6
📌 Description
The PhenLabs LVN/HVN Auto Detection indicator is an advanced volume profile analysis tool that automatically identifies Low Volume Nodes (LVN) and High Volume Nodes (HVN) across multiple trading sessions. This sophisticated indicator analyzes volume distribution patterns to pinpoint critical support and resistance levels where price is likely to react, providing traders with high-probability zones for entries, exits, and risk management.
Unlike traditional volume indicators that only show current activity, this tool builds comprehensive volume profiles from historical sessions and intelligently filters the most significant levels. It combines real-time volume analysis with dynamic level detection, offering both visual bubbles for immediate volume activity and persistent horizontal lines that act as ongoing support/resistance references.
🚀 Points of Innovation
Multi-Session Volume Profile Analysis - Automatically calculates and analyzes volume profiles across the last 5 trading sessions
Intelligent Level Separation Logic - Prevents overlapping signals by maintaining minimum separation between LVN and HVN levels
Dynamic Timeframe Adaptation - Automatically adjusts session lengths based on chart timeframe for optimal level detection
Real-Time Activity Bubbles - Shows volume activity strength through different bubble sizes at key levels
Persistent Line Management - Creates horizontal lines that extend until price crosses them, providing ongoing reference points
Dual Threshold System - Independent percentage-based thresholds for both LVN and HVN identification
🔧 Core Components
Volume Profile Engine : Builds 20-row volume profiles for each analyzed session, distributing volume across price levels
Level Identification Algorithm : Uses percentage-based thresholds to classify volume distribution patterns
Separation Logic : Ensures minimum distance between conflicting levels, prioritizing HVN when overlap occurs
Line Management System : Tracks active support/resistance lines and removes them when price crosses through
Volume Activity Monitor : Compares current volume to 13-period moving average for activity classification
🔥 Key Features
Customizable Thresholds : LVN threshold (5-35%, default 20%) and HVN threshold (65-95%, default 80%) for precise level filtering
Volume Activity Multiplier : Adjustable volume threshold (0.5+, default 1.5) for bubble and line creation sensitivity
Flexible Display Modes : Choose between Lines only, Bubbles only, or Both for optimal chart clarity
Smart Level Separation : Minimum separation percentage (0.1-2%, default 0.5%) prevents conflicting signals
Color Customization : Independent color controls for LVN (red) and HVN (blue) elements
Performance Optimization : Processes every 15 bars with maximum 500 active lines for smooth operation
🎨 Visualization
Colored Bubbles : Three sizes (large, medium, small) indicate volume activity strength at key levels
Horizontal Lines : Persistent support/resistance lines with width corresponding to volume activity
Dual Color System : Semi-transparent red for LVN areas, semi-transparent blue for HVN zones
Information Tooltip : Optional table showing usage guidelines and optimization tips
📖 Usage Guidelines
Volume Thresholds
LVN Threshold
○ Default: 20.0%
○ Range: 5.0-35.0%
○ Description: Price levels with volume below this percentage are marked as LVNs. Lower values create fewer, more significant levels. Typical range 15-25% works for most instruments.
HVN Threshold
○ Default: 80.0%
○ Range: 65.0-95.0%
○ Description: Price levels with volume above this percentage are marked as HVNs. Higher values create fewer, stronger levels. Range 75-85% is optimal for most trading.
Display Controls
Volume Threshold
○ Default: 1.5
○ Range: 0.5+
○ Description: Multiplier for volume significance (High=2+threshold, Medium=1+threshold, Low=0+threshold). Higher values require more volume for signals.
✅ Best Use Cases
Swing Trading : Identify key levels for position entries and exits over multiple days
Scalping : Use bubbles for immediate volume activity confirmation at critical levels
Risk Management : Place stops beyond LVN levels where price moves quickly
Breakout Trading : Monitor HVN levels for potential breakout or rejection scenarios
Multi-Timeframe Analysis : Combine with higher timeframe levels for confluence
⚠️ Limitations
Timeframe Sensitivity : Lower timeframes may produce too many levels; higher timeframes recommended for cleaner signals
Volume Data Dependency : Accuracy depends on reliable volume data from your data provider
Historical Analysis : Uses past volume data which may not predict future price behavior
Performance Impact : High number of active lines may affect chart performance on slower devices
💡 What Makes This Unique
Automated Session Analysis : No manual drawing required - automatically analyzes multiple sessions
Intelligent Filtering : Advanced separation logic prevents overlapping and conflicting signals
Adaptive Processing : Adjusts to different timeframes automatically for optimal level detection
Dual Visualization System : Combines persistent lines with real-time activity indicators
🔬 How It Works
1. Volume Profile Construction :
Analyzes the last 5 trading sessions with dynamic session length based on timeframe
Divides each session’s price range into 20 equal levels for volume distribution analysis
2. Level Classification :
Calculates volume percentage at each price level relative to session maximum
Identifies LVN levels below threshold and HVN levels above threshold
3. Signal Generation :
Creates bubbles when volume activity exceeds thresholds at identified levels
Draws horizontal lines that persist until price crosses through them
💡 Note : For optimal results, increase your chart timeframe if you see too many levels. The indicator performs best on 15-minute and higher timeframes where volume patterns are more meaningful and less noisy.
Quantum Reversal# 🧠 Quantum Reversal
## **Quantitative Mean Reversion Framework**
This algorithmic trading system employs **statistical mean reversion theory** combined with **adaptive volatility modeling** to capitalize on Bitcoin's inherent price oscillations around its statistical mean. The strategy integrates multiple technical indicators through a **multi-layered signal processing architecture**.
---
## ⚡ **Core Technical Architecture**
### 📊 **Statistical Foundation**
- **Bollinger Band Mean Reversion Model**: Utilizes 20-period moving average with 2.2 standard deviation bands for volatility-adjusted entry signals
- **Adaptive Volatility Threshold**: Dynamic standard deviation multiplier accounts for Bitcoin's heteroscedastic volatility patterns
- **Price Action Confluence**: Entry triggered when price breaches lower volatility band, indicating statistical oversold conditions
### 🔬 **Momentum Analysis Layer**
- **RSI Oscillator Integration**: 14-period Relative Strength Index with modified oversold threshold at 45
- **Signal Smoothing Algorithm**: 5-period simple moving average applied to RSI reduces noise and false signals
- **Momentum Divergence Detection**: Captures mean reversion opportunities when momentum indicators show oversold readings
### ⚙️ **Entry Logic Architecture**
```
Entry Condition = (Price ≤ Lower_BB) OR (Smoothed_RSI < 45)
```
- **Dual-Condition Framework**: Either statistical price deviation OR momentum oversold condition triggers entry
- **Boolean Logic Gate**: OR-based entry system increases signal frequency while maintaining statistical validity
- **Position Sizing**: Fixed 10% equity allocation per trade for consistent risk exposure
### 🎯 **Exit Strategy Optimization**
- **Profit-Lock Mechanism**: Positions only closed when showing positive unrealized P&L
- **Trend Continuation Logic**: Allows winning trades to run until momentum exhaustion
- **Dynamic Exit Timing**: No fixed profit targets - exits based on profitability state rather than arbitrary levels
---
## 📈 **Statistical Properties**
### **Risk Management Framework**
- **Long-Only Exposure**: Eliminates short-squeeze risk inherent in cryptocurrency markets
- **Mean Reversion Bias**: Exploits Bitcoin's tendency to revert to statistical mean after extreme moves
- **Position Management**: Single position limit prevents over-leveraging
### **Signal Processing Characteristics**
- **Noise Reduction**: SMA smoothing on RSI eliminates high-frequency oscillations
- **Volatility Adaptation**: Bollinger Bands automatically adjust to changing market volatility
- **Multi-Timeframe Coherence**: Indicators operate on consistent timeframe for signal alignment
---
## 🔧 **Parameter Configuration**
| Technical Parameter | Value | Statistical Significance |
|-------------------|-------|-------------------------|
| Bollinger Period | 20 | Standard statistical lookback for volatility calculation |
| Std Dev Multiplier | 2.2 | Optimized for Bitcoin's volatility distribution (95.4% confidence interval) |
| RSI Period | 14 | Traditional momentum oscillator period |
| RSI Threshold | 45 | Modified oversold level accounting for Bitcoin's momentum characteristics |
| Smoothing Period | 5 | Noise reduction filter for momentum signals |
---
## 📊 **Algorithmic Advantages**
✅ **Statistical Edge**: Exploits documented mean reversion tendency in Bitcoin markets
✅ **Volatility Adaptation**: Dynamic bands adjust to changing market conditions
✅ **Signal Confluence**: Multiple indicator confirmation reduces false positives
✅ **Momentum Integration**: RSI smoothing improves signal quality and timing
✅ **Risk-Controlled Exposure**: Systematic position sizing and long-only bias
---
## 🔬 **Mathematical Foundation**
The strategy leverages **Bollinger Band theory** (developed by John Bollinger) which assumes that prices tend to revert to the mean after extreme deviations. The RSI component adds **momentum confirmation** to the statistical price deviation signal.
**Statistical Basis:**
- Mean reversion follows the principle that extreme price deviations from the moving average are temporary
- The 2.2 standard deviation multiplier captures approximately 97.2% of price movements under normal distribution
- RSI momentum smoothing reduces noise inherent in oscillator calculations
---
## ⚠️ **Risk Considerations**
This algorithm is designed for traders with understanding of **quantitative finance principles** and **cryptocurrency market dynamics**. The strategy assumes mean-reverting behavior which may not persist during trending market phases. Proper risk management and position sizing are essential.
---
## 🎯 **Implementation Notes**
- **Market Regime Awareness**: Most effective in ranging/consolidating markets
- **Volatility Sensitivity**: Performance may vary during extreme volatility events
- **Backtesting Recommended**: Historical performance analysis advised before live implementation
- **Capital Allocation**: 10% per trade sizing assumes diversified portfolio approach
---
**Engineered for quantitative traders seeking systematic mean reversion exposure in Bitcoin markets through statistically-grounded technical analysis.**
Canuck Trading Trader StrategyCanuck Trading Trader Strategy
Overview
The Canuck Trading Trader Strategy is a high-performance, trend-following trading system designed for NASDAQ:TSLA on a 15-minute timeframe. Optimized for precision and profitability, this strategy leverages short-term price trends to capture consistent gains while maintaining robust risk management. Ideal for traders seeking an automated, data-driven approach to trading Tesla’s volatile market, it delivers strong returns with controlled drawdowns.
Key Features
Trend-Based Entries: Identifies short-term trends using a 2-candle lookback period and a minimum trend strength of 0.2%, ensuring responsive trade signals.
Risk Management: Includes a configurable 3.0% stop-loss to cap losses and a 2.0% take-profit to lock in gains, balancing risk and reward.
High Precision: Utilizes bar magnification for accurate backtesting, reflecting realistic trade execution with 1-tick slippage and 0.1 commission.
Clean Interface: No on-chart indicators, providing a distraction-free trading experience focused on performance.
Flexible Sizing: Allocates 10% of equity per trade with support for up to 2 simultaneous positions (pyramiding).
Performance Highlights
Backtested from March 1, 2024, to June 20, 2025, on NASDAQ:TSLA (15-minute timeframe) with $1,000,000 initial capital:
Net Profit: $2,279,888.08 (227.99%)
Win Rate: 52.94% (3,039 winning trades out of 5,741)
Profit Factor: 3.495
Max Drawdown: 2.20%
Average Winning Trade: $1,050.91 (0.55%)
Average Losing Trade: $338.20 (0.18%)
Sharpe Ratio: 2.468
Note: Past performance is not indicative of future results. Always validate with your own backtesting and forward testing.
Usage Instructions
Setup:
Apply the strategy to a NASDAQ:TSLA 15-minute chart.
Ensure your TradingView account supports bar magnification for accurate results.
Configuration:
Lookback Candles: Default is 2 (recommended).
Min Trend Strength: Set to 0.2% for optimal trade frequency.
Stop Loss: Default 3.0% to cap losses.
Take Profit: Default 2.0% to secure gains.
Order Size: 10% of equity per trade.
Pyramiding: Allows up to 2 orders.
Commission: Set to 0.1.
Slippage: Set to 1 tick.
Enable "Recalculate After Order is Filled" and "Recalculate on Every Tick" in backtest settings.
Backtesting:
Run backtests over March 1, 2024, to June 20, 2025, to verify performance.
Adjust stop-loss (e.g., 2.5%) or take-profit (e.g., 1–3%) to suit your risk tolerance.
Live Trading:
Use with a compatible broker or TradingView alerts for automated execution.
Monitor execution for slippage or latency, especially given the high trade frequency (5,741 trades).
Validate in a demo account before deploying with real capital.
Risk Disclosure
Trading involves significant risk and may result in losses exceeding your initial capital. The Canuck Trading Trader Strategy is provided for educational and informational purposes only. Users are responsible for their own trading decisions and should conduct thorough testing before using in live markets. The strategy’s high trade frequency requires reliable execution infrastructure to minimize slippage and latency.
Intermarket Correlation Oscillator (ICO)The Intermarket Correlation Oscillator (ICO) is a TradingView indicator that helps traders analyze the relationship between two assets, such as stocks, indices, or cryptocurrencies, by measuring their price correlation. It displays this correlation as an oscillator ranging from -1 to +1, making it easy to spot whether the assets move together, oppositely, or independently. A value near +1 indicates strong positive correlation (assets move in the same direction), near -1 shows strong negative correlation (opposite movements), and near 0 suggests no correlation. This tool is ideal for confirming trends, spotting divergences, or identifying hedging opportunities across markets.
How It Works?
The ICO calculates the Pearson correlation coefficient between the chart’s primary asset (e.g., Apple stock) and a secondary asset you choose (e.g., SPY for the S&P 500) over a specified number of bars (default: 20). The oscillator is plotted in a separate pane below the chart, with key levels at +0.8 (overbought, strong positive correlation) and -0.8 (oversold, strong negative correlation). A midline at 0 helps gauge neutral correlation. When the oscillator crosses these levels or the midline, labels ("OB" for overbought, "OS" for oversold) and alerts notify you of significant shifts. Shaded zones highlight extreme correlations (red for overbought, green for oversold) if enabled.
Why Use the ICO?
Trend Confirmation: High positive correlation (e.g., SPY and QQQ both rising) confirms market trends.
Divergence Detection: Negative correlation (e.g., DXY rising while stocks fall) signals potential reversals.
Hedging: Identify negatively correlated assets to balance your portfolio.
Market Insights: Understand how assets like stocks, bonds, or crypto interact.
Easy Steps to Use the ICO in TradingView
Add the Indicator:
Open TradingView and load your chart (e.g., AAPL on a daily timeframe).
Go to the Pine Editor at the bottom of the TradingView window.
Copy and paste the ICO script provided earlier.
Click "Add to Chart" to display the oscillator below your price chart.
Configure Settings:
Click the gear icon next to the indicator’s name in the chart pane to open settings.
Secondary Symbol: Choose an asset to compare with your chart’s symbol (e.g., "SPY" for S&P 500, "DXY" for USD Index, or "BTCUSD" for Bitcoin). Default is SPY.
Correlation Lookback Period: Set the number of bars for calculation (default: 20). Use 10-14 for short-term trading or 50 for longer-term analysis.
Overbought/Oversold Levels: Adjust thresholds (default: +0.8 for overbought, -0.8 for oversold) to suit your strategy. Lower values (e.g., ±0.7) give more signals.
Show Midline/Zones: Check boxes to display the zero line and shaded overbought/oversold zones for visual clarity.
Interpret the Oscillator:
Above +0.8: Strong positive correlation (red zone). Assets move together.
Below -0.8: Strong negative correlation (green zone). Assets move oppositely.
Near 0: No clear relationship (midline reference).
Labels: "OB" or "OS" appears when crossing overbought/oversold levels, signaling potential correlation shifts.
Set Up Alerts:
Right-click the indicator, select "Add Alert."
Choose conditions like "Overbought Alert" (crossing above +0.8), "Oversold Alert" (crossing below -0.8), or zero-line crossings for bullish/bearish correlation shifts.
Configure notifications (e.g., email, SMS) to stay informed.
Apply to Trading:
Use positive correlation to confirm trades (e.g., buy AAPL if SPY is rising and correlation is high).
Spot divergences for reversals (e.g., stocks dropping while DXY rises with negative correlation).
Combine with other indicators like RSI or moving averages for stronger signals.
Tips for New Users
Start with related assets (e.g., SPY and QQQ for tech stocks) to see clear correlations.
Test on a demo account to understand signals before trading live.
Be aware that correlation is a lagging indicator; confirm signals with price action.
If the secondary symbol doesn’t load, ensure it’s valid on TradingView (e.g., use correct ticker format).
The ICO is a powerful, beginner-friendly tool to explore intermarket relationships, enhancing your trading decisions with clear visual cues and alerts.
TAIndicatorsThis library offers a comprehensive suite of enhanced technical indicator functions, building upon TradingView's built-in indicators. The primary advantage of this library is its expanded flexibility, allowing you to select from a wider range of moving average types for calculations and smoothing across various indicators.
The core difference between these functions and TradingView's standard ones is the ability to specify different moving average types beyond the default. While a standard ta.rsi() is fixed, the rsi() in this library, for example, can be smoothed by an 'SMMA (RMA)', 'WMA', 'VWMA', or others, giving you greater control over your analysis.
█ FEATURES
This library provides enhanced versions of the following popular indicators:
Moving Average (ma): A versatile MA function that includes optional secondary smoothing and Bollinger Bands.
RSI (rsi): Calculate RSI with an optional smoothed signal line using various MA types, plus built-in divergence detection.
MACD (macd): A MACD function where you can define the MA type for both the main calculation and the signal line.
ATR (atr): An ATR function that allows for different smoothing types.
VWAP (vwap): A comprehensive anchored VWAP with multiple configurable bands.
ADX (adx): A standard ADX calculation.
Cumulative Volume Delta (cvd): Provides CVD data based on a lower timeframe.
Bollinger Bands (bb): Create Bollinger Bands with a customizable MA type for the basis line.
Keltner Channels (kc): Keltner Channels with selectable MA types and band styles.
On-Balance Volume (obv): An OBV indicator with an optional smoothed signal line using various MA types.
... and more to come! This library will be actively maintained, with new useful indicator functions added over time.
█ HOW TO USE
To use this library in your scripts, import it using its publishing link. You can then call the functions directly.
For example, to calculate a Weighted Moving Average (WMA) and then smooth it with a Simple Moving Average (SMA) :
import ActiveQuants/TAIndicators/1 as tai
// Calculate a 20-period WMA of the close
// Then, smooth the result with a 10-period SMA
= tai.ma("WMA", close, 20, "SMA", 10)
plot(myWma, color = color.blue)
plot(smoothedWma, color = color.orange)
█ Why Choose This Library?
If you're looking for more control and customization than what's offered by the standard built-in functions, this library is for you. By allowing for a variety of smoothing methods across multiple indicators, it enables a more nuanced and personalized approach to technical analysis. Fine-tune your indicators to better fit your trading style and strategies.
Trend Flow Trail [AlgoAlpha]OVERVIEW
This script overlays a custom hybrid indicator called the Money Flow Trail which combines a volatility-based trend-following trail with a volume-weighted momentum oscillator. It’s built around two core components: the AlphaTrail—a dynamic band system influenced by Hull MA and volatility—and a smoothed Money Flow Index (MFI) that provides insights into buying or selling pressure. Together, these tools are used to color bars, generate potential reversal markers, and assist traders in identifying trend continuation or exhaustion phases in any market or timeframe.
CONCEPTS
The AlphaTrail calculates a volatility-adjusted channel around price using the Hull Moving Average as the base and an EMA of range as the spread. It adaptively shifts based on price interaction to capture trend reversals while avoiding whipsaws. The direction (bullish or bearish) determines both the band being tracked and how the trail locks in. The Money Flow Index (MFI) is derived from hlc3 and volume, measuring buying vs selling pressure, and is further smoothed with a short Hull MA to reduce noise while preserving structure. These two systems work in tandem: AlphaTrail governs directional context, while MFI refines the timing.
FEATURES
Dynamic AlphaTrail line with regime switching logic that controls directional bias and bar coloring.
Smoothed MFI with gradient coloring to visually communicate pressure and exhaustion levels.
Overbought/oversold thresholds (80/20), mid-level (50), and custom extreme zones (90/10) for deeper signal granularity.
Built-in take-profit signal logic: crossover of MFI into overbought with bullish AlphaTrail, or into oversold with bearish AlphaTrail.
Visual fills between price and AlphaTrail for clearer confirmation during trend phases.
Alerts for regime shifts, MFI crossovers, trail interactions, and bar color regime changes.
USAGE
Add the indicator to any chart. Use the AlphaTrail plot to define trend context: bullish (trailing below price) or bearish (trailing above). MFI values give supporting confirmation—favor long setups when MFI is rising and above 50 in a bullish regime, and shorts when MFI is falling and below 50 in a bearish regime. The colored fills help visually track strength; sharp changes in MFI crossing 80/20 or 90/10 zones often precede pullbacks or reversals. Use the plotted circles as optional take-profit signals when MFI and trend are extended. Adjust AlphaTrail length/multiplier and MFI smoothing to better match the asset’s volatility profile.
MTF RSI MA System + Adaptive BandsMTF RSI MA System + Adaptive Bands
Overview
MTF RSI MA System + Adaptive Bands is a highly customizable Pine Script indicator for traders seeking a versatile tool for multi-timeframe (MTF) analysis. Unlike traditional RSI, it focuses on the Moving Average of RSI (RSI MA), delivering smoother and more flexible trading signals. The main screenshot displays the indicator in two panels to showcase its diverse capabilities.
Important: Timeframes do not adjust automatically – users must manually set them to match the chart’s timeframe.
Features
Core Component: Built around RSI MA, not raw RSI, for smoother trend signals.
Multi-Timeframe: Analyze RSI MA across three customizable timeframes (default: 4H, 8H, 12H).
Adaptive Bands: Three band calculation methods (Fixed, Percent, StdDev) for dynamic signals.
Flexible Signals: Generated via RSI MA crossovers, band interactions, or directional alignment across timeframes.
Background Coloring: Highlights when RSI MAs across timeframes move in the same direction, aiding trend confirmation.
Screenshot Panels Configuration
Upper Panel: Shows RSI, RSI MA, and fixed bands for reversal strategies (RSI crossing bands).
Lower Panel: Displays three RSI MAs (Alligator-style) for trend-following, with background coloring for directional alignment.
Band Calculation Methods
The indicator offers three ways to calculate bands around RSI MA, each with unique characteristics:
Fixed Bands
Set at a fixed point value (default: 10) above and below RSI MA.
Example: If RSI MA = 50, band value = 10 → upper band = 60, lower = 40.
Use Case: Best for stable markets or fixed-range preferences.
Tip: Adjust the band value to widen or narrow the range based on asset volatility.
Percent Bands
Calculated as a percentage of RSI MA (default: 10%).
Example: If RSI MA = 50, band value = 10% → upper band = 55, lower = 45.
Use Case: Ideal for assets with varying volatility, as bands scale with RSI MA.
Tip: Experiment with percentage values to match typical price swings.
Standard Deviation Bands (StdDev)
Based on RSI’s standard deviation over the MA period, multiplied by a user-defined factor (default: 10).
Example: If RSI MA = 50, standard deviation = 5, factor = 2 → upper band = 60, lower = 40.
Important: The default value (10) may produce wide bands. Reduce to 1–2 for tighter, practical bands.
Use Case: Best for dynamic markets with fluctuating volatility.
Configuration Options
RSI Length: Set RSI calculation period (default: 20).
MA Length: Set RSI MA period (default: 20).
MA Type: Choose SMA or EMA for RSI MA (default: EMA).
Timeframes: Configure three timeframes (default: 4H, 8H, 12H) for MTF analysis.
Overbought/Oversold Levels: Optionally display fixed levels (default: 70/30).
Background Coloring: Enable/disable for each timeframe to highlight directional alignment.
How to Use
Add Indicator: Load it onto your TradingView chart.
Setup:
Reversals: Configure like the upper panel (RSI, RSI MA, bands) and watch for RSI crossing bands.
Trends: Configure like the lower panel (three RSI MAs) and look for fastest MA crossovers and background coloring.
Adjust Timeframes: Manually set tf1, tf2, tf3 (e.g., 1H, 2H, 4H on a 1H chart) to suit your strategy.
Adjust Bands: Choose band type (Fixed, Percent, StdDev) and value. For StdDev, reduce to 1–2 for tighter bands.
Experiment: Test settings to match your trading style, whether scalping, swing trading, or long-term.
Notes
Timeframes: Always match tf1, tf2, tf3 to your chart’s needs, as they don’t auto-adjust.
StdDev Bands: Lower the default value (10) to avoid overly wide bands.
Versatility: Works across markets (stocks, forex, crypto).
Copper to Gold Ratioratio = copper / gold: Calculates the ratio by dividing copper price by gold price.
plot(ratio): Plots the ratio as a blue line.
ma = ta.sma(ratio, 20): Adds a 20-period simple moving average (optional) to smooth the ratio, plotted as a red line.
A rising Copper/Gold ratio often signals economic expansion (strong copper demand relative to gold), while a falling ratio may indicate economic uncertainty or recession fears, as gold outperforms copper.
The ratio is also used as a leading indicator for 10-year U.S. Treasury yields, with a rising ratio often correlating with higher yields.
X-Day Capital Efficiency ScoreThis indicator helps identify the Most Profitable Movers for Your fixed Capital (ie, which assets offer the best average intraday profit potential for a fixed capital).
Unlike traditional volatility indicators (like ATR or % change), this script calculates how much real dollar profit you could have made each day over a custom lookback period — assuming you deployed your full capital into that ticker daily.
How it works:
Calculates the daily intraday range (high − low)
Filters for clean candles (where body > 60% of the candle range)
Assumes you invested the full amount of capital ($100K set as default) on each valid day
Computes an average daily profit score based on price action over the selected period (default set to 20 days)
Plots the score in dollars — higher = more efficient use of capital
Why It’s Useful:
Compare tickers based on real dollar return potential — not just % volatility
Spot low-priced, high-volatility stocks that are better suited for intraday or momentum trading
Inputs:
Capital ($): Amount you're hypothetically deploying (e.g., 100,000)
Look Back Period: Number of past days to average over (e.g., 20)
Linear Regression Forecast (ADX Adaptive)Linear Regression Forecast (ADX Adaptive)
This indicator is a dynamic price projection tool that combines multiple linear regression forecasts into a single, adaptive forecast curve. By integrating trend strength via the ADX and directional bias, it aims to visualize how price might evolve in different market environments—from strong trends to mean-reverting conditions.
Core Concept:
This tool builds forward price projections based on a blend of linear regression models with varying lookback lengths (from 2 up to a user-defined max). It then adjusts those projections using two key mechanisms:
ADX-Weighted Forecast Blending
In trending conditions (high ADX), the model follows the raw forecast direction. In ranging markets (low ADX), the forecast flips or reverts, biasing toward mean-reversion. A logistic transformation of directional bias, controlled by a steepness parameter, determines how aggressively this blending reacts to price behavior.
Volatility Scaling
The forecast’s magnitude is scaled based on ADX and directional conviction. When trends are unclear (low ADX or neutral bias), the projection range expands to reflect greater uncertainty and volatility.
How It Works:
Regression Curve Generation
For each regression length from 2 to maxLength, a forward projection is calculated using least-squares linear regression on the selected price source. These forecasts are extrapolated into the future.
Directional Bias Calculation
The forecasted points are analyzed to determine a normalized bias value in the range -1 to +1, where +1 means strongly bullish, -1 means strongly bearish, and 0 means neutral.
Logistic Bias Transformation
The raw bias is passed through a logistic sigmoid function, with a user-defined steepness. This creates a probability-like weight that favors either following or reversing the forecast depending on market context.
ADX-Based Weighting
ADX determines the weighting between trend-following and mean-reversion modes. Below ADX 20, the model favors mean-reversion. Above 25, it favors trend-following. Between 20 and 25, it linearly blends the two.
Blended Forecast Curve
Each forecast point is blended between trend-following and mean-reverting values, scaled for volatility.
What You See:
Forecast Lines: Projected future price paths drawn in green or red depending on direction.
Bias Plot: A separate plot showing post-blend directional bias as a percentage, where +100 is strongly bullish and -100 is strongly bearish.
Neutral Line: A dashed horizontal line at 0 percent bias to indicate neutrality.
User Inputs:
-Max Regression Length
-Price Source
-Line Width
-Bias Steepness
-ADX Length and Smoothing
Use Cases:
Visualize expected price direction under different trend conditions
Adjust trading behavior depending on trending vs ranging markets
Combine with other tools for deeper analysis
Important Notes:
This indicator is for visualization and analysis only. It does not provide buy or sell signals and should not be used in isolation. It makes assumptions based on historical price action and should be interpreted with market context.
light_logLight Log - A Defensive Programming Library for Pine Script
Overview
The Light Log library transforms Pine Script development by introducing structured logging and defensive programming patterns typically found in enterprise languages like C#. This library addresses a fundamental challenge in Pine Script: the lack of sophisticated error handling and debugging tools that developers expect when building complex trading systems.
At its core, Light Log provides three transformative capabilities that work together to create more reliable and maintainable code. First, it wraps all native Pine Script types in error-aware containers, allowing values to carry validation state alongside their data. Second, it offers a comprehensive logging system with severity levels and conditional rendering. Third, it includes defensive programming utilities that catch errors early and make code self-documenting.
The Philosophy of Errors as Values
Traditional Pine Script error handling relies on runtime errors that halt execution, making it difficult to build resilient systems that can gracefully handle edge cases. Light Log introduces a paradigm shift by treating errors as first-class values that flow through your program alongside regular data.
When you wrap a value using Light Log's type system, you're not just storing data – you're creating a container that can carry both the value and its validation state. For example, when you call myNumber.INT() , you receive an INT object that contains both the integer value and a Log object that can describe any issues with that value. This approach, inspired by functional programming languages, allows errors to propagate through calculations without causing immediate failures.
Consider how this changes error handling in practice. Instead of a calculation failing catastrophically when it encounters invalid input, it can produce a result object that contains both the computed value (which might be na) and a detailed log explaining what went wrong. Subsequent operations can check has_error() to decide whether to proceed or handle the error condition gracefully.
The Typed Wrapper System
Light Log provides typed wrappers for every native Pine Script type: INT, FLOAT, BOOL, STRING, COLOR, LINE, LABEL, BOX, TABLE, CHART_POINT, POLYLINE, and LINEFILL. These wrappers serve multiple purposes beyond simple value storage.
Each wrapper type contains two fields: the value field v holds the actual data, while the error field e contains a Log object that tracks the value's validation state. This dual nature enables powerful programming patterns. You can perform operations on wrapped values and accumulate error information along the way, creating an audit trail of how values were processed.
The wrapper system includes convenient methods for converting between wrapped and unwrapped values. The extension methods like INT() , FLOAT() , etc., make it easy to wrap existing values, while the from_INT() , from_FLOAT() methods extract the underlying values when needed. The has_error() method provides a consistent interface for checking whether any wrapped value has encountered issues during processing.
The Log Object: Your Debugging Companion
The Log object represents the heart of Light Log's debugging capabilities. Unlike simple string concatenation for error messages, the Log object provides a structured approach to building, modifying, and rendering diagnostic information.
Each Log object carries three essential pieces of information: an error type (info, warning, error, or runtime_error), a message string that can be built incrementally, and an active flag that controls conditional rendering. This structure enables sophisticated logging patterns where you can build up detailed diagnostic information throughout your script's execution and decide later whether and how to display it.
The Log object's methods support fluent chaining, allowing you to build complex messages in a readable way. The write() and write_line() methods append text to the log, while new_line() adds formatting. The clear() method resets the log for reuse, and the rendering methods ( render_now() , render_condition() , and the general render() ) control when and how messages appear.
Defensive Programming Made Easy
Light Log's argument validation functions transform how you write defensive code. Instead of cluttering your functions with verbose validation logic, you can use concise, self-documenting calls that make your intentions clear.
The argument_error() function provides strict validation that halts execution when conditions aren't met – perfect for catching programming errors early. For less critical issues, argument_log_warning() and argument_log_error() record problems without stopping execution, while argument_log_info() provides debug visibility into your function's behavior.
These functions follow a consistent pattern: they take a condition to check, the function name, the argument name, and a descriptive message. This consistency makes error messages predictable and helpful, automatically formatting them to show exactly where problems occurred.
Building Modular, Reusable Code
Light Log encourages a modular approach to Pine Script development by providing tools that make functions more self-contained and reliable. When functions validate their inputs and return wrapped values with error information, they become true black boxes that can be safely composed into larger systems.
The void_return() function addresses Pine Script's requirement that all code paths return a value, even in error handling branches. This utility function provides a clean way to satisfy the compiler while making it clear that a particular code path should never execute.
The static log pattern, initialized with init_static_log() , enables module-wide error tracking. You can create a persistent Log object that accumulates information across multiple function calls, building a comprehensive diagnostic report that helps you understand complex behaviors in your indicators and strategies.
Real-World Applications
In practice, Light Log shines when building sophisticated trading systems. Imagine developing a complex indicator that processes multiple data streams, performs statistical calculations, and generates trading signals. With Light Log, each processing stage can validate its inputs, perform calculations, and pass along both results and diagnostic information.
For example, a moving average calculation might check that the period is positive, that sufficient data exists, and that the input series contains valid values. Instead of failing silently or throwing runtime errors, it can return a FLOAT object that contains either the calculated average or a detailed explanation of why the calculation couldn't be performed.
Strategy developers benefit even more from Light Log's capabilities. Complex entry and exit logic often involves multiple conditions that must all be satisfied. With Light Log, each condition check can contribute to a comprehensive log that explains exactly why a trade was or wasn't taken, making strategy debugging and optimization much more straightforward.
Performance Considerations
While Light Log adds a layer of abstraction over raw Pine Script values, its design minimizes performance impact. The wrapper objects are lightweight, containing only two fields. The logging operations only consume resources when actually rendered, and the conditional rendering system ensures that production code can run with logging disabled for maximum performance.
The library follows Pine Script best practices for performance, using appropriate data structures and avoiding unnecessary operations. The var keyword in init_static_log() ensures that persistent logs don't create new objects on every bar, maintaining efficiency even in real-time calculations.
Getting Started
Adopting Light Log in your Pine Script projects is straightforward. Import the library, wrap your critical values, add validation to your functions, and use Log objects to track important events. Start small by adding logging to a single function, then expand as you see the benefits of better error visibility and code organization.
Remember that Light Log is designed to grow with your needs. You can use as much or as little of its functionality as makes sense for your project. Even simple uses, like adding argument validation to key functions, can significantly improve code reliability and debugging ease.
Transform your Pine Script development experience with Light Log – because professional trading systems deserve professional development tools.
Light Log Technical Deep Dive: Advanced Patterns and Architecture
Understanding Errors as Values
The concept of "errors as values" represents a fundamental shift in how we think about error handling in Pine Script. In traditional Pine Script development, errors are events – they happen at a specific moment in time and immediately interrupt program flow. Light Log transforms errors into data – they become information that flows through your program just like any other value.
This transformation has profound implications. When errors are values, they can be stored, passed between functions, accumulated, transformed, and inspected. They become part of your program's data flow rather than exceptions to it. This approach, popularized by languages like Rust with its Result type and Haskell with its Either monad, brings functional programming's elegance to Pine Script.
Consider a practical example. Traditional Pine Script might calculate a momentum indicator like this:
momentum = close - close
If period is invalid or if there isn't enough historical data, this calculation might produce na or cause subtle bugs. With Light Log's approach:
calculate_momentum(src, period)=>
result = src.FLOAT()
if period <= 0
result.e.write("Invalid period: must be positive", true, ErrorType.error)
result.v := na
else if bar_index < period
result.e.write("Insufficient data: need " + str.tostring(period) + " bars", true, ErrorType.warning)
result.v := na
else
result.v := src - src
result.e.write("Momentum calculated successfully", false, ErrorType.info)
result
Now the function returns not just a value but a complete computational result that includes diagnostic information. Calling code can make intelligent decisions based on both the value and its associated metadata.
The Monad Pattern in Pine Script
While Pine Script lacks the type system features to implement true monads, Light Log brings monadic thinking to Pine Script development. The wrapped types (INT, FLOAT, etc.) act as computational contexts that carry both values and metadata through a series of transformations.
The key insight of monadic programming is that you can chain operations while automatically propagating context. In Light Log, this context is the error state. When you have a FLOAT that contains an error, operations on that FLOAT can check the error state and decide whether to proceed or propagate the error.
This pattern enables what functional programmers call "railway-oriented programming" – your code follows a success track when all is well but can switch to an error track when problems occur. Both tracks lead to the same destination (a result with error information), but they take different paths based on the validity of intermediate values.
Composable Error Handling
Light Log's design encourages composition – building complex functionality from simpler, well-tested components. Each component can validate its inputs, perform its calculation, and return a result with appropriate error information. Higher-level functions can then combine these results intelligently.
Consider building a complex trading signal from multiple indicators:
generate_signal(src, fast_period, slow_period, signal_period) =>
log = init_static_log(ErrorType.info)
// Calculate components with error tracking
fast_ma = calculate_ma(src, fast_period)
slow_ma = calculate_ma(src, slow_period)
// Check for errors in components
if fast_ma.has_error()
log.write_line("Fast MA error: " + fast_ma.e.message, true)
if slow_ma.has_error()
log.write_line("Slow MA error: " + slow_ma.e.message, true)
// Proceed with calculation if no errors
signal = 0.0.FLOAT()
if not (fast_ma.has_error() or slow_ma.has_error())
macd_line = fast_ma.v - slow_ma.v
signal_line = calculate_ma(macd_line, signal_period)
if signal_line.has_error()
log.write_line("Signal line error: " + signal_line.e.message, true)
signal.e := log
else
signal.v := macd_line - signal_line.v
log.write("Signal generated successfully")
else
signal.e := log
signal.v := na
signal
This composable approach makes complex calculations more reliable and easier to debug. Each component is responsible for its own validation and error reporting, and the composite function orchestrates these components while maintaining comprehensive error tracking.
The Static Log Pattern
The init_static_log() function introduces a powerful pattern for maintaining state across function calls. In Pine Script, the var keyword creates variables that persist across bars but are initialized only once. Light Log leverages this to create logging objects that can accumulate information throughout a script's execution.
This pattern is particularly valuable for debugging complex strategies where you need to understand behavior across multiple bars. You can create module-level logs that track important events:
// Module-level diagnostic log
diagnostics = init_static_log(ErrorType.info)
// Track strategy decisions across bars
check_entry_conditions() =>
diagnostics.clear() // Start fresh each bar
diagnostics.write_line("Bar " + str.tostring(bar_index) + " analysis:")
if close > sma(close, 20)
diagnostics.write_line("Price above SMA20", false)
else
diagnostics.write_line("Price below SMA20 - no entry", true, ErrorType.warning)
if volume > sma(volume, 20) * 1.5
diagnostics.write_line("Volume surge detected", false)
else
diagnostics.write_line("Normal volume", false)
// Render diagnostics based on verbosity setting
if debug_mode
diagnostics.render_now()
Advanced Validation Patterns
Light Log's argument validation functions enable sophisticated precondition checking that goes beyond simple null checks. You can implement complex validation logic while keeping your code readable:
validate_price_data(open_val, high_val, low_val, close_val) =>
argument_error(na(open_val) or na(high_val) or na(low_val) or na(close_val),
"validate_price_data", "OHLC values", "contain na values")
argument_error(high_val < low_val,
"validate_price_data", "high/low", "high is less than low")
argument_error(close_val > high_val or close_val < low_val,
"validate_price_data", "close", "is outside high/low range")
argument_log_warning(high_val == low_val,
"validate_price_data", "high/low", "are equal (no range)")
This validation function documents its requirements clearly and fails fast with helpful error messages when assumptions are violated. The mix of errors (which halt execution) and warnings (which allow continuation) provides fine-grained control over how strict your validation should be.
Performance Optimization Strategies
While Light Log adds abstraction, careful design minimizes overhead. Understanding Pine Script's execution model helps you use Light Log efficiently.
Pine Script executes once per bar, so operations that seem expensive in traditional programming might have negligible impact. However, when building real-time systems, every optimization matters. Light Log provides several patterns for efficient use:
Lazy Evaluation: Log messages are only built when they'll be rendered. Use conditional logging to avoid string concatenation in production:
if debug_mode
log.write_line("Calculated value: " + str.tostring(complex_calculation))
Selective Wrapping: Not every value needs error tracking. Wrap values at API boundaries and critical calculation points, but use raw values for simple operations:
// Wrap at boundaries
input_price = close.FLOAT()
validated_period = validate_period(input_period).INT()
// Use raw values internally
sum = 0.0
for i = 0 to validated_period.v - 1
sum += close
Error Propagation: When errors occur early, avoid expensive calculations:
process_data(input) =>
validated = validate_input(input)
if validated.has_error()
validated // Return early with error
else
// Expensive processing only if valid
perform_complex_calculation(validated)
Integration Patterns
Light Log integrates smoothly with existing Pine Script code. You can adopt it incrementally, starting with critical functions and expanding coverage as needed.
Boundary Validation: Add Light Log at the boundaries of your system – where user input enters and where final outputs are produced. This catches most errors while minimizing changes to existing code.
Progressive Enhancement: Start by adding argument validation to existing functions. Then wrap return values. Finally, add comprehensive logging. Each step improves reliability without requiring a complete rewrite.
Testing and Debugging: Use Light Log's conditional rendering to create debug modes for your scripts. Production users see clean output while developers get detailed diagnostics:
// User input for debug mode
debug = input.bool(false, "Enable debug logging")
// Conditional diagnostic output
if debug
diagnostics.render_now()
else
diagnostics.render_condition() // Only shows errors/warnings
Future-Proofing Your Code
Light Log's patterns prepare your code for Pine Script's evolution. As Pine Script adds more sophisticated features, code that uses structured error handling and defensive programming will adapt more easily than code that relies on implicit assumptions.
The type wrapper system, in particular, positions your code to take advantage of potential future features or more sophisticated type inference. By thinking in terms of wrapped values and error propagation today, you're building code that will remain maintainable and extensible tomorrow.
Light Log doesn't just make your Pine Script better today – it prepares it for the trading systems you'll need to build tomorrow.
Library "light_log"
A lightweight logging and defensive programming library for Pine Script.
Designed for modular and extensible scripts, this utility provides structured runtime validation,
conditional logging, and reusable `Log` objects for centralized error propagation.
It also introduces a typed wrapping system for all native Pine values (e.g., `INT`, `FLOAT`, `LABEL`),
allowing values to carry errors alongside data. This enables functional-style flows with built-in
validation tracking, error detection (`has_error()`), and fluent chaining.
Inspired by structured logging patterns found in systems like C#, it reduces boilerplate,
enforces argument safety, and encourages clean, maintainable code architecture.
method INT(self, error_type)
Wraps an `int` value into an `INT` struct with an optional log severity.
Namespace types: series int, simple int, input int, const int
Parameters:
self (int) : The raw `int` value to wrap.
error_type (series ErrorType) : Optional severity level to associate with the log. Default is `ErrorType.error`.
Returns: An `INT` object containing the value and a default Log instance.
method FLOAT(self, error_type)
Wraps a `float` value into a `FLOAT` struct with an optional log severity.
Namespace types: series float, simple float, input float, const float
Parameters:
self (float) : The raw `float` value to wrap.
error_type (series ErrorType) : Optional severity level to associate with the log. Default is `ErrorType.error`.
Returns: A `FLOAT` object containing the value and a default Log instance.
method BOOL(self, error_type)
Wraps a `bool` value into a `BOOL` struct with an optional log severity.
Namespace types: series bool, simple bool, input bool, const bool
Parameters:
self (bool) : The raw `bool` value to wrap.
error_type (series ErrorType) : Optional severity level to associate with the log. Default is `ErrorType.error`.
Returns: A `BOOL` object containing the value and a default Log instance.
method STRING(self, error_type)
Wraps a `string` value into a `STRING` struct with an optional log severity.
Namespace types: series string, simple string, input string, const string
Parameters:
self (string) : The raw `string` value to wrap.
error_type (series ErrorType) : Optional severity level to associate with the log. Default is `ErrorType.error`.
Returns: A `STRING` object containing the value and a default Log instance.
method COLOR(self, error_type)
Wraps a `color` value into a `COLOR` struct with an optional log severity.
Namespace types: series color, simple color, input color, const color
Parameters:
self (color) : The raw `color` value to wrap.
error_type (series ErrorType) : Optional severity level to associate with the log. Default is `ErrorType.error`.
Returns: A `COLOR` object containing the value and a default Log instance.
method LINE(self, error_type)
Wraps a `line` object into a `LINE` struct with an optional log severity.
Namespace types: series line
Parameters:
self (line) : The raw `line` object to wrap.
error_type (series ErrorType) : Optional severity level to associate with the log. Default is `ErrorType.error`.
Returns: A `LINE` object containing the value and a default Log instance.
method LABEL(self, error_type)
Wraps a `label` object into a `LABEL` struct with an optional log severity.
Namespace types: series label
Parameters:
self (label) : The raw `label` object to wrap.
error_type (series ErrorType) : Optional severity level to associate with the log. Default is `ErrorType.error`.
Returns: A `LABEL` object containing the value and a default Log instance.
method BOX(self, error_type)
Wraps a `box` object into a `BOX` struct with an optional log severity.
Namespace types: series box
Parameters:
self (box) : The raw `box` object to wrap.
error_type (series ErrorType) : Optional severity level to associate with the log. Default is `ErrorType.error`.
Returns: A `BOX` object containing the value and a default Log instance.
method TABLE(self, error_type)
Wraps a `table` object into a `TABLE` struct with an optional log severity.
Namespace types: series table
Parameters:
self (table) : The raw `table` object to wrap.
error_type (series ErrorType) : Optional severity level to associate with the log. Default is `ErrorType.error`.
Returns: A `TABLE` object containing the value and a default Log instance.
method CHART_POINT(self, error_type)
Wraps a `chart.point` value into a `CHART_POINT` struct with an optional log severity.
Namespace types: chart.point
Parameters:
self (chart.point) : The raw `chart.point` value to wrap.
error_type (series ErrorType) : Optional severity level to associate with the log. Default is `ErrorType.error`.
Returns: A `CHART_POINT` object containing the value and a default Log instance.
method POLYLINE(self, error_type)
Wraps a `polyline` object into a `POLYLINE` struct with an optional log severity.
Namespace types: series polyline, series polyline, series polyline, series polyline
Parameters:
self (polyline) : The raw `polyline` object to wrap.
error_type (series ErrorType) : Optional severity level to associate with the log. Default is `ErrorType.error`.
Returns: A `POLYLINE` object containing the value and a default Log instance.
method LINEFILL(self, error_type)
Wraps a `linefill` object into a `LINEFILL` struct with an optional log severity.
Namespace types: series linefill
Parameters:
self (linefill) : The raw `linefill` object to wrap.
error_type (series ErrorType) : Optional severity level to associate with the log. Default is `ErrorType.error`.
Returns: A `LINEFILL` object containing the value and a default Log instance.
method from_INT(self)
Extracts the integer value from an INT wrapper.
Namespace types: INT
Parameters:
self (INT) : The wrapped INT instance.
Returns: The underlying `int` value.
method from_FLOAT(self)
Extracts the float value from a FLOAT wrapper.
Namespace types: FLOAT
Parameters:
self (FLOAT) : The wrapped FLOAT instance.
Returns: The underlying `float` value.
method from_BOOL(self)
Extracts the boolean value from a BOOL wrapper.
Namespace types: BOOL
Parameters:
self (BOOL) : The wrapped BOOL instance.
Returns: The underlying `bool` value.
method from_STRING(self)
Extracts the string value from a STRING wrapper.
Namespace types: STRING
Parameters:
self (STRING) : The wrapped STRING instance.
Returns: The underlying `string` value.
method from_COLOR(self)
Extracts the color value from a COLOR wrapper.
Namespace types: COLOR
Parameters:
self (COLOR) : The wrapped COLOR instance.
Returns: The underlying `color` value.
method from_LINE(self)
Extracts the line object from a LINE wrapper.
Namespace types: LINE
Parameters:
self (LINE) : The wrapped LINE instance.
Returns: The underlying `line` object.
method from_LABEL(self)
Extracts the label object from a LABEL wrapper.
Namespace types: LABEL
Parameters:
self (LABEL) : The wrapped LABEL instance.
Returns: The underlying `label` object.
method from_BOX(self)
Extracts the box object from a BOX wrapper.
Namespace types: BOX
Parameters:
self (BOX) : The wrapped BOX instance.
Returns: The underlying `box` object.
method from_TABLE(self)
Extracts the table object from a TABLE wrapper.
Namespace types: TABLE
Parameters:
self (TABLE) : The wrapped TABLE instance.
Returns: The underlying `table` object.
method from_CHART_POINT(self)
Extracts the chart.point from a CHART_POINT wrapper.
Namespace types: CHART_POINT
Parameters:
self (CHART_POINT) : The wrapped CHART_POINT instance.
Returns: The underlying `chart.point` value.
method from_POLYLINE(self)
Extracts the polyline object from a POLYLINE wrapper.
Namespace types: POLYLINE
Parameters:
self (POLYLINE) : The wrapped POLYLINE instance.
Returns: The underlying `polyline` object.
method from_LINEFILL(self)
Extracts the linefill object from a LINEFILL wrapper.
Namespace types: LINEFILL
Parameters:
self (LINEFILL) : The wrapped LINEFILL instance.
Returns: The underlying `linefill` object.
method has_error(self)
Returns true if the INT wrapper has an active log entry.
Namespace types: INT
Parameters:
self (INT) : The INT instance to check.
Returns: True if an error or message is active in the log.
method has_error(self)
Returns true if the FLOAT wrapper has an active log entry.
Namespace types: FLOAT
Parameters:
self (FLOAT) : The FLOAT instance to check.
Returns: True if an error or message is active in the log.
method has_error(self)
Returns true if the BOOL wrapper has an active log entry.
Namespace types: BOOL
Parameters:
self (BOOL) : The BOOL instance to check.
Returns: True if an error or message is active in the log.
method has_error(self)
Returns true if the STRING wrapper has an active log entry.
Namespace types: STRING
Parameters:
self (STRING) : The STRING instance to check.
Returns: True if an error or message is active in the log.
method has_error(self)
Returns true if the COLOR wrapper has an active log entry.
Namespace types: COLOR
Parameters:
self (COLOR) : The COLOR instance to check.
Returns: True if an error or message is active in the log.
method has_error(self)
Returns true if the LINE wrapper has an active log entry.
Namespace types: LINE
Parameters:
self (LINE) : The LINE instance to check.
Returns: True if an error or message is active in the log.
method has_error(self)
Returns true if the LABEL wrapper has an active log entry.
Namespace types: LABEL
Parameters:
self (LABEL) : The LABEL instance to check.
Returns: True if an error or message is active in the log.
method has_error(self)
Returns true if the BOX wrapper has an active log entry.
Namespace types: BOX
Parameters:
self (BOX) : The BOX instance to check.
Returns: True if an error or message is active in the log.
method has_error(self)
Returns true if the TABLE wrapper has an active log entry.
Namespace types: TABLE
Parameters:
self (TABLE) : The TABLE instance to check.
Returns: True if an error or message is active in the log.
method has_error(self)
Returns true if the CHART_POINT wrapper has an active log entry.
Namespace types: CHART_POINT
Parameters:
self (CHART_POINT) : The CHART_POINT instance to check.
Returns: True if an error or message is active in the log.
method has_error(self)
Returns true if the POLYLINE wrapper has an active log entry.
Namespace types: POLYLINE
Parameters:
self (POLYLINE) : The POLYLINE instance to check.
Returns: True if an error or message is active in the log.
method has_error(self)
Returns true if the LINEFILL wrapper has an active log entry.
Namespace types: LINEFILL
Parameters:
self (LINEFILL) : The LINEFILL instance to check.
Returns: True if an error or message is active in the log.
void_return()
Utility function used when a return is syntactically required but functionally unnecessary.
Returns: Nothing. Function never executes its body.
argument_error(condition, function, argument, message)
Throws a runtime error when a condition is met. Used for strict argument validation.
Parameters:
condition (bool) : Boolean expression that triggers the runtime error.
function (string) : Name of the calling function (for formatting).
argument (string) : Name of the problematic argument.
message (string) : Description of the error cause.
Returns: Never returns. Halts execution if the condition is true.
argument_log_info(condition, function, argument, message)
Logs an informational message when a condition is met. Used for optional debug visibility.
Parameters:
condition (bool) : Boolean expression that triggers the log.
function (string) : Name of the calling function.
argument (string) : Argument name being referenced.
message (string) : Informational message to log.
Returns: Nothing. Logs if the condition is true.
argument_log_warning(condition, function, argument, message)
Logs a warning when a condition is met. Non-fatal but highlights potential issues.
Parameters:
condition (bool) : Boolean expression that triggers the warning.
function (string) : Name of the calling function.
argument (string) : Argument name being referenced.
message (string) : Warning message to log.
Returns: Nothing. Logs if the condition is true.
argument_log_error(condition, function, argument, message)
Logs an error message when a condition is met. Does not halt execution.
Parameters:
condition (bool) : Boolean expression that triggers the error log.
function (string) : Name of the calling function.
argument (string) : Argument name being referenced.
message (string) : Error message to log.
Returns: Nothing. Logs if the condition is true.
init_static_log(error_type, message, active)
Initializes a persistent (var) Log object. Ideal for global logging in scripts or modules.
Parameters:
error_type (series ErrorType) : Initial severity level (required).
message (string) : Optional starting message string. Default value of ("").
active (bool) : Whether the log should be flagged active on initialization. Default value of (false).
Returns: A static Log object with the given parameters.
method new_line(self)
Appends a newline character to the Log message. Useful for separating entries during chained writes.
Namespace types: Log
Parameters:
self (Log) : The Log instance to modify.
Returns: The updated Log object with a newline appended.
method write(self, message, flag_active, error_type)
Appends a message to a Log object without a newline. Updates severity and active state if specified.
Namespace types: Log
Parameters:
self (Log) : The Log instance being modified.
message (string) : The text to append to the log.
flag_active (bool) : Whether to activate the log for conditional rendering. Default value of (false).
error_type (series ErrorType) : Optional override for the severity level. Default value of (na).
Returns: The updated Log object.
method write_line(self, message, flag_active, error_type)
Appends a message to a Log object, prefixed with a newline for clarity.
Namespace types: Log
Parameters:
self (Log) : The Log instance being modified.
message (string) : The text to append to the log.
flag_active (bool) : Whether to activate the log for conditional rendering. Default value of (false).
error_type (series ErrorType) : Optional override for the severity level. Default value of (na).
Returns: The updated Log object.
method clear(self, flag_active, error_type)
Clears a Log object’s message and optionally reactivates it. Can also update the error type.
Namespace types: Log
Parameters:
self (Log) : The Log instance being cleared.
flag_active (bool) : Whether to activate the log after clearing. Default value of (false).
error_type (series ErrorType) : Optional new error type to assign. If not provided, the previous type is retained. Default value of (na).
Returns: The cleared Log object.
method render_condition(self, flag_active, error_type)
Conditionally renders the log if it is active. Allows overriding error type and controlling active state afterward.
Namespace types: Log
Parameters:
self (Log) : The Log instance to evaluate and render.
flag_active (bool) : Whether to activate the log after rendering. Default value of (false).
error_type (series ErrorType) : Optional error type override. Useful for contextual formatting just before rendering. Default value of (na).
Returns: The updated Log object.
method render_now(self, flag_active, error_type)
Immediately renders the log regardless of `active` state. Allows overriding error type and active flag.
Namespace types: Log
Parameters:
self (Log) : The Log instance to render.
flag_active (bool) : Whether to activate the log after rendering. Default value of (false).
error_type (series ErrorType) : Optional error type override. Allows dynamic severity adjustment at render time. Default value of (na).
Returns: The updated Log object.
render(self, condition, flag_active, error_type)
Renders the log conditionally or unconditionally. Allows full control over render behavior.
Parameters:
self (Log) : The Log instance to render.
condition (bool) : If true, renders only if the log is active. If false, always renders. Default value of (false).
flag_active (bool) : Whether to activate the log after rendering. Default value of (false).
error_type (series ErrorType) : Optional error type override passed to the render methods. Default value of (na).
Returns: The updated Log object.
Log
A structured object used to store and render logging messages.
Fields:
error_type (series ErrorType) : The severity level of the message (from the ErrorType enum).
message (series string) : The text of the log message.
active (series bool) : Whether the log should trigger rendering when conditionally evaluated.
INT
A wrapped integer type with attached logging for validation or tracing.
Fields:
v (series int) : The underlying `int` value.
e (Log) : Optional log object describing validation status or error context.
FLOAT
A wrapped float type with attached logging for validation or tracing.
Fields:
v (series float) : The underlying `float` value.
e (Log) : Optional log object describing validation status or error context.
BOOL
A wrapped boolean type with attached logging for validation or tracing.
Fields:
v (series bool) : The underlying `bool` value.
e (Log) : Optional log object describing validation status or error context.
STRING
A wrapped string type with attached logging for validation or tracing.
Fields:
v (series string) : The underlying `string` value.
e (Log) : Optional log object describing validation status or error context.
COLOR
A wrapped color type with attached logging for validation or tracing.
Fields:
v (series color) : The underlying `color` value.
e (Log) : Optional log object describing validation status or error context.
LINE
A wrapped line object with attached logging for validation or tracing.
Fields:
v (series line) : The underlying `line` value.
e (Log) : Optional log object describing validation status or error context.
LABEL
A wrapped label object with attached logging for validation or tracing.
Fields:
v (series label) : The underlying `label` value.
e (Log) : Optional log object describing validation status or error context.
BOX
A wrapped box object with attached logging for validation or tracing.
Fields:
v (series box) : The underlying `box` value.
e (Log) : Optional log object describing validation status or error context.
TABLE
A wrapped table object with attached logging for validation or tracing.
Fields:
v (series table) : The underlying `table` value.
e (Log) : Optional log object describing validation status or error context.
CHART_POINT
A wrapped chart point with attached logging for validation or tracing.
Fields:
v (chart.point) : The underlying `chart.point` value.
e (Log) : Optional log object describing validation status or error context.
POLYLINE
A wrapped polyline object with attached logging for validation or tracing.
Fields:
v (series polyline) : The underlying `polyline` value.
e (Log) : Optional log object describing validation status or error context.
LINEFILL
A wrapped linefill object with attached logging for validation or tracing.
Fields:
v (series linefill) : The underlying `linefill` value.
e (Log) : Optional log object describing validation status or error context.
Multifractal Forecast [ScorsoneEnterprises]Multifractal Forecast Indicator
The Multifractal Forecast is an indicator designed to model and forecast asset price movements using a multifractal framework. It uses concepts from fractal geometry and stochastic processes, specifically the Multifractal Model of Asset Returns (MMAR) and fractional Brownian motion (fBm), to generate price forecasts based on historical price data. The indicator visualizes potential future price paths as colored lines, providing traders with a probabilistic view of price trends over a specified trading time scale. Below is a detailed breakdown of the indicator’s functionality, inputs, calculations, and visualization.
Overview
Purpose: The indicator forecasts future price movements by simulating multiple price paths based on a multifractal model, which accounts for the complex, non-linear behavior of financial markets.
Key Concepts:
Multifractal Model of Asset Returns (MMAR): Models price movements as a multifractal process, capturing varying degrees of volatility and self-similarity across different time scales.
Fractional Brownian Motion (fBm): A generalization of Brownian motion that incorporates long-range dependence and self-similarity, controlled by the Hurst exponent.
Binomial Cascade: Used to model trading time, introducing heterogeneity in time scales to reflect market activity bursts.
Hurst Exponent: Measures the degree of long-term memory in the price series (persistence, randomness, or mean-reversion).
Rescaled Range (R/S) Analysis: Estimates the Hurst exponent to quantify the fractal nature of the price series.
Inputs
The indicator allows users to customize its behavior through several input parameters, each influencing the multifractal model and forecast generation:
Maximum Lag (max_lag):
Type: Integer
Default: 50
Minimum: 5
Purpose: Determines the maximum lag used in the rescaled range (R/S) analysis to calculate the Hurst exponent. A higher lag increases the sample size for Hurst estimation but may smooth out short-term dynamics.
2 to the n values in the Multifractal Model (n):
Type: Integer
Default: 4
Purpose: Defines the resolution of the multifractal model by setting the size of arrays used in calculations (N = 2^n). For example, n=4 results in N=16 data points. Larger n increases computational complexity and detail but may exceed Pine Script’s array size limits (capped at 100,000).
Multiplier for Binomial Cascade (m):
Type: Float
Default: 0.8
Purpose: Controls the asymmetry in the binomial cascade, which models trading time. The multiplier m (and its complement 2.0 - m) determines how mass is distributed across time scales. Values closer to 1 create more balanced cascades, while values further from 1 introduce more variability.
Length Scale for fBm (L):
Type: Float
Default: 100,000.0
Purpose: Scales the fractional Brownian motion output, affecting the amplitude of simulated price paths. Larger values increase the magnitude of forecasted price movements.
Cumulative Sum (cum):
Type: Integer (0 or 1)
Default: 1
Purpose: Toggles whether the fBm output is cumulatively summed (1=On, 0=Off). When enabled, the fBm series is accumulated to simulate a price path with memory, resembling a random walk with long-range dependence.
Trading Time Scale (T):
Type: Integer
Default: 5
Purpose: Defines the forecast horizon in bars (20 bars into the future). It also scales the binomial cascade’s output to align with the desired trading time frame.
Number of Simulations (num_simulations):
Type: Integer
Default: 5
Minimum: 1
Purpose: Specifies how many forecast paths are simulated and plotted. More simulations provide a broader range of possible price outcomes but increase computational load.
Core Calculations
The indicator combines several mathematical and statistical techniques to generate price forecasts. Below is a step-by-step explanation of its calculations:
Log Returns (lgr):
The indicator calculates log returns as math.log(close / close ) when both the current and previous close prices are positive. This measures the relative price change in a logarithmic scale, which is standard for financial time series analysis to stabilize variance.
Hurst Exponent Estimation (get_hurst_exponent):
Purpose: Estimates the Hurst exponent (H) to quantify the degree of long-term memory in the price series.
Method: Uses rescaled range (R/S) analysis:
For each lag from 2 to max_lag, the function calc_rescaled_range computes the rescaled range:
Calculate the mean of the log returns over the lag period.
Compute the cumulative deviation from the mean.
Find the range (max - min) of the cumulative deviation.
Divide the range by the standard deviation of the log returns to get the rescaled range.
The log of the rescaled range (log(R/S)) is regressed against the log of the lag (log(lag)) using the polyfit_slope function.
The slope of this regression is the Hurst exponent (H).
Interpretation:
H = 0.5: Random walk (no memory, like standard Brownian motion).
H > 0.5: Persistent behavior (trends tend to continue).
H < 0.5: Mean-reverting behavior (price tends to revert to the mean).
Fractional Brownian Motion (get_fbm):
Purpose: Generates a fractional Brownian motion series to model price movements with long-range dependence.
Inputs: n (array size 2^n), H (Hurst exponent), L (length scale), cum (cumulative sum toggle).
Method:
Computes covariance for fBm using the formula: 0.5 * (|i+1|^(2H) - 2 * |i|^(2H) + |i-1|^(2H)).
Uses Hosking’s method (referenced from Columbia University’s implementation) to generate fBm:
Initializes arrays for covariance (cov), intermediate calculations (phi, psi), and output.
Iteratively computes the fBm series by incorporating a random term scaled by the variance (v) and covariance structure.
Applies scaling based on L / N^H to adjust the amplitude.
Optionally applies cumulative summation if cum = 1 to produce a path with memory.
Output: An array of 2^n values representing the fBm series.
Binomial Cascade (get_binomial_cascade):
Purpose: Models trading time (theta) to account for non-uniform market activity (e.g., bursts of volatility).
Inputs: n (array size 2^n), m (multiplier), T (trading time scale).
Method:
Initializes an array of size 2^n with values of 1.0.
Iteratively applies a binomial cascade:
For each block (from 0 to n-1), splits the array into segments.
Randomly assigns a multiplier (m or 2.0 - m) to each segment, redistributing mass.
Normalizes the array by dividing by its sum and scales by T.
Checks for array size limits to prevent Pine Script errors.
Output: An array (theta) representing the trading time, which warps the fBm to reflect market activity.
Interpolation (interpolate_fbm):
Purpose: Maps the fBm series to the trading time scale to produce a forecast.
Method:
Computes the cumulative sum of theta and normalizes it to .
Interpolates the fBm series linearly based on the normalized trading time.
Ensures the output aligns with the trading time scale (T).
Output: An array of interpolated fBm values representing log returns over the forecast horizon.
Price Path Generation:
For each simulation (up to num_simulations):
Generates an fBm series using get_fbm.
Interpolates it with the trading time (theta) using interpolate_fbm.
Converts log returns to price levels:
Starts with the current close price.
For each step i in the forecast horizon (T), computes the price as prev_price * exp(log_return).
Output: An array of price levels for each simulation.
Visualization:
Trigger: Updates every T bars when the bar state is confirmed (barstate.isconfirmed).
Process:
Clears previous lines from line_array.
For each simulation, plots a line from the current bar’s close price to the forecasted price at bar_index + T.
Colors the line using a gradient (color.from_gradient) based on the final forecasted price relative to the minimum and maximum forecasted prices across all simulations (red for lower prices, teal for higher prices).
Output: Multiple colored lines on the chart, each representing a possible price path over the next T bars.
How It Works on the Chart
Initialization: On each bar, the indicator calculates the Hurst exponent (H) using historical log returns and prepares the trading time (theta) using the binomial cascade.
Forecast Generation: Every T bars, it generates num_simulations price paths:
Each path starts at the current close price.
Uses fBm to model log returns, warped by the trading time.
Converts log returns to price levels.
Plotting: Draws lines from the current bar to the forecasted price T bars ahead, with colors indicating relative price levels.
Dynamic Updates: The forecast updates every T bars, replacing old lines with new ones based on the latest price data and calculations.
Key Features
Multifractal Modeling: Captures complex market dynamics by combining fBm (long-range dependence) with a binomial cascade (non-uniform time).
Customizable Parameters: Allows users to adjust the forecast horizon, model resolution, scaling, and number of simulations.
Probabilistic Forecast: Multiple simulations provide a range of possible price outcomes, helping traders assess uncertainty.
Visual Clarity: Gradient-colored lines make it easy to distinguish bullish (teal) and bearish (red) forecasts.
Potential Use Cases
Trend Analysis: Identify potential price trends or reversals based on the direction and spread of forecast lines.
Risk Assessment: Evaluate the range of possible price outcomes to gauge market uncertainty.
Volatility Analysis: The Hurst exponent and binomial cascade provide insights into market persistence and volatility clustering.
Limitations
Computational Intensity: Large values of n or num_simulations may slow down execution or hit Pine Script’s array size limits.
Randomness: The binomial cascade and fBm rely on random terms (math.random), which may lead to variability between runs.
Assumptions: The model assumes log-normal price movements and fractal behavior, which may not always hold in extreme market conditions.
Adjusting Inputs:
Set max_lag based on the desired depth of historical analysis.
Adjust n for model resolution (start with 4–6 to avoid performance issues).
Tune m to control trading time variability (0.5–1.5 is typical).
Set L to scale the forecast amplitude (experiment with values like 10,000–1,000,000).
Choose T based on your trading horizon (20 for short-term, 50 for longer-term for example).
Select num_simulations for the number of forecast paths (5–10 is reasonable for visualization).
Interpret Output:
Teal lines suggest bullish scenarios, red lines suggest bearish scenarios.
A wide spread of lines indicates high uncertainty; convergence suggests a stronger trend.
Monitor Updates: Forecasts update every T bars, so check the chart periodically for new projections.
Chart Examples
This is a daily AMEX:SPY chart with default settings. We see the simulations being done every T bars and they provide a range for us to analyze with a few simulations still in the range.
On this intraday PEPPERSTONE:COCOA chart I modified the Length Scale for fBm, L, parameter to be 1000 from 100000. Adjusting the parameter as you switch between timeframes can give you more contextual simulations.
On BITSTAMP:ETHUSD I modified the L to be 1000000 to have a more contextual set of simulations with crypto's volatile nature.
With L at 100000 we see the range for NASDAQ:TLT is correctly simulated. The recent pop stays within the bounds of the highest simulation. Note this is a cherry picked example to show the power and potential of these simulations.
Technical Notes
Error Handling: The script includes checks for array size limits and division by zero (math.abs(denominator) > 1e-10, v := math.max(v, 1e-10)).
External Reference: The fBm implementation is based on Hosking’s method (www.columbia.edu), ensuring a robust algorithm.
Conclusion
The Multifractal Forecast is a powerful tool for traders seeking to model complex market dynamics using a multifractal framework. By combining fBm, binomial cascades, and Hurst exponent analysis, it generates probabilistic price forecasts that account for long-range dependence and non-uniform market activity. Its customizable inputs and clear visualizations make it suitable for both technical analysis and strategy development, though users should be mindful of its computational demands and parameter sensitivity. For optimal use, experiment with input settings and validate forecasts against other technical indicators or market conditions.