Sostuituisci la riga 1 con TRUE per consentire di avere più operazioni aperte (in caso di operazioni contrarie credo ci sia un’opzione per consentire l’hedging, non so se direttamente dalla piattaforma ProRealTime o da quella di IG)
DEFPARAM CumulateOrders = True // Posizioni cumulate attivate
poi commenta la linea 38 per evitare l’uscita dai LONG.
Aggiungi questa riga subito dopo la 38 (l’attuale 39 diventerà 40):
SELLSHORT 1 CONTRACT AT MARKET
Però non ci sono chiusure e resteranno aperti all’infinito!
A meno che tu non decida di usare SL e TP per chiuderli.
Grazie Roberto,
ho dovuto fare qualche modifica aggiuntiva però ora va!
Ora vedrò se il caso di continuare a lavorarci o lasciar perder
ROBERTO torno a bussare alla tua porta, scusami.
vorrei capire se possibile creare una variabile che in fase di ottimizzazione mi trovi il miglior orario per operare.
nel codice ho messo questa istruzione
IF time > 140000 and time < 210000 THEN
siamo su un time frame orario, le ore 14 e 21 le ho messe io a naso, ma vorrei sapere se possibile farle cercare al computer tramite una variabile.
Ho provato ma non riesco
Grazie Geronima
Si, è possibile usando delle variabili al posto delle costanti orarie ed usando il Walk Forward, che, alla fine dei vari passaggi del backtest, segnala le combinazioni migliori.
Ho scritto questo codice
DEFPARAM CumulateOrders = false
//IF time >= 140000 and time <= 210000 THEN
IF time >= Inizio and time <= Fine THEN
Tradare = 1
ELSE
Tradare = 0
ENDIF
IF MiaCondizioneLong AND Tradare AND Not OnMarket THEN
BUY AT MARKET
ENDIF
IF MiaCondizioneShort AND Tradare AND Not OnMarket THEN
SELLSHORT AT MARKET
ENDIF
SET TARGET pPROFIT 20
SET STOP pLOSS 20
Tu inseriscilo ed inserisci le due variabili da provare (foto 1), indicando per ciascuna il valore minimo iniziale, quello finale e l’incremento ad ogni passaggio (1 ora). Tieni presente che PRT usa solo variabili numeriche, quindi 090000 diventa 90000 e lo step di un’ora va indicato con 10000 (010000). Attiva il Walk Forward e poi chiudi la finestra. A quel punto clicca per l’esecuzione del backtest con lo stesso pulsante (che avrà in più un’icona che indica l’ottimizzazione da fare).
La foto 2 mosta la finestra, durante l’esecuzione del backtest, che indica i passaggi fatti/da fare.
Infine la foto 3 mostra il risultato, dove ho cerchiato una X che, al passaggio del mouse, segnala le combinazioni per quel risultato (nell’esempio dalle 090000 alle 180000 sembrano siano state le migliori). Manca però l’indicazione dell’efficienza, dove c’è n.d., perché è una strategia stupidissima che non ha senso, è solo per darti un input.
Puoi trovare dettagli e spiegazioni qui (in inglese) https://www.prorealcode.com/blog/learning/prorealtime-walk-analysis-tool/ e qui un video YouTube in francese con Nicolas che ne spiega il funzionamento https://www.youtube.com/watch?v=fiRh0H6ih9s, qui in inglese https://www.prorealcode.com/blog/learning/strategy-optimisation-walk-analysis/.
Alcuni topic di discussione https://www.prorealcode.com/topic/walk-forward-efficiency-ratio/ e https://www.prorealcode.com/topic/walk-forward-analysis/.
CIAO ROBERTO,
ho fatto delle prove e funziona bene l’istruzioni che mi hai scritto.
una domanda:
ho semplificato in questo modo, mi dici se corretto? I risultati sono identici.
IF time >= Inizio and time <= Fine THEN
aggiunto un ENDIF alla fine del codice
e creato le varibili inizio e fine
in pratica ho tolto tradare dal codice….
Geronima
Dal punto di vista funzionale va bene.
Dal punto di vista della forma non è bello racchiudere un’intera strategia all’interno di un blocco IF…ENDIF, non tanto visivamente, quanto può andare a scapito di future necessità di modifiche. Un programmatore non lo farebbe mai! C’è da dire che queste strategie sono brevi, poche decine di righe, per cui si può tollerare. Con centinaia di righe sarebbe una soluzione impossibile da gestire.
Roberto, avendo impostato nel codice degli orari specifici di trading, ho notato delle incongruenze sostanziali operative.
Differenze che emergono in base al fuso orario scelto nelle impostazioni.
Mi spiego meglio, andando a cercare la funzione TIME nel programma di scrittura troviamo scritto: ….L’orario sarà quello della zona oraria ufficiale dello strumento (senza prendere in conto nessuna personalizzazione ai fuso orari)…..
E’ chiaro! sencondo gli sviluppatori di PRT il fuso orario scelto (se modificato) non incide a livello di codice operativo, invece ho notato che non è così!!!
esempio sul dax, imposto orari di trading nel codice in questo modo: IF time >= 110000 and time <= 210000
bene se ho fuso orario UTC+01:00 EUROPA/LONDRA se ci sono le condizioni inizia l’operazione alla barra delle 11
ma anche se ho il fuso orario +02:00 di ROMA inizierà le operazioni alla barra dell 11 come sopra, solamente che in questo caso la barra delle 11 non è più la stessa ma risulta esser la precedente a quella con il fuso impostato su londra. vedi immagini utc+1 e utc+2
Quindi tornando al discordo della funzione TIME che il programma dice che verrà applicata al fuso orario ufficiale dello strumento in questione senza che le personalizzazioni influiscano…a me sembra che questo non sia vero!!!
Quindi come si fa? qual’è il corretto fuso orario da tenere impostato quando si lavora con codici dove ci sono fasce orarie???
Ringrazio
Geronima
Io ho il fuso orario italiano (Utc+2). Il fuso orario puoi settarlo come vuoi, l’orario che vedi in basso sul grafico è solo un’etichetta. Quella stessa candela oraria che tu vedi come 09:00 a New York la vedranno con la scritta 03:00 (Utc-4), mentre a Sydney con la scritta 17:00 (Utc+10), ma si tratta della STESSA candela.
Se vuoi puoi modificare, nelle impostazioni PRT relative all’orari di contrattazione, gli orari ufficiali di contrattazione. Per il DAX io ho indicato l’orario ufficiale dalle 08:00 alle 22:00 (PRT lo vuole in Utc+1, non Utc+2, per cui dovrai mettere dalle 7 alle 21, ma poco importa). La differenza sta nei gap, la mattina alle 8 vedrò il gap rispetto alle 22 della sera precedente ed il lunedì alle 8 il gap rispetto alle 22 del venerdì precedente. Siccome PRT ed IG usano orari di contrattazione estesi, quando lancio (non in backtest) una strategia su TF > 1 ora mi segnala una difformità di orari ed io li ripristino com’erano di default, poi dopo averla lanciata li rimetto come voglio io.
E’ un pò macchinoso ma non è poi tanto scocciante.
Ti allego 3 videate del mio grafico DAX h1 e delle mia impostazioni relative.
chiaro il tuo discorso…..
però il problema segnalto nel mio precedente messaggio rimane li ed imspiegabile non credi?????
Ti mostrato con foto come una strategia cambi in base agli orari scelti…..
se hai utc+1 impostato hai un buy alla candela X
mentre se hai impostato utc+2 lo stesso buy lo avrai alla candela Y.
NON E’ UNA QUESTIONE DI ETICHETTATURA DEGLI ORARI COME DICI, MA E’ PROPRIO LO STESSO SEGNALE OPERATIVO CHE AVVIENE SU UNA BARRA DIFFERENTE
e’ questa cosa che vorrei capire…perchè si verfica (se problema mio, o di codice o di impostazioni) o se invece è un BUG da segnalare ai programmatori di PRT
Se non si riesce a trovar una risposta dovrei abbandonare l’idea di prt e trading sistematico
Grazie saluti
Geronima
vedi come cambia barra il segnale long con impostazioni di fuso orario differente
ho cambiato tre setting nelle impostazioni del fuso orario e come si può vedere LO STESSO LONG è AVVENUTO IN TRE BARRE DIVERSE
ricordo che nel codice è impostato che l’operatività deve partire dalle ora 11
IF time >= 110000 and time <= 210000
Mi spiego meglio, andando a cercare la funzione TIME nel programma di scrittura troviamo scritto: ….L’orario sarà quello della zona oraria ufficiale dello strumento (senza prendere in conto nessuna personalizzazione ai fuso orari)…..
E’ chiaro! sencondo gli sviluppatori di PRT il fuso orario scelto (se modificato) non incide a livello di codice operativo, invece ho notato che non è così!!!
esempio sul dax, imposto orari di trading nel codice in questo modo: IF time >= 110000 and time <= 210000
bene se ho fuso orario UTC+01:00 EUROPA/LONDRA se ci sono le condizioni inizia l’operazione alla barra delle 11
Non saprei, a me non è mai capitata una cosa del genere, anche perché non ho motivo di cambiare il mio fuso orario. Ho fatto la personalizzazione che ti ho detto e funziona benissimo!
Perché delle 3 ipotesi di fusi oari applicabili non selezioni la seconda indicando UTC+2?
cambiare il fuso orario non è un operazione che si fa abitualmente e forse la maggior parte delle persone non lo faranno mai.
Io mi ci sono imbattuta per caso, in quanto in fase di scrittura codice non capivo bene come funzionavano gli orari…..
Resta il fatto che mi sembra chiaro che ci sia qualcosa che non va…..
che cosa consigli di fare?
sarà il caso di segnalare il problema a PRT? come si fa?
Comunque se vuoi vedere bene come funzionano TIME e OPENTIME basta che tu provi queste righe su Dax h1:
graph time
graph opentime
graph currentime
buy at close * 2 limit //buy richiesto da ProOrder
