Adriano Dal Pastro
95f7fb30a3
L'operatore ha contestato un numero che avevo citato io ("anno migliore +184%"). Aveva
ragione, e l'errore era di METODO, non di calcolo.
IL NUMERO E' VERO. Tracciato l'anno estremo: 18 blocchi da 20 giorni, nessuno
significativamente negativo (+20% +15% +12% +10% +8% ... -1%). La popolazione lo consente:
blocchi 20g reali con mediana -0.1%, p95 +8.5%, max +22.4%, skew +2.15 — firma classica di
un trend-follower. E la materia prima esiste: la miglior finestra 365g REALE e' +89.8%.
MA CITARLO ERA SBAGLIATO, perche' il massimo di N estrazioni cresce con N:
su 1.000 anni simulati -> max +96.0%
su 5.000 -> max +135.2%
su 114.000 -> max +184.3%
Il numero che avevo dato parlava del mio N_PATHS, non del book. Con 1.000 percorsi avrei
scritto +96% per la stessa identica strategia.
I NUMERI CORRETTI SONO I PERCENTILI: p1 -11.9% · p5 -5.5% · MEDIANA +16.0% · p95 +51.2% ·
p99 +71.8%. Vale simmetricamente per il "peggiore -27.4%", anch'esso minimo campionario (a
1.000 percorsi era -19.1%): la coda sinistra onesta e' p1 = -11.9%.
CABLATO: r0726_decadimento.py aveva lo stesso difetto ("drawdown PEGGIORE 44.2%") -> ora
stampa p99 = 26.0% e dichiara che il 44.2% e' un massimo campionario da non citare come
"il caso peggiore".
REGOLA: il massimo (o il minimo) di una simulazione e' una statistica del NUMERO DI
SIMULAZIONI, non della strategia. Si citano i percentili. Stessa famiglia dell'errore gia'
codificato oggi ("un percentile stampato a 0 decimali mente esattamente agli estremi"):
gli estremi sono dove i numeri sembrano piu' informativi e lo sono meno.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
422 lines
20 KiB
Markdown
422 lines
20 KiB
Markdown
# 2026-07-26 — I versamenti: le quattro ipotesi che il piano non aveva mai fatto
|
||
|
||
**Richiesta:** *"allora concentriamoci sui versamenti"* — dopo la rivalutazione che ha misurato il
|
||
book dentro il suo plateau (ottimizzare il peso = +0.030 Sharpe, gate fallito) mentre i versamenti
|
||
valgono la differenza fra **mai** e **16 anni**.
|
||
|
||
**Script:** `r0726_deposits.py`. **Test:** `tests/test_deposits.py` (12).
|
||
**Book, pesi, cron, config: INVARIATI.** (Questo filone non tocca il codice di produzione.)
|
||
|
||
---
|
||
|
||
## 0. Cosa mancava
|
||
|
||
Tutte le traiettorie calcolate finora (25/07 e 26/07) assumono la stessa cosa: **versamento
|
||
piatto, ininterrotto, per sempre**. E' l'ipotesi meno realistica dell'intero piano. Qui si misurano
|
||
le deviazioni che succedono davvero, con la stessa macchineria (block bootstrap sui ritorni reali
|
||
del book live, fattore d'ancora ×0.89 **misurato**).
|
||
|
||
## 1. Smettere di versare — il costo non e' proporzionale ai soldi mancanti
|
||
|
||
€250/mese per K anni, poi stop, orizzonte 20 anni:
|
||
|
||
```
|
||
versi per totale versato cap. mediano a 20a P(muro entro 20a) rendita mediana
|
||
3a $10,410 $202,771 32.7% 37.27 €/g
|
||
5a $16,950 $287,081 53.3% 52.76 €/g
|
||
10a $33,572 $410,220 77.9% 75.39 €/g
|
||
20a $66,818 $496,778 90.0% 91.30 €/g
|
||
```
|
||
|
||
**I primi 5 anni sono il 25% dei soldi e il 58% del risultato.** Chi versa 5 anni e poi smette
|
||
arriva comunque alla rendita bersaglio nel 53% dei casi; chi versa gli ultimi 10 anni (piu' soldi)
|
||
arriva nell'11% (§3). **La variabile non e' quanto versi: e' quanto presto.**
|
||
|
||
Corollario pratico: un'interruzione al 12° anno costa poco; una al 3° costa quasi tutto. Se il
|
||
piano deve rompersi, e' meglio che si rompa tardi — il che e' un argomento per **partire con un
|
||
importo sostenibile** invece che con uno ambizioso.
|
||
|
||
## 2. Un piano crescente e' peggiore di uno piatto, a pari soldi
|
||
|
||
```
|
||
piano totale versato cap. mediano P(muro) $ finale / $ versato
|
||
piatto €250 $66,818 $496,778 90.0% 7.43x
|
||
€150 +5%/anno $67,998 $401,889 80.8% 5.91x
|
||
```
|
||
|
||
**Stessi soldi (€67-68k), 24% di risultato in meno.** Il piano crescente versa gli stessi euro
|
||
piu' **tardi**, e quegli euro compongono meno. L'ultima colonna e' la metrica giusta per
|
||
confrontare piani di taglia diversa: quanto capitale finale compra ogni dollaro versato — e i
|
||
piani crescenti stanno tutti a 5.1-5.9x contro 7.4x dei piatti.
|
||
|
||
E' contro-intuitivo perche' "i versamenti crescono col reddito" suona prudente. Lo e' dal punto di
|
||
vista del bilancio familiare; **non** lo e' dal punto di vista del capitale.
|
||
|
||
## 3. Stesso totale, calendario diverso — il tempo vale 2.2x
|
||
|
||
€60.000 in totale (= €250/mese per 20 anni), distribuiti diversamente:
|
||
|
||
```
|
||
calendario cap. mediano P(muro) vs piatto
|
||
piatto su 20 anni $496,778 90.0% 1.00x
|
||
tutto nei primi 10 anni $806,285 98.3% 1.62x
|
||
tutto nei primi 5 anni $1,104,587 99.4% 2.22x
|
||
solo negli ultimi 10 anni $178,494 11.0% 0.36x
|
||
```
|
||
|
||
**Gli stessi €60.000 valgono da $178k a $1.104k — un fattore 6 — a seconda di QUANDO entrano.**
|
||
|
||
⚠️ Questo **non** dice "versa tutto subito": dice quanto vale il tempo. Un piano che non si
|
||
sostiene non e' un piano, e il confronto serve a scegliere fra calendari **sostenibili**.
|
||
|
||
### E regge al rischio di venue?
|
||
|
||
Il vantaggio del front-loading e' calcolato mettendo **piu' capitale sull'exchange prima** — cioe'
|
||
proprio il rischio misurato stamattina. Andava verificato, non assunto:
|
||
|
||
```
|
||
calendario p=0.5% p=2.0% p=5.0%
|
||
piatto su 20 anni $463,413 $359,251 $0
|
||
tutto nei primi 10 anni $765,178 $555,904 $0
|
||
tutto nei primi 5 anni $1,015,491 $752,367 $0
|
||
solo negli ultimi 10 anni $172,228 $147,203 $0
|
||
```
|
||
|
||
Il vantaggio **regge** (2.22x → 2.09x a p=2%): il rischio di venue colpisce il **tempo**, non il
|
||
calendario dei versamenti. Anticipare non aumenta la probabilita' di essere colpiti, aumenta solo
|
||
quanto c'e' dentro quando succede — e nel frattempo ha composto di piu'.
|
||
|
||
⚠️ **Ma guardare la colonna p=5%: il capitale mediano e' $0 per OGNI calendario.** A quel tasso di
|
||
rischio la meta' dei percorsi finisce a zero (64% di rovina su 20 anni, come misurato stamattina) e
|
||
**come versi diventa irrilevante**. E' la formulazione piu' netta del rischio di venue trovata
|
||
finora: non erode il piano, lo **cancella**.
|
||
|
||
## 4. La domanda inversa — che rendita compra quello che posso permettermi
|
||
|
||
Rendita **netta** mediana in €/giorno:
|
||
|
||
```
|
||
€/mese 5a 10a 15a 20a P(€50/g a 20a)
|
||
100 2.08€ 6.54€ 16.40€ 38.07€ 31.0%
|
||
150 3.00€ 9.55€ 23.96€ 55.80€ 58.7%
|
||
250 4.83€ 15.53€ 39.11€ 91.30€ 90.0%
|
||
400 7.59€ 24.52€ 61.85€ 144.23€ 98.9%
|
||
600 11.26€ 36.52€ 92.17€ 215.07€ 100.0%
|
||
```
|
||
|
||
E' la tabella che **riformula l'obiettivo**. €50/g e' un punto su questa griglia, non l'unico
|
||
risultato che conta: €150/mese porta a ~€24/g in 15 anni, che non e' un fallimento del piano da
|
||
€50 — e' un risultato diverso, e ora si sa quanto costa il salto.
|
||
|
||
Da notare la **non-linearita' temporale**: da 15 a 20 anni la rendita piu' che raddoppia a ogni
|
||
livello. Gli ultimi anni del piano contano piu' dei primi *in rendita*, esattamente come i primi
|
||
contano piu' degli ultimi *in versamenti*.
|
||
|
||
## 5. Ogni quanto versare — la decisione meno importante
|
||
|
||
```
|
||
costo/tras. mensile bimestrale trimestrale semestrale
|
||
$0.00 *$490,149 $486,725 $482,587 $473,908
|
||
$2.00 *$486,597 $484,964 $481,446 $473,342
|
||
$5.00 $481,270 *$482,323 $479,727 $472,495
|
||
$25.00 $445,984 $464,692 *$468,226 $466,817
|
||
```
|
||
|
||
**Mensile fino a ~$2 di costo per trasferimento, bimestrale sopra.** Ma le differenze sono
|
||
**1-3%** del capitale finale: e' la meno importante delle cinque decisioni di questo diario, e non
|
||
merita ottimizzazione oltre la regola in una riga.
|
||
|
||
Verificato che un deposito **non resta strozzato**: col cap dinamico attivo (`_cap`), cap =
|
||
equity/2 = esattamente il nozionale massimo che il book puo' chiedere per asset.
|
||
|
||
## 6. Le cinque decisioni, in ordine di quanto pesano
|
||
|
||
| decisione | effetto misurato |
|
||
|---|---|
|
||
| **versare o no** | da **mai** a 16 anni |
|
||
| **quando** (front vs back, stesso totale) | **6x** sul capitale finale |
|
||
| **quanto presto smettere** | 5 anni = 25% dei soldi, 58% del risultato |
|
||
| piatto vs crescente | 24% a pari soldi |
|
||
| frequenza | 1-3% |
|
||
|
||
E sopra tutte, fuori scala: **a p=5% di rischio venue il risultato mediano e' zero comunque.**
|
||
|
||
## 7. Regole trasferibili
|
||
|
||
1. **Un piano di accumulo si giudica sulle sue deviazioni, non sul caso nominale.** Piatto,
|
||
ininterrotto e per sempre e' l'unico scenario che non succede.
|
||
2. **Confrontare piani di taglia diversa richiede una metrica normalizzata** (`$ finale / $
|
||
versato`), altrimenti "versa di piu'" vince sempre e non si impara niente.
|
||
3. **Un vantaggio calcolato ignorando un rischio noto va ri-misurato con quel rischio dentro**,
|
||
anche quando ci si aspetta che regga — qui reggeva, ma la colonna p=5% ha prodotto il risultato
|
||
piu' importante del filone.
|
||
4. **Quando l'obiettivo dichiarato non e' raggiungibile, la tabella utile e' quella inversa**:
|
||
non "quando arrivo a X" ma "cosa compro con quello che ho".
|
||
|
||
---
|
||
|
||
# Addendum — il piano dichiarato: €5.000 subito + €500/mese
|
||
|
||
L'operatore ha dato i numeri veri. Cambiano la scala: €5.000 portano il conto da **$597 a $6.047
|
||
(10.1x)** e €500/mese e' il doppio del livello tabulato sopra. Ricalcolato in dedicata
|
||
(`r0726_piano_5k500.py`), non estrapolato.
|
||
|
||
## Quando
|
||
|
||
```
|
||
traguardo ($272.061): p10 9.4a MEDIANA 11.6a p90 14.4a
|
||
P(entro 10a) 18% P(entro 12a) 57% P(entro 15a) 94% P(entro 20a) 100%
|
||
```
|
||
|
||
```
|
||
anno capitale p10 MEDIANO p90 rendita mediana
|
||
1$ 12,408$ 14,057$ 16,405 2.58 €/g
|
||
3$ 28,401$ 34,674$ 44,000 6.37 €/g
|
||
5$ 48,306$ 62,952$ 86,121 11.57 €/g
|
||
10$ 130,089$ 191,398$ 299,555 35.18 €/g
|
||
15$ 288,993$ 476,825$ 847,266 87.63 €/g
|
||
```
|
||
|
||
✅ **Validazione incrociata:** la variante "solo €500/mese da $600" da' **12.4 anni**, che e'
|
||
*esattamente* il numero pubblicato il 25/07 con macchineria diversa. Replica indipendente.
|
||
|
||
## Quanto vale il versamento iniziale: 0.8 anni
|
||
|
||
```
|
||
€5.000 subito (il piano) 11.6a
|
||
€5.000 spalmati sul 1° anno 11.7a
|
||
€5.000 al 5° anno 12.1a
|
||
niente lump, solo €500/mese 12.4a
|
||
```
|
||
|
||
⚠️ **Meno di quanto suggerisse il "fattore 6" del §3**, e la ragione e' aritmetica: €5.000 sono
|
||
**~10 mesi** di versamenti a €500, quindi comprano ~10 mesi. Il fattore 6 riguardava lo spostamento
|
||
di €60.000 su vent'anni. **Anticipare vale in proporzione a quanto si anticipa** — ovvio a
|
||
posteriori, ma la mia aspettativa era piu' alta e va corretta.
|
||
|
||
## Le soglie, e la data che compare
|
||
|
||
```
|
||
$ 3,000 GIA' SUPERATA il giorno 1 GTAA01 eseguibile
|
||
$ 5,000 GIA' SUPERATA il giorno 1 XSR01 eseguibile (gate pre-registrato 23/10)
|
||
$ 13,000 ~0.9 anni GTAA01 entra nel book deployable
|
||
$ 20,000 ~1.6 anni SOGLIA DELLA DECISIONE VENUE
|
||
$117,000 ~7.6 anni XS01 eseguibile
|
||
```
|
||
|
||
**La decisione "niente split fino a $20k" smette di essere un'ipotesi e diventa una data: ~19
|
||
mesi.** E le soglie $3k/$5k sono superate il primo giorno — il che NON autorizza ad anticipare il
|
||
gate XSR01 del 23/10 (anticiparlo e' selezione sull'hold-out), ma rende viva la sua domanda di
|
||
eseguibilita'.
|
||
|
||
## Con il rischio di venue dentro
|
||
|
||
```
|
||
p annua P(traguardo) P(perso TUTTO) cap. mediano 25a
|
||
0.0% 100.0% 0.0% $2,540,508
|
||
0.5% 94.3% 11.7% $2,304,596
|
||
1.0% 88.0% 23.2% $2,018,727
|
||
2.0% 78.8% 39.6% $1,464,013
|
||
5.0% 55.4% 72.0% $0
|
||
```
|
||
|
||
Il piano regge bene fino a p=2%. A p=5% il capitale mediano e' **zero**: e' la stessa conclusione
|
||
del §3, e vale a maggior ragione ora che il capitale in gioco e' 10x.
|
||
|
||
## ⚠️ AZIONE OPERATIVA PRIMA DEL VERSAMENTO — il cap fisso diventa una strozzatura
|
||
|
||
`src/live/book._cap` usa il cap **dinamico** (equity/2) solo quando l'equity reale e' leggibile;
|
||
altrimenti ripiega su `max_notional_per_asset_usd = $300`. **A $597 il fallback era INERTE**
|
||
(equity/2 = $298 ≈ $300). **Dopo il versamento l'equity/2 vale ~$3.023**, quindi un fallback
|
||
strozzerebbe il book a **~10% del target** — silenziosamente, con la sola allerta `eq_fallback`.
|
||
|
||
E' esattamente l'azione **gia' pre-registrata il 2026-07-02** (*"al deposito alzare il cap a
|
||
equity/2"*). Cablato `test_il_cap_fisso_diventa_una_strozzatura_dopo_un_deposito`: **fallisce** se
|
||
si deposita senza adeguare `max_notional_per_asset_usd`.
|
||
|
||
**Non eseguita**: e' un cambio di config su soldi veri, decisione dell'operatore.
|
||
|
||
---
|
||
|
||
## Il cap: alzato a $3.000, ma il modo conta piu' del numero
|
||
|
||
L'operatore ha autorizzato *"si alza il cap a 3000"*. Verificato prima di eseguire: **il deposito
|
||
non era ancora arrivato** (equity reale letta dal conto: $596.92). Alzare il cap in quel momento
|
||
sarebbe stato **pericoloso nel verso opposto**.
|
||
|
||
### Perche' alzarlo prima del deposito e' pericoloso
|
||
|
||
Quando l'equity reale non e' leggibile, `shadow_report` ripiega su `paper_cap` = **$2.000
|
||
nominali**, che non e' il conto vero. Il sizing diventa `0.5 × 2000 × (...)` = fino a $1.000/asset,
|
||
e **il cap fisso e' l'unica cosa che impedisce a quel nominale di diventare leva reale**:
|
||
|
||
| cap fisso | fallback su conto da $597 | leva reale |
|
||
|---|---|---|
|
||
| $300 (prima) | $300/asset = $600 lordi | **1.00x** ✅ |
|
||
| $3.000 (alzato a mano) | $1.000/asset = $2.000 lordi | **3.35x** ❌ |
|
||
|
||
Cioe' il cap sarebbe stato troppo alto **proprio nel momento in cui non si sa quanto c'e' sul
|
||
conto** — e con `disaster_sl_pct` −30% quella e' la configurazione peggiore possibile.
|
||
|
||
### La correzione: il fallback segue l'ultima equity osservata
|
||
|
||
Invece di alzare un numero da ricordare, il cap di fallback e' stato **legato al conto**:
|
||
|
||
```python
|
||
cap_fallback = min(cap_fisso_di_config, ultima_equity_reale_osservata * frac)
|
||
```
|
||
|
||
con un watermark in `data/live/equity_seen.json`, scritto da `book_report` ogni volta che l'equity
|
||
reale e' leggibile. Il cap di config torna a essere quello che dovrebbe: un **tetto dichiarato**.
|
||
|
||
Verificato sul conto vero, nei due regimi:
|
||
|
||
```
|
||
oggi, watermark $596.92 -> $298.46/asset = leva 1.00x
|
||
dopo il versamento, $6.047 -> $3,000.00/asset = leva 0.99x
|
||
```
|
||
|
||
**Sicuro in entrambi gli ordini di eventi**, e senza dipendere da un'azione manuale al momento del
|
||
deposito. Senza watermark (primo avvio, file cancellato) si usa `CAP_UNKNOWN_USD` = $300: non si sa
|
||
niente del conto, si usa la taglia storicamente sicura.
|
||
|
||
Questo **chiude l'azione pre-registrata il 2026-07-02** (*"al deposito alzare il cap a equity/2"*),
|
||
rimasta ineseguita per 24 giorni — non eseguendola, ma **rendendola non necessaria**.
|
||
|
||
Guardie: `tests/test_cap_watermark.py` (11), **a due lati** — il cap non puo' ne' superare il conto
|
||
reale (leva nascosta) ne' restare sotto dopo un deposito (strozzatura).
|
||
|
||
### Regola trasferibile
|
||
|
||
**Un parametro di sicurezza che va aggiornato a mano a ogni cambio di scala e' un difetto, non una
|
||
configurazione.** Qui lo stesso numero era sbagliato in un verso prima del deposito e nell'altro
|
||
dopo: la soluzione non era scegliere il valore giusto, era **legarlo alla grandezza che lo
|
||
determina**. Il segnale che serviva questa correzione era gia' visibile: l'azione manuale era stata
|
||
pre-registrata 24 giorni prima e non era mai stata eseguita.
|
||
|
||
---
|
||
|
||
# Addendum 2 — "dai per scontato che non perdiamo mai con i trade?"
|
||
|
||
Obiezione dell'operatore. Si divide in due parti che hanno risposte **opposte**:
|
||
la prima e' infondata, la seconda coglie l'ipotesi piu' fragile di tutto il piano.
|
||
Script `r0726_decadimento.py`.
|
||
|
||
## Parte 1 — no: le perdite sono nel modello
|
||
|
||
Il block bootstrap ricampiona i ritorni **reali** del book a blocchi di 20 giorni, quindi conserva
|
||
autocorrelazione e forma dei drawdown.
|
||
|
||
```
|
||
serie reale (2.692 giorni): in perdita 35.6% · flat 27.5% · in guadagno 36.9%
|
||
giorno peggiore -3.94% · peggior mese -5.76%
|
||
5.000 percorsi simulati (20a): maxDD mediano 14.4% · p90 19.8% · PEGGIORE 44.2%
|
||
anni-calendario in perdita 5.8% (su 95.000 anni)
|
||
```
|
||
|
||
⚠️ **Errore mio catturato scrivendo questo**: la prima stesura riportava **63.9%** di giorni in
|
||
perdita. Artefatto: il de-luck sottrae una costante a *ogni* giorno (e' cosi' che riduce il drift
|
||
lasciando la vol invariata, come prescrive la misura d'ancora), quindi **trasforma il 27.5% di
|
||
giorni flat in piccoli negativi**. Corretto per il drift, fuorviante per la forma.
|
||
**REGOLA: una correzione uniforme sul drift e' giusta per le domande sul drift e sbagliata per le
|
||
domande sulla distribuzione** — la stessa serie dice 36% o 64% di giorni in perdita a seconda di
|
||
quale delle due si guarda, senza che sia cambiato niente.
|
||
|
||
## Parte 2 — si', ma l'assunzione e' un'altra: che l'edge continui a esistere
|
||
|
||
Il bootstrap assume che **il futuro sia il passato rimescolato**. Nessuna parte del progetto misura
|
||
il decadimento dell'alpha. Quanto costa se e' falso (piano €5.000 + €500/mese):
|
||
|
||
```
|
||
scenario mediana traguardo P(entro 20a) cap. mediano 20a
|
||
edge intatto (cio' che ho mostrato finora) 11.6a 99.9% $1,115,643
|
||
edge DIMEZZATO da subito 15.8a 76.6% $342,224
|
||
edge che decade a zero in 20 anni 14.3a 65.5% $269,970
|
||
edge che decade a zero in 10 anni oltre 20a 18.4% $157,856
|
||
edge MORTO dall'anno 10 (rende 0) oltre 20a 42.0% $259,553
|
||
edge MORTO dall'anno 5 oltre 20a 0.0% $163,377
|
||
```
|
||
|
||
**Il piano NON e' fragile a un dimezzamento dell'edge** (11.6 → 15.8 anni, P ancora 77%). **Lo e'
|
||
alla morte dell'edge.** E la differenza fra i due casi non e' distinguibile in anticipo — e' la
|
||
ragione per cui il progetto ha gate pre-registrati con date e soglie invece di aspettarsi che le
|
||
cose continuino a funzionare.
|
||
|
||
## Il limite strutturale del metodo
|
||
|
||
```
|
||
Peggior BIENNIO dell'intero campione: +3.0%
|
||
Se tutti i 20 anni fossero fatti cosi': P(traguardo) 2.9%, capitale mediano $149.014
|
||
(a fronte di $136.847 versati)
|
||
```
|
||
|
||
**Il peggior biennio della storia del book e' POSITIVO.** Sette anni di storia crypto contengono
|
||
due mercati toro: un decennio davvero brutto **non e' mai successo**, quindi il bootstrap non lo
|
||
puo' estrarre. Non e' un parametro da alzare, e' il limite del ricampionamento: **non si puo'
|
||
simulare un regime peggiore di qualunque cosa ci sia nel campione.**
|
||
|
||
Se i prossimi 20 anni somigliassero al peggior biennio gia' visto, il capitale finirebbe **appena
|
||
sopra i soldi versati**: il piano non fallirebbe, semplicemente non renderebbe.
|
||
|
||
## Cosa se ne fa
|
||
|
||
Nessun cambio a book, pesi o piano. Cambia **cosa si sorveglia**: la domanda "l'edge c'e' ancora?"
|
||
non ha una risposta nel backtest, ce l'ha solo nel forward — che e' esattamente cio' che i monitor
|
||
paper e i gate pre-registrati esistono per misurare.
|
||
|
||
---
|
||
|
||
## Addendum 3 — "+184% sembra alto, da dove arriva?"
|
||
|
||
Obiezione dell'operatore su un numero che avevo citato io. **Aveva ragione, e l'errore era di
|
||
metodo, non di calcolo.**
|
||
|
||
### Il numero e' vero
|
||
|
||
Non e' un bug. Tracciato l'anno estremo: e' composto da 18 blocchi da 20 giorni, e **nessuno di
|
||
essi e' negativo in modo significativo**:
|
||
|
||
```
|
||
+20% +15% +12% +10% +8% +8% +8% +7% +6% +6% +5% +5% +2% +1% +0% -0% -0% -1%
|
||
```
|
||
|
||
La popolazione da cui pesca lo consente: blocchi 20g reali con mediana **−0.1%**, p95 **+8.5%**,
|
||
max **+22.4%**, **skew +2.15** — la firma classica di un trend-follower (molte perdite piccole,
|
||
poche vincite grandi). E la materia prima esiste davvero: **la miglior finestra 365g della storia
|
||
reale e' +89.8%** (il 2020 fece +58% come anno di calendario).
|
||
|
||
### Ma citarlo era sbagliato
|
||
|
||
```
|
||
su 1.000 anni simulati: max +96.0%
|
||
su 5.000 anni simulati: max +135.2%
|
||
su 20.000 anni simulati: max +135.2%
|
||
su 114.000 anni simulati: max +184.3%
|
||
```
|
||
|
||
**Il massimo di N estrazioni cresce con N: descrive la taglia della mia simulazione, non la
|
||
strategia.** Con 1.000 percorsi avrei scritto "+96%" e sarebbe stata la stessa strategia. Il numero
|
||
che avevo dato all'operatore parlava del mio `N_PATHS`, non del book.
|
||
|
||
I numeri corretti sono i **percentili**, che non dipendono dal campione:
|
||
|
||
| p0.1 | p1 | p5 | p50 | p95 | p99 | p99.9 |
|
||
|---|---|---|---|---|---|---|
|
||
| −17.6% | −11.9% | −5.5% | **+16.0%** | +51.2% | +71.8% | +99.9% |
|
||
|
||
Vale simmetricamente per il "peggiore": il **−27.4%** che avevo citato e' anch'esso un minimo
|
||
campionario (a 1.000 percorsi era −19.1%). Il numero onesto per la coda sinistra e' **p1 = −11.9%**.
|
||
|
||
### Cablato
|
||
|
||
Corretto anche `r0726_decadimento.py`, che riportava "drawdown PEGGIORE 44.2%" con lo stesso
|
||
difetto: ora stampa **p99 = 26.0%** e dichiara esplicitamente che il 44.2% e' un massimo
|
||
campionario da non citare come "il caso peggiore".
|
||
|
||
### Regola trasferibile
|
||
|
||
**Il massimo (o il minimo) di una simulazione non e' una statistica della strategia: e' una
|
||
statistica del numero di simulazioni.** Si citano i percentili. E' la stessa famiglia dell'errore
|
||
gia' codificato oggi ("un percentile stampato a 0 decimali mente esattamente agli estremi"): gli
|
||
estremi sono il posto dove i numeri sembrano piu' informativi e lo sono meno.
|