Bid && Ask && Spread - pagina 4

[Renat Fatkhullin]

hrenfx:

Puoi rispondere onestamente quali sono le ragioni per usare OHLC Bid + Spread, invece di OHLC Bid + OHLC Ask? Memorizzare 8 numeri invece di 5 (il formato della barra e della storia è difficile da cambiare)? Avrà un impatto significativo sulla quantità di storia fornita? O forse non hai una cronologia dei prezzi Ask? La logica del tester diventa più complicata? Bene, nel secondo caso è ancora più semplice - non c'è affatto il concetto di spread. Cosa lo ferma, sii onesto.

Ladimensione della struttura della barra è la caratteristica più significativa che influenza proporzionalmente la quantità di risorse consumate dal terminale.

Siamo sempre di fronte al compito di risparmiare risorse, quindi l'espansione in questa forma non è appropriata.

[hrenfx]

La dimensione di MqlRates:

struct MqlRates
  {
   datetime time;         // время начала периода
   double   open;         // цена открытия
   double   high;         // наивысшая цена за период
   double   low;          // наименьшая цена за период
   double   close;        // цена закрытия
   long     tick_volume;  // тиковый объем
   int      spread;       // спред
   long     real_volume;  // биржевой объем 
  };

Equivale (se non mi sbaglio) a 46 byte.

La dimensione della struttura alternativa:

struct MqlRates
  {
   datetime time;         // время начала периода

   double   openBid;      // цена открытия Bid
   double   highBid;      // наивысшая цена за период Bid
   double   lowBid;       // наименьшая цена за период Bid
   double   closeBid      // цена закрытия Bid

   double   openAsk;      // цена открытия Ask
   double   highAsk;      // наивысшая цена за период Ask
   double   lowAsk;       // наименьшая цена за период Ask
   double   closeAsk      // цена закрытия Ask

   long     tick_volume;  // тиковый объем
   long     real_volume;  // биржевой объем 
  };

Pari a 76 byte.

Cioè, stiamo parlando del 65% di aumento del traffico durante il download della storia e del consumo di memoria da parte del terminale e del tester (compresi gli agenti) nel caso peggiore. Ovviamente, solo un 65% non può fermarvi. Le ragioni sono chiaramente diverse.

[[Eliminato]]

hrenfx:

Se non credi alle parole del tuo avversario, che senso ha parlare?

[hrenfx]

E se credi a tutto quello che dice il tuo avversario, che senso ha parlare? Non andare agli estremi.

[Vladimir Gomonov]

hrenfx:

La dimensione di MqlRates:

Equivale (se non mi sbaglio) a 46 byte.

La dimensione della struttura alternativa:

Pari a 76 byte.

Cioè, stiamo parlando del 65% di aumento del traffico durante il download della storia e del consumo di memoria da parte del terminale e del tester (compresi gli agenti) nel caso peggiore. Ovviamente, solo un 65% non può fermarvi. Le ragioni sono chiaramente diverse.

Ho 48 byte:

struct MqlRates
  {
   datetime time;         // время начала периода
  
   double   Base;          // базовая цена бара.  Все остальные цены отсчитываются от базы в пипсах 

   short     openBid;      // цена открытия Bid
   short     highBid;      // наивысшая цена за период Bid
   short     lowBid;       // наименьшая цена за период Bid
   short     closeBid      // цена закрытия Bid

   short     openAsk;      // цена открытия Ask
   short     highAsk;      // наивысшая цена за период Ask
   short     lowAsk;       // наименьшая цена за период Ask
   short     closeAsk      // цена закрытия Ask


   long     tick_volume;  // тиковый объем
   long     real_volume;  // биржевой объем 
  };

Chi dice che lo shorting non è sufficiente - che sia il primo a lanciarmi almeno un esempio (dalla borsa o dal forex comunque).

[Vladimir Kustikov]

Renat:

Ladimensione della struttura della barra è la caratteristica più significativa che influenza proporzionalmente la quantità di risorse consumate dal terminale.

Siamo sempre di fronte al compito di risparmiare risorse, quindi una proroga in questa forma non è appropriata.

Renat, ci sono stati dei tentativi di ottimizzare la struttura diMqlRates? Per esempio, perché abbiamo bisogno di valori di precisione doppia (8 byte) di OLHC, se la precisione è ora limitata a un massimo di cinque cifre decimali? Perché non memorizzare questi valori come int normalizzati a 3 o 5 cifre, che occupano la metà della memoria?

Ilvalore massimo che può essere scritto con questo approccio è 42949.67295.

C'è qualche dato forex OLHC che va oltre questo limite?

[---]

Vladix:

Ci sono dati OLHC sul forex che vanno oltre questo confine?

Perché solo il forex? la piattaforma non serve solo i simboli del forex.

[hrenfx]

MetaDriver:

Ho 48 byte:

Chi dice che lo short non è sufficiente - sia il primo a tirarmi almeno un esempio (dalla borsa o dal forex comunque).

hrenfx:

Cioè stiamo parlando di un aumento del 65% del traffico per scaricare la storia e il consumo di memoria da parte del terminale e del tester (compresi gli agenti) nel caso peggiore.

È chiaro che gli sviluppatori utilizzano una trasformazione simile della struttura originale prima di comprimere i dati per trasferire la storia, il che si traduce in un enorme rapporto di compressione. Ma resta il fatto che anche se non fai niente, niente di niente, il peggio che puoi ottenere è un 65% in più.

[Vladimir Gomonov]

Vladix:

Per esempio, perché i valori OLHC hanno bisogno di una precisione doppia (8 byte) se .....................

Questo è a proposito, SÌ.

   double   Base;          // базовая цена бара.  Все остальные цены отсчитываются от базы в пипсах 

potrebbe benissimo essere sostituito da

   float     Base;          // базовая цена бара.  Все остальные цены отсчитываются от базы в пипсах 

e non ci sarà NESSUNO interessato. poi la dimensione torna magicamente a 46 byte. bello, vero :)

[Vladimir Kustikov]

MetaDriver:

Ho 48 byte:

Chi dice che lo short non è sufficiente - sia il primo a tirarmi almeno un esempio (dalla borsa o dal forex comunque).

Penso che se le candele saranno un grande intervallo (mese o anno), sarà possibile trovare un esempio, anche se non lo affermerò...