Organizando o ciclo do pedido - página 2
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Como o preço se moverá, e a cada nova chamada para a OnTick, a condição para uma nova modificação do mesmo, primeiro na lista, a ordem será cumprida. Especialmente se a modificação durar 5 segundos ;)
Mais uma vez, a questão da relevância é abordada. Um pedido estará sempre atualizado. As demais estarão atualizadas. Sua variante, por outro lado, são todas as ordens não atualizadas.
Tal "espinha dorsal" quebraria a lógica de uma EA trabalhando com mais de uma ordem.
Qual seria a vantagem se não desse nenhuma vantagem a sistemas com uma ordem e estragasse o resto?
Eu adoraria entender o que você quer dizer, mas não posso. Não vejo o problema com o princípio "se o tempo de espera já passou, atualize o ambiente comercial".
Classificar por volume e/ou distância do preço antes de lidar com pedidos é a coisa certa a fazer. Mas não devemos assumir que todos que copiam o código do fórum o implementarão.
Nesse sentido, meu código é mais seguro.
Bem, não foi escrito para iniciantes. Você e eu discutimos isso muito bem aqui - sem água.
Mais uma vez é levantada a questão da relevância. Um pedido estará sempre atualizado. As outras estarão atualizadas, se possível. Sua opção é que todos os pedidos não estejam em dia.
Real - por quanto?
Fico feliz em entender o que você quer dizer, mas não funciona. Não vejo nenhum problema com o princípio "se o tempo de espera já passou, atualize o ambiente comercial".
Seu algoritmo está fixado na primeira ordem da lista, só isso.
Em algumas situações isto pode ser prejudicial ao sistema (eu o encontrei na prática).
Real - por quanto?
Em meu cenário, ambos os SLs teriam sido modificados em 1.2375 ou, no pior dos casos, em 1.2374. Conclusão: +30 pips em ambos os pedidos.
Em cada etapa de seu exemplo, o TS deve saber onde suas ordens devem estar sem nenhuma ordem comercial. Isto é, o TS não pode ser anexado de forma alguma ao local onde suas ordens estão agora. Trata-se apenas de calcular onde eles devem ficar e sincronizar o ambiente comercial com o que foi calculado através de ordens de negociação.
Em seu exemplo, no entanto, o resultado do TS depende se o OnTick chegou ao preço alto ou não. E o TS correto deve estar exatamente à altura disso. Ela vê que tal preço foi (mesmo que o OnTick com ele tenha faltado), e portanto seus SLs devem ser colocados de acordo. E a sincronização fará seu trabalho 100%.
E eu não entendo porque você continua dizendo que o segundo está parado. Mesmo sem lógica de sincronização, ela ainda será modificada da mesma forma que em sua variante. Não é como se o OnTick fosse chamado no evento NewTick, mas como uma função interna normal.
Em cada etapa de seu exemplo, o TS precisa saber onde suas ordens devem estar sem nenhuma ordem comercial. Ou seja, o TS não pode ser ligado de forma alguma ao local onde as ordens estão agora. Trata-se apenas de calcular onde eles devem ficar e sincronizar o ambiente comercial com o que foi calculado através de ordens de negociação.
Ela sabe que sim. Mas não tem tempo para sincronizá-la - enquanto uma modificação está passando, o preço avança e uma nova condição calculada lhe diz para modificar a primeira encomenda novamente. E isto acontece o tempo todo.
Em seu exemplo, o resultado da TC depende se a OnTick chegou ou não ao alto preço. E o TS correto deve ser exatamente antes disso. Ela vê que tal preço foi (mesmo que o OnTick com ele tenha falhado), o que significa que seus SLs devem ser colocados de acordo. E a sincronização fará seu trabalho 100%.
Não o faz (no exemplo, não houve cálculo de nível SL).
E a sincronização não fará o trabalho, pois não terá tempo (ver acima).
E eu não entendo porque você continua dizendo que o segundo fica parado. Mesmo sem lógica de sincronização, ela ainda será modificada da mesma forma que em sua variante. Não é como se o OnTick fosse chamado no evento NewTick, mas como uma função interna normal.
Como sempre, eu o entendi.
Entretanto, o preço já foi alterado enquanto a modificação estava em andamento e a chamada forçada da OnTick já funciona com o novo preço, enquanto a segunda ordem permanece no nível inicial.
Não há erro. Talvez seja muito específico demais para você (mas, mais uma vez, bastante real, da vida).
Ele faz, ele sabe. Mas não tem tempo para sincronizar - enquanto uma modificação passa, o preço se move mais adiante, e a nova condição calculada diz-lhe para modificar a primeira encomenda novamente. E isto acontece o tempo todo.
O exemplo que você inventou não nos dá perdas adicionais, considerando esta lógica. Agora deixe-me dar-lhe um exemplo.
Suponha que nós rastreamos BuyLimits após o movimento para cima a fim de abrir no pullback necessário. Quase Lucky-TC. Se arrastarmos uma montanha de Limites toda vez, não vamos pegar um pullback com sua opção.
Bem, é estranho dar ordens comerciais com base em um ambiente comercial ultrapassado. Mas você teimosamente (como eu) defende um ponto de vista diferente.
Bem, é estranho dar ordens comerciais baseadas em um ambiente comercial ultrapassado. Mas você teimosamente (como eu) defende um ponto de vista diferente.
Você tem que escolher o menor de dois males.
Naturalmente, o exemplo com o alongamento do limite atrás do preço é melhor para implementar na variante "1 EA = 1 ordem em cada direção".
Mas, em geral, é melhor manter todas as suas ordens sob controle.
Mas em geral é mais correto manter todos os seus pedidos sob controle.
Ou seja, você não concorda com a exigência de que o TS trabalhe somente com o ambiente comercial atual.
Ou seja, você não concorda com a exigência de que o TS trabalhe apenas com o ambiente comercial atual.
Se você tiver que sacrificar o controle de todas as ordens da TC para fazê-lo - absolutamente.
Imagine: você tem uma frota de quatro caminhões. Cada um deles está transportando cargas valiosas do ponto A ao ponto B. Você precisa monitorar a rota.
O que você preferiria: estar em contato a cada minuto com um deles, ou a cada 2 minutos com todos eles?
No segundo caso, o atraso será ligeiramente maior, e todos os quatro podem ter que fazer um ligeiro desvio se não forem roteados a tempo. Mas em geral será melhor para o negócio do que carregar um caminhão e perder os outros três.
Se você tiver que sacrificar o controle de todas as ordens da TC para fazê-lo, absolutamente.
Imagine: você tem uma frota de 4 caminhões. Cada um deles transporta uma carga valiosa do ponto A ao ponto B. Você precisa controlar a rota.
Você prefere ter comunicação a cada minuto com um deles, ou a cada 2 minutos com todos eles?
No segundo caso, o atraso será ligeiramente maior, e todos os quatro podem ter que fazer um pequeno desvio se você não conseguir encaminhá-los a tempo. Mas em geral será melhor para os negócios do que gastar um caminhão e perder os outros três.
+1.
Talvez a nova idéia não tivesse surgido com a abordagem OOP, onde um loop analógico com força bruta de ordem está escondido em alguma entidade tipo gerente que, ao invés de chamar OrderModify diretamente, gera um comando de modificação (com todos os parâmetros) e o coloca em uma fila que é então processada. A idéia é dividir a responsabilidade (que, neste código, está enfiada em um único loop) entre alguma entidade que analisa o ambiente e uma entidade que realiza ações com base na análise.
Talvez esta idéia não surgisse com a abordagem OOP, quando um análogo de loop com busca de ordem é escondido em alguma entidade como o gerente, que em vez de chamar OrderModify gera diretamente um comando para modificar (com todos os parâmetros) e o coloca em uma fila, que é então processada. A idéia é dividir a responsabilidade (que neste código está enfiada em um único loop) entre um objeto de análise do ambiente e um objeto de realização de ações com base na análise.
A única maneira de evitar tal situação é usar ordens assíncronas.
Caso contrário, ainda haveria um loop na lista de comandos a serem executados, que é, na verdade, um loop nas ordens.
Somente em uma situação de fila você ainda teria que fazer provisões para substituir uma ordem antiga não executada relativa a uma ordem por uma ordem mais nova. Caso contrário, a fila poderia transbordar e as ordens enviadas para fora da fila ficariam obsoletas.