Regras de estrutura. Aprender a estruturar programas, explorar possibilidades, erros, soluções, etc. - página 9
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
Não pensem que estou a ser esperto, mas dêem outra vista de olhos a esta arquitectura de escrever um TC de combate. Não há feedback.
Existem posições virtuais e existe um ambiente comercial real que está adaptado à virtualidade.
Nesse caso, não importa sequer se a rede está na plataforma ou noutro sistema contabilístico.
Penso que é uma estrutura muito interessante, especialmente para estratégias de alta velocidade que não podem ser verificadas no testador regular.
Só que não é muito claro sobre o "sincronizador inteligente". Provavelmente significam um copiador adaptativo de ordens de negociação cuja tarefa, se bem entendi, é ajustar a rentabilidade virtual / rentabilidade da estratégia e o estado actual do mercado - liquidez, velocidade de execução, etc...
Em geral, seria bom ter tal testador e sincronizador não monolítico construído no Expert Advisor, mas como um módulo externo separado.
Neste caso, qualquer Expert Advisor ou vários podem estar ligados a ele e mesmo utilizar selectivamente os sinais mais apropriados.
Será que isto é realista usando apenas MQL?
Este é um módulo separado em termos de lógica.
Por exemplo, o serviço de Sinais é um módulo separado, não relacionado com o TS de forma alguma:
Traduz simplesmente posições de fonte virtual (são virtuais para si) para o seu ambiente comercial.
Curiosamente (não da melhor forma), é claro, mas traduz-se.
Este é um módulo separado em termos de lógica.
Por exemplo, o serviço de Sinais é um módulo separado, não relacionado com o TS de forma alguma:
Traduz simplesmente posições de fonte virtual (são virtuais para si) para o seu ambiente comercial.
Curiosamente (não da melhor forma), é claro, mas traduz-se.
Acontece que existe um tradutor do Google que traduz tortuosamente mas que o fará se não precisar de o compreender, mas se precisar de o compreender com precisão - aprender a língua).
Eu ficaria satisfeito com uma opção intermédia - um tradutor pessoal de alta qualidade (módulo), quando a tradução é boa e não há necessidade de escrever código em cada EA.
Compreender como estruturar um programa vem com a experiência. Todos aqui têm experiências diferentes, e por isso a ordem e as regras de estruturação serão únicas. Além disso, estas regras vão mudar com o tempo - isto é, o que parecia uma estrutura ideal há alguns anos atrás, hoje pode não resistir nem mesmo às críticas mais leves.
A estrutura dos programas em MQL é uma canção separada, porque é na essência uma DSL, controlada por eventos do terminal (embora tenham sido dados passos enormes para a aproximar das línguas de uso geral). Imho, para a descrição de estratégias comerciais a melhor maneira é uma máquina de estado, e já houve aqui alguns artigos sobre o assunto. Na realidade, a estrutura degenera num grande caso com muitas exclusões para a realização de cada caso.
Abstraindo-me das tarefas comerciais, atribuo geralmente uma parte essencial, que nada sabe sobre as especificidades da interacção com o utilizador. A sua finalidade é fornecer uma forma de se preencher com dados, resolver o problema com base nos dados recebidos e emitir o resultado. O núcleo pode ser constituído fisicamente por vários ficheiros, mas todos eles devem estar ligados logicamente e fornecer fora apenas métodos de recepção de dados e métodos de devolução de dados e nada mais. A analogia mais simples é um moedor de carne.
A segunda coisa que considero importante é localizar as partes a serem alteradas (ou as partes que poderiam potencialmente ser alteradas) e separá-las numa abstracção separada. Com esta abordagem, podemos alternar sem problemas entre diferentes implementações do mecanismo (por exemplo, ao mudar o mecanismo de abertura de posição, podemos virtualizar a negociação). As diferentes implementações são convenientemente armazenadas numa pasta separada com um nome genérico.
A estrutura do projecto assemelhar-se-á a uma árvore com o seu tronco (Núcleo) constituído por diferentes subsistemas (Subsistemas) e ramos de comportamento variável (Comportamento) divergindo do mesmo. E junto a ela haverá um binóculo (Reporting, GUI) para olhar para esta árvore do ângulo necessário e um machado e uma serra eléctrica (Actions, GUI) para nos proporcionar a interacção necessária com esta árvore.
Máquinas de estado simples ao serviço do revelador
Máquinas de estado simples ao serviço do revelador
Dê pelo menos um exemplo aproximado a aplicar às nossas realidades.
Você é realmente algo :) A implementação de qualquer estratégia é essencialmente uma máquina estatal.
Compreendo. Pedi um exemplo de tal máquina à luz do artigo sobre o charabra.
Oh, ok. Havia um artigo onde o tipo fazia um "análogo" de uma máquina estatal. E estava a impulsionar esta tecnologia como uma inovação de programação de vanguarda).
Mas não me consigo lembrar de nenhum artigo substantivo sobre máquinas estatais aqui. Não me lembro disso aqui.
Dar pelo menos um exemplo rudimentar, tal como aplicado às nossas realidades.
Ahaha, faz-me lembrar "quais serão as vossas provas".
Basta pesquisar no Google "state machine", escolher o conteúdo de que mais gostava e carregá-lo aqui.
Não provando nada, não refutando nada. Artigo interessante.
Em geral, sou contra os dogmas. Se uma pessoa o usa, não significa que sirva a outra.
Mas ao ler o código de outra pessoa, deparo-me frequentemente com analogias com máquinas de estado. Apenas uma observação.