Algoritmos de otimização populacionais: salto de sapo embaralhado
Algoritmos de otimização populacionais: salto de sapo embaralhado
O artigo apresenta uma descrição detalhada do algoritmo salto de sapo embaralhado (Shuffled Frog Leaping Algorithm, SFL) e suas capacidades na solução de problemas de otimização. O algoritmo SFL é inspirado no comportamento dos sapos em seu ambiente natural e oferece uma nova abordagem para a otimização de funções. O algoritmo SFL é uma ferramenta eficaz e flexível, capaz de lidar com diversos tipos de dados e alcançar soluções ótimas.
Desenvolvendo um sistema de Replay (Parte 43): Projeto do Chart Trade (II)
Desenvolvendo um sistema de Replay (Parte 43): Projeto do Chart Trade (II)
Grande parte das pessoas que querem, ou desejam aprender a programar, não fazem de fato ideia, do que estão fazendo. O que elas fazem é tentar criar as coisas de uma determinada maneira. No entanto, quando programamos não estamos de fato tentando criar um solução. Se você tentar fazer isto, desta forma irá gerar mais problemas do que realmente uma solução. Aqui iremos fazer algo um pouco mais avançado, e por consequência diferente.
Teoria das Categorias em MQL5 (Parte 18): Quadrado de naturalidade
Teoria das Categorias em MQL5 (Parte 18): Quadrado de naturalidade
Este artigo dá continuidade à série sobre a teoria das categorias, abordando as transformações naturais, que são um elemento fundamental da teoria. Vamos examinar a definição que parece complexa à primeira vista, depois mergulhar em exemplos e formas de aplicar as transformações na previsão de volatilidade.
GIT: Mas que coisa é esta ?
GIT: Mas que coisa é esta ?
Neste artigo apresentarei uma ferramenta de suma importância para quem desenvolve programas. Se você não conhece GIT, veja este artigo para ter uma noção do que se trata, tal ferramenta. E como usá-la junto ao MQL5.
Teoria das Categorias em MQL5 (Parte 15): Funtores com grafos
Teoria das Categorias em MQL5 (Parte 15): Funtores com grafos
Este artigo continua a série sobre a implementação da teoria de categorias no MQL5, ele aborda os funtores como uma ponte entre grafos e conjuntos. Nesse escopo, voltaremos a analisar os dados de calendário e, apesar de suas limitações no uso do testador de estratégias, justificaremos o uso de funtores na previsão de volatilidade mediante correlação.
Desenvolvendo um sistema de Replay (Parte 40): Iniciando a segunda fase (I)
Desenvolvendo um sistema de Replay (Parte 40): Iniciando a segunda fase (I)
Esta é a nova fase do sistema de replay / simulação. Nesta fase a conversa de fato irá ser seria. E o conteúdo irá ser tornar bastante denso. Peço que você leia com calma o artigo e sempre procure usar as referencias que possivelmente estarão sendo indicadas nos artigos. Isto para lhe ajudar a compreender melhor o que estará sendo explicado.
Teoria das Categorias em MQL5 (Parte 14): funtores com ordem linear
Teoria das Categorias em MQL5 (Parte 14): funtores com ordem linear
Este artigo, parte de uma série de artigos sobre a implementação da teoria das categorias no MQL5, é dedicado aos funtores. Vamos explorar como a ordem linear pode ser mapeada em um conjunto de dados através dos funtores ao analisar dois conjuntos de dados que, à primeira vista, parecem não ter nenhuma conexão entre si.
Desenvolvendo um sistema de Replay (Parte 38): Pavimentando o Terreno (II)
Desenvolvendo um sistema de Replay (Parte 38): Pavimentando o Terreno (II)
Muita gente que se diz programador de MQL5, não tem as bases que estarei apresentando aqui, neste artigo. Muitos consideram o MQL5 algo limitado, mas tudo isto se deve a falta de conhecimento. Então, não fique com vergonha por não saber. Mas tenha vergonha de não perguntar. Mas o simples fato, de forçar, e obrigar o MetaTrader 5 a não permitir que um indicador seja duplicado. Não nos dá de maneira alguma meios de efetivar uma comunicação bilateral entre o indicador e o EA. Ainda estamos um pouco longe disto. Mas o simples fato de que o indicador não estará duplicado no gráfico, já nos garante uma certa tranquilidade.
Desenvolvendo um sistema de Replay (Parte 37): Pavimentando o Terreno (I)
Desenvolvendo um sistema de Replay (Parte 37): Pavimentando o Terreno (I)
Neste artigo iremos começar a fazer algo, que eu gostaria de ter feito a muito mais tempo. No entanto, por falta de "terreno firme", não me sentia seguro para apresentar de forma publica. Mas agora já tenho as bases para poder fazer o que iremos começar a fazer, a partir de agora. É bom que foque ao máximo em compreender o conteúdo deste artigo. E não estou dizendo isto, apenas para que você o leia apenas por ler. Quero e preciso enfatizar que se você não entender este artigo especifico. Poderá abandonar completamente qualquer esperança em compreender o conteúdo dos próximos.
Desenvolvendo um sistema de Replay (Parte 36): Ajeitando as coisas (II)
Desenvolvendo um sistema de Replay (Parte 36): Ajeitando as coisas (II)
Uma das coisas que mais pode complicar a nossa vida como programadores é o fato de supor as coisas. Neste artigo mostrarei o perigo de fazer suposições. Tanto na parte da programação em MQL5, onde você supõem que um tipo terá um dado tamanho. Assim como no uso do MetaTrader 5, onde você supõem que servidores diferentes funcionam da mesma forma.
Desenvolvendo um sistema de Replay (Parte 35): Ajeitando as coisas (I)
Desenvolvendo um sistema de Replay (Parte 35): Ajeitando as coisas (I)
Temos que corrigir algumas coisas antes de realmente poder continuar. Mas não se trata necessariamente de uma correção e sim de um aperfeiçoamento na forma de gerir e utilizar classe. O motivo é que existem falhas ocorrendo por conta de algum tipo de interação dentro do sistema. Apesar das tentativas de tentar compreender o motivo de algumas das falhas, para assim sana-las. Todas foram frustradas, já que não fazia o mínimo sentido de algumas delas estarem ocorrendo. Quando fazemos uso de ponteiros ou recursão em C / C++, e o programa começa a apresentar falhas.
Desenvolvendo um sistema de Replay (Parte 34): Sistema de Ordens (III)
Desenvolvendo um sistema de Replay (Parte 34): Sistema de Ordens (III)
Vamos neste artigo concluir a primeira fase da construção. Será algo relativamente rápido, mas explicarei detalhes que podem não ter sido comentados no passado. Mas ainda assim aqui explicarei algumas coisas que muitos não entender por que são como são. Um destes casos é o Mouse. Você sabe o motivo de ter que pressionar a tecla Shift ou Ctrl no teclado ?!?!
Desenvolvendo um sistema de Replay (Parte 33): Sistema de Ordens (II)
Desenvolvendo um sistema de Replay (Parte 33): Sistema de Ordens (II)
Vamos continuar o desenvolvimento do sistema de ordens. Mas você irá ver que iremos fazer uma reutilização massiva de coisas já vistas em outros artigos. Mesmo assim teremos um bônus neste artigo. Iremos desenvolver, primeiramente um sistema que consiga ser operado junto ao servidor de negociação real, seja usando uma conta demo, seja usando uma conta real. Vamos fazer uso massivo e extensivo da plataforma MetaTrader 5, para nos fornecer todo o suporte do qual precisaremos neste inicio de jornada
Desenvolvendo um sistema de Replay (Parte 32): Sistema de Ordens (I)
Desenvolvendo um sistema de Replay (Parte 32): Sistema de Ordens (I)
De todas as coisas desenvolvidas até aqui. Esta com toda a certeza, vocês também irão notar, e com o tempo irão concordar, que é a mais desafiadora de todas. O que temos de fazer é algo simples. Fazer com que o nosso sistema, simule o que um servidor de negociação efetua na prática. Isto de ter que implementar uma forma de simular, exatamente o que seria feito, pelo servidor de negociação, parece simples. Pelo menos nas palavras. Mas precisamos fazer isto de uma maneira, que para o usuário do sistema de replay / simulação, tudo venha a acontecer, de forma o mais invisível, ou transparente, possível.
Desenvolvendo um sistema de Replay (Parte 31): Projeto Expert Advisor - Classe C_Mouse (V)
Desenvolvendo um sistema de Replay (Parte 31): Projeto Expert Advisor - Classe C_Mouse (V)
Desenvolver uma forma de colocar o cronometro, de modo que durante um replay / simulação, ele consiga nos dizer quanto tempo falta, pode parecer a principio uma tarefa simples e de rápida solução. Muitos iriam simplesmente tentar adaptar e usar o mesmo sistema que é usado quando temos o servidor de negociação ao nosso lado. Mas aqui mora um ponto que muitos talvez não se atentem ao pensar em tal solução. Quando você está fazendo um replay, e isto para não falar do fato da simulação, o relógio não funciona da mesma forma. Este tipo de coisa torna complexo construir tal sistema.
Desenvolvendo um sistema de Replay (Parte 30): Projeto Expert Advisor - Classe C_Mouse (IV)
Desenvolvendo um sistema de Replay (Parte 30): Projeto Expert Advisor - Classe C_Mouse (IV)
Aqui demonstrarei uma técnica que pode lhe ajudar muito, em vários momentos durante a sua vida como programador. Diferente do que muitos dizem, não é a plataforma que é limitada, mas sim o conhecimento do individuo que diz que tal coisa. O que será explicado aqui, mostrar que com um pouco de bom senso e criatividade, você pode tornar a plataforma MetaTrader 5 muito mais interessante e versátil. E sem precisar de fato criar programas malucos ou coisas do estilo. Você pode criar um código simples, porém seguro e confiável. Usando de perspicácia, domar o código a fim de modificar algo já existente, sem se quer remover ou adicionar uma única linha se quer, no código original.
Desenvolvendo um sistema de Replay (Parte 29): Projeto Expert Advisor — Classe C_Mouse (III)
Desenvolvendo um sistema de Replay (Parte 29): Projeto Expert Advisor — Classe C_Mouse (III)
Agora que a classe C_Mouse foi melhorada. Podemos focar em criar uma classe que será usada para promover uma base completamente diferente de estudos. Mas como expliquei no inicio do artigo, não iremos usar herança ou polimorfismo para gerar esta nova classe. Iremos modificar, ou melhor dizendo, agregar alguns objetos novos a linha de preço. Isto neste primeiro momento, no próximo artigo mostrarei como modificar os estudos. Mas faremos isto sem mexer no código da classe C_Mouse. Sei que na pratica, isto seria mais simples ser feito usando herança ou polimorfismo. No entanto, existem técnicas diferentes para se conseguir a mesma coisa.
Desenvolvendo um sistema de Replay (Parte 28): Projeto Expert Advisor — Classe C_Mouse (II)
Desenvolvendo um sistema de Replay (Parte 28): Projeto Expert Advisor — Classe C_Mouse (II)
Quanto de fato os primeiros sistema capazes de fatorar alguma coisa, começaram a ser produzidos. Tudo tinha que ser feito por engenheiros com grande conhecimento, no que estava sendo projetado. Isto nos primórdios da computação, onde se quer existia algum tipo de terminal, para que fosse possível programar algo. Conforme ia se desenvolvendo, e o interesse de que mais pessoas também conseguisse criar algo, começou surgir novas ideias e meios, de programar aquelas máquinas, que antes era feito mudando a posição dos conectores. Assim começamos a ter os primeiros terminais.
Desenvolvendo um sistema de Replay (Parte 27): Projeto Expert Advisor — Classe C_Mouse (I)
Desenvolvendo um sistema de Replay (Parte 27): Projeto Expert Advisor — Classe C_Mouse (I)
Neste artigo irá nascer a classe C_Mouse. Esta foi pensada de maneira que a programação, seja feita no mais alto nível quanto for possível ser feita. Mas dizer que trabalharemos em alto, ou baixo nível, nada tem haver com questões de colocarmos palavrões ou chavões no meio do código. Longe disto. Trabalhar em alto nível ou de baixo nível, quando se fala em programação, diz o quanto o programa pode ser mais simples ou mais difícil de ser lido por outro programador.
Teoria das Categorias (Parte 9): Ações dos monoides
Teoria das Categorias (Parte 9): Ações dos monoides
Esse artigo é a continuação da série sobre a implementação da teoria das categorias em MQL5. Nele são discutidas as ações de monoides como um meio de transformar os monoides descritos no artigo anterior para aumentar suas aplicações.
Desenvolvendo um sistema de Replay (Parte 26): Projeto Expert Advisor — Classe C_Terminal
Desenvolvendo um sistema de Replay (Parte 26): Projeto Expert Advisor — Classe C_Terminal
Talvez já podemos começar a desenvolver um Expert Advisor a ser utilizado no replay / simulação. Mas não iremos criar qualquer coisa, este precisará ser algo um pouco mais bem elaborado. Mas não nos deixemos nos levar pelo grau de dificuldade neste primeiro momento. Temos de começar a fazer as coisas partindo de algum ponto. Caso contrário apenas iremos nos conformar, imaginando o qual difícil o desafio é, sem ao menos tentarmos de fato superar este obstáculo. Vida de programador de fato é isto: Encontrar um obstáculo e tentar superar ele, via estudo, testes e bastante pesquisa.
Desenvolvendo um sistema de Replay - Simulação de mercado (Parte 25): Preparação para a próxima etapa
Desenvolvendo um sistema de Replay - Simulação de mercado (Parte 25): Preparação para a próxima etapa
Aqui neste artigo iremos finalizar a primeira etapa do desenvolvimento do sistema de replay / simulador. Ao finalizar esta etapa, estou dizendo a você, caro leitor, que o sistema já estará em um estágio avançado o suficiente para que novas funcionalidades possam de fato serem implementadas. Isto a fim de tornar o sistema ainda mais elaborado e mais útil para efetuar estudos e desenvolver conceitos de analise de mercado.
Desenvolvendo um sistema de Replay - Simulação de mercado (Parte 24): FOREX (V)
Desenvolvendo um sistema de Replay - Simulação de mercado (Parte 24): FOREX (V)
Aqui estamos retirando o bloqueio de simulação baseada na plotagem LAST, e adicionando um ponto de entrada para este tipo de simulação. Agora prestem atenção ao fato de que todo o funcionamento, irá se basear no sistema do forex. Sendo que a única diferença, aqui nesta rotina, é o fato de que estaremos separando uma simulação BID, de uma LAST. Mas a questão de randomização do tempo e a sua correção para ser utilizado pela classe C_Replay, é a mesma em ambos modos de simulação. Isto é uma coisa boa, já que se modificarmos um dos modos, o outro irá se beneficiar, pelo menos no que rege a parte do tempo entre os tickets
Teoria das Categorias em MQL5 (Parte 8): Monoides
Teoria das Categorias em MQL5 (Parte 8): Monoides
Esse artigo continua a série sobre a implementação da teoria da categoria em MQL5. Aqui, apresentamos os monoides como um domínio (conjunto) que distingue a teoria da categoria de outros métodos de classificação de dados ao incorporar regras e um elemento de equivalência.
Desenvolvendo um sistema de Replay - Simulação de mercado (Parte 23): FOREX (IV)
Desenvolvendo um sistema de Replay - Simulação de mercado (Parte 23): FOREX (IV)
A criação, agora, é efetuada no mesmo ponto que fazemos a conversão dos tickets em barras. Então se algo vim a dar errado durante a conversão, iremos logo notar o erro. Pois o mesmo código que lança as barras de 1 minuto no gráfico, quando fazemos um avanço rápido, também é utilizando pelo sistema de posicionamento, e também é usado para lançar as barras durante o avanço normal. Ou seja, agora o código responsável por tal tarefa, não esta mais sendo duplicado em ponto algum. Desta forma, já temos um sistema bem mais adequado, tanto para manutenção, quanto para melhorias.
Desenvolvendo um sistema de Replay - Simulação de mercado (Parte 22): FOREX (III)
Desenvolvendo um sistema de Replay - Simulação de mercado (Parte 22): FOREX (III)
Para quem ainda não entendeu a diferença entre o mercado de bolsa e o de forex, apesar de este já ser o terceiro artigo em que estou abordando isto. Devo deixar claro, que a grande diferença, é o fato de que no forex não existe, ou melhor, não nos é informado algumas coisas a respeito do que aconteceu de fato na negociação.
Desenvolvendo um sistema de Replay - Simulação de mercado ( Parte 21):  FOREX (II)
Desenvolvendo um sistema de Replay - Simulação de mercado ( Parte 21): FOREX (II)
Vamos continuar a montagem do sistema para cobrir o mercado de FOREX. Então para resolver este problema, precisaríamos primeiramente, declarar o carregamento dos tickets, antes de fazer o carregamento das barras previas. Isto resolve o problema, mas ao mesmo tempo força o usuário, a um tipo de modelagem do arquivo de configuração, que ao meu ver não faz muito sentido. O motivo é que, ao desenvolver a programação, responsável por analisar e executar o que esta no arquivo de configuração, podemos permitir ao usuário, declarar as coisas em qualquer ordem.