Licitações && Pergunte && Espalhe - página 4

[Renat Fatkhullin]

hrenfx:

Pode responder honestamente quais são as razões para usar OHLC Bid + Spread, versus OHLC Bid + OHLC Ask? Armazenar 8 números em vez de 5 (o formato de barra e histórico é difícil de alterar)? Terá um impacto significativo sobre a quantidade de história fornecida? Ou talvez simplesmente não tenha um histórico de preços Ask? A lógica do testador torna-se mais complicada? Bem, no segundo caso é ainda mais simples - não existe qualquer conceito de propagação. O que a está a impedir, seja honesto.

O tamanho da estrutura da barra é a característica mais significativa que afecta proporcionalmente a quantidade de recursos consumidos pelo terminal.

Somos sempre confrontados com a tarefa de poupar recursos, pelo que a expansão sob esta forma não é apropriada.

[hrenfx]

O tamanho dos MqlRates:

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

Igual (se não estou enganado) 46 bytes.

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

Equivale a 76 bytes.

Ou seja, estamos a falar de um aumento de 65% no tráfego durante o descarregamento do histórico e no consumo de memória pelo terminal e pelo testador (incluindo agentes) no pior dos casos. Obviamente, apenas cerca de 65% não o podem deter. As razões são claramente diferentes.

[[Excluído]]

hrenfx:

Se não acredita nas palavras do seu oponente, de que serve falar?

[hrenfx]

E se acredita em tudo o que o seu oponente diz, qual é o sentido de falar? Não vá a extremos.

[Vladimir Gomonov]

hrenfx:

O tamanho dos MqlRates:

Igual (se não estou enganado) 46 bytes.

O tamanho da estrutura alternativa:

Equivale a 76 bytes.

Ou seja, estamos a falar de um aumento de 65% no tráfego durante o descarregamento do histórico e no consumo de memória pelo terminal e pelo testador (incluindo agentes) no pior dos casos. Obviamente, apenas cerca de 65% não o podem deter. As razões são claramente diferentes.

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

Quem disser que não basta encurtar - que seja o primeiro a atirar-me pelo menos um exemplo (da bolsa de valores ou forex de qualquer forma).

[Vladimir Kustikov]

Renat:

O tamanho da estrutura da barra é a característica mais significativa que afecta proporcionalmente a quantidade de recursos consumidos pelo terminal.

Somos sempre confrontados com a tarefa de poupar recursos, pelo que uma extensão sob esta forma não é apropriada.

Renat, houve alguma tentativa de optimizar a estrutura dosMqlRates? Por exemplo, porque precisamos de valores de precisão duplos (8 bytes) de OLHC, se a precisão está agora limitada a um máximo de cinco casas decimais? Porque não armazenar estes valores como normalizados a 3 ou 5 dígitos int, o que ocupa metade da memória?

O valor máximo que pode ser escrito com esta abordagem é 42949.67295.

Existe algum dado OLHC forex que vá além deste limite?

[---]

Vladix:

Existem dados OLHC sobre Forex que vão para além deste limite?

porquê apenas forex? a plataforma não serve apenas símbolos forex.

[hrenfx]

MetaDriver:

Recebi 48 bytes:

Quem disser que curto não é suficiente - que seja o primeiro a atirar-me pelo menos um exemplo (da bolsa de valores ou forex de qualquer forma).

hrenfx:

Ou seja, estamos a falar de um aumento de 65% no tráfego para descarregar o histórico e o consumo de memória pelo terminal e pelo testador (incluindo agentes) no pior dos casos.

É evidente que os criadores utilizam uma transformação semelhante da estrutura original antes de comprimir os dados para transferir o histórico, o que resulta numa enorme taxa de compressão. Mas o facto é que mesmo que não se faça nada, nada mesmo, o pior que se pode obter é um extra de 65%.

[Vladimir Gomonov]

Vladix:

Por exemplo, porque é que os valores OLHC precisam de uma precisão dupla (8 bytes) se .....................

A propósito, SIM.

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

poderia muito bem ser substituído por

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

e não haverá NENHUM afetado. então o tamanho retorna magicamente a 46 bytes. bom, não é :)

[Vladimir Kustikov]

MetaDriver:

Recebi 48 bytes:

Quem disser que curto não é suficiente - que seja o primeiro a atirar-me pelo menos um exemplo (da bolsa de valores ou forex de qualquer forma).

Penso que se as velas forem um grande intervalo (mês ou ano), será possível encontrar um exemplo, embora eu não o afirme...