OptiPine: High-Performance Caching and Data PipelinesOptiPine is a high performance architecture library for Pine Script™, built for algorithms that push beyond ordinary indicator workloads. It turns caching, sparse updates, reusable storage and workload-aware data structures into practical APIs that stay small at the call site.
In a small indicator, optimization is often optional. In a rendering engine, machine learning library, simulation, dashboard or object system, it can determine whether a feature runs at all. The problem is rarely one slow formula. It is the thousands of unnecessary operations around it: recalculating unchanged results, shifting rolling arrays, scanning large collections for a few changes, and moving stored objects when one disappears.
OptiPine attacks that layer with techniques used in projects such as Pine3D and NeuraLib . The idea is simple: do less work, move less data, and let the representation follow the workload.
Compared with conventional Pine implementations of the same task, OptiPine's optimized paths commonly ran 15% to 40% faster . Sparse updates and indexed lookups exceeded 90% when the alternative scanned or searched the full collection.
Most users can stay entirely within the high-level API. A Memo cache with several dependencies looks like this:
// Pseudocode: trendRegime and volatilityRegime are floats;
// rebuildModel() is a pure calculation.
var op.FloatMemo model = op.floatMemo()
if model.staleOn(trendRegime, volatilityRegime)
model.store(rebuildModel(trendRegime, volatilityRegime))
float result = model.get()
// Output: rebuildModel() runs once, then only when either regime changes.
Memo owns the previous dependencies, first-run state, validity and cached result. The caller only declares what the result depends on.
----------------------------------------------------------------------------------------------------------------
🔷 DO NOT CALCULATE THE SAME THING TWICE
The fastest expensive calculation is the one that never needed to run. Models, simulations and generated geometry often remain valid across many script executions.
Memo is the direct choice when the cached result is an int, float, bool, string or color. staleOn() checks up to four floats, two integers, one Boolean and one string; store() saves a rebuilt value, and get() returns it.
Many models respond to regimes rather than every tiny change in raw data. Round the inputs into meaningful regimes, pass them to staleOn() , and the model runs only when a regime changes.
In practice: Memo is useful for scenario models, parameter sweeps, numerical solvers and other expensive pure calculations that reduce to one primitive result. If its dependencies repeat on nine out of ten executions, it avoids roughly 90% of those model runs.
For collections or a variable dependency list, use Memo's explicit begin() , dependencies.watch*() and miss() lifecycle.
Keep guarded work pure: Stateful ta.* and similar history-dependent calls must remain outside Memo and Watch guards. Compute them every bar, then pass their results into the guarded calculation.
🔸 WATCH: CHANGE DETECTION WITHOUT RESULT STORAGE
Watch is the lighter choice when the caller already owns the result. Several consumers can observe the same producer independently by giving each its own Watch. changed() returns true on the first observation and whenever one scalar, primitive array or OptiPine row ring changes. Row rings expose an internal revision, so checking them is O(1).
For a single source, the dependency check should take less attention than the calculation it protects. Here another component supplies one caller-owned feature array:
// Pseudocode: getFeatureSnapshot() supplies an array.
array features = getFeatureSnapshot()
var op.Watch featureWatch = op.watch()
var float modelScore = na
if featureWatch.changed(features)
modelScore := evaluateModel(features)
// Output: modelScore is rebuilt only when the features array changes.
Because OptiPine does not own features , it compares the array with a retained snapshot and rewrites that snapshot only after a change. Supported row rings use their internal revision instead. The call stays the same, and this compare-first array pattern measured roughly 35% to 60% faster than rewriting the snapshot every time.
The array comparison is still O(N), so use it when the avoided calculation costs more than the comparison. If the producer already provides one reliable change flag, use the flag directly.
For several dependencies, use an explicit pass. begin() starts the comparison, the typed watch*() methods add dependencies, and finish() returns true if the completed set changed. A Watch remembers dependencies; it does not store the result.
// Pseudocode dependencies: int length, float multiplier,
// and array features.
var op.Watch settingsWatch = op.watch()
var float result = na
settingsWatch.begin()
settingsWatch.watchInt(length)
settingsWatch.watchFloat(multiplier)
settingsWatch.watchFloats(features)
bool dependenciesChanged = settingsWatch.finish()
if dependenciesChanged
result := rebuild(length, multiplier, features)
// Output: result is rebuilt when any observed dependency changes.
Construct the Watch once with var , then run begin() and finish() on every comparison pass. For one dependency, changed(source) is the shorter path.
In practice: Watch fits module boundaries: a model can observe a feature array, a renderer can observe a managed ring, or a cache can observe several mixed settings without duplicating the producer's change logic.
CadenceGate limits how often work may run. due() is periodic; dueWhenChanged() also requires a producer revision and remembers changes until the cadence opens. Use it for intentionally delayed work such as periodic model fitting, not results that must update immediately.
----------------------------------------------------------------------------------------------------------------
🔷 ROLLING HISTORY WITHOUT SHIFTING IT
Rolling histories often perform work that adds nothing to the result. If an array keeps the latest 200 events, removing the oldest one and shifting the other 199 entries is unnecessary.
FloatRowRing and IntRowRing keep fixed-width rows in reusable storage. Once full, the next row overwrites the oldest physical slot while reads remain chronological.
var op.FloatRowRing history = op.floatRowRing(200, 3)
float atr14 = ta.atr(14)
if barstate.isconfirmed
history.push(array.from(close, volume, atr14))
float oldestPrice = history.at(0, 0)
float latestPrice = history.newestAt(0, 0)
// Output: after a confirmed push, these are the oldest and newest retained closes.
A push costs O(width), or O(1) through pushValue() for a width-one ring. Rings also provide chronological windows and gathered rows. When several producers can mutate a ring, a separate consumer can detect its revision with Watch.changed(ring) in O(1).
In practice: Row rings fit pivots, completed trades, sampled features and other fixed event histories.
Performance: A full ring overwrites one row instead of shifting every retained row. Its chronological output uses at most two native contiguous copies, which measured 90% faster than rebuilding a 512-cell, width-four output row by row.
Use RingCursor when several caller-owned arrays need the same circular layout. Ordinary series history such as close should remain native Pine.
----------------------------------------------------------------------------------------------------------------
🔷 KEEP DYNAMIC OBJECTS STABLE
Dynamic objects become surprisingly expensive when identity is tied to array position. If one object is removed from several parallel arrays, every later entry shifts, every synchronized payload array needs the same removal, and every external reference to those positions becomes fragile.
StablePool is not the zone storage itself. It keeps one association: an object ID supplied by the script points to a reusable array slot. The ID answers "which zone is this?" while the slot answers "where is this zone's data stored?"
The example has three different logical zones named A, B and C. Their IDs, 1001, 1002 and 1003, are arbitrary unique values chosen for readability. Real IDs may come from a pivot bar, timestamp, order number or incrementing counter.
const int ZONE_A_ID = 1001
const int ZONE_B_ID = 1002
const int ZONE_C_ID = 1003
var op.StablePool zonePool = op.stablePool()
// This example never has more than two active zones.
var array prices = array.new(2, na)
if barstate.isfirst
// A receives slot 0. B receives slot 1.
= zonePool.acquire(ZONE_A_ID)
= zonePool.acquire(ZONE_B_ID)
prices.set(slotA, 100.0)
prices.set(slotB, 200.0)
// Zone A no longer exists. Its slot becomes available.
zonePool.release(ZONE_A_ID)
// C is a new zone with a new identity, but it can reuse A's old slot.
= zonePool.acquire(ZONE_C_ID)
prices.set(slotC, 300.0)
// Output: B keeps slot 1. C has ID 1003 but reuses A's released slot 0.
// prices is .
Why C needs a new ID: C is a different zone, even though it occupies the same array position A once used. Reusing 1001 would describe A returning, not a new zone C. IDs preserve object identity; slots are only reusable storage addresses.
Several fields, one slot: In production, the same slot usually addresses every field belonging to the object. Continuing the A, B and C lifecycle with four parallel arrays:
const int ZONE_A_ID = 1001
const int ZONE_B_ID = 1002
const int ZONE_C_ID = 1003
var op.StablePool zonePool = op.stablePool()
var array zonePrices = array.new()
var array zoneTimes = array.new()
var array zoneStrengths = array.new()
var array zoneColors = array.new()
if barstate.isfirst
= zonePool.acquire(ZONE_A_ID)
= zonePool.acquire(ZONE_B_ID)
// Grow every payload array to cover the allocated slots.
int required = zonePool.slotCount()
op.ensureSizeFloat(zonePrices, required, na)
op.ensureSizeInt(zoneTimes, required, na)
op.ensureSizeFloat(zoneStrengths, required, na)
op.ensureSizeColor(zoneColors, required, na)
zonePrices.set(slotA, 100.0)
zoneTimes.set(slotA, 10)
zoneStrengths.set(slotA, 0.40)
zoneColors.set(slotA, color.blue)
zonePrices.set(slotB, 200.0)
zoneTimes.set(slotB, 20)
zoneStrengths.set(slotB, 0.80)
zoneColors.set(slotB, color.red)
zonePool.release(ZONE_A_ID)
= zonePool.acquire(ZONE_C_ID)
// C reuses A's slot, so every field at that slot must be overwritten.
zonePrices.set(slotC, 300.0)
zoneTimes.set(slotC, 30)
zoneStrengths.set(slotC, 0.60)
zoneColors.set(slotC, color.lime)
// Output: B keeps slot 1 in every array. C owns slot 0 in every array.
// Nothing is removed or shifted.
acquire(id) returns the slot and whether the ID was newly added. Calling it again for an active ID returns the same slot. release(id) frees the slot, but does not erase its array data, so every field must be overwritten when that slot is reused.
The example preallocates two values because it has at most two active zones. A dynamic script can grow its payload arrays with ensureSize*() whenever acquire() reports a new ID. zonePool.slots() returns the currently active slots as a read-only view.
In practice: One zone slot can index its price, time, color, strength and line across several arrays. In the complete example later, the pivot bar and event type form each zone ID. Releasing one zone frees its slot without shifting other zones or breaking saved positions.
Performance: StablePool is independent of payload layout: its slots can index parallel arrays or one array of UDTs. acquire() , release() and find() are O(1), and releasing an object never shifts caller-owned payloads.
For a few fixed objects, manual indices are simpler. StablePool becomes useful when IDs appear and disappear over time, several payload arrays share the same slots, or other parts of the script retain those positions.
SlotCache is the frame-based alternative. Call begin() , acquire every active key, then call finish() ; previously active keys that were not touched are retired automatically.
----------------------------------------------------------------------------------------------------------------
🔷 UPDATE ONLY WHAT CHANGED
Large state does not imply large change. A dashboard may contain 10,000 cells while only a few change on one bar, or a large object system may need to refresh only a handful of entries.
A conventional dirty-flag array must be cleared and scanned in full. DirtySet stores only the changed indices, removes duplicate marks and begins a new cycle without clearing the entire universe. It is a work list, not payload storage or an ID-to-slot map.
Here StablePool resolves zoneId , the arrays store zone data, and DirtySet schedules the slots that need rebuilding. The event values are pseudocode:
int MAX_ZONES = 50000
var op.StablePool zones = op.stablePool()
var op.DirtySet dirtySlots = op.dirtySet(MAX_ZONES)
var array tops = array.new()
var array bottoms = array.new()
var array midpoints = array.new()
// Start this bar's sparse-work cycle.
dirtySlots.begin()
if zoneGeometryChanged
// StablePool converts the logical ID into a reusable physical slot.
= zones.acquire(zoneId)
if created
op.ensureSizeFloat(tops, zoneSlot + 1, na)
op.ensureSizeFloat(bottoms, zoneSlot + 1, na)
op.ensureSizeFloat(midpoints, zoneSlot + 1, na)
tops.set(zoneSlot, newTop)
bottoms.set(zoneSlot, newBottom)
dirtySlots.mark(zoneSlot)
if zoneStyleChanged
int styleSlot = zones.find(zoneId)
if styleSlot >= 0
dirtySlots.mark(styleSlot) // A second mark of the same slot is ignored.
// Process only the distinct physical slots marked during this bar.
for dirtySlot in dirtySlots.values()
float midpoint = (tops.get(dirtySlot) + bottoms.get(dirtySlot)) * 0.5
midpoints.set(dirtySlot, midpoint)
redrawZone(zones.keyAt(dirtySlot), midpoint)
// Output: one zone is rebuilt once even if geometry and style both mark it.
Repeated marks are deduplicated, and unmarked zones are never visited. Work scales with the number of changed slots, not the size of the collection. If the natural address is already a dense index, mark it directly without StablePool.
In practice: Several producers can mark work, then one consumer updates each affected cell, drawing or record once. With 1% of entries changed, this measured 93% faster than clearing and scanning the full universe.
----------------------------------------------------------------------------------------------------------------
🔷 KEYED LOOKUP WITHOUT GUESSWORK
Keyed lookup appears throughout object systems, caches and grouped data, but no structure fits every key set. Distribution, rebuild frequency and query volume change the best choice. OptiPine sees the completed keys at build() , then selects the lookup shape that fits them.
🔸 TYPED STORES: ONE VALUE PER KEY
A typed store maps each integer key to one primitive value. build() pairs entries at matching positions in the key and value arrays. Consecutive IDs allow direct addressing:
var op.IntFloatStore scores = op.intFloatStore()
if barstate.isfirst
// Four entries are shown for readability; both arrays may be much larger.
scores.build(
array.from(410, 411, 412, 413),
array.from(0.80, 0.30, 0.95, 0.50))
float selected = scores.get(412)
// Output: integer key 412 resolves to float value 0.95.
Lookup is one-way: get(412) returns 0.95 , but values may repeat, so get(0.95) has no general meaning.
What automatic mode chooses:
Consecutive ascending keys: Direct arithmetic indexing.
Compact key ranges: A dense lookup table.
Other unordered keys: A native map when within Pine's map limit.
Ascending sparse keys: Binary search, or a map within that limit when expectedQueries justifies its build cost.
Linear lookup remains available for unusual workloads that rebuild far more often than they query. Automatic mode only selects it for non-empty stores when linearMaxEntries is deliberately configured.
The same API avoids hashing when direct addressing fits, uses a map when it pays, and remains usable beyond Pine's map capacity. Automatic mode is the normal default. Use op.indexConfigDynamic() when future query volume is unknown and the store may need to promote itself later.
build(keys, values, expectedQueries) accepts two same-length arrays. The optional hint tells OptiPine how many lookups to expect before the next build. Stores support int, float, bool, string and color values. Use one IntIndex for several payload fields, or IntBuckets when a key owns several integers.
In practice: Batch-build IDs to scores, states or metadata, then query them without committing to a representation. Direct integer addressing measured 21% faster than a map, while a map measured 91% faster than repeated linear lookup with 32 entries.
🔸 INTBUCKETS: ONE KEY TO MANY INTEGER VALUES
A Store returns one value for each key. IntBuckets returns a group of integers, usually object IDs or physical slots. Repeating a key adds another member instead of replacing the previous one.
var op.IntBuckets cellMembers = op.intBuckets()
var array matches = array.new()
if barstate.isfirst
// Six (cell, object slot) pairs. Cell 7 appears three times.
array cellKeys = array.from(7, 2, 7, 5, 2, 7)
array objectSlots = array.from(101, 205, 412, 990, 777, 888)
cellMembers.buildFromPairs(cellKeys, objectSlots)
// Read cell 7's group from flat storage. matches is only demo output.
= cellMembers.rangeByKey(7)
if count > 0
for position = start to start + count - 1
matches.push(cellMembers.valueAt(position))
// Output: matches contains , the object slots assigned to cell 7.
What happens: Each key is paired with the slot at the same array position. Cell 7 appears three times, so its group contains 101, 412 and 888. rangeByKey() returns where that group starts and how many values it contains. A missing key returns a count of 0.
Lifecycle: buildFromPairs() replaces all previous groups. Use buildBegin() , add() and buildFinish() only when pairs arrive one at a time.
In practice: A price cell can own several zone slots, a graph node can own several neighbors, or a category can own several record IDs. One query visits only that group.
Why use it: A native map stores one value per key, and Pine does not allow an array directly as that value. Giving one key several values therefore requires a small wrapper UDT containing an array. IntBuckets provides that relationship directly, packing every group into shared contiguous storage. It suits batch rebuilds followed by repeated traversal, while the wrapper approach is more convenient when individual groups change constantly. In the tested 64-key traversal workload, IntBuckets averaged 19% faster across four runs.
----------------------------------------------------------------------------------------------------------------
🔷 REUSE STATE INSTEAD OF REBUILDING IT
IntDoubleBuffer and FloatDoubleBuffer retain current and previous arrays. swap() exchanges their references in O(1), preserves the old result and clears the new current buffer for reuse. That clear still costs O(N).
This is useful when one pass must remain readable while the next is built. In this small search, node n has children 2n and 2n + 1 . Each pass reads the active level and writes the next one:
var op.IntDoubleBuffer searchFrontier = op.intDoubleBuffer()
if barstate.isfirst
searchFrontier.current.push(1)
for depth = 1 to 3
= searchFrontier.swap()
for nodeId in activeFrontier
nextFrontier.push(nodeId * 2)
nextFrontier.push(nodeId * 2 + 1)
// Output: current contains .
// previous contains .
What happens: swap() makes the completed level available as activeFrontier and returns the other retained array, already empty, as nextFrontier . No level is copied and no replacement array is created. The same pattern supports graph searches, flood fills, iterative clustering and simulations. Use swapSized() when every pass needs a fixed-size output.
A var array can also be reused. The ensureSize*() , resize*() and refill*() families modify existing storage, while sameExact*() compares primitive arrays without Pine's float-comparison rounding.
Revision handles caller-owned state that OptiPine cannot observe. The producer calls bump() after a change; each consumer compares its own saved token with changedSince() instead of keeping a snapshot.
----------------------------------------------------------------------------------------------------------------
🔷 WEIGHTED SELECTION FOR STATIC AND DYNAMIC SYSTEMS
Weighted selection chooses entries in proportion to their weights. It is useful in simulations, randomized search and priority sampling.
WeightedSampler is the high-level interface. Set weights, then supply a fraction to select a slot. The sampler does not generate randomness; use math.random() or a repeatable fraction sequence:
var op.WeightedSampler sampler = op.weightedSampler(512)
if barstate.isfirst
sampler.setWeight(10, 0.25)
sampler.setWeight(11, 0.80)
sampler.setWeight(12, 0.10)
float fraction = 0.50
int selected = sampler.sample(fraction)
// Output: selected is 11 for the supplied fraction of 0.50.
The default cumulative prefix suits stable weights. Pass op.weightConfigSparseUpdates() and the sampler can move to an update-friendly Fenwick tree as the workload changes. sample() stays the same. Use WeightedIndex for circular ranges or explicit policy control.
In practice: Each slot can represent a candidate model, simulation outcome or work item. Update its weight when its score changes, then sample repeatedly through the same interface.
----------------------------------------------------------------------------------------------------------------
🔷 THREE LEVELS OF CONTROL
OptiPine is layered so high-level code describes the problem rather than the mechanism. Start with Tier 1 and move deeper only when the workload requires more control:
Tier 1, Quick: Ready-to-use APIs with automatic defaults, including Watch, Memo, CadenceGate, typed stores, StablePool, DirtySet, row rings, double buffers and WeightedSampler.
Tier 2, Composable: Explicit lifecycles, configuration and representation policies through IntIndex, IntBuckets, SlotCache, RingCursor and Revision.
Tier 3, Expert: Physical addressing, unchecked operations and scoped raw mutation for measured hot paths. Ordinary read-only views are not Tier 3.
Editor warnings: Methods such as get() , set() , push() and clear() intentionally match Pine's collection vocabulary. Any shadowing-method warning is cosmetic; the receiver's type determines which method runs.
----------------------------------------------------------------------------------------------------------------
🔷 COMPLETE, COPY-PASTE EXAMPLES
The fragments above isolate one idea at a time. These two copy-paste indicators combine them in practical workflows, using native Pine where it is simpler and OptiPine where it removes real work.
🔸 Complete example 1: high-level cached stress model
What it does: The indicator plots a probability-weighted downside estimate for the current trend and volatility regime, while exposing both regime values in the Data Window.
The EMA and ATR calculations run normally on every bar. Their rounded regimes change less often, so Memo recalculates the 401-scenario model only when one of those regimes changes and serves the cached result between changes.
//@version=6
indicator("OptiPine - Cached Regime Stress", overlay = false)
import Alien_Algorithms/OptiPine/1 as op
// Test 401 possible moves, giving more weight to common moves.
// This function is pure: its result depends only on its inputs.
estimateDownside(float trendInAtr, float atrPercent) =>
float result = na
if not na(trendInAtr) and not na(atrPercent) and atrPercent > 0
float weightedDownside = 0.0
float totalWeight = 0.0
for scenario = -200 to 200
float standardShock = scenario / 40.0
float weight = math.exp(-0.5 * standardShock * standardShock)
float projectedMove = (trendInAtr + standardShock) * atrPercent
float downside = math.max(-projectedMove, 0.0)
weightedDownside += downside * weight
totalWeight += weight
result := totalWeight > 0 ? weightedDownside / totalWeight : na
result
// Stateful Pine calculations stay outside the Memo guard.
float ema20 = ta.ema(close, 20)
float ema50 = ta.ema(close, 50)
float atr14 = ta.atr(14)
float trendInAtr = atr14 > 0 ? (ema20 - ema50) / atr14 : na
float atrPercent = close > 0 ? atr14 / close * 100.0 : na
// Quantization makes the dependencies describe a regime, not every tick.
float trendRegime = math.round(
math.max(-3.0, math.min(3.0, trendInAtr)) * 10.0) / 10.0
float volatilityRegime = math.round(atrPercent * 4.0) / 4.0
var op.FloatMemo downsideStress = op.floatMemo()
if downsideStress.staleOn(trendRegime, volatilityRegime)
downsideStress.store(
estimateDownside(trendRegime, volatilityRegime))
float stress = downsideStress.get()
plot(stress, "Expected downside (%)", color.orange, linewidth = 2)
plot(trendRegime, "Trend regime (ATR units)", display = display.data_window)
plot(volatilityRegime, "Volatility regime (%)", display = display.data_window)
🔸 Complete example 2: advanced zone-cluster engine
What it does: The indicator draws recent pivot levels, thickens those near the current price, plots the strongest price cluster and reports its key statistics in the Data Window.
StablePool preserves drawing slots, the ring tracks retirement order, DirtySet queues redraws, IntBuckets forms price clusters and IntFloatStore looks up their strength.
Relevant benchmarks: These are component results, not a total for this 32-zone indicator. In larger matching workloads, DirtySet saved 93% at 1% dirty and IntBuckets averaged 19% with 64 keys. For typed lookup, direct addressing saved 21% over a map on compact keys, while a map saved 91% over linear search at 32 entries. Automatic mode selects the representation.
StablePool and the ring manage recycling. The script still scans live zones for proximity changes, then DirtySet avoids unnecessary drawing updates.
//@version=6
indicator("OptiPine - Zone Cluster Engine", overlay = true, max_lines_count = 100)
import Alien_Algorithms/OptiPine/1 as op
int pivotLength = input.int(5, "Pivot length", minval = 1)
int maxZones = input.int(32, "Maximum zones", minval = 4, maxval = 100)
int bucketTicks = input.int(25, "Cluster size in ticks", minval = 1)
float bucketSize = syminfo.mintick * bucketTicks
// Stateful Pine calculations remain outside every conditional rebuild.
float pivotHigh = ta.pivothigh(high, pivotLength, pivotLength)
float pivotLow = ta.pivotlow(low, pivotLength, pivotLength)
float pivotStrength = math.max(nz(volume , 1.0), 1.0)
float highlightDistance = ta.atr(14)
var op.StablePool zones = op.stablePool()
var op.IntRowRing zoneOrder = op.intRowRing(maxZones, 1)
var op.DirtySet dirtyZones = op.dirtySet(maxZones)
var array zonePrices = array.new(maxZones, na)
var array zoneStrengths = array.new(maxZones, 0.0)
var array zoneTimes = array.new(maxZones, na)
var array resistance = array.new(maxZones, false)
var array highlighted = array.new(maxZones, false)
var array zoneLines = array.new(maxZones)
var op.IntBuckets zonesByBucket = op.intBuckets()
var op.IntFloatStore strengthByBucket = op.intFloatStore()
// Retained build storage is resized and overwritten, never cleared and repopulated.
var array bucketKeyByPosition = array.new()
var array aggregateKeys = array.new()
var array aggregateStrengths = array.new()
var int strongestBucketKey = na
var float strongestBucketStrength = na
var int strongestZoneCount = 0
dirtyZones.begin()
bool topologyChanged = barstate.isfirst
// Logical pivot IDs receive stable, reusable physical drawing slots.
for event = 0 to 1
float level = event == 0 ? pivotHigh : pivotLow
if barstate.isconfirmed and not na(level)
int pivotBar = bar_index - pivotLength
int pivotTime = time
int zoneId = pivotBar * 2 + event
int slot = zones.find(zoneId)
// Only a new logical pivot enters the retirement queue.
if slot < 0
if zoneOrder.rowCount() == maxZones
int oldestId = zoneOrder.at(0, 0)
zones.release(oldestId)
= zones.acquire(zoneId)
slot := newSlot
zoneOrder.pushValue(zoneId)
zonePrices.set(slot, level)
zoneStrengths.set(slot, pivotStrength)
zoneTimes.set(slot, pivotTime)
resistance.set(slot, event == 0)
highlighted.set(slot, false)
dirtyZones.mark(slot)
topologyChanged := true
// Proximity can mark a newly created slot again; DirtySet still stores it once.
for slot in zones.slots()
bool isHighlighted = math.abs(close - zonePrices.get(slot)) <= highlightDistance
if isHighlighted != highlighted.get(slot)
highlighted.set(slot, isHighlighted)
dirtyZones.mark(slot)
// Only changed drawings cross the line API boundary.
for slot in dirtyZones.values()
float level = zonePrices.get(slot)
color baseColor = resistance.get(slot) ? color.red : color.lime
line zoneLine = zoneLines.get(slot)
if na(zoneLine)
zoneLine := line.new(zoneTimes.get(slot), level, time, level,
xloc = xloc.bar_time)
zoneLines.set(slot, zoneLine)
line.set_xy1(zoneLine, zoneTimes.get(slot), level)
line.set_xy2(zoneLine, time, level)
line.set_extend(zoneLine, extend.right)
line.set_width(zoneLine, highlighted.get(slot) ? 3 : 1)
line.set_color(zoneLine,
color.new(baseColor, highlighted.get(slot) ? 0 : 55))
// Rebuild grouped lookup only after the explicit creation event.
if topologyChanged
array liveSlots = zones.slots()
int liveCount = liveSlots.size()
op.resizeInt(bucketKeyByPosition, liveCount, 0)
if liveCount > 0
for position = 0 to liveCount - 1
int slot = liveSlots.get(position)
int bucketKey = int(math.round(zonePrices.get(slot) / bucketSize))
bucketKeyByPosition.set(position, bucketKey)
// Repeated bucket keys accumulate several physical zone slots.
zonesByBucket.buildFromPairs(bucketKeyByPosition, liveSlots)
int bucketCount = zonesByBucket.bucketCount()
op.resizeInt(aggregateKeys, bucketCount, 0)
op.resizeFloat(aggregateStrengths, bucketCount, 0.0)
strongestBucketKey := na
strongestBucketStrength := na
strongestZoneCount := 0
if bucketCount > 0
for bucketSlot = 0 to bucketCount - 1
int bucketKey = zonesByBucket.keyAt(bucketSlot)
= zonesByBucket.rangeBySlot(bucketSlot)
float totalStrength = 0.0
if count > 0
for position = start to start + count - 1
int zoneSlot = zonesByBucket.valueAt(position)
totalStrength += zoneStrengths.get(zoneSlot)
aggregateKeys.set(bucketSlot, bucketKey)
aggregateStrengths.set(bucketSlot, totalStrength)
if na(strongestBucketStrength) or totalStrength > strongestBucketStrength
strongestBucketKey := bucketKey
strongestBucketStrength := totalStrength
strongestZoneCount := count
strengthByBucket.build(aggregateKeys, aggregateStrengths)
// Query the current price cluster directly and display the strongest cluster.
int currentBucketKey = int(math.round(close / bucketSize))
float nearbyStrength = strengthByBucket.get(currentBucketKey, 0.0)
float strongestClusterPrice = na(strongestBucketKey) ?
na : strongestBucketKey * bucketSize
plot(strongestClusterPrice, "Strongest zone cluster", color.orange,
linewidth = 2, style = plot.style_stepline)
plot(nearbyStrength, "Strength near current price", display = display.data_window)
plot(strongestBucketStrength, "Strongest cluster strength",
display = display.data_window)
plot(strongestZoneCount, "Zones in strongest cluster",
display = display.data_window)
plot(dirtyZones.size(), "Drawings updated", display = display.data_window)
----------------------------------------------------------------------------------------------------------------
🔷 API REFERENCE
This is a compact index of the main public entry points.
🔸 Watch and Memo: changed(source) handles one scalar, primitive array or row ring. For several dependencies, use begin() , watch*() and finish() . Typed Memos add staleOn() , store() , get() and invalidate() .
🔸 Revision and Cadence: revision() exposes bump() , current() and changedSince() for manual change tracking. cadenceGate() provides due() and change-aware dueWhenChanged() scheduling.
🔸 Row Rings: floatRowRing() and intRowRing() provide push() , width-one pushValue() , at() , setAt() , newestAt() , chronological() and gather() .
🔸 RingCursor: Circular addressing for caller-owned arrays. Use reserve() to advance, physical() and logical() to translate positions, and newest() or oldest() to locate retained rows.
🔸 StablePool: acquire() and release() manage stable key-to-slot assignments. Lookup and traversal use find() , contains() , keyAt() , slots() and size() . Recycled slots retain their caller-owned payload until overwritten.
🔸 SlotCache: Frame-based stable allocation follows begin() , acquire() , finish() . active() , retired() and size() expose its state.
🔸 DirtySet: begin() starts a cycle; mark() , markMany() and markRange() add entries. Read the distinct work list with values() and size() .
🔸 Typed Stores: intIntStore() , intFloatStore() , intBoolStore() , intStringStore() and intColorStore() map integer keys to primitive values. Build with build() , then use get() , set() , contains() or getMany() .
🔸 IntIndex: A shared integer key-to-slot directory for custom payloads and explicit lookup policy. Build with buildBegin() , add() or addMany() and buildFinish() ; query with find() , keyAt() and findMany() . IndexConfig controls representation and duplicate policy.
🔸 IntBuckets: A one-key-to-many-integers index. Build directly with buildFromPairs() , or incrementally with buildBegin() , add() or addMany() and buildFinish() . Read groups with rangeByKey() and valueAt() .
🔸 Double Buffers: intDoubleBuffer() and floatDoubleBuffer() retain current and previous arrays. swap() exchanges them; swapSized() also sizes and refills the new current buffer.
🔸 Weighted Sampling: weightedSampler() provides weight updates, sample() , sampleMany() , probability() and total() . It maps caller-supplied fractions; it does not generate randomness. weightedIndex() adds circular ranges and explicit policy control.
🔸 Storage Utilities: ensureSize*() , resize*() , refill*() and sameExact*() handle primitive arrays. Other helpers cover flat/matrix conversion, transposition and bulk ring reads.
----------------------------------------------------------------------------------------------------------------
🔷 WHY OPTIPINE EXISTS
Pine's limits are real, but standard architecture often reaches them long before the idea itself has to. Repeating unchanged calculations, shifting rolling storage, scanning mostly untouched collections and rebuilding state all consume the same execution budget the feature needs to exist.
OptiPine reclaims that budget. Expensive models can run only when their inputs change. Large dashboards can refresh only what moved. Dynamic object systems can grow and recycle storage without reorganizing everything around them. The APIs stay approachable, while the architecture underneath is built for workloads that would normally force a Pine project to scale back.
At large scale, optimization is no longer simply about feature speed. It is the factor that dictates whether an ambitious idea can ship at all.
----------------------------------------------------------------------------------------------------------------
This work is licensed under (CC BY-NC-SA 4.0) , meaning usage is free for non-commercial purposes given that Alien_Algorithms is credited in the description for the underlying software. For commercial use licensing, contact Alien_Algorithms
The publication diagram has been rendered natively by Pine3D .
Library
RSI Divergence: Out-of-Sample Optimizer [LuxAlgo]The RSI Divergence: Out-of-Sample Optimizer indicator is a comprehensive backtesting and optimization tool designed to identify the most effective RSI period for trading price-RSI divergences within a specified historical window and validate those results through out-of-sample and forward testing.
🔶 USAGE
The script is divided into three distinct chronological phases to simulate a professional quantitative workflow:
🔹 In-Sample (IS) Optimization
During this period (highlighted by the first background gradient), the script simulates dozens of RSI periods simultaneously. It calculates divergence signals and trade outcomes for every period within the user-defined range (e.g., RSI 2 to 50). The "best" period is selected based on your chosen Optimization Metric, such as Net Profit or Profit Factor.
🔹 Out-of-Sample (OOS) Validation
Once the best RSI period is identified in the IS phase, the script "locks" that parameter and applies it to the next segment of data (the OOS period). This tests whether the strategy’s performance was due to genuine market alpha or simply "curve-fitting" to historical noise.
🔹 Forward Testing
The Forward period represents the most recent data leading up to the current bar. The script continues using the parameter validated during the OOS phase to show how the strategy is performing in the current market environment.
🔶 DETAILS
🔹 Divergence Detection
The script identifies regular bullish and bearish divergences. A bullish divergence occurs when price makes a lower low while the RSI makes a higher low. A bearish divergence occurs when price makes a higher high while the RSI makes a lower high. The script uses pivot lookback settings to confirm these peaks and troughs.
🔹 Trade Execution Logic
Trades are entered on the bar following a confirmed divergence. Stop loss and take profit levels are calculated using an ATR (Average True Range) multiplier to account for market volatility. Users can also enable "Exit on Opposite Signal" to close trades if a contrary divergence appears before hitting a price target.
🔹 Sensitivity Analysis (Heatmap)
The dashboard includes a "Sensitivity Table" that acts as a heatmap. It displays every RSI period tested during the In-Sample phase. Darker green cells indicate superior performance, while darker red cells indicate poorer performance based on the selected optimization metric. This allows you to see if your "best" setting is an outlier or part of a robust cluster of profitable periods.
🔶 SETTINGS
🔹 Optimization & Backtest Ranges
In-Sample Start/End: Defines the historical window used to find the best performing RSI period.
Out-of-Sample Start/End: Defines the validation window where the best IS period is tested on unseen data.
Min/Max RSI Period: The range of RSI lengths the script will simulate (e.g., 2 to 50).
Optimization Metric: The primary KPI used to rank RSI periods (e.g., Sharpe Ratio, Win Rate, Net Profit).
🔹 Divergence Settings
Pivot Left/Right Bars: The number of bars required on either side of a point to confirm a local high or low in the RSI.
Max Divergence Bars: The maximum distance allowed between two pivots to qualify as a divergence.
🔹 Trade Rules
Stop Loss/Take Profit ATR Multiplier: Controls the distance of exit levels based on recent volatility.
Exit on Opposite Signal: When enabled, a long trade will close immediately if a bearish divergence is detected.
🔹 Dashboard
Extra Dashboard Metric 1/2: Allows you to add two additional performance statistics to the dashboard (e.g., Z-Score or Average Trade) alongside the default metrics.
Dashboard Position/Size: Adjusts the UI elements to fit your screen resolution and preference.
Indicator
Supertrend Parameter Sensitivity 3D [LuxAlgo]The Supertrend Parameter Sensitivity 3D indicator is a powerful optimization tool that executes 100 simultaneous Supertrend backtests bar-by-bar to visualize how different ATR Lengths and Multipliers impact performance across various metrics.
By projecting this data onto a 3D surface and a heatmap dashboard, it allows traders to identify "stable" parameter zones and avoid over-optimized "peaks" that may lead to curve-fitting.
🔶 USAGE
This tool is designed to help traders find the most robust settings for the Supertrend indicator on any given timeframe or asset. Instead of manually guessing settings, users can see a holistic view of the parameter space.
🔹 3D Surface Projection
The 3D surface is rendered directly on the chart, where the X-axis represents the Multiplier, the Y-axis represents the ATR Length, and the Z-axis (height) represents the chosen performance metric.
Gold Highlight: Marks the absolute "Best" parameter combination based on the selected metric.
Blue Highlight: Marks the "Stable Area," which is the region where the average performance of a 3x3 parameter window is highest. This helps identify settings that remain profitable even if market conditions shift slightly.
🔹 Optimization Dashboard
The dashboard provides a detailed heatmap of the 100 tested combinations.
Value Distribution: An ASCII histogram at the top shows the distribution of all results, helping you understand if the "best" setting is an outlier or part of a consistent trend.
Heatmap Matrix: Displays the exact values for every combination. Hovering over any cell in the table reveals a tooltip with specific data, including the total number of trades for that combination.
Color Scaling: The colors are normalized relatively. Green represents the best results in the current set, while red represents the worst, allowing for clear visual distinction even if all results are negative or positive.
🔶 DETAILS
🔹 Bar-by-Bar Evaluation
The script manages 100 independent Supertrend states simultaneously. On every bar, it calculates the ATR and trailing stop levels for every combination in the sensitivity matrix. It simulates "Always-in-Market" trades (flipping long/short on direction changes) to track performance data without needing a separate strategy execution.
🔹 Optimization Metrics
Users can choose from 9 different metrics to optimize the 3D surface and Dashboard:
Win Rate: Percentage of trades that resulted in a profit.
Net Profit: Total gross profit minus total gross loss.
Profit Factor: Ratio of gross profit to gross loss.
Total Trades: The raw volume of signals generated.
Average Trade: The mean percentage return per trade.
Reward/Risk Ratio: The average win divided by the average loss.
Gross Profit: Total sum of all winning trades.
Total Wins: The absolute count of profitable trades.
Win/Loss Ratio: The count of wins divided by the count of losses.
🔶 SETTINGS
🔹 Main Indicator
ATR Length: The length used for the primary Supertrend line plotted on the chart.
Multiplier: The multiplier used for the primary Supertrend line plotted on the chart.
🔹 Sensitivity Ranges
Length Start: The starting ATR length for the 10x10 matrix.
Length Step: The increment added to the length for each subsequent row.
Multiplier Start: The starting Multiplier for the 10x10 matrix.
Multiplier Step: The increment added to the multiplier for each subsequent column.
🔹 Optimization
Metric: Selects the performance data used to determine the Z-height of the surface and the colors of the heatmap.
🔹 3D Surface Style
High/Low/Wire/Stable Colors: Customize the visual appearance of the 3D projection.
X/Y/Z Spacing & Scale: Adjusts the physical dimensions and height of the 3D surface on the chart.
🔹 Dashboard
Enable Dashboard: Toggles the visibility of the heatmap table.
Position/Size: Controls where the dashboard appears and how large it is on the screen.
Indicator
Strategy Sensitivity MatrixThe Strategy Sensitivity Matrix is an institutional-grade backtesting tool designed to evaluate the robustness and parameter sensitivity of trend-following strategies. It enables users to compare the historical performance of a broad range of parameter combinations across multiple metrics to assess the overall stability of the selected strategy. The model displays the complete backtest landscape in a structured, color-coded matrix that allows investors to quickly identify robust parameter regions and evaluate historical performance stability across parameter combinations.
At its core, the matrix systematically evaluates a wide range of parameter combinations, where every individual cell represents the backtest result for one unique parameter configuration. Users can switch between volatility-based strategies and moving-average strategies. In volatility mode, the matrix rows represent volatility lengths and the matrix columns represent volatility factors. In crossover mode, the rows represent fast moving-average lengths and the columns represent slow moving-average lengths. Supported volatility types include the Average True Range (ATR), Standard Deviation (SD), and Mean Absolute Deviation (MAD). Supported moving-average types include the Exponential Moving Average (EMA), Simple Moving Average (SMA), Wilder’s Moving Average (RMA), and Weighted Moving Average (WMA). Supported display metrics include:
CAGR = Compounded Annual Growth Rate.
Sharpe = CAGR per unit of standard deviation.
Sortino = CAGR per unit of downside deviation.
Martin = CAGR relative to the Ulcer Index (UI).
Calmar = CAGR relative to maximum drawdown.
Max DD = Largest peak-to-trough decline in value.
Alpha (α) = Excess annualized risk-adjusted returns.
Expectancy = Average expected return per trade.
Profit Factor = Total gross profit per unit of losses.
Win Rate = Ratio of profitable trades to total trades.
Trades/Year = Average number of trades per year.
The matrix follows an intuitive percentile-based coloring framework that dynamically compares the relative performance and stability of all parameter combinations. Stronger values above or equal to the matrix median are highlighted in green, with bright green representing the top 10% of all parameter combinations. Weaker values below the matrix median are highlighted in orange, while red represents objectively weak performance based on the selected metric. Broad clusters of consistently strong results generally suggest lower parameter sensitivity and potentially greater robustness, while isolated peaks generally suggest elevated parameter sensitivity.
The summary table displayed above the matrix provides a broader distribution-level statistical overview of results across all parameter combinations. This structure allows investors to evaluate whether strong historical performance appears statistically widespread or narrowly concentrated across the parameter landscape. Stable parameter landscapes generally exhibit lower standard deviation, similar median and average values, and smaller performance gaps between the best and top 10% parameter combinations. The summary table includes the following sections:
Start = Start month and year of the selected backtest period.
End = End month and year of the selected backtest period.
Metric = Performance metric currently displayed in the matrix.
B&H = Buy-and-hold performance for the selected metric.
Best = Best-performing parameter combination in the matrix.
Top 10% = Average value of the top 10% parameter combinations.
Median = Median value across all parameter combinations.
Average = Average value across all parameter combinations.
Std Dev = Standard deviation of all parameter combinations.
≥ B&H = Percentage of combinations equal or better than B&H.
In summary, the Strategy Sensitivity Matrix is a powerful robustness analysis tool designed to help investors make data-driven decisions when evaluating parameter combinations across trend-following strategies. By evaluating the full parameter landscape, investors can quickly determine whether strong historical performance appears broadly distributed across stable parameter regions or narrowly concentrated within isolated parameter combinations. While historical robustness can provide valuable insight into past market behavior over the selected backtest period, users should remain mindful that market structures evolve over time and that historically stable parameter regions may not necessarily persist in future market conditions. Indicator
Volatility Stop SelectorThe Volatility Stop Selector is a comprehensive trend-following tool designed to automatically identify the optimal volatility stop strategy. It features adjustable parameters and an integrated backtester that delivers institutional-grade insights into the recommended strategy. The model continuously adapts to new data in real time by evaluating multiple volatility length and factor combinations, determining the best-performing configuration, and presenting the backtest results in a clear, color-coded table that benchmarks performance against the buy-and-hold strategy.
At its core, the model systematically backtests a wide range of volatility stop combinations to identify the configuration that maximizes the selected optimization metric. Users can choose to optimize for absolute returns or risk-adjusted returns using metrics such as the Sharpe, Sortino, Martin, or Calmar ratios. The Martin ratio is particularly well suited for volatility-based risk management strategies, as it evaluates returns relative to the Ulcer Index, capturing both the depth and duration of drawdowns and therefore favoring smoother equity curves. Alternatively, users can enable manual optimization to test custom volatility length and factor settings and view the corresponding backtest results. The label displays the Compounded Annual Growth Rate (CAGR) of the strategy, with the buy-and-hold CAGR in parentheses for comparison. The table presents the backtest results based on the volatility length and factor displayed at the top:
Sharpe = CAGR per unit of standard deviation.
Sortino = CAGR per unit of downside deviation.
Calmar = CAGR relative to maximum drawdown.
Max DD = Largest peak-to-trough decline in value.
Beta (β) = Return sensitivity relative to buy-and-hold.
Alpha (α) = Excess annualized risk-adjusted returns.
Win Rate = Ratio of profitable trades to total trades.
Profit Factor = Total gross profit per unit of losses.
Expectancy = Average expected return per trade.
Trades/Year = Average number of trades per year.
This indicator is designed with flexibility in mind, enabling users to specify the start date of the backtesting period, the preferred volatility type, and the price source. Supported volatility types include the Average True Range (ATR), Standard Deviation (SD), and Mean Absolute Deviation (MAD). Supported price sources include Close, Heikin Ashi, HL2, HLC3, and OHLC4. To minimize overfitting, users can define constraints such as a minimum and maximum number of trades per year, as well as an optional optimization margin that prioritizes more robust combinations by requiring more reactive combinations to exceed this threshold. The table follows an intuitive color-coded logic that enables quick performance comparison against buy-and-hold (B&H):
Sharpe = Green indicates better than B&H, while red indicates worse.
Sortino = Green indicates better than B&H, while red indicates worse.
Calmar = Green indicates better than B&H, while red indicates worse.
Max DD = Green indicates better than B&H, while red indicates worse.
Beta (β) = Green indicates better than B&H, while red indicates worse.
Alpha (α) = Green indicates above 0%, while red indicates below 0%.
Win Rate = Green indicates above 50%, while red indicates below 50%.
Profit Factor = Green indicates above 2, while red indicates below 1.
Expectancy = Green indicates above 0%, while red indicates below 0%.
In summary, the Volatility Stop Selector is a powerful tool designed to help investors make data-driven decisions when selecting volatility-based trend-following strategies. By optimizing for risk-adjusted returns, investors can identify the best configurations using institutional-grade metrics. While results are based on the selected historical period, users should be mindful of overfitting, as past results may not persist under future market conditions. Since the model continuously recalibrates to incorporate new data, the recommended length and factor may evolve over time. Indicator
Adaptive Trend SelectorThe Adaptive Trend Selector is a comprehensive trend-following tool designed to automatically identify the optimal moving average crossover strategy. It features adjustable parameters and an integrated backtester that delivers institutional-grade insights into the recommended strategy. The model continuously adapts to new data in real time by evaluating multiple moving average combinations, determining the best performing lengths, and presenting the backtest results in a clear, color-coded table that benchmarks performance against the buy-and-hold strategy.
At its core, the model systematically backtests a wide range of moving average combinations to identify the configuration that maximizes the selected optimization metric. Users can choose to optimize for absolute returns or risk-adjusted returns using the Sharpe, Sortino, or Calmar ratios. Alternatively, users can enable manual optimization to test custom fast and slow moving average lengths and view the corresponding backtest results. The label displays the Compounded Annual Growth Rate (CAGR) of the strategy, with the buy-and-hold CAGR in parentheses for comparison. The table presents the backtest results based on the fast and slow lengths displayed at the top:
Sharpe = CAGR per unit of standard deviation.
Sortino = CAGR per unit of downside deviation.
Calmar = CAGR relative to maximum drawdown.
Max DD = Largest peak-to-trough decline in value.
Beta (β) = Return sensitivity relative to buy-and-hold.
Alpha (α) = Excess annualized risk-adjusted returns.
Win Rate = Ratio of profitable trades to total trades.
Profit Factor = Total gross profit per unit of losses.
Expectancy = Average expected return per trade.
Trades/Year = Average number of trades per year.
This indicator is designed with flexibility in mind, enabling users to specify the start date of the backtesting period and the preferred moving average strategy. Supported strategies include the Exponential Moving Average (EMA), Simple Moving Average (SMA), Wilder’s Moving Average (RMA), Weighted Moving Average (WMA), and Volume-Weighted Moving Average (VWMA). To minimize overfitting, users can define constraints such as a minimum and maximum number of trades per year, as well as an optional optimization margin that prioritizes longer, more robust combinations by requiring shorter-length strategies to exceed this threshold. The table follows an intuitive color logic that enables quick performance comparison against buy-and-hold (B&H):
Sharpe = Green indicates better than B&H, while red indicates worse.
Sortino = Green indicates better than B&H, while red indicates worse.
Calmar = Green indicates better than B&H, while red indicates worse.
Max DD = Green indicates better than B&H, while red indicates worse.
Beta (β) = Green indicates better than B&H, while red indicates worse.
Alpha (α) = Green indicates above 0%, while red indicates below 0%.
Win Rate = Green indicates above 50%, while red indicates below 50%.
Profit Factor = Green indicates above 2, while red indicates below 1.
Expectancy = Green indicates above 0%, while red indicates below 0%.
In summary, the Adaptive Trend Selector is a powerful tool designed to help investors make data-driven decisions when selecting moving average crossover strategies. By optimizing for risk-adjusted returns, investors can confidently identify the best lengths using institutional-grade metrics. While results are based on the selected historical period, users should be mindful of potential overfitting, as past results may not persist under future market conditions. Since the model recalibrates to incorporate new data, the recommended lengths may evolve over time. Indicator
PnL Bubble [%] | Fractalyst1. What's the indicator purpose?
The PnL Bubble indicator transforms your strategy's trade PnL percentages into an interactive bubble chart with professional-grade statistics and performance analytics. It helps traders quickly assess system profitability, understand win/loss distribution patterns, identify outliers, and make data-driven strategy improvements.
How does it work?
Think of this indicator as a visual report card for your trading performance. Here's what it does:
What You See
Colorful Bubbles: Each bubble represents one of your trades
Blue/Cyan bubbles = Winning trades (you made money)
Red bubbles = Losing trades (you lost money)
Bigger bubbles = Bigger wins or losses
Smaller bubbles = Smaller wins or losses
How It Organizes Your Trades:
Like a Photo Album: Instead of showing all your trades at once (which would be messy), it shows them in "pages" of 500 trades each:
Page 1: Your first 500 trades
Page 2: Trades 501-1000
Page 3: Trades 1001-1500, etc.
What the Numbers Tell You:
Average Win: How much money you typically make on winning trades
Average Loss: How much money you typically lose on losing trades
Expected Value (EV): Whether your trading system makes money over time
Positive EV = Your system is profitable long-term
Negative EV = Your system loses money long-term
Payoff Ratio (R): How your average win compares to your average loss
R > 1 = Your wins are bigger than your losses
R < 1 = Your losses are bigger than your wins
Why This Matters:
At a Glance: You can instantly see if you're a profitable trader or not
Pattern Recognition: Spot if you have more big wins than big losses
Performance Tracking: Watch how your trading improves over time
Realistic Expectations: Understand what "average" performance looks like for your system
The Cool Visual Effects:
Animation: The bubbles glow and shimmer to make the chart more engaging
Highlighting: Your biggest wins and losses get extra attention with special effects
Tooltips: hover any bubble to see details about that specific trade.
What are the underlying calculations?
The indicator processes trade PnL data using a dual-matrix architecture for optimal performance:
Dual-Matrix System:
• Display Matrix (display_matrix): Bounded to 500 trades for rendering performance
• Statistics Matrix (stats_matrix): Unbounded storage for complete statistical accuracy
Trade Classification & Aggregation:
// Separate wins, losses, and break-even trades
if val > 0.0
pos_sum += val // Sum winning trades
pos_count += 1 // Count winning trades
else if val < 0.0
neg_sum += val // Sum losing trades
neg_count += 1 // Count losing trades
else
zero_count += 1 // Count break-even trades
Statistical Averages:
avg_win = pos_count > 0 ? pos_sum / pos_count : na
avg_loss = neg_count > 0 ? math.abs(neg_sum) / neg_count : na
Win/Loss Rates:
total_obs = pos_count + neg_count + zero_count
win_rate = pos_count / total_obs
loss_rate = neg_count / total_obs
Expected Value (EV):
ev_value = (avg_win × win_rate) - (avg_loss × loss_rate)
Payoff Ratio (R):
R = avg_win ÷ |avg_loss|
Contribution Analysis:
ev_pos_contrib = avg_win × win_rate // Positive EV contribution
ev_neg_contrib = avg_loss × loss_rate // Negative EV contribution
How to integrate with any trading strategy?
Equity Change Tracking Method:
//@version=6
strategy("Your Strategy with Equity Change Export", overlay=true)
float prev_trade_equity = na
float equity_change_pct = na
if barstate.isconfirmed and na(prev_trade_equity)
prev_trade_equity := strategy.equity
trade_just_closed = strategy.closedtrades != strategy.closedtrades
if trade_just_closed and not na(prev_trade_equity)
current_equity = strategy.equity
equity_change_pct := ((current_equity - prev_trade_equity) / prev_trade_equity) * 100
prev_trade_equity := current_equity
else
equity_change_pct := na
plot(equity_change_pct, "Equity Change %", display=display.data_window)
Integration Steps:
1. Add equity tracking code to your strategy
2. Load both strategy and PnL Bubble indicator on the same chart
3. In bubble indicator settings, select your strategy's equity tracking output as data source
4. Configure visualization preferences (colors, effects, page navigation)
How does the pagination system work?
The indicator uses an intelligent pagination system to handle large trade datasets efficiently:
Page Organization:
• Page 1: Trades 1-500 (most recent)
• Page 2: Trades 501-1000
• Page 3: Trades 1001-1500
• Page N: Trades to
Example: With 1,500 trades total (3 pages available):
• User selects Page 1: Shows trades 1-500
• User selects Page 4: Automatically falls back to Page 3 (trades 1001-1500)
5. Understanding the Visual Elements
Bubble Visualization:
• Color Coding: Cyan/blue gradients for wins, red gradients for losses
• Size Mapping: Bubble size proportional to trade magnitude (larger = bigger P&L)
• Priority Rendering: Largest trades displayed first to ensure visibility
• Gradient Effects: Color intensity increases with trade magnitude within each category
Interactive Tooltips:
Each bubble displays quantitative trade information:
tooltip_text = outcome + " | PnL: " + pnl_str +
" Date: " + date_str + " " + time_str +
" Trade #" + str.tostring(trade_number) + " (Page " + str.tostring(active_page) + ")" +
" Rank: " + str.tostring(rank) + " of " + str.tostring(n_display_rows) +
" Percentile: " + str.tostring(percentile, "#.#") + "%" +
" Magnitude: " + str.tostring(magnitude_pct, "#.#") + "%"
Example Tooltip:
Win | PnL: +2.45%
Date: 2024.03.15 14:30
Trade #1,247 (Page 3)
Rank: 5 of 347
Percentile: 98.6%
Magnitude: 85.2%
Reference Lines & Statistics:
• Average Win Line: Horizontal reference showing typical winning trade size
• Average Loss Line: Horizontal reference showing typical losing trade size
• Zero Line: Threshold separating wins from losses
• Statistical Labels: EV, R-Ratio, and contribution analysis displayed on chart
What do the statistical metrics mean?
Expected Value (EV):
Represents the mathematical expectation per trade in percentage terms
EV = (Average Win × Win Rate) - (Average Loss × Loss Rate)
Interpretation:
• EV > 0: Profitable system with positive mathematical expectation
• EV = 0: Break-even system, profitability depends on execution
• EV < 0: Unprofitable system with negative mathematical expectation
Example: EV = +0.34% means you expect +0.34% profit per trade on average
Payoff Ratio (R):
Quantifies the risk-reward relationship of your trading system
R = Average Win ÷ |Average Loss|
Interpretation:
• R > 1.0: Wins are larger than losses on average (favorable risk-reward)
• R = 1.0: Wins and losses are equal in magnitude
• R < 1.0: Losses are larger than wins on average (unfavorable risk-reward)
Example: R = 1.5 means your average win is 50% larger than your average loss
Contribution Analysis (Σ):
Breaks down the components of expected value
Positive Contribution (Σ+) = Average Win × Win Rate
Negative Contribution (Σ-) = Average Loss × Loss Rate
Purpose:
• Shows how much wins contribute to overall expectancy
• Shows how much losses detract from overall expectancy
• Net EV = Σ+ - Σ- (Expected Value per trade)
Example: Σ+: 1.23% means wins contribute +1.23% to expectancy
Example: Σ-: -0.89% means losses drag expectancy by -0.89%
Win/Loss Rates:
Win Rate = Count(Wins) ÷ Total Trades
Loss Rate = Count(Losses) ÷ Total Trades
Shows the probability of winning vs losing trades
Higher win rates don't guarantee profitability if average losses exceed average wins
7. Demo Mode & Synthetic Data Generation
When using built-in sources (close, open, etc.), the indicator generates realistic demo trades for testing:
if isBuiltInSource(source_data)
// Generate random trade outcomes with realistic distribution
u_sign = prand(float(time), float(bar_index))
if u_sign < 0.5
v_push := -1.0 // Loss trade
else
// Skewed distribution favoring smaller wins (realistic)
u_mag = prand(float(time) + 9876.543, float(bar_index) + 321.0)
k = 8.0 // Skewness factor
t = math.pow(u_mag, k)
v_push := 2.5 + t * 8.0 // Win trade
Demo Characteristics:
• Realistic win/loss distribution mimicking actual trading patterns
• Skewed distribution favoring smaller wins over large wins
• Deterministic randomness for consistent demo results
• Includes jitter effects to prevent visual overlap
8. Performance Limitations & Optimizations
Display Constraints:
points_count = 500 // Maximum 500 dots per page for optimal performance
Pine Script v6 Limits:
• Label Count: Maximum 500 labels per indicator
• Line Count: Maximum 100 lines per indicator
• Box Count: Maximum 50 boxes per indicator
• Matrix Size: Efficient memory management with dual-matrix system
Optimization Strategies:
• Pagination System: Handle unlimited trades through 500-trade pages
• Priority Rendering: Largest trades displayed first for maximum visibility
• Dual-Matrix Architecture: Separate display (bounded) from statistics (unbounded)
• Smart Fallback: Automatic page clamping prevents empty displays
Impact & Workarounds:
• Visual Limitation: Only 500 trades visible per page
• Statistical Accuracy: Complete dataset used for all calculations
• Navigation: Use page input to browse through entire trade history
• Performance: Smooth operation even with thousands of trades
9. Statistical Accuracy Guarantees
Data Integrity:
• Complete Dataset: Statistics matrix stores ALL trades without limit
• Proper Aggregation: Separate tracking of wins, losses, and break-even trades
• Mathematical Precision: Pine Script v6's enhanced floating-point calculations
• Dual-Matrix System: Display limitations don't affect statistical accuracy
Calculation Validation:
// Verified formulas match standard trading mathematics
avg_win = pos_sum / pos_count // Standard average calculation
win_rate = pos_count / total_obs // Standard probability calculation
ev_value = (avg_win * win_rate) - (avg_loss * loss_rate) // Standard EV formula
Accuracy Features:
• Mathematical Correctness: Formulas follow established trading statistics
• Data Preservation: Complete dataset maintained for all calculations
• Precision Handling: Proper rounding and boundary condition management
• Real-Time Updates: Statistics recalculated on every new trade
10. Advanced Technical Features
Real-Time Animation Engine:
// Shimmer effects with sine wave modulation
offset = math.sin(shimmer_t + phase) * amp
// Dynamic transparency with organic flicker
new_transp = math.min(flicker_limit, math.max(-flicker_limit, cur_transp + dir * flicker_step))
• Sine Wave Shimmer: Dynamic glowing effects on bubbles
• Organic Flicker: Random transparency variations for natural feel
• Extreme Value Highlighting: Special visual treatment for outliers
• Smooth Animations: Tick-based updates for fluid motion
Magnitude-Based Priority Rendering:
// Sort trades by magnitude for optimal visual hierarchy
sort_indices_by_magnitude(values_mat)
• Largest First: Most important trades always visible
• Intelligent Sorting: Custom bubble sort algorithm for trade prioritization
• Performance Optimized: Efficient sorting for real-time updates
• Visual Hierarchy: Ensures critical trades never get hidden
Professional Tooltip System:
• Quantitative Data: Pure numerical information without interpretative language
• Contextual Ranking: Shows trade position within page dataset
• Percentile Analysis: Performance ranking as percentage
• Magnitude Scaling: Relative size compared to page maximum
• Professional Format: Clean, data-focused presentation
11. Quick Start Guide
Step 1: Add Indicator
• Search for "PnL Bubble | Fractalyst" in PulseWire indicators
• Add to your chart (works on any timeframe)
Step 2: Configure Data Source
• Demo Mode: Leave source as "close" to see synthetic trading data
• Strategy Mode: Select your strategy's PnL% output as data source
Step 3: Customize Visualization
• Colors: Set positive (cyan), negative (red), and neutral colors
• Page Navigation: Use "Trade Page" input to browse trade history
• Visual Effects: Built-in shimmer and animation effects are enabled by default
Step 4: Analyze Performance
• Study bubble patterns for win/loss distribution
• Review statistical metrics: EV, R-Ratio, Win Rate
• Use tooltips for detailed trade analysis
• Navigate pages to explore full trade history
Step 5: Optimize Strategy
• Identify outlier trades (largest bubbles)
• Analyze risk-reward profile through R-Ratio
• Monitor Expected Value for system profitability
• Use contribution analysis to understand win/loss impact
12. Why Choose PnL Bubble Indicator?
Unique Advantages:
• Advanced Pagination: Handle unlimited trades with smart fallback system
• Dual-Matrix Architecture: Perfect balance of performance and accuracy
• Professional Statistics: Institution-grade metrics with complete data integrity
• Real-Time Animation: Dynamic visual effects for engaging analysis
• Quantitative Tooltips: Pure numerical data without subjective interpretations
• Priority Rendering: Intelligent magnitude-based display ensures critical trades are always visible
Technical Excellence:
• Built with Pine Script v6 for maximum performance and modern features
• Optimized algorithms for smooth operation with large datasets
• Complete statistical accuracy despite display optimizations
• Professional-grade calculations matching institutional trading analytics
Practical Benefits:
• Instantly identify system profitability through visual patterns
• Spot outlier trades and risk management issues
• Understand true risk-reward profile of your strategies
• Make data-driven decisions for strategy optimization
• Professional presentation suitable for performance reporting
Disclaimer & Risk Considerations:
Important: Historical performance metrics, including positive Expected Value (EV), do not guarantee future trading success. Statistical measures are derived from finite sample data and subject to inherent limitations:
• Sample Bias: Historical data may not represent future market conditions or regime changes
• Ergodicity Assumption: Markets are non-stationary; past statistical relationships may break down
• Survivorship Bias: Strategies showing positive historical EV may fail during different market cycles
• Parameter Instability: Optimal parameters identified in backtesting often degrade in forward testing
• Transaction Cost Evolution: Slippage, spreads, and commission structures change over time
• Behavioral Factors: Live trading introduces psychological elements absent in backtesting
• Black Swan Events: Extreme market events can invalidate statistical assumptions instantaneously Indicator
*Auto Backtest & Optimize EngineFull-featured Engine for Automatic Backtesting and parameter optimization. Allows you to test millions of different combinations of stop-loss and take profit parameters, including on any connected indicators.
⭕️ Key Futures
Quickly identify the optimal parameters for your strategy.
Automatically generate and test thousands of parameter combinations.
A simple Genetic Algorithm for result selection.
Saves time on manual testing of multiple parameters.
Detailed analysis, sorting, filtering and statistics of results.
Detailed control panel with many tooltips.
Display of key metrics: Profit, Win Rate, etc..
Comprehensive Strategy Score calculation.
In-depth analysis of the performance of different types of stop-losses.
Possibility to use to calculate the best Stop-Take parameters for your position.
Ability to test your own functions and signals.
Customizable visualization of results.
Flexible Stop-Loss Settings:
• Auto ━ Allows you to test all types of Stop Losses at once(listed below).
• S.VOLATY ━ Static stop based on volatility (Fixed, ATR, STDEV).
• Trailing ━ Classic trailing stop following the price.
• Fast Trail ━ Accelerated trailing stop that reacts faster to price movements.
• Volatility ━ Dynamic stop based on volatility indicators.
• Chandelier ━ Stop based on price extremes.
• Activator ━ Dynamic stop based on SAR.
• MA ━ Stop based on moving averages (9 different types).
• SAR ━ Parabolic SAR (Stop and Reverse).
Advanced Take-Profit Options:
• R:R: Risk/Reward ━ sets TP based on SL size.
• T.VOLATY ━ Calculation based on volatility indicators (Fixed, ATR, STDEV).
Testing Modes:
• Stops ━ Cyclical stop-loss testing
• Pivot Point Example ━ Example of using pivot points
• External Example ━ Built-in example how test functions with different parameters
• External Signal ━ Using external signals
⭕️ Usage
━ First Steps:
When opening, select any point on the chart. It will not affect anything until you turn on Manual Start mode (more on this below).
The chart will immediately show the best results of the default Auto mode. You can switch Part's to try to find even better results in the table.
Now you can display any result from the table on the chart by entering its ID in the settings.
Repeat steps 3-4 until you determine which type of Stop Loss you like best. Then set it in the settings instead of Auto mode.
* Example: I flipped through 14 parts before I liked the first result and entered its ID so I could visually evaluate it on the chart.
Then select the stop loss type, choose it in place of Auto mode and repeat steps 3-4 or immediately follow the recommendations of the algorithm.
Now the Genetic Algorithm at the bottom right will prompt you to enter the Parameters you need to search for and select even better results.
Parameters must be entered All at once before they are updated. Enter recommendations strictly in fields with the same names.
Repeat steps 5-6 until there are approximately 10 Part's left or as you like. And after that, easily pour through the remaining Parts and select the best parameters.
━ Example of the finished result.
━ Example of use with Takes
You can also test at the same time along with Take Profit. In this example, I simply enabled Risk/Reward mode and immediately specified in the TP field Maximum RR, Minimum RR and Step. So in this example I can test (3-1) / 0.1 = 20 Takes of different sizes. There are additional tips in the settings.
━
* Soon you will start to understand how the system works and things will become much easier.
* If something doesn't work, just reset the engine settings and start over again.
* Use the tips I have left in the settings and on the Panel.
━ Details:
Sort ━ Sorting results by Score, Profit, Trades, etc..
Filter ━ Filtring results by Score, Profit, Trades, etc..
Trade Type ━ Ability to disable Long\Short but only from statistics.
BackWin ━ Backtest Window Number of Candle the script can test.
Manual Start ━ Enabling it will allow you to call a Stop from a selected point. which you selected when you started the engine.
* If you have a real open position then this mode can help to save good Stop\Take for it.
1 - 9 Сheckboxs ━ Allow you to disable any stop from Auto mode.
Ex Source - Allow you to test Stops/Takes from connected indicators.
Connection guide:
//@version=6
indicator("My script")
rsi = ta.rsi(close, 14)
buy = not na(rsi) and ta.crossover (rsi, 40) // OS = 40
sell = not na(rsi) and ta.crossunder(rsi, 60) // OB = 60
Signal = buy ? +1 : sell ? -1 : 0
plot(Signal, "🔌Connector🔌", display = display.none)
* Format the signal for your indicator in a similar style and then select it in Ex Source.
⭕️ How it Works
Hypothesis of Uniform Distribution of Rare Elements After Mixing.
'This hypothesis states that if an array of N elements contains K valid elements, then after mixing, these valid elements will be approximately uniformly distributed.'
'This means that in a random sample of k elements, the proportion of valid elements should closely match their proportion in the original array, with some random variation.'
'According to the central limit theorem, repeated sampling will result in an average count of valid elements following a normal distribution.'
'This supports the assumption that the valid elements are evenly spread across the array.'
'To test this hypothesis, we can conduct an experiment:'
'Create an array of 1,000,000 elements.'
'Select 1,000 random elements (1%) for validation.'
'Shuffle the array and divide it into groups of 1,000 elements.'
'If the hypothesis holds, each group should contain, on average, 1~ valid element, with minor variations.'
* I'd like to attach more details to My hypothesis but it won't be very relevant here. Since this is a whole separate topic, I will leave the minimum part for understanding the engine.
Practical Application
To apply this hypothesis, I needed a way to generate and thoroughly mix numerous possible combinations. Within Pine, generating over 100,000 combinations presents significant challenges, and storing millions of combinations requires excessive resources.
I developed an efficient mechanism that generates combinations in random order to address these limitations. While conventional methods often produce duplicates or require generating a complete list first, my approach guarantees that the first 10% of possible combinations are both unique and well-distributed. Based on my hypothesis, this sampling is sufficient to determine optimal testing parameters.
Most generators and randomizers fail to accommodate both my hypothesis and Pine's constraints. My solution utilizes a simple Linear Congruential Generator (LCG) for pseudo-randomization, enhanced with prime numbers to increase entropy during generation. I pre-generate the entire parameter range and then apply systematic mixing. This approach, combined with a hybrid combinatorial array-filling technique with linear distribution, delivers excellent generation quality.
My engine can efficiently generate and verify 300 unique combinations per batch. Based on the above, to determine optimal values, only 10-20 Parts need to be manually scrolled through to find the appropriate value or range, eliminating the need for exhaustive testing of millions of parameter combinations.
For the Score statistic I applied all the same, generated a range of Weights, distributed them randomly for each type of statistic to avoid manual distribution.
Score ━ based on Trade, Profit, WinRate, Profit Factor, Drawdown, Sharpe & Sortino & Omega & Calmar Ratio.
⭕️ Notes
For attentive users, a little tricks :)
To save time, switch parts every 3 seconds without waiting for it to load. After 10-20 parts, stop and wait for loading. If the pause is correct, you can switch between the rest of the parts without loading, as they will be cached. This used to work without having to wait for a pause, but now it does slower. This will save a lot of time if you are going to do a deeper backtest.
Sometimes you'll get the error “The scripts take too long to execute.”
For a quick fix you just need to switch the TF or Ticker back and forth and most likely everything will load.
The error appears because of problems on the side of the site because the engine is very heavy. It can also appear if you set too long a period for testing in BackWin or use a heavy indicator for testing.
Manual Start - Allow you to Start you Result from any point. Which in turn can help you choose a good stop-stick for your real position.
* It took me half a year from idea to current realization. This seems to be one of the few ways to build something automatic in backtest format and in this particular Pine environment. There are already better projects in other languages, and they are created much easier and faster because there are no limitations except for personal PC. If you see solutions to improve this system I would be glad if you share the code. At the moment I am tired and will continue him not soon.
Also You can use my previosly big Backtest project with more manual settings(updated soon)
Indicator
Walk Forward PatternsINTRO
In Euclidean geometry, every mathematical output has a planar projection. 'Walk Forward Patterns' can be considered a practical example of this concept. On the other hand, this indicator might also be viewed as an experiment in 'how playing with Lego as a child contributes to time series analysis' :)
OVERVIEW
This script dynamically generates the necessary optimization and testing ranges for Walk Forward Analysis based on user-defined bar count and length inputs. It performs automatic calculations for each step, offers 8 different window options depending on the inputs, and visualizes the results dynamically. I should also note that most of the window models consist of original patterns I have created.
ADDITIONAL INFO : WHAT IS WALK FORWARD ANALYSIS?
Although it is not the main focus of this indicator, providing a brief definition of Walk Forward Analysis can be helpful in correctly interpreting the results it generates. Walk Forward Analysis (WFA) is a systematic method for optimizing parameters and validating trading strategies. It involves dividing historical data into variable segments, where a strategy is first optimized on an in-sample period and then tested on an out-of-sample period. This process repeats by shifting the windows forward, ensuring that each test evaluates the strategy on unseen data, helping to assess its robustness and adaptability in real market conditions.
ORIGINALITY
There are very few studies on Walk Forward Analysis in PulseWire. Even worse, there are no any open-source studies available. Someone has to start somewhere, I suppose. And in my personal opinion, determining the optimization and backtest intervals is the most challenging part of WFA. These intervals serve as a prerequisite for automated parameter optimization. I felt the need to publish this pattern module, which I use in my own WFA models, partly due to this gap on community scripts.
INDICATOR MECHANICS
To use the indicator effectively, you only need to perform four simple tasks:
Specify the total number of bars in your chart in the 'Bar Index' parameter.
Define the optimization (In-Sample Test) length.
Define the testing (Out-Of-Sample Test) length.
Finally, select the window type.
The indicator automatically models everything else (including the number of steps) based on your inputs. And the result; you now have a clear idea of which bars to use for your Walk Forward tests!
A COMMONLY USED WINDOW SELECTION METHOD: ROLLING
A more concrete definition of Walk Forward Analysis, specifically for the widely used Rolling method, can be described as follows:
Parameters that have performed well over a certain period are identified (Optimization: In-Sample).
These parameters are then tested on a shorter, subsequent period (Backtest: Out-of-Sample).
The process is repeated forward in time (At each step, the optimization and backtest periods are shifted by the backtest length).
If the cumulative percentage profit obtained from the backtest results is greater than half of the historical optimization profit, the strategy is considered "successful."
If the strategy is successful, the most recent (untested) optimization values are used for live trading.
OTHER WINDOW OPTIONS
ANCHORED: That's a pattern based on progressively expanding optimization ranges at each step. Backtest ranges move forward in a staircase-like manner.
STATIC: Optimization ranges remain fixed, while backtest ranges are shifted forward.
BLOCKED: Optimization ranges are shifted forward in groups of three blocks. Backtest ranges are also shifted in a staircase manner, even at the cost of creating gaps from the optimization end bars.
TRIANGULAR: Optimization ranges are shifted forward in triangular regions, while backtest ranges move in a staircase pattern.
RATIO: The optimization length increases by 25% of the initial step’s fixed length at each step. In other words, the length grows by 25% of the first step's length incrementally. Backtest ranges always start from the bar where the optimization ends.
FIBONACCI: A variation of the Ratio method, where the optimization shift factor is set to 0.618
RANDOM WALK
Unlike the window models explained above, we can also generate optimization and backtest ranges completely randomly—offering almost unlimited variations! When you select the "Random" option in the "Window" parameter on the indicator interface, random intervals are generated based on various trigonometric calculations. By changing the numerical value in the '🐒' parameter, you can create entirely unique patterns.
WHY THE 🐒 EMOJI?
Two reasons.
First, I think that as humanity, we are a species of tailless primates who become happy when we understand things :). At least evolutionarily. The entire history of civilization is built on the effort to express the universe in a scale we can comprehend. 'Knowledge' is an invention born from this effort, which is why we feel happiness when we 'understand'. Second, I can't think of a better metaphor for randomness than a monkey sitting at a keyboard. See: Monkey Test.
Anyway, I’m rambling :)
NOTES
The indicator generates results for up to 100 steps. As the number of steps increases, the table may extend beyond the screen—don’t forget to zoom out!
FINAL WORDS
I haven’t published a Walk Forward script yet . However, there seem to be examples that can perform parameter optimization in the true sense of the word, producing more realistic results without falling into overfitting in my library. Hopefully, I’ll have the chance to publish one in the coming weeks. Sincerely thanks to Kıvanç Özbilgiç, Robert Pardo, Kevin Davey, Ernest P. Chan for their inspiring publishments.
DISCLAIMER
That's just a script, nothing more. I hope it helps everyone. Do not forget to manage your risk. And trade as safely as possible. Best of luck!
© dg_factor
Indicator
Moving Average PropertiesThis indicator calculates and visualizes the Relative Smoothness (RS) and Relative Lag (RL) or call it accuracy of a selected moving average (MA) in comparison to the SMA of length 2 (the lowest possible length for a moving average and also the one closest to the price).
Median RS (Relative Smoothness):
Interpretation: The median RS represents the median value of the Relative Smoothness calculated for the selected moving average across a specified look-back period (max bar lookback is set at 3000).
Significance: A more negative (larger) median RS suggests that the chosen moving average has exhibited smoother price behavior compared to a simple moving average over the analyzed period. A less negative value indicates a relatively choppier price movement.
Median RL (Relative Lag):
Interpretation: The median RL represents the median value of the Relative Lag calculated for the selected moving average compared to a simple moving average of length 2.
Significance: A higher median RL indicates that the chosen moving average tends to lag more compared to a simple moving average. Conversely, lower values suggest less lag in the selected moving average.
Ratio of Median RS to Median RL:
Interpretation: This ratio is calculated by dividing the median RS by the median RL.
Significance: Traders might use this ratio to assess the balance between smoothness and lag in the chosen moving average. This a measure of for every % of lag what is the smoothness achieved. This can be used a benchmark to decide what length to choose for a MA to get an equivalent value between two stocks. For example a TESLA stock on a 15 minute time frame with a length of 12 has a value (ratio of RS/RL) of -150 , where as APPLE stock of length 35 on a 15 minute chart also has a value (ratio of RS/RL) of -150.
I imply that a MA of length 12 working on TESLA stock is equivalent to MA of length 35 on a APPLE stock. (THIS IS A EXAMPLE).
My assumption is that finding the right moving average length for a stock isn't a one-size-fits-all situation. It's not just about using a fixed length; it's about adapting to the unique characteristics of each stock. I believe that what works for one stock might not work for another because they have different levels of smoothness or lag in their price movements. So, instead of applying the same length to all stocks, I suggest adjusting the length of the moving average to match the values that we know work best for achieving the desired smoothness or lag or its ratio (RS/RL). This way, we're customizing the indicator for each stock, tailoring it to their individual behaviors rather than sticking to a one-size-fits-all approach.
Users can choose from various types of moving averages (EMA, SMA, WMA, VWMA, HMA) and customize the length of the moving average. RS measures the smoothness of the MA, while RL measures its lag compared to a simple moving average. The script plots the median RS and RL values, the selected MA, and the ratio of median RS to median RL on the price chart. Traders can use this information to assess the performance of different moving averages and potentially inform their trading decisions. Indicator
Backtest any Indicator v5Happy Trade,
here you get the opportunity to backtest any of your indicators like a strategy without converting them into a strategy. You can choose to go long or go short and detailed time filters. Further more you can set the take profit and stop loss, initial capital, quantity per trade and set the exchange fees. You get an overall result table and even a detailed, scroll-able table with all trades. In the Image 1 you see the provided info tables about all Trades and the Result Summary. Further more every trade is marked by a background color, Labels and Levels. An opening Label with the trade direction and trade number. A closing Label again with the trade number, the trades profit in % and the total amount of $ after all past trades. A green line for the take profit level and a red line for the stop loss.
Image 1
Example
For this description we choose the Stochastic RSI indicator from PulseWire as it is. In Image 2 is shown the performance of it with decent settings.
Timeframe=45, BTCUSD, 2023-08-01 - 2023-10-20
Stoch RSI: k=30, d=40, RSI-length=140, stoch-length=140
Backtest any Indicator: input signal=Stoch RSI, goLong, take profit=9.1%, stop loss=2.5%, start capital=1000$, qty=5%, fee=0.1%, no Session Filter
Image 2
Usage
1) You need to know the name of the boolean (or integer) variable of your indicator which hold the buy condition. Lets say that this boolean variable is called BUY. If this BUY variable is not plotted on the chart you simply add the following code line at the end of your pine script.
For boolean (true/false) BUY variables use this:
plot(BUY ? 1:0,'Your buy condition hold in that variable BUY',display = display.data_window)
And in case your script's BUY variable is an integer or float then use instate the following code line:
plot(BUY ,'Your buy condition hold in that variable BUY',display = display.data_window)
2) Probably the name of this BUY variable in your indicator is not BUY. Simply replace in the code line above the BUY with the name of your script's trade condition variable.
3) Save your changed Indicator script.
4) Then add this 'Backtest any Indicator' script to the chart ...
5) and go to the settings of it. Choose under "Settings -> Buy Signal" your Indicator. So in the example above choose .
The form is usually: ' : BUY'. Then you see something like Image 2
6) Decide which trade direction the BUY signal should trigger. A go Long or a go Short by set the hook or not.
Now you have a backtest of your Indicator without converting it into a strategy. You may change the setting of your Indicator to the best results and setup the following strategy settings like Time- and Session Filter, Stop Loss, Take Profit etc. More of it below in the section Settings Menu.
Appereance
In the Image 2 you see on the right side the List of Trades . To scroll down you go into the settings again and decrease the scroll value. So you can see all trades that have happened before. In case there is an open trade you will find it at the last position of the list.
Every Long trade is green back grounded while Short trades are red.
Every trade begins with a label that show goLong or goShort and its number. And ends with another label again with its number, Profit in % and the resulting total amount of cash.
If activated you further see the Take Profit as a green line and the Stop Loss as a orange line. In the settings you can set their percentage above or below the entry price.
You also see the Result Summary below. Here you find the usual stats of a strategy of all closed trades. The profit after total amount of fees , amount of trades, Profit Factor and the total amount of fees .
Settings Menu
In the settings menu you will find the following high-lighted sections. Most of the settings have a question mark on their right side. Move over it with the cursor to read specific explanation.
Input Signal of your Indicator: Under Buy you set the trade signal of your Indicator. And under Target you set the value when a trade should happen. In the Example with the Stochastic RSI above we used 20. Below you can set the trade direction, let it be go short when hooked or go long when unhooked.
Trade Settings & List of Trades: Take Profit set the target price of any trade. Stop Loss set the price to step out when a trade goes the wrong direction. Check mark the List of Trades to see any single trade with their stats. In case that there are more trades as fits in the list you can scroll down the list by decrease the value Scroll .
Time Filter: You can set a Start Time or deactivate it by leave it unhooked. The same with End Time .
Session Filter: here you can choose to activate it on weekly base. Which days of the week should be trading and those without. And also on daily base from which time on and until trade are possible. Outside of all times and sessions there will be no new trades if activated.
Invest Settings: here you can choose the amount of cash to start with. The Quantity percentage define for every trade how much of the cash should be invested and the Fee percentage which have to be payed every trade. Open position and closing position.
Other Announcements
This Backtest script don't use the strategy functions of PulseWire. It is programmed as an indicator. All trades get executed at candle closing. This script use the functionality "Indicator-on-Indicator" from PulseWire.
Conclusion
So now it is your turn, take your promising indicators and connect it to that Backtest script. With it you get a fast impression of how successful your indicator will trade. You don't have to relay on coders who maybe add cheating code lines. Further more you can check with the Time Filter under which market condition you indicator perform the best or not so well. Also with the Session Filter you can sort out repeating good market conditions for your indicator. Even you can check with the GoShort XOR GoLong check mark the trade signals of you indicator in opposite trade direction with one click. And compare your indicators under the same conditions and get the results just after 2 clicks. Thanks to the in-build fee setting you get an impression how much a 0.1% fee cost you in total.
Cheers Indicator
Indicator
Logistic RSI, STOCH, ROC, AO, ... by DGTExperimental attemt of applying Logistic Map Equation for some of widly used indicators.
With this study "Awesome Oscillator (AO)", "Rate of Change (ROC)", "Relative Strength Index (RSI)", "Stochastic (STOCH)" and a custom interpretation of Logistic Map Equation is presented
Calculations with Logistic Map Equation makes sense when the calculated results are iterated many times within the same equation.
Here is the Logistic Map Equation : Xn+1 = r * Xn * (1 - Xn)
Where, the value of r is the key for this equation which changes amazingly the behaviour of the Logistic Map.
The value we have asigned for r is less then 1 and greater than 0 ( 0 < r < 1) and in this case the iterations performed with the maximum number of output series allowed by Pine is quite enough for our purpose and thanks to arrays we can easiliy store them for further processing
What we have as output:
Each iteration result is then plotted (excluding plotting the first iteration), as circles or line based on user preference
Values above and below zero level (0) are coloured differently to emphasis bull and bear power
Finally Standard Deviation of Array's Elements is ploted as line. Users may choose to display this line only
So where it comes the indicators "Awesome Oscillator (AO)", "Rate of Change (ROC)", "Relative Strength Index (RSI)", "Stochastic (STOCH)".
Those are the indicators whose values are assigned to our key varaiable in the Logistic Map equation forulma which is r
Further details regarding Logistic Map can found under the description of “Logistic EMA w/ Signals by DGT” study
Disclaimer:
Trading success is all about following your trading strategy and the indicators should fit within your trading strategy, and not to be traded upon solely
The script is for informational and educational purposes only. Use of the script does not constitute professional and/or financial advice. You alone have the sole responsibility of evaluating the script output and risks associated with the use of the script. In exchange for using the script, you agree not to hold dgtrd PulseWire user liable for any possible claim for damages arising from any decision you make based on use of the script
Indicator
Indicator
Optimized Linear Regression ChannelReturn a linear regression channel with a window size within the range (min, max) such that the R-squared is maximized, this allows a better estimate of an underlying linear trend, a better detection of significant historical supports and resistance points, and avoid finding a good window size manually.
Settings
Min : Minimum window size value
Max : Maximum window size value
Mult : Multiplicative factor for the rmse, control the channel width.
Src : Source input of the indicator
Details
The indicator displays the specific window size that maximizes the R-squared at the bottom of the lower channel.
When optimizing we want to find parameters such that they maximize or minimize a certain function, here the r-squared. The R-squared is given by 1 minus the ratio between the sum of squares (SSE) of the linear regression and the sum of squares of the mean. We know that the mean will always produce an SSE greater or equal to the one of the linear regression, so the R-squared will always be in a (0,1) range. In the case our data has a linear trend, the linear regression will have a better fit, thus having a lower SSE than the SSE of the mean, has such the ratio between the linear regression SSE and the mean SSE will be low, 1 minus this ratio will return a greater result. A lower R-squared will tell you that your linear regression produces a fit similar to the one produced by the mean. The R-squared is also given by the square of the correlation coefficient between the dependent and independent variables.
In pinescript optimization can be done by running a function inside a loop, we run the function for each setting and keep the one that produces the maximum or minimum result, however, it is not possible to do that with most built-in functions, including the function of interest, correlation , as such we must recreate a rolling correlation function that can be used inside loops, such functions are generally loops-free, this means that they are not computed using a loop in the first place, fortunately, the rolling correlation function is simply based on moving averages and standard deviations, both can be computed without using a loop by using cumulative sums, this is what is done in the code.
Note that because the R-squared is based on the SSE of the linear regression, maximizing the R-squared also minimizes the linear regression SSE, another thing that is minimized is the horizontality of the fit.
In the example above we have a total window size of 27, the script will try to find the setting that maximizes the R-squared, we must avoid every data points before the volatile bearish candle, using any of these data points will produce a poor fit, we see that the script avoid it, thus running as expected. Another interesting thing is that the best R-squared is not always associated to the lowest window size.
Note that optimization does not fix core problems in a model, with the linear regression we assume that our data set posses a linear trend, if it's not the case, then no matter how many settings you use you will still have a model that is not adapted to your data. Indicator
Momentum adjusted Moving Average by DGTA brand new Moving Average , calculated using Momentum, Acceleration and Probability (Psychological Effect).
Momentum adjusted Moving Average(MaMA) is an indicator that measures Price Action by taking into consideration not only Price movements but also its Momentum, Acceleration and Probability. MaMA, provides faster responses comparing to the regular Moving Average
Here is the math of the MaMA idea
Momentum measures change in price over a specified time period
momentum = source – source(length)
where,
source, indicates current bar’s price value
source(length), indicates historical price value of length bars earlier
Lets play with this formula and rewrite it by moving source(length) to other side of the equation
source = source(length) + momentum
to avoid confusion let’s call the source that we aim to predict as adjustedSource
adjustedSource = source(length) + momentum
looks nice the next value of source simply can be calculated by summing of historical value of the source value and value of the momentum. I wish it was so easy, the formula holds true only when the momentum is conserved/constant/steady but momentum move up or down with the price fluctuations (accelerating or decelerating)
Let’s add acceleration effects on our formula, where acceleration is change in momentum for a given length. Then the formula will become as (skipped proof part of acceleration effects, you may google for further details)
adjustedSource = source(length) + momentum + 1/2 * acceleration
here again the formula holds true when the acceleration is constant and once again it is not the case for trading, acceleration also changes with the price fluctuations
Then, how we can benefit from all of this, it has value yet requires additional approaches for better outcome
Let’s simulate behaviour with some predictive approach such as using probability (also known as psychological effect ), where probability is a measure for calculating the chances or the possibilities of the occurrence of a random event. As stated earlier above momentum and acceleration are changing with the price fluctuations, by using the probability approach we can add a predictive skill to determine the likelihood of momentum and acceleration changes (remember it is a predictive approach). With this approach, our equations can be expresses as follows
adjustedSource = source(length) + momentum * probability
adjustedSource = source(length) + ( momentum + 1/2 * acceleration ) * probability , with acceleration effect
Finally, we plot MaMA with the new predicted source adjustedSource, applying acceleration effect is made settable by the used from the dialog box, default value is true.
What to look for:
• Trend Identification
• Support and Resistance
• Price Crossovers
Recommended settings are applied as default settings, if you wish to change the length of the MaMA then you should also adjust length of Momentum (and/or Probability). For example for faster moving average such as 21 period it would be suggested to set momentum length to 13
Alternative usage , set moving average length to 1 and keep rest lengths with default values, it will produce a predictive price line based on momentum and probability. Experience acceleration factor by enabling and disabling it
Conclusion
MaMA provide an added level of confidence to a trading strategy and yet it is important to always be aware that it implements a predictive approach in a chaotic market use with caution just like with any indicator
Trading success is all about following your trading strategy and the indicators should fit within your trading strategy, and not to be traded upon solely
Disclaimer : The script is for informational and educational purposes only. Use of the script does not constitutes professional and/or financial advice. You alone the sole responsibility of evaluating the script output and risks associated with the use of the script. In exchange for using the script, you agree not to hold dgtrd PulseWire user liable for any possible claim for damages arising from any decision you make based on use of the script
Indicator
Momentum Acceleration by DGTItalian physicist Galileo Galilei is usually credited with being the first to measure speed by considering the distance covered and the time it takes. Galileo defined speed as the distance covered during a period of time. In equation form, that is v = Δd / Δt where v is speed, Δd is change in distance, and Δt is change in time. The Greek symbol for delta, a triangle (Δ), means change.
Is the speed getting faster or slower?
Acceleration will be the answer, acceleration is defined as the rate of change of speed over a set period of time, meaning something is getting faster or slower. Mathematically expressed, acceleration denoted as a is a = Δv / Δt , where Δv is the change in speed and Δt is the change in time.
How to apply in trading
Lets think about Momentum, Rate of Return, Rate of Change all are calculated in almost same approach with Speed
Momentum measures change in price over a specified time period,
Rate of Change measures percent change in price over a specified time period,
Rate of Return measures the net gain or loss over a specified time period,
And Speed measures change in distance over a specified time period
So we may state that measuring the change in distance is also measuring the change in price over a specified time period which is length, hence
speed can be calculated as (source – source )/length and acceleration becomes (speed – speed )/length
In this study acceleration is used as signal line and result plotted as arrows demonstrating bull or bear direction where direction changes can be considered as trading setups
Just a little fun, since we deal with speed the short name of the study is named after famous cartoon character Speedy Gonzales
Trading success is all about following your trading strategy and the indicators should fit within your trading strategy, and not to be traded upon solely
Disclaimer: The script is for informational and educational purposes only. Use of the script does not constitutes professional and/or financial advice. You alone the sole responsibility of evaluating the script output and risks associated with the use of the script. In exchange for using the script, you agree not to hold dgtrd PulseWire user liable for any possible claim for damages arising from any decision you make based on use of the script
Indicator
Elliott Wave Oscillator Signals by DGTElliott Wave Principle , developed by Ralph Nelson Elliott, proposes that the seemingly chaotic behaviour of the different financial markets isn’t actually chaotic. In fact the markets moves in predictable, repetitive cycles or waves and can be measured and forecast using Fibonacci numbers. These waves are a result of influence on investors from outside sources primarily the current psychology of the masses at that given time. Elliott wave predicts that the prices of the a traded currency pair will evolve in waves: five impulsive waves and three corrective waves. Impulsive waves give the main direction of the market expansion and the corrective waves are in the opposite direction (corrective wave occurrences and combination corrective wave occurrences are much higher comparing to impulsive waves)
The Elliott Wave Oscillator (EWO) helps identifying where you are in the 5-3 Elliott Waves, mainly the highest/lowest values of the oscillator might indicate a potential bullish/bearish Wave 3. Mathematically expressed, EWO is the difference between a 5-period and 35-period moving average based on the close. In this study instead 35-period, Fibonacci number 34 is implemented for the slow moving average and formula becomes ewo = ema(source, 5) - ema(source, 34)
The application of the Elliott Wave theory in real time trading gets difficult because the charts look messy. This study (EWO-S) simplifies the visualization of EWO and plots labels on probable reversals/corrections. The good part is that all plotting’s are performed on the top of the price chart including a histogram (optional and supported on higher timeframes). Additionally optional Keltner Channels Cloud added to help confirming the price actions.
What to look for:
Plotted labels can be used to follow the Elliott Wave occurrences and most importantly they can be considered as signals for possible trade setup opportunities. Elliott Wave Rules and Fibonacci Retracement/Extensions are suggested to confirm the patters provided by the EWO-S
Trading success is all about following your trading strategy and the indicators should fit within your trading strategy, and not to be traded upon solely
Disclaimer : The script is for informational and educational purposes only. Use of the script does not constitutes professional and/or financial advice. You alone the sole responsibility of evaluating the script output and risks associated with the use of the script. In exchange for using the script, you agree not to hold dgtrd PulseWire user liable for any possible claim for damages arising from any decision you make based on use of the script
Indicator
Script Stopwatch - PineCoders FAQ█ WARNING
The publication of our LibraryStopwatch has deprecated this publication.
█ ORIGINAL DESCRIPTION
This script calculates the run time of a Pine script. While its numbers are not very precise and it doesn’t work on all scripts, it will help developers calculate run times more precisely than by hand, and so provides Pine coders with an additional profiling tool to help them optimize their code.
How to use the code
• Place the code included between the up/down arrows after your script’s input() calls.
• Comment out the display modes you don’t want to use.
• Save your script, wait and look at the results.
• Results show in different colors, depending on the average time per bar:
- green for < 5 ms
- dark red for < 50 ms
- bright red for > 50 ms (the maximum allowed is 200).
How the code works
The code in this script starts by saving the value of the timenow variable on the first bar. While the time variable returns the time at the beginning of the bar, timenow returns the current time. The code then follows the progression of timenow during the script’s execution. The variable only updates every second, so in between updates the script makes an estimate of the total time elapsed by adding the last average time per bar calculated to each bar that passes until timenow increases by another 1000 because one more second has elapsed since its last update. At that point a new, current average time per bar is calculated and the cycle repeats.
The code only calculates elapsed time for the initial run. Once the realtime bar is hit, timing stops so that time spent in the realtime bar does not affect the numbers once they have been calculated on the script’s initial pass over the dataset.
Notes
• If results show zero elapsed time, it’s most probably because your script executes in less than one second, which is very good. In that case timenow hasn’t changed, so no timing can be calculated.
• The code is quirky and doesn’t work on all scripts.
• It doesn’t properly time execution of security() calls.
• The average time per bar will sometimes vary quite a bit with changes in chart resolution.
Look first. Then leap.
Indicator
