Mt4 Fine del supporto. - pagina 29
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
Lo svantaggio principale: l'OOP costringe a seguire la strada della frammentazione del codice in molte funzioni.
È più facile per gli umani accettare il codice frammentato, ma la frammentazione è controindicata a qualsiasi meccanismo.
Va bene, ma qual è lo svantaggio?
È il vantaggio principale: proprio perché è più facile per una persona percepire il codice frammentato!
Il computer deve adattarsi all'uomo, non l'uomo al computer.
È vero, ma qual è il rovescio della medaglia?
Questo è il vantaggio principale! Proprio perché è più facile per una persona percepire il codice frammentato!
Il computer deve adattarsi alla persona, non la persona al computer.
Ahimè, uno sviluppatore dovrebbe pensare prima di tutto all'efficienza del suo meccanismo, non alla sua comodità)).
Altrimenti il meccanismo "zoppica".
Lo sviluppatore dovrebbe adattarsi al computer.
Se le quotazioni provengono dallo stesso server, non fa differenza quale strumento. Dopo tutto, le barre si aprono su ogni strumento allo stesso tempo.
È diverso se le fonti delle citazioni sono in diverse parti del mondo. Per i minuti non ha importanza, ma potrebbe esserci un problema con timeframe più alti. Forse le funzioni temporali devono essere studiate più in dettaglio e deve essere fatta una correzione temporale accurata. Ma questa è la prossima tappa nello sviluppo di questa soluzione...
È necessario fare una calibrazione per questa funzione...
All'inizio volevo leggere tutto quello che è stato scritto senza di me, nel caso ci fosse già una domanda e una risposta, ma ho paura che sarà difficile trovare il post che deve essere citato in seguito.
Per ora c'è solo 1 domanda: come tutti sanno, una nuova barra non apparirà fino al primo tick del nuovo intervallo di tempo. Pertanto, se ci dovrebbe essere una barra per millisecondi ma è assente, è possibile ottenere letture dell'indicatore dalla barra sbagliata.
Spero di trovare una risposta alla seconda domanda, è stata posta da Artem.
All'inizio volevo leggere tutto quello che è stato scritto senza di me, nel caso ci fosse già una domanda e una risposta, ma ho paura che sarà difficile trovare il post che deve essere citato.
Finora solo 1 domanda: come tutti sanno, una nuova barra non apparirà fino al primo tick del nuovo intervallo di tempo. Pertanto, se ci dovrebbe essere una barra per millisecondi ma è assente, possiamo ottenere i valori dell'indicatore dalla barra sbagliata.
Spero di trovare una risposta alla seconda domanda, è stata posta da Artem.
Sì, ne abbiamo discusso ieri.
Ho avuto a che fare con un'altra piattaforma e lì le barre si formavano in base al tempo indipendentemente dall'arrivo delle quotazioni (guarda TWS).
Mi è stato detto che non è il caso di MT.
Aggiungerò un controllo dell'arrivo del preventivo per confermare l'evento della nuova apparizione del bar.
Ho già risposto che i bar si aprono indipendentemente dall'arrivo di un preventivo. Se non c'è una quotazione, il prezzo della nuova barra sarà il prezzo di chiusura della barra precedente. Il fatto di una nuova barra sarà fissato indipendentemente dall'arrivo delle quotazioni, dai contatori stessi, che funzionano su un timer.
Il timeframe specifico non ha importanza, perché è solo un contatore che raggiunge il suo valore e imposta l'evento della nuova barra di questo timeframe. Questo è semplicemente un metodo per sincronizzarsi con l'apparizione di nuove barre di diversi timeframes. SINCRONIZZAZIONE.
Anche lo strumento non ha importanza. Se le quotazioni provengono da un server, significa che hanno lo stesso tempo di apparizione delle nuove barre. Pertanto, non importa quale strumento, purché questi strumenti provengano da un punto del globo.
Finisco quello che ho detto e faccio altre cose. Un po' di roba buona).
E come si può spiegare il fatto che la chiusura di venerdì, la barra precedente di qualsiasi periodo è uguale a 1,20333, e l'apertura di lunedì di qualsiasi periodo è uguale a 1,20142?
Naturalmente questo è il preventivo di un broker, l'altro potrebbe essere un po' diverso, ma c'è una differenza in tutto.
E come si spiega il fatto che la chiusura di venerdì, la barra precedente di qualsiasi periodo è 1,20333 e l'apertura di lunedì di qualsiasi periodo è anche 1,20142?
Queste sono ovviamente le quotazioni di un broker, l'altro può essere un po' diverso, ma tutti hanno delle differenze.
Si spiega con il divario. Succede all'apertura della sessione.
Non sono un esperto di trading, quindi non giudicate la mia opinione troppo duramente).
E so ancora meno di quello che succede sul mercato del forex).
Ahimè, il progettista deve pensare prima all'efficienza del suo meccanismo, non alla sua comodità).
Altrimenti il meccanismo "zoppica".
Lo sviluppatore deve adattarsi al computer.
No.
Lascia che il computer si adatti a me. Ho abbastanza altri problemi. Lo sviluppatore può solo modificare dove il computer non può gestire il compito, ad esempio, nei colli di bottiglia dove manca la performance o la memoria. Poi, sì, è il turno dello sviluppatore di adattarsi. Ma finora non mi sono imbattuto in nessun posto dove l'OOP imporrebbe un carico aggiuntivo così significativo sul computer da dover essere ridotto in qualche modo.
Qualcosa del genere (codice per MQL5):
Ma ripeto - sono un sostenitore dell'OOP.
È solo un esempio davvero infelice per mostrare ciò che è impossibile fare nella programmazione procedurale.
Quando ho iniziato questo, non avevo intenzione di mostrare che tutto è possibile/impossibile da fare, ma solo più conveniente da usare in futuro quando scrivo i miei codici.
Ma è venuto fuori, come ha detto V.S., volevo il meglio, ma è venuto fuori come sempre.
Oh, no.
È il computer che si adatta a me. Ho abbastanza altri problemi. Lo sviluppatore può solo regolare dove il computer "non può gestire", per esempio, nei "colli di bottiglia", dove non ci sono abbastanza prestazioni o memoria. Poi, sì, è il turno dello sviluppatore di adattarsi. Ma finora non mi sono imbattuto in nessun posto dove l'OOP fornisce un carico aggiuntivo così significativo sul computer che deve essere in qualche modo ridotto.
Il carico sul computer è causato dall'attitudine disattenta dello sviluppatore alla questione della coerenza del suo meccanismo. Il desiderio di risparmiare energia per migliorare il sistema. Un irragionevole spreco di risorse informatiche in nome della facilitazione del loro lavoro.
Finché il computer riesce a far fronte con successo a un codice scritto in modo inefficiente, lo sviluppatore continuerà a "parassitare" la potenza di elaborazione. Questa è una strada senza uscita.
Prima o poi, il meccanismo inefficace smetterà di svilupparsi e sarà sostituito da una controparte migliore.
Il tempo e lo sforzo dell'uomo saranno sprecati e la sua invenzione finirà nella pattumiera.
Nel mondo competitivo, questo rischio esiste sempre.
Quando progettiamo le macchine, dovremmo pensare prima alle loro prestazioni e poi al comfort e alla comodità di trascorrere le nostre ore di lavoro).
L'onere è posto sul computer dall'atteggiamento negligente dello sviluppatore verso la coerenza del suo meccanismo. Il desiderio di risparmiare energia per migliorare il sistema. Consumo irragionevole di risorse informatiche in nome della semplificazione del loro lavoro.
Finché il computer riesce a far fronte con successo a un codice scritto in modo inefficiente, lo sviluppatore continuerà a "parassitare" la potenza di elaborazione. Questa è una strada senza uscita.
Prima o poi, il meccanismo inefficace smetterà di svilupparsi e sarà sostituito da una controparte migliore.
Il tempo e lo sforzo dell'uomo saranno sprecati e la sua invenzione finirà nella pattumiera.
Nel mondo competitivo, questo rischio esiste sempre.
Quando si progettano i meccanismi, dobbiamo pensare al loro rendimento in primo luogo, e al comfort e alla comodità delle nostre ore di lavoro in secondo luogo).
Si chiama programma non è scritto. Ecco perché un codice correttamente funzionante (e leggibile da qualsiasi altro sviluppatore) viene scritto prima e solo dopo viene ottimizzato - se c'è qualcosa da ottimizzare.