Processamento OnTradeTransaction - página 6

 

Boa tarde.

Ninguém se sente intimidado por ninguém.

prostotrader:

Você não tem switch(trans.type)

Bem, é claro que o caso dado está em switch(trans.type). Como havia outro caso, eu não queria mostrar todo o código para não sobrecarregá-lo com informações desnecessárias.

fxsaber , obrigado pelo exemplo!

Alexey, é exatamente a mesma coisa. Estou usando 2 robôs diferentes para comercializar no mesmo símbolo em modo de rede. Os 2 cargos que você citou se complementam.

É interessante resolver o problema a partir do gatilho primário da mudança - onTradeTransaction.

Total de problemas atuais encontrados:

1. deal_add desencadeia, mas sem pose. Nenhuma reflexão até agora.

2. deal_add é acionado, mas a ordem está na terceira dimensão. Colocando um deslize, os últimos dois dias parecem ajudar. O pedido consegue chegar à história em 1 segundo. Eu não tenho robôs comerciais de alta freqüência e não uso ordens de mercado, portanto, esta solução seria apropriada.

3. deal_add é acionado 2 vezes, ou seja, um e o mesmo deal_add é acionado 2 vezes. Isto pode ser resolvido verificando o ticket de um negócio anterior e comparando-o com o atual.

Há ainda o ponto 1. explicações para isso.

Ontem eu estabeleci o limite de venda, funcionou, o deal_add veio, mas a posição não apareceu e abrimos uma ordem de parada por nada. Comecei a olhar para a descrição da transação e vi que o tipo de transação é DEAL_TYPE_SELL mas o tipo de ordem é ORDER_TYPE_BUY. Ao mesmo tempo, o bilhete de pedido é nosso. Não parecia ser muito lógico. Decidi verificar se o tipo de ordem e o tipo de comércio devem ser os mesmos na OnTradeTransaction, se o tipo de ordem e o tipo de comércio devem ser os mesmos.

Coloquei o robô na demonstração e consegui outra transação semelhante, mas desta vez a posição mudou. Mas devido à nossa verificação, a ordem de parada não foi executada. O que está acontecendo?

2019.02.08 16:05:14 [INFO]: ( FrTrend_2_Si-3.19_33) TRADE_TRANSACTION_DEAL_ADD
TRADE_TRANSACTION_DEAL_ADD
Symbol: Si-3.19
Deal ticket: 12677775
Deal type: DEAL_TYPE_SELL
Order ticket: 82675535
Order type: ORDER_TYPE_BUY
Order state: ORDER_STATE_STARTED
Order time type: ORDER_TIME_GTC
Order expiration: 1970.01.01 00:00
Price: 66287
Price trigger: 0
Stop Loss: 0
Take Profit: 0
Volume: 1
Position: 82675534
Position by: 0

Vou lhe dizer imediatamente, isto é o que está vindo para o terminal. Sem que eu o invente.

 
Илья Ребенок:

Ontem eu coloquei sell_limit, ele acionou, deal_add veio, mas nenhuma posição apareceu e abrimos ordens de parada por nada. Comecei a olhar a descrição da transação e vi que o tipo de transação é DEAL_TYPE_SELL e o tipo de ordem é ORDER_TYPE_BUY. Ao mesmo tempo, o bilhete de pedido é nosso. Não parecia ser muito lógico. Decidi verificar se o tipo de ordem e o tipo de transação devem coincidir na OnTradeTransaction na transação deal_add.

Mas aqui vale a pena reler a ajuda"Estrutura das transações comerciais" - em termos de quais campos são preenchidos para o tipo deal_add.

E tomar as propriedades da ordem não da transação (onde não são preenchidas, mas zeros também correspondem a alguns valores em enumeração), mas da própria ordem, se ela estiver disponível no momento (e não no processo de transição das ordens para a história).

 

Isto facilita a análise de como as coisas estão indo.


Você pode acrescentar que, junto com as transações, o status das posições, ordens atuais e histórico de negociações também podem ser registrados. Então, o quadro completo estará disponível.

 
JRandomTrader:

É aqui que vale a pena reler a ajuda"Estrutura de uma transação comercial" - em termos de quais campos são preenchidos para o tipo deal_add.

E tomar as propriedades do pedido não da transação (onde eles não são preenchidos, mas zeros também correspondem a alguns valores do tipo enumeração), mas do próprio pedido, se ele estiver disponível atualmente (e não no processo de transição dos pedidos para o histórico).

Concordo, eu estava ciente disso, mas não prestei atenção. Obrigado por me lembrar.

Entretanto, o problema de uma posição não aparecer em um caso e aparecer em outro caso permanece e não é claro.

 

Илья Ребенок:

No entanto, o problema com a posição não aparecendo em um caso e aparecendo no outro permanece e não é claro.

A posição foi ticada na transação, mas a posição não existia antes e não apareceu? Isto tem que ser resolvido.

 
JRandomTrader:

A posição foi ticada na transação, mas a posição não estava lá antes e não apareceu? Isto precisa ser resolvido.

a posição não estava lá antes

 
Илья Ребенок:

a posição não estava lá antes

Havia um bilhete de posição na transação?

 
JRandomTrader:

Havia um bilhete de posição na transação?

No posto acima, devo ter feito um pequeno mal-entendido. Havia uma posição, depois foi fechada por ordens de parada. Ou seja, o número de posições passou a ser 0. Então, uma troca foi acionada, mas a posição não apareceu.

Acho que é isto que você quer dizer. A transação continha informações sobre o bilhete da posição, mas este bilhete = bilhete da ordem anterior. Como deveria estar em modo de rede, se entendi corretamente.

Position: 82675534
 
Илья Ребенок:

No posto acima, devo ter feito um pequeno mal-entendido. Havia uma posição, depois foi fechada por ordens de parada. Ou seja, o número de posições passou a ser 0. Então, uma troca foi acionada, mas a posição não apareceu.

Acho que é isto que você quer dizer. A transação continha informações sobre o bilhete da posição, mas este bilhete = bilhete da ordem anterior. Como em geral, deveria estar em modo de rede, se eu entendi corretamente.

Se a posição sobre o símbolo (cumulativo, todos os robôs e operações manuais juntos) tornar-se 0,0, a próxima transação abrirá (DEAL_ENTRY_IN) uma nova posição, com um novo bilhete (==ticket de ordem).

Na verdade, parece-me que quando se faz a compensação, não há necessidade de olhar a posição de forma alguma - cada robô tem que responder por "sua" - como os resultados das negociações em suas ordens.

 

A presença de posições e bandeiras DEAL_ENTRY não deve de forma alguma ser envolvida na lógica.

Só precisamos olhar para o mágico e comentar os novos negócios e ordens atuais como identificadores dos próprios/estrangeiros.


O código de trabalho mostrado. É exatamente a mesma coisa.

Tentar resolver o problema através da OnTradeTransaction é uma má idéia do número de armadilhas. Que em uma determinada tarefa ainda pode, às vezes, ser contornada. Mas se você mudar a tarefa apenas um pouco, toda a lógica é quebrada durante a implementação da OnTradeTransaction-implementação.

Os desenvolvedores criaram um modelo comercial orientado por eventos, mas eles não forneceram um único exemplo de trabalho. Porque é um completo idiota no que o código se derrama e em quanto depende de cada exemplo.

Portanto, eu recomendaria observar as operações comerciais síncronas e a função OnTrade. Lá tudo é muito mais fácil e a lógica é muito flexível para mudanças. Além disso, é mais confiável.


A transição para a Async+Transactions é comparável à transição da linguagem de alto nível para o montador. Isto é, deve ser feito no último estágio da criação da TS, quando ela for COMPLETAMENTE pesquisada, pronta para REAL e a última coisa é acelerar as operações comerciais SEM mudar a lógica comercial.