Um checklist dos riscos dos robôs antes de operar em conta real - página 4
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 falei há itens que jamais se passaram por minha mente ou o que já tenha lido sobre segurança em execução em Expert Adivisor. Assim costumo apreciar seu comentários, pois creio ser um bom aprendizado. Sobre o ultimo item que apontei, por mais óbvio e auto explicativo seja os itens de sua lista, você sempre um algo mais a explorar, o que considero relevante, interessante e até didático.
Não me considero um grande trader, mais programador que trader. Acho válida e excelente a lista. Além do mais esta lista ressalta a importância de como temos que ensinar nossos robôs a passar por suas adversidades no decorrer de sua vida. Muito só pode advir de muito experiência, testes, erros, simulações, acertos.
Considero de altíssima importante gerenciar as possíveis e já existentes exceções e limites. Afinal de contas, sendo nós traders programadores de robôs, não vamos querer que nosso programa trave, ainda mais quando está em jogo nossas reservas e capitais financeiro.
Sua lista ensina muito, além de ser um ótimo atalho, em especial aos novatos deste fórum, que assim como eu um dia fui, podem ser aventurar a criar robôs sem dedicação e atenção às adversidades que poderiam enfrentar.
Mas dos itens que atualmente me intriga é como gerenciar a proteção contra mudanças abruptas de volumes e preços dos instrumentos financeiros. Mas ao meu ver requer capacidade de processamento do hardware elevado (ao menos é requerimento que meu hardware não obedece), já que surtos podem ocorrer de ora para outra.
O que me fez lembrar a um tempo: quais os requerimentos de hardware são necessários para darmos ao nosso robô as condições para promover a execução da checklist? Considero isso altamente pertinente.
Como falei há itens que jamais se passaram por minha mente ou o que já tenha lido sobre segurança em execução em Expert Adivisor. Assim costumo apreciar seu comentários, pois creio ser um bom aprendizado. Sobre o ultimo item que apontei, por mais óbvio e auto explicativo seja os itens de sua lista, você sempre um algo mais a explorar, o que considero relevante, interessante e até didático.
Não me considero um grande trader, mais programador que trader. Acho válida e excelente sua lista. Além do mais esta lista ressalta como temos que ensinar nossos robôs a passar por suas adversidades no decorrer de sua vida. Muito só pode advir de muito experiência, testes, erros, simulações, acertos.
Considero de altíssima importante gerenciar as possíveis e já existentes exceções e limites. Afinal de contas, sendo nós traders programadores de robôs, não vamos querer que nosso programa trave, ainda mais quando está em jogo nossas reservas e capitais financeiro.
Sua lista ensina muito, além de ser um ótimo atalho, em especial aos novatos deste fórum, que assim como eu um dia fui, podem ser aventurar a criar robôs sem dedicação e atenção às adversidades que poderiam enfrentar.
Mas dos itens que atualmente me intriga é como gerenciar a proteção contra mudanças abruptas de volumes e preços dos instrumentos financeiros. Mas ao meu ver requer capacidade de processamento do hardware elevado (ao menos é requerimento que meu hardware não obedece). O que me fez lembrar de quais os requerimentos de hardware são necessários para darmos ao nosso robô as condições para promover a execução da checklist?
Olá Elmo, obrigado pelas palavras, sempre com viés positivo e equilibrado. Nessa questão de proteção contra mudanças abruptas de volumes e preços existem no mínimo dois enfoques: mudanças reais do mercado, afinal o grau de incerteza do mercado financeiro é muito alto e as mudanças abruptas por falhas e erros dos sistemas de gestão e tratamento dos dados.
Acredito que nesse tópico a principal preocupação é o enfoque de falhas e erros dos sistemas, como por exemplo a falta de dados em determinados períodos, ou até mesmo a falha por erro grosseiro nos preços ou volume de determinado ativo.
Endereçar essa questão é realmente complexo, pois na prática podem acontecer gaps no mercado que injetam ruído nos algoritmos de conferência. Talvez a melhor solução seja comparar os dados com o de outras plataformas (o que até já foi feito em outros tópicos desse fórum). Nesse ponto a tua pergunta quanto à necessidade de recursos está bem alinhada, porque estamos falando de mais recursos, principalmente de software.
Sendo assim, e já respondendo tua pergunta, acredito que não há um limite fácil de ser determinado de software, hardware, e até mesmo firmware para execução do checklist, até porque estamos diante de diversas incertezas, mas talvez o desafio esteja justamente em conseguir fazer isso com o mínimo de recursos. Como o engenheiro que ergue prédios com custos e segurança viáveis, acredito que nosso objetivo deva ser encontrar um meio termo onde seja possível responder sim para todo checklist utilizando as próprias especificações de hardware/software da plataforma MT5 e de preferência tentar encapsular isso em um Expert Advisor.
Olá Elmo, obrigado pelas palavras, sempre com viés positivo e equilibrado. Nessa questão de proteção contra mudanças abruptas de volumes e preços existem no mínimo dois enfoques: mudanças reais do mercado, afinal o grau de incerteza do mercado financeiro é muito alto e as mudanças abruptas por falhas e erros dos sistemas de gestão e tratamento dos dados.
(...)
Sendo assim, e já respondendo tua pergunta, acredito que não há um limite fácil de ser determinado de software, hardware, e até mesmo firmware para execução do checklist, até porque estamos diante de diversas incertezas, mas talvez o desafio esteja justamente em conseguir fazer isso com o mínimo de recursos. Como o engenheiro que ergue prédios com custos e segurança viáveis, acredito que nosso objetivo deva ser encontrar um meio termo onde seja possível responder sim para todo checklist utilizando as próprias especificações de hardware/software da plataforma MT5 e de preferência tentar encapsular isso em um Expert Advisor.
Dica de artigo na área de controle de risco de robôs, vários deles já estão no checklist do tópico.
WilmerHale discusses Risk Controls for Automated Trading Environments - Addressing the Need for Speed: CFTC Seeks Comment on Risk Controls for Automated Trading Environments
http://clsbluesky.law.columbia.edu/2013/11/08/wilmerhale-discusses-risk-controls-for-automated-trading-environments/
Conta e risco real? Pense no risco, antes do lucro
Se eu fosse condensar todo o checklist desse tópico em relação aos riscos de operar em conta real, talvez a frase mais importante seria essa: pense no risco, antes do lucro.
Não há nada mais perigoso que uma teoria e um sistema que se apresenta com uma lógica infalível. Isso porque ela irá colocar o lucro antes do risco.
Na verdade não é nada fácil priorizar o risco diante da possibilidade de lucro, principalmente quando essa possibilidade está baseada em alguma lógica científica.
Ao longo de vários anos estudando e testando robôs, não foram poucas vezes que vi brilhantes gênios e quants serem surpreendidos com a queda repentina de toda sua teoria infalível. É o momento que o grande cientista volta à humildade, e a fórmula inicial.
Talvez nessa fórmula inicial seja necessário mudar a gestão de risco, ou, no mínimo, sua prioridade.
Ou seja, talvez o maior perigo para um trader, principalmente o quantitativo, e portanto para seu trading system, seja a certeza de que encontrou uma lógica no mercado. Quando visualizamos a lógica, muitas vezes através de simples backtesting, geralmente ficamos cegos para o risco. Lembre que encontrar uma lógica no passado é talvez algo muito simples nos dias de hoje, com tantas alternativas de sistemas e tecnologias. Eu diria que é quase uma obrigação. O risco está no fato de que essa lógica sempre será probabilística e não determinística.
Para fugir da lógica você deve começar a aceitar e buscar o improvável, o pouco esperado ou ainda o que parece ser totalmente contra a lógica, e que você considera praticamente uma ruptura da lei de mercado que aparenta estar em suas mãos.
E talvez o mais improvável de tudo seja que você terá que esquecer aquela lógica que parecia uma grande fonte de lucro e substituir por outra de menor lucro, e, provavelmente, menor risco.
Nesse sentido, vale a pena pensar no risco não apenas como um StopLoss, como a maioria, mas como um CheckList de segurança, no mínimo com a extensão proposta nesse tópico.
No tópico abaixo é analisado um problema que poderia e deveria ser eliminado no checklist, e que considero ainda mais relevante para quem estiver operando na BM&FBovespa.
Forum on trading, automated trading systems and testing trading strategies
Multiple Order Entry Problem for live account with a specific broker
figurelli, 2014.05.16 12:38
Hi FinanceEngineer, you are right, however the first thing to manage is select a low latency broker, since markets are each time faster, and it will be usual such problems.
Also, it's always good think about the worst case, because you can have a low latency broker but at some moments of day a big delay, for instance when you have relevant news.
Anyway, OrderSend() in MT5 is not so easy to manage as MT4, because MT4 returned value is a Ticket. This change was necessary at MT5 because asynchronous communication of stock markets, introduced at MQL5 architecture, that is enabled to communicate with broker OMS protocol (like FIX, for instance).
But I think this is the big change of OMS for order management today, since it's very hard get a real time Ticket, and MT5 is updated to this new scenario, mainly if we use stock markets, where we have more latency.
In this sense, the more relevant thing you do after a OrderSend() at MT5 is check PositionSelect(), and I strongly suggest use my proposed PositionSelectTimeout() workaround, for all reasons above.
The only way I see to think about worst cases is manage all the if { } else { } conditions after sending an order to the market, in a way you can manage any situation.
I would like to have catch { } too, but we can use GetLastError() to do something near this.
This because you also need the Ticket to confirm a position and MT5 OrderSend() don't return the ticket as sychronous as MT4 does.
Excelente tópico!
Testei diversos robôs e continuo a testar. Vários quebraram, mesmo os EA Martingale. Creio que seja possível ter um robô que obtenha um percentual mais alto do que perda.
Para isso, no meu ponto de vista esse robô terá que ter sem sombra de dúvida um Stop Loss, reconhecer também a margem de lucro para se manter na ordem e utilizar um trailling stop para sair no ponto certo com ganho.
Ninguém sabe para onde vai o mercado, os que sabem estão bem longe daqui, creio eu...rs.
Sendo assim, o negócio é seguir a onda, pois o mercado se movimenta através dos sentimentos e acontecimentos das empresas e mercados. Até onde vai, só vamos saber quando tivermos bola de cristal.
Excelente tópico!
Testei diversos robôs e continuo a testar. Vários quebraram, mesmo os EA Martingale. Creio que seja possível ter um robô que obtenha um percentual mais alto do que perda.
Para isso, no meu ponto de vista esse robô terá que ter sem sombra de dúvida um Stop Loss, reconhecer também a margem de lucro para se manter na ordem e utilizar um trailling stop para sair no ponto certo com ganho.
Ninguém sabe para onde vai o mercado, os que sabem estão bem longe daqui, creio eu...rs.
Sendo assim, o negócio é seguir a onda, pois o mercado se movimenta através dos sentimentos e acontecimentos das empresas e mercados. Até onde vai, só vamos saber quando tivermos bola de cristal.
Olá katsu, obrigado e bem-vindo ao Fórum.
Essa sua frase é fundamental, testar e continuar testando robôs.
Realmente ninguém sabe com certeza para onde vai o mercado (nem o potencial ilimitado dos robôs), mas é possível construir modelos e cenários de possíveis mercados futuros, o que não está muito distante do que fazem os grandes gestores utilizando sua visão estratégica.
Conseguindo fazer isso, o desafio passa a ser perceber rapidamente quando o mercado está mudando de rumo.
Uma das perguntas que mais recebo, quando estou envolvido na análise de sistemas existentes é por que o EA não executou determinada operação?
Na verdade o trader busca entender as razões de um problema dentro do checklist apresentado. E são muitas as possibilidades.
Esse é um fator curioso dos robôs, pois eles são muito elogiados por executarem tudo que mandamos eles fazerem de forma fria e calculista, sem emoções portanto.
Mas temos a esperança de que eles irão executar algo que não programamos.
Talvez a vantagem do trader discricionário esteja nesse fato, os sentimentos fazem ele ter sensores de risco aguçados, que identificam rapidamente a necessidade de mais insights, ou no caso dos robôs, mais algoritmos, principalmente na área de segurança.
Já o robô ele estará frio no caso de uma falha ou erro nos algoritmos, principalmente quanto às lacunas que deixaram de ser preenchidas, e que no backtesting pareciam tão corretas.
E isso me faz concluir que talvez os robôs de maior risco sistêmico no mercado, principalmente na BM&FBovespa, não são os relacionados à codificação de seus modelos que irão resultar em suas estratégias, mas ao que deixou de ser programado no robô para a execução segura de suas operações e sua estabilidade diante das incertezas da plataforma e mercado.
Estou acrescentando um novo item no checklist, que é o segunte: 17.Existe proteção de limite nos loops do código fonte?
Isso se deve ao que tenho percebido com alguns clientes, e seus códigos fonte, onde não existe nenhuma proteção de limites dentro dos loops utilizados.
Para maior entendimento, vamos analisar um exemplo de código fonte, sem proteção, como o abaixo:
Aparentemente não existe nenhum problema nesse loop, mas o que aconteceria se por algum motivo o valor da variável 'periodo_media' fosse alterado de forma errônea para um valor absurdamente alto?
Em termos técnicos, chamamos essa como uma situação de overflow.
Para proteger contra situações não esperadas, principalmente em conta real, seria mais prudente limitar o valor de varredura e testar as situações de overflow, como por exemplo no código abaixo:
Nesse caso, além de uma proteção contra variação errônea do valor da variável 'periodo_media', o sistema irá alertar o trader quando a situação de não conformidade ocorrer.
Sem dúvida é mais trabalhoso pensar e fazer dessa forma, mas considero essencial esse tipo de proteção em qualquer código de robô.