Idee ambiziose!!! - pagina 7

 
Mathemat:

Sbagliato di nuovo. L'interpretazione del flusso in arrivo è il compito di colui che sta sopra il ricevitore e stabilisce le condizioni del gioco. Il ricevitore è di ferro; macina le informazioni secondo l'algoritmo stabilito per lui dal Game Master. In questo senso è completamente e strettamente oggettivo, perché è un ferro muto. Ma è il Maestro che è soggettivo.

Sai che l'informazione può essere definita in modi diversi, a seconda del contesto del problema da risolvere?

Per soggettività del ricevitore intendo che può interpretare l'informazione in entrata in modo arbitrario, secondo l'algoritmo implicito in essa. In questo caso l'informazione oggettiva in entrata viene trasformata dal ricevitore in una soggettiva. Il contesto e tutto il resto non c'entrano niente.
 
Grazie, non è un brutto sito.
 
Alcune persone pensano che OOP sia davvero efficace nei grandi progetti, mentre in quelli piccoli è meglio usare la buona vecchia programmazione procedurale. Ma non sono d'accordo con questa opinione. Se il programma che volete scrivere è più grande di "Hello word" di almeno una riga, è meglio usare OOP piuttosto che la programmazione procedurale. Dalla mia esperienza personale, posso dire che anche i programmi più piccoli vengono migliorati, vengono aggiunte nuove funzionalità, nuovi controlli, nuovi compiti. Come risultato, un programma che inizialmente era stato concepito come piccolo si trasforma in un vero e proprio mostro. È molto importante gettare le basi qui. Se si tratta di programmazione procedurale, un progetto sarà invaso da un sacco di funzioni ingestibili, conversioni di puntatori, etc., etc. OOP è una brutta cosa. Scrivete programmi in esso, a partire da "Hello Word", e poi sviluppate facilmente e volentieri le loro funzionalità. Per esempio, è impossibile scrivere anche il più piccolo programma in C# senza usare OOP. Pensate che gli sviluppatori di questo linguaggio siano degli idioti miopi?
 
C-4:
Ma non sono d'accordo con questa opinione. Se il programma che volete scrivere è più di "Hello word" di almeno una riga, è meglio usare OOP piuttosto che
Potrebbe darci un esempio concreto con cui confrontarlo, per non essere infondato?
 

Ecco, l'argomento è stato sviato, stavamo parlando di qualcos'altro:

>NASCOSTO 10.11.2010 22:39

>Sono stato perseguitato dall'idea di implementare un tester di strategie multicurrency per un paio d'anni.

Se non ti piace l'OOP, non usarlo, è un argomento inutile.

 
xeon:

Ecco, l'argomento è stato sviato, stavamo parlando di qualcos'altro:

>NASCOSTO 10.11.2010 22:39

>Sono stato perseguitato dall'idea di implementare un tester di strategie multicurrency per un paio d'anni.

Se non ti piace l'OOP, non usarlo, è un argomento inutile.


Ho letto tutto quello che è stato scritto qui, e ora ho davvero paura di MT5 perché ne sono ossessionato, e voglio implementarlo il più presto possibile.

Grazie a tutti coloro che sanno come mettere correttamente (ragionevolmente) i cervelli al loro posto.

Se penso che MT5 è sviluppato da un team di persone, e tutti lo stiamo testando, quanto tempo spenderò per la sua implementazione in MQL4? E MT4 sarà morto prima o poi, è solo una questione di tempo. Penso che MT5 durerà comunque 5-10 anni.

 
HIDDEN:

Dopo aver letto tutto quello che è stato scritto qui, ho iniziato a guardare verso la MT5 perché sono davvero attratto da essa, e voglio implementarla il più presto possibile.

Grazie a tutti coloro che sanno come mettere correttamente (ragionevolmente) a posto i cervelli.

Se penso che MT5 è sviluppato da un team di persone, e tutti lo stiamo testando, quanto tempo spenderò per la sua implementazione in MQL4? E MT4 sarà morto prima o poi, è solo una questione di tempo. Penso che MT5 durerà comunque 5-10 anni.

Al momento nel tester di MT5, c'è un ostacolo insormontabile (almeno per ora), che potrebbe scoraggiarlo (per alcuni utenti), è l'impossibilità di impostare per i test/ottimizzazione la propria storia (di terze parti).
 
xeon:
Al momento, nel tester MT5, c'è un ostacolo insuperabile (almeno per ora) che può far desistere (per alcuni utenti), è l'impossibilità di utilizzare la propria storia (di terzi) per i test/ottimizzazione.


Ahimè, ci sono un paio di "punti sensibili" in MT5 - indicatori multicurrency - molto instabili lavorando nel tester, è difficile fare il debug degli indicatori multicurrency a causa della necessità di caricare indipendentemente gli array di serie temporali - non ancora fatto, ma presto lo farò - sposterò il calcolo degli indicatori multicurrency nell'Expert Advisor stesso - allora i problemi dovrebbero andare via

SBS: grazie al topicstarter per la comprensione - abbiamo ottenuto abbastanza occupato nel suo argomento :), con l'implementazione di un auto-tester multi-valuta in MT4, non ci sono particolari problemi - esempi decenti sul forum, ma come un tester completamente funzionale non funzionerà, e si sforzano di creare il proprio tester - tempo sprecato - con lo stesso successo si può analizzare il trading multi-valuta nello stesso Exel

 
IgorM:


ahimè, ci sono un paio di "problemi delicati" in MT5 - indicatori multicurrency - non funzionano con sicurezza nel tester, è difficile fare il debug degli indicatori multicurrency a causa della necessità di caricare indipendentemente gli array di serie temporali - non ancora fatto, ma presto lo farò - sposterò il calcolo degli indicatori multicurrency nell'Expert Advisor stesso - allora i problemi dovrebbero andare via

Pompare la storia dal database MQ è facile, soprattutto perché c'è un esempio già pronto: - https://www.mql5.com/ru/docs/series/timeseries_access

p.s. se ho capito bene il compito...

 
xeon:
Al momento nel tester di MT5, c'è un ostacolo insormontabile (almeno per ora) che potrebbe porre fine ad esso (per alcuni utenti), che è l'impossibilità di sostituire la propria storia (di terzi) per il test/ottimizzazione.


Questo è un dato di fatto. I principianti non ne hanno davvero bisogno, ma nel trading reale è una cosa necessaria.

Motivazione: