Eu faria uma pergunta mais ampla, quem é capaz de reescrever tudo no mql5 na GPU :)
Só no processo de reescrever algo pode faltar ou cometer erros, caso contrário eu precisaria executá-lo na GPU, pelo menos, e então algum co-processador poderia ser anexado. Ou combine o poder do processador via rede de Internet. Portanto, a tarefa não é trivial. Aumentar o número de núcleos para cerca de 20-30 e construir modelo.... apenas ....
Apenas no processo de reescrever você pode perder algo ou cometer erros, caso contrário você tem que executá-lo em uma GPU, pelo menos, e lá você já pode anexar algum co-processador. Ou combine o poder do processador via rede de Internet. Portanto, a tarefa não é trivial. Aumentar o número de núcleos para cerca de 20-30 e construir modelo.... apenas ....
O problema é que, mais cedo ou mais tarde, você ainda vai querer tal biblioteca para MT, pois ela abrirá mais possibilidades como auto-treinamento, menos hodge-podge, menos dor de cabeça. Ou pelo menos como uma dll.
E para este em Java você pode apenas alugar um servidor multi-core por uma hora e fazer tudo o que você precisa, porque a alocação para threads já está implementada lá... então se vale a pena, trabalho extra
Pessoalmente, mesmo que eu não o reescrevesse, eu contribuiria com dinheiro para ele (para a versão mql5).
O problema é que, mais cedo ou mais tarde, você ainda vai querer tal biblioteca para MT, pois ela abrirá mais possibilidades como auto-treinamento, menos hodge-podge, menos dor de cabeça. Ou pelo menos como uma dll.
E para este em java você pode apenas alugar um servidor multi-core por uma hora e fazer tudo o que você precisa, porque as distribuições de thread já estão implementadas lá... então, vale a pena, trabalho extra
Uma vez considerei a opção de alugar para este caso, mas as minhas mãos nunca chegaram a chegar lá, mas veremos....
VS Dois classe decisão florestal e regressão logística:
Reshetov ganha este por um deslizamento de terra.
Uma espécie de fã-clube Reshetov... (risos por amor de Deus)) Você também deve tomar um ponto cada um para comprar e vender e 1000 fichas...
Na verdade, é um ajuste limpo. Para tal etapa de amostragem, são necessárias amostras de treinamento não por 3 meses, mas por 5 anos no mínimo, 3 meses mesmo para ultra-HFT não é suficiente quando você tem um milhão de pontos por dia. E não há necessidade de reinventar a roda, o simples XGB com o conjunto certo de características dá um resultado quase óptimo.
Uma espécie de fã-clube Reshetov... (risos por amor de Deus)) Você também deve tomar um ponto cada um para comprar e vender e 1000 características...
Na verdade, é um ajuste limpo. Para tal etapa de amostragem, são necessárias amostras de treinamento não por 3 meses, mas por 5 anos no mínimo, 3 meses mesmo para ultra-HFT não é suficiente quando você tem um milhão de pontos por dia. E não há necessidade de reinventar a roda, o XGB banal com o conjunto certo de características dá resultados quase óptimos.
Não, não somos fãs, só estamos à procura do melhor ) Durante 3 meses por xft é mais do que suficiente. O que é o XGB trivial? O ingénuo Bayesian só sabe :)
Mesmo que o ajuste, outros modelos também não o conseguem fazer, não importa como eu os tenha girado.
É melhor definir a importância dos prognosticadores da seguinte forma
library(vtreat)
sourceTable <- read.table("BuySell.csv", sep=";", header = TRUE, stringsAsFactors = FALSE)
#Эта строка кода относится только к конкретно этому файлу.
#В этом csv первая колонка и первая строка специально заполнены для конкретной модели, и тут не нужны. Удалить.
#для обычных csv файлов такую команду выполнять не нужно.
sourceTable <- sourceTable[-1,-1]
#число колонок
sourceTable_ncol <- ncol(sourceTable)
#Оценка для классификации, только для двух классов.
#Outcometarget должен быть равен значению одного из классов.
#На выбор или эта функция designTreatmentsC, или designTreatmentsN, или designTreatmentsZ (ниже, закоменчены)
#Взаимная корреляция предкиторов учитывается только в designTreatmentsC, и у повторяющихся или похожих предикторов оценка будет понижаться
set.seed(0)
treats <- designTreatmentsC(dframe = sourceTable,
varlist = colnames(sourceTable)[-sourceTable_ncol],
outcomename = colnames(sourceTable)[sourceTable_ncol],
outcometarget = 1,
verbose = FALSE
)
# #оценка для регрессии или если больше двух классов
# sourceTable[,sourceTable_ncol] <- as.numeric(sourceTable[,sourceTable_ncol])
# set.seed(0)
# treats <- designTreatmentsN(dframe = sourceTable,
# varlist = colnames(sourceTable)[-sourceTable_ncol],
# outcomename = colnames(sourceTable)[sourceTable_ncol],
# verbose = FALSE# )
# #Оценка предикторов без учёта цели.
# set.seed(0)
# treats <- designTreatmentsZ(dframe = sourceTable,
# varlist = colnames(sourceTable)[-sourceTable_ncol],
# verbose = FALSE# )
#
#табличка только с названием колонки и её оценкой важности
resultTable <- treats$scoreFrame[,c("varName", "sig")]
#сортировка
resultTable <- resultTable[order(resultTable$sig),]
#согласно общему правилу, оценка предиктора (sig) должна быть меньше 1/<общее число предикторов>
#чем оценка меньше, тем лучше
resultTable$testPassed <- resultTable$sig < 1/(sourceTable_ncol-1)
#для создания модели и прогноза лучше использовать только те предкторы у которых testPassed == TRUE
resultTable
Pelo que entendi, os preditores com alta correlação entre eles são rastreados. Faço-o um pouco diferente - conto a matriz de correlação completa e a partir da 1ª verifico a correlação, se for superior a 0,9 (parâmetro é ajustável) deixo-a cair. O método foi descrito em artigos sobre MO.
Parece ter muitos preditores não seleccionados... Parece que a sua função elimina ao nível de 0,5
Não, nós não somos fãs, só estamos à procura do óptimo ) Em 3 meses para o hft é mais do que suficiente. O que é o XGB banal? O ingénuo Bayesian só sabe :)
Mesmo que o ajuste, outros modelos também não o podem fazer, pois eu não os torci.
3 meses para o hft não é suficiente, para um ciclo completo de simulação, já que o modelo precisa ser testado em diferentes mercados, mudanças de modo, coberturas flash e diferentes cisnes, testes de estresse sintético não podem fazer isso como o mercado real. O modelo final não utilizará mais do que os dados da semana anterior, mas para configurá-lo você precisará executá-lo em amostras de 1-3 anos para ter certeza de que não estrague tudo. Em 3 meses os dados podem ser treinados e, se os cientistas de dados souberem do seu material, vai acabar por ser um cortador de relva regular, mas um dia, talvez em 3 meses, talvez em meio ano, tudo pode quebrar abruptamente, por razões "desconhecidas", ou melhor, conhecidas, uma vez que o modelo não enfrentou essa condição de meta mercado e se tornou irrelevante.
Espero que isto não tenha sido compilado manualmente? Foi, de alguma forma, em ciclos? Manualmente, teria levado horas...
Em loop, sim.
Um pouco fora de tópico e ainda assim, é possível executar java em GPU????
Eu faria uma pergunta mais ampla, quem é capaz de reescrever tudo no mql5 na GPU :)
Eu faria uma pergunta mais ampla, quem é capaz de reescrever tudo no mql5 na GPU :)
Só no processo de reescrever algo pode faltar ou cometer erros, caso contrário eu precisaria executá-lo na GPU, pelo menos, e então algum co-processador poderia ser anexado. Ou combine o poder do processador via rede de Internet. Portanto, a tarefa não é trivial. Aumentar o número de núcleos para cerca de 20-30 e construir modelo.... apenas ....
Apenas no processo de reescrever você pode perder algo ou cometer erros, caso contrário você tem que executá-lo em uma GPU, pelo menos, e lá você já pode anexar algum co-processador. Ou combine o poder do processador via rede de Internet. Portanto, a tarefa não é trivial. Aumentar o número de núcleos para cerca de 20-30 e construir modelo.... apenas ....
O problema é que, mais cedo ou mais tarde, você ainda vai querer tal biblioteca para MT, pois ela abrirá mais possibilidades como auto-treinamento, menos hodge-podge, menos dor de cabeça. Ou pelo menos como uma dll.
E para este em Java você pode apenas alugar um servidor multi-core por uma hora e fazer tudo o que você precisa, porque a alocação para threads já está implementada lá... então se vale a pena, trabalho extra
Pessoalmente, mesmo que eu não o reescrevesse, eu contribuiria com dinheiro para ele (para a versão mql5).
O problema é que, mais cedo ou mais tarde, você ainda vai querer tal biblioteca para MT, pois ela abrirá mais possibilidades como auto-treinamento, menos hodge-podge, menos dor de cabeça. Ou pelo menos como uma dll.
E para este em java você pode apenas alugar um servidor multi-core por uma hora e fazer tudo o que você precisa, porque as distribuições de thread já estão implementadas lá... então, vale a pena, trabalho extra
Uma vez considerei a opção de alugar para este caso, mas as minhas mãos nunca chegaram a chegar lá, mas veremos....
Reshetov:
VS Dois classe decisão florestal e regressão logística:
Reshetov ganha este por um deslizamento de terra.
Uma espécie de fã-clube Reshetov... (risos por amor de Deus)) Você também deve tomar um ponto cada um para comprar e vender e 1000 fichas...
Na verdade, é um ajuste limpo. Para tal etapa de amostragem, são necessárias amostras de treinamento não por 3 meses, mas por 5 anos no mínimo, 3 meses mesmo para ultra-HFT não é suficiente quando você tem um milhão de pontos por dia. E não há necessidade de reinventar a roda, o simples XGB com o conjunto certo de características dá um resultado quase óptimo.
Uma espécie de fã-clube Reshetov... (risos por amor de Deus)) Você também deve tomar um ponto cada um para comprar e vender e 1000 características...
Na verdade, é um ajuste limpo. Para tal etapa de amostragem, são necessárias amostras de treinamento não por 3 meses, mas por 5 anos no mínimo, 3 meses mesmo para ultra-HFT não é suficiente quando você tem um milhão de pontos por dia. E não há necessidade de reinventar a roda, o XGB banal com o conjunto certo de características dá resultados quase óptimos.
Não, não somos fãs, só estamos à procura do melhor ) Durante 3 meses por xft é mais do que suficiente. O que é o XGB trivial? O ingénuo Bayesian só sabe :)
Mesmo que o ajuste, outros modelos também não o conseguem fazer, não importa como eu os tenha girado.
É melhor definir a importância dos prognosticadores da seguinte forma
Pelo que entendi, os preditores com alta correlação entre eles são rastreados.
Faço-o um pouco diferente - conto a matriz de correlação completa e a partir da 1ª verifico a correlação, se for superior a 0,9 (parâmetro é ajustável) deixo-a cair. O método foi descrito em artigos sobre MO.
Parece ter muitos preditores não seleccionados... Parece que a sua função elimina ao nível de 0,5
Não, nós não somos fãs, só estamos à procura do óptimo ) Em 3 meses para o hft é mais do que suficiente. O que é o XGB banal? O ingénuo Bayesian só sabe :)
Mesmo que o ajuste, outros modelos também não o podem fazer, pois eu não os torci.
XGB - https://en.wikipedia.org/wiki/Xgboost - a arma de fusão da aprendizagem de máquinas. "Banal" como é o mais popular.
3 meses para o hft não é suficiente, para um ciclo completo de simulação, já que o modelo precisa ser testado em diferentes mercados, mudanças de modo, coberturas flash e diferentes cisnes, testes de estresse sintético não podem fazer isso como o mercado real. O modelo final não utilizará mais do que os dados da semana anterior, mas para configurá-lo você precisará executá-lo em amostras de 1-3 anos para ter certeza de que não estrague tudo. Em 3 meses os dados podem ser treinados e, se os cientistas de dados souberem do seu material, vai acabar por ser um cortador de relva regular, mas um dia, talvez em 3 meses, talvez em meio ano, tudo pode quebrar abruptamente, por razões "desconhecidas", ou melhor, conhecidas, uma vez que o modelo não enfrentou essa condição de meta mercado e se tornou irrelevante.