Fazer um serviço de certificação para programadores ... - página 6

[Rustamzhan Salidzhanov]

Sim, pessoal....

já está pronto a ser classificado :))))

[snowman]

VOLDEMAR:
Se não tem nada de bom a dizer, não diga nada ou pelo menos fale sobre isso ..... Se soubesse alguma coisa, mostrar-me-ia... Ou é demasiado mau? Ou não sabe nada ....?

não há nada a discutir.

Na verdade, seria melhor pentear as suas funções de envio de encomendas para a exactidão da encomenda a ser enviada para o servidor.

Não quero que o erro seja comunicado perante o servidor, mas antes...)

[Alexander Bereznyak]

MrGold166:

No pior dos casos, só nos impede se contarmos as encomendas, por exemplo o preço médio, uma encomenda será contada 2 vezes. Mesmo que interfira fortemente nos cálculos, no próximo tick tudo voltará ao seu lugar e colocaremos o take profit onde deveria estar. Na minha memória, com mais de 50 ordens e com o pior dos chamados "corretores" asiáticos (sim, sabe a quem me refiro), isto nunca aconteceu depois de a conta ter sido negociada (sabe porquê). Mas isto também pode ser evitado:

int i,last_ticket;

for(i=OrdersTotal()-1;i>=0;i--) if(OrderSelect(i,SELECT_BY_POS) {

   if(OrderTicket()==last_ticket) continue;

   last_ticket=OrderTicket();

   }

E como pode garantir que não terá a mesma situação da próxima vez que marcar, sim, nada.

E o pior caso pode vir, calculará a média errada e abrirá uma ordem errada e o próximo tique não terá importância.

Não é o número de ordens que importa, mas sim o ambiente de negociação, a presença de paragens reais, a presença de outras EAs na conta.

[A100]

MrGold166:

Mas isto também pode ser evitado:

int i,last_ticket;

for(i=OrdersTotal()-1;i>=0;i--) if(OrderSelect(i,SELECT_BY_POS) {

   if(OrderTicket()==last_ticket) continue;

   last_ticket=OrderTicket();

   }

Teoricamente, mais do que uma encomenda poderia mudar de estado

[Alexander Bereznyak]

A100:
Teoricamente, o estado de mais do que uma encomenda pode mudar

Uma boa ideia, não pensei em duas, fiquei pendurado em uma.

Voltando ao ponto de partida, como resolver colisões com esta função.

[snowman]

sandex:

Boa ideia, não pensei em duas, fiquei preso a uma.

Voltando ao ponto de partida, como resolver colisões com esta função.

   int j=OrdersTotal();
   for(int i=j-1;i>=0;i--)
   {
      if(OrderSelect(i,SELECT_BY_POS))
      {
      }
   }
   if(j!=OrdersTotal())return(0);

Se alguma coisa, recalcule novamente. se o número de ordens de entrada e saída não for igual.

[[Excluído]]

A100:
Teoricamente, mais do que uma encomenda poderia mudar

E então? Mesmo que todos mudem, continuamos a não analisar os mesmos ofícios.

Se estivermos a falar de uma troca no topo da lista que tenha mudado, então pode mudar depois de termos passado pela pesquisa - antes de colocarmos o lucro total.

[A100]

snowman:

Se alguma coisa, recalcule novamente se o número de ordens de entrada e saída não for igual.

Em geral, se mesmo o número de encomendas pode ser igual, só podem ser encomendas diferentes

[[Excluído]]

snowman:

Se o número de encomendas à entrada e à saída não for igual, então recalcule-o novamente.

Isto também não nos ajudará se uma ordem pendente for aberta, a quantidade de ordens será guardada mas os parâmetros não o serão. Por outro lado, isto dificilmente nos perturbaria, se não tivéssemos incluído no montante uma ordem recentemente aberta e pendente, tudo bem. (Não vejo realmente uma situação, em que isto possa causar um erro). Esta situação só pode ocorrer sob um conjunto especial de circunstâncias, uma das quais é um monte de carraças, ou seja, a próxima iteração será muito em breve e o erro será corrigido. No caso do ressalto da ordem acontecer entre carraças, isto não é um problema para nós.

Vemos frequentemente códigos de outros programadores onde a enumeração é feita dezenas de vezes por iteração separadamente para calcular um monte de parâmetros e isto é um problema.

[A100]

MrGold166:

E então? Mesmo que todos mudem, continuamos a não analisar os mesmos ofícios.

Se estivermos a falar de uma troca no topo da lista que tenha mudado, então pode mudar depois de termos passado pela pesquisa - antes de colocarmos o lucro total.

Não estava a referir-me ao cálculo aplicado a uma situação específica, mas sim ao caso geral. Penso que a dupla contagem e/ou a sub-contagem são importantes, por vezes de forma crítica