Errori, bug, domande - pagina 673

 

Renat, zero - grazie mille per la tua attenzione all'argomento e la tua risposta costruttiva!

Il prossimo.

1. su x64

Renat:

L'opzione più corretta è l'aggiornamento a x64.

...

Naturalmente, se qualcuno chiamerà centinaia di indicatori nella modalità di scansione del mercato senza il loro scarico, dovrebbe andare direttamente alla versione a 64 bit + installare memoria aggiuntiva.

È strano fare dei test massicci seduti su x32 al momento. Qualsiasi computer x64 decente con 16GB di memoria (senza essere fanatici di schede grafiche e monitor) può essere comprato per 15.000 rubli.

Passare a x64 è senza dubbio la giusta linea d'azione. Ma. Uno non esclude l'altro. Anche i miei 16 giga (li ho) non voglio sprecarli in dati inutili. Ho altre cose su cui lavorare in parallelo - MSVS, Matlab, ecc. Sono lieto che lei lo capisca e che sia disposto a cercare modi per risparmiare denaro.

2. su un inizio fisso della storia:


Renat:

Noi stessi vogliamo ridurre il consumo di risorse. Forse la soluzione potrebbe essere qualche funzione IndicatorMaxDepth(uint len), che agirà solo sugli indicatori creati in questo EA.

Ma il problema è che durante i test i buffer degli indicatori in modalità di accumulo cresceranno insieme alla storia e non ci sarà alcun salvataggio.

Completamente (quasi) d'accordo. Disclaimer: in molti casi l'ottimizzazione è fatta su una piccola parte dell'ultima storia. In questo caso il risparmio può essere abbastanza sostanziale. Ancora, considero l'opzione come relativamente funzionante - specialmente se avete un buon lavoro o delle stime sull'implementazione. A me, per esempio, l'opzione sembra non del tutto completa - un sacco di lavoro, e il risultato non è radicale. Una mezza soluzione.

3. ecco un'idea! :

Renat:

Ritagliare lastoria dell'indicatore in rltime, pur mantenendo la profondità impostata , è irto di bellissimi glitch e metterà direttamente al tappeto i programmatori che calcolano/utilizzano il sincronismo delle barre del grafico e del buffer dell'indicatore.

No! , non è irto - se le barre del grafico si comportano allo stesso modo - in modo sincrono. In altre parole, se i buffer dell'anello (anche se di dimensioni diverse) sempre (forzatamente) usare il flag AsSeries - non ci si aspetta un problema enorme per l'utente.

// In questo caso, sarebbe conveniente rendere tutti i buffer di storia presentati all'utente - indicatore (cioè circolare, con AsSeries=true).

In questa variante:

(1) c'è una rappresentazione interna degli array di indicatori e prezzi (dalla tua parte): indicizzazione da sinistra a destra (AsSeries==false), le dimensioni non riguardano l'utente, e infatti"l'entrata è vietata".

E (2) c'è un lato utente - tutti i buffer sono circolari (nell'implementazione. l'utente vede un array lineare virtuale), l'indicizzazione è da destra a sinistra (AsSeries==true) e la dimensione è impostata dall'utente.

Qual è il tetto dell'utente qui? Nessuno. Quando è fuori portata - risposta standard Array out of range.

Solo tu hai delle difficoltà (non piccole, per essere onesti), ma considerando l'universalità dello schema, devi sforzarti solo una volta. E per eliminare tutti i "bei difetti" sul nascere, al beta debugging. Dopo di che - felicità universale e costruzione molto economica .

Eseguiremo la revisione della cache dell'indicatore, che ora utilizza il principio della massima efficienza contro il principio del risparmio di memoria. Gli indicatori che sono stati rifiutati saranno scaricati immediatamente, invece di tenerli in memoria per qualche tempo, come si fa ora. Questo renderà possibile chiamare centinaia di indicatori in fila con uno scarico diretto tramite IndicatorRelease.

Buona idea, io sono a favore. Ma non annulla l'implementazione dello schema ad anello, ma semplicemente lo completa piacevolmente.
 
MetaDriver:

3. Arriva lo yazel! :

No! Non lo farà - se le barre del grafico si comportano allo stesso modo - in modo sincrono. In altre parole, se i buffer ad anello (anche se di dimensioni diverse) sempre (forzatamente) usare il flag AsSeries - non ci si aspetta un problema enorme per l'utente.

// In questo caso, sarebbe conveniente rendere tutti i buffer storici forniti all'utente - indicativi (cioè circolari, con AsSeries=true).

In questa variante:

(1) c'è una rappresentazione interna degli array di indicatori e prezzi (dalla tua parte): indicizzazione da sinistra a destra (AsSeries==false), le dimensioni non riguardano l'utente, e infatti"l'entrata è vietata".

E (2) c'è un lato utente - tutti i buffer sono circolari (nell'implementazione. l'utente vede un array lineare virtuale), l'indicizzazione è da destra a sinistra (AsSeries==true) e la dimensione è impostata dall'utente.

Qual è il tetto dell'utente qui? Nessuno. Quando l'utente va fuori portata - reazione standard Array fuori portata.

Solo tu hai delle difficoltà (non piccole, per essere onesti), ma considerando l'universalità dello schema, devi sforzarti solo una volta. E tutti i "bei difetti" devono essere eliminati sul nascere durante il debugging della beta, dopo di che tutti sono felici e la costruzione è molto economica .

Buona idea, sono d'accordo. Ma non annulla l'implementazione dello schema ad anello, lo completa solo piacevolmente.

Lasciatemi descrivere le condizioni del test:

  • La storia delle barre va dal 2000.01.01 al 2012.01.01 su M1 come ordinato
  • L'Expert Advisor lavora con indicatori brevi di 10 000 barre, la storia degli indicatori è tagliata per non andare oltre le 10 000 - 15 000 barre

Come risultato della sottoquotazione automatica dell'indicatore noi

  • spoil cumulatività (questo può essere tollerato, anche se ci sarà jitter dei risultati, che porterà all'inevitabile - "sì in MT5 anche gli induks glitch!")
  • perdiamo velocità nell'inevitabile spostamento della storia dell'indicatore (la copia in memoria è costosa, anche se la capacità di memoria è ancora più costosa)
  • far saltare la testa ai programmatori, che riusciranno a usare contatori memorizzati (questo può essere trattato con cura personale)
 
Renat:

Descriverò le condizioni del test:

  • La storia delle barre va come ordinato dal 2000.01.01 al 2012.01.01 su M1
  • l'Expert Advisor lavora con indicatori brevi di 10 000 barre, la storia degli indicatori è tagliata per non andare oltre le 10 000 - 15 000 barre

Come risultato della sottoquotazione automatica dell'indicatore noi:

1.

  • roviniamo la cumulatività (può essere tollerato, anche se ci sarà un jitter dei risultati, che porterà all'inevitabile - "in MT5 anche gli induttori fanno glitch!")

Sì, è tollerabile. Difficilmente causerà un malcontento di massa, al contrario, l'economia sarà molto attraente. Nessuno vieta di sprecare la memoria installando un'enorme MaxBar.

// Ma gli indicatori si bloccano a causa del salto delle barre! È qui che il malcontento è giustificato!

// Così si tollera anche questo... :) Beh, dobbiamo... :(

2.

  • perdiamo velocità sull'inevitabile spostamento della storia dell'indicatore (la copia di memoria è costosa, ma la capacità di memoria è ancora più costosa)

Beh, no e no! Lo schema circolare è esattamente quello che porta a enormi risparmi sulla copiatura nei turni di storia. In realtà, quando si sposta di una barra (N barre), dobbiamo copiare esattamente un valore (N valori). I costi( dell'utente) della virtualizzazione degli indici sono trascurabili. In effetti, sono persino difficili da rilevare nei test di stress(il resto della divisione è calcolato dal processore durante un ciclo di clock + lo spostamento dell'inizio del buffer virtuale a ogni spostamento attraverso la storia richiede un altro paio di cicli di clock). Quindi, non c'è quasi nessuna perdita di velocità. È impossibile rilevare questo rallentamento, è così piccolo. E sullo sfondo di un enorme risparmio di memoria queste perdite sono incommensurabili con il guadagno.

3.

  • Facciamo davvero impazzire i programmatori che riescono a usare contatori memorizzati (questo può essere trattato con cautela personale)
Non capisco nemmeno di cosa stiamo parlando qui, forse è solo sano in questo posto.
 

Ehhh, una faccia...

Per qualche ragione, c'è così tanto ballare e gridare sugli indicatori che soffocano sulle barre illimitate, ma non una parola sugli oggetti grafici che ballano. Prova a costruire, per esempio, la super grande Pitchfork di Andrews su Unlimited (su MN1, per esempio), poi limita il numero di barre nelle impostazioni del terminale, vai a timeframes bassi e riavvolgi ai punti di ancoraggio. Alcuni di loro saranno in un tremendo ritardo temporale dagli estremi (questo mentre i forconi di tutti e tre i punti si trovano esclusivamente nella zona delle vere barre M1, senza andare oltre il confine di quelle false dei timeframe superiori!) E perché? Apparentemente, perché non avevamo abbastanza dati storici su M1 per calcolare l'esatto valore M1 di alcuni punti di autobinding. Ma cosa c'entrano i dati storici? Beh, forse erano sufficienti, ma le barre esposte in vetrina non lo erano, da qui i turni. Cioè, alcuni punti "non sanno veramente dove sono".

Vorrei che qualcuno controllasse di persona, o forse sono l'unico che ha un tale casino...

 

Ho notato una stranezza!

Al momento della formazione di una nuova barra se leggete i valori di apertura e chiusura delle barre precedenti (per esempio 10 barre precedenti) e poi 5 secondi dopo li ottenete di nuovo, allora alcuni di questi valori sono diversi e poi se li ottenete mentre si sta formando una nuova barra allora tutto è ok, ma nei primi secondi per qualche motivo questi valori sono diversi.

Spero di essermi spiegato chiaramente.

Potete dirmi se prima di leggere i valori delle barre Open e Close dall'inizio di una nuova barra ci deve essere un ritardo di più di 5 secondi?

Ecco un esempio di funzionamento:


Sopra è correttamente attivato dopo un ritardo, sotto immediatamente dopo una nuova barra con un errore, e sulla destra il benchmark per la 6° linea.

 
pusheax:
Forse il problema non è sincronizzato, una nuova barra dovrebbe preferibilmente essere tracciata su tutti gli strumenti in uso.
Обработчик события "новый бар"
Обработчик события "новый бар"
  • 2010.10.04
  • Konstantin Gruzdev
  • www.mql5.com
Язык программирования MQL5 позволяет решать задачи на совершенно новом уровне. Даже те задачи, которые уже вроде имеют решения, благодаря объектно-ориентированному программированию могут подняться на качественно новый уровень. В данной статье специально взят простой пример проверки появления нового бара на графике, который был преобразован в достаточно мощный и универсальный инструмент. Какой? Читайте в статье.
 
Swan 2012.03.19 13:34

Forse il problema non è sincronizzato, è consigliabile seguire la nuova barra su tutti gli strumenti in uso.

Sì, hai avuto ragione, grazie!

 
Non capisco. O ho un problema o non ce l'ho. Quando ho cliccato su "rispondi" nella finestra dell'editor che è apparsa, il post in questione è stato duplicato come citazione. Ora, un paio di giorni fa, questa caratteristica è sparita. Apre una finestra vuota. Provato in Opera e IE.
 
Allo stesso modo, l'opera.
 
220Volt:
Allo stesso modo, l'opera.
Sto bene in FF.