Aprendizado de máquina no trading: teoria, prática, negociação e não só - página 197
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
apenas a pensar - você só toma os valores dos preços e indicadores diferentes dos preços como preditores aqui? e alguém usa volumes reais e indicadores de volumes?
Eu trabalho com preços, sem volume.
Eu tentei usar volumes e seus indicadores, mas não funcionou. Não há volumes reais em forex, mas há carrapatos, que parecem corresponder um pouco aos reais, ou seja, em princípio, você pode experimentá-los. Mas o problema é que o histórico de barras e carrapatos do corretor contém alguns volumes de carrapatos"não tão". Enquanto o símbolo está na praça do mercado no terminal em funcionamento - há um histórico correto de volumes de tick para ele. Se o símbolo for removido do wotch ou se o terminal for fechado - os volumes de tick para estas barras serão tomados como dado pelo corretor. E estes dois valores, "digitado pelo terminal" e "recebido do corretor", são completamente diferentes, às vezes dez vezes. Agora eu preciso manter o terminal funcionando por alguns meses para obter os volumes reais do tick, não o que o corretor me dá, então eu posso tentar usá-los novamente.
Eu trabalho com preços, sem volume.
Eu tentei usar volumes e seus indicadores, mas não funcionou. Não há volumes reais em forex, mas há carrapatos, que parecem corresponder um pouco aos reais, ou seja, em princípio, você pode experimentá-los. Mas o problema é que o histórico de barras e carrapatos do corretor contém alguns volumes de carrapatos"não tão". Desde que o símbolo esteja na praça do mercado no terminal em funcionamento - para ele é coletado o histórico correto dos volumes de tick. Se o símbolo for removido do wotch ou se o terminal for fechado - os volumes de tick para estas barras serão tomados como dados pelo corretor. E estes dois valores, "digitado pelo terminal" e "recebido do corretor", são completamente diferentes, às vezes dez vezes. Agora preciso manter o terminal funcionando por alguns meses para obter volumes reais de tick e não de broker e depois posso tentar usá-los mais uma vez.
Para informações sobre a linguagem R e o novo MetaTrader 5 build 1467:
Distribuições estatísticas em MQL5 - tire o melhor de R e torne-o mais rápido
Muitas novas funções matemáticas e estatísticas semelhantes a R serão adicionadas nas próximas versões. Isto permitirá mais cálculos e visualização directamente no MetaTrader 5.Você pode atualizar para 1467 a partir do servidor MetaQuotes-Demo.
Caro Renat!
Deixe-me responder ao comentário sobre o ponto 6. Os erros de cálculo detectados em R no link citado:Distribuições estatísticas em MQL5 - tirar o melhor de R e torná-lo mais rápido
A verificação foi feita para a função Gama. Deixaremos a verificação para o resto das funções à sua própria responsabilidade.
Em nome do departamento de Data Science, representado pelo gerente e dois estatísticos (posso informá-lo sobre PM) informamos que a densidade de distribuição gama no ponto zero não é reduzida a zero, estritamente falando.
R de facto estima que a densidade no ponto zero seja 1:
x <- seq(0, 20, 0.5) #support
plot(k, dgamma(x = x, shape = 1, scale = 1, log = FALSE)) #PDF plot
print(dgamma(x = 0.000001, shape = 1, scale = 1, log = FALSE)) #limiting to zero
No entanto, podemos ver que quando x tende para zero, a densidade aproxima-se da unidade.
Além disso, de acordo com:
https://en.wikipedia.org/wiki/Gamma_distribution
em x = 0, alfa = 1, beta = 1, o numerador dá um valor indeterminado, o que traz toda a fração para a incerteza.
Afirmamos que, estritamente falando, a densidade gama da distribuição no ponto zero é indefinida. E tomando o limite à direita, a densidade é uma só.
À luz disto, acreditamos que a formulação da declaração "erros de cálculo em R" não é correcta. Mais precisamente, é uma questão de convenção: o que deve ser considerado igual à expressão zero ao poder do zero. Equalizar a densidade da distribuição gama a zero no ponto zero não parece ser nenhuma prática condicional.
Sv.
Alexey
Declarar que, estritamente falando, a densidade da distribuição gama no ponto zero é indefinida. E quando o limite da direita é tomado, a densidade é igual a um.
luz disto, pensamos que a formulação da declaração "erros de cálculo em R" não é correcta. Mais precisamente, é uma questão de convenção: do que igualar a expressão zero ao poder do zero. Equalizar a densidade da distribuição gama a zero no ponto zero não parece ser nenhuma prática condicional.
Se a densidade (pdf) for diferente de zero, então a integral (cdf) nesse ponto também deve ser diferente de zero, caso contrário não é possível zero.
Mas cdf=0. É difícil de explicar.
Em x=0 o pdf é zero por definição:
Wolfram Alpha:
Para distribuições não centrais e centrais do qui-quadrado:
Se a densidade (pdf) for diferente de zero, então a integral (cdf) nesse ponto também deve ser diferente de zero, caso contrário não há zero.
Mas cdf=0. Isto é difícil de explicar.
Em x=0 pdf é zero por definição:
Wolfram Alpha:
Para distribuições não centrais e centrais do qui-quadrado:
É melhor dizer-nos por si mesmo o que é 0 ^ alfa - 1, quando alfa = 1.
O integral também não está lá definido.... Mas no limite, está perto de zero. Questão de convenções...
print(pgamma(q = 0.000001, shape = 1, scale = 1, log = FALSE, lower.tail = F)) #right side
print(pgamma(q = 0.000001, shape = 1, scale = 1, log = FALSE, lower.tail = T)) #left side
e alguém usa volumes reais e indicadores de volume?
para que o limite seja definido, é preciso que seja o mesmo para as abordagens esquerda e direita, mas não é o caso:
http://www.wolframalpha.com/input/?i=Limit%5BPDF%5BGammaDistribution%5B1,1%5D,x%5D,+x-%3E0%5D
para que o limite seja definido, é preciso que seja o mesmo para as abordagens esquerda e direita, mas não é o caso:
http://www.wolframalpha.com/input/?i=Limit%5BPDF%5BGammaDistribution%5B1,1%5D,x%5D,+x-%3E0%5D
Há apenas um à direita e esse é 1...
O que a Wolfram diz 0 não é a verdade em último recurso. Quero dizer que a palavra "erro" no texto é redundante...
Encontrei outro erro no R. R não se divide por 0 corretamente.
Aqui está o roteiro:
//| test.mq5 |
//| Copyright 2016, MetaQuotes Software Corp. |
//| https://www.mql5.com |
//+------------------------------------------------------------------+
#property copyright "Copyright 2016, MetaQuotes Software Corp."
#property link "https://www.mql5.com"
#property version "1.00"
#property script_show_inputs
input double div = 0.0;
//+------------------------------------------------------------------+
//| Script program start function |
//+------------------------------------------------------------------+
void OnStart()
{
//---
Print(1.0/div);
}
//+------------------------------------------------------------------+
A resposta correcta, em mql é.
divisão zero em 'test.mq5' (20,13)
com parada de script
Incorrecto, em R:
> 1/0
Inf
com continuação do roteiro
Quero dizer a mesma coisa que Alexey - o comportamento de programas sob condições indefinidas pode ser diferente, e não é um erro. Do jeito que a arquitetura deve ser, é assim que o resultado será.
Outra observação interessante. Não se pode dividir por zero. E não se pode tirar a raiz dos números negativos. Lembro-me da união que tudo isto é possível, mas não se trata disso agora, em matemática simples não se pode fazer as duas coisas.
Por que se eu dividir por 0 em mql então ele quebra todo o script e o quebra, mas se eu extrair uma raiz de um número negativo então eu recebo "-nan(ind)" sem quebrar o script, e este "-nan(ind)" pode ser usado para fazer cálculos adicionais (ele irá quebrar todos os cálculos adicionais)? Aqui é onde eu esperaria o mesmo comportamento do script mql em ambos os casos.