⚠️ la sezione ARTICOLI di QTLab si sposta su un nuovo sito: clicca qui per leggere TUTTI i prossimi articoli di Luca Giusti e dello staff di QTLab 👉

https://www.lucagiusti.it/2021/11/17/imparare-ad-usare-una-piattaforma-o-imparare-a-programmare-ecco-il-nostro-punto-di-vista/


Nello svolgere analisi sui dati per costruire dei modelli di investimento o di trading ci si imbatte spesso nella scelta della tecnologia più opportuna da utilizzare.

La domanda spesso gira intorno a due possibili soluzioni:

1) utilizzare Programmi o Piattaforme dedicate (che già esistono), oppure...

2) imparare a programmare in Python, Matlab, R, C#, e scrivere quel programma da zero

In questo articolo vogliamo darvi il nostro punto di vista su entrambi gli approcci.

Vorrei iniziare sottolineando la posta in gioco: i nostri risparmi 💰

Nell’investing e nel trading gli gli Errori vengono spesso puniti molto duramente. E questo è probabilmente il primo punto da cui partire:

quando si scrive un software è inevitabile commettere una moltitudine di errori: non esiste un software privo di bug, indipendentemente dalle capacità di chi l’ha scritto.

Facciamo un paio di esempi: partiamo dalla NASA.

Nel 1998 la NASA ha lanciato il Mars Climate Orbiter🚀, una sonda deputata alla mappatura dell’atmosfera di Marte. Tuttavia nel Settembre dell’anno successivo, quando la sonda sarebbe dovuta entrare in orbita marziana, la comunicazione andò perduta in seguito allo schianto della sonda sul pianeta rosso. Il problema?

Una parte del software utilizzava il sistema metrico di misurazione, un’altra parte, scritta da un’altra agenzia, il sistema imperiale

Passiamo al’ESA, l’equivalente europeo della NASA.

Nel 1996 un razzo Arian 5🚀 andò completamente distrutto, insieme al suo carico, 30 secondi dopo il lancio. Il problema, si capì in seguito, fu che un numero con la virgola a 64 bit relativo alla velocità orizzontale rispetto alla piattaforma di lancio, veniva convertito in un intero a 16 bit. Il numero era maggiore di 32'767, ovvero il più grande valore registrabile come intero a 16 bit.

La conversione quindi falliva, comportando la perdita del razzo.

Il nostro principale obiettivo, nell’investing e nel trading, prima ancora di guadagnare, è che il nostro conto non finisca come l’Arian 5 o il Mars Climate Orbiter🚀.

Ogni riga di codice che scriviamo, ogni singola riga,
ha dentro di se una certa probabilità di contenere un errore.

Il problema è che noi non conosciamo nemmeno che tipo di errore potrebbe contenere.

Lo spazio degli errori possibili è talmente vasto che è impossibile a priori sapere quale impatto avrà (o potrebbe avere) il nostro prossimo errore, sulle nostre analisi.

Ogni modello che andiamo a implementare porta con se scelte da fare e ipotesi da formulare.

In questa o quella situazione bisogna usare la media aritmetica o quella logaritmica?

Devo includere i weekend nel tempo restante a scadenza?

Al tasso risk-free posso assegnare un valore statico arbitrario, come il 3%, o è necessario fare un’ipotesi più precisa?

Devo considerare l’inflazione?

Nel calcolo delle correlazioni devo utilizzare le serie storiche o le serie delle loro variazioni?

O forse è la serie delle loro log-variazioni quella corretta?

Quando un errore nei dati fa divergere i risultati come faccio a riscalarli per renderli utilizzabili?

In questo o quel calcolo devo utilizzare la serie grezza, quella rettificata sugli split, o quella rettificata su split e dividendi?

Come gestisco le variazioni dei tassi di cambio nella simulazione?

Quale modello di machine learning è più adatto al problema che mi sto ponendo?

Se le serie che sto analizzando sono di mercati di paesi diversi come gestisco lo sfasamento del fuso orario?

Come gestisco lo sfasamento delle date delle festività? Questo test statistico è utilizzabile per il problema che sto affrontando?

Le sue ipotesi sono conformi al contesto in cui è posto il mio problema?

Quale valore di significatività statistica devo utilizzare?

Devo usare il test a una coda o il test a due code?

queste sono solo alcune delle domande che nello sviluppo di tecnologie di analisi dei dati, dobbiamo porci ogni giorno...

Per poter fare queste scelte e formulare correttamente le ipotesi è necessario comprendere nella sua interezza il modello che stiamo implementando, il problema che questo è deputato a risolvere, e come il modello giunge alla soluzione.

E’ necessaria una preparazione tecnica non indifferente, perchè si tratta di UNIRE abilita di programmazione a conoscenze di matematica e statistica che NON sono proprio così diffuse fra trader e investitori...

Che sia un motore di Black-Scholes per il calcolo della volatilità implicita, che sia un motore per l’allocazione di portafoglio, che sia un motore per l’analisi di una serie storica, che sia un motore di machine learning, noi dobbiamo conoscere quello che stiamo sviluppando intimamente, o i nostri risparmi non saranno al sicuro e saranno esposti agli sbagli che andremo a compiere e alle loro imprevedibili conseguenze.

Se non si hanno settimane a disposizione per studiare il problema che si cerca di risolvere, attaccarlo da soli non farà che esporci a rischi.

Al contrario, utilizzare una piattaforma non richiede tutto questo...

Vediamo un esempio: in Invest Studio abbiamo inserito un motore per la produzione di portafogli Beta Neutrali che permette l’implementazione di strategie di arbitraggio statistico. L’utente ha la garanzia che le scelte e le ipotesi fatte nello sviluppo del motore del calcolo dei beta sono frutto di studio approfondito e di un’attenta analisi. Può assumere che le serie utilizzate sono quelle corrette.

Ma il fatto che possa fidarsi non significa che debba farlo.

Se volesse conoscere i dettagli dei calcoli e delle ipotesi e delle scelte fatte, gli basta aprire la guida e andare a leggerle. Se non fosse sufficiente può interfacciarsi con noi e chiedere informazioni.

Insomma, l’utente si può dedicare a interpretare i risultati di quell’analisi, con la serenità che sia stata condotta in maniera corretta

Non è tutto. Un ulteriore fonte di incertezza è che anche conoscendo i dettagli più intimi del problema i nostri risparmi non sono al sicuro dagli errori che inevitabilmente commetteremo. La NASA e l’ESA sanno fare molto bene il loro lavoro, ma molto, molto bene. E conoscono indubbiamente molto bene il problema della navigazione spaziale, sono i migliori al mondo. Questo non li ha messi al riparo dal commettere errori che sono costati ai contribuenti miliardi di dollari e di euro. Ma non per disattenzione, ma per la natura caotica intrinseca dei sistemi software.

L’Arian 5, dopo il 1996 è stato lanciato altre 110 volte ed è ora ritenuto il razzo più sicuro del mondo tanto che è stato selezionato per portare in orbita, questo Dicembre, il telescopio spaziale James Webb, ovvero il telescopio più avanzato, nonché uno degli esperimenti scientifici più costosi del mondo.

La stessa cosa accade a un software di analisi dei dati.

Un programma con un’ampia base di utiizzatori viene lanciato di continuo molteplici volte, questo comporta che i suoi inevitabili problemi vengano rapidamente a galla, cosa che permette che siano risolti rendendo il programma più affidabile giorno dopo giorno.

Capitali relativamente grandi sono affidati agli output dei nostri programmi, proprio perché sappiamo di poterci fidare dell’output che forniscono.

Un programma che ha un UNICO utilizzatore (=colui che l'ha implementato, il programmatore stesso), per essere soggetto alla stessa quantità di stress a cui è sottoposto un programma con una moltitudine di utenti, richiederebbe parecchi anni.

Il fatto stesso che l’unico utilizzatore è anche il programmatore comporta di per se già il problema di avere un BIAS nell’utilizzo: è stupefacente come 2 persone possano utilizzare uno stesso programma in modi completamente diversi. Questo rende molto più probabile che i bug vengano a galla. Accade spesso, infatti, che un bug resti sommerso quando il programma viene utilizzato in un certo modo, e che diventi macroscopico quando viene utilizzato in un altro. Ma anche da sommerso può essere potenzialmente molto dannoso.

Finora abbiamo discusso la sicurezza del programma e dei nostri risparmi, ma questo non è l'unico punto a cui prestare attenzione.

C’è anche il problema della rapidità dell’analisi e dell’efficienza con cui utilizziamo la nostra risorsa più importante: il Tempo

Raramente un programma ha un’unico fine, mentre uno script viene scritto con un determinato scopo.

Se l’analisi non è soddisfacente, e vogliamo cambiarla, va cambiato lo script.

Questo perché le cose non vanno mai come noi pensiamo: crediamo che un certo modello sia quello giusto, lo testiamo, e scopriamo che invece non ha valore. Dovremo quindi modificarlo, o passare a un altro modello. La versatilità ha un valore immenso nell’analisi dei dati proprio perché questa analisi è un percorso che si modifica mano a mano che lo percorriamo.

Si capisce che c’è un problema in questo: se si vuole implementare un motore con un discreto grado di versatilità, a un certo punto, ci scontreremo con i problemi che la versatilità comporta: l’interfaccia input, la manutenibilità del codice, la gestibilità della soluzione.

Qui subentra la quantità di tempo che ci si può dedicare. Costruire un programma completo e versatile richiede mesi di intenso lavoro per essere pensato, progettato, e sviluppato, e altrettanto per essere sistemato fino a diventare affidabile.

Ma questo è possibile solo se il lavoro è giustificato dalla presenza di un'ampia base di utilizzatori.

Se noi siamo l’unico utilizzatore di un programma, difficilmente l’operazione di svilupparlo diventa economicamente sostenibile in termini di costo e di tempo, e quindi, di fatto, non scriveremo un programma ampio e versatile, ma solo una cozzaglia disordinata di script, ognuno con i suoi problemi e bug.

Il collo di bottiglia nel condurre così queste analisi, sarà la scrittura di script poco affidabili 👎 che replicano calcoli che potrebbero essere effettuati da software già esistenti, in maniera più affidabile👍.

Perderemo tempo a scrivere codice relativamente inutile invece che passarlo a fare ciò che compete all’investitore: usare qui modelli per cercare opportunità sui mercati.

Lasciando lo sviluppo agli sviluppatori, l’investitore può dedicarsi alle sue analisi senza dover investire il proprio tempo nella creazione dell’infrastruttura necessaria a farla quell’analisi.

Questo è un utilizzo efficiente del proprio tempo.

...ma d'altronde non è già quello stai facendo?

Usi Windows 10 (o Mac OS), oppure ti sei scritto da solo un tuo sistema operativo? É senza dubbio affascinante (e per alcuni molto appagante) imparare a scrivere un proprio sistema operativo, ma sei davvero sicuro che potrà mai avvicinarsi all'efficienza, alla velocità e alla stabilità di Windows 10, che è stato costruito sul lavoro di migliaia di ingegneri della Microsoft, e utilizzato da una base di utenti sterminata, che segnala (in maniera più o meno consapevole) eventuali bug? Davvero pensi di far meglio?

Quando devi effettuare dei calcoli, usi Excel (o un foglio di calcolo equivalente) oppure ti rimbocchi le maniche e programmi il tuo foglio di calcolo in C#?

E se devi scrivere una lettera, apri Word oppure sei davvero convinto che sia più comodo scrivere da zero un software per farlo?

E allora perchè dovresti imparare risolvere un'equazione differenziale stocastica alle derivate parziali, invece di lanciare quella stessa analisi con un paio di click su una piattaforma che è stata costruita proprio per questo?🤷‍♂️

(e guarda che stavo parlando della Black & Scholes, non di fisica dei razzi)

Non sei un fisico che lavora in JP Morgan a modelli di Machine Learning, all'interno di un team di alcune centinaia di persone...

Se lo sei, allora stai già usando Python. Ma è probabile che tu non abbia mai negoziato un future in vita tua, e che tu non sappia neppure cosa significhi fare trading, perchè semplicemente fai un mestiere differente...

Noi usiamo Easy Language per codificare e testare le nostre di idee di Trading, perchè è un linguaggio che è stato pensato per il TRADER, che è il mestiere che facciamo (e non per un programmatore che ha già alla spalle una certa esperienza), e che ci permette di muoverci all'interno di due piattaforme (TradeStation oppure Multicharts) che sono nate proprio per fare questo, dove puoi scrivere "BUY" senza dover spiegare alla macchina cosa significhi "BUY".

Se pensi che il Core Easy Language sia troppo "limitato" per la sofisticazione dei tuoi modelli, dai un'occhiata a quello che puoi fare con l'Object Oriented Easy Language (...magari non sapevi neppure che esistesse)

In Da Vinci Fintech abbiamo sviluppato le piattaforme Strategy LAB, la Option LAB ed infine Invest Studio proprio per superare i limiti di TradeStation e Multicharts. Su queste piattaforme puoi effettuare in pochi click delle analisi che difficilmente riusciresti a replicare cercando di scrivere qualche script in un qualche linguaggio di programmazione, perchè SONO STATE PENSATE (E PROGRAMMATE) PER FARE QUESTO. E se anche avessi le capacità per farlo, chi ti assicura che siano poi corrette?

E se sei un utilizzatore di queste piattaforme, sai bene che se c'è qualche analisi che ritieni utile e che non trovi già in queste piattaforme, basta dircelo e (...se è sensata) possiamo implementarla! La base degli utilizzatori si amplia, ogni bug che viene segnalato, viene indagato e poi risolto, e se questo significa che la piattaforma diventa sempre più stabile e affidabile, per la Da Vinci Fintech significa poter continuare a investire in nuove funzionalità o nell'usabilità di questi software.

Quindi la domanda finale che vorrei che tu ti facessi è: che mestiere vuoi fare?

Abbiamo scritto questo articolo perchè vediamo sempre più speso persone normali, imbarcarsi in ambiziosi avventure per imparare a programmare in Python (che è il linguaggio che va per la maggiore, ma fino a qualche anno fa avrei potuto dire Matlab o R) e poi alla fine realizzare che si trattava di qualcosa che andava al di là delle proprie capacità, o magari realizzare che alla fine dei conti, loro volevano fare un mestiere diverso.

Volevano semplicemente comprendere, e imparare a USARE quei modelli e non impazzire a cercare di scrivere codice (pieno di bug), per realizzare un'analisi che avrebbero potuto effettuare con un paio di click, su una piattaforma che è stata pensata proprio per questo.

E queste stesse persone, dopo avere speso tempo, denaro ed energie, decidono che è meglio orientarsi ad usare una piattaforma, perchè si fa prima, perchè si commettono meno errori, o pecche semplicemente vogliono tornare a fare il loro lavoro: quello del Trader o dell'Investitore, e non del Programmatore (e lo vediamo di continuo, tutti i giorni...)

Ecco, ora hai qualche elemento in più per decidere che mestiere vuoi fare...

Buon Trading!

PS: nella settimana del Black Friday, fino al 28 novembre, tutte le piattaforme di Da Vinci Fintech sono scontate. Se sei arrivato alla conclusione che questa sia la strada più corretta per te, allora puoi scorrere in basso questa pagina dedicata a tutte le offerte sui Corsi di QTLab e sulle Piattaforme di Da Vinci Fintech.