Discussione sull’articolo "Programmazione basata su automi come nuovo approccio alla creazione di sistemi di trading automatizzati" - pagina 4
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
L'articolo non tratta affatto l'argomento, tranne che per il fatto che esiste un interruttore. Non importa se esiste o meno, può essere commutato con degli "if".
Una volta stavo scrivendo un EA, con un sistema molto complesso di ordini. Ho dovuto analizzarlo seriamente e stilare un elenco di stati: nessun ordine, uno in sospeso, un ordine di mercato, due ordini in sospeso, uno in sospeso e uno di mercato, ecc. Solo in questo modo sono riuscito a superarlo. Ma si è rivelata una cosa così universale e rapidamente riprogrammabile. Un argomento che si presta a un articolo.
Potresti scrivere un articolo? Credo che molte persone sarebbero interessate a leggerlo.
Va bene, lo farò.
Preferisco anche utilizzare un normale if. In generale, esistono due approcci: con l'aiuto di if e con l'aiuto di funzioni speciali che vengono richiamate dal commutatore di stato. La domanda è quale approccio sia migliore/semplice.
È necessario esaminare l'argomento: il contatore è più veloce nella scelta di una soluzione, ma if è più facile da chiamare.
Se ci sono molti contatori annidati, allora if funzionerà più velocemente, perché una chiamata a if è più economica di una chiamata a switch.
Ma se ci sono più soluzioni a ogni livello, switch è più appropriato.
Questa è una novità. Qualsiasi TS (senza eccezioni) si basa sull'analisi e sulla chiara comprensione degli stati del TS. Gli stati più semplici: l'elaborazione dei segnali per aprire/chiudere/modificare un ordine, ecc. ecc.
Se "lo stato attuale dell'Expert Advisor non è chiaramente noto", allora non si tratta assolutamente di un Expert Advisor, né di un programma, e la parola "algoritmo" in relazione a un Expert Advisor dovrebbe essere cancellata e dimenticata per sempre.
Le informazioni di mercato arrivano in ritardo, ci possono essere (e probabilmente ci sono) errori nel software sul server e sul computer, gli ordini possono non essere eseguiti per un milione di motivi, la rete - la connessione al provider può lampeggiare, l'elettricità può essere interrotta in qualsiasi momento (ricordate i guasti e i riavvii del campionato). I fattori di incertezza sono più che sufficienti. E un Expert Advisor o un algoritmo deve tenerne conto. È impossibile contare sul perfetto funzionamento del server, del software, delle comunicazioni, del mercato, dell'operatore e dell'elettricità.
Quindi lo stato attuale degli ordini, del mercato, delle comunicazioni, dell'elettricità non è mai noto all'Expert Advisor, e l'Expert Advisor o l'algoritmo devono comunque funzionare correttamente in condizioni di incertezza.
Le informazioni di mercato arrivano in ritardo, ci possono essere (e probabilmente ci sono) errori nel software del server e del computer, gli ordini possono non essere eseguiti per un milione di motivi, la rete - la connessione al provider - può saltare, l'elettricità può essere interrotta da un momento all'altro (ricordate i guasti e i riavvii del campionato). I fattori di incertezza sono più che sufficienti. E un Expert Advisor o un algoritmo deve tenerne conto. È impossibile contare sul perfetto funzionamento del server, del software, delle comunicazioni, del mercato, dell'operatore, dell'elettricità.
Quindi lo stato attuale degli ordini, del mercato, delle comunicazioni, dell'elettricità non è mai noto all'Expert Advisor, e l'Expert Advisor o l'algoritmo devono comunque funzionare correttamente in condizioni di incertezza.
Assurdo. Mescolare tutto in un unico grande mucchio.
- controllo di eventuali ritardi nella quotazione; - rifiuto del broker di eseguire un ordine; - riavvio anomalo dell'EA - questi sono stati chiari e definiti dell'EA - come risultato dell'identificazione di ciascuno di tali stati - adempimento della funzione corrispondente
- se una funzione non viene fornita in risposta a un possibile stato - non significa "condizione di lavoro confusa" - semplicemente l'EA non analizza (secondo il suo algoritmo chiaro e non ambiguo) questo stato.
Qualsiasi programma (compreso un Expert Advisor) funziona secondo un chiaro algoritmo predeterminato. Non esistono azioni confuse e indefinite nel lavoro di un programma. In caso contrario, si tratterebbe di uno stato di "congelamento". E il "congelamento" di un programma è, come sappiamo, un errore dell'algoritmo, non una conseguenza dell'eterea vaghezza.
Per i veri Expert Advisor è impossibile definire lo stato in modo univoco. Lo stato interno è determinato in modo inequivocabile, ma lo stato delle posizioni sul server può essere sconosciuto, conosciuto con un certo ritardo, essere in uno stato poco chiaro (alcuni ordini e richieste vengono eseguiti, altri no, e non si sa perché).
I fattori di incertezza sono più che sufficienti. E un Expert Advisor o un algoritmo deve tenerne conto. È impossibile contare sul perfetto funzionamento di server, software, comunicazioni, mercato, operatori, elettricità. Quindi, lo stato attuale degli ordini, del mercato, delle comunicazioni, dell'elettricità non è mai noto al Consulente Esperto in generale.
Non ci sono incertezze. Ci sono errori di un programmatore che non ha tenuto conto di qualcosa.
"Non conosciuto", "in uno stato non chiaro" sono stati a tutti gli effetti come tutti gli altri. Naturalmente, devono essere presi in considerazione, altrimenti non c'è altro modo.
Se si scrive la frase "c = a + b", si tratta di una programmazione teorica, accettabile solo nelle lezioni scolastiche. Ma quando si programma un vero impianto industriale, un'operazione utile come "c = a + b" richiede 100500 operazioni di controllo per confermare che un ingresso è davvero "a", un altro ingresso è davvero "b", e bisogna anche assicurarsi che "a" e "b" non siano cambiati durante l'addizione, e se improvvisamente "c" non ha raggiunto l'uscita, l'operazione dovrebbe essere riconosciuta come errata e tutto dovrebbe essere riportato indietro, ecc.ecc. Benvenuti nel mondo reale ))))
Non ci sono incertezze. Ci sono errori di un programmatore che non ha tenuto conto di qualcosa.
"Non noto", "in stato non chiaro": sono Stati a tutti gli effetti, come tutti gli altri. Naturalmente, devono essere presi in considerazione, altrimenti non c'è altro modo.
Se avete scritto la frase "c = a + b", questa è una programmazione teorica, accettabile solo nelle lezioni scolastiche. Ma quando si programma un vero impianto industriale, un'operazione utile come "c = a + b" richiede altre 100500 operazioni di controllo per confermare che un ingresso è davvero "a", un altro ingresso è davvero "b", e bisogna anche assicurarsi che "a" e "b" non siano cambiati durante l'addizione, e se improvvisamente "c" non ha raggiunto l'uscita, l'operazione deve essere riconosciuta come errata e tutto deve essere riportato indietro, ecc.ecc. Benvenuto nel mondo reale )))).
Questa è una buona analogia. )) Ma con tutto ciò, non bisogna dimenticare che è comunque impossibile spiegare tutto. Anche la natura commette errori e sbaglia sotto forma di mutazioni. Ma si dovrebbe tendere alla perfezione, naturalmente. ))
La natura non commette errori perché non gliene importa nulla. Siamo noi a proporre teorie giustificative.
E la natura è una cosa inconsapevole, e quindi non segue chi ha ragione e chi è colpevole.
...
E la natura è inconscia e quindi...