Organizzazione del ciclo dell'ordine - pagina 2
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Perché il prezzo si muoverà, e ad ogni nuova chiamata a OnTick, la condizione per una nuova modifica dello stesso ordine, il primo della lista, sarà soddisfatta. Soprattutto se la modifica durerà 5 secondi ;)
Di nuovo, si tocca la questione della pertinenza. Un ordine sarà sempre aggiornato. Gli altri saranno aggiornati, se possibile. La tua variante, d'altra parte, è tutti gli ordini non aggiornati.
Una tale "spina dorsale" romperebbe la logica di un EA che lavora con più di un ordine.
Che senso avrebbe se non desse alcun vantaggio ai sistemi con un ordine e rovinasse il resto?
Mi piacerebbe capire cosa vuoi dire, ma non ci riesco. Non vedo il problema con il principio "se il tempo di attesa è passato, aggiorna l'ambiente di trading".
Ordinare per volume e/o distanza dal prezzo prima di trattare gli ordini è la cosa giusta da fare. Ma non dobbiamo dare per scontato che tutti quelli che copiano il codice dal forum lo implementino.
In questo senso, il mio codice è più sicuro.
Beh, non è stato scritto per i neofiti. Noi due ne discutiamo molto bene qui: niente acqua.
Ancora una volta viene sollevata la questione della rilevanza. Un ordine sarà sempre aggiornato. Gli altri saranno aggiornati, se possibile. La tua opzione è che tutti gli ordini non sono aggiornati.
Reale - di quanto?
Sono felice di capire quello che vuoi dire, ma non funziona. Non vedo un problema con il principio "se il tempo di attesa è passato, aggiorna l'ambiente di trading".
Il tuo algoritmo è fissato sul primo ordine della lista, tutto qui.
In alcune situazioni questo può essere dannoso per il sistema (l'ho incontrato nella pratica).
Reale - di quanto?
Nel mio scenario, entrambi gli SL sarebbero stati modificati a 1,2375 o al peggio a 1,2374. Linea di fondo: +30 pip su entrambi gli ordini.
Ad ogni passo del tuo esempio il TS dovrebbe sapere dove dovrebbero essere i suoi ordini senza alcun ordine di compravendita. Cioè il TS non può essere attaccato in alcun modo a dove sono i suoi ordini ora. Si occupa solo di calcolare dove dovrebbero stare e di sincronizzare l'ambiente di trading con quello che ha calcolato attraverso gli ordini di compravendita.
Nel tuo esempio, però, il risultato del TS dipende dal fatto che OnTick sia arrivato o meno al prezzo alto. E il TS corretto dovrebbe essere esattamente all'altezza. Vede che tale prezzo è stato (anche se l'OnTick con esso è stato mancato), e quindi i suoi SL dovrebbero essere posizionati di conseguenza. E la sincronizzazione farà il suo lavoro al 100%.
E non capisco perché continui a dire che il secondo è fermo. Anche senza logica di sincronizzazione, sarà comunque modificato come nella vostra variante. Non è come se OnTick fosse chiamato sull'evento NewTick, ma come una normale funzione interna.
Ad ogni passo del tuo esempio il TS ha bisogno di sapere dove dovrebbero essere i suoi ordini senza alcun ordine di compravendita. Cioè, il TS non può essere legato in alcun modo a dove si trovano ora gli ordini. Si occupa solo di calcolare dove dovrebbero stare e di sincronizzare l'ambiente di trading con quello che ha calcolato attraverso gli ordini di compravendita.
Lo fa, lo sa. Ma non ha il tempo di sincronizzarlo - mentre una modifica sta passando, il prezzo si muove ulteriormente e una nuova condizione calcolata le dice di modificare nuovamente il primo ordine. E questo accade di continuo.
Nel tuo esempio, il risultato di TC dipende dal fatto che OnTick sia arrivato al prezzo alto o meno. E il TS corretto dovrebbe essere esattamente prima. Vede che tale prezzo è stato (anche se l'OnTick con esso è stato mancato), il che significa che i suoi SL dovrebbero essere posizionati di conseguenza. E la sincronizzazione farà il suo lavoro al 100%.
Non lo fa (nell'esempio non c'era il calcolo del livello SL).
E la sincronizzazione non farà il lavoro, perché non avrà tempo (vedi sopra).
E non capisco perché continui a dire che il secondo sta fermo. Anche senza logica di sincronizzazione, sarà comunque modificato come nella vostra variante. Non è come se OnTick fosse chiamato sull'evento NewTick, ma come una normale funzione interna.
Come al solito, l'ho capito.
Tuttavia, il prezzo è già cambiato mentre il processo di modifica è in corso e la chiamata forzata di OnTick funziona già con il nuovo prezzo, mentre il secondo ordine rimane al suo livello iniziale.
Non c'è nessun errore. Forse troppo specifico per la tua (ma di nuovo, abbastanza reale, dalla vita) situazione.
Lo fa, lo sa. Ma non ha tempo per sincronizzarsi - mentre passa una modifica, il prezzo si muove ulteriormente, e la nuova condizione calcolata gli dice di modificare nuovamente il primo ordine. E questo accade di continuo.
L'esempio che avete inventato non ci dà ulteriori perdite considerando questa logica. Ora vi faccio un esempio.
Supponiamo di tracciare BuyLimits dopo il movimento verso l'alto per aprire al pullback necessario. Quasi Lucky-TC. Se trasciniamo una montagna di Limiti ogni volta, non prenderemo un pullback con la tua opzione.
Beh, è strano dare ordini di trading basati su un ambiente di trading obsoleto. Ma lei si ostina (come me) a difendere un punto di vista diverso.
Beh, è strano dare ordini commerciali basati su un ambiente commerciale obsoleto. Ma lei si ostina (come me) a difendere un punto di vista diverso.
Bisogna scegliere il male minore.
Naturalmente, l'esempio con il limite che si estende dietro il prezzo è meglio da implementare nella variante "1 EA = 1 ordine in ogni direzione".
Ma in generale è meglio tenere sotto controllo tutti gli ordini.
Ma in generale è più corretto tenere sotto controllo tutti gli ordini.
Cioè, non siete d'accordo con il requisito che il TS funzioni solo con l'ambiente commerciale attuale.
Cioè, non siete d'accordo con il requisito che il TS funzioni solo con l'attuale ambiente di trading.
Se dovete sacrificare il controllo di tutti gli ordini di TC per farlo - assolutamente.
Immaginate: avete una flotta di quattro camion. Ognuno di loro trasporta un carico prezioso dal punto A al punto B. È necessario monitorare il percorso.
Cosa preferiresti: essere in contatto ogni minuto con uno di loro o ogni 2 minuti con tutti?
Nel secondo caso, il ritardo sarà leggermente più lungo, e tutti e quattro potrebbero dover fare una leggera deviazione se non li instradi in tempo. Ma nel complesso sarà meglio per il business che avere un camion e perdere gli altri tre.
Se dovete sacrificare il controllo di tutti gli ordini di TC per farlo, assolutamente.
Immaginate: avete una flotta di 4 camion. Ognuno di loro trasporta un carico prezioso dal punto A al punto B. È necessario controllare il percorso.
Preferiresti essere in contatto ogni minuto con uno di loro, o ogni 2 minuti con tutti?
Nel secondo caso, il ritardo sarà leggermente più lungo, e tutti e quattro potrebbero dover fare una leggera deviazione se non riuscite a instradarli in tempo. Ma nel complesso sarà meglio per gli affari che spendere un camion e perdere gli altri tre.
+1.
Forse la nuova idea non sarebbe nata con l'approccio OOP, dove un analogo del ciclo con forza bruta dell'ordine è nascosto in qualche entità simile al manager che, invece di chiamare OrderModify direttamente, genera un comando di modifica (con tutti i parametri) e lo mette in una coda che viene poi elaborato. L'idea è di dividere la responsabilità (che in questo codice è stipata in un unico ciclo) tra un oggetto di analisi dell'ambiente e un oggetto che esegue azioni basate sull'analisi.
Forse questa idea non si presenterebbe con un approccio OOP, quando un analogo del ciclo con la ricerca dell'ordine è nascosto in qualche entità come il manager, che invece di chiamare OrderModify genera direttamente il comando da modificare (con tutti i parametri) e lo mette in una coda, che viene poi elaborato. L'idea è di dividere la responsabilità (che in questo codice è stipata in un unico ciclo) tra un oggetto di analisi dell'ambiente e un oggetto di esecuzione delle azioni basate sull'analisi.
L'unico modo per evitare una tale situazione è usare ordini asincroni.
Altrimenti ci sarebbe ancora un ciclo sulla lista dei comandi da eseguire, che è, di fatto, un ciclo sugli ordini.
Solo in una situazione di coda dovreste ancora prendere disposizioni per sostituire un vecchio ordine non eseguito relativo a un ordine con uno più recente. Altrimenti la coda potrebbe traboccare e gli ordini inviati dalla coda sarebbero obsoleti.