FORTI Si prega di aiutare - pagina 9

Nuovo commento
 
komposter:

Qual è la differenza tra "non" e "non pronto" per il programma (e il programmatore)?

Se i dati non sono pronti, ci sarà un errore.

O forse anche questa informazione non è immediatamente disponibile, ed è per questo che non viene mostrata.

E per evitare di "entrare" nel server.

Inoltre, tu sei il nostro "lettore"... Domanda:

Perché costruiscono le serie temporali se i dati sono pronti ( CopyTime(symbol,period,first_date+PeriodSeconds(period),1,times) )?

Если мы успешно прошли все проверки, то сделаем последнюю попытку обойтись без обращения к торговому серверу. Сначала узнаем начальную дату, для которой доступны минутные данные в формате HCC.
Запросим это значение функцией SeriesInfoInteger() с модификатором SERIES_TERMINAL_FIRSTDATE и опять сравним со значением параметра start_date.

   if(SeriesInfoInteger(symbol,PERIOD_M1,SERIES_TERMINAL_FIRSTDATE,first_date))
     {
      //--- there is loaded data to build timeseries
      if(first_date>0)
        {
         //--- force timeseries build                                            
         CopyTime(symbol,period,first_date+PeriodSeconds(period),1,times);
         //--- check date
         if(SeriesInfoInteger(symbol,period,SERIES_FIRSTDATE,first_date))
            if(first_date>0 && first_date<=start_date) return(2);
        }
     }
 
MigVRN:
Proprio così - carica e prepara quello che c'è. Ma a causa del fatto che qualsiasi ritardo nell'indicatore rallenta la chat con tutto ciò che pende su di essa - abbiamo fatto in modo che negli indicatori se la serie non è pronta al momento della chiamata - la funzione restituisca un errore e INIZIALIZZI la preparazione dei dati. Dopo un po' non restituirà più un errore. Questo è quello che succede nei vostri registri.

MigVRN!

Chukcha ha riletto l'aiuto e non è d'accordo con te.

"Esatto -carica e prepara quello che c'è".

Questa è la tua speculazione....

Ma l'aiuto dice che la funzione SeriesInfoInteger con identificatoreSERIES_TERMINAL_FIRSTDATE

Dovrebbe tornare:

DATA_PRIMA_SERIE

Prima data nella storia per simbolo nel terminale del cliente indipendentemente dal periodo

Non deve preparare nulla!

Ci sono dati nella cronologia del terminale - ottenere la data.

No - restituisce "0".

 
Un nuovo giorno e giro e giro ancora.
 
barabashkakvn:
Un nuovo giorno e giro e giro ancora.
Mostra nel riferimento, qualcosa di ALTRO
 
papaklass:
Preparare i dati e lavorare con essi. Puoi dire 150 volte che qualcosa non va e ottenere 150 risposte su cosa fare. È il tuo lavoro, quindi prenditi cura di te!

Grazie, ma lei sa molto bene che TUTTO deve essere provato.

SD pensa che restituire 0, quando i dati sono presenti, non sia un errore della loro funzione.

Se è così, DEVE essere scritto nella documentazione!

 

Mikalas:

Dovrebbe, non dovrebbe - non si parla d'altro. Beh, puoi vedere tu stesso come funziona :)

L'unica cosa su cui posso essere d'accordo è che non è molto chiaro quali dati sono pronti AT ONCE (disponibili in qualsiasi momento) e quali dati il terminale prepara quando vi si accede.

Io(!) capisco che quando si accede a qualsiasi dato di serie temporale (tempo e prezzo, numero di barre, enumerazioneENUM_SERIES_INFO_INTEGER, o forse ho dimenticato qualcos'altro), i dati non sono pronti subito.

Per evitare tali situazioni, è scritto nell'aiuto:

Poiché mql5-programma può accedere ai dati per qualsiasi simbolo e timeframe, c'è la possibilità che i dati di un timeframe richiesto non siano ancora stati generati nel terminale, o che i dati di prezzo richiesti non siano sincronizzati con il server di trading. In questo caso, il tempo di attesa della disponibilità dei dati è difficile da prevedere.

Glialgoritmi che utilizzano cicli di attesa di dati non sono la soluzione migliore. L'unica eccezione in questo caso - gli script, perché non hanno altra scelta di algoritmo, a causa della mancanza di elaborazione degli eventi. Per gli indicatori personalizzati tali algoritmi, così come qualsiasi altro ciclo di attesa, sono categoricamente sconsigliati, poiché portano all'arresto del calcolo di tutti gli indicatori e di altre elaborazioni di dati di prezzo per questo simbolo.

Per gli Expert Advisor e gli indicatori personalizzati è meglio usareil modello di elaborazionebasato sugli eventi. Se l'elaborazione degli eventi OnTick() o OnCalculate() non è riuscita a ottenere tutti i dati necessari della serie temporale richiesta, si dovrebbe lasciare il gestore dell'evento, sperando nella comparsa dell'accesso ai dati alla prossima chiamata del gestore.

 
MigVRN:

Dovrebbe, non dovrebbe - non si parla d'altro. Beh, potete vedere voi stessi come funziona :)

L'unica cosa su cui posso essere d'accordo è che non è molto chiaro quali dati sono pronti AT ONCE (disponibili in qualsiasi momento) e quali dati il terminale prepara quando vi si accede.

Io(!) capisco che quando si accede a qualsiasi dato di serie temporale (tempo e prezzo, numero di barre, enumerazioneENUM_SERIES_INFO_INTEGER, o forse ho dimenticato qualcos'altro), i dati non sono pronti subito.

Per evitare tali situazioni, è scritto nell'aiuto:

Poiché mql5-programma può accedere ai dati per qualsiasi simbolo e timeframe, c'è la possibilità che i dati di un timeframe richiesto non siano ancora stati generati nel terminale, o che i dati di prezzo richiesti non siano sincronizzati con il server di trading. In questo caso, il tempo di attesa della disponibilità dei dati è difficile da prevedere.

Glialgoritmi che utilizzano cicli di attesa per la disponibilità dei dati non sono la soluzione migliore. L'unica eccezione in questo caso - gli script, perché non hanno altra scelta di algoritmo, a causa della mancanza di elaborazione degli eventi. Per gli indicatori personalizzati tali algoritmi, così come qualsiasi altro ciclo di attesa, sono categoricamente sconsigliati, poiché portano all'arresto del calcolo di tutti gli indicatori e di altre elaborazioni di dati di prezzo per questo simbolo.

Per gli Expert Advisor e gli indicatori personalizzati è meglio usareil modello di elaborazionebasato sugli eventi. Se durante l'elaborazione degli eventi OnTick() o OnCalculate() non siete riusciti a ottenere tutti i dati necessari della serie temporale richiesta, dovreste uscire dal gestore dell'evento, aspettando di avere accesso ai dati durante la prossima chiamata del gestore.

Andrew!

Non so voi, ma io lavoro con la documentazione da molti anni.

Guarda, dalla documentazione segue, come ho(!) capito.

1. Controlliamo se ci sono dati storici per il simbolo nel terminale (SeriesInfoInteger con l'identificatoreSERIES_TERMINAL_FIRSTDATE)

Forse, non ne discuto, costruisce e inizializza qualcosa.

2. Nessun dato (restituisce una data di inizio della storia vuota) - va al server per i dati.

Se c'è una data, costruiamo il timeframe specificato usando la funzioneCopyTime(symbol,period,first_date+PeriodSeconds(period),1,times);

4. Controlliamo l'inizio della serie temporale con la data indicata(SeriesInfoInteger(symbol,period,SERIES_FIRSTDATE,first_date).

È scritto nella documentazione.

Ma quando io(!) chiedo i dati storici per simbolo(non per serie temporale!!!!) nel terminale, che sono ESATTAMENTE lì

restituisce "0".

Pensate che questo sia giusto?

 
Mikalas:

MA, quando io(!) chiedo i dati storici per simbolo(non per serie temporale!!!!) nel terminale, che è ESATTAMENTE lì

la funzione restituisce "0".

Pensate che questo sia giusto?

I dati (non preparati) sono su disco. I dati (preparati) possono essere sulla chat adiacente. Ma non ci sono dati preparati sulla chat che sta eseguendo l'indirezione. Quindi c'è un errore. È corretto. Ma non è conveniente :)

Anche se non mi piacciono queste domande - è critico per voi richiedere i dati dell'indicatore per i caratteri adiacenti? (tenendo conto di ciò che è scritto nell'aiuto e del mio esempio - come un indicatore può rallentare l'esecuzione di Expert Advisor e della chat). È possibile aggirare tutte queste difficoltà...

 
papaklass:

Stai chiedendo "FIRSDDATE", non dati. La data è probabilmente lì, ma i dati possono essere mancanti a causa dell'economia. Perché pompare dati per tutti i personaggi se non vengono utilizzati al momento. Gli sviluppatori hanno preso la strada razionale di pompare i dati solo quando l'utente accede a quei dati. Questo è l'approccio normale. Voi, lavorando con il terminale, dovreste SAPERE questo e agire di conseguenza.

Invece di sprecare il vostro tempo nel trading siete bloccati su cose elementari e state sprecando il vostro tempo. Risparmia il tuo tempo. :)

I robot stanno facendo trading per me, non sono a casa al momento...

E ho bisogno dell'indicatore solo per migliorare il mio trading :)

 
Mikalas:

Andrei!

Non so voi, ma io lavoro con la documentazione da molti anni.

Guarda, dalla documentazione segue, come io(!) capisco.

1. Vediamo se ci sono dati storici sul simbolo nel terminale (SeriesInfoInteger con identificatoreSERIES_TERMINAL_FIRSTDATE)

Forse, non ne discuto, costruisce e inizializza qualcosa.

2. Nessun dato (restituisce una data di inizio della storia vuota) - va al server per i dati.

Se c'è una data, costruiamo il timeframe specificato usando la funzioneCopyTime(symbol,period,first_date+PeriodSeconds(period),1,times);

4. Controlliamo l'inizio della serie temporale con la data indicata(SeriesInfoInteger(symbol,period,SERIES_FIRSTDATE,first_date).

È scritto nella documentazione.

Ma quando io(!) chiedo i dati storici per simbolo(non per serie temporale!!!!) nel terminale, che sono ESATTAMENTE lì

restituisce "0".

Pensate che questo sia giusto?

Leggete la documentazione con più attenzione, non in modo selettivo. La presenza di dati storici sul disco non significa "sicuramente lì" per il terminale. In questo caso (quando si accede dall'indicatore), le funzioni lavorano solo con la cache delle serie temporali in memoria. Significa che viene eseguito un accesso sincrono alla memoria e se non c'è una serie temporale preparata, la data SERIES_FIRSTDATE (del primo elemento dell'array) non verrà restituita. Ma naturalmente, la richiesta avvia la preparazione-caricamento delle serie temporali nella memoria.

La richiesta SERIES_TERMINAL_FIRSTDATE è collegata all'inizializzazione del database e alla sincronizzazione con il server, quindi la prima chiamata non funzionerà immediatamente.

In linea di principio, la capacità di ottenere la cronologia richiesta viene controllata utilizzando SERIES_SERVER_FIRSTDATE . Cioè si può naturalmente contare su X iterazioni di richiesta di storia, ma se il terminale conferma la presenza di storia tramite SERIES_SERVER_FIRSTDATE, allora la disponibilità di dati di serie temporali rilevanti è solo una questione di tempo (sincronizzazione del database m1 con il server e generazione di serie temporali).

12345678910111213141516...31
Nuovo commento