Pergunta sobre a função OnTradeTransaction - página 4

 
Mikalas:

Isso porque a troca não tem cozinha (apenas comissões) e FOREX tem milhões de seguidores MMM,

podem ser 100 dólares, mas TODOS os têm! Muito dinheiro, há algo para contar! :)

Eu não entendo MetaQuotes )

Para cozinhas forex existe um ótimo terminal MT4.

Muitas cozinhas forex nunca fornecem acesso via MT5, elas não precisam dele porra nenhuma.

É impossível durante tantos anos fazer um terminal próximo às trocas?

Se eles tiverem um bom terminal, eles terão muitos clientes que desejam fornecer serviços MT5.

 
Serj_Che:

Eu não entendo MetaQuotes )

Para cozinhas forex existe um ótimo terminal MT4.

Muitas cozinhas forex nunca fornecem acesso via MT5, elas não precisam dele porra nenhuma.

É impossível durante tantos anos fazer um terminal próximo às trocas?

Se tivermos um bom terminal, haverá muitos clientes que queiram fornecer serviços MT5.

Não se trata de MQ, mas sim de corretores.

Os corretores se beneficiam dos clientes que fazem negócios - mais negócios - mais comissão.

O robô só fará "ofícios corretos", e ao fazer pedidos "à mão" as pessoas são muito

O robô só fará acordos "corretos" e ao fazer um pedido de mão as pessoas cometem erros com muita freqüência (eu mesmo já cometi este erro muitas vezes),

Você é pego, você jura, você fecha o pedido com uma perda, você quer recuperá-lo, você o enganou novamente, etc.

E o corretor e a bolsa receberam uma comissão :)

Assim, para a troca e especialmente para o corretor QUIK é a pátria.

 
Mikalas:

Vasily, vai haver uma resposta?

Acho que não.

Eu ganhei?

Vou lhe dar uma resposta esta noite. Neste momento, não posso.
 
C-4:

Não complique as coisas. Não é necessário utilizar a assincronia para comercializar em FORTS. Para começar, dê uma olhada neste artigo, capítulo 3: "Os princípios básicos das operações assíncronas". Não é muito, é muito básico, mas é o suficiente para começar a estudá-lo. O código ali descrito é 100% assíncrono, porém não o impede de trabalhar em modo síncrono sem obter todos os tipos de OnTradeTransaction e outros eventos.

A solução deve ser baseada em sua tarefa. No MetaTrader 5, você tem apenas uma posição ativa em um determinado momento, e é isso que você precisa monitorar. Não há necessidade de olhar para o histórico do pedido. Se você ainda precisar do histórico do pedido, você deve esclarecer seu objetivo.

Não, Vasily, você ainda não entendeu bem meu objetivo. Não vou escrever nada ou negociar em FORTS, apenas comecei a aprender o mql5. Eu comecei a ler este artigo antes. Mas eu não li mais de 2 páginas e desisti. Acho que não preciso disso, eu mesmo sou um NT. Mas uma explicação clara da diferença OrderSend e OrderSendAsync é útil. Isso é praticamente o que eu esperava.

Se saltarmos a submissão assíncrona de pedidos e usarmos a OnTradeTransaction para acompanhar o que está acontecendo na conta, isso não melhoraria o desempenho da EA?

Uma coisa é fazer uma verificação em cada tic, e outra bem diferente é verificar apenas se houve alguma mudança na conta. Eu estou errado? A ordem pendente foi ativada, temos informações sobre ela. Uma posição é fechada, podemos analisar o resultado de seu fechamento. Há apenas algumas poucas verificações durante o tempo desde a abertura até o fechamento de uma posição. E, em contraste, há verificações em cada carrapato.

Aqui está outra pergunta: Para determinar o lucro de uma posição, existe a função PositionGetDouble(POSITION_PROFIT), mas para determinar o lucro de uma posição fechada, somente OrderCalcProfit() tem um amontoado de parâmetros que devem ser obtidos primeiramente deste comércio. Ou talvez eu seja tão novo no mql5 que não consiga encontrar uma solução adequada?

Se você não se importa...

 
AlexeyVik:

Não, Vasily, você entendeu mal meu objetivo. Ainda não vou escrever nada ou negociar em FORTS, apenas comecei a aprender mql5. Eu comecei a ler este artigo antes. Mas eu não li mais de 2 páginas e desisti. Acho que não preciso disso, eu mesmo sou um NT. Mas uma explicação clara da diferença OrderSend e OrderSendAsync é útil. Isso é praticamente o que eu esperava.

Se descartarmos o envio assíncrono de pedidos e ainda usarmos a OnTradeTransaction para rastrear o que está acontecendo na conta, isso não irá melhorar o desempenho da EA?

Uma coisa é fazer uma verificação em cada tic, e outra bem diferente é verificar apenas se houver alguma mudança na conta. Eu estou errado? A ordem pendente foi ativada, temos informações sobre ela. Uma posição é fechada, podemos analisar o resultado de seu fechamento. Há apenas algumas poucas verificações durante o tempo desde a abertura até o fechamento de uma posição. E, em contraste, há verificações em cada carrapato.

Aqui está outra pergunta: Para determinar o lucro de uma posição, existe a função PositionGetDouble(POSITION_PROFIT), mas para determinar o lucro de uma posição fechada, somente OrderCalcProfit() tem um amontoado de parâmetros que devem ser obtidos primeiramente deste comércio. Ou talvez eu seja tão novo no mql5 que não consiga encontrar uma solução adequada?

Se não for muito incômodo...

A OrderCalcProfit não vai ajudar.

É preciso calcular o preço médio de todos os pedidos (dentro) e o preço médio de todos os pedidos (fora),

então o lucro de uma posição fechada pode ser calculado.

Teremos que olhar através da história.

 
Mikalas:

A OrderCalcProfit não vai ajudar.

Você precisa calcular o preço médio de todas as ordens (dentro) e o preço médio de todas as ordens (fora),

Então, podemos calcular o lucro de uma posição fechada.

Teremos que investigar a história.

Em princípio, eu o entendo (embora ainda não entenda como fazê-lo), mas neste caso, apenas a última posição fechada é importante para mim. Aparentemente, isto é mais adequado para o caso quando o cargo foi preenchido. Mas minha tarefa é diferente.

Decidi reescrever minhas corujas mql5 com martin. Está no mercado continuamente e abre o próximo comércio para a última posição...

Oops... é o quanto é útil se comunicar no fórum. Afinal, se a posição só pode reverter quando a ordem pendente é ativada, ou fechar na tomada, eu não me importo com o tamanho do lucro ou perda. Bem, se o último joelho der um menos, então você não precisará de nada... É suficiente saber o tipo de posição fechada... E isto pode ser escrito em variável de nível global na OnTradeTransaction handler com o tipo de transação TRADE_TRANSACTION_DEAL_ADD e com o tipo de transação TRADE_TRANSACTION_HISTORY_ADD ou com a condição de PositionsTotal ser igual a zero para colocar a próxima primeira ordem da série... Escrevi isto por mim mesmo, para não esquecer :))))



 
papaklass:

...Ou seja, a lógica de seu algoritmo deve ser baseada na MUDANÇA DO AMBIENTE DE TRADING, e não no processamento de quaisquer funções ou eventos.

3 A freqüência de verificação do ambiente comercial (no tick, na barra, no temporizador, etc.) deve corresponder à lógica de seu TS. Ou seja, com que rapidez o ambiente comercial deve ser processado? Se a lógica de seu TS exige o processamento da mudança o mais rápido possível, então você não pode evitar verificá-la em cada carrapato...

E se a sua EA é multi-moeda?
 
papaklass:

1. A função OrderSendAsync() é utilizada quando várias ordens precisam ser enviadas UMA única vez, um tipo de envio em lote. Com o envio de lotes, se você esperar que o servidor responda a cada pedido (usando a função OrderSend()), haverá um atraso total significativo no envio de todo o lote. Durante este lapso de tempo, o mercado pode mudar significativamente! Para evitar este atraso de tempo, introduzimos a função OrderSendAsync(). Você deve entender isso claramente.

Se você não precisa enviar pedidos em lote, então não faz sentido usar a função OrderSendAsync().

A maneira mais confiável de determinar se uma ordem, ordem, etc. foi acionada, é monitorar seu ambiente comercial. - é o acompanhamento de seu ambiente comercial, não o acionamento de qualquer função ou evento. Uma função ou evento pode funcionar, mas isso não necessariamente muda seu ambiente comercial. Por quê? Porque um erro pode simplesmente ocorrer durante a execução da função.

Portanto, a lógica de seu algoritmo deve ser baseada na MUDANÇA VARIÁVEL, mas não no processamento de quaisquer funções ou eventos.

3. A freqüência de verificação do ambiente comercial (em um carrapato, em uma barra, por temporizador, etc.) deve se ajustar à lógica de seu TS. Ou seja, com que rapidez as mudanças no ambiente comercial precisam ser processadas? Se a lógica de seu TS exige o processamento de uma mudança o mais rápido possível, então você não pode evitar verificá-la em cada carrapato.

Alexander, obrigado por seu feedback.

Entendo apenas para entender que não preciso disso até agora. Por enquanto, a função OrderSend é suficiente para mim.

2. sim, concordo que o estado mais preciso só pode ser determinado pelo monitoramento de todo o ambiente a cada tique. Mas ter um manipulador de eventos assim para ignorá-lo... Bem, eu estou apenas experimentando. Entendo perfeitamente seu desejo de me ajudar a torná-lo de alguma forma mais confiável, mas meu objetivo é diferente. Eu não preciso deste consultor especializado com urgência e não estou escrevendo para pedir.

3. Talvez na versão final da EA eu volte a testar a cada tick, mas por enquanto...

A questão era se podíamos confiar no manipulador de eventos da OnTradeTransaction se a documentação nos advertisse contra isso.

Além disso, as transações podem ser perdidas na entrega do servidor para o terminal.

E em que casos é melhor não confiar, e em que casos é necessário apoiá-lo com algo.

Sou muito grato a todos, Vasiliy, Michael e você Alexander. Ficarei muito feliz e obrigado mais uma vez se você compartilhar mais alguma idéia.

 
papaklass:

Esta é exatamente a pergunta que tanto Vasily como eu respondemos.

Pense nisso, se o trabalho da função OnTradeTransaction() precisa ser verificado da mesma forma, pode ser melhor verificar o ambiente de negociação imediatamente do que depois que a OnTradeTransaction() tiver sido processada. No entanto, é uma questão de gosto.

E na próxima linha Renat prometeu trabalhar com a função e talvez nas próximas construções consigamos uma melhoria desta função.

Mas ainda assim, estamos focados na colocação assíncrona de pedidos. Neste caso, não temos motivos para perder um pedido entre centenas de outros. No entanto, Michael diz que em seis meses, com um número incrivelmente grande de pedidos, não perdeu uma única transação. E qual é a probabilidade de perder uma transação se o pedido for feito usando a função OrderSend()?

E se houver uma melhoria, é mais um motivo para se preocupar com isso. Ou estou errado novamente?

 
denkir:
А если советник мультивалютный?


papaklass:

Não está claro o que você quer que eu diga.

Um argumento contra o modelo do evento...