Vizard_: OK)))) mas leia atentamente as condições - "pós resultados em % (casos previstos com sucesso) para ambas as amostras (trem = xx%, teste = xx%). Não há necessidade de especificar métodos e modelos, apenas números". Estamos à espera de mais resultados. Pergunto-me que conclusões tirará Mihail Marchukajtes.
meu resultado (se você desejar, eu lhe darei o método também):
De qualquer forma, o nível máximo de generalização é de cerca de 53%, portanto..... Ocasionalmente o Lixo no Lixo Sai, ou seja, o lixo.... Não há como testá-lo, porque o Excel não suporta fórmulas longas. Não quero escrever para isso em MKUL, se o modelo fosse de qualidade normal eu o tentaria, mas com tal percentagem de generalização, acho que o resultado não será muito bom no teste...
mytarmailS: Não entendo como é calculada esta "previsibilidade" e se faz algum sentido se o alvo não for levado em conta.
Existem fórmulas para estimar o ruído do sinal, ou vice-versa. Como e o que estas fórmulas calculam, só o autor sabe, só podemos confiar que ele sabe o que está fazendo. O resultado final é bastante simples - se os próprios preditores não são "ruídos", é mais fácil prever algo com eles. E se os processar de alguma forma, pode obter um sinal ainda mais estável. Um sinal estável é uma boa base para uma previsão.
Você mesmo pode estimar rapidamente os preditores usando a função Omega() deste pacote e aplicar valores de algum preditor em particular (uma coluna da tabela de treinamento) a ele. O resultado é 0% - ruído e o preditor é inútil. 100% - tudo é bom, o prognosticador pode ser usado. Suponho que não devemos alimentar a função com os valores do indicador puro, mas com o seu incremento, por exemplo, para uma média móvel - c(MA[0]-MA[1], MA[1]-MA[2], MA[2]-MA[3], etc.).
Sobre os valores alvo - sim, eles não são usados no pacote. Este pacote não pode prever nada. Só de alguma forma determina quais os preditores em que se pode e quais não se pode confiar, e cria mais alguns novos baseados neles. A seleção da variável alvo e o treinamento do modelo preditivo devem ser tratados de forma diferente. É lógico que algumas variáveis-alvo podem ser previstas melhor e outras pior. A variável alvo é um problema para qualquer pacote. Não é certo que a variável alvo utilizada possa sequer ser prevista com os preditores disponíveis. Por exemplo, posso usar ou "subir/descer no preço na barra seguinte" ou "subir/descer em ziguezague" para a variável alvo. Eu gostaria de aprender como criar novas variáveis-alvo para que elas se ajustem melhor aos preditores disponíveis. Quem sabe, talvez eu pudesse prever perfeitamente um apartamento com os meus preditores, mas nunca saberei porque ainda não o experimentei.
Como entendo que ninguém lê os termos e condições (qualquer manipulação de dados é permitida), por isso não vou torturar. Na verdade, tudo é simples. Só preciso de tirar os atrasos do A6, aplicar uma fórmula simples sete menos de quinto e obter 100% em ambas as amostras. Obrigado a todos vocês. Boa sorte...
Vizard_: Como entendo que ninguém lê os termos e condições (qualquer manipulação de dados é permitida), por isso não vou torturar. Na verdade, tudo é simples. Só precisa de retirar os atrasos do A6, aplicar uma fórmula simples de sétimo menos de quinto e obter 100% em ambas as amostras. Obrigado a todos vocês. Boa sorte...
Então, qual é o senão? Eu também posso codificar uma variável de saída em uma pilha de lixo de entrada como essa. Nunca adivinharia. Eu ainda não sei qual é o objectivo disto.
Mihail Marchukajtes: Qual é a graça disso? Eu também posso codificar uma variável de saída em uma pilha de lixo de entrada. Não vais conseguir adivinhar. Ainda não sei qual foi o objectivo disso.
Ele chamou nossa atenção para o fato de que a quantidade de dados utilizados nem sempre é suficiente para a previsão. Por exemplo, se nos limitarmos a 9 bares, podemos perder informações importantes de bares mais distantes. E também que não podemos avaliar um preditor sem ter em conta as suas interacções com outros preditores.
Mihail Marchukajtes: Qual é a graça disso? Eu também posso codificar uma variável de saída em uma pilha de lixo de entrada. Não vais conseguir adivinhar. Ainda não percebi o objectivo disto.
Que não consegues ver o gopher, mas consegues). Vá lá, vamos tentar. Só uma simples.
Por exemplo, este arquivo. Chitso Train não precisa de fazer nenhum teste. O otimizador Reshetov mostra o lixo em 56%, mas o gopher também está lá. Quem pode encontrar....??? Realmente não vejo o objetivo desses jogos quando a saída é feita a partir da transformação da entrada, aqui e a rede não será necessária.... então é isso....
Mihail Marchukajtes: Bem, por exemplo, este ficheiro. Chitso Train não precisa de fazer nenhum teste. O otimizador Reshetov mostra lixo ou 56%, mas o gopher também está lá. Quem pode encontrar....??? Realmente não vejo o objectivo destes jogos quando a saída é feita a partir da transformação da entrada, também não haverá necessidade da rede.... so....
Foda-se, chateia este fórum que um simples arquivo raro não pode ser anexado.... É patético em uma palavra....
Para login e uso do site MQL5.com, você deve ativar o uso de cookies.
Ative esta opção no seu navegador, caso contrário você não poderá fazer login.
Você entrou na conta. A autenticação de dois fatores foi desativada. Configure-a novamente e escaneie um novo código QR ou continue com a autenticação de dois fatores desativada.
OK)))) mas leia atentamente as condições -
"pós resultados em % (casos previstos com sucesso) para ambas as amostras (trem = xx%, teste = xx%). Não há necessidade de especificar métodos e modelos, apenas números".
Estamos à espera de mais resultados. Pergunto-me que conclusões tirará Mihail Marchukajtes.
meu resultado (se você desejar, eu lhe darei o método também):
# predict with best models
glm_predict_train <- as.data.frame(predict(glm_obj
, newx = training
, type = "class"
, s = best_models$bestTune$lambda))
glm_predict_train$observed <- train_y
table(glm_predict_train[, 2], glm_predict_train[, 1])
table(glm_predict_train[, 2], glm_predict_train[, 1]) / nrow(training)
# validate with best models
glm_predict_validate <- as.data.frame(predict(glm_obj
, newx = validating
, type = "class"
, s = best_models$bestTune$lambda))
glm_predict_validate$observed <- validate_y
table(glm_predict_validate[, 2], glm_predict_validate[, 1])
table(glm_predict_validate[, 2], glm_predict_validate[, 1]) / nrow(validating)
56% em treinamento:
> table(glm_predict_train[, 2], glm_predict_train[, 1])
down up
down 333 181
up 256 230
> table(glm_predict_train[, 2], glm_predict_train[, 1]) / nrow(training)
down up
down 0.333 0.181
up 0.256 0.230
52% no teste:
> table(glm_predict_validate[, 2], glm_predict_validate[, 1])
down up
down 332 173
up 309 186
> table(glm_predict_validate[, 2], glm_predict_validate[, 1]) / nrow(validating)
down up
down 0.332 0.173
up 0.309 0.186
Não entendo como é calculada esta "previsibilidade" e se faz algum sentido se o alvo não for levado em conta.
Existem fórmulas para estimar o ruído do sinal, ou vice-versa. Como e o que estas fórmulas calculam, só o autor sabe, só podemos confiar que ele sabe o que está fazendo.
O resultado final é bastante simples - se os próprios preditores não são "ruídos", é mais fácil prever algo com eles. E se os processar de alguma forma, pode obter um sinal ainda mais estável. Um sinal estável é uma boa base para uma previsão.
Você mesmo pode estimar rapidamente os preditores usando a função Omega() deste pacote e aplicar valores de algum preditor em particular (uma coluna da tabela de treinamento) a ele. O resultado é 0% - ruído e o preditor é inútil. 100% - tudo é bom, o prognosticador pode ser usado.
Suponho que não devemos alimentar a função com os valores do indicador puro, mas com o seu incremento, por exemplo, para uma média móvel - c(MA[0]-MA[1], MA[1]-MA[2], MA[2]-MA[3], etc.).
Sobre os valores alvo - sim, eles não são usados no pacote. Este pacote não pode prever nada. Só de alguma forma determina quais os preditores em que se pode e quais não se pode confiar, e cria mais alguns novos baseados neles. A seleção da variável alvo e o treinamento do modelo preditivo devem ser tratados de forma diferente. É lógico que algumas variáveis-alvo podem ser previstas melhor e outras pior.
A variável alvo é um problema para qualquer pacote. Não é certo que a variável alvo utilizada possa sequer ser prevista com os preditores disponíveis. Por exemplo, posso usar ou "subir/descer no preço na barra seguinte" ou "subir/descer em ziguezague" para a variável alvo. Eu gostaria de aprender como criar novas variáveis-alvo para que elas se ajustem melhor aos preditores disponíveis. Quem sabe, talvez eu pudesse prever perfeitamente um apartamento com os meus preditores, mas nunca saberei porque ainda não o experimentei.
SanSanych Fomenko
Mihail Marchukajtes
Só preciso de tirar os atrasos do A6, aplicar uma fórmula simples sete menos de quinto e obter 100% em ambas as amostras. Obrigado a todos vocês. Boa sorte...
Como entendo que ninguém lê os termos e condições (qualquer manipulação de dados é permitida), por isso não vou torturar. Na verdade, tudo é simples.
Só precisa de retirar os atrasos do A6, aplicar uma fórmula simples de sétimo menos de quinto e obter 100% em ambas as amostras. Obrigado a todos vocês. Boa sorte...
Qual é a graça disso? Eu também posso codificar uma variável de saída em uma pilha de lixo de entrada. Não vais conseguir adivinhar. Ainda não sei qual foi o objectivo disso.
Qual é a graça disso? Eu também posso codificar uma variável de saída em uma pilha de lixo de entrada. Não vais conseguir adivinhar. Ainda não percebi o objectivo disto.
Vá lá, vamos tentar. Só uma simples.
No qual você não pode ver o gopher, mas ele está lá))))
Vá lá, vamos tentar. Só uma simples.
Bem, por exemplo, este ficheiro. Chitso Train não precisa de fazer nenhum teste. O otimizador Reshetov mostra lixo ou 56%, mas o gopher também está lá. Quem pode encontrar....??? Realmente não vejo o objectivo destes jogos quando a saída é feita a partir da transformação da entrada, também não haverá necessidade da rede.... so....