算法的优化。 - 页 6 12345678910 新评论 Andrey Khatimlianskii 2012.05.22 02:54 #51 C-4:整个问题是在第二个周期。它同时处理来自潜在极值的左右分支,因此它只经过(N-1)/2条,但这是不够的。测量表明,在算术级数中搜索极值所花费的时间取决于周期N,这非常非常糟糕。至少有一个断点没有了。//Перебираем все бары for (int bar = 0; bar < MyQuotes.Count; bar++) { //Подготовка данных ... int pperiod = (N - 1)/2; //Перебираем бары относительно потенциального экстремума for (int i = 1; i <= pperiod; i++) { if (MyQuotes.High[bar - i] > MyQuotes.High[bar] || MyQuotes.High[bar + i] > MyQuotes.High[bar]) up = false; if (MyQuotes.Low[bar - i] < MyQuotes.Low[bar] || MyQuotes.Low[bar + i] < MyQuotes.Low[bar]) down = false; if ( !up && !down ) break; // А зачем искать дальше? } }更好的是,真的分出上下,在检查不成功后立即停止。 TheXpert 2012.05.22 09:39 #52 Mathemat:如果所有其他方法都失败了,可以试试OCL。 这不会有太大的区别。 Vasiliy Sokolov 2012.05.22 15:09 #53 TheXpert: 这不会有很大的区别。 是的,会的。这是因为该任务不需要顺序执行。整个酒吧的历史可以分为k段,每段将由不同的CPU核心处理。我不知道OCL的机械原理,但我认为这里的原理是一样的。之字形本身的另一个特点是,它是有顺序的,每一个新的行都是从上一个行的末尾开始的,这使得分割成子任务非常困难,甚至不可能。 Vasiliy Sokolov 2012.05.22 15:14 #54 komposter:至少有一个断点没有了。更好的是,真正做到上下分离,在检查不成功的情况下立即停止。 同样,分离顶部和底部的结果是两个通道的。这使搜索时间增加了一倍。如果不使用多线程,分离本身并不能带来任何性能上的提升,尤其是对于小的n来说。 hrenfx 2012.05.22 15:27 #55 尽管如此,OCL(或一般意义上的并行化)并不是一种算法上的优化,而是一种技术上的优化。我怀疑在你的案例中,是否有必要将最快的O(N)变量的解决方案并行化。 TheXpert 2012.05.22 15:32 #56 C-4: 他将。没有雅达雅达?给我看看。所以,祝你好运。要讨论一个复杂度线性地依赖于一个参数值的算法的优化,可能是你无事可做。 Vasiliy Sokolov 2012.05.22 18:02 #57 TheXpert:没有雅达雅达?给我看看。总之,祝你好运。讨论一个复杂度线性地依赖于一个参数值的算法的优化--你真的没有什么可做的。好的,我将完成完成算法,并在工作室发布并联的结果。hrenfx:尽管如此,OCL(或一般意义上的并行)并不是一种算法上的优化,它更像是一种技术上的优化。我怀疑在你的情况下,是否有必要将最快的O(N)变量解决方案并行化。我怎么说呢。任何并行化都是算法的严重复杂化。此外,如果你不对一个对数据量有线性依赖的算法进行并行化,你还能并行化什么呢?简而言之,我将重写算法,看看会带来什么。 Andrey Khatimlianskii 2012.05.23 00:43 #58 C-4: 同样,分离顶部和底部的结果是两个通道,用于。这使搜索的时间增加了一倍。如果不使用多线程,分离本身并不能带来性能上的提升,特别是对于小的n。你怎么能如此肯定?我的检查显示并非如此。01:29:25 SpeedTest EURUSD,M15 输入: Interations=10000; pperiod=10;01:29:25 SpeedTest EURUSD,M15:条数=378001:30:46 SpeedTest EURUSD,M15: 原始函数:81.558 秒,极值:131/12101:31:10 SpeedTest EURUSD,M15: 在我的编辑下(中断):23.291 秒,极端值:131/12101:31:27 SpeedTest EURUSD,M15: 随着我的突破(突破):17.565 秒,极值:131/121附上一个mq4脚本。 附加的文件: SpeedTest.mq4 4 kb Andrey Khatimlianskii 2012.05.23 01:12 #59 还有一个测试来完成这幅画。01:38:56 SpeedTest EURUSD,M1 inputs: Interations=1000; pperiod=100;01:38:56 SpeedTest EURUSD,M1:条数=3389601:50:19 SpeedTest EURUSD,M1: 原始函数:683.565 秒,极值:121/12701:50:54 SpeedTest EURUSD,M1: 在我的编辑下(中断): 34.383 秒,极值:121/12701:51:16 SpeedTest EURUSD,M1: 随着我的突破(突破):22.714 秒,极值:121/127 TheXpert 2012.05.23 09:57 #60 komposter: C.T.D.在他的第一个帖子中正是这样写的。 12345678910 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
整个问题是在第二个周期。它同时处理来自潜在极值的左右分支,因此它只经过(N-1)/2条,但这是不够的。测量表明,在算术级数中搜索极值所花费的时间取决于周期N,这非常非常糟糕。
至少有一个断点没有了。
更好的是,真的分出上下,在检查不成功后立即停止。
如果所有其他方法都失败了,可以试试OCL。
这不会有很大的区别。
至少有一个断点没有了。
更好的是,真正做到上下分离,在检查不成功的情况下立即停止。
尽管如此,OCL(或一般意义上的并行化)并不是一种算法上的优化,而是一种技术上的优化。
我怀疑在你的案例中,是否有必要将最快的O(N)变量的解决方案并行化。
他将。
没有雅达雅达?给我看看。
所以,祝你好运。要讨论一个复杂度线性地依赖于一个参数值的算法的优化,可能是你无事可做。
没有雅达雅达?给我看看。
总之,祝你好运。讨论一个复杂度线性地依赖于一个参数值的算法的优化--你真的没有什么可做的。
好的,我将完成完成算法,并在工作室发布并联的结果。
尽管如此,OCL(或一般意义上的并行)并不是一种算法上的优化,它更像是一种技术上的优化。
我怀疑在你的情况下,是否有必要将最快的O(N)变量解决方案并行化。
我怎么说呢。任何并行化都是算法的严重复杂化。此外,如果你不对一个对数据量有线性依赖的算法进行并行化,你还能并行化什么呢?
简而言之,我将重写算法,看看会带来什么。
同样,分离顶部和底部的结果是两个通道,用于。这使搜索的时间增加了一倍。如果不使用多线程,分离本身并不能带来性能上的提升,特别是对于小的n。
你怎么能如此肯定?
我的检查显示并非如此。
01:29:25 SpeedTest EURUSD,M15 输入: Interations=10000; pperiod=10;
01:29:25 SpeedTest EURUSD,M15:条数=3780
01:30:46 SpeedTest EURUSD,M15: 原始函数:81.558 秒,极值:131/121
01:31:10 SpeedTest EURUSD,M15: 在我的编辑下(中断):23.291 秒,极端值:131/121
01:31:27 SpeedTest EURUSD,M15: 随着我的突破(突破):17.565 秒,极值:131/121
附上一个mq4脚本。
还有一个测试来完成这幅画。
01:38:56 SpeedTest EURUSD,M1 inputs: Interations=1000; pperiod=100;
01:38:56 SpeedTest EURUSD,M1:条数=33896
01:50:19 SpeedTest EURUSD,M1: 原始函数:683.565 秒,极值:121/127
01:50:54 SpeedTest EURUSD,M1: 在我的编辑下(中断): 34.383 秒,极值:121/127
01:51:16 SpeedTest EURUSD,M1: 随着我的突破(突破):22.714 秒,极值:121/127