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
我希望这不是手动编译的?它是否以某种方式在循环?手动操作,这将需要几个小时......
在一个循环中,是的。
有点偏离主题,还是那句话,是否可以在GPU???? 上运行JAVA?
我想问一个更广泛的问题,谁能够在GPU上重写mql5上的一切:)
我想问一个更广泛的问题,谁能够在GPU上重写mql5上的一切:)
只是在改写的过程中可能会遗漏或犯错,否则我至少需要在GPU上运行,然后可以附加一些辅助处理器。或通过互联网网结合处理器的力量。因此,这项任务并非微不足道。将核心数量增加到约20-30个,并建立模型....。只是....
只是在改写的过程中,你可能会错过一些东西或犯错,否则你必须在GPU上运行,至少,在那里你已经可以附加一些辅助处理器。或通过互联网网结合处理器的力量。因此,这项任务并非微不足道。将核心数量增加到约20-30个,并建立模型....。只是....
问题是,你迟早还是会想要这样一个用于MT的库,因为它将开启更多的可能性,比如自动训练,减少大杂烩,减少头痛。或者至少是作为一个dll。
而对于Java中的这个,你只需租一个多核服务器一个小时,就可以完成你所需要的一切,因为分配给线程的工作已经在那里实现了......所以是否值得呢,额外的工作
就个人而言,即使我不会重写它,我也会为它捐钱(为mql5版本)。
问题是,你迟早还是会想要这样一个用于MT的库,因为它将开辟更多的可能性,比如自动训练,更少的大杂烩,更少的头痛。或者至少是作为一个dll。
而对于java上的这个问题,你只需要租一个多核服务器一个小时,就可以完成你所需要的一切,因为线程分布已经在那里实现了......所以,这值得吗,额外的工作
我曾经考虑过为这个案子租房的方案,但我的手一直没有动过,但我们会看到....。
雷舍托夫。
VS 两类决策森林和逻辑回归。
雷舍托夫以压倒性优势赢得了这场比赛。
某种Reshetov粉丝俱乐部...(看在上帝的份上笑一笑))你也应该为买入和卖出以及1000个筹码各取一分......
事实上,它是一个干净的配合。对于这样的采样步骤,需要的训练样本不是3个月,而是至少5年,当你每天有一百万个点时,即使是超HFT的3个月也是不够的。而且没有必要重新发明轮子,简单的XGB加上正确的功能集就能得到准最佳的结果。
某种Reshetov粉丝俱乐部...(看在上帝的份上笑一笑))你还应该为买卖和1000个功能各拿一分......
事实上,它是一个干净的配合。对于这样的采样步骤,需要的训练样本不是3个月,而是至少5年,当你每天有一百万个点时,即使是超HFT的3个月也是不够的。而且,没有必要重新发明轮子,平庸的XGB加上正确的功能设置,就可以得到准最佳的结果。
不,我们不是粉丝,我们只是在寻找最佳的)对于XFT来说,3个月是绰绰有余的。什么是琐碎的XGB? 天真的贝叶斯主义者只知道:)
即使适合,其他模型也做不到,不管我怎么转。
最好将预测因素的重要性定义如下
按照我的理解,相互之间有高度关联的预测因子会被淘汰。
我的做法有点不同--我计算完整的相关矩阵,然后从第一个开始检查与它的相关性,如果它高于0.9(参数可调),我就放弃它。该方法在关于MO的文章中进行了描述。
你似乎有很多预测器没有被选中...看来,你的函数在0.5的水平上消除了
不,我们不是粉丝,我们只是在寻找最佳的)在3个月的时间里,对于hft来说是绰绰有余的。什么是平庸的XGB? 天真的贝叶斯主义者只知道:)
即使适合,其他模型也做不到,因为我没有扭曲它们。
XGB - https://en.wikipedia.org/wiki/Xgboost - 机器学习的融合武器。"平庸",因为它是最受欢迎的。
对于一个完整的模拟周期来说,3个月的时间是不够的,因为模型需要在不同的市场、模式变化、闪光屋顶和不同的天鹅上进行测试,合成压力测试不能像真实市场那样做。最终的模型在大多数情况下将使用不超过前一周的数据,但为了配置它,你将需要在1-3年的样本上运行它,以确保它不会到处乱来。在3个月内,数据可以被训练,如果数据科学家知道他们的东西,它将变成一个普通的割草机,但有一天,也许在3个月内,也许在半年内,一切都可以突然打破,因为 "未知 "的原因,或者说是已知的,因为模型没有面对这样的元市场条件,变得不相关。