Quartz 4

FIRE 75.29 PAD ✨ Evoluzione del Backtest Engine a Supporto Birezionale

4 min read

PAD (Piano d’Azione Dettagliato): Evoluzione del Backtest Engine a Supporto Birezionale (Long/Short)

Versione: 1.0
Data: 2025-10-27
Stato: Posticipato - Da riprendere dopo il completamento delle attuali priorità di sviluppo.

1. Premessa (Il “Perché”)

Contesto: Durante il nostro ciclo di ricerca, abbiamo sviluppato con successo una strategia profittevole, la TrendFollowingForecastStrategy. Questa strategia ha dimostrato un “edge” significativo, ma ha anche messo in luce un limite fondamentale della nostra attuale infrastruttura di backtesting.

Il Problema Identificato:
La nostra architettura attuale, dal BacktestEngine al MetricsCalculator, è unidirezionale. È stata progettata per simulare e analizzare solo strategie long (acquisto a un prezzo basso, vendita a un prezzo più alto).

Le Conseguenze di Questa Limitazione:

  1. Analisi Incompleta delle Strategie: Non possiamo testare la logica short della nostra nuova strategia, impedendoci di valutarne la performance nei mercati ribassisti. Una vera strategia “trend following” deve poter guadagnare in entrambe le direzioni.

  2. Mancanza di Profondità Analitica: Il nostro report di backtest aggrega tutte le metriche. Non possiamo distinguere le performance del lato long da quelle del lato short. Questo ci impedisce di rispondere a domande cruciali come: “La strategia è brava a prevedere i rialzi ma pessima a prevedere i ribassi?“. Senza questa distinzione, non possiamo ottimizzare la strategia in modo efficace.

  3. Blocco per Sviluppi Futuri: Questa limitazione ci impedisce di sviluppare strategie più sofisticate, come quelle market-neutral o di arbitraggio, che sono fondamentali per uno strumento di trading di livello professionale.

Conclusione della Premessa: Per elevare FIRE da uno strumento di analisi a una vera piattaforma di ricerca quantitativa, è imperativo potenziare il nostro sistema di backtesting per renderlo birezionale.

2. Obiettivo (Il “Cosa”)

L’obiettivo di questo piano d’azione è far evolvere l’infrastruttura di backtesting di FIRE per simulare, registrare e analizzare in modo distinto le performance delle operazioni long e short.

Al termine di questo intervento, un utente sarà in grado di:

  • Scrivere strategie che eseguano vendite allo scoperto (short selling).

  • Ottenere un report di backtest dettagliato che presenti le metriche di performance aggregate e separate per il “Long Side” e lo “Short Side”.

3. Piano d’Azione Dettagliato (Il “Come”)

L’implementazione verrà suddivisa in 5 fasi sequenziali per garantire un’integrazione controllata e testabile.

Fase 1: Potenziamento del BacktestEngine

  • Obiettivo: Modificare il motore per gestire internamente lo stato di una posizione short.

  • Azioni:

    1. Modificare la variabile di stato self.position da Optional[str] a Optional[str] dove i valori possibili sono ‘long’, ‘short’, None.

    2. Creare un nuovo metodo pubblico short().

    3. Modificare buy(): se self.position è ‘short’, buy() deve agire come un cover (chiusura della posizione short); altrimenti, apre una nuova posizione long.

    4. Modificare sell(): deve chiudere esplicitamente solo una posizione long.

    5. Aggiornare close_position() in modo che chiami sell() se self.position 'long' e un futuro cover() se self.position ‘short’.

    6. Modificare il calcolo del profitto per gestire correttamente i trade short (profitto = prezzo di ingresso - prezzo di uscita).

Fase 2: Aggiornamento dell’Interfaccia BaseStrategy

  • Obiettivo: Esporre le nuove funzionalità allo sviluppatore di strategie.

  • Azioni:

    1. Aggiungere un nuovo metodo short() all’interfaccia di BaseStrategy che delega la chiamata all’engine.

    2. Aggiornare la documentazione (docstring) della proprietà self.position per riflettere i nuovi possibili valori di ritorno (‘long’, ‘short’, None).

Fase 3: Potenziamento del MetricsCalculator

  • Obiettivo: Estendere il calcolatore di metriche per fornire un’analisi differenziata.

  • Azioni:

    1. Modificare il metodo principale (calculate_all o simile).

    2. All’interno, filtrare il DataFrame dei trade in due sottoinsiemi: long_trades = trades_df[trades_df[‘type’] == ‘BUY’] e short_trades = trades_df[trades_df[‘type’] == ‘SHORT’].

    3. Eseguire il calcolo delle metriche su tre DataFrame: quello completo, long_trades e short_trades.

    4. Modificare la struttura dati di ritorno per restituire un dizionario nidificato, ad esempio:

      codeJSON

      {
  "Overall": { "Total P/L": ..., "Win Rate": ..., ... },
  "Long Side": { "Total P/L": ..., "Win Rate": ..., ... },
  "Short Side": { "Total P/L": ..., "Win Rate": ..., ... }
}

Fase 4: Aggiornamento della UI (BacktestTabWidget)

  • Obiettivo: Visualizzare il nuovo report dettagliato.

  • Azioni:

    1. Modificare il BacktestStatsModel (il modello per la QTableView dei risultati) per accettare la nuova struttura dati nidificata.

    2. Aggiornare la logica di visualizzazione per presentare i dati in modo chiaro, probabilmente utilizzando righe speciali o intestazioni per separare le sezioni “Overall”, “Long Side” e “Short Side”.

Fase 5: Attivazione e Test della Strategia Completa

  • Obiettivo: Validare l’intera catena con un caso d’uso reale.

  • Azioni:

    1. De-commentare e implementare la logica short nella TrendFollowingForecastStrategy.

    2. Eseguire un backtest completo su un titolo con trend sia rialzisti che ribassisti (es. TSLA).

    3. Verificare:

      • Che il trade log registri correttamente sia i trade BUY che SHORT.

      • Che il report di backtest nella UI mostri correttamente le tre sezioni di metriche.

      • Che i calcoli di profitto per i trade short siano corretti.

4. Visione a Lungo Termine

Il completamento di questo piano d’azione non è solo un potenziamento, ma un’abilitazione. Sbloccherà la capacità per noi e per i nostri utenti di ricercare e sviluppare una nuova classe di strategie molto più sofisticate, portando FIRE a un nuovo livello di professionalità.

Graph View