Errori, bug, domande - pagina 673
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
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.
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:
Come risultato della sottoquotazione automatica dell'indicatore noi
Descriverò le condizioni del test:
Come risultato della sottoquotazione automatica dell'indicatore noi:
1.
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.
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.
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.
Forse il problema non è sincronizzato, è consigliabile seguire la nuova barra su tutti gli strumenti in uso.
Sì, hai avuto ragione, grazie!
Allo stesso modo, l'opera.