Aprendizaje automático en el trading: teoría, práctica, operaciones y más - página 401

Nuevo comentario
 
elibrarius:
Espero que esto no haya sido compilado manualmente. ¿Fue de alguna manera en ciclos? Manualmente habría llevado horas...


En un bucle, sí.

N_INPUTS <- 10

outputfile <- "rnn_10.mq5"

cat("double RNN(\n",paste(" double p",1:N_INPUTS, sep="", collapse = ",\n"),"){\n", sep="", file = outputfile)
cat("   double probability = \n", file = outputfile, append = TRUE)
i <- 0
while(i < 2^N_INPUTS){
  binary <- tail(rev(as.integer(intToBits(i))), N_INPUTS)
  cat("      ", file = outputfile, append = TRUE)
  for(j in 1:N_INPUTS){
    cat("(", file = outputfile, append = TRUE)
    if(binary[j] == 0){
      cat("1.0 - ", file = outputfile, append = TRUE)
    }
    cat("p",j,") * ", sep="", file = outputfile, append = TRUE)
  }
  cat("x", i, sep="", file = outputfile, append = TRUE)
  if(i!=(2^N_INPUTS-1)){
    cat(" +", file = outputfile, append = TRUE)
  }else{
    cat(";", file = outputfile, append = TRUE)
  }
  cat("\n", file = outputfile, append = TRUE)
  i <- i+1
}
cat("\n    probability=probability/100.0;\n", file = outputfile, append = TRUE)
cat("\n    return(probability);\n", file = outputfile, append = TRUE)
cat("}", file = outputfile, append = TRUE)
 
Un poco fuera de tema, pero ¿es posible ejecutar java en la GPU????
 
Mihail Marchukajtes:
Un poco fuera de tema y aún así, ¿es posible ejecutar java en GPU????

Yo haría una pregunta más amplia, que es capaz de reescribir todo en mql5 en la GPU :)
 
Maxim Dmitrievsky:

Yo haría una pregunta más amplia, que es capaz de reescribir todo en mql5 en la GPU :)

Sólo en el proceso de reescritura se puede perder algo o cometer errores, de lo contrario tendría que ejecutarlo en la GPU, por lo menos, y luego se podría adjuntar algún coprocesador. O combinar la potencia del procesador a través de la red de Internet. Por tanto, la tarea no es trivial. Aumenta el número de núcleos a unos 20-30 y construye el modelo .... sólo ....
 
Mihail Marchukajtes:

Justo en el proceso de reescritura se te puede escapar algo o cometer errores, de lo contrario tienes que ejecutarlo en una GPU, como mínimo, y ahí ya puedes acoplar algún coprocesador. O combinar la potencia del procesador a través de la red de Internet. Por tanto, la tarea no es trivial. Aumenta el número de núcleos a unos 20-30 y construye el modelo .... sólo ....


El problema es que, tarde o temprano, usted querrá una biblioteca de este tipo para la MT, ya que abrirá más posibilidades como el auto-entrenamiento, menos batiburrillo, menos dolor de cabeza. O, al menos, como dll.

Y para esto en Java puedes simplemente alquilar un servidor multinúcleo por una hora y hacer todo lo que necesitas, porque la asignación a hilos ya está implementada allí... así que si vale la pena, trabajo extra

Personalmente, aunque no lo reescribiría, aportaría dinero para ello (para la versión mql5).

 
Maxim Dmitrievsky:


El problema es que, tarde o temprano, usted querrá una biblioteca de este tipo para la MT, ya que le abrirá más posibilidades, como el autoentrenamiento, menos batiburrillo y menos dolor de cabeza. O, al menos, como dll.

Y para este en java puedes simplemente alquilar un servidor multinúcleo por una hora y hacer todo lo que necesitas, porque las distribuciones de hilos ya están implementadas allí... así que, ¿merece la pena, el trabajo extra


Alguna vez consideré la opción de alquilar para este caso, pero mis manos nunca llegaron a hacerlo, pero ya veremos....
 
Maxim Dmitrievsky:

Reshetov:

VS Bosque de decisión de dos clases y regresión logística:

Reshetov gana esta por goleada.

Una especie de club de fans de Reshetov... (risas por el amor de Dios)) También debería tomar un punto cada uno para comprar y vender y 1000 fichas...

En realidad, es un ajuste limpio. Para un paso de muestreo de este tipo, se necesitan muestras de entrenamiento no para 3 meses sino para 5 años como mínimo, 3 meses incluso para la ultra-HFT no es suficiente cuando se tiene un millón de puntos al día. Y no es necesario reinventar la rueda, un simple XGB con el conjunto de características adecuadas da un resultado casi óptimo.

 
Aliosha:

Una especie de club de fans de Reshetov... (risas por el amor de Dios)) También debería tomar un punto cada uno para la compra y venta y 1000 características...

En realidad, es un ajuste limpio. Para un paso de muestreo de este tipo, se necesitan muestras de entrenamiento no para 3 meses sino para 5 años como mínimo, 3 meses incluso para la ultra-HFT no es suficiente cuando se tiene un millón de puntos al día. Y no hay necesidad de reinventar la rueda, el banal XGB con el conjunto adecuado de características da resultados casi óptimos.


No, no somos fanáticos, sólo buscamos lo óptimo ) Por 3 meses para xft es más que suficiente. ¿Qué es el XGB trivial? Los bayesianos ingenuos sólo lo saben :)

Aunque los encajen, otros modelos tampoco pueden hacerlo, por mucho que los haya hilado

 
Dr. Trader:

Es mejor definir la importancia de los predictores de la siguiente manera

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

Según tengo entendido, los predictores con alta correlación entre ellos son descartados.
Yo lo hago de forma un poco diferente - cuento la matriz de correlación completa y luego empezando por la 1ª compruebo la correlación con ella, si es superior a 0,9 (el parámetro es ajustable) la descarto. El método fue descrito en artículos sobre MO.

Parece que tienes muchos predictores sin seleccionar... Parece que su función elimina en el nivel de 0,5


 
Maxim Dmitrievsky:


No, no somos fanáticos, sólo buscamos lo óptimo ) En 3 meses para hft es más que suficiente. ¿Qué es el XGB banal? Los bayesianos ingenuos sólo lo saben :)

Aunque el ajuste, otros modelos no pueden hacerlo tampoco, ya que no los torcí

XGB - https://en.wikipedia.org/wiki/Xgboost - el arma de fusión del aprendizaje automático. "Banal", ya que es el más popular.

3 meses para hft no es suficiente, para un ciclo de simulación completo, ya que el modelo necesita ser probado en diferentes mercados, cambios de modo, techos de flash y diferentes cisnes, las pruebas de estrés sintéticas no pueden hacer eso como el mercado real. El modelo final no utilizará, en su mayor parte, más que los datos de la semana anterior, pero para configurarlo habrá que ejecutarlo con muestras de 1 a 3 años para asegurarse de que no lo estropea todo. En 3 meses los datos pueden ser entrenados y si los datascientists saben sus cosas, resultará ser un segador de dinero regular, pero un día, tal vez en 3 meses tal vez en medio año, todo puede romper bruscamente, por razón "desconocida", o más bien conocida, ya que el modelo no se ha enfrentado a tal condición de mercado meta y se convirtió en irrelevante.

1...394395396397398399400401402403404405406407408...3399
Nuevo comentario