トレーディングにおける機械学習:理論、モデル、実践、アルゴトレーディング - ページ 401

 
エリブラリウス
手動でコンパイルしたものではないのでしょうね?なんとなくサイクルがあったのでしょうか?手作業だと何時間もかかってしまうので...。


ループでは、そうですね。

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)
 
少し話がそれますが、GPUでjavaを動かすことは可能なのでしょうか?
 
ミハイル・マルキュカイツ
少し話がそれますが、それでもGPUでjavaを動かすことは可能なのでしょうか?

GPUでmql5の全てを書き換えることができるのは誰なのか、もっと広い質問をしたいですね :)
 
マキシム・ドミトリエフスキー

GPUでmql5の全てを書き換えることができるのは誰なのか、もっと広い質問をしたいですね :)

ただ、書き換える過程で何か見落としがあったり、間違いがあったりするので、そうでなければ、せめてGPUで動かして、何かコプロセッサを付ける必要がありますね。あるいは、インターネット・ネット経由でプロセッサ・パワーを組み合わせる。だから、その作業は些細なことではないのです。コア数を20〜30程度に増やし、モデルを構築する......。一応
 
ミハイル・マルキュカイツ

ただ、書き換えていく過程で、何か見落としたり、間違えたりすることがあります。そうでなければ、少なくともGPUで動かす必要があり、そこにはすでに何らかのコプロセッサを取り付けることができます。あるいは、インターネット・ネット経由でプロセッサ・パワーを組み合わせる。だから、その作業は些細なことではないのです。コア数を20〜30程度に増やし、モデルを構築する......。一応


問題は、自動トレーニングのような可能性が広がり、寄せ集めが減り、頭痛の種が減るので、遅かれ早かれMT用のこのようなライブラリが必要になることです。せめてdllとして。

また、Javaのこれについては、マルチコアサーバーを1時間借りれば、スレッドへの割り当てはすでにそこで実装されているので、必要なことはすべてできる...だから、それに見合うかどうかは、余分な仕事

個人的には、書き直しはしないにしても、お金を寄付するつもりです(mql5版の場合)。

 
マキシム・ドミトリエフスキー


問題は、自動トレーニングのような可能性を広げ、ごった煮を減らし、頭を使わなくなるため、遅かれ早かれMT用にこのようなライブラリが欲しくなることに変わりはない。せめてdllとして。

そして、このjavaでの1つは、マルチコアサーバーを1時間借りるだけで、必要なことはすべてできます。スレッド分散はすでにそこに実装されているからです。


今回の件で一度はレンタルという選択肢を考えたのですが、手が回らなかったのですが、これからですね...。
 
マキシム・ドミトリエフスキー

レシェトフ

VS 2クラス決定森とロジスティック回帰。

レシェトフの圧勝です。

レシェトフ・ファンクラブのようなものか......。(笑))売買と1000チップも1点ずつ取った方が...。

実は、きれいに収まっているんです。このようなサンプリングステップでは、トレーニングサンプルは3ヶ月ではなく、最低でも5年分必要です。また、車輪を再発明する必要はなく、シンプルなXGBと適切な機能の組み合わせで、準最適な結果を得ることができます。

 
アリョーシャ

レシェトフ・ファンクラブのようなものか......。(笑))売買と1000の機能もそれぞれ1点ずつ取った方が...。

実は、きれいに収まっているんです。このようなサンプリングステップでは、トレーニングサンプルは3ヶ月ではなく、最低でも5年分必要です。また、車輪を再発明する必要はなく、ありふれたXGBに適切な機能を組み合わせることで、準最適な結果を得ることができるのです。


いや、私たちはファンではなく、最適なものを探しているだけです)xftは3ヶ月で十分すぎるくらいです。トリビアルXGBとは何か?)

フィットしても、他のモデルもどう紡いでもダメなんです

 
Dr.トレーダー

予測変数の重要度は、以下のように定義するのがよいでしょう。

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

私の理解では、予測因子間の相関が高いものは排除されます。
私は少し違った方法で、相関行列をすべて数え、最初のものからその相関をチェックし、それが0.9より高ければ(パラメータは調整可能)、それを削除しています。その方法は、MOの記事で紹介した。

プレディクターがたくさん未選択になっているようですが...。0.5倍で消去されるようです。


 
マキシム・ドミトリエフスキー


ファンではなく、最適なものを探しているのです。一般的なXGBとは何なのか?)

フィットしても、他のモデルは、私はそれらをひねったわけではないので、行うことはできません。

XGB - https://en.wikipedia.org/wiki/Xgboost - 機械学習の融合兵器。"バナル "が一番人気。

hftの3ヶ月は、完全なシミュレーションサイクルとしては不十分です。なぜなら、モデルは、異なる市場、モードシフト、フラッシュルーフ、異なるスワンでテストする必要があり、合成ストレステストでは、実際の市場としてそれを行うことはできません。最終的なモデルは、ほとんどの場合、前週のデータしか使用しませんが、設定するためには、1〜3年分のサンプルで実行し、あらゆる場所で失敗しないようにする必要があります。しかし、ある日、あるいは3ヶ月後、あるいは半年後に、「未知の」理由で、あるいはむしろ既知の理由で、すべてが突然に壊れることがあります。

理由: