|
  

Online grazie a...

FastForward 3fx

Cosa diavolo è un sistema automatico. Parte 4.

Stampa E-mail
Scritto da Simon   
Lunedì 08 Agosto 2011 17:26

Salve a tutti!

Ci eravamo lasciati con la parte 3 anticipando che avremmo dovuto in qualche modo trattare l'argomento di cosa diamine è una black box e perché dovrei fidarmici.

Per black box intendiamo un sistema senza regole, ma solo metaregole. In pratica, parlando di trading, è un sistema che quando decide di aprire o chiudere una determinata posizione non lo fa perché un insieme di condizioni inputate dal programmatore si verificano nel grafico. Il processo decisionale di apertura/chiusura posizioni è guidato da metaregole (regole a livello superiore, istruzioni su come ricavare autonomamente, di volta in volta, le regole). Posso istruire il programma a cercare di ottimizzare di continuo determinati fattori sulla base degli storici o del rendimento passato. Tali fattori entreranno poi in una funzione decisionale in cui scopo è ricavare un output del tipo compra . vendi . non agire. Ma quando arriva il momento in cui la posizione viene aperta/chiusa lo stesso programmatore non sa minimamente il perché, così come non è in grado di prevedere quali e quante operazioni l'algoritmo aprirà/chiuderà a breve. Il programmatore infatti non sa come le metaregole hanno lavorato sui fattori e non ne conosce il risultato. Per questo tali algoritmi si chiamano scatole nere o anche scatole chiuse.

Qui di seguito elenchiamo i vantaggi e gli svantaggi di questo approccio, assumendo un algoritmo realizzato con la dovuta cura e quiandi efficace nell'elaborare previsioni e operatività.

 

VANTAGGI

- Adattività. Questi sistemi immagazzinano le esperienze del passato e tendono ad assimilarle incrementando con il tempo la propria complessità.

- Solidità. Questi sistemi sono in grado di produrre profitti non spaventosi ma con una buona continuità nel tempo. Producono già nel medio periodo curve di guadagno stabili contro un livelli bassi di maximal drawdown (concetto esposto nella parte 2).

- Non riproduciblità. Essendo programmi complessi con un insieme di metaregole non banali e non emergenti alla luce dell'operatività sul campo, non sono clonabili (in gergo hacker, non sono decompilabili).

- Presenza/rilevanza. Questi sistemi sono praticamente sempre sul mercato. Come potete osservare dalle immagini sotto, trascorrono poche barre tra la chiusura di un'operazione e l'apertura della successiva (e alle volte nemmeno quelle poche). Questo (come esposto nella parte 2) produce l'acculuarsi di molte operazioni. E significa in ultima analisi una rilevanza statistica dei risultati maggiore di qualunque altro sistema automatico a parità di tempo di test.

 

Ovviamente la freccia blu sta per: ordine long aperto. La freccia rossa sta per: ordine short aperto. Le rispettive controfrecce ne rappresentano ovviamente le chiusure. La barre orizzontale marrone è l'ultimo livello di stop loss o trailing stop dell'ordine in corrispondenza del quale si situa.

 

SVANTAGGI

- Incomunicabilità. E' impossibile da comunicare il perché il sistema automatico di tipo black box ha aperto questa o quella operazione. L'investitore, ovvero colui che ci mette dentro i soldi e che spesso non può essere attento alle nuove frontiere della statistica avanzata, rimane pertanto all'oscuro dei fondamenti di base del processo decisionale. Questo può produrre un comprensibile scetticismo. Questo tipo di strumento rimane in una nicchia scientifica di affascinati del genere tout court fintanto che non dimostra con dati alla mano i rendimenti sul campo.

- Tempo di elaborazione. Sono sistemi fondati su programmi non leggeri e alle volte pesanti. C'è da dire che dal momento in cui vengono attivati al momento in cui operano a pieno regime possono trascorrere anche settimane. In quell'arco di tempo i programmi scandagliano il passato, lo mettono alla prova simulandone l'impatto sul presente e reitarano fintanto che una mole statisticamente sufficiente di dati-prova non è emersa abbastanza chiaramente a guidare l'operatività reale.

- Curva di apprendimento limitata. Il ritmo al quale tali programmi apprendono è molto rapido per un primo periodo. Periodo durante il quale ogni nuova informazione in più viene metabolizzata efficamente e diventa parte del crescente tasso di successo. Ma ad un certo punto il ritmo prende a stabilizzarsi se non addirittura a decrescere. Quando le informazioni accumulate sono troppe, infatti, la sensibilità ad ogni nuove informazione ricavata dall'interazione del modello con il passato e il presente è via via minore. In molti casi si può ovviare a questo inconveniente semplicemente resettando periodicamente la memoria dei programmi e riavviando il sistema ex novo.

 

Queste caratteristiche accostano tale approccio a quello della cosiddetta intelligenza artificiale. Termine molto pomposo e sopravvalutato, poiché alla fin fine di veramente intelligente in senso umano non c'è proprio nulla. Diciamo che se utilizzassimo il sistema per andare a pesca, la differenza tra l'approccio di chi programma un sistema sull'identificazione di patterns e chi invece programma un sistema 'intelligente' sarebbe questa:

- Identificazione patterns. Il mio sistema ad ogni segnale di una certa intensità proveniente da una certa profondità immerge un po' di più la lenza e poi inizia ad opporre resistenza.

- Sistema 'intelligente'. Il mio sistema parte senza avere la benché minima idea di come si faccia a pescare ma ha dei vettori di memoria assemblati in una struttura tale da permettergli di andare a tentavi (trials and errors) in maniera ordinata. Questo ordinato andare a tentativi apre 'finestre' statisticamente importanti di successo. A seconda della complessità del problema e dell'efficacia dell'algoritmo, tali 'finestre aperte' possono essere maggiori o minori (in frequenza e/o dimensione) della voragine di caos che tipicamente si abbatte sempre a cadenza incerta sul tasso di comprensione e successo di sistemi come questi. Diciamo, per farla breve, che anche un sistema 'intelligente' di livello base ha il suo momento di gloria... il punto è che un sistema che produce guadagni ne deve avere parecchi e costanti di momenti di gloria...

Anche a parità di profondità di visione del problema e di eleganza matematica oltre che ovviamente informatica, mentre il primo approccio darebbe magari risultati migliori del secondo in una prima fase, il secondo lo batterebbe con ogni probabilità sul medio periodo.

Ma questo è solo un mio personale parere... perciò ad ognuno la propria canna da pesca automatica allora... e alla prossima!

Ultimo aggiornamento Lunedì 08 Agosto 2011 18:13
 

Cosa diavolo è un sistema automatico. Parte 3.

Stampa E-mail
Scritto da Simon   
Lunedì 25 Luglio 2011 18:25

Nella precedente parte 2 di questa serie di articoli ho affermato che un backtest serio è per esempio quello in dotazione con la piattaforma MetaTrader (parlo per mia esperienza, tanto più che la piattaforma appena menzionata è del tutto gratuita e non necessita di pubblicità). Ho anche sostenuto che un backtest meno serio ("che lascia il tempo che trova") è per esempio quello di ProRealTime (piattaforma che ho usato per diversi anni prima di cimentarmi con MT).

Antonio giustamente ha chiesto chiarimenti in merito alla mia affermazione.

Per capire come avviene il processing di un backtest su MT consiglio questo video.

Coloro che sanno l'inglese possono digerirlo tutto, mentre coloro che non lo sanno possono togliere l'audio e concentrarsi dal minuto 6:30 in poi. Da tale minuto infatti il collaudatore lascia il correre il test facendo vedere chiaramente (quando non mette in pausa ovviamente) i movimenti del prezzo tick per tick. Va da sé che per tick intendiamo l'oscillazione minima di prezzo, nel mercato dei cambi altresì detto pip.

Sto parlando quindi del fatto che:

- Ogni singolo tick è stato salvato dentro un grande database subito disponibile per farci sopra dei test, indipendentemente dal timeframe su cui sto testando.

- I segnali generati nel passato dal sistema automatico sono esaminati, esattamente come se fossimo in ogni istante live, contro ogni singolo tick in modo da ottenere:

  1. altissima precisione;
  2. massimo potenziale di programmazione.

- Tutte le modifiche al livello di take profit, stop loss, prezzo dei pending orders (ecc.) vengono processate esattamente al tick in cui sarebbero avvenute live.

Faccio un esempio. Diciamo che ho un sistema automatico intraday tale per cui:

- Vengono aperte tre posizioni contemporaneamente al verificarsi di una certa condizione

- Viene impostato un take profit diverso per ognuna (rispettivamente in ordine crescente di distanza dal prezzo di apertura: tpA, tpB, tpC)

- Toccato il tpA, il tpB viene spostato in break-even (vale a dire al livello di apertura) mentre il tpC viene aumentato della stessa misura del tpA.

A me risulta che ProRealTime non generi un grafico tick per tick al momento dell'inizializzazione di un backtest. Mi risulta che lavori sulle barre. Perciò se sto testando sul timeframe 5M, per esempio, il backtest sarà fatto contro il massimo il minimo l'apertura e la chiusura di ogni barra da 5 minuti. Al limite, potrà essere fatto contro il massimo il minimo l'apertura e la chiusura di ogni barra di timeframe inferiori, fino a M1. Ma sempre di barre parliamo. E non di singoli ticks.

Su ProRealTime il sistema che ho descritto sopra (ed è un sistema semplicissimo) non potrebbe essere programmato. Infatti, come può sapere con esattezza quando viene raggiunto tpA se non ha in memoria ogni singolo tick? E come può processare il conseguente spostamento degli altri due livelli di presa di profitto? Può solo ciecamente sapere se è stato raggiunto un determinato livello, ma non quando. Quindi non può concatenare istruzioni del tipo: "se A allora (B e C)" all'interno della stessa barra.

Per concludere, una curiosità.

Nel grafico che ho allegato (grafico tick per tick su EURUSD) ho scritto a manona dei numeri in rosso. Su quei due tick che ho indicato con le frecce ho misurato facilmente il delta del prezzo (la variazione rispetto al tick precedente). E' interessante che - evidentemente in un momento di news molto importanti - il prezzo fosse balzato immediatamente di 27+9=36 pips. Ma la cosa più interessante è come questo fosse accaduto. Nella sezione inferiore dell'immagine ho inserito il numero di scambi scrivendoci sopra anche lì il delta. Così, il primo tick ha un delta prezzo di 27 con un delta scambi di 14 (rapporto che sfiora 2). Mentre il secondo tick ha un delta prezzo di 9 con un delta scambi di - udite udite - 1. Quest'ultimo tick è un'entrata di un operatore istituzionale. Se non ci credete, provate voi a muovere l'EURUSD di 9 pips con un solo ordine di acquisto... :-)

La possibilità di isolare particolarità (o singolarità) di questo tipo c'è e mi dà da pensare che la prossima frontiera della conoscenza dei mercati adiuvata da sistemi esperti sia l'individuazione degli ordini importanti (o, meglio, di cluster di ordini importanti) filtrando via tutto il rumore caotico del 90% di ordini in sé insignificanti. E tra quegli ordini insignificanti ci sono ovviamente anche i nostri....

Questo mi dà da pensare quando sia paradossale il mondo del trading. Tutti noi cerchiamo di capirci qualcosa, ma più siamo e più la realtà si fa oscura e complessa. E' un fatto anche demografico, come dire. Prendiamo una comunità. Se questa persona è fatta di 10 abitanti, i loro comportanti e le loro interazioni saranno tutte facilmente prevedibili. Se diventano 100 sarà molto più complesso capire le loro interazioni. Quando saranno 10000 diventerà quasi impossibile. Ma la difficoltà non sta tanto nel numero di connessioni possibili, quanto nel fatto che tante connessioni producono tante modificazioni a livello di ciascun individuo, a livello di ciascun comportamento. E quante più sono, tanto più rapido è il processo. Così è la borsa nell'era di internet... abbiamo accesso a un sacco di informazioni, un sacco di persone e un sacco di pareri, le nostre competenze si accrescono a ritmi esponenziali; per non parlare della possibilità dei sistemi automatici di scovare singolarità ad una velocità prossima a quella della luce. Tutto questo non fa che complicare le cose. Ogni giorno nasce almeno un nuovo set di regole (chiamati usualmente "patterns") da qualche parte del mondo. Ma ogni giorno ne muore almeno uno, solo che il suo "scopritore" non lo sa subito. Fintanto che non se ne accorge, il suo sistema automatico creato perlappunto su quel "pattern" gli ripulisce parte dei guadagni prodotti fino a quel momento (magari anche dal 1999 a quel momento!). Quanto ci metterà secondo voi questo "scopritore" a capire che il suo sistema ha smesso di funzionare? E' un tempo psicologico, la misura che ognuno si dà del Maximal Drawdown che il proprio conto o la propria gestione può sostenere rispetto al totale dei profitti cumulati in un certo - più o meno lungo - arco di tempo passato. Se tale "scopritore", anziché andare alla ricerca del Sacro Graal, avesse osservato tutta la complessità dei mercati e umilmente orientato i suoi sforzi verso una black box adattiva*, oggi avrebbe il sonno più tranquillo che mai: sopravvive chi si adatta continuamente.

Probabilmente si può abbozzare qui una legge in negativo: tanto meno complesso è un pattern tanto meno tempo è destinato a durare.

Se fosse vero darebbe conforto alla mia tesi implicita per cui un sistema leggero e semplice, backtestato con i mezzi di ProRealTime, può anche dare delle curve di profitto buone nel passato ma a rigor di logica è una scommessa sul futuro. Una di quelle scommesse su cui non ci metterei 1000 euro nemmeno sotto minaccia di vita.

*Al prossimo articolo!

Ultimo aggiornamento Lunedì 25 Luglio 2011 20:45
 

Cosa diavolo è un sistema automatico. Parte 2.

Stampa E-mail
Scritto da Simon   
Sabato 23 Luglio 2011 12:06



Con il precedente articolo avevamo affermato che un sistema automatico, secondo noi, deve onorare essenzialmente due requisiti: una serie di algoritmi lo devono reggere in tutto e per tutto (autosussistenza); deve essere profittevole (profittabilità duratura e costante).

Cosa sia l'autosussistenza è stato brevemente trattato, cerchiamo quindi di addentrarci nel concetto chiave di profittabilità.

 

PROFITTABILITA'.

Un sistema automatico che fa profitti è un sistema che ad una certa data futura sarà certamente in guadagno. Le domande che ci si deve porre sono tante. Di sicuro mi sento di sintetizzare le seguenti:

1 - Prima di entrare in guadagno quale sarà il livello minimo che toccherà il mio conto? Ovvero quanti soldi rischia di bruciare nelle settimane o nei mesi in cui siamo in loss? E più in generale, preso un campione abbastanza grande di persone che vogliono mettere i soldi su questo sistema automatico. Posto che ognuna di esse sceglierà di attivare il sistema sul proprio conto in un momento dell'anno abbastanza distante da tutte le altre attivazioni. Posto anche che tutte ci mettano, diciamo 10.000, a parità di tutte le altre condizioni ci chiediamo:

  1. quanto sarà grande la perdita massima registrata su tutti questi conti prima del loro ingresso in guadagno?
  2. quale sarà la media?
  3. quale sarà la mediana?

2 - Preso lo stesso campione di persone. Prima o poi tutte decideranno di chiudere il conto su cui hanno attivato il nostro sistema per necessità di liquidità. Diciamo che un terzo lo farà dopo 3 mesi, un terzo dopo 6 mesi e l'ultimo terzo dopo un anno.

  1. quante di esse avranno indietro il capitale iniziale aumentato di alcuni profitti? Quante dopo 3 mesi, quante dopo 6, quante dopo un anno?
  2. quale sarà la media? Quale sarà la media a 3 mesi, la media a 6, la media a un anno?
  3. quale sarà la mediana? Quale sarà la mediana a 3 mesi, la mediana a 6, la mediana a un anno?

3 - Come scegliere tra un sistema "A" e un sistema "B" se su di essi dispongo di backtest (test offline simulati sulle barre passate) e livetest (test online su conti demo o reali) su archi temporali diversi? La risposta a mio avviso è questa: occorre guardare non tanto alla durata temporale dei test, quanto al numero complessivo di operazioni chiuse. Se il sistema "A" ha un backtest di un solo anno e un livetest di un solo trimestre, mentre il sistema "B" ha un backtest di 3 anni e un livetest di 9 mesi posso dire con certezza che il sistema "B" batte il sistema "A" 3 a 1 in termini di ESTENSIVITA' di test. Ma se il sistema "A" ha chiuso 800 operazioni nel suo anno di backtest e 200 nel suo trimestre di livetest, mentre il sistema "B" ha chiuso 600 operazioni nei 3 anni di backtest e 150 nei 9 mesi di livetest, il sistema "A" batte il sistema "B" 4 a 1 in termini di INTENSITA' di test. I test del sistema "A" sono statisticamente molto più attendibili di quelli del sistema "B".

Per quanto riguarda il punto 1, la perdita assoluta registrata prima dell'ingresso guadagno del sistema si dice Absolute Drawdown. Ma per capire meglio il concetto di "drawdown", aggiungiamo un altro aspetto importante. Quando un'operazione viene chiusa in perdita io posso vedere la stessa perdita in due modi diversi: la perdita massima che il conto stava subendo quanto ancora l'operazione era aperta, la perdita finale una volta che il sistema ha chiuso l'operazione. Da una parte ho il concetto di Maximal Drawdown come ritracciamento massimo della curva del Controvalore (o Equity Curve), dall'altra ho il concetto di perdita registrata sulla curva del Saldo (o Balance Curve).

Dal momento che io posso volere i miei soldi indietro in qualsiasi momento della gestione chiudendo eventuali posizioni ancora in essere, risulta chiaro che i concetti chiave per misurare il rischio reale massimo che un sistema fa sopportare al nostro conto sono questi due:

  • Absolute Drawdown
  • Maximal Drawdown

A questo dovrebbe essere chiaro che per valutare un sistema automatico in termini di profittabilità di servono 3 misure:

  1. misura del profitto a parità del resto
  2. misura della massima perdita a parità del resto
  3. misura del numero di operazioni a parità del resto

In particolare, tolto il punto 3 piuttosto facile da calcolare, le prime due si possono molto opportunamente sintetizzare come segue:

  1. Qualora si disponga di statistiche di più anni di performance: Indice di Calmar, ovvero il rapporto tra il Compound Annual Growth Rate (che altro non è se non il tasso al quale l'investimento sarebbe cresciuto di anno in anno ponendo tale tasso come sempre uguale) e il Maximal Drawdown (che abbiamo descritto in precedenza).
  2. Qualora si disponga di statistiche inferiori ai 2 anni di performance: si guarda al Fattore di Profitto (ovvero al rapporto profitti totali lordi/perdite totali lorde) e al Maximal Drawdown costruendo eventualmente un indice (poco elegante ma funzionale se vogliamo ordinare più sistemi secondo questi concetti di rendimento) come rapporto tra i due termini.

Altre due cose sull'importanza di test di qualità.

Se parliamo di test nel passato, un backtest di qualità non è una semplice simulazione quanto piuttosto una ricostruzione esatta di cosa sarebbe accaduto tick per tick! E allora se un test è svolto così ha un valore (e mi riferisco per esempio alla dotazione di MetaTrader), altrimenti (vedi per esempio quelli su ProRealTime) lascia veramente il tempo che trova. Ciò detto, molti test su piattaforme autorevoli possono dare in uscita una bellissima curva di guadagno...

... solo che il sistema non funzionerà affatto così in versione live. Perché?

Perché se prendo un sistema relativamente semplice e leggero, ne isolo le variabili di input determinanti per l'apertura e la chiusura delle operazioni in modo da passarle agli algoritmi di ottimizzazione presenti nell'ambiente di backtesting, posso ottenere una curva dei profitti drogata. Una curva come sarebbe stata se io all'inizio della gestione del mio conto avessi "indovinato" il valore ideale di queste variabili di input per questo arco di tempo.

Il 99% dei sistemi in commercio attualmente presenta curve di backtest drogate. Questo stesso 99% presenta statements (vale a dire fogli con il dettaglio di ogni operazione, in teoria certificati dal broker che ti dà accesso alla piattaforma e al flusso dati) falsi anche quando si tratta del livetest.

Il mercato, così come qualsiasi cosa ruoti intorno al mondo dei sistemi automatici, oggi è fortemente compromesso nella sua credibilità per via di tutto questo rumore che in gergo si chiama "scam". Senza volerci dilungare oltre in questa sede, per emergere da questo rumore occorre una solidità provata e una umiltà avvertibile anche per l'assenza di promesse irrealizzabili.

Al prossimo articolo!

Ultimo aggiornamento Lunedì 08 Agosto 2011 17:58
 

Cosa diavolo è un sistema automatico. Parte 1.

Stampa E-mail
Scritto da Simon   
Mercoledì 20 Luglio 2011 21:32

Eccoci qua. Dal momento che non esistono fonti scientifiche autorevoli o letteratura affermata a riguardo, non potrò citare altri autori. Sembra sempre molto scientifico citare gli altri, in realtà proprio "gli altri" da qualche devono pure avere incominciato... da soli.

Un sistema automatico, secondo noi, deve onorare essenzialmente due requisiti: una serie di algoritmi lo devono reggere in tutto e per tutto (autosussistenza); deve essere profittevole (profittabilità duratura e costante).

Ora, per capire meglio e addentrarci un po' nel ragionamento facciamo innanzitutto chiarezza sul primo di questi due punti.

 

ALGORITMI.

Crediamo che un sistema automatico debba potersi basare su un linguaggio flessibile e scalabile, tale da poter elaborare una discreta mole di dati in tempi ragionevoli e tale da consentire un vero lavoro sia matematico che informatico. Allo stato attuale ci sono essenzialmente due possibilità:

- C/C++ e successiva integrazione su piattaforme tramite API (application programming interface... interfaccia per programmare applicazioni)

- linguaggi embedded su piattaforme perfettamente integrate (MetaTrader con il suo MQL, ovvero MetaQuote Language)

Gran parte della nostra esperienza si è svolta nei binari della seconda opzione. Ci ha convinto da subito l'immediatezza con cui si poteva mettere al vaglio dei mercati qualsiasi serio progetto informatico. Non credo opportuno spendere altre parole su questi prodotti, chi vuole lo farà da sé.

Gli algoritmi devono reggersi da soli. Vale a dire devono contemplare sicuramente:

- Elaborazioni volte a prendere decisioni di entrata, uscita, livelli di s/l t/p

- Elaborazioni volte a reagire alle possibili inefficienza del flusso dati della piattaforma (vale anche a dire del broker stesso). Per esempio, l'algoritmo ha emesso una decisione di acquisto (per entrare ad un certo livello di prezzo che chiameremo "decisionale"). Tra la decisione e l'effettivo acquisto c'è un brevissimo lasso di tempo in cui l'ordine va al mercato e viene finalizzato al meglio secondo il parametro di slippage e le caratteristiche del broker/mercato con cui abbiamo deciso di fare i conti. Lo slippage, per la cronaca è molto noto nel mondo del Forex ed è la tolleranza massima a nostro sfavore che decidiamo di sopportare nel caso in cui il tempo di esecuzione dell'ordine non possa essere abbastanza breve (in circostanze di elevata volatilità) da "fissare" il prezzo all'esatto livello decisionale. Ebbene, possono darsi due casi:

  1. il sistema automatico sta emettendo un ordine, la volatilità è eccezionalmente alta e lo slippage che abbiamo impostato come parametro in ingresso non consente di entrare a mercato, per cui l'ordine semplicemente non passa anche solo per un paio di pips (in questo caso il sistema emette la segnalazione di un requote in atto)
  2. errori di sovraffollamento ordini, crash generico e perdita connessione, per cui l'ordine viene ugualmente ignorato.

Stiamo ovviamente parlando di casi remotissimi, il flusso dati è stabile ed efficientissimo e molti broker oggi permettono un'entrata veramente istantanea e non necessitano più di parametrare lo slippage. Cionondimeno, quando ho iniziato a lavorare su questo sistema automatico ho dovuto necessariamente risolvere tutte queste questioni.

- Immagazzinaggio della situazione di tutte le variabili globali in ogni istante. Diciamo, per farci capire, che un certo sistema fa fare una determinata operazione quando si verifica un certo incrocio di medie mobili. Al verificarsi di questo evento la variabile globale "A" passa da 0 a 1. Diciamo anche che abbiamo consapevolmente programmato il nostro sistema in modo che nessuna successiva elaborazione per decidere sulla chiusura di tale operazione possa avvenire fintanto che tale variabile rimane 1. Se il mio pc si spegne, oppure sono costretto a spegnerlo, oppure mi sono dimenticato di pagare la bolletta al mio provider, oppure mi sono appoggiato ai server di Aruba ma nella loro webfarm è in corso un incendio, oppure semplicemente la piattaforma su cui sta girando il mio sistema fa crash... in tutti questi casi io perderei un'informazione preziosissima: il valore di "A" prima del crollo. Immaginate che il vostro sistema stesse operando su 4 o più cambi contemporaneamente e avesse perlappunto 4 o più posizioni aperte al momento del crash... nel caso in cui l'evento che fa passare "A" da 0 a 1 sia un minimo complicato ci troveremmo a riavviare la piattaforma senza sapere cosa fare di queste posizioni aperte. Per questo è fondamentale dedicare spazio alle procedure di backup continuo e di ricaricamento variabili in fase di ripartenza.

- Emissione di testo per tenere sempre al corrente di cosa stia avvenendo dentro al sistema. Nella piattaforma che adopero io il procedere del sistema va di pari passo con la costruzione di file di testo in cui leggo in tempo reale che: si sta verificando una condizione, si sta verificando un segnale, si sta verificando una certa - di tante - routine di apertura o chiusura, si sta verificando un certo - di tanti possibili - errori o bug. Ovviamente, quest'ultimo caso viene prima o poi debellato completamente per trials&errors.

Tutto questo, raccontato qui in forma molto stringata, non basta.

Per essere veramente autosussistente, un sistema deve avere due cose importantissime:

- un sottoalgoritmo, alimentato da masse più o meno enormi e uniformi di dati storici, di previsione sulla cui base vengono emessi segnali di ingresso/uscita rispetto al mercato.

- un sottoalgoritmo, alimentato dalle stesse recentissime prestazioni del sistema, di ottimizzazione sulla cui base viene modulata la soglia inibizione/magnificazione dei segnali emessi sopra.

In parole semplici, realizzato un algoritmo con cui "prevedere" in qualche misura il futuro a partire dal passato, posso essere certo che su 100 operazioni non accadrà mai di prevedere al meglio tutti e 100 i movimenti.  Allora serve un meccanismo di autoregolazione che metta insieme a) la frequenza storica con cui sotto determinate condizioni di mercato il sistema ha previsto bene con b) l'attuale frequenza data una determinata condizione di mercato.

Nessun sistema basato su un meccanismo rigido di previsione o di ricerca "pattern" può essere definito stabile (su cosa intendiamo per "stabile" si aprirà in seguito un capitolo a sé nell'ambito della nozione di "profittabilità duratura e costante") senza un sistema di ottimizzazione interno. Sarebbe come un ABS per le nostre auto che funziona allo stesso modo sia quando cerco di frenare alla velocità di 150km/h che quando cerco di frenare alla velocità di 50km/h. Se ho tarato l'ABS sui 50km/h sicuramente lo spazio di frenata quando sarò sparato a 150km/h sarà ampissimo. Viceversa, se ho tarato l'ABS sui 150km/h, quando andrò a 50km/h verrò sbalzato fuori dal parabrezza. :-)

Per questo alcuni sistemi vanno benino in certe condizioni di mercato (tipicamente, e per semplificare, si dividono in trending e ranging) e male nelle altre (abbastanza male, per intenderci, da vanificare tutto il buono fatto nelle condizioni favorevoli). Un sistema che sia accettabile deve essere anche solo un minimo ADATTIVO. Deve potere capire che, se nella stessa condizione ha fatto 9 buone operazioni sulle ultime 10, i prossimi segnali che emetterà sempre in analoghe condizioni di mercato saranno statisticamente sempre meno attendibili nell'attesa che un certo tasso "naturale" di successo/insuccesso venga ripristinato.

Alla prossima!

Ultimo aggiornamento Sabato 23 Luglio 2011 10:04