Python: impariamolo insieme

2000 linee di AFL??? 😱😱😱
guarda... sinceramente non capisco il problema...
se utilizzi barre Daily (se non ho capito male) su Tradestation basta che utilizzi come fonte di input i dati in formato ASCII scaricati da Yahoo (e Federico ti ha già scritto il codice) o altri fornitori (Investing etc)...
Idem per Amibroker...
quindi perché mai dovresti riconvertire?🤔
non ti basta utilizzare i tuoi indicatori/trsys sui software che già utilizzi?🤔

Cia'

PS
TS2000 (che per me era ottimo) non può essere più utilizzato con dati Metastock dal 2020...
MultiCharts è cmq una buona alternativa... 👍🏼👍🏼👍🏼

PS 2
se non sbaglio AFL dovrebbe essere molto simile a Python indipercui non dovresti avere problemi a scrivere codici in tale linguaggo...
e poi c'è sempre FOL ed il gruppo di studio di Scalpo che può darti una mano...
 

Zipline secondo me è una porcheria. Era meglio Quantopian che lo migliorava e lo implementava ma preso "raw" fa schifo. Poi bisogna vedere cosa si debba fare, ci sono librerie ed automatismi per tutto. Infatti per quello non capisco nemmeno io le 2000 righe di codice. O meglio capisco che ne servano 2000 per linguaggi francamente dozzinali e poco ottimizzati per queste materie, ma con Python in poche linee ci fai il mondo. Che poi è il problema anche di C++, linguaggio velocissimo ma non nato per la compattezza e la chiarezza ecco, diventi pazzo. Ma questo tu lo sai molto meglio di me.
 
2000 linee di AFL??? 😱😱😱
guarda... sinceramente non capisco il problema...
se utilizzi barre Daily (se non ho capito male) su Tradestation basta che utilizzi come fonte di input i dati in formato ASCII scaricati da Yahoo (e Federico ti ha già scritto il codice) o altri fornitori (Investing etc)...
Idem per Amibroker...
quindi perché mai dovresti riconvertire?🤔
non ti basta utilizzare i tuoi indicatori/trsys sui software che già utilizzi?🤔

Cia'

PS
TS2000 (che per me era ottimo) non può essere più utilizzato con dati Metastock dal 2020...
MultiCharts è cmq una buona alternativa... 👍🏼👍🏼👍🏼

PS 2
se non sbaglio AFL dovrebbe essere molto simile a Python indipercui non dovresti avere problemi a scrivere codici in tale linguaggo...
e poi c'è sempre FOL ed il gruppo di studio di Scalpo che può darti una mano...

Mi sa che non ci capiamo....

TS2000 è buggato e non più adatto ai sistemi operativi nuovi (può fare errori a caso senza che te ne rendi conto perché non fatto per essere usato con essi), quindi io non me la sento più di usarlo se devo fare un po' di trading con soldi veri.

Amibroker è potente ma ha un linguaggio che ha delle mancanze importanti. Mi veniva da ridere quando vedevo, qua sul fol, anni fa, trading sistem che facevano entrate ed uscite col mitragliatore con quella programmazione matriciale (che non si riusciva mai a capire cosa succedeva su ogni barra), poi, finalmente, hanno messo anche la programmazione di barra in barra come gli altri software di borsa. gli è rimasto ancora qualcosa da aggiustare.


Con Multicharts ci vuole molto meno codice per scrivere qualcosa di importante.
 
Zipline secondo me è una porcheria. Era meglio Quantopian che lo migliorava e lo implementava ma preso "raw" fa schifo. Poi bisogna vedere cosa si debba fare, ci sono librerie ed automatismi per tutto. Infatti per quello non capisco nemmeno io le 2000 righe di codice. O meglio capisco che ne servano 2000 per linguaggi francamente dozzinali e poco ottimizzati per queste materie, ma con Python in poche linee ci fai il mondo. Che poi è il problema anche di C++, linguaggio velocissimo ma non nato per la compattezza e la chiarezza ecco, diventi pazzo. Ma questo tu lo sai molto meglio di me.

2000 righe servivano per trasformare Amibroker in un discreto emulatore di TS2000i, cioè amibroker grazie a questo codice si sarebbe comportato come TS2000.

Tradestation e Amibroker hanno delle importanti differenze nell'eseguire gli ordini. A mio modesto parere Amibroker Lavora in modo errato....

...faccio un esempio:
Amibroker, in fase di backtesting, analizza la barra dello storico e quando si trova sul close della barra (facendo girare il trading system) capisce (a volte sbagliando, perché compera obbligatoriamente senza considerare il concetto di buy/sell Limit o Stop) che doveva entrare su un punto all'interno della barra ed entra a mercato tornando indietro... ...ma è già sul close e non potrebbe andare indietro nel tempo per piazzare l'ordine... ...magari fosse possibile nella realtà andare indietro nel tempo e piazzare l'ordine!

Tradestation invece ragiona così: Ad ogni close fa girare il trading system su questa barra già conclusa e una volta capito cosa fare lancia l'ordine x la prossima barra (ordine che può non andare a mercato perché Tradestation capisce il concetto di buy/sel Limit e Stop).

Se a voi pare poco..........

Con le 2000 righe di codice obbligavo amibroker a girare sul close della barra ed a lanciare sulla barra futura l'opportunità di acquisto vendita Limit o Stop, più avevo ricreato alcune funzioni che mi ricreavano alcune reserved word tipiche di tradestation per semplificarmi la trascrizione dell'easylanguage in AFL.
 
Ultima modifica:
2000 righe servivano per trasformare Amibroker in un discreto emulatore di TS2000i, cioè amibroker grazie a questo codice si sarebbe comportato come TS2000.

Tradestation e Amibroker hanno delle importanti differenze nell'eseguire gli ordini. A mio modesto parere Amibroker Lavora in modo errato....

...faccio un esempio:
Amibroker, in fase di backtesting, analizza la barra dello storico e quando si trova sul close della barra (facendo girare il trading system) capisce (a volte sbagliando, perché compera obbligatoriamente senza considerare il concetto di buy/sell Limit o Stop) che doveva entrare su un punto all'interno della barra ed entra a mercato tornando indietro... ...ma è già sul close e non potrebbe andare indietro nel tempo per piazzare l'ordine... ...magari fosse possibile nella realtà andare indietro nel tempo e piazzare l'ordine!

Tradestation invece ragiona così: Ad ogni close fa girare il trading system su questa barra già conclusa e una volta capito cosa fare lancia l'ordine x la prossima barra (ordine che può non andare a mercato perché Tradestation capisce il concetto di buy/sel Limit e Stop).

Se a voi pare poco..........

Con le 2000 righe di codice obbligavo amibroker a girare sul close della barra ed a lanciare sulla barra futura l'opportunità di acquisto vendita Limit o Stop, più avevo ricreato alcune funzioni che mi ricreavano alcune reserved word tipiche di tradestation per semplificarmi la trascrizione dell'easylanguage in AFL.

si AFL ha quel modo di gestire la barra di ingresso di cui occorre tenere conto nell'implementazione del testing dei TS, come hai fatto tu
però non lo ritengo un errore di amibroker perchè secondo me l'errore concettuale di fondo è che se si opera su di un determinato time frame quello che succede all'interno della singola barra deve essere assolutamente ininfluente, di quella barra sappiamo solo OHLCV non quello che è successo o che succede durante la formazione della barra, se si vule tenere conto di quello che succede dentro la barra bisogna scendere di time frame fin che basta (idealmente fino alle singole operazioni)

Per capirci, se si imposta un TS su time frame daily i segnali nella realtà si hanno disponibili solo a barra conclusa e gli ordini operativi devono essere immessi per il giorno successivo, se si immettono delle condizionalità per l'esecuzione di questi ordini che per forza di cose dipendono da cosa succede all'interno della giornata di contrattazione, non si opera più con TF daily, ma su un TF inferiore (per essere pignoli, si opera sul flusso degli ordini e degli eseguiti) e di questo occorre tenerne conto durante le simulazioni.


Si può tenerne conto in vari modi:
il più preciso sarebbe acquisire il segnale sul TF che si preferisce e simulare l'esecuzione degli ordini conseguenti a questo segnale su TF inferiori o tick by tick (simulando in sostanza quello che si fa effettivamente nella realtà)
oppure prendere come prezzo di riferemento un prezzo standard della barra di ingresso ( l' Open, il Close, il medio, oppure anche l' Hi o il Low se si vuole simulare la peggior esecuzione)
oppure immettere delle condizioni univoche che non dipendono dall'evoluzione della barra ( es compra al prezzo x, si può ritenere valido se il prezzo è all'inteno della barra)

sui TF inferiori al giornaliero, in cui il flusso delle barre è continuo, bisogna anche tenere conto nelle simulazioni (e nella realtà) del ritardo che intercorre tra l'acquisizione del segnale operativo e il momento in cui esso può materialmente essere messo in pratica, se il segnale è alla definizione della barra n non è detto che possa generare effetti sulla barra n+1 che parte immediatamente dopo la barra n, quando ancora il segnale e l'operazione conseguente è ancora in elaborazione.
 
Amibroker, in fase di backtesting, analizza la barra dello storico e quando si trova sul close della barra (facendo girare il trading system) capisce (a volte sbagliando, perché compera obbligatoriamente senza considerare il concetto di buy/sell Limit o Stop) che doveva entrare su un punto all'interno della barra ed entra a mercato tornando indietro... ...ma è già sul close e non potrebbe andare indietro nel tempo per piazzare l'ordine... ...magari fosse possibile nella realtà andare indietro nel tempo e piazzare l'ordine!

Amibroker è inizialmente un incubo per chi arriva da Tradestation, ma bisogna semplicemente “disimparare” quello che si è applicato su TS2000i , ed adattarsi al modo in cui ragiona lui (se si vuole usarlo, ovviamente).

Perchè AMB ragiona di default per array e non barra per barra.

Faccio un esempio, compra al massimo delle ultime 25 barre, con ordine stop sulla NEXT BAR;

Tradestation:
Channelbuy = Highest (H,25);
Buy next bar ChannelBuy stop;

Amibroker:
Channelbuy = Ref( HHV( High, 25 ), -1 );
Buy = H > channelbuy;
BuyPrice = Max (Open, Channelbuy);

Quindi si, ci vuole 1 riga in più per simulare un ordine STOP, ma non 2000.

Questo perché BUY in AMB è "solo" un array di 0 e 1, ti dice solo se sulla barra c’è stato un segnale , non ti dice nulla del prezzo a cui è stato eseguito quel segnale, per quello usi la funzione “Buyprice”.

La vera differenza tra AMB e TS (come dice Guglielmo) è che AMB permette generalmente un solo segnale a barra, perché Tomasz Janezko non accetta di fare supposizioni su come si sono sviluppati i prezzi all’interno della barra (se gli fai notare che per te è un problema , ti consiglia di usare timeframe inferiori) e questa cosa è superabile solo se si usa il custom backtester e si è programmatori molto bravi (o si assume qualcuno in India…).

Per il resto, pensare di fare da zero su Python perché Multicharts costa 1500 USD mi pare un’altra stranezza. Delle tre l’una
- O siete programmatori provetti in Phyton;
- O valutate ZERO il vostro tempon impiegato a partire da zero con Phyton
- Oppure vi accorgete in fretta che spendere 1500 USd su multichart è asoslutamente meglio che non spendere nulla ed impazzire su Python, se va bene per qualche mese, se va male per anni, se va malissimo… per sempre senza ottenere niente di realmente funzionante.
 
Amibroker è inizialmente un incubo per chi arriva da Tradestation, ma bisogna semplicemente “disimparare” quello che si è applicato su TS2000i , ed adattarsi al modo in cui ragiona lui (se si vuole usarlo, ovviamente).

Amibroker è un software che ti fa sbagliare, involontariamente, a fare i Trading System (= TS da ora) e, la cosa più grave, è che non ti fa capire che il TS non fa quello che pensi tu... ...a meno che non hai letto tutto il manuale e sei ben conscio di come lavora.


Perchè AMB ragiona di default per array e non barra per barra.
Lavorare x array è bellissimo per cose semplicissime e ripetitive.
Con gli array ti basta poco codice (x queste cose semplici).
Il problema arriva quando in una barra (o in ogni barra), un TS, deve fare delle scelte condizionate fra un multiplo di opzioni... ...e qui incominciano i dolori, scrivere una riga di codice, che lavora x array, che tenga conto delle della serie di opzioni barra x barra... ...è impossibile! ...e per questo che anni fa Tomasz Janezko fu subissato di richieste x implementare il modo di scrivere il codice barra x barra e non per array. Naturalmente, Tomasz Janezko è solo orgoglioso del suo metodo di programmazione x array.


Faccio un esempio, compra al massimo delle ultime 25 barre, con ordine stop sulla NEXT BAR;

Tradestation:
Channelbuy = Highest (H,25);
Buy next bar ChannelBuy stop;

Amibroker:
Channelbuy = Ref( HHV( High, 25 ), -1 );
Buy = H > channelbuy;
BuyPrice = Max (Open, Channelbuy);

Quindi si, ci vuole 1 riga in più per simulare un ordine STOP, ma non 2000.

Questo perché BUY in AMB è "solo" un array di 0 e 1, ti dice solo se sulla barra c’è stato un segnale , non ti dice nulla del prezzo a cui è stato eseguito quel segnale, per quello usi la funzione “Buyprice”.

2000 righe servivano anche a dare la precedenza dei vari ordini (o stop loss) che c'erano su una barra in stile tradestation (è per questo che dico che era un emulatore).
Se tu sei a mercato e su una certa barra scatta sia il take profit che lo stop loss, AMB fa l'operazione che incontra prima mentre legge il codice. TS2000 non fa così, li mette in ordine in base al time frame originario della banca dati o simula un certo movimento all'interno della barra (se lo storico non ha un time frame inferiore).


La vera differenza tra AMB e TS (come dice Guglielmo) è che AMB permette generalmente un solo segnale a barra, perché Tomasz Janezko non accetta di fare supposizioni su come si sono sviluppati i prezzi all’interno della barra (se gli fai notare che per te è un problema , ti consiglia di usare timeframe inferiori) e questa cosa è superabile solo se si usa il custom backtester e si è programmatori molto bravi (o si assume qualcuno in India…).

...e sì, è così.


Per il resto, pensare di fare da zero su Python perché Multicharts costa 1500 USD mi pare un’altra stranezza. Delle tre l’una
- O siete programmatori provetti in Phyton;
- O valutate ZERO il vostro tempon impiegato a partire da zero con Phyton
- Oppure vi accorgete in fretta che spendere 1500 USd su multichart è asoslutamente meglio che non spendere nulla ed impazzire su Python, se va bene per qualche mese, se va male per anni, se va malissimo… per sempre senza ottenere niente di realmente funzionante.

D'accordissimo.
Si deve tener presente che multicharts lo puoi installare su tutti i PC che vuoi (ma solo un PC alla volta deve avere il programma collegato on-line),
poi ti danno a vita sempre l'ultima versione, quindi tu ottieni continuamente il programma sempre nuovo al di là del lavoro che loro hanno perso per fare continuamente nuove versioni senza spendere niente (è un lavoro gratuito che ti sarà dato a vita)... ...almeno così ho sentito da un filmato di youtube.
Poi, pare che a volte fanno scontistiche grosse anche del 30% (black friday per es. ...sempre secondo il video di youtube)
 
Ultima modifica:
Per il resto, pensare di fare da zero su Python perché Multicharts costa 1500 USD mi pare un’altra stranezza. Delle tre l’una
- O siete programmatori provetti in Phyton;
- O valutate ZERO il vostro tempon impiegato a partire da zero con Phyton
- Oppure vi accorgete in fretta che spendere 1500 USd su multichart è asoslutamente meglio che non spendere nulla ed impazzire su Python, se va bene per qualche mese, se va male per anni, se va malissimo… per sempre senza ottenere niente di realmente funzionante.

Io sono ottimista: se hai già altri sistemi che funzionano per conto loro, con la forza di un gruppo di studio tenace, ci AFFIANCHI Python, e nel giro di qualche mese ti si potranno spalancare panorami validi sia dal punto di vista trading (per chi fa solo trading) sia da un punto di vista lavorativo (per chi lavora), senza sacrificare troppo i propri "flussi di cassa" che servono per vivere. Python (a differenza di Multichart, Tradestation, MT5 etc, che sono ambienti di sviluppo fini a se stessi) è infatti uno skill in grado di motorizzare opportunità da sfruttare anche in ambito lavorativo/professionale.

Parola d'ordine: lavorare, lavorare, lavorare a testa bassa: esperienza mi insegna che si fa prima a fare che a dire.
 
Ultima modifica:
Non ho capito cosa usate in Python per fare backtest seri e accurati.

Concordo con Imar: la scelta di farsi tutto in casa non può essere dettata da esigenze di risparmio quando parliamo da un lato di fare trading e dall'altro di spendere €1.500... Se quest'ultima spesa è utile, il costo si recupera in un attimo coi profitti.
 
Non ho capito cosa usate in Python per fare backtest seri e accurati.

interrogazione di database con dati tick.


Concordo con Imar: la scelta di farsi tutto in casa non può essere dettata da esigenze di risparmio quando parliamo da un lato di fare trading e dall'altro di spendere €1.500... Se quest'ultima spesa è utile, il costo si recupera in un attimo coi profitti.

chi volesse usare Multichart.net (richiesta conoscenza almeno di C#) senza spendere: Multichart.NET special edition (gratuita a vita)

altra possibilità efficiente e gratis: The Zorro Project (che in questo forum mi sembra lo conosciamo solo io e @federicoJuvarra)

Chiaro che, per chi intenda ampliare le proprie analisi in ambito quant, in caso di successo ed in caso di trading frequente, le piattaforme offerte dai vari broker gli serviranno solo in fase di order-execution/controlling/monitoring: siano esse Multichart, MT5, o quello che più gli aggrada. Secondo me Python non dovrebbe essere usato come sostituto della piattaforma (sebbene possa in teoria farlo, integrato a buone API), casomai la integra.

concludendo, personalmente: 1500€ preferisco investirli in dati a pagamento di buona qualità.
 
Ultima modifica:
interrogazione di database con dati tick.
No, mi riferisco a tutto ció che serve a creare ordini con le loro regole, a gestire lo stato del portafoglio e l'interazione tra gli ordini e il mercato simulato.

Quello che fa il "context manager" della Zipline, per capirci, invece che vettorizzare una serie di posizioni accese/spente sulle candele dei titoli.
 
No, mi riferisco a tutto ció che serve a creare ordini con le loro regole, a gestire lo stato del portafoglio e l'interazione tra gli ordini e il mercato simulato.

Quello che fa il "context manager" della Zipline, per capirci, invece che vettorizzare una serie di posizioni accese/spente sulle candele dei titoli.

Zipline, da neofita in Python che sono, non lo conosco ancora.

Per lo scopo da te indicato ho però una soluzione alquanto articolata ma che taglia la testa al toro. Ho iniziato a parlarne nel gruppo Telegram, a causa della sua complessità lo approfondiremo più avanti. Naturalmente dopo aver valutato i pro e contro con altre soluzioni disponibili che ci impediscano di reinventare la ruota.
Naturalmente, nel caso avessi voglia/tempo, ti invito a contattarmi, saremo ben lieti di confrontarci in tale sede. OK!
 
valutate di aprire con Tradestation Global, è IB con la Tradestation gratis, dati IB e mi sembra no inactivity fees

E’ un a buona soluzione se non fai troppe operazioni (Tradestation global è introducing broker di IB, paghi il software con un piccolo mark up, che per un trader attivo a fine mese “conta”) e se non ti interessa il trading automatico ( è da due anni che dicono faranno l’API apposita. ma la sensazione è che non gli convenga cannibalizzare al 100% la casa madre Tradestation US).


Lavorare x array è bellissimo per cose semplicissime e ripetitive.
Il problema arriva quando in una barra (o in ogni barra), un TS, deve fare delle scelte condizionate fra un multiplo di opzioni... ...e qui incominciano i dolori, scrivere una riga di codice, che lavora x array, che tenga conto delle della serie di opzioni barra x barra... ...è impossibile! ...

No, non è impossibile, è … complesso perché non è l’impostazione di default.

Guarda, io ho tuttora – dopo tanti anni - un rapporto di amore ed odio con AMB, però da come parli si capisce che non conosci il software abbastanza per dare giudizi.

Con AMB non sei obbligato a lavorare per array.

Puoi racchiudere tutto il tuo codice in un ciclo FOR… NEXT ed anche AMB lavora barra per barra, anche se così si rallenta l’esecuzione e questo a molti programmatori non piace.

Del resto, tutto il nostro codice di TS2000i è dentro un gigantesco FOR … NEXT, solo che noi non lo vediamo perchè è impostato di default.

In generale, penso che sia sbagliato dare classifiche, dipende da quello che vuoi fare. Ad esempio, AMB è molto potente quando vuoi filtrare i segnali nuovi in base ai vecchi. Il “last trade loser filter” che è un complicato da ottenere in TS2000i, è questione di una riga in AMB.

Altro esempio: testare un portafoglio, che è tuttora laborioso su MC, perché PortfolioTrader è arrivato MOLTO DOPO e si vede, mentre AMB è stato quasi da subito programmato con una logica multimarket.

Invece per converso, se applichi in sistema di trading in tempo reale non hai su AMB in automatico i segnali come su MC, devi programmare un indicatore ad hoc o un explorer. Se poi vuoi fare trading automatico su AMB rischi di nuovo gli incubi perchè ti devi programmare tutto a mano, mentre su MC basta un click di mouse. L’assistenza su MC è discreta, mente su AMB… lasciamo perdere.

Insomma, come ogni cosa della vita… pro e contro….


Se tu sei a mercato e su una certa barra scatta sia il take profit che lo stop loss, AMB fa l'operazione che incontra prima mentre legge il codice. TS2000 non fa così, li mette in ordine in base al time frame originario della banca dati o simula un certo movimento all'interno della barra (se lo storico non ha un time frame inferiore).

Si, ma in generale – con qualunque software – lo STOP take profit e lo STOP loss su stessa barra va sempre usato con cautela, se non sai lo sviluppo intrabar dei prezzi. Che dici, vogliamo parlare delle stupidaggini del “SET_TRAILING” di TS 2000i?

Anch’io ero affezionato alle convenzioni di TS2000i, però ho poi scoperto che sono solo – appunto – ipotesi di lavoro, per cui se vuoi un back testing efficiente devi avere attivo il “look inside bar” che è equivalente a testare su time frame inferiori. Non se ne esce…………

E per finire un piccolo warning: da sempre , in particolari circostanze, MC e TS2000i danno risultati di testing diversi, pur a parità di codice e dati. Non se ne esce, devo conoscere il tuo software, è quello il vero investimento che fai, il tempo che ci vuole ad apprenderlo.

Io sono ottimista: se hai già altri sistemi che funzionano per conto loro, con la forza di un gruppo di studio tenace, ci AFFIANCHI Python, e nel giro di qualche mese ti si potranno spalancare panorami validi sia dal punto di vista trading (per chi fa solo trading) sia da un punto di vista lavorativo (per chi lavora), senza sacrificare troppo i propri "flussi di cassa" che servono per vivere. Python (a differenza di Multichart, Tradestation, MT5 etc, che sono ambienti di sviluppo fini a se stessi) è infatti uno skill in grado di motorizzare opportunità da sfruttare anche in ambito lavorativo/professionale.

Questo è un altro discorso, se uno vuole ANCHE imparare phyton per il suo diletto o per il suo lavoro, va bene.

Solo anche così, non è il caso di reinventare la ruota, esistono tanti backtester in phyton, ad esempio:
georgepruitt (George Pruitt) * GitHub

Sul resto, ognuno si deve fare i conti in tasca, se 1500 USD valgono per voi qualche mese di attesa, nulla quaestio. A me suona strano , ma nulla quaestio.

Se quest'ultima spesa è utile, il costo si recupera in un attimo coi profitti.

Il costo si recupera in un attimo anche se non ci sono profitti, perchè ti libera il tuo tempo per fare altro.
Poi, ognuno la vede come vuole, è chiaro che il costo opportunità di un imprenditore è un pò diverso da quello di un pensionato.
 
altra possibilità efficiente e gratis: The Zorro Project (che in questo forum mi sembra lo conosciamo solo io e @federicoJuvarra)

Non è gratis se non per conticini insignificanti.

Ed io preferisco spendere XXX Euto una tantum che 35 Euro al mese per tutta la vita

Come sempre, sono scelte personali.


MC.NET non è usato perchè con MC classic fai il 95% di quello che fa Mc.NET, e con una semplicità di programmazione non paragonabile.
Se un software non sfonda, è perchè c'è un motivo, poi se preferite pensare che siamo tutti distratti..... ok..... non importa.
 
Amibroker è inizialmente un incubo per chi arriva da Tradestation, ma bisogna semplicemente “disimparare” quello che si è applicato su TS2000i , ed adattarsi al modo in cui ragiona lui (se si vuole usarlo, ovviamente).

Perchè AMB ragiona di default per array e non barra per barra.

Faccio un esempio, compra al massimo delle ultime 25 barre, con ordine stop sulla NEXT BAR;

Tradestation:
Channelbuy = Highest (H,25);
Buy next bar ChannelBuy stop;

Amibroker:
Channelbuy = Ref( HHV( High, 25 ), -1 );
Buy = H > channelbuy;
BuyPrice = Max (Open, Channelbuy);

Quindi si, ci vuole 1 riga in più per simulare un ordine STOP, ma non 2000.

Questo perché BUY in AMB è "solo" un array di 0 e 1, ti dice solo se sulla barra c’è stato un segnale , non ti dice nulla del prezzo a cui è stato eseguito quel segnale, per quello usi la funzione “Buyprice”.

La vera differenza tra AMB e TS (come dice Guglielmo) è che AMB permette generalmente un solo segnale a barra, perché Tomasz Janezko non accetta di fare supposizioni su come si sono sviluppati i prezzi all’interno della barra (se gli fai notare che per te è un problema , ti consiglia di usare timeframe inferiori) e questa cosa è superabile solo se si usa il custom backtester e si è programmatori molto bravi (o si assume qualcuno in India…).

Per il resto, pensare di fare da zero su Python perché Multicharts costa 1500 USD mi pare un’altra stranezza. Delle tre l’una
- O siete programmatori provetti in Phyton;
- O valutate ZERO il vostro tempon impiegato a partire da zero con Phyton
- Oppure vi accorgete in fretta che spendere 1500 USd su multichart è asoslutamente meglio che non spendere nulla ed impazzire su Python, se va bene per qualche mese, se va male per anni, se va malissimo… per sempre senza ottenere niente di realmente funzionante.
Con Python sei flessibile, spendi tempo per imparare ma puoi implementare dal cross di medie mobili al trading ad alta frequenza istituzionale. Con un programma blackbox sei limitato ad un linguaggio specifico poco usato e limitato nelle funzioni. Spendi soldi e quello puoi fare (analisi tecnica), nulla più. Sei pure dipendente dall'azienda stessa che se il programma non viene più aggiornato devi ricominciare da capo.
 
Non ho capito cosa usate in Python per fare backtest seri e accurati.

Concordo con Imar: la scelta di farsi tutto in casa non può essere dettata da esigenze di risparmio quando parliamo da un lato di fare trading e dall'altro di spendere €1.500... Se quest'ultima spesa è utile, il costo si recupera in un attimo coi profitti.
Se fai machine learning lo sai già te meglio di me, nel test è implicito un backtest. Non è realistico? Certo, ma ti da le percentuali di accuratezza e la precisione. Se vuoi passare a sistemi più realistici a parer mio backtrader e Quantrocket sono il meglio disponibile, anche se nulla di trascendentale. Oppure piattaforma Quantconnect.
Per il resto, cioè gestione ordini ecc. usi l'API del broker scelto.
 
No, non è impossibile, è … complesso perché non è l’impostazione di default.

Guarda, io ho tuttora – dopo tanti anni - un rapporto di amore ed odio con AMB, però da come parli si capisce che non conosci il software abbastanza per dare giudizi.

Con AMB non sei obbligato a lavorare per array.

Puoi racchiudere tutto il tuo codice in un ciclo FOR… NEXT ed anche AMB lavora barra per barra, anche se così si rallenta l’esecuzione e questo a molti programmatori non piace.

Sì, lo so.
Io ho fatto così quando lo usavo.


Del resto, tutto il nostro codice di TS2000i è dentro un gigantesco FOR … NEXT, solo che noi non lo vediamo perchè è impostato di default.

Sì, lo so.
L'easylanguage "nasconde" molte cose.

In generale, penso che sia sbagliato dare classifiche, dipende da quello che vuoi fare. Ad esempio, AMB è molto potente quando vuoi filtrare i segnali nuovi in base ai vecchi. Il “last trade loser filter” che è un complicato da ottenere in TS2000i, è questione di una riga in AMB.


Altro esempio: testare un portafoglio, che è tuttora laborioso su MC, perché PortfolioTrader è arrivato MOLTO DOPO e si vede, mentre AMB è stato quasi da subito programmato con una logica multimarket.
Non sono arrivato a queste cose... ..non le ho mai usate.


E per finire un piccolo warning: da sempre , in particolari circostanze, MC e TS2000i danno risultati di testing diversi, pur a parità di codice e dati. Non se ne esce, devo conoscere il tuo software, è quello il vero investimento che fai, il tempo che ci vuole ad apprenderlo.

Lo so! ...mannaggia, secondo me lo fanno apposta! ...non ti sarà mai dato il software perfetto.
 
Se fai machine learning lo sai già te meglio di me, nel test è implicito un backtest. Non è realistico? Certo, ma ti da le percentuali di accuratezza e la precisione. Se vuoi passare a sistemi più realistici a parer mio backtrader e Quantrocket sono il meglio disponibile, anche se nulla di trascendentale. Oppure piattaforma Quantconnect.
Per il resto, cioè gestione ordini ecc. usi l'API del broker scelto.
Ok, spiego meglio cercando di usare un po' di astrazione di programmazione.

Una architettura di backtest "seria" è composta da almeno tre elementi modellati come oggetti indipendenti all'interno del programma:
  1. un manager di portafoglio che si occupa unicamente di tenere il mark-to-market delle posizioni, aggiornare i prezzi di carico, valutare quanta liquidità è disponibile per poter fare le operazioni etc. etc. Questo oggetto prende dentro degli ordini eseguiti a mercato prima di aggiornare le posizioni ed è colui che poi si occuperà anche di produrre tutta la reportistica sui risultati finali. Inoltre gli si può demandare di tenere anche traccia degli ordini a mercato ancora aperti oppure delegare all'attore qui sotto;
  2. un generatore di ordini basato sulla tripletta [indicatori, regole, segnali]. Gli indicatori non vanno ovviamente intesi come quelli di analisi tecnica ma in generale come qualsiasi oggetto indicizzato al tempo in grado di definire una regola. Gli indicatori definiscono regole e le regole generano segnali che a loro volta producono ordini di vario tipo con varie condizioni. Attenzione che un ordine può avere al suo interno anche l'istruzione di cancellare un altro set di ordini già a mercato;
  3. un simulatore del mercato, ovvero qualcosa che ricostruisca le condizioni del mercato in ogni istante in cui è suddiviso il backtest e che soprattutto definisca in che modo gli ordini generati interagiscono col mercato simulato. Quindi qua non è necessario avere una OHLC: puoi anche avere per assurdo dei tracciati FIX, l'importante è che riesci a ricostruire come era il mercato in quel momento.
Dopodiché l'interazione di questi tre oggetti avviene all'interno di un gigantesco ciclo che passa attraverso i giorni e le ore di interesse: in ogni istante oggetto di backtest, si innescano le interazioni tra gli attori lì sopra. Gli oggetti di cui sopra sono ovviamente istanziati "out of scope" in modo da poter essere aggiornati ad ogni iterazione e a tenere traccia dei cambiamenti di stato (tranne la fotografia del mercato che invece per sicurezza può essere anche creata "in scope").

Zipline ha una logica del genere, anche con diverse semplificazioni e i suoi bei difetti; quantstrat in R ci prova a fare una cosa del genere con tutti i suoi limiti.

Quindi la mia domanda è: esistono alternative migliori in Python in modo da non essere costretti a reinventare la ruota e senza dover fare le odiose e irrealistiche vettorizzazioni?
 
Con Python sei flessibile, spendi tempo per imparare ma puoi implementare dal cross di medie mobili al trading ad alta frequenza istituzionale. Con un programma blackbox sei limitato ad un linguaggio specifico poco usato e limitato nelle funzioni. Spendi soldi e quello puoi fare (analisi tecnica), nulla più. Sei pure dipendente dall'azienda stessa che se il programma non viene più aggiornato devi ricominciare da capo.


Achievable things in AB (using a tiny bit of imagination) | Unofficial AmiBroker Forum (the most proficient 3rd party one)
 
Indietro