Erros, bugs, perguntas - página 616

[Serj]

Pergunta para programadores:

Porque é que no testador não é possível obter o campo da estrutura

PreçoMqlTradeResult;// Preço numa transacção, confirmado pelo corretor? Dá 0.

Funciona bem em demonstração.

[Victor Kirillin]

x100intraday:

Existe alguma relação entre a estrutura da lista de prazos e as bandeiras de visibilidade dos objectos (porque mesmo a extensão das listas é diferente: 22 vs 23)? Em geral, peço a fim de atribuir de forma eficiente e compacta a visibilidade dos objectos em períodos de tempo num ciclo com determinados limites, em vez de listar e resumir manualmente as bandeiras. Que lógica utilizar se um prazo arbitrário for tomado ao acaso, um objecto gráfico é construído sobre ele e tem de ser permitido ser visível em todos os prazos não mais antigos do que o actual (isto é, o que foi construído sobre ele)? O algoritmo deve ser universal, e não para um caso em particular. A correlação do índice já está aparafusada, não há sequer uma correspondência do índice. Parsing strings de nomes e comparação é novamente um fracasso devido à impossibilidade de lidar com strings em caso de constantes de visibilidade. Até agora, vem-me à mente uma implementação complicada, vaga e muito tortuosa.

Claro que existe uma correlação, mas é tão implícita que a única forma de escrever <flag_visibilidade> = F(<tempo>):

int PeriodToTimeframeFlag(ENUM_TIMEFRAMES period)
  {
   flags=0;
   static ENUM_TIMEFRAMES _p_int[]={PERIOD_M1, PERIOD_M2, PERIOD_M3, PERIOD_M4, PERIOD_M5, PERIOD_M6,
                                    PERIOD_M10,PERIOD_M12,PERIOD_M15,PERIOD_M20,PERIOD_M30,
                                    PERIOD_H1, PERIOD_H2, PERIOD_H3, PERIOD_H4, PERIOD_H6, PERIOD_H8,PERIOD_H12,
                                    PERIOD_D1, PERIOD_W1, PERIOD_MN1};
//--- cycle for all timeframes
   for(int i=0;i<ArraySize(_p_int);i++)
      if(period==_p_int[i])
        {
         //--- at the same time generate the flag of the working timeframe
         flags=((int)1)<<i;
         break;
        }
   return(flags);
  }

[Aleksey Lebedev]

x100intraday:

Que lógica utilizar se tomarmos ao acaso um período de tempo arbitrário, construirmos um objecto gráfico sobre ele e precisarmos de permitir a sua visibilidade em todos os períodos de tempo não mais antigos do que o actual (ou seja, aquele em que foi construído)?

se não for um verificador)

ENUM_TIMEFRAMES TF[21]={PERIOD_M1,PERIOD_M2,PERIOD_M3,PERIOD_M4,PERIOD_M5,PERIOD_M6,PERIOD_M10,
                     PERIOD_M12,PERIOD_M15,PERIOD_M20,PERIOD_M30,PERIOD_H1,PERIOD_H2,PERIOD_H3,
                     PERIOD_H4,PERIOD_H6,PERIOD_H8,PERIOD_H12,PERIOD_D1,PERIOD_W1,PERIOD_MN1};

int Visibility[21]={1,3,7,15,31,63,127,255,511,1023,2047,4095,8191,
            16383,32767,65535,131071,262143,524287,1048575,2097151};

Considerar TF[i], definir Visibilidade[i]...

ou visibilidade=(int)(MathPow(2,i+1)-1));

[x572intraday]

Swan:

Se precisar dele, então não é um tabuleiro de xadrez)

Considerar TF[i], definir Visibilidade[i]...

ou visibilidade=(int)(MathPow(2,i+1)-1));

Obrigado pela fórmula de Visibilidade - talvez eu a adapte. Era óbvio a partir de valores sobre prazos, que é um grau de alguma coisa, mas eu próprio não tentei reconstruir a fórmula.

É necessário -1? Em geral, a Visibilidade[] parece estar cheia de valores incorrectos, de facto deveria estar em todo o lado sem -1, ou seja: 1, 2, 4, 8, 16...

[x572intraday]

uncleVic:

Claro que existe uma relação, mas é tão implícita que a única forma de escrever <flag_visibilidade>=F(<tempo>) é fazê-lo dessa forma:

Obrigado, elegante. Era exactamente isso que eu estava a tentar fazer, excepto o turno em si, que é exactamente o que me faltava.

E no final, abordei a questão do cálculo dos valores das bandeiras em cada volta do ciclo de regressão ao longo de uma série de intervalos de tempo _p_int (no final, algo terá de ser acrescentado nas bandeiras), e não apenas na actual. Bem, ao deslocar o valor da bandeira de visibilidade no período de tempo actual, e depois com cada rotação de i... algo deve mudar em algum lugar... Ou a fórmula de exponenciação deve ser aí aplicada ou deve ser utilizado o mesmo princípio de turno. Ainda não descobri como...

... Apesar de, sim, ser uma função com o objectivo da TF - Vou tentar fazer um loop...

No entanto, está novamente errado. Deixem-me explicar. No exemplo, há ENUM_TIMEFRAMES estáticos _p_int[] para 21 itens, mas eis o que eu quero: já tenho tal matriz, mas pode ser de qualquer comprimento. É uma matriz contendo os prazos, sobre os quais algo será construído. Mas também devem ser visíveis em todos os prazos inferiores e nenhuma das matrizes é preenchida com eles separadamente ou adicionalmente às existentes. Por isso, aqui menciono a necessidade de calcular as bandeiras da corrente e de todos os períodos de tempo inferiores e resumi-las no ciclo de regressão na mosca, dançando a partir do período de tempo actual. O truque não é criar um conjunto completo de valores predefinidos de nada (mesmo de prazos ou bandeiras de visibilidade) e brincar com eles, mas sim calcular na minha mente para cada volta apenas o conjunto incompleto de prazos predefinidos.

Irei por um tempo e se ficar preso, vou perguntar.

[x572intraday]

Porque não tenho pressa em usar (int)(MathPow(2,i+1)-1) ou ((int)1)<<<i... Se eu estiver lá, pode facilmente substituí-lo por um laço e correr... Mas, tal como em caso de multiplicação e mudança - será sempre seguro? Suponha que os programadores alguma vez acrescentem novos prazos, não se perderá toda a lógica? Logo à partida - no exemplo com um turno, esperamos que o período actual coincida com o pré-estabelecido:

if(period==_p_int[i])

portanto, mesmo que no caso real alguns prazos da sequência teoricamente completa sejam omitidos ou esta sequência seja prolongada pelos programadores, a lógica não deve rastejar. Mas se dependermos da matemática pura e correr o ciclo por fórmula de fronteira em fronteira, sem olhar a possíveis ausências ou presença de novos prazos, mais cedo ou mais tarde, na construção seguinte, ficaríamos enviesados...

[Victor Kirillin]

x100intraday:

Porque não tenho pressa em usar (int)(MathPow(2,i+1)-1) ou ((int)1)<<<i... Como estou lá, pode facilmente substituí-lo por um laço e correr. Mas, tal como em caso de multiplicação e mudança - será sempre seguro? Suponha que os programadores alguma vez acrescentem novos prazos, não se perderá toda a lógica? Mesmo fora do topo - no exemplo com um turno, esperamos que o período actual seja o mesmo que o pré-estabelecido:

portanto, mesmo que no caso real alguns prazos da sequência teoricamente completa sejam omitidos ou esta sequência seja prolongada pelos programadores, a lógica não se deve introduzir. Mas se nos basearmos na matemática pura e apenas correr o ciclo pela fórmula de fronteira a fronteira, sem prestar atenção a uma possível ausência ou presença de novos prazos, então, mais cedo ou mais tarde, na próxima construção, obteríamos um enviesamento...

As nossas preocupações são muito razoáveis. O código acima justifica o facto de a bandeira de visibilidade ser na realidade uma macro.

Seria mais correcto trabalhar com base nisso:

int result=0;
//---
switch(period)
  {
   case PERIOD_M1: result=OBJ_PERIOD_M1; break;
   case PERIOD_M2: result=OBJ_PERIOD_M2; break;
   case PERIOD_M3: result=OBJ_PERIOD_M3; break;
   case PERIOD_M4: result=OBJ_PERIOD_M4; break;
   case PERIOD_M5: result=OBJ_PERIOD_M5; break;

//--- и так далее

   default: print("Что-то новенькое");
  }

[Aleksey Lebedev]

x100intraday:

Obrigado pela fórmula de visibilidade - talvez eu a adapte. Pude ver pelos valores sobre os prazos que era um grau de algo, mas não tentei reconstruir a fórmula eu próprio.

Será -1 realmente necessário? Na verdade, a Visibilidade[] parece estar incorrectamente preenchida, de facto, deveria estar em todo o lado sem -1, ou seja, 1, 2, 4, 8, 16...

1,2,4 etc. - visibilidade do objecto num período de tempo. =MathPow(2,i);

sobre correntes e menores 1, 1+2, 1+2+4, 1+2+4+8 etc., taki =MathPow(2,i+1)-1;

É mais claro no código binário.

tioVic:

As apreensões são muito razoáveis. O código acima só justifica o facto de o conjunto de bandeiras de visibilidade ser na realidade uma macro.

A forma correcta é trabalhar através dele:

A mesma coisa em princípio. Se mudar na lista de af's, terá de editar o código.

Não consigo imaginar nenhuma solução universal, e suspeito que seja teoricamente impossível prever possíveis mudanças.

x100intraday:

Errado novamente, no entanto. Deixem-me explicar. No exemplo, ENUM_TIMEFRAMES _p_int[] estático é criado para 21 itens, mas aqui está o que eu quero: já tenho essa matriz, mas pode ser de qualquer comprimento. É uma matriz contendo os prazos, sobre os quais algo será construído. Mas também devem ser visíveis em todos os prazos inferiores e nenhuma das matrizes é preenchida com eles separadamente ou adicionalmente às existentes. Por isso, aqui estou a mencionar a necessidade de calcular as bandeiras do período de tempo actual e todos os períodos de tempo inferiores e somá-los no ciclo de regressão na mosca, dançando a partir do actual. O truque não é criar um conjunto completo de valores predefinidos de nada (mesmo de períodos de tempo ou bandeiras de visibilidade) e fazer loop através deles, mas sim calcular em cada volta apenas o conjunto incompleto de períodos de tempo predefinidos.

Não, não o fará. A correspondência de tempo e visibilidade tem de ser definida. Ou duas matrizes correspondentes, ou interruptor.

+array com as TFs de que necessita, +init calcula a visibilidade do objecto para cada TF que utiliza. Algo parecido com isto...)

[Serj]

Não consigo perceber o que está errado.

double VirtualSL;
MqlTick tick;
//+------------------------------------------------------------------+
//| Expert initialization function                                   |
//+------------------------------------------------------------------+
int OnInit()
  {
   VirtualSL=0.0;
   return(0);
  }
//+------------------------------------------------------------------+
//| Expert tick function                                             |
//+------------------------------------------------------------------+
void OnTick()
  {
   trail();
  }
//+------------------------------------------------------------------+
void trail()
  {
   double stopcal;

   SymbolInfoTick(_Symbol,tick);
   stopcal=tick.bid;

//   if((VirtualSL!=0.0 && stopcal>VirtualSL) || VirtualSL==0.0) // так все работает

   if(VirtualSL==0.0 || (VirtualSL!=0.0 && stopcal>VirtualSL)) // так не хочет работать
     {
      VirtualSL=stopcal;
      Print("use Ok!");
     }
   if(VirtualSL<stopcal) Print("o_O ((((( stopcal = ",stopcal,"   VirtualSL = ",VirtualSL);
  }
//+------------------------------------------------------------------+

2011.12.29 01:16:07 Core 1 2011.09.26 02:54:13 o_O ((((( stopcal = 1.54508 VirtualSL = 1.53378

2011.12.29 01:16:07 Core 1 2011.09.26 02:54:12 o_O ((((( stopcal = 1.54507 VirtualSL = 1.53378

2011.12.29 01:16:07 Core 1 2011.09.26 02:54:12 o_O stopcal = 1.54508 VirtualSL = 1.53378

[Ilyas]

her.human:

Eu tenho o meu cérebro atordoado, não entendo o que está errado?

É um erro no optimizador do compilador. Obrigado pela sua mensagem, nós vamos corrigi-la.

O erro ocorre com a seguinte construção

if(VirtualSL==0.0 || (VirtualSL!=0.0 && stopcal>VirtualSL))
if(VirtualSL<stopcal)

VirtualSL!=0.0 pode ser removido da segunda parte da primeira se a condição forverificada, uma vez que esta expressão é sempre verdadeira após a primeira parte ser verificada. O erro do optimizador desaparecerá.


Corrigido, a correcção será incluída na próxima construção.