Argomento interessante per molti: cosa c'è di nuovo in MetaTrader 4 e MQL4 - grandi cambiamenti in arrivo - pagina 50

 
hrenfx:

Allora è condiscendenza (attenzione a queste cose - peggio della critica nuda e cruda):

:-)

È un po' tardi per me per bere borjomi o per fare ammenda. Un posto all'inferno è stato a lungo riservato per me.

Non credo che cercare di capire senza giudicare sia il più grave dei miei peccati. ;)

 
MetaDriver:
Esiste una tale lettera. Tuttavia, il gap (salto discontinuo di quotazione) può avvenire in qualsiasi momento, non solo all'inizio della barra. Quindi, qualsiasi formato "assottigliato" non è senza peccato, per definizione. L'alimentazione completa solo in tick. E nella storia della tazza potrebbe essere ancora più piena. Sto cercando di fare un formato minuto per me, finora ho trovato un tale compromesso.Posso lasciarlo come descritto sopra (senza Open, solo {Hi-Lo-Close}), capisco tutti gli inconvenienti, è solo una versione della mia codifica per il mio tester. Userò ticks grezzi o li ridurrò artificialmente con qualsiasi metodo (con ticks salvati formato {bid-ask-time}).
Sì, i bar erano originariamente costruiti per giorni. Per loro, la chiusura e l'apertura sono importanti e le lacune sono frequenti. Sui tf o c più piccoli non sono importanti. Forse l'apertura e la chiusura delle sessioni giocano ancora un ruolo, ma certamente non i minuti) imha
 
MetaDriver:

Non credo che cercare di capire senza giudicare sia il più grave dei miei peccati. ;)

Il pensiero - in termini di gravità del peccato, naturalmente - è il più grande. Sono d'accordo.
 
hrenfx:
Pensare, in termini di gravità del peccato, naturalmente, è più forte. Sono d'accordo.

Mi fa piacere che tu l'abbia capito bene, quindi è meglio che ti procuri un calderone vicino al mio, ci darà un sacco di tempo per chiacchierare. Niente libertà vigilata.

;)

 
MetaDriver:

Siete sicuri che le barre MQ M1 sono memorizzate senza imballaggio?

Allora come mai ci sono ritardi nell'ottenere la storia (piccoli ma ci sono), ma riapplicare (come nella cache) è più veloce.

Apparentemente nel file di cronologia le barre sono memorizzate come modifiche da synchrobar, quelle in forma compressa.

Quindi il vostro conteggio di 52 byte è un conteggio della storia spacchettata.

 
Urain:

Siete sicuri che le barre MQ M1 sono memorizzate senza imballaggio?

Allora come mai ci sono ritardi nell'ottenere la storia (piccoli ma ci sono), ma riapplicare (come nella cache) è più veloce.

Apparentemente nel file di cronologia le barre sono memorizzate come modifiche da synchrobar, quelle in forma compressa.

Quindi il tuo calcolo sui 52 byte è un calcolo della storia spacchettata.

Non ho detto nulla su questo, non solo - sono sicuro che c'è un imballaggio. Il formato non è dichiarato al pubblico, e non ho cercato di "craccarlo".

Quindi tutto è corretto, ho descritto solo il formato scompattato. È preso dalla documentazione.

 
MetaDriver:

Non ho detto niente di questo, non solo, sono sicuro che è pieno. Il formato non è stato annunciato pubblicamente e non ho cercato di "craccarlo".

Quindi è così, ho solo il formato scompattato descritto. È preso dalla documentazione.

È vero, ma stai cercando di dimostrare che il nuovo formato sarà economico, mentre confronti il formato attuale spacchettato e quello nuovo parzialmente confezionato.
 
Urain:
È vero, ma stai cercando di dimostrare che il nuovo formato sarà parsimonioso, mentre confronti l'attuale formato non imballato e quello nuovo parzialmente imballato.
Non sto paragonando l'economia, lo stai immaginando, solo informativo. Non c'è economia, il mio formato spacchettato è più grande == 88 byte {Open, High, Low, Close} e == 72 byte {High, Low, Close}.
 
MetaDriver:
Non sto paragonando l'economia, hai immaginato, solo l'informatività. Nessuna economia, il mio formato spacchettato è più == 88 byte {Open, High, Low, Close} e == 72 byte {High, Low, Close}.

Beh, non avresti dovuto prendere il cancro dalla pietra. Avrei suggerito solo di raddoppiare l'informatività invece di 52 byte 88.

Lo stesso dall'inizio hrenfx ha suggerito.

 

Perché esiste un formato con così tanti dati? Cioè è necessario definire le limitazioni di questo filtro tick (questo formato), quando non differisce il risultato dalla pura storia tick.

A prima vista, un semplice filtro tick HighBid+LowAsk non è molto peggiore di quello intelligente (secondo la quantità di dati).

Close-data è buono solo per la sincronizzazione multicurrency.

Forse, è più facile passare a un lasso di tempo più piccolo invece di fare questo. Per esempio, S20 richiede solo 48 byte per lo stesso minuto nel formato HighBid+LowAsk (forse anche meno, se 4 byte per prezzo sono più che sufficienti). Nel mio tester, faccio tutto tramite long int - molto veloce). E in termini di precisione, il 100% batterà il vostro filtro minuto di 88 byte.

P.S. La funzione Error(Freq, DataSize) = Full - Freq * DataSize tende a zero, quando aumenta Freq,

dove l'errore è la perdita di informazioni.

Completo - informazioni di mercato complete.

Freq * DataSize è una funzione di "moltiplicazione": la quantità di informazioni che possono essere recuperate con la frequenza di quantizzazione Freq, e il contenuto informativo(DataSize) per ogni termine di quantizzazione.