ORDER_POSITION_ID - página 21

Novo comentário
 
Mikalas:

...

Mas eu queria implementá-la através deordens (acontece que uma ordem parcialmente executada "permanece" por um par ou três dias),

...

Michael, você estava certo! Por que você não fez isso? Você tem que entender que ao lidar com posições líquidas, mais cedo ou mais tarde você será confrontado com o fato de que não pode prescindir da análise das ordens incluídas nela. Isto é o que estou lhe dizendo como pessoa que passou meses estudando esta questão, e cometeu este erro muitas vezes:) Além disso, se você tem mais de um robô comercial, você tem que considerar o lucro de cada robô na posição total, e você não pode passar sem ordens aqui também. Todas as informações necessárias estão presentes nos pedidos e nos acordos baseados neles, e os acordos de tapetes em uma única posição líquida, ao contrário, eliminam irreversivelmente as informações.

Mas se você basear seu sistema na análise de ordens e negócios, você deve considerar a execução parcial de ordens. Para fazer isso, você deve criar uma versão virtual da ordem e controlar a chegada de novos negócios. Meu algoritmo é o seguinte:

1. Um novo acordo foi recebido (o contador HistóricoDealsTotal() foi alterado).

2. Se este negócio for iniciado por uma ordem, criamos uma nova ordem incluindo uma única ordem (ordem COrder* = nova ordem(acordo)).

3. Em seguida, procuramos em nossa lista de pedidos virtuais já existentes, por um pedido com o mesmo identificador. Se tal ordem for encontrada, então fundimos os negócios da ordem criada com os negócios da ordem encontrada e atualizamos suas propriedades, e apagamos a ordem criada. Se a mesma ordem ainda não estiver na lista, nós simplesmente a adicionamos à lista.

Desta forma, o sistema torna-se totalmente determinístico. Com cada nova operação nossa ordem virtual mudará seu estado, e não importa se a ordem real está pendente de execução ou se já foi movida para a história, sempre a veremos em nosso sistema no volume efetivamente executado.

 
Contender:
E se fecharmos a posição, e a parte não executada da ordem não for removida, ela abrirá (ou mudará) outra posição?

Boa pergunta!

Se a ordem está ativa, não está na história (isto foi verificado com certeza),

E, claro, uma ordem ativa pode abrir outra posição, mas se

será parcialmente executado novamente, não lhe atribuiremos ORDER_POSITION_ID.

Em outraspalavras, oORDER_POSITION_ID só pode ser visto na história.

 
C-4:

Sim, isso acontece no mercado de ações e essas situações devem ser levadas em conta. Esta é uma das desvantagens fundamentais das ordens de limite.

Em seu exemplo, acho que podemos substituí-lo:

Para:

Como todas as operações de compra e venda são iniciadas por algum tipo de ordem.

Não, você não pode, porque os negócios ocorrem na compensação, mas eles não têm um bilhete ( ou melhor, bilhete = 0 ),

mas eles têm um preço e um tipo (COMPRAR e VENDER) e, claro, IN e OUT :(

 
C-4:

Mikhail, e com razão! Por que você ainda não implementou isso? Você tem que entender que ao lidar com posições líquidas, mais cedo ou mais tarde você será confrontado com o fato de que não pode prescindir da análise das ordens incluídas nela. Isto é o que estou lhe dizendo como pessoa que passou meses estudando esta questão, e cometeu este erro muitas vezes:) Além disso, se você tem mais de um robô comercial, você tem que considerar a contribuição de cada robô na posição conjunta, e você não pode passar sem ordens aqui também. Todas as informações necessárias estão presentes nos pedidos e nos acordos baseados neles, e os acordos de tapetes em uma única posição líquida, ao contrário, eliminam irreversivelmente as informações.

Mas se você basear seu sistema na análise de ordens e negócios, você deve considerar a execução parcial de ordens. Para fazer isso, você deve criar uma versão virtual da ordem e controlar a chegada de novos negócios. Meu algoritmo é o seguinte:

1. Um novo acordo foi recebido (o contador HistóricoDealsTotal() foi alterado).

2. Se este negócio for iniciado por uma ordem, criamos uma nova ordem incluindo uma única ordem (ordem COrder* = nova ordem(acordo)).

3. Em seguida, procuramos em nossa lista de pedidos virtuais já existentes, por um pedido com o mesmo identificador. Se tal ordem for encontrada, então fundimos os negócios da ordem criada com os negócios da ordem encontrada e atualizamos suas propriedades, e apagamos a ordem criada. Se a mesma ordem ainda não estiver na lista, nós simplesmente a adicionamos à lista.

Desta forma, o sistema torna-se totalmente determinístico. O estado de nossa ordem virtual mudará a cada novo negócio e não importa se a ordem real está pendente de execução ou se já foi movida para a história, sempre a veremos em nosso sistema no volume efetivamente executado.

Vasiliy, eu implementei tudo ( não como você fez, mas também não mal ), eu só queria reduzir o tempo de busca...
 
Serj_Che:

Problema resolvido, relações resolvidas )

Tenho uma pergunta relacionada:

É muito inconveniente selecionar uma ordem por bilhete para ver suas propriedades, pois não importa onde a ordem está na história ou no mercado, e o bilhete não mudará.

Portanto, temos que procurar o pedido tanto aqui como ali.

Não seria mais fácil fazer como no MT4: se selecionarmos um pedido, não importa onde ele está localizado.

Eu li no MT4 Ajuda:

O que você pensa sobre isso?

P.S. Espero que a Mihail não se importe de continuar esta linha, para não produzir mais novas?


Mikalas:

С-4, é muito bom que a discussão tenha sido construtiva!

Portanto, preciso do preço "líquido" da posição para saber (em um mês, por exemplo) qual é o meu lucro.

...

Na função (estou usando-o agora):

...

A questão é relevante, em geral o MetaTrader5 API é realmente de nível bastante baixo. Mas ... A negociação na bolsa tem muitas nuances: execução de ordens por múltiplas negociações, negociações combinadas em uma posição líquida e transferência através de compensação, uma abundância de transações de corretagem e assim por diante e assim por diante. Portanto, o MetaTrader5 API (e o próprio MT5) é tal, como qualquer terminal de troca deve ser.

Outra questão é que seu API pode ser embalado em um invólucro de alto nível escrito em MQL5 e utilizar através dele as funções de nível mais baixo do MT5. Se eu tivesse o invólucro, a tarefa de cálculo de lucro da Mihail ficaria assim

for(int i = 0; i < TransactionsTotal(); i++)
{
    if(TransactionSelect(i, SELECT_BY_POS, MODE_TRADES))
    {
         ENUM_TRANS_TYPE trans_type = TransactionType();
         if(trans_type == TRANS_HEDGE_POSITION)
         {
              if(HedgePositionGetInteger(HEDGE_POSITION_MAGIC) != myMagic)continue;  // Работаем только со своими позициями.
              if(HedgePositionGetString(HEDGE_POSITION_SYMBOL) != Symbol())continue; // Работаем только с позициями на своем инструменте.
              double profit = HedgePositionGetDouble(HEDGE_POSITION_PROFIT_POINTS); //Профит в пунктах
              double currency = HedgePositionGetDouble(HEDGE_POSITION_PROFIT_CURRENCY); //Профит в валюте депозита.
              double price_open = HedgePositionGetDouble(HEDGE_POSITION_PRICE_OPEN); //Фактическая цена открытия позиции без клирингов и пр. изменений.
              double sl = HedgePositionGetDouble(HEDGE_POSITION_SL); //Узнаем уровень стоп-лосса позиции, если он есть, если нет - вернет нормализованный 0.0.
              if(HedgeOrderSelect(ORDER_SELECTED_INIT)) //Выбираем ордер, открывающий текущую позицию.
              {
                 int deals = HedgeOrderGetInteger(HEDGE_ORDER_DEALS_TOTAL); //Получаем количество сделок, открывающего ордера.
              }
              // Ну и так далее...
         }   
    }
}
 
Mikalas:

Não, você não pode, porque as negociações são liberadas, mas não têm bilhete ( ou melhor, bilhete = 0 ),

mas têm um preço e um tipo (COMPRAR e VENDER) e, claro, IN e OUT :(

Merda, certo:

Depois, tristeza para você.

 
Mikalas:
Vasiliy, eu implementei tudo ( não como você fez, mas também não mal ), eu só queria reduzir o tempo de busca...
A propósito, como você lida com as entradas multidirecionais de seus robôs? Afinal, a entrada no mercado de um Expert Advisor pode ser a saída de outro robô.
 
Mikalas:

Boa pergunta!

Se a ordem está ativa, não está na história (isto foi verificado com certeza),

E, claro, uma ordem ativa pode abrir outra posição, mas se

será parcialmente executado novamente, não lhe atribuiremos ORDER_POSITION_ID.

Em outraspalavras, oORDER_POSITION_ID só pode ser visto na história.

Há aqui outra armadilha. Uma parte dos negócios executados por esta ordem pertencerá a uma posição, e a outra parte já pertencerá à outra, nova posição. Então a questão é, qual identificador de posição será atribuído a ele, quando ele eventualmente chegar ao histórico?
 
C-4:
A propósito, como você lida com as entradas multidirecionais de seus robôs? Afinal, a entrada de um Expert Advisor no mercado pode ser uma saída da posição de outro robô.
Eu não tenho nenhuma sobreposição.
 
C-4:
O problema aqui é diferente. Parte dos negócios executados desta ordem pertencerá a uma posição, e a outra parte já pertencerá a outra, nova posição. Então a questão é, que cargo de identificação lhe será atribuído quando, mais cedo ou mais tarde, chegar ao histórico?

Uma ordem totalmente preenchida, receberá a identificação da posição que abriu ou mudou.

Mas isto só estará disponível ( ID ) na história.

1...1415161718192021
Novo comentário