Il mio approccio. Il nucleo è il motore. - pagina 38
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
Bene, bene... Vai, Peter.
Hai ragione sul "degrado", ma penso che tu sia presuntuoso sul "tirare gli utenti".
Ma, vai avanti. Ci può essere qualcuno là fuori che può programmare, ma i commerci "a mani vuote".
Sto pensando che c'è una famosa piattaforma americana per il trading manuale. Ha la possibilità di automatizzare parzialmente le azioni all'interno della piattaforma, ma bisogna sapere come farlo. C'è anche un'API. Ma quanti saranno in grado di usarlo?
Possiamo scrivere comode semiautomatiche e offrirle ai clienti. E non solo loro. A tutti i trader che commerciano manualmente può essere offerta una parziale automazione delle azioni, monitorare il mercato dalle tabelle e interagire con il programma utilizzando finestre di dialogo. Visualizza messaggi su eventi di mercato. Beh, forse non so o non capisco qualcosa, ma in teoria?
Noi, invece, possiamo scrivere comode semiautomatiche e offrirle ai clienti. E non solo loro. Possiamo offrire a tutti i trader che fanno trading manuale un'automazione parziale delle loro azioni, osservare il mercato dalle tabelle e interagire con il programma attraverso finestre di dialogo. Visualizza messaggi su eventi di mercato. Beh, forse non so o non capisco qualcosa, ma in teoria?
C'è solo un modo per scoprirlo.
Infine, almeno pubblicare qualcosa.
Lasciate che sia meno che ideale e senza plushkas (se necessario, aggiungere più tardi), e immediatamente vedere la domanda + feedback da parte degli utenti andrà e sarà più chiaro in quale direzione scavare dopo.
Prima lo fai, più tempo risparmi (o meglio, meno tempo perdi... :(
Avrei dato molto per questi consigli ai miei tempi :)
Bene, bene... Vai, Peter.
Hai ragione sul "degrado", ma penso che tu sia presuntuoso sul "tirare gli utenti".
Ma, vai avanti. Ci potrebbe essere qualcuno che sa programmare, ma che scambia "mani in pasta".
Non è possibile. Coloro che sanno programmare faranno sicuramente un assistente in MQL5 e passeranno solo 1-2 settimane a studiare le operazioni di trading in MQL5.
Per quanto riguarda il robot semi-automatico, tra qualche ora farò un video e vi mostrerò come appare un moderno robot automatizzato che può lavorare in modalità semi-automatica come un Expert Advisor.
E non c'è bisogno di inventare pannelli complicati per questo, ma farne uno molto semplice per renderlo più chiaro a tutti.
Gli utenti di oggi sono degradati dal graal del testering. Hanno bisogno di essere tirati verso un po' di complessità e di responsabilità per le loro azioni. Altrimenti, una completa degradazione dell'algotrading.
Non vedo altro futuro per la nicchia dell'algotrading. Onestamente, non vedo...
Così tanto pathos... vedo mani alzate di dolore ;)))
Tu, Petya, ami il ruolo di messia.
Tutti sono degradati... dove sta andando il mondo... la vostra missione, il vostro destino è di guidare un'umanità degradata verso un futuro luminoso di algotrading. Qui c'è già una diagnosi. Se ti viene in mente qualcosa...
Petya, non fare il finto tonto.
C'è qualcosa di mql oop che personalmente non mi piace. Qualsiasi oggetto "vuoto" richiede 16 byte. Inoltre il suo puntatore prende 8 byte. Totale 24 byte per 1 oggetto, senza contare i dati. Se invece fai una matrice di proprietà, puoi sostituire un oggetto "vuoto" con 6 ints, ognuno dei quali può memorizzare quasi tutto tranne le stringhe (per il tempo o il prezzo un int è sufficiente nel 99% dei casi)
E l'operazione di conversione del tipo dynamic_cast non è economica in termini di velocità. Quindi il metodo del topicstarter (non l'ho visto, ovviamente, ma teoricamente) potrebbe funzionare più velocemente e prendere meno memoria dell'analogico con OOP.
Ilya Malev:
Quindi il metodo di topikstarter (non l'ho visto, ovviamente, ma teoricamente) potrebbe funzionare più velocemente e prendere meno memoria degli analoghi OOP.
Non può, il "kernel" del topicstarter è un array di stringhe di dimensioni immense, e parlare di efficienza di tale approccio è irrealistico, anche teoricamente.
E l'operazione di conversione del tipo dynamic_cast non è economica in termini di velocità. Quindi il metodo del topicstarter (non l'ho visto, ovviamente, ma in teoria) potrebbe funzionare più velocemente e occupare meno memoria del suo analogo OOP.
Quindi nessuno sostiene che l'accesso diretto a un enorme array globale sia più veloce di tutti questi espedienti di interfaccia e conversioni di tipo. Possiamo anche pensare ai design pattern, ad esempio Visitor con doppio dispatch - c'è un sacco di overhead lì.
Tuttavia, tutto questo è compensato dalla comodità del supporto e della modifica. Sfortunatamente, il massimo trasferimento di qualsiasi sforzo di pensiero al computer è stato lo sviluppo della programmazione mainstream per molto tempo. Si arriva al punto che la somma di una progressione aritmetica viene calcolata per mezzo di un ciclo invece di usare la nota formula della somma. In questo senso, sono d'accordo con Peter che le persone sono "degradanti".
Ma, ahimè, non c'è scelta - o si "degrada" con tutti gli altri, cercando di non farlo così velocemente, o si rimane irrimediabilmente indietro. E il fatto che il vostro programma sia inefficace ha poca importanza.
Qui vedo persino un'analogia con la competizione in biologia, nei rapporti tra predatore e preda: la lepre che scappa dal lupo non è affatto in competizione con il lupo, ma con altre lepri. Non ha bisogno di allontanarsi dal lupo il più velocemente possibile. È molto più importante per lui non essere l'ultimo a scappare dal lupo. Perché se è l'ultimo a scappare - sarà mangiato, ma se scappa più velocemente di tutti gli altri - spenderà più energia del necessario, e può essere spesa in direzioni più utili.
Così è con tutti i tipi di tecnologie di programmazione... Il modo più efficiente per programmare in assembler, ma richiede così tanto sforzo che non ha senso - l'energia è meglio spesa in modo più produttivo, anche se il codice non è così efficiente. L'array di Peter con accesso globale è dello stesso tipo. Accedervi è efficiente, ma ricordare cosa si trova dove e come accedere a cosa richiede troppo sforzo.
Non può, il "nucleo" nel topicstarter è un array di stringhe di dimensioni immense, ed è irrealistico, anche teoricamente, parlare dell'efficacia di un tale approccio.
È davvero un array di stringhe o è un modo di dire? Se i dati sono rappresentati da stringhe mql (string), non c'è davvero alcuna possibilità...
Accedervi è efficiente, ma ricordare cosa si trova dove e come accedervi richiede troppo.
Quando il "kernel" è pronto, si può spendere uno sforzo relativamente piccolo per attaccargli un'interfaccia comoda che risolva tutti i problemi di presentazione e di accesso alle informazioni "goffi". Anche se questo è un discorso ozioso, da quanto ho capito, TC non ha pubblicato i suoi codici e chissà se sono proprio in natura :) O li ha pubblicati? Onestamente, non sono riuscito a leggere tutte le 38 pagine
Inoltre, un metodo che si limita esclusivamente alle "semiautomatiche" non ha valore per definizione. Anche se può aiutare ad occupare una nicchia locale e limitata nel mercato dei prodotti e dei freelance