Regras de estrutura. Aprender a estruturar programas, explorar possibilidades, erros, soluções, etc. - página 14

Novo comentário
 
C-4:
Neste caso, teremos de armazenar o histórico dos sinais, o que é muito caro. Vejamos novamente o cruzamento de 2 médias. Suponhamos que reiniciamos a EA. Não há uma nova cruz para a entrada e a EA precisará, de alguma forma, de restaurar a sua história comercial e compreender que houve uma cruz e que deve agora estar no estado de Comprar e que este sinal foi processado e que não devemos abrir uma nova posição, mas precisaremos de encontrar a posição antiga, mas não será fácil de encontrar, porque a posição actual pode não pertencer necessariamente a apenas uma EA ... No fim de contas, é um pesadelo. Este é o caminho espinhoso sugerido por hrenfx: escrever um testador de história em cada robô, que recolheria sinais históricos, calcularia se funcionavam ou não, e depois armazenaria volumes de estratégias, etc. Como resultado, a complexidade do desenvolvimento aumenta por uma ordem de grandeza, enquanto ainda não existe uma solução fiável.

O histórico dos sinais é um indicador, os indicadores são concebidos para este fim, para fazer cálculos, gerar sinais e carregá-los para o Expert Advisor.

E não diga que os indicadores estão a ser redesenhados, escreva indicadores que não estão a ser redesenhados e ficará satisfeito.

Ninguém nos pode desencaminhar, não nos interessa para onde vamos :)

 
C-4:

Como é que isso não importa!? Qualquer estratégia, ao seu nível lógico, conhece sempre o seu estado actual!

Aqui está o problema básico. Estou familiarizado com isto, já passei por todos os cantos e fendas aqui. E está errado.

A estratégia não precisa de conhecer a sua história. A estratégia deve olhar para a frente e não para trás. O que aconteceu já está no passado e não há volta a dar.

Tomemos uma estratégia simples de cruzamento: tem apenas dois estados, ou é comprar ou vender. Sem memorizar a sua posição, abrirá uma posição longa sempre que vir que a média rápida está acima da média lenta. Então, o que deve fazer o sincronizador? Diz-lhe: "Não, já tens uma posição longa, não te darei outra".

:)

Bem, já escrevi, está a resolver um problema inexistente. O problema parece real apenas com o pensamento de "ordem". Com o pensamento de rede, não existe.

Não estou a falar do seu ou do meu pensamento, estou a falar do pensamento do programa (estratégia).

Num sistema baseado em encomendas, a estratégia é um produtor de sinais discretos de compra/venda/fecho. Num sistema baseado em redes, a estratégia produz um número (duplo) - a posição de mercado recomendada.

Vamos usar o exemplo de dois vagões para mostrar como uma rede de malha de capotagem TC irá produzir o seu produto, digamos, ao comercializar um lote constante (pseudo-código):

 Pos = Sign(MA(ShortPeriod) - MA(LongPeriod));

É isso mesmo.

A estratégia manterá +1 na saída desde que o balanço curto seja mais alto que o longo, e -1 quando for mais baixo.

As decisões sobre que ordens colocar/fechar para manter essas posições nos momentos apropriados são tomadas pelo motorista do mercado. A estratégia não precisa de se preocupar com ela, o seu papel é mais aristocrático e não se preocupa com todas essas coisas mercantis. O motorista toma a posição recomendada do símbolo, subtrai-lhe a posição real e mostra a diferença. Se a diferença for igual a zero, não faz nada.

A minha solução é universal, a estratégia decide por si só quantas ordens e em que direcção pode manter-se aberta.

Será que a estratégia tem de se preocupar de todo com as encomendas? O impulsionador do mercado decide sobre estas questões.


Se quiser uma posição de compra e duas posições de venda, não há problema.

Será possível rir aqui? É exactamente este o problema - chama-se a isto "fechadura".

Tenho todas as fechaduras potenciais desbloqueadas ANTES que a posição agregada de várias estratégias de entrada seja submetida ao impulsionador do mercado:

  Pos=0;
  for (i=0; i<StrategyCount; i++)  Pos+= Strategy[i].GetPos();
  MarketDriver.Synhronize(Pos, Err);

A classe base tem toda a informação de que necessita para tomar decisões. Ao nível do terminal, não há posição líquida, enquanto a própria estratégia funciona no modo de multiposição confortável.

O Expert Advisor criado pelo meu modelo proposto terá automaticamente as propriedades de um multi-especialista. Não terei de acrescentar ou modificar nada. Posições de diferentes EAs sobre um símbolo não se desmoronarão em rede, é tão fácil programar uma grelha ou um cacifo neste padrão como em qualquer outra estratégia. Por outras palavras, a unificação total da implementação do programa é alcançada, independentemente da lógica do Expert Advisor!

Uh.... a minha solução é ainda mais versátil quando se considera que as fechaduras nem sequer surgem nela. Os amantes de fechaduras não vão comigo. Eu vou com eles.
 
MetaDriver:

...

A estratégia manterá +1 na saída desde que o curto seja mais alto do que o longo, e -1 quando for mais baixo.

O motor do mercado decide que ordens colocar/fechar para manter essas posições nos momentos apropriados. A estratégia não precisa de se preocupar com ela, o seu papel é mais aristocrático, não se preocupa com toda esta vaidade mercantil.

Será que a estratégia precisa mesmo de se preocupar com algum tipo de encomendas? O motor do mercado decide estes pequenos detalhes para mim.

...

Tudo isso está muito bem, claro, mas o que dizer das estratégias cuja "recomendação" actual depende de uma posição previamente aberta. Suponha que uma estratégia é activamente piramidal e tem uma tal condição (pseudo-código):

if(LastPosition.NetProfit > 400 && LastPosition.PositionType == Long)
{
   double volume = LastPosition.Volume + 1;
   BuyAtMarket(volume, "Entry long by strengthening");
}

Outro exemplo de como o sistema de recomendação trataria uma condição tão simples (pseudo-código):

if(LastPosition.NetProfit < -400)
{
    CloseAtMarket(LastPosition, "Exit position by stop-loss");
    if(LastPosition.PositionType == Long)
       ShortAtMarket(volume, "Entry long by revers")
    else
       BuyAtMarket(volume, "Entry short by revers")
}
Na realidade, pode haver muitas dessas condições.
 
MetaDriver:
Isso é o mais básico. Estou muito familiarizado com isto, já vasculhei todos os recantos aqui dentro. E está errado.

A estratégia não tem necessidade de conhecer a sua história. A estratégia deve olhar para a frente e não para trás. O que aconteceu já aconteceu no passado e não há volta a dar.

Porque gritas :) não foi isso que ele disse.


Qualquer estratégia, ao nível da sua lógica, conhece sempre o seu estado actual!

É sobre o estado actual, não sobre a história.
 
C-4:

Tudo isto está muito bem, claro, mas o que dizer das estratégias cuja "recomendação" actual depende de uma posição previamente aberta. Suponha que a estratégia é activamente piramidal e tem esta condição (pseudo-código):

Estas estratégias precisam definitivamente de ser curadas, ao nível da filosofia comercial. Nomeadamente, este buraco particular na cabeça deve ser curado: "a recomendação actual depende de uma posição previamente aberta".

A actual posição recomendada nunca deve depender de acções previamente tomadas no mercado.

 
sergeev:

Porque gritas :) não foi isso que ele disse.

diz estado actual, não história.

Não estou a comunicar com o que ele disse, estou a comunicar com o que ele quis dizer. Ele estava a referir-se ao estado anterior actual.

:)

 

:)

De facto, para o meu esquema, não existem obstáculos principais à criação de estratégias que tenham em conta o comércio passado.

Em termos mais académicos: Um sistema sem memória pode facilmente simular um sistema com memória. Para o fazer, a memória é simplesmente movida para fora do sistema - torna-se outro indicador de entrada. Isto é suficiente. A própria estratégia continua a ser um "sistema sem memória" e isto é bom e correcto.

 
MetaDriver:

A actual posição recomendada nunca deve depender de acções realizadas anteriormente no mercado.

E os robôs "emitindo as suas próprias recomendações" cujos sinais são de uma frase? O robô viu uma vela grande - um sinal de compra. O bar seguinte é um bar normal e não há sinal. Se o robô não se lembra do seu estatuto, a sua recomendação sobre esta barra já é nula, enquanto que o robô que se lembra dela não é nulo mas tem uma posição longa. Mas esses são dois robôs idênticos.

MetaDriver:

Não estou a comunicar com o que ele disse, mas com o que ele quis dizer. Ele estava a referir-se ao estado anterior actual.

Ah, então era mesmo isso que eu queria dizer! Eu saberei:)
 
C-4: ... Tudo isso está muito bem, claro, mas o que dizer das estratégias cuja "recomendação" actual depende de uma posição previamente aberta. Suponha que uma estratégia é activamente piramidal ...

A questão é que o primeiro arranque não é provavelmente uma estratégia, mas uma previsão de preços.

MetaDriver: ... A tarefa de uma estratégia é prever se o mercado irá subir ou descer no próximo momento, e com que probabilidade. A posição de mercado recomendada depende disso. O que existia no passado, quer haja ou não posições abertas (em qualquer direcção), é absolutamente sem importância.
E do que você(C-4) está a falar é do trabalho do módulo de gestão de dinheiro que toma como input(algum tipo de função) tanto as leituras preditoras como os resultados comerciais passados. Se não houver MM, então o algoritmo de negociação final, de facto, transforma uma posição de previsão virtual (que não se importa com resultados de negociação passados) numa posição real, onde a direcção futura do mercado é o sinal de posição recomendada, e a confiança/rentabilidade é proporcional ao volume da mesma posição.

O módulo MM é uma camada entre Forecaster e Driver, e os resultados podem ser qualquer coisa, desde capitalização e limite de risco (drawdown relativo em X ... horas/trades/movimento de navios) até à inversão radical da posição recomendada pelo forecaster.

 
C-4:

E os robôs "emitindo as suas próprias recomendações" cujos sinais são de uma frase? O robô viu uma vela grande - um sinal de compra. O bar seguinte é um bar normal, não há sinal. Se o robô não se lembra do seu estatuto, a sua recomendação sobre esta barra já é nula, enquanto que o robô que se lembra dela não é nulo mas tem uma posição longa. E esses são dois robôs idênticos.

Estes robôs devem definitivamente ser tratados. O tratamento pode ser muito simples. Tudo o que precisa é de motivação. Isso é o principal.

E para estarem motivados, precisam de ver e apreciar a tremenda superioridade do pensamento de rede sobre o pensamento de ordem. Enquanto estiverem doentes, não os deixarei chegar perto da população saudável - deixe-os ficar em quarentena...

:)

Ah, então era mesmo isso que eu queria dizer! É bom saber:)
Por que não? Tenho de pedir desculpa, ou achei bem? ;-))
1...7891011121314151617181920
Novo comentário