Dicas úteis para os participantes do campeonato - página 11

Novo comentário
 
VNIK писал (а):

Desculpe pela pergunta indiscreta aos organizadores do Campeonato:

Como será tratada a tributação do prêmio (porque o valor de cada prêmio é muito grande):

Cada premiado terá que pagar seu próprio imposto? (e a que ritmo?) Ou será centralizada? (ou seja, os impostos já são levados em conta?).

Seria uma pena desistir da metade do prêmio por impostos!

Concordo com você, eu também lamentaria dar metade de seu prêmio para pagar meus impostos...
Na verdade, é melhor não ganhar nada para não se sentir arrependido... .
 
VNIK:

Desculpe pela pergunta indiscreta aos organizadores do Campeonato:

Como será tratada a tributação do prêmio (porque o valor de cada prêmio é muito grande):

Cada premiado terá que pagar seu próprio imposto? (e a que ritmo?) Ou será centralizada? (ou seja, os impostos já são levados em conta?).

Seria uma pena desistir da metade do prêmio por impostos!


Sim, os premiados pagam seus próprios impostos - esta é uma prática padrão para prêmios em todo o mundo.
 
Não há como testar se este fechamento de pedidos sempre funcionará corretamente:
while (OrdersTotal()>0)
   {
      OrderSelect(0,SELECT_BY_POS);
      if (OrderType()==OP_BUY)       OrderClose(OrderTicket(),OrderLots(),Bid,3,Green);
      else if (OrderType()==OP_SELL) OrderClose(OrderTicket(),OrderLots(),Ask,3,Red);
      
      err=GetLastError();
      if (err==135 || err==138) RefreshRates();
   }
A questão é: se o código de erro não for 135 ou 138, haverá um loop? Em caso afirmativo, como se pode evitar isso, com a garantia de que as ordens serão fechadas?
 
MAEstro:
Não há como testar se este fechamento de pedidos sempre funcionará corretamente:
Aqui há erro após erro. Contei 4 erros e todos eles são catastróficos.
Leia o artigo de aconselhamento novamente, por favor.
 
Lembro-me deste conselho de cor, mas parece ser de pouca utilidade :(

Negligência grosseira no controle de erros com looping
(Eu tenho controle de erros, ordens pendentes não são usadas, ou devo fazer uma condição de saída de loop também? O que fazer então com a garantia de fechamento do pedido? Ou talvez eu não tenha processado todos os códigos de erro?

Falta de controle do OrderSelect - processos assíncronos em ação
(sim, eu não verifico o que a Order_Select retorna! Bem, digamos que se neste caso em particular ele retornar falso, o que mudará dentro do laço, ou o que será incorreto? Não estou modificando o pedido, estou fechando-o!)

Saltar a função de atualização do ambiente de mercado através de RefreshRates()
(acho que atualizo, tudo deve ficar bem aqui)

Talvez haja uma peça de código pronta para fechar TODOS os pedidos... Eu apreciaria se você pudesse publicá-la!

P.S. o que Rosh sugeriu http://www.alpari-idc.ru/ru/experts/articles/9.html , não garante o fechamento dos pedidos!
 
Há até 5 erros:
  1. O resultado da OrderSelect não é verificado
  2. o resultado do OrderClose() não é verificado explicitamente
  3. GetLastError() pode ser chamado sem nenhuma operação comercial (por exemplo, se você encontrou uma ordem pendente)
  4. RefreshRates() nem sempre é chamado, mas somente quando há uma falha - este é um erro grosseiro.
  5. se houver ordens pendentes na lista, este é um loop de 100%.
Como resultado: há 5 erros em 9 linhas - o código só pode ser jogado fora.
 
Renat:
Mesmo 5 erros:
  1. O resultado da OrderSelect não é verificado
  2. o resultado do OrderClose() não é verificado explicitamente
  3. GetLastError() pode ser chamado sem nenhuma operação comercial (por exemplo, se você encontrou uma ordem pendente)
  4. ...
Como resultado: há 5 erros em 9 linhas - o código só pode ser jogado fora.
E por que enfiar tudo isso em um especialista para um concurso? Para ler o diário de bordo?
A OrderSelect deve selecionar e a OrderClose deve fechar as ordens necessárias.
E não deve haver nenhum erro :-)
Ou às custas do cliente :-)
 
Renat писал (а):
Há até 5 erros:
  1. OrderSelect não verifica
  2. explicitamente
    3. o resultado
  3. OrderClose()
  4. GetLastError() pode ser chamado sem qualquer operação comercial (por exemplo, se uma ordem pendente for encontrada)
  5. RefreshRates() nem sempre é chamado, mas apenas em caso de falhas - um erro grave
  6. se a lista contiver ordens pendentes, então 100% looping
Como resultado: há 5 erros em 9 linhas - o código só pode ser jogado fora.

Objetivo: fechar todos os pedidos com garantia de 100%.
Restrições: pedidos pendentes não são utilizados

1. Por que devemos verificar o resultado se precisamos fechar um pedido? Se ele retornar falso, voltará a ele na próxima passagem, já que um loop é usado durante algum tempo.
2. Ver o ponto 1.
3. Há uma verificação de códigos de erro para este fim.
4. Se atualizar sempre, então não há sentido em verificar erros :(
5. Sem ordens pendentes

Todos os exemplos de fechamento de pedidos que encontrei em minha busca são de passagem única e só funcionam se tudo estiver bem com o servidor, sem solicitações, etc. E todos eles levam ao fato de que um dia um pedido não fechará e teremos um bom lucro... Se eu estiver errado, me corrija, ou me dê um link onde eu possa ser convencido de que estou errado.

É claro que estou bem ciente de que meu código pode levar a um loop, mas na minha opinião é melhor do que o risco de não fechar uma ordem, o que poderia levar a sérias perdas financeiras.
Embora fosse melhor se todas as ordens fossem fechadas com 100% de garantia e não houvesse possibilidade de uma ordem vadiagem, este é o código que eu gostaria que você me desse =)

Aqui está um código ligeiramente modificado, que deve até mesmo levar em conta as ordens pendentes:
while (OrdersTotal()>0)
   {
      OrderSelect(0,SELECT_BY_POS);
      if (OrderType()==OP_BUY)       OrderClose(OrderTicket(),OrderLots(),Bid,3,Green);
      else if (OrderType()==OP_SELL) OrderClose(OrderTicket(),OrderLots(),Ask,3,Red);
      else OrderDelete(OrderTicket());
      
      RefreshRates();
      err=GetLastError();
      if (err!=135 && err!=138 && err!=0) break;
   }

Não é tão "imprudente" como o anterior?
Ainda não entendo, por que verificar OrderSelect e OrderClose neste caso?
 
Infelizmente, ninguém dará qualquer garantia sobre as operações comerciais. O código acima é muito melhor do que o anterior.

OrderSelect deve ser sempre verificado, isto é explicitamente declarado nas Dicas Úteis:
  • Falta de controle do OrderSelect - processos assíncronos em ação


    Normalmente, um comerciante percebe seu programa como uma única tarefa e a única tarefa. Mas na realidade, há muitas mudanças assíncronas na conta comercial durante o funcionamento do Expert Advisor. As posições são modificadas, adicionadas e excluídas. Se o resultado de cada chamada OrderSelect() não for controlado, então pode acontecer que em um determinado momento o especialista opere com dados errados (zero) e faça um movimento errado.

 
Renat:
Infelizmente, não há garantias nas operações comerciais. O código acima é muito melhor do que o anterior.

OrderSelect deve ser sempre verificado, isto é explicitamente declarado nas Dicas Úteis:
  • Sem controle de OrderSelect - processos assíncronos em ação

    ... As posições são modificadas, acrescentadas e removidas. ...

Suponha que uma posição seja modificada. Há um pedido para selecionar um pedido por alguma condição. Ocorre um erro. O que pode ser alterado? As condições iniciais podem não estar disponíveis no próximo tick, então por que eu deveria cometer o mesmo erro novamente?
Sem comentários sobre "adicionado e removido" :-(
Por favor, me dê um exemplo de código funcional usando OrderSelect para obter OrderCloseTime.
1...45678910111213141516
Novo comentário
Razão: