Aiuto brekout max della signal bar

• 05/28/2018 at 3:34 PM #71521
  robertogozzi

  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

  1	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

  1	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.

   

   

  

  robertogozzi

  Moderator

  Topics: 69

  Replies: 16469

  Been thanked: 3643 times
  05/28/2018 at 6:19 PM #71525
  Geronima Ortiz

  Grazie Roberto,

  ho dovuto fare qualche modifica aggiuntiva però ora va!

  Ora vedrò se il caso di continuare a lavorarci o lasciar perder

  

  Geronima Ortiz

  Participant

  Topics: 6

  Replies: 58

  Been thanked: 1 time
  05/30/2018 at 10:12 PM #71743
  Geronima Ortiz

  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

   

  

  Geronima Ortiz

  Participant

  Topics: 6

  Replies: 58

  Been thanked: 1 time
  05/31/2018 at 12:52 AM #71745
  robertogozzi

  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

  Strategia di prova per Walk Forward

  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

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

  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/.

   

  1 user thanked author for this post.

  Nicolas

  

  robertogozzi

  Moderator

  Topics: 69

  Replies: 16469

  Been thanked: 3643 times
  05/31/2018 at 3:48 AM #71750
  Geronima Ortiz

  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

  

  Geronima Ortiz

  Participant

  Topics: 6

  Replies: 58

  Been thanked: 1 time
  05/31/2018 at 8:34 AM #71819
  robertogozzi

  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.

  

  robertogozzi

  Moderator

  Topics: 69

  Replies: 16469

  Been thanked: 3643 times
  05/31/2018 at 5:35 PM #71884
  Geronima Ortiz

  ho capito grazie.

  

  Geronima Ortiz

  Participant

  Topics: 6

  Replies: 58

  Been thanked: 1 time
  06/01/2018 at 12:31 AM #71902
  Geronima Ortiz

  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

  

  Geronima Ortiz

  Participant

  Topics: 6

  Replies: 58

  Been thanked: 1 time
  06/01/2018 at 11:22 AM #71930
  robertogozzi

  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.

   

  

  robertogozzi

  Moderator

  Topics: 69

  Replies: 16469

  Been thanked: 3643 times
  06/01/2018 at 1:49 PM #71945
  Geronima Ortiz

  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

  

  Geronima Ortiz

  Participant

  Topics: 6

  Replies: 58

  Been thanked: 1 time
  06/01/2018 at 2:23 PM #71949
  Geronima Ortiz

  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

   

  

  Geronima Ortiz

  Participant

  Topics: 6

  Replies: 58

  Been thanked: 1 time
  06/01/2018 at 2:34 PM #71954
  robertogozzi

  Geronima Ortiz wrote:

  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!

   

   

  

  robertogozzi

  Moderator

  Topics: 69

  Replies: 16469

  Been thanked: 3643 times
  06/01/2018 at 2:38 PM #71955
  robertogozzi

  Perché delle 3 ipotesi di fusi oari applicabili non selezioni la seconda indicando UTC+2?

  

  robertogozzi

  Moderator

  Topics: 69

  Replies: 16469

  Been thanked: 3643 times
  06/01/2018 at 2:41 PM #71957
  Geronima Ortiz

  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?

  

  Geronima Ortiz

  Participant

  Topics: 6

  Replies: 58

  Been thanked: 1 time
  06/01/2018 at 3:42 PM #71966
  robertogozzi

  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

  1 2 3 4

  graph time graph opentime graph currentime buy at close * 2 limit //buy richiesto da ProOrder

  

  robertogozzi

  Moderator

  Topics: 69

  Replies: 16469

  Been thanked: 3643 times
• Author
  Posts