Bid && Ask && Spread - page 4

[Renat Fatkhullin]

hrenfx:

Can you honestly answer what are the reasons for using OHLC Bid + Spread, versus OHLC Bid + OHLC Ask? Storing 8 numbers instead of 5 (bar and history format is difficult to change)? Will it have a significant impact on the amount of history provided? Or maybe you just don't have an Ask price history? Does the logic of the tester become more complicated? Well, in the second case it is even simpler - there is no concept of spread at all. What is stopping it, be honest.

The size of the barstructure is the most significant characteristic that proportionally affects the amount of resources consumed by the terminal.

We are always faced with the task of saving resources, so expansion in this form is not appropriate.

[hrenfx]

The size of MqlRates:

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

Equals (if I'm not mistaken) 46 bytes.

The size of the alternative structure:

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;  // биржевой объем 
  };

Equals 76 bytes.

I.e., we are talking about 65% increase in traffic during history downloading and memory consumption by the terminal and tester (including agents) in the worst case. Obviously, just some 65% cannot stop you. The reasons are clearly different.

[[Deleted]]

hrenfx:

If you don't believe your opponent's words, what's the point of talking?

[hrenfx]

And if you believe everything your opponent says, what's the point of talking? Don't go to extremes.

[Vladimir Gomonov]

hrenfx:

The size of MqlRates:

Equals (if I'm not mistaken) 46 bytes.

The size of the alternative structure:

Equals 76 bytes.

I.e., we are talking about 65% increase of traffic during history downloading and memory consumption by the terminal and tester (including agents) in the worst case. Obviously, just some 65% cannot stop you. The reasons are clearly different.

I got 48 bytes:

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;  // биржевой объем 
  };

Whoever says that shorting is not enough - let him be the first to throw at me at least one example (from the stock exchange or forex anyway).

[Vladimir Kustikov]

Renat:

The size of the barstructure is the most significant characteristic that proportionally affects the amount of resources consumed by the terminal.

We are always faced with the task of saving resources, so an extension in this form is not appropriate.

Renat, have there been any attempts to optimize the structure ofMqlRates? For example, why do we need double (8 bytes) precision values of OLHC, if the precision is now limited to a maximum of five decimal places? Why not store these values as normalized to 3 or 5 digits int, which takes up half as much memory?

The maximum value that can be written with this approach is 42949.67295.

Is there any OLHC forex data that will go beyond this limit?

[---]

Vladix:

Is there OLHC data on forex that will go beyond this boundary?

why only forex? the platform does not only serve forex symbols.

[hrenfx]

MetaDriver:

I got 48 bytes:

Whoever says that short is not enough - let him be the first to throw at me at least one example (from stock exchange or forex anyway).

hrenfx:

I.e. we are talking about a 65% increase in traffic for downloading history and memory consumption by the terminal and tester (including agents) in the worst case.

It is clear that the developers use a similar transformation of the original structure before compressing the data to transfer the history, which results in a huge compression ratio. But the fact remains that even if you do nothing, nothing at all, the worst you can get is an extra 65%.

[Vladimir Gomonov]

Vladix:

For example, why do you need double (8 bytes) precision for OLHC values if .....................

That's by the way, YES.

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

could very well be replaced by

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

and there will be NO ONE affected. then the size magically returns to 46 bytes. nice, isn't it :)

[Vladimir Kustikov]

MetaDriver:

I got 48 bytes:

Whoever says that short is not enough - let him be the first to throw at me at least one example (from stock exchange or forex anyway).

I think that if the candles will be a large interval (month or year), an example will be possible to find, although I will not assert...