Aprendizado de máquina no trading: teoria, prática, negociação e não só - página 3151

 
mytarmailS #:

o tamanho da janela de histórico é apenas uma grande limitação para MOs clássicos com dados tabulares

As regras AS (asoc. rules) não sofrem desse mal, elas digerem perfeitamente dados não estruturados e, além disso, cada observação pode ter um tamanho arbitrário.

E a própria "janela de visão" (janela de histórico) pode ser limitada apenas pela capacidade de computação.


Portanto, seu exemplo com o tamanho da janela do histórico é apenas um voto a favor do AC e contra o MO.


Dê-me mais argumentos, estou curioso para saber se realmente estou perdendo alguma coisa.

E outra pergunta: o quanto você está interessado no AU?

Eu não me aprofundei nas regras. Já escrevi que cheguei à aplicação de gramáticas formais pelo outro lado - observei o preço como construído pela gramática estocástica. Desisti dessa abordagem justamente por causa de sua complexidade, o que é ruim, em primeiro lugar, porque provoca treinamento excessivo.

Agora evito modelos pesados. A principal regra informal para mim é que o peso do modelo deve corresponder ao peso das informações na amostra.

Seu modelo é pesado o suficiente para um modelo de preço completo, mas a amostra real de preços que temos (mesmo se adicionarmos outras informações) não é suficiente para tal modelo.

Naturalmente, IMHO

 
mytarmailS #:

Então, como o AMO encontra um padrão a partir do exemplo?

Descrevi tudo de forma muito modesta para fins de clareza; na realidade, é mais parecido com isso.



E seu modelo vê apenas isso: (as últimas 5 velas não horárias).

Observe também que não há vínculo com o índice; se um evento importante ocorreu ontem há 200 candles, hoje o mesmo evento pode ocorrer há 1555 candles ou 12, por exemplo....

O AC encontrará esse padrão, mas o AMO não!

O AMO precisa que cada recurso tenha sempre a mesma coluna na tabela, para que seja sempre acionado com o mesmo índice.


ou assim, o que também é bastante visual.

[[1]]
[1] ".....A...............................................................B........C..............SELL"

[[2]]
[1] ".......A........B...........C...........SELL"

[[3]]
[1] "........................................A........B.........................C.............SELL"

[[4]]
[1] "..A.............................................................B..............C...SELL"

[[5]]
[1] ".......A..........................................B...C...SELL"

E o modelador vê isso.

[[1]]
[1] ".....A...............................................................B........C.............. SELL"

[[2]]
[1] ".......A........B...........C........... SELL"

[[3]]
[1] "........................................A........B.........................C............. SELL"

[[4]]
[1] "..A.............................................................B..............C... SELL"

[[5]]
[1] ".......A..........................................B...C... SELL"


De qualquer forma, espero ter esclarecido meu ponto de vista.

 
Aleksey Nikolayev #:

A propósito, como está indo o estudo sobre python?

 
mytarmailS #:

A propósito, como está indo o estudo sobre python?

É uma boa linguagem, mas, a partir de certo nível, torna-se muito complicada para quem não é programador. Por exemplo, é muito mais difícil escrever extensões em C do que em R. Gostei muito das tabelas em numpy.

 
Aleksey Nikolayev #:

Não me aprofundei nas regras. Já escrevi que cheguei à aplicação de gramáticas formais pelo outro lado - observei o preço como construído pela gramática estocástica. Desisti dessa abordagem justamente por causa de sua complexidade, o que é ruim, em primeiro lugar, porque provoca excesso de treinamento.

Agora evito modelos pesados. A principal regra informal para mim é que o peso do modelo deve corresponder ao peso das informações na amostra.

Seu modelo é pesado o suficiente para ser um modelo de preço completo, mas a amostra real de preços que temos (mesmo se adicionarmos outras informações) não é suficiente para tal modelo.

Naturalmente, IMHO

100%

 
mytarmailS #:

Observe também que não há nenhum vínculo com o índice; se um evento importante ocorreu ontem há 200 candles, hoje o mesmo evento pode já ter ocorrido há 1555 candles ou 12, por exemplo....

O AC encontrará esse padrão, mas o AMO não!

O AMO precisa que cada recurso tenha sempre a mesma coluna na tabela, para que seja sempre acionado com o mesmo índice.


ou assim, o que também é bastante visual.

Curioso, fazendo exatamente o que descrevi há cerca de meio ano.

Não entendo como suas regras pesquisam o valor de um recurso verticalmente sem referência ao índice - no meu conceito, deve haver um intervalo de pesquisa aceitável - não entendo sua implementação.

 
Aleksey Vyazmikin #:

Curioso, fazendo exatamente o que descrevi há cerca de meio ano.

Não entendo como suas regras pesquisam o valor de um recurso verticalmente sem referência ao índice - em meu conceito, deve haver um intervalo de pesquisa aceitável - não entendo sua implementação.

Por algoritmos usuais de regras associativas, diferentes dependendo da tarefa.

Eu lhe dei uma solução (código) para o seu problema na época (há meio ano), você se esqueceu?
 
Aleksey Nikolayev #:

É uma boa linguagem, mas, a partir de certo nível, torna-se muito complicada para quem não é programador. Por exemplo, é muito mais difícil escrever extensões em C do que em R. Gostei muito das tabelas em numpy.

santa pergunta)

para pesquisa de mercado - R ou python?

 
mytarmailS #:

pergunta holivar)

para pesquisa de mercado - R ou Python?

Para pesquisa de mercado por mim, no momento - R. Não estou pronto para responder por outros ou por mim mesmo no futuro).

 
mytarmailS #:
Os algoritmos usuais de regras associativas, diferentes dependendo do problema.

Eu lhe dei uma solução (código) para o seu problema naquela época (meio ano atrás), você se esqueceu?

Nem sei de que código estamos falando - aparentemente algo falhou na execução. De que código estamos falando?

Você afirma que a profundidade não é um evento importante no tempo - e como ela é escrita pela regra - eu não entendi.