Auto-aprendizagem da linguagem MQL5 a partir do zero - página 48

[Реter Konow]

Se o objetivo imediato é implementar uma simples parada de rastreamento, você deve continuar escrevendo o roteiro adicionando os loops de e para e enquanto isso.

Não tenho certeza de que o roteiro de "paciência suficiente" tenha uma extensão lógica. É provavelmente melhor passar para uma nova idéia que requer ter:

1. Uma árvore de condição if-else.

2. Funções de cálculo.

3. Ciclos.

Como teremos que trabalhar no campo do comércio algorítmico, seria mais conveniente se o roteiro estivesse relacionado com a estratégia comercial. Pense sobre isso.

[Реter Konow]

Para uma melhor compreensão dos loops:

Um laço permite que você passe uma seção de código fechada em seu corpo uma e outra vez. Os resultados de cada passe serão diferentes dos resultados de outros passes, pois os valores das variáveis/funções chamadas podem ser diferentes a cada passe. O número de iterações de loop é definido pelo programador, o valor da variável ou função - depende do código específico.

[Aleksey Masterov]

MrBrooklin:

Alexei, você está brincando? Sim, eu gostaria de aprender o básico primeiro!

Com todo o respeito, Vladimir.

Não muito. A julgar pela dinâmica e pela sua base, teoria e prática - é o seu perfil do início ao fim. Então, por que não... Não agora, mas depois... Quando se apanha o jeito e se está em primeiro nome com o código.

[MrBrooklin]

Реter Konow:
Se seu propósito imediato é implementar uma simples parada de rastreamento, continue escrevendo o roteiro adicionando as voltas de e para.

Não tenho certeza de que o roteiro de "paciência suficiente" tenha uma extensão lógica. É provavelmente melhor passar para uma nova idéia que requer ter:

1. Uma árvore de condição if-else.

2. Funções de cálculo.

3. Ciclos.

Como teremos que trabalhar no campo do comércio algorítmico, seria mais conveniente se o roteiro estivesse relacionado com a estratégia comercial. Pense sobre isso.

Obrigado, Peter, por apoiar minha intenção de equipar a New7.mq5 script com trailing stops, especialmente agora, quando eu comecei a estudar ciclos. A propósito, eu já tentei a função Dormir no roteiro. Foi recomendado o uso desta função ao escrever o trailing stop. Por onde eu começo? Provavelmente, seria melhor descrever todo o algoritmo de parada de rastreamento em palavras primeiro, e depois continuar a escrever o código?

Atenciosamente, Vladimir.

[MrBrooklin]

Aleksey Masterov:

Não muito. A julgar pela dinâmica e sua base e teoria e prática, é o seu perfil do início ao fim. Então, por que não... não agora, mas mais tarde... Quando se apanha o jeito e se está no primeiro nome,

Obrigado, Alexey, por sua fé em mim. Tudo o que tenho que fazer é manter o bom trabalho!

Atenciosamente, Vladimir.

[Реter Konow]

MrBrooklin:

Obrigado, Peter, por apoiar meu desejo de equipar a New7.mq5 script com trailing stops, especialmente agora, quando comecei a estudar ciclos. A propósito, eu já tentei a função Dormir no roteiro. Foi recomendado o uso desta função ao escrever o trailing stop. Por onde eu começo? Provavelmente, seria melhor descrever todo o algoritmo de parada de rastreamento em palavras primeiro, e depois continuar a escrever o código?

Atenciosamente, Vladimir.

Objetivamente falando, não se pode escrever no roteiro uma simples parada de trilha. Deixe-me explicar: os trailing stops não existem sozinhos, em um "vácuo", eles estão "amarrados" a uma posição aberta, que, por sua vez, está "amarrada" a uma estratégia, e a estratégia é implementada apenas em uma EA.

O problema e a complexidade do rastreamento no roteiro está no fato de que você precisa coletar informações sobre as posições abertas e suas ordens no loop, e então selecionar a ordem requerida no símbolo requerido e calcular sua modificação. É complicado e confuso, mas para uma EA, tudo é muito mais fácil. Primeiro, você já saberá qual ordem modificar, e segundo, você saberá quando modificar, porque o evento OnTick vem.

Então, você coloca uma "ordem pendente" no roteiro, então ele aciona, uma posição é aberta e você pode rastrear a parada... O que você precisa para isso:

1. Para loopar o roteiro.

2. Escreva a função de fixação do evento de mudança de preço no símbolo do texto.

3. Função de escrita de modificação de ordem de parada.

4. Escreva a condição de descarga do roteiro (saída do ciclo loopless) no fechamento da posição.

Eu esbocei o esboço do roteiro aproximadamente, mas precisarei pensar mais seriamente sobre isso.

P.S. A função Dormir é usada para atrasar a execução do código quando é necessário. Por exemplo, ao fazer uma solicitação ao servidor ou à espera de um evento. Em um roteiro de rastreamento, esta função será definitivamente necessária.

[Vladimir Simakov]

Реter Konow:
Os programadores têm medo de usar variáveis globais devido a erros que ocorrem ao alterar seus valores. Cria uma situação em que um erro é difícil de localizar, pois cada função pode alterá-los. Naturalmente, somente essas variáveis devem existir no escopo global que todas as funções do programa devem ver. Não pode ser de outra forma.

Sempre gostei de usar variáveis globais porque elas proporcionavam um rápido crescimento de funcionalidade, e o programa se transformou em um enorme e ativo canteiro de obras. Muitas vezes fui criticado pela maneira como escrevo o código, mas é por isso que é um canteiro de obras: é limpo depois que o trabalho básico de construção é feito, e quando a casa é construída, você pode começar a azulejar, pintar e limpar. Até lá, a prioridade é montar a cofragem e despejar concreto).

No entanto, os programadores pensam de maneira diferente. Eles vão "limpar" e "esfregar" seu código, mesmo que sejam duas linhas e meia. Esfregarão seu código mesmo que tenha duas linhas e meia de comprimento, mas brilhará como... como uma nova moeda). Esta atitude em relação ao código é justificada pela profissão pela qual eles vivem, mas do ponto de vista criativo, eles são rígidos e pouco desenvolvidos. É assim que é...

Meu conselho: aprenda a escrever corretamente, mas às vezes deixe-se afastar das regras e experimente para ganhar uma experiência mais variada. Ele o ajudará a aprender e você aprenderá mais rápido.

Há uma observação de que uma vez que você começa a se mutilar, é difícil parar, e como conseqüência, o código do projeto se transforma no que eles chamam de dre... código.

Deixe-me explicar:

1. Você tem um projeto com uma solução de trabalho intermediário e o número de características implementadas conta=0.
2. Nossa tarefa é implementar o recurso ++conta.
3. Para acrescentar as características de que necessitamos:
• para escrever métodos de árvore de objetos e conectar todas essas coisas aos manipuladores de eventos com lógica (tempo estimado 3 horas *contagem; contagem=0).
• escrever uma muleta na forma de variável global e usá-la em vários métodos, onde precisamos dela (tempo estimado de 15 min *conta.)
4. Bug de numeração automática (este é um relatório de bug para meta-cotações).
5. Naturalmente, escolhemos uma muleta (é realmente difícil nos fazer trabalhar neste caso)
6. se (nós o fizemos) for para 2
7. senão tudo vai para o inferno, gritando help-mi e lendo comentários hilariantes de que é errado fazer isso.

Espero que tenha prestado atenção ao fato de que o contador de recursos implementados aumenta o tempo de implementação do próximo recurso, mas quando implementado corretamente, ele volta a zero?

Esta é uma idéia muito exagerada, mas é assim que ela funciona na vida real.

O que quero dizer é que se você não reescrever o projeto depois de implementar todas as características, ele entrará em produção como um spoiler ilegível. E então, o ciclo de vida de qualquer projeto leva a uma dor de cabeça para a gerência: ou colocar toda a equipe em uma refatoração global de todas aquelas coisas que foram fiadas (e os concorrentes não dormem, eles, caras malvados, escrevem novas características), ou continuar escrevendo muletas e remendos de bugs, vazando em torrentes.

[MrBrooklin]

Реter Konow:
Objetivamente falando, uma simples parada de rastreamento não funcionará no roteiro. Deixe-me explicar: os trailing stops não existem por si mesmos, em um "vácuo", eles estão "presos" a uma posição aberta, que por sua vez está "ligada" à estratégia, e a estratégia é implementada somente em um Expert Advisor.

O problema e a complexidade de implementar o trailing no roteiro é que você precisa coletar informações sobre posições em aberto e suas ordens no loop, e então selecionar a ordem correta no símbolo certo e calcular como modificá-la. É complicado e confuso, mas para uma EA, tudo é muito mais fácil. Primeiro, você já saberá qual ordem modificar, e segundo, você saberá quando modificar, porque o evento OnTick vem.

Então, você coloca uma "ordem pendente" no roteiro, então ela aciona, uma posição é aberta e você pode rastrear a parada... O que você precisa para isso:

1. Para loopar o roteiro.

2. A função de fixação do evento de mudança de preço no símbolo.

3. Função de escrita de modificação de ordem de parada.

4. Escreva a condição de descarga do roteiro (saída do laço) no fechamento da posição.

Eu esbocei o esboço do roteiro aproximadamente, mas precisarei pensar mais seriamente sobre isso.

P.S. A função Dormir é usada para atrasar a execução do código quando é necessário. Por exemplo, ao fazer uma solicitação ao servidor ou à espera de um evento. Em um roteiro de rastreamento, esta função será definitivamente necessária.

Peter, nós criamos código de rastreamento no roteiro? Perfeito! Agora eu pego o que você listou como seções básicas e começo a descrevê-las em palavras, assim fica claro como eu devo escrever funções, loops, etc. mais tarde. Isto é correto?

Cumprimentos, Vladimir.

[Реter Konow]

MrBrooklin:

Peter, então criamos o código de rastreamento no roteiro? Ótimo! O que você listou agora eu tomo como seções básicas e começo a descrevê-las em palavras, para que fique claro como escrever funções, loops, etc. mais tarde. Isto é correto?

Cumprimentos, Vladimir.

Sim, correto.

[MrBrooklin]

Vladimir Simakov:

Há uma observação de que, uma vez que você começa a ranger, é difícil parar, e como conseqüência, o código do projeto se transforma no que é conhecido como d.c.

Deixe-me explicar:

1. Você tem um projeto com uma solução de trabalho intermediário e o número de características implementadas conta=0.
2. Nossa tarefa é implementar o recurso ++conta.
3. Para acrescentar as características de que necessitamos:
• para escrever métodos de árvore de objetos e conectar todas essas coisas aos manipuladores de eventos com lógica (tempo estimado 3 horas *contagem; contagem=0).
• escrever uma muleta na forma de variável global e usá-la em vários métodos, onde precisamos dela (tempo estimado de 15 min *conta.)
4. Bug de numeração automática (este é um relatório de bug para meta-cotações).
5. Naturalmente, escolhemos uma muleta (é realmente difícil nos fazer trabalhar neste caso)
6. se (nós o fizemos) for para 2
7. senão tudo vai para o inferno, gritando help-mi e lendo comentários hilariantes de que é errado fazer isso.

Espero que tenha prestado atenção ao fato de que o contador de recursos implementados aumenta o tempo de implementação do próximo recurso, mas quando implementado corretamente, ele volta a zero?

Esta é uma idéia muito exagerada, mas é assim que ela funciona na vida real.

O que quero dizer é que se você não reescrever o projeto depois de implementar todas as características, ele entrará em produção como um spoiler ilegível. E então, o ciclo de vida de qualquer projeto leva a uma dor de cabeça para a gerência: ou colocar toda a equipe em uma refatoração global de todas aquelas coisas que eles giraram (e os concorrentes estão acordados, eles, caras maus, estão escrevendo novas características), ou continuar escrevendo muletas e remendos de bugs, vazando em torrentes.

Embora esta mensagem seja dirigida principalmente a Peter, peço que a escrevam sem qualquer gíria, a fim de compreender plenamente suas mensagens, em uma linguagem acessível ao aluno do 1º ano da escola de programação, pois o tema é para iniciantes a partir do zero.

Cumprimentos, Vladimir.