Erros, bugs, perguntas - página 2450
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
No entanto, diz exactamente a mesma coisa sobre tropeçar em macros. No entanto, é claro que vamos verificá-lo.
O desenvolvimento deste projecto ainda tem um enorme potencial, especialmente em termos de melhoria da linguagem utilizando os seus próprios recursos, porque muitas coisas no MQL ainda não foram implementadas e muitas coisas funcionam mal (bugs) e os programadores, como eu o entendo, não têm planos para melhorar nada na própria linguagem.
Para processar macros tenho de implementar uma camada adicional algures perto do início de toda a cadeia - descrever a gramática das macros, analisá-las na fonte einterpretá-las (obter fonte/valor de resultado para cada macro). Isto é complicado, e a aplicação só é necessária para alguns programadores de MQL, pelo que não há desenvolvimento.
Quanto à utilização de hash para identificar alterações nos produtos, não creio que esta seja uma solução (ou não faço ideia do caso de uso de que estamos a falar). Normalmente é necessário um ou dois anos após a geração de algum ex-arquivo para compreender que versão era um determinado módulo incorporado e a sua fonte. Para o fazer, provavelmente terá de ligar o processo de construção com sistemas de controlo de versões. O hashing não é uma opção.
Ajude-me com a OnTradeTransaction(). O comportamento descrito abaixo é normal? Verifiquei-o no testador - é assim :( E numa conta "ao vivo"?
OnTick() tem um laço que fecha as posições em ordem.
A OnTradeTrancaction() calcula o número de posições em aberto.
O Expert Advisor fá-lo desta forma: primeiro fecha o laço até ao fim, depois vai à OnTradeTransaction e efectua cálculos na mesma ordem.
Por outras palavras, não
а
ou seja, funciona sequencialmente em vez de em paralelo.
Se o acima descrito for normal, verifica-se que a OnTradeTransaction() só pode ser utilizada com segurança em Consultores Especialistas que abram/fechem apenas uma encomenda. Se houver uma grelha ou uma grelha com vários símbolos (ou uma grelha com vários símbolos, que é onde se encontra :) ) - o algoritmo avaria-se.
Citação da documentação
Um pedido de comércio enviado manualmente do terminal ou através das funções OrderSend()/OrderSendAsync() pode gerar várias transacções comerciais consecutivas no servidor de comércio. Além disso, a ordem de chegada destas transacções ao terminal não está garantida, pelo que não podemos construir o nosso algoritmo comercial na espera da chegada de uma transacção comercial atrás de outra.
Consequentemente, tudo será calculado, mas não na sequência esperada.
Pode explicar porque decidiu contar o número de posições na OnTradeTrancaction()? Se o cálculo não for organizado correctamente, então não podemos excluir que haja operações desnecessárias. Afinal, se fechar várias posições no laço, não há necessidade de recalcular todas elas depois de fechar cada posição. Basta contá-los uma vez após o laço estar terminado. Ou, organizar na OnTradeTrancaction() de tal forma que a quantidade aumente 1 quando o tipo IN é definido, e diminua quando o tipo OUT é definido. E mesmo neste caso, se a posição não for completamente fechada, deve ser tida em conta.
Pode explicar porque decidiu contar o número de posições na OnTradeTrancaction()?
Se contar com cada carrapato - é de recursos intensivos, especialmente perceptível no testador de estratégias. Não seria mais correcto contar apenas no evento Trade, ou seja, quando algo na lista de posições em aberto muda de facto? Com a OnTradeTransaction(), é mais fácil controlar a intervenção do utilizador na EA. (Há alguns precedentes :)
Neste robô estava a testar a possibilidade de fechar a grelha pelo esquema: Perda + lucro > X , depois fechar ambos (normalmente em símbolos diferentes). Mas ocorre uma falha, porque mesmo estando fechados, o testador não tem conhecimento disso, e prossegue para a iteração seguinte, "emparelhando" erradamente os existentes com os já fechados. Isto é, tive de acrescentar um novo cálculo após cada encerramento.
Tenho de recalcular com um contador de reset e, sobretudo, os abertos primeiro, não +1 / -1
Citação da documentação
Concordo, era demasiado arriscado utilizar inicialmente a OnTradeTransaction(). Na verdade, provavelmente recusá-la-ia nos casos em que os pedidos não fossem assíncronos - apenas problemas da mesma.
Para uma grelha com vários símbolos, a assíncronia é boa. É por isso que eu escolheria a segunda opção.
Já a pensar nessa direcção ;)
***
Neste robô, testei a possibilidade de fechar grelhas de acordo com o esquema: perda + lucro > X , depois fechar ambos (geralmente em símbolos diferentes).
***
Se souber que quer fechar exactamente estas duas posições, é melhor memorizar os bilhetes para estas posições, e fechá-las até as fechar (ATENÇÃO: não enquanto e Dorme - dê ordens para fechar, saia OnTick, verifique se há mais posições com estes bilhetes - se sim, tente fechá-las novamente e saia OnTick).
Se souber que precisa de fechar exactamente estas duas posições, é melhor lembrar-se dos tickers destas posições e fechá-las até as fechar (NOTA: não enquanto e Dorme - dê ordens para fechar, saia OnTick, verifique se há mais posições com estes tickers - se houver, então tente fechar novamente e saia OnTick).
Esta é uma ideia valiosa. Talvez o OnTick() forma um array com o bilhete e tenta fechá-lo uma vez, e o OnTimer() verifica se há mais deles e fecha, se há.
Pode haver vários minutos entre as carraças, por isso vamos passar a tarefa para o temporizadorIdeia valiosa. Talvez sim?: OnTick() gera uma matriz com bilhetes e tenta fechar uma vez, enquanto OnTimer() verifica se eles ainda estão presentes e fecha se estiverem.
Entre carrapatos pode haver vários minutos, por isso vamos passar a tarefa a um temporizadorEu abandonaria TODOS enquanto, Sleep e OnTimer para a tarefa de fechar posições. Eu faria o seguinte: ordens de incêndio para fechar - sair do OnTick, no próximo tick eu verificaria se as posições com bilhetes necessários ainda estão vivas - novamente ordens de incêndio para fechar, e assim por diante através do loop via entrada/saída para o OnTick.
A lógica é a seguinte: o fecho de uma posição é a primeira prioridade, pelo que o ciclo de fecho está no início do OnTick. E a formação de uma matriz de bilhetes próxima pode ser localizada em qualquer lugar noTick - mesmo no final.
***
Pode haver vários minutos entre as carraças, por isso vamos passar a tarefa para o temporizadorPortanto, não há nada que possamos fazer - só temos de esperar por um novo tique.
OnTick() gera um array com bilhetes e tenta fechá-los uma vez, e OnTimer() verifica se eles ainda estão presentes e fecha se estiverem.
Outra opção (para o mundo real - esta é a melhor) é executar a EA num ambiente virtual (há uma execução perfeita), e no mundo real apenas sincronização com o virtual.
Portanto, não há nada que possa fazer - basta esperar pelo próximo tique.
Se, por exemplo, houver uma falha na rede, então esperar pelo próximo tick é uma oportunidade perdida de fechar.
Se, por exemplo, houver uma falha na rede, então, à espera do próximo tique, perde-se uma oportunidade de fechar.
Falha de rede == desconexão? Se não houver Internet, então nada pode ser fechado ou aberto - qual é a oportunidade perdida?
Em geral, se o sistema de negociação for muito sensível a cada espirro (uma falha de ligação ou algo parecido) - então aparafuse um sistema de negociação deste tipo.