The Math Behind Dipsern: Drawdown Segmentation Explained

What Dipsern Actually Computes

Most "buy the dip" tools either show you a chart and let you eyeball it, or they spit out a black-box signal with no transparency. Dipsern sits in the middle: every number we display is computable from public data with a single page of math.

Here's the entire pipeline.

Step 1: Drawdown From All-Time High

For a price series P(t), drawdown is:

running_max(t) = max(P(0), P(1), ..., P(t))
drawdown(t)    = (P(t) - running_max(t)) / running_max(t)

Drawdown is bounded mathematically to [-1.0, 0.0]. It can never be positive (you're always either at or below your all-time high) and can never go below -100% (you can't lose more than 100%). This bounded range is what makes the next step work.

For AAPL on a given trading day, this might give you drawdown = -0.084 (down 8.4% from ATH). For BTC during the 2022 bear market, it would have read around -0.75.

Step 2: Equal-Width Segmentation

Take the fixed range [-1.0, 0.0] and divide it into N equal-width buckets. Dipsern uses N=20 by default, so each bucket is 5% wide:

Bucket 0:  [-1.00, -0.95]   (catastrophic crashes)
Bucket 1:  [-0.95, -0.90]
...
Bucket 18: [-0.10, -0.05]
Bucket 19: [-0.05,  0.00]   (at or near ATH)

The key design choice: fixed boundaries. We do NOT compute segment edges from each asset's historical drawdown range, because that would mean adding new data could shift the buckets and change the assignment of historical observations. Fixed boundaries mean every observation's bucket assignment is immutable once it's recorded.

Step 3: Forward 90-Day Return

For each historical observation at time t, we compute the realized forward return over the next 90 calendar days:

forward_return(t) = (P(t + 90 days) - P(t)) / P(t)

This uses calendar days, not trading days, because mean-reversion clocks tick over weekends. The engine builds a forward map via a two-pointer O(n) algorithm so that t+90 always lands on the first trading day at or after the target date.

The last 90 calendar days of the series have no forward return (the future hasn't happened yet). They're set to NaN and excluded from training but still get a forecast at inference time.

Step 4: Per-Segment Aggregation

For each of the 20 buckets, we collect every historical forward_return(t) where drawdown(t) fell into that bucket. Then we compute two summary statistics per bucket:

1. Rolling median of forward returns
2. Rolling EMA of forward returns (with decay = 0.95)

The rolling median is our primary signal. The EMA is kept as a secondary reference in the segments table.

Why Median Beat EMA

When we built v1 of Dipsern, we used the EMA as the primary forecast. It made sense — recent observations weighted more heavily, regime-aware, smooth signal.

Then we ran the prediction-error analysis. For every historical forecast, we computed |actual_forward_return - predicted_forward_return| and aggregated by asset class.

The result: median forecasts had lower error than EMA forecasts in 14 of 17 asset categories. The places EMA won were small thematic ETFs with sharp regime changes (ARKK, cannabis ETFs). Everywhere else, the EMA's responsiveness to recent data was a bug, not a feature — it overweighted recent noise relative to the long-run base rate.

So we made the median primary. EMA still appears in the segments table for users who want to see both, but the headline KPI is the median, and the prediction error you see in the app is computed against the median forecast.

Step 5: No Look-Ahead Bias

This is the part most retail "backtests" get wrong. Many tools accidentally use future information to make past forecasts look better.

Dipsern's engine enforces a strict reveal-at-target convention. At time t, the segment medians and EMAs are updated only with forward returns that have actually been revealed by time t. A 90-day forward return computed at time t-90 is the latest information available; anything more recent than that is in the future and excluded.

This is enforced by a test (test_no_lookahead_bias) that asserts the first 90 EMA values are exactly 0.0 (no data yet). If that test fails, the engine has a correctness bug, and the daily pipeline blocks deployment.

Step 6: Current-Segment Lookup

To produce a forecast for "right now," the engine:

1. Computes today's drawdown from ATH
2. Looks up the bucket (one of the 20 fixed-width segments)
3. Returns the current rolling median for that bucket as the predicted forward 90-day return
4. Returns the mean prediction error across all historical forecasts in that bucket
5. Returns the win rate (fraction of historical observations in that bucket where the forward return was positive)

These three numbers — median return, prediction error, win rate — are the core Dipsern signal. Everything else in the app (charts, scatter plots, historical paths) is decoration.

What Dipsern Is Not

Dipsern is a base-rate engine. It tells you: at this exact drawdown level for this exact asset, this is what historically happened in the next 90 days. It does not tell you:

• Whether the current setup matches the historical analog (you have to decide that)
• Whether the asset's fundamentals have changed (story, not statistics)
• Whether to actually buy (we don't execute trades)

What it does is replace vibes with conditional base rates. That's the whole product.

Try It Yourself

Pick any of the 2,200+ assets in the signals list. Each page shows the current drawdown, the bucket assignment, and (gated behind a free signup) the median forward return, win rate, and prediction error for that bucket. Free tier gets you 5 full analyses per month.

For the more methodologically curious, the full engine source is in api/arad_engine.py in the repo — pure NumPy, no dependencies beyond pandas, ~600 lines.