![MQL5 - Linguagem para estratégias de negociação inseridas no terminal do cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
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.
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>):
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)
Considerar TF[i], definir Visibilidade[i]...
ou visibilidade=(int)(MathPow(2,i+1)-1));
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...
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.
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...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:
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.
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...)
Não consigo perceber o que está errado.
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
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
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.