交易中的机器学习：理论、模型、实践和算法交易 - 页 298

新评论
 
安德烈-迪克

是在开发上多花一点时间，然后总是快速计算，还是快速开发，然后总是忍受迟缓的计算？

如果你用R语言快速开发，但计算速度很慢，你想在哪里进行计算？迅速开发出一款驾驶起来很慢的超级跑车？你不需要这样一辆超级跑车。


在研究任务中，发展速度才是最重要的。与其说一个写着超快的代码但一天只测试一个假设的人，不如说一个写着缓慢的代码，整夜运行计算，但第二天就有20个假设被测试的人将很容易被雇用。

对于模型的生产-实施 来说，用少量的工资雇用另一个人比较容易，他将用最快的语言重写最有希望的模型。程序员很多，竞争也很激烈，但能想出新东西的研究人员却很难找到 :P

这是一种常见的做法。寻找定量研究人员和定量开发人员的工作。前者通常需要R/Python，后者通常需要C++/Java。

 
匿名 的。


在研究任务中，发展的速度才是最重要的。与其说一个人写了超快的代码，但每天检查1个假设，不如说一个人写了慢的代码，整晚运行计算，但到了第二天他已经检查了20个假设。

对于模型的生产-实施，用少量的工资雇佣另一个人，用快速语言重写最有希望的模型，是比较容易的。程序员很多，竞争也很激烈；但能想出新东西的研究人员却很难找到 :P

这是一种常见的做法。寻找定量研究人员和定量开发人员的工作。前者通常要知道R/Python，后者通常要知道C++/Java。

使用现成的、快速的C++库，而不是在R中使用同样但缓慢的库来实现 "快速开发"，不是更容易吗？你和这里的许多人，不断地进行概念的替换。以同样的方式，人们可以在类似C语言的环境中 "快速发展"。或者你不需要适当的数据挖掘和统计知识就能在R中工作？以同样的方式，你需要知识来开发C语言。那么，为什么要做双重工作？

而且我不知道你说的是哪种 "正常做法"，但我已经习惯了一次又一次地做好。

在我的工程实践中，我经常看到一些人出于某种原因认为，如果他们使用超级方便开发的软件，就一定会做得很好......但他们无法理解一件事：他们需要另一件东西来使一切运作良好：他们头脑中的脂肪。

 
Andrey Dik:

使用现成的、快速的C++库，而不是使用同样的但在R中很慢的库来进行 "快速开发"，不是更容易吗？你和这里的许多人，不断地进行概念的替换。同样，你可以在一个类似C语言的环境中 "快速开发"。

语言的选择是你的权利和个人事务。 关于库--唉，对于任何现代或不寻常的算法，你必须自己实现一切。例如，计算 "双功率方差"（什么意思？ :D）我没有找到库。

或者一个人不需要适当的数据挖掘和统计知识就能在R中工作？

我没有这么说，我也不支持这个观点。

而且我不知道你说的是哪种 "常见做法"，但我习惯于一次就做好，一次就好。

在我的工程实践中，我经常看到一些人，出于某种原因，认为如果他们使用超级方便开发的软件包，他们一定会做得很好......但他们无法理解一件事--他们需要别的东西来使一切顺利：他们头脑中的脂肪。

我在一些复杂度为##人年的项目 中的实践表明，不同的工具适合不同的任务，有时甚至是缓慢的任务，只要它们是用于原型而不是用于生产。在不同的开发阶段使用不同的工具是开发行业的普遍做法，这也被不同工作对专家的要求所证实。我提到的项目如果用类似C语言来实现，会变得更加复杂，甚至是由知道并能做所有事情的普遍士兵来实现，并一次性写出问题的解决方案，而不需要任何研究阶段。

因此，我告辞了。

 
安德烈-迪克

使用现成的、快速的C++库，而不是为了 "快速开发 "而在R中使用同样但缓慢的库，这不是更容易吗？

在讨论R时，我一直站在全面、系统地评价这个 "图形和统计系统 "的立场上。算法语言本身在标题中根本没有提及。

在一个具体的、局部的例子上，正面比较R中的代码和上述μl中的代码或另一种编程语言的性能是完全不正确的，因为TC从来没有像上面讨论的那样由一个相关的函数组成，而总是由代码和函数调用组成的一个大集合。由于R有一个巨大的函数集，代码通常有少量的行数（1000行是很多的），但从内容上来说非常有容量。

程序本身解决了一些有意义的问题，可以大致分为两部分。

  1. 一个用R语言编写的代码形式的算法
  2. 调用函数，对于这些函数，R是一个外壳。

关于第1点，如果不得不编写大量的代码，那么速度问题就会非常严重。有三种方法来克服它。

  • 转换为字节码
  • 并行到所有核心和/或相邻的计算机。如果算法允许，这是标准的，而且非常容易做到。
  • 重写为另一种编译类型的语言。C语言是R的原生语言，这种插入的过程是有据可查的。

关于第2项，性能是相当不同的，我怀疑如果不在μl-程序的通常开发中作出特别努力，它的性能会超过R。

比如说。

表面上看，R语言中对向量和矩阵的操作是基本的。一个形式为a <- b*c 的表达式被英特尔库执行。没有循环。每个人都可以使用它，不需要额外的知识或努力。在开发一个μl程序时，很可能会使用周期，虽然也可以参考同一个库（如果程序不是针对市场的），但要达到同样的效果，需要相当高的知识水平和努力。


但这还不是全部。

如果我们解决计算量大的算法，而这些都是对R函数的诉求，开发者本人面对性能问题，已经关注到这个问题，通常在开发阶段就解决了。这通常是通过编写C代码或参考C或Fortran库来解决的。此外，这种算法在其参数中可以指定使用许多内核。R语言的开发者无需努力就能自动获得所有这些。人们可以完全专注于TC的本质，而不是实施的技术。μl-程序的开发者能否超越R中的函数开发者是值得怀疑的，原因很简单--有必要专门在性能上下功夫，而不是在TC的本质上。


从所有编写的内容来看，正确的性能比较是在μl上编写真正的TC代码和在μl+R上编写同样的代码（R中没有交易订单）并进行比较。但在它的全盛时期--我们需要它吗？

 
mytarmailS:
有人尝试过使用递归图吗？ 你可以在这里读到https://habrahabr.ru/post/145805/ ，特别是用MO代替原始BP？可能作为一种选择。


以及更多阅读http://geo.phys.spbu.ru/Problems_of_geophysics/2005/20_Zolotova_38_2005.pdf


为那些能够实施的人提供一个想法。机器视觉比较这些图，寻找模式匹配。作为无用的关联性的替代
 
马克西姆-德米特里耶夫斯基。

为那些能够实施的人提供一个想法。对这些图进行机视比较，寻找模式匹配。作为无用的关联的替代。
有可能在没有任何庞杂的情况下找到最频繁的模式。但这有什么意义呢？
 
fxsaber:

以前，一些想法无法通过TC进行测试，因为它受到了一些算法的低性能的阻碍。在这种情况下，这正是发生的事情--一种替代算法允许在优化器中探索一个与世界一样古老的想法，但以前无法在合理的时间内计算出来。


当一个人必须在几千长度的模式中计算数以千亿计的皮尔逊QC时，一个看似简单的任务的低速度就成了一个不可逾越的瓶颈。人们可能会开始说，如果一个问题看起来计算量太大，那么它就是一个表述不清楚的问题，没有什么理解。也许是这样。但是，该做的还是要做。而且，看到其他人如何实施类似的事情总是很有趣。


如果你也能在GPU上实现它，你将会非常有价值))
 
fxsaber:
没有庞氏骗局，你可以找到最频繁的模式。但这有什么意义呢？

那么对于一个模式的策略，当然不一定是最频繁的，可能有很多变种。
 
马克西姆-德米特里耶夫斯基。

不一定是模式策略中最常见的一种，可能有很多变种。

这就是我不明白的地方。在压缩数据时，使用模式数据是很有用的，而且信息损失很小（各种媒体）。但这与TC有什么关系呢？

谈论这个话题的最简单方法是用最频繁的模式作为例子。找到它并不是一件难事。

下面是一些最常出现的谜语（模式）。它的选择标准现在还不是那么重要。让谜语在那里。如何利用它进行交易？

说如果一个最外层的历史与前80%的扎古利纳相吻合，那么接下来的价格将遵循与其余20%的扎古利纳相同的模式是无稽之谈。

 
fxsaber:

这就是我不明白的地方。在压缩数据时，使用模式数据是很有用的，而且信息损失很小（各种媒体）。但这与TC有什么关系呢？

谈论这个话题的最简单方法是用最频繁的模式作为例子。要找到它并不困难。

下面是一些最常出现的谜语（模式）。它的选择标准现在还不是那么重要。让谜语在那里。如何利用它进行交易？

说如果一个最外层的历史与前80%的扎古利纳相吻合，那么接下来的价格将与其余20%的扎古利纳走势相同，这是无稽之谈。


如果预测将被证实，在相同的历史上，在大量的情况下，你为什么认为这是胡说八道呢？
1...291292293294295296297298299300301302303304305...3399
新评论