Gostei do artigo, especialmente sobre a prática moderna de desenvolvimento e documentação de programas. É assim que as coisas são.
É claro que o artigo deveria ter mostrado pelo menos o Expert Advisor mais simples baseado no método de autômatos. Ou isso está planejado para o próximo artigo?
E um grande problema do método de autômatos, na minha opinião. Para os Expert Advisors reais, é impossível definir o estado sem ambiguidade. O estado do Expert Advisor é determinado por algumas variáveis internas no computador do usuário e pelo estado das posições (taxa atual, patrimônio líquido, execução de ordens) no servidor. O estado interno é determinado de forma inequívoca, mas o estado das posições no servidor pode não ser conhecido, ser conhecido com atraso, estar em um estado pouco claro (algumas ordens e solicitações são executadas e outras não, e não se sabe por quê).
E como o estado atual do consultor não é conhecido, as ordens e solicitações não são executadas, é impossível criar uma lógica clara de autômatos. Na realidade, temos este algoritmo:
comp: Compre-me algumas centenas de euros, servidor.
servidor: Vai se foder, comp, seus stops na solicitação estão errados.
comp: Por que estão errados?
servidor: então o preço subiu.
comp: well, then buy without stops.
servidor fica em silêncio
comp: bem, o que você comprou?
servidor está em silêncio
comp: well, fuck you. Vamos tirar um cochilo por oito minutos.
Comp em oito minutos: como está indo?
Servidor: Comprei eurobucks, mas durante a compra o preço foi para outro lugar.
comp: Que se dane. Vamos tirar mais uma hora de cochilo.
E um grande problema do método de autômatos, na minha opinião. Para os Expert Advisors reais, é impossível definir o estado de forma inequívoca. O estado do Expert Advisor é determinado por algumas variáveis internas no computador do usuário e pelo estado das posições (taxa atual, patrimônio líquido, execução de ordens) no servidor. O estado interno é determinado de forma inequívoca, mas o estado das posições no servidor pode não ser conhecido, ser conhecido com atraso ou estar em um estado pouco claro (algumas ordens e solicitações são executadas, outras não, e não se sabe por quê).
Bem, como o estado atual do EA não é conhecido, as ordens e solicitações não são executadas, é impossível criar uma lógica clara de autômatos.
...
Isso é algo novo. Apenas QUALQUER (sem exceção) TS é construído com base na análise e na compreensão clara dos estados do TS. Os estados mais simples: processamento de sinais para abertura/fechamento/modificação de uma ordem, etc. etc.
Se "o estado atual do EA não for claramente conhecido", então ele definitivamente não é um EA, e definitivamente não é um programa, e a palavra "algoritmo" em relação a um EA deve ser riscada e esquecida para sempre.
Muito bem, proponho transformar a discussão em uma direção prática. Vamos analisar um algoritmo concreto baseado na teoria dos autômatos finitos. Vamos discutir seus pontos fortes e fracos. Eu mesmo não escrevo por esse método, mas estou um pouco familiarizado com a questão e os algoritmos, portanto, agora vou esboçar o princípio geral desse controle:
//СХЕМА + ПСВЕДОКОД
enum eTradeState {NoTradeRegim, BuyRegim, SellRegim, WaitRegim};
eTradeState TradeState = eTradeState.NoTradeRegim;
int Trade()
{
switch (TradeState)
{
case eTradeState.NoTradeRegim:
NoTradeRegim();
break;
case eTradeState.WaitRegim:
WaitRegim();
break;
case eTradeState.SellRegim:
SellRegim();
break;
case eTradeState.BuyRegim:
BuyRegim();
break;
}
}
//Aqui descrevemos as condições sob as quais o Expert Advisor começará a negociar. Por exemplovoid NoTradeRgim()
{
// Mais pseudocódigo a seguir. if(CurrentDay == WorksDays && Market.Enable = true)
TradeState = eTradeState.WaitRegim;
}
//Aqui capturamos sinais para entrar em uma posição longa ou curta.void WaitRegim()
{
if(CheckForNoTrade() == true)
{
TradeState = eTradeState.NoTradeRegim;
}
if(CheckForBuy() == true)
{
BuyAtStop(...)
TradeState = eTradeState.BuyRegim;
}
if(CheckForSell() == true)
{
SellAtStop(...);
TradeState = eTradeState.SellRegim;
}
}
//Nessa função, acompanhamos um negócio longovoid BuyRegim()
{
//Escreva aqui as condições sob as quais a transação é fechada, ou seu stop loss ou outros parâmetros são alterados, etc.if(StopLossChanged() == true)
NewStop = ...;
if(profit >= takeprofit)
{
CloseDeal(...);
TradeState = eTradeState.WaitRegim;
}
}
//Nessa função, acompanhamos uma negociação a descobertovoid SellRegim()
{
//Escreva aqui as condições sob as quais a transação é fechada, ou seu stop loss é movido, etc.if(StopLossChanged() == true)
NewStop = ...;
if(profit >= takeprofit)
{
CloseDeal(...);
TradeState = eTradeState.WaitRegim;
}
}
Descrito de forma esquemática, mas acho que a ideia básica está clara. A cada momento, o Expert Advisor tem apenas um estado (modo de não mercado, modo de espera de sinal, modo de compra, modo de venda). Em cada estado, há um determinado conjunto de ações e condições sob as quais ocorrerá a transição do estado atual para outro. A ideia é que controlamos claramente cada um dos estados e, portanto, a lógica interna é estritamente localizada e erros lógicos como o fechamento de uma transação inexistente ou já fechada simplesmente não podem ocorrer.
Eu mesmo não escrevo com essa técnica, pois acho que ela não é adequada para todos os algoritmos. Mas, ainda assim, ela resolve algumas tarefas melhor do que a abordagem clássica.
Eu mesmo não escrevo com essa técnica, pois acho que ela não é adequada para todos os algoritmos. Mas, ainda assim, ela resolve alguns problemas melhor do que a abordagem clássica.
O que os especialistas pensam sobre isso?
E posso perguntar o que você quer dizer com a frase "abordagem clássica"?
Porque todo mundo tem seu próprio reflexo da realidade.
Posso perguntar o que você quer dizer com "abordagem clássica"?
Porque todo mundo tem seu próprio reflexo da realidade.
Devo ter me expressado mal. É claro que cada um escreve à sua maneira. Eu me referia à maioria das abordagens quando o estado do sistema em cada etapa não está claramente definido. Ele precisa ser determinado não apenas durante a execução do Expert Advisor. O exemplo mais simples é o código escrito em um bloco OnTick(). Nenhum modo é analisado. A escolha de uma solução é feita com base na ramificação do bloco if(...).
C-4: Eu estava me referindo à maioria das abordagens quando o estado do sistema em cada etapa não está claramente definido. Ele precisa ser determinado no momento da execução do EA.
Se o estado "não está claramente definido", como você pode definir o que "não está claramente definido"? No caso de trabalhar com ordens/posições, não é necessário que o EA entenda a cada tick em que estado se encontra? Ou o EA está em um "estado indefinido" a cada tick. Que tipo de EA é esse que não sabe o que fazer em cada tick?
O artigo não aborda o assunto de forma alguma, exceto o fato de que existe uma chave. Não importa se ela existe ou não, ela pode ser trocada por if's.
Certa vez, eu estava escrevendo um EA e havia um sistema muito complexo com ordens. Tive de analisá-lo seriamente e fazer uma lista de estados: sem ordens, uma pendente, uma ordem de mercado, duas ordens pendentes, uma pendente e uma de mercado etc. Só assim consegui superar o problema. Mas acabou se revelando uma coisa universal e rapidamente reprogramável. Um ótimo tópico para um artigo.
"3. Eu estava curioso e queria ouvir o ruído branco de carrapatos reais, e consegui fazer isso usando o software WaveLab 6.0."
Hee. Parece que não sou o único maluco assim))))) Aqui está o que eu consegui. Fiz isso por meio do Adobe Audience.
Como você normalizou o preço?
Um carro cheio de emoções
1) Um monte de bukaf nada...
2) Olhando para isso, você começa a perceber por que os americanos estão em Marte agora e não nós.
3) Prefiro manter silêncio sobre o resto (apenas por causa das emoções).
Gostei do artigo, especialmente sobre a prática moderna de desenvolvimento e documentação de programas. É assim que as coisas são.
É claro que o artigo deveria ter mostrado pelo menos o Expert Advisor mais simples baseado no método de autômatos. Ou isso está planejado para o próximo artigo?
E um grande problema do método de autômatos, na minha opinião. Para os Expert Advisors reais, é impossível definir o estado sem ambiguidade. O estado do Expert Advisor é determinado por algumas variáveis internas no computador do usuário e pelo estado das posições (taxa atual, patrimônio líquido, execução de ordens) no servidor. O estado interno é determinado de forma inequívoca, mas o estado das posições no servidor pode não ser conhecido, ser conhecido com atraso, estar em um estado pouco claro (algumas ordens e solicitações são executadas e outras não, e não se sabe por quê).
E como o estado atual do consultor não é conhecido, as ordens e solicitações não são executadas, é impossível criar uma lógica clara de autômatos. Na realidade, temos este algoritmo:
comp: Compre-me algumas centenas de euros, servidor.
servidor: Vai se foder, comp, seus stops na solicitação estão errados.
comp: Por que estão errados?
servidor: então o preço subiu.
comp: well, then buy without stops.
servidor fica em silêncio
comp: bem, o que você comprou?
servidor está em silêncio
comp: well, fuck you. Vamos tirar um cochilo por oito minutos.
Comp em oito minutos: como está indo?
Servidor: Comprei eurobucks, mas durante a compra o preço foi para outro lugar.
comp: Que se dane. Vamos tirar mais uma hora de cochilo.
E assim por diante.
...
E um grande problema do método de autômatos, na minha opinião. Para os Expert Advisors reais, é impossível definir o estado de forma inequívoca. O estado do Expert Advisor é determinado por algumas variáveis internas no computador do usuário e pelo estado das posições (taxa atual, patrimônio líquido, execução de ordens) no servidor. O estado interno é determinado de forma inequívoca, mas o estado das posições no servidor pode não ser conhecido, ser conhecido com atraso ou estar em um estado pouco claro (algumas ordens e solicitações são executadas, outras não, e não se sabe por quê).
Bem, como o estado atual do EA não é conhecido, as ordens e solicitações não são executadas, é impossível criar uma lógica clara de autômatos.
...
Isso é algo novo. Apenas QUALQUER (sem exceção) TS é construído com base na análise e na compreensão clara dos estados do TS. Os estados mais simples: processamento de sinais para abertura/fechamento/modificação de uma ordem, etc. etc.
Se "o estado atual do EA não for claramente conhecido", então ele definitivamente não é um EA, e definitivamente não é um programa, e a palavra "algoritmo" em relação a um EA deve ser riscada e esquecida para sempre.
Muita emoção.
Muito bem, proponho transformar a discussão em uma direção prática. Vamos analisar um algoritmo concreto baseado na teoria dos autômatos finitos. Vamos discutir seus pontos fortes e fracos. Eu mesmo não escrevo por esse método, mas estou um pouco familiarizado com a questão e os algoritmos, portanto, agora vou esboçar o princípio geral desse controle:
Descrito de forma esquemática, mas acho que a ideia básica está clara. A cada momento, o Expert Advisor tem apenas um estado (modo de não mercado, modo de espera de sinal, modo de compra, modo de venda). Em cada estado, há um determinado conjunto de ações e condições sob as quais ocorrerá a transição do estado atual para outro. A ideia é que controlamos claramente cada um dos estados e, portanto, a lógica interna é estritamente localizada e erros lógicos como o fechamento de uma transação inexistente ou já fechada simplesmente não podem ocorrer.
Eu mesmo não escrevo com essa técnica, pois acho que ela não é adequada para todos os algoritmos. Mas, ainda assim, ela resolve algumas tarefas melhor do que a abordagem clássica.
O que os especialistas pensam sobre isso?
...
Eu mesmo não escrevo com essa técnica, pois acho que ela não é adequada para todos os algoritmos. Mas, ainda assim, ela resolve alguns problemas melhor do que a abordagem clássica.
O que os especialistas pensam sobre isso?
E posso perguntar o que você quer dizer com a frase "abordagem clássica"?
Porque todo mundo tem seu próprio reflexo da realidade.
Posso perguntar o que você quer dizer com "abordagem clássica"?
Porque todo mundo tem seu próprio reflexo da realidade.
Eu estava me referindo à maioria das abordagens quando o estado do sistema em cada etapa não está claramente definido. Ele precisa ser determinado no momento da execução do EA.
Se o estado "não está claramente definido", como você pode definir o que "não está claramente definido"? No caso de trabalhar com ordens/posições, não é necessário que o EA entenda a cada tick em que estado se encontra? Ou o EA está em um "estado indefinido" a cada tick. Que tipo de EA é esse que não sabe o que fazer em cada tick?
O artigo não aborda o assunto de forma alguma, exceto o fato de que existe uma chave. Não importa se ela existe ou não, ela pode ser trocada por if's.
Certa vez, eu estava escrevendo um EA e havia um sistema muito complexo com ordens. Tive de analisá-lo seriamente e fazer uma lista de estados: sem ordens, uma pendente, uma ordem de mercado, duas ordens pendentes, uma pendente e uma de mercado etc. Só assim consegui superar o problema. Mas acabou se revelando uma coisa universal e rapidamente reprogramável. Um ótimo tópico para um artigo.