95424f0755a795dedba686a87d90d26ad84fbea6
5 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Adriano Dal Pastro
|
95f7fb30a3 |
fix: il massimo di una simulazione non e' una statistica della strategia
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>
|
||
|
Adriano Dal Pastro
|
1296fa2d96 |
research: "dai per scontato che non perdiamo mai?" — meta' infondata, meta' e' il punto piu' debole del piano
Obiezione dell'operatore, presa sul serio. Due parti con risposte opposte. PARTE 1 (infondata): le perdite SONO nel modello. Il block bootstrap ricampiona i ritorni reali a blocchi di 20 giorni e conserva la forma dei drawdown. Serie reale: 35.6% giorni in perdita, 27.5% flat, 36.9% in guadagno; giorno peggiore -3.94%, peggior mese -5.76%. Sui 5.000 percorsi: maxDD mediano 14.4%, p90 19.8%, PEGGIORE 44.2%; anni-calendario in perdita 5.8% su 95.000 anni simulati. ⚠️ ERRORE MIO CATTURATO PRIMA DI PUBBLICARE: la prima stesura diceva 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. REGOLA: una correzione uniforme sul drift e' giusta per le domande sul drift e sbagliata per quelle sulla distribuzione — la stessa serie dice 36% o 64% a seconda di quale si guarda, senza che sia cambiato niente. PARTE 2 (coglie il punto): l'assunzione ottimista c'e' ed e' che l'EDGE CONTINUI A ESISTERE per vent'anni. Il bootstrap assume che il futuro sia il passato rimescolato; nessuna parte del progetto misura il decadimento dell'alpha. Misurato ora: edge intatto -> 11.6a, P(20a) 99.9% edge dimezzato -> 15.8a, P 76.6% decade a zero in 20a -> 14.3a, P 65.5% decade a zero in 10a -> oltre 20a, P 18.4% morto dall'anno 10 -> oltre 20a, P 42.0% morto dall'anno 5 -> oltre 20a, P 0.0% Il piano NON e' fragile a un dimezzamento dell'edge, lo e' alla sua morte. E i due casi non sono distinguibili in anticipo: e' la ragione per cui esistono i gate pre-registrati. IL LIMITE STRUTTURALE: il peggior BIENNIO dell'intero campione e' +3.0%, cioe' POSITIVO. Sette anni di storia crypto contengono due tori: un decennio davvero brutto non e' mai successo, quindi il bootstrap non lo puo' estrarre. Se i 20 anni fossero tutti come quel biennio, P(traguardo) 2.9% e capitale finale $149.014 contro $136.847 versati — il piano non fallirebbe, semplicemente non renderebbe. Non e' un parametro da alzare: non si puo' simulare un regime peggiore di qualunque cosa ci sia nel campione. Book, pesi, piano INVARIATI. Cambia cosa si sorveglia. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Adriano Dal Pastro
|
b023cc2bdf |
fix(live): cap di fallback legato all'ultima equity osservata + cap config 300 -> 3000
L'operatore ha autorizzato "si alza il cap a 3000". Verificato PRIMA di eseguire: il
deposito non era ancora arrivato (equity reale $596.92), e alzare il cap in quel momento
sarebbe stato pericoloso NEL VERSO OPPOSTO.
IL PROBLEMA. 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 x 2000 x (...) = fino a
$1.000/asset, e il cap fisso e' l'unica cosa che impedisce a quel nominale di diventare
leva reale.
cap $300 -> fallback $600 lordi su $597 = 1.00x OK
cap $3000 -> fallback $2.000 lordi su $597 = 3.35x NO
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. Invece di alzare un numero da ricordare, il cap di fallback e' legato al
conto: cap_fallback = min(cap_fisso_di_config, ultima_equity_reale_osservata * frac), con
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 un TETTO DICHIARATO.
Senza watermark (primo avvio, file cancellato) -> CAP_UNKNOWN_USD = $300: non si sa niente
del conto, si usa la taglia storicamente sicura.
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, senza dipendere da un'azione manuale al deposito.
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.
REGOLA: un parametro di sicurezza che va aggiornato a mano a ogni cambio di scala e' un
difetto, non una configurazione. 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.
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).
Dry-run sul conto reale: cap/asset $298, book flat, nessun ordine. 391 test verdi (+11).
Strategia, pesi, cron INVARIATI. Cambia solo config/live.json e il calcolo del cap di
fallback.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Adriano Dal Pastro
|
1227b2baab |
research: il piano dichiarato EUR 5.000 + EUR 500/mese, e la strozzatura del cap
L'operatore ha dato i numeri veri: EUR 5.000 subito + EUR 500/mese. Cambia la scala (conto da $597 a $6.047 = 10.1x), quindi ricalcolato in dedicata invece che estrapolato. QUANDO: traguardo EUR 50/g ($272.061) a p10 9.4a / MEDIANA 11.6a / p90 14.4a; P(entro 15a) 94%, P(entro 20a) 100%. Rendita mediana: EUR 6.37/g a 3 anni, EUR 11.57/g a 5, EUR 35.18/g a 10, EUR 87.63/g a 15. VALIDAZIONE INCROCIATA: la variante "solo EUR 500/mese da $600" da' 12.4 anni = esattamente il numero pubblicato il 25/07 con macchineria diversa. IL LUMP VALE 0.8 ANNI (12.4 -> 11.6), MENO di quanto suggerisse il "fattore 6" del calendario, e la ragione e' aritmetica: EUR 5.000 sono ~10 mesi di versamenti a EUR 500, quindi comprano ~10 mesi. Anticipare vale in proporzione a quanto si anticipa. La mia aspettativa era piu' alta ed e' corretta. SOGLIE: $3k e $5k superate il giorno 1 (GTAA01 e XSR01 diventano eseguibili); $13k a ~0.9 anni (GTAA01 entra nel book deployable); $20k a ~1.6 anni = LA DECISIONE VENUE DEL 26/07 SMETTE DI ESSERE UN'IPOTESI E DIVENTA UNA DATA (~19 mesi); $117k a ~7.6 anni (XS01). Le soglie superate subito NON autorizzano ad anticipare il gate XSR01 del 23/10. CON IL RISCHIO DI VENUE: P(traguardo) 100% -> 88% a p=1% (P(perso tutto) 23.2%); a p=5% il capitale mediano e' ZERO. Il piano regge fino a p=2%. ⚠️ AZIONE OPERATIVA TROVATA (non eseguita, e' config su soldi veri): `book._cap` ripiega su max_notional_per_asset_usd=$300 quando l'equity reale non e' leggibile. A $597 il fallback era INERTE (equity/2 = $298 ~ $300); dopo il versamento equity/2 vale ~$3.023, quindi un fallback strozzerebbe il book al ~10% del target, in silenzio. E' 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, che FALLISCE se si deposita senza adeguare il cap. Aggiunta anche la sezione (F) frontiera di sostenibilita' a r0726_deposits.py: capitale e rendita per (importo x anni sostenuti), e il confronto "tirare poco tempo vs comodo a lungo" — EUR 400/m per 5a batte EUR 200/m per 20a, ma EUR 600/m per 3a perde contro EUR 250/m per 15a. Book, pesi, cron, config INVARIATI. 380 test verdi (+3). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Adriano Dal Pastro
|
4703f75f9f |
research: i versamenti — le 4 ipotesi che il piano non aveva mai fatto
Tutte le traiettorie del 25-26/07 assumevano versamento PIATTO, ININTERROTTO, PER SEMPRE: l'ipotesi meno realistica dell'intero piano. Misurate le deviazioni che succedono davvero, con la stessa macchineria (block bootstrap sui ritorni reali del book live, fattore d'ancora x0.89 misurato). (1) SMETTERE — il costo non e' proporzionale ai soldi mancanti. EUR 250/m per K anni poi stop, orizzonte 20a: 3a ($10.410) -> $202.771 / P(muro) 32.7%; 5a -> $287.081 / 53.3%; 20a ($66.818) -> $496.778 / 90.0%. I PRIMI 5 ANNI SONO IL 25% DEI SOLDI E IL 58% DEL RISULTATO -> un'interruzione al 12° anno costa poco, una al 3° quasi tutto. Argomento per partire con un importo sostenibile invece che ambizioso. (2) CRESCENTE E' PEGGIO DI PIATTO A PARI SOLDI. EUR 150/m +5%/anno versa EUR 67.998 -> $401.889; piatto EUR 250 versa EUR 66.818 -> $496.778 = +24% con gli stessi soldi, solo perche' entrano prima. Metrica giusta per confrontare piani di taglia diversa = $ finale / $ versato (piatti 7.4x, crescenti 5.1-5.9x). (3) STESSO TOTALE, CALENDARIO DIVERSO = FATTORE 6. EUR 60.000 distribuiti: ultimi 10 anni $178.494 (11%) / piatto 20a $496.778 (90%) / primi 5 anni $1.104.587 (99.4%). NON significa "versa tutto subito": un piano che non si sostiene non e' un piano. Verificato COL RISCHIO DI VENUE DENTRO (il front-load mette piu' capitale sull'exchange prima = proprio il rischio del giorno): REGGE, 2.22x -> 2.09x a p=2%, perche' il rischio colpisce il tempo, non il calendario. MA a p=5% il capitale mediano e' $0 PER OGNI CALENDARIO -> formulazione piu' netta del rischio di venue trovata finora: non erode il piano, lo CANCELLA. (4) LA DOMANDA INVERSA — rendita netta EUR/g mediana per versamento e orizzonte. EUR 150/m -> 23.96/g a 15 anni; EUR 250/m -> 39.11/g a 15a e 91.30/g a 20a (P(EUR 50/g) 90%). Riformula l'obiettivo: EUR 50/g e' UN punto sulla griglia, non l'unico risultato. Non-linearita': da 15 a 20 anni la rendita piu' che raddoppia a ogni livello. (5) FREQUENZA = la decisione meno importante. Mensile fino a ~$2/trasferimento, bimestrale sopra; differenze 1-3% del capitale finale. Verificato che un deposito NON resta strozzato: col cap dinamico cap = equity/2 = il nozionale massimo richiedibile. ORDINE DI IMPORTANZA: versare o no (da mai a 16 anni) > quando (6x) > quanto presto si smette (5 anni = 58% del risultato) > piatto vs crescente (24%) > frequenza (1-3%). Book, pesi, cron, config INVARIATI. 377 test verdi (+12). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |