Fare un sistema di trading Python per la MT. - pagina 9
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
Se potete scrivere tutto in MQL, non avete davvero bisogno di nient'altro.
Non posso e non voglio nemmeno scrivere ed entrare nei dettagli di algoritmi che sono già scritti, praticati e disponibili. Non voglio usarli direttamente, invece di riscrivere o adattare la loro applicazione in MQL. A proposito, questo è il concetto principale di OOP.
Per non entrare nel merito, OOP da solo non basta, abbiamo bisogno di modelli di componenti per lo scambio e l'interazione interprogramma, come OLE->ActiveX->DCOM->.Net, altrimenti dovremo sempre manovrare tra linguaggi e librerie.
Presumo che Python, con le sue ampie librerie, non avrà bisogno di tutto questo nel prossimo futuro. Tranne che per la comunicazione terminale, ma questo problema è stato risolto da tempo e anche in diversi modi.
Onestamente, questo Python è fastidioso, insieme alle sue classi. Ecco un piccolo frammento di una delle funzioni:
Contate quante volte la parola self è ripetuta in questo piccolo pezzo di codice ?
E sempre e ovunque, in ogni linea più volte. Questa assurdità si ripeterà sempre in tutte le funzioni (metodi) di qualsiasi classe.
Sì... Sì, python è buono solo come "collante", per lo scripting da poche a un paio di decine di linee, allora c'è un chiaro vantaggio rispetto a C++\Java, ma è più costoso implementare OOP multi-tier in python, anche a livello di convenienza, la velocità di tali librerie è fuori questione. Python è divertente per mostrare i principi nelle presentazioni, ecc. È molto "pulito" nell'aspetto dalle personalizzazioni, che ovviamente devono essere scritte in altri linguaggi, ma scrivere qualcosa di serio, con thread e GUI in Python è una vera seccatura
Il proprio tester è più interessante perché si può avere il controllo completo del processo, che è assolutamente essenziale per i test. E il tester stesso è una costruzione molto semplice.
Non vedo l'utilità di finanziare qualcosa, dato che lo faccio solo per me stesso.
Lo faccio solo per me stesso. Il tester non ha un algoritmo complicato, ma ci sono un sacco di posti dove posso fare un errore. Ma ovviamente usare gli sviluppi di qualcun altro non può essere meno rischioso, almeno per le stesse ragioni, e forse per alcune altre ragioni legate allo specifico di "chi ne beneficia".
hum hum... Sì, python è buono solo come "collante", per lo scripting da poche a un paio di decine di linee, allora c'è un chiaro vantaggio su C++/Java, ma è costoso fare OOP multistrato in python, anche a livello di convenienza, la velocità di tali librerie è fuori questione. Python è divertente per mostrare i principi nelle presentazioni, ecc. È molto "pulito" nell'aspetto dalle personalizzazioni, che chiaramente devono essere scritte in altri linguaggi, ma scrivere qualcosa di serio, con thread e GUI in Python è un vero dolore.
Perché "whew..."? Tutto va bene lì in Python, e anche la velocità va bene. Anche i loop da 55k funzionano bene, nella penultima versione. Infatti, le librerie in Python sono veloci, mentre Python stesso è soprattutto per collegare le parole in una frase.
In generale, parlare veloce - lento non ha senso di per sé. Se è veloce, a cosa serve esattamente? Se lento, in modo simile.
Che cos'è questo "affannoso..."? Tutto va bene lì in Python, e anche con la velocità. Anche i loop da 55k funzionano bene, nella penultima versione. Infatti, le librerie in Python sono veloci, mentre Python stesso è soprattutto per collegare le parole in una frase.
In generale, parlare veloce - lento non ha senso di per sé. Se è veloce, a cosa serve esattamente? Se lento, in modo simile.
55k sono briciole, devi contare miliardi, e quindi il tester nativo python non funzionerà, dovrai scrivere e importare la libu sui plus, e python è solo per chiamare e configurare, perché potrebbe essere 100 volte più lento.
e "ahem" riguardava "self" e 100500 metodi e attributi __***__, IMHO rendono il codice molto più complicato che anche su plus, e se parliamo di thread, eventi e GUI, tutto non è migliore che con plus, piuttosto il contrario, tutto questo "duck typing" e roba del genere comincia a far male, bisogna tenere molto a mente, ricordare un sacco di cose55k sono briciole, devi contare miliardi, e quindi un tester nativo python non funzionerà, dovrai scrivere e importare la libreria in plusses, e python solo chiamate e configurazioni, perché potrebbe essere 100 volte più lento.
e "ehm" era a proposito di "self" e 100500 metodi __***__, IMHO fanno un codice molto più complicato che anche con i plus, e se parliamo di thread, eventi e GUI, tutto non è meglio che con i plus, piuttosto il contrario, tutto questo "duck typing" e roba del genere, al contrario, comincia solo a far male, bisogna tenere a mente un sacco di coseNon so perché ho bisogno di miliardi)). Il tester - non ho lamentele, finora tutto è veloce, 3 mesi passano in un attimo, e non ho bisogno di altro).
Con tutto il resto, credo di essere d'accordo, sui plus è più divertente scrivere. Ma non si può davvero modellare sui vantaggi. Si scopre che: prima modelliamo da qualche parte in un software, e poi lo portiamo sui plus, scriviamo ogni sorta di interfacce per le libs - è una vera seccatura.
E in Python tutto in un pacchetto, e un normale ambiente di simulazione + tutte le librerie necessarie, di solito in C++. Per la strategia è abbastanza veloce - 15-30 ms non è un ritardo per me. Alla fine si possono riscrivere le sezioni critiche in C, come fanno alla NASA. Se ce ne saranno, ovviamente.
E niente è perfetto in assoluto).
Non so perché ho bisogno di miliardi)). Tester - non ho lamentele, finora tutto è veloce, 3 mesi scivolano in un momento, e non ho bisogno di più).
Con tutto il resto, credo di essere d'accordo, sui plus è più divertente scrivere. Ma non si può davvero modellare sui vantaggi. Si scopre che: prima modelliamo da qualche parte in un software, e poi lo portiamo al plus, scriviamo ogni sorta di interfacce per le libs - è una vera seccatura.
E in Python tutto in un pacchetto, e un ambiente normale per la modellazione + tutte le libs necessarie, di solito in C++. Per la strategia è abbastanza veloce - 15-30 ms non è un ritardo per me. Alla fine si possono riscrivere le sezioni critiche in C, come fanno alla NASA. Se ce ne saranno, ovviamente.
E niente è perfetto in assoluto).
Miliardi nel contesto dell'ottimizzazione, quando centinaia o addirittura migliaia di test vengono eseguiti su centinaia di migliaia di barre di minuti. Non siamo i nostri nemici che aspettano ore per recuperare un paio di semplici indici genetici per un anno di minuti, dovrebbe essere fatto in secondi, mentre in Python ci vorrebbe molto più tempo, così come su scatole nere con rallentamento deliberato dei calcoli.
E python in generale è uno strumento molto attraente nel giusto contesto, anche se IMHO la sua attuale popolarità è un fenomeno transitorio, è qualcosa come la moda dei social network e dei gadget Apple, c'è una connessione con la lucentezza esterna e il minimalismo su esempi molto semplici, e anche gli studenti che gonfiano le sue valutazioni.
PS A proposito, perché pensi che il tuo tester funzioni correttamente? Il tester è una cosa complicata....
Miliardi nel contesto dell'ottimizzazione quando il test viene eseguito centinaia o addirittura migliaia di volte su centinaia di migliaia di barre di minuti. Non siamo i nostri nemici che aspettano per ore un paio di semplici indici genetici per un anno di minuti, dovrebbe essere fatto in secondi, ma in Python ci vorrà molto più tempo, così come su scatole nere con rallentamento deliberato dei calcoli.
Non mi occupo di ottimizzazione e di ogni sorta di abbinamento di parametri. La mia metodologia è diversa, ma ho bisogno di un ambiente simile a MatLab, R, SciLab, ecc. Python è altrettanto buono.
Inoltre non ho bisogno di 10^6 barre. Per tutto - circa 6, massimo 9 mesi su minuti è sufficiente. Ora il test è di 3 mesi -2,5 m, anche se il sistema non è ancora così complicato.
Il più lungo è imparare ML, ma non c'è niente di meglio di Python, e qui è solo come linguaggio di scripting. Diciamo che la risposta di una rete neurale addestrata di 5 strati, circa 60 neuroni è di 3-5 ms.
Finora, non vedo alcuna conferma reale dell'allarmismo.