错误、漏洞、问题 - 页 212 1...205206207208209210211212213214215216217218219...3184 新评论 --- 2010.11.29 00:15 #2111 Urain: 是的，没错，只是以标准函数的形式来优化访问速度。我认为我们还不能谈论速度，尤其是MQL5处理现有的新闻数据阵列很快。而这是在希望MQL会更快的情况下。 但我想详细说明一下这个问题。我想知道你之后打算如何处理这些数据？ Mykola Demko 2010.11.29 00:20 #2112 sergeev:我认为我们还不能谈论速度，尤其是MQL5处理现有的新闻数据阵列很快。并希望MQL会更快。 但我想详细说明这一点。我想知道他们以后打算如何处理这些数据？ 具体的使用实例？而接下来是一个热门领域，之前的新闻是无法正常获得的，那么新闻策略的编码将蓬勃发展。我打算在国家统计委员会中一直使用它，但我想进一步发展这个课题。ZZZY 但只要新闻在测试器中不会出现（即新闻故事），它将不得不通过文件来做，并解析第三方资源上的新闻。 Andrey Sharov 2010.11.29 00:39 #2113 随着交易数量的增加，测试器的速度也会减慢。 期间 贸易 交易 蜱虫 酒吧 内产生的虱子，毫秒 报告大小.xlsx, KB 报告生成时间 04.10.2010-05.10.2010 5 720 46226 1438 27960 126 30秒 04.10.2010-06.10.2010 9 1680 99347 2871 240966 275 2分钟 04.10.2010-07.10.2010 21 2703 149837 4306 382370 430 10分钟 04.10.2010-10.10.2010 35 4865 253175 7118 1202809 753 35分钟 04.10.2010-16.10.2010 67 9783 492163 14226 8908720 1463 50分钟 04.10.2010-01.11.2010 79 13199 1189566 28453 20956134 不适用 (错误) 1小时10分钟 04.10.2010-27.11.2010 79 13199 2863155 56334 16055687 当以每2分钟1次交易的强度开仓时，你可以看到（日志标签），在相当长的时间内，1秒的测试时间比测试开始时少了几倍。在以Open XML格式输出测试结果 时也有类似情况。 Errors, bugs, questions 反向交易: 减少最大回撤以及在其它市场上测试 使用 OpenCL 测试烛形形态 Rashid Umarov 2010.11.29 09:26 #2114 实际上，测试时间并不直接取决于交易量。 确切地说，有10个交易的单次运行当然比有100 000个交易的运行所需时间要短，因为测试器中的每个交易都需要时间来处理。但是，对测试时间影响最大的是在一个通道中被处理的蜱虫数量。我从一个月开始在所有刻度模式下运行标准的移动平均线（区间2009.01.01-2009.02.01），每次增加一个月的测试时间，达到22个月。从图中你可以看到，测试时间对刻度数的依赖是严格的线性关系。 Rashid Umarov 2010.11.29 09:48 #2115 Vigor: 你好，反映出增加了构造#property tester_indicator " indicator.ex5"在文档中，在iCustom函数的描述中。我花了几个小时试图了解为什么iCustom在图表中能工作，但在测试器中却不能工作的原因。这在程序属性 部分有描述。测试员_指示器 绳子 自定义指标的名称，格式为"indicator_name.ex5" 。如果相应的参数被指定为常量字符串，测试所需的指标将从iCustom() 函数调用中自动确定。对于其他情况（使用IndicatorCreate()函数或在定义指标名称的参数中使用非恒定字符串），我们需要这个属性 测试员文件 绳子 测试器的文件名，指定其扩展名，用双引号括起来（作为一个常量字符串）。 指定的文件将被传递给测试人员进行操作。 如果需要，必须始终指定用于测试的输入文件 测试员资料库 绳子 带扩展名的图书馆名称，用双引号括起来。一个库可以同时拥有dll扩展名和ex5扩展名。 测试所需的库被自动检测。然而，如果一个库被一个自定义 指标所使用，就应该使用这个属性但你是对的，你需要在相关的地方再次明确地添加有关信息。 Andrey Sharov 2010.11.29 11:22 #2116 Rosh: 实际上，测试时间并不直接取决于交易的数量。确切地说，有10个交易的单次运行当然会比有100 000个交易的运行花费更少的时间，因为测试器中的每个交易都需要时间来处理。 但是，对测试时间影响最大的是在一个通道中被处理的蜱虫数量。我从一个月开始在所有刻度模式下运行标准的移动平均线（区间2009.01.01-2009.02.01），每次增加一个月的测试时间，达到22个月。 从图中可以看出，测试时间对刻度数的依赖是严格的线性关系。 也许，我应该说 "一次运行10个交易，当然比运行100 000个交易所需的时间少，因为测试器中的每个交易都需要时间来处理。 我同意关于蜱虫的说法。但要准确地注意交易的数量--那里的时间增长显然不是线性的，形成一个测试报告是完全不可能的! Гребенев Вячеслав 2010.11.29 11:32 #2117 在EventSetTimer( )中可以设置的最大时间是什么？INT_MAX？ 我不这么认为。我不想自己去调查，帮助中也没有。 Документация по MQL5: Стандартные константы, перечисления и структуры / Именованные константы / Константы числовых типов www.mql5.com Стандартные константы, перечисления и структуры / Именованные константы / Константы числовых типов - Документация по MQL5 Rashid Umarov 2010.11.29 11:34 #2118 Ashes: 也许应改为 "有10个交易的单次运行当然会比有100,000个交易的运行花费更少的时间，因为测试器中的每个交易都需要时间来处理。 纠正了。 Rashid Umarov 2010.11.29 11:35 #2119 Ashes: 我同意关于蜱虫的说法。但是，请再次注意交易数量--那里的时间增加显然不是线性的，形成的测试报告是完全没有问题的! 以相同的点数和不同的交易数量 进行运行。然后你可以进行比较。 Документация по MQL5: Торговые функции / HistoryDealsTotal www.mql5.com Торговые функции / HistoryDealsTotal - Документация по MQL5 Oleg Tsarkov 2010.11.29 13:34 #2120 在测试过程中，出现了一些问题，我展示了在同一时间拍摄的照片。从图中可以看出，只有三个核心在工作，不止一次面临这样的情况，在测试过程中，参与工作的核心数量逐渐下降到零，然后一下子进入工作状态，也就是出现了停机，为什么被解放的核心不立即开始工作？ 运行次数被定义为287次，不过优化结果是这样显示的。那么这些数字意味着什么呢？ 优化图中的点的数量也约为381... 1...205206207208209210211212213214215216217218219...3184 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
是的，没错，只是以标准函数的形式来优化访问速度。
我认为我们还不能谈论速度，尤其是MQL5处理现有的新闻数据阵列很快。而这是在希望MQL会更快的情况下。
但我想详细说明一下这个问题。我想知道你之后打算如何处理这些数据？
我认为我们还不能谈论速度，尤其是MQL5处理现有的新闻数据阵列很快。并希望MQL会更快。
但我想详细说明这一点。我想知道他们以后打算如何处理这些数据？ 具体的使用实例？
而接下来是一个热门领域，之前的新闻是无法正常获得的，那么新闻策略的编码将蓬勃发展。
我打算在国家统计委员会中一直使用它，但我想进一步发展这个课题。
ZZZY 但只要新闻在测试器中不会出现（即新闻故事），它将不得不通过文件来做，并解析第三方资源上的新闻。
随着交易数量的增加，测试器的速度也会减慢。
当以每2分钟1次交易的强度开仓时，你可以看到（日志标签），在相当长的时间内，1秒的测试时间比测试开始时少了几倍。在以Open XML格式输出测试结果 时也有类似情况。
实际上，测试时间并不直接取决于交易量。 确切地说，有10个交易的单次运行当然比有100 000个交易的运行所需时间要短，因为测试器中的每个交易都需要时间来处理。
但是，对测试时间影响最大的是在一个通道中被处理的蜱虫数量。我从一个月开始在所有刻度模式下运行标准的移动平均线（区间2009.01.01-2009.02.01），每次增加一个月的测试时间，达到22个月。
从图中你可以看到，测试时间对刻度数的依赖是严格的线性关系。
你好，反映出增加了构造
#property tester_indicator " indicator.ex5"
在文档中，在iCustom函数的描述中。我花了几个小时试图了解为什么iCustom在图表中能工作，但在测试器中却不能工作的原因。
这在程序属性 部分有描述。
测试员_指示器
绳子
自定义指标的名称，格式为"indicator_name.ex5" 。如果相应的参数被指定为常量字符串，测试所需的指标将从iCustom() 函数调用中自动确定。对于其他情况（使用IndicatorCreate()函数或在定义指标名称的参数中使用非恒定字符串），我们需要这个属性
测试员文件
绳子
测试器的文件名，指定其扩展名，用双引号括起来（作为一个常量字符串）。 指定的文件将被传递给测试人员进行操作。 如果需要，必须始终指定用于测试的输入文件
测试员资料库
绳子
带扩展名的图书馆名称，用双引号括起来。一个库可以同时拥有dll扩展名和ex5扩展名。 测试所需的库被自动检测。然而，如果一个库被一个自定义 指标所使用，就应该使用这个属性
但你是对的，你需要在相关的地方再次明确地添加有关信息。
实际上，测试时间并不直接取决于交易的数量。确切地说，有10个交易的单次运行当然会比有100 000个交易的运行花费更少的时间，因为测试器中的每个交易都需要时间来处理。
但是，对测试时间影响最大的是在一个通道中被处理的蜱虫数量。我从一个月开始在所有刻度模式下运行标准的移动平均线（区间2009.01.01-2009.02.01），每次增加一个月的测试时间，达到22个月。
从图中可以看出，测试时间对刻度数的依赖是严格的线性关系。
也许，我应该说 "一次运行10个交易，当然比运行100 000个交易所需的时间少，因为测试器中的每个交易都需要时间来处理。
我同意关于蜱虫的说法。但要准确地注意交易的数量--那里的时间增长显然不是线性的，形成一个测试报告是完全不可能的!
在EventSetTimer( )中可以设置的最大时间是什么？
INT_MAX？ 我不这么认为。我不想自己去调查，帮助中也没有。
也许应改为 "有10个交易的单次运行当然会比有100,000个交易的运行花费更少的时间，因为测试器中的每个交易都需要时间来处理。
我同意关于蜱虫的说法。但是，请再次注意交易数量--那里的时间增加显然不是线性的，形成的测试报告是完全没有问题的!
在测试过程中，出现了一些问题，我展示了在同一时间拍摄的照片。
从图中可以看出，只有三个核心在工作，不止一次面临这样的情况，在测试过程中，参与工作的核心数量逐渐下降到零，然后一下子进入工作状态，也就是出现了停机，为什么被解放的核心不立即开始工作？
运行次数被定义为287次，不过优化结果是这样显示的。
那么这些数字意味着什么呢？ 优化图中的点的数量也约为381...