In generale, quando si confrontano due numeri di tipo doppio, si raccomanda di prendere la loro differenza e confrontarla con il valore di soglia ammissibile. Ma di solito confronto direttamente - non ho mai avuto problemi.
tol64: Forse si può provare a determinare in qualche modo la frequenza delle lacune? Conta le lacune per un certo periodo.
Ci sono molti modi per essere contorti. Ma non ne vedo nessuno che sia veramente affidabile. Perché non esiste un vero criterio per giudicare l'"autenticità" dei dati di ogni barra.
Tutti i grafici sono basati su barre di minuti. Potrebbe essere calcolato programmaticamente fino alla data in cui l'orizzonte temporale appropriato può essere costruito correttamente. Ma anche qui c'è un "però". Tuttavia, neanche i TF minuti sono corretti per tutta la profondità della storia:
Non so, IMHO, abbiamo bisogno di un meccanismo standard per l'identificazione di tali limiti, qualcosa come questo
int Correct_Boundary_of_Timeframe
(
string symbol_name, // имя символаENUM_TIMEFRAMES timeframe // период
);
-restituisce l'indice dell'ultima barra valida del simbolo richiesto del TF richiesto.
Ci sono molti modi per essere contorti. Ma non ne vedo nessuno che sia veramente affidabile. Perché non esiste un vero criterio per giudicare l'"autenticità" dei dati di ogni singola barra.
Tutti i grafici sono basati su barre di minuti. Potrebbe essere calcolata programmaticamente fino alla data in cui è possibile la creazione corretta di un vecchio lasso di tempo richiesto. Ma anche qui c'è un "però". Tuttavia, anche i TF minuti non sono corretti per tutta la profondità della storia:
Non so, penso che abbiamo bisogno di un meccanismo speciale per definire tali limiti, qualcosa come
-restituisce l'indice dell'ultima barra corretta del simbolo richiesto del TF richiesto.
Quindi, se non vi dispiace leggere tutta la storia al passato, allora non vedo il problema. Trova il tempo di apertura e di chiusura di ogni barra e guarda il numero di secondi in questi intervalli intra-barra. Se meno del previsto, scrivere una barra "falsa". Questo sarà il punto di svolta, dopo il quale tutte le altre barre saranno incomplete. Non ha senso perlustrare ulteriormente.
Sì, da solo. In linea di principio, potrei postare il codice in MQL5 per il calcolo.
Per favore, ditemi come confrontare correttamente Double ( == < > ). Deve essere normalizzato? Per esempio, c'era una tale funzione in MT4:
ConfrontaDoppia(doppio numero1,doppio numero2)
{
se(NormalizeDouble(number1-number2,8)==0) return(true);
else return(false);
}
E in generale, qual è l'algoritmo approssimativo della funzione NormalizeDouble()?
Per favore, ditemi come confrontare correttamente Double ( == < > ). Deve essere normalizzato? Per esempio, in MT4 c'era una tale funzione:
ConfrontaDoppia(doppio numero1,doppio numero2)
{
se(NormalizeDouble(number1-number2,8)==0) return(true);
else return(false);
}
Per favore, ditemi come confrontare correttamente Double ( == < > ). Deve essere normalizzato? Per esempio, c'era una tale funzione in MT4:
ConfrontaDoppia(doppio numero1,doppio numero2)
{
se(NormalizeDouble(number1-number2,8)==0) return(true);
else return(false);
}
E in generale, qual è l'algoritmo approssimativo della funzione NormalizeDouble()?
Si sa che all'inizio del grafico la storia non è corretta, la domanda "perché non è corretta" non si pone.
Sorge un'altra domanda: come possiamo determinare programmaticamente il confine oltre il quale seguono i dati storici errati?
La linea verticale rossa mostra il confine.
Si sa che all'inizio del grafico la storia non è corretta, la domanda "perché non è corretta" non si pone.
Sorge un'altra domanda: come possiamo determinare programmaticamente il confine oltre il quale seguono i dati storici errati?
La linea verticale rossa mostra il confine.
Forse si può provare a determinare in qualche modo la frequenza delle lacune? Conta le lacune per un certo periodo.
Ci sono molti modi per essere contorti. Ma non ne vedo nessuno che sia veramente affidabile. Perché non esiste un vero criterio per giudicare l'"autenticità" dei dati di ogni barra.
Tutti i grafici sono basati su barre di minuti. Potrebbe essere calcolato programmaticamente fino alla data in cui l'orizzonte temporale appropriato può essere costruito correttamente. Ma anche qui c'è un "però". Tuttavia, neanche i TF minuti sono corretti per tutta la profondità della storia:
Non so, IMHO, abbiamo bisogno di un meccanismo standard per l'identificazione di tali limiti, qualcosa come questo
-restituisce l'indice dell'ultima barra valida del simbolo richiesto del TF richiesto.
Non so, IMHO, abbiamo bisogno di un meccanismo interno per definire tali limiti, qualcosa come
-restituisce l'indice dell'ultima barra valida dello strumento richiesto del TF richiesto.
-restituisce l'indice dell'ultima barra valida dello strumento richiesto del TF richiesto.
Ci sono molti modi per essere contorti. Ma non ne vedo nessuno che sia veramente affidabile. Perché non esiste un vero criterio per giudicare l'"autenticità" dei dati di ogni singola barra.
Tutti i grafici sono basati su barre di minuti. Potrebbe essere calcolata programmaticamente fino alla data in cui è possibile la creazione corretta di un vecchio lasso di tempo richiesto. Ma anche qui c'è un "però". Tuttavia, anche i TF minuti non sono corretti per tutta la profondità della storia:
Non so, penso che abbiamo bisogno di un meccanismo speciale per definire tali limiti, qualcosa come
-restituisce l'indice dell'ultima barra corretta del simbolo richiesto del TF richiesto.