清除一个定义元素的数组 - 页 16 1...91011121314151617181920212223...30 新评论 Nikolai Semko 2018.11.15 19:06 #151 Taras Slobodyanik:我认为这两面旗帜是很好的搭配。http://osinavi.ru/asm/4.php 并为对于不必要的运营商/比较... 我通过剖析进行了检查。匹配的比较、赋值和矩阵操作的数量 Maxim Kuznetsov 2018.11.15 19:29 #152 Nikolai Semko:我又回到了我被 误解的执行时间上的差异,两个循环的逻辑和检查数量几乎100%相同。我已经在上面写了--我的代码中的比较操作较少... ----- 来自校外的,90年代的某个地方。 1)如果(条件)A,B,C是独立的,那么你必须在概率增加时将它们塞进AND函数,在概率减少时塞进OR函数。 如果它们是相互依存的,就不能把它们合并成一个表达式(即做if (A && B) )。 2) 如果有嵌套的循环A,B,那么外层的循环应该更短。 3) 如果循环内有一个条件,你应该划分循环,如果可能的话,把这个条件带到循环外。 Алексей Тарабанов 2018.11.15 19:39 #153 Maxim Kuznetsov:我已经在上面写过了--我的代码中的比较操作比较少... ----- 来自校外学习,在90年代的某个地方。 1)如果(条件)A,B,C是独立的,那么它们应该按概率增加的方式放在AND函数中,按概率减少的方式放在OR函数中。 而如果是依赖性的,它们就不能合并成一个表达式(即做if (A &&B) )。 2) 如果有嵌套的循环A,B,那么外层的循环应该更短。 3) 如果循环内有一个条件,你应该把循环分割开来,如果可能的话,把条件带到外面。 1)反之亦然,这正是你所做的。如果复合 与运算符 中的第一个条件没有被执行,我们为什么要检查所有其他条件?因此,首先我们检查一下这个条件,它很可能是假的。 虽然,是的--它是:按复合条件中的真话概率升序排序。 Maxim Kuznetsov 2018.11.15 19:51 #154 Алексей Тарабанов:1)反过来说,你已经做了。C语言中条件运算符执行的特殊性。也许我写错了,但一次就能为大家解释清楚......。 A && B & C 并应尽快feyed,以避免尝试所有其他条件。优化器不会为程序员做这件事(*),因为他/她不知道程序将在什么数据上执行。 A || B || C 这里反之亦然 :-) 因为它是布尔运算。!( ( (!a)&&(!b)&&(!c))(如果你不把括号弄乱,再签一次) (*) 优化编译器可以依靠条件设置得恰到好处这一事实,它们在这些假设的基础上建立自己的内部厨房。 Алексей Тарабанов 2018.11.15 19:57 #155 Maxim Kuznetsov:也许我写错了,但这样更容易让大家一目了然...... A && B & C 而且应该尽快进行治疗,以便不通过所有其他条件。这意味着第一个要放的谓词是一个将无法执行整个进一步的链的谓词。 优化器不会为程序员这样做(*),因为他/她不知道程序将在什么数据上执行 A || B || C 它是反过来的 :-) 因为它是布尔运算。!( ( (!a)&&(!b)&&(!c))(如果再在括号内,标志就不会混淆了) (*) 优化编译器可以依靠条件设置得恰到好处这一事实,它们在这些假设的基础上建立自己的内部厨房。我完全同意。 Stanislav Dray 2018.11.15 21:31 #156 Nikolai Semko:我又回到了我被 误解的执行时间上的差异,两个循环的逻辑和检查数量几乎100%相同。 因此,再次强调,为什么要从库兹涅佐夫的代码中找出这样一个变体。工作的速度是做绝对相同事情的两倍以上。编译器的奇妙之处在于什么? 这样的设计真的可能吗。编译器为处理器找到一些特殊的汇编器的搜索命令?但里面有一个额外的检查i<j,不是吗? 因为同样的事情通过为执行起来要慢得多。 示范脚本的代码见附件 这就是经常发生的情况。你正忙于处理一些不必要的垃圾,发现了一些相当有趣的事情。开发人员,你能不能看一下可执行代码,看看是什么造成了这种差异? 你需要了解编译器的逻辑,以便在未来创建更多的最优算法。总的来说,这是一个很奇怪的情况。 我想很多事情取决于编译器和我测试的机器。 以下是我在32位机器上对你的例子的结果 正如你所看到的,没有什么特别的优势。而这里是对上一个变体中的数组删除功能的测试。 Stanislav Dray 2018.11.15 21:33 #157 有时,测试结果会与以前的结果有很大不同,不清楚这是什么原因造成的,也许是MQL代码处理中的一些特定的中断系统 Maxim Kuznetsov 2018.11.15 21:44 #158 Stanislav Dray: 在测试过程中,有时 结果可能与之前的结果大不相同,目前还不清楚原因,也许这与MQL代码处理中的一些特定中断系统有关。在测试算法的时候,应该采取 *或预先准备好的数据集(与实际需要的数据大致相似)。 *或在RNG上做非常 多的传递。 在测试中。 *交替/洗刷测试顺序和 * 观察停顿并重置各种缓存 Stanislav Dray 2018.11.15 21:53 #159 Maxim Kuznetsov:在测试算法的时候,应该采取 *或预先准备好的数据集(与实际需要的数据大致相似)。 *或者在RNG上做非常 多的传递。 在测试中。 *交替/洗牌测试序列和 * 观察停顿并重置各种缓存 好,就像我们使用预先准备好的数据一样。对于所有的功能,都使用相同的数据进行测试。至于洗牌/排队,是的,如果你改变测试的顺序,我已经注意到了差异。但如何重置缓存? Алексей Тарабанов 2018.11.15 21:55 #160 Maxim Kuznetsov:在测试算法的时候,应该采取 *或预先准备好的数据集(与实际需要的数据大致相似)。 *或在RNG上做非常 多的传递。 在测试中。 *交替/洗牌测试序列和 * 观察停顿,倾倒各种缓存 不要取笑别人 1...91011121314151617181920212223...30 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
我认为这两面旗帜是很好的搭配。
http://osinavi.ru/asm/4.php
并为对于不必要的运营商/比较...
我又回到了我被 误解的执行时间上的差异,两个循环的逻辑和检查数量几乎100%相同。
我已经在上面写了--我的代码中的比较操作较少...
-----
来自校外的,90年代的某个地方。
1)如果(条件)A,B,C是独立的,那么你必须在概率增加时将它们塞进AND函数,在概率减少时塞进OR函数。
如果它们是相互依存的,就不能把它们合并成一个表达式(即做if (A && B) )。
2) 如果有嵌套的循环A,B,那么外层的循环应该更短。
3) 如果循环内有一个条件,你应该划分循环,如果可能的话,把这个条件带到循环外。
我已经在上面写过了--我的代码中的比较操作比较少...
-----
来自校外学习,在90年代的某个地方。
1)如果(条件)A,B,C是独立的,那么它们应该按概率增加的方式放在AND函数中,按概率减少的方式放在OR函数中。
而如果是依赖性的,它们就不能合并成一个表达式(即做if (A &&B) )。
2) 如果有嵌套的循环A,B,那么外层的循环应该更短。
3) 如果循环内有一个条件,你应该把循环分割开来,如果可能的话,把条件带到外面。
1)反之亦然,这正是你所做的。如果复合 与运算符 中的第一个条件没有被执行,我们为什么要检查所有其他条件?因此,首先我们检查一下这个条件,它很可能是假的。
虽然,是的--它是:按复合条件中的真话概率升序排序。
1)反过来说,你已经做了。C语言中条件运算符执行的特殊性。
也许我写错了,但一次就能为大家解释清楚......。
A && B & C
并应尽快feyed,以避免尝试所有其他条件。优化器不会为程序员做这件事(*),因为他/她不知道程序将在什么数据上执行。
A || B || C
这里反之亦然 :-) 因为它是布尔运算。!( ( (!a)&&(!b)&&(!c))(如果你不把括号弄乱,再签一次)
(*) 优化编译器可以依靠条件设置得恰到好处这一事实,它们在这些假设的基础上建立自己的内部厨房。
也许我写错了,但这样更容易让大家一目了然......
A && B & C
而且应该尽快进行治疗,以便不通过所有其他条件。这意味着第一个要放的谓词是一个将无法执行整个进一步的链的谓词。 优化器不会为程序员这样做(*),因为他/她不知道程序将在什么数据上执行
A || B || C
它是反过来的 :-) 因为它是布尔运算。!( ( (!a)&&(!b)&&(!c))(如果再在括号内,标志就不会混淆了)
(*) 优化编译器可以依靠条件设置得恰到好处这一事实,它们在这些假设的基础上建立自己的内部厨房。
我完全同意。
我又回到了我被 误解的执行时间上的差异,两个循环的逻辑和检查数量几乎100%相同。
因此,再次强调,为什么要从库兹涅佐夫的代码中找出这样一个变体。
工作的速度是做绝对相同事情的两倍以上。
编译器的奇妙之处在于什么?
这样的设计真的可能吗。
编译器为处理器找到一些特殊的汇编器的搜索命令?但里面有一个额外的检查i<j,不是吗?
因为同样的事情通过为执行起来要慢得多。
示范脚本的代码见附件
这就是经常发生的情况。你正忙于处理一些不必要的垃圾,发现了一些相当有趣的事情。
开发人员,你能不能看一下可执行代码,看看是什么造成了这种差异?
你需要了解编译器的逻辑,以便在未来创建更多的最优算法。
总的来说,这是一个很奇怪的情况。 我想很多事情取决于编译器和我测试的机器。 以下是我在32位机器上对你的例子的结果
正如你所看到的,没有什么特别的优势。而这里是对上一个变体中的数组删除功能的测试。
在测试过程中,有时 结果可能与之前的结果大不相同,目前还不清楚原因,也许这与MQL代码处理中的一些特定中断系统有关。
在测试算法的时候,应该采取
*或预先准备好的数据集(与实际需要的数据大致相似)。
*或在RNG上做非常 多的传递。
在测试中。
*交替/洗刷测试顺序和
* 观察停顿并重置各种缓存
在测试算法的时候,应该采取
*或预先准备好的数据集(与实际需要的数据大致相似)。
*或者在RNG上做非常 多的传递。
在测试中。
*交替/洗牌测试序列和
* 观察停顿并重置各种缓存
好,就像我们使用预先准备好的数据一样。对于所有的功能,都使用相同的数据进行测试。至于洗牌/排队,是的,如果你改变测试的顺序,我已经注意到了差异。但如何重置缓存?
在测试算法的时候,应该采取
*或预先准备好的数据集(与实际需要的数据大致相似)。
*或在RNG上做非常 多的传递。
在测试中。
*交替/洗牌测试序列和
* 观察停顿,倾倒各种缓存
不要取笑别人