使用iClose/iOpen时间序列访问等工作时的MQL5错误。 - 页 2 12345678910 新评论 Renat Fatkhullin 2018.11.14 11:06 #11 Stanislav Dray:那么请告诉我,为什么冻结会发生在我的案例中?在指标轮询功能之前,我在OnTick中冻结了数据,即M1的CopyTime更新作为触发器开始OnTick中的其他处理,而在CopyTime之前没有任何功能或指标轮询。 而为什么在30日之前没有这样的问题,而从2017年10月开始,一切工作都很正常?请按我的建议去做。 否则需要完整的材料来实现100%的播放。 חולםטרנסצנדר ᨖ 2018.11.14 11:21 #12 为什么开发人员不写一个函数来保证数据的同步数组(跨越几个工具),这样人们就不用费心,白白浪费时间了? 毕竟MT5被定位为一个很酷、很方便的工具,对吗? 非常期待... Artyom Trishkin 2018.11.14 11:28 #13 Vladimir Karputov:我们也一直建议,如果你在使用别人的时间框架--你应该每分钟从该时间框架获得一次OHLC(任何CopyXXXX功能)。这种情况一直存在。斯拉瓦每两分钟说一次。懒得去找了,但我记得很清楚。 Unicornis 2018.11.14 12:00 #14 transcendreamer:为什么开发人员不写一个函数来保证数据的同步数组(跨越几个工具),这样人们就不用费心,白白浪费时间了? 毕竟MT5被定位为一个很酷、很方便的工具,对吗? 我们正在等待...是的,OnCalculate构造器用于计算所需的符号和时间段的数量。或者,在OnCalculate 之外,引入一个新的对象,例如 "MainCalculate",最大可容纳255个OnCalculate对象--不需要的人使用旧的OnCalculate,需要mtf和不同符号的人使用 "MainCalculate"。条形图的第一个和最后一个刻度对所有符号和重合的时间段都是一样的。因为OnCalculate已经建立并解决了,所以通过OnCalculate聚合输出所有对第三方符号和时间框架的调用是合乎逻辑的,不需要其他函数对时间框架和符号进行调解。 Renat Fatkhullin 2018.11.14 12:08 #15 想一想,当你的指标慢得让人无法忍受,每个刻度线需要几百毫秒甚至几秒钟来接收/布置刻度线时,数据(尤其是保证数据)将在哪里可用。因此,在时间上没有足够的CPU来处理这些刻度线,这就转化为一个不断累积的赤字,并在图表历史中出现相应的停滞。 当你要求 "保证给予 "时,很可能是 "什么都不想知道,想继续按我的意愿写作,不想考虑性能和锁,只要给予 "的要求? 当你有数以百万计的条条框框可用时,想想你和其他人的指标的表现。一个写得不好的、昂贵的指标很容易使其符号图表的更新速度变慢。 对于初学者,开始测量 OnCalculate的响应时间,以微秒为单位。然后用1秒除以平均刻度线响应时间,得到指标的最大分解,单位为每秒刻度线。 这让人立刻清醒过来。 Vladimir Karputov 2018.11.14 12:37 #16 Artyom Trishkin:每两分钟,斯拉瓦说。我懒得去找了,但我记得很清楚。我记得,但我总是用1分钟的时间间隔。这样做更可靠。 Renat Fatkhullin 2018.11.14 12:37 #17 Farkhat Guzairov:对不起,但在这种情况下,M15时间框架的历史深度是120条,怎么,对MQL5来说已经很关键了? 你没有提供任何可复制的材料。 我已经解释了为什么当别人的符号 上有弱智指标时,访问别人的数据的功能会被弱智化。你说的是你的特殊情况下的调用,完全忽略了图表上其他指标的存在。而他们才是你应该开始的,尤其是我明确地写到了这一点。 不要搞妖言惑众,完全没有技术事迹和专家指标清单的比较性发言。 请给我重现的代码。 Vladimir Karputov 2018.11.14 12:52 #18 Farkhat Guzairov:***那么,你如何回放它呢?请给我播放的数据。 Vladimir Karputov 2018.11.14 13:10 #19 Farkhat Guzairov:当然,我不能把整个代码放在这里,但我已经指出了出现问题的部分,所以我再做一次。 要么整个代码,要么什么都不说。没有完整的代码,它只是一个很大的空气。 חולםטרנסצנדר ᨖ 2018.11.14 15:43 #20 Renat Fatkhullin:想一想,当你的指标令人难以忍受地缓慢接收/应用刻度线,为一个刻度线花费数百毫秒甚至数秒时,数据(越是这样越有保证)将在哪里出现。因此,在时间上没有足够的CPU来处理这些刻度线,这就转化为一个不断累积的赤字,并在图表历史中出现相应的停滞。 当你要求 "保证给予 "时,很可能是 "什么都不想知道,想继续按我的意愿写作,不想考虑性能和锁,只要给予 "的要求? 当你有数以百万计的条条框框可用时,想想你和其他人的指标的表现。一个写得不好的、昂贵的指标很容易使其符号的图表更新停滞。 首先测量OnCalculate的响应时间(微秒)。然后用1秒除以平均tick响应时间,得到指标的最大tick吞吐量,单位为每秒tick。 这让人立刻清醒过来。 你并不总是需要超快的速度,可用性是非常重要的,现在编写多货币指标 的过程就像 "手写日落",即使在MT4中也比较容易,因为在那里你总是可以通过i-function得到它,即使很慢,但你可以得到它,但在MT5中,数据要么有,要么没有,你需要自己创造一个特殊的代码。 另外,你应该记住,并不是所有的用户都是高级程序员,有些人只是需要一个方便可靠的工具,即使它不是超音速的,这样的速度通常不是组合系统所需要的,在这种情况下,最大的吞吐量并不关键,重要的是它的工作保证和容易,事实上,这是使产品更受欢迎和容易获得的因素。 mt5中i-functions的出现在一定程度上改善了情况,但它并没有解决问题,没有可能轻松简单地获得几个工具的同步数组,也许这不是每个人都需要的,也许它甚至不是一个优先事项,我可以理解,但尽管如此,还是有这样的任务存在。 函数:GetSyncData 输入:符号列表、时间框架、条形范围和/或日期范围 输出:具有MqlRates元素的数组,以便所有符号的索引对应于同一时间 12345678910 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
那么请告诉我,为什么冻结会发生在我的案例中?在指标轮询功能之前,我在OnTick中冻结了数据,即M1的CopyTime更新作为触发器开始OnTick中的其他处理,而在CopyTime之前没有任何功能或指标轮询。
而为什么在30日之前没有这样的问题,而从2017年10月开始,一切工作都很正常?
请按我的建议去做。
否则需要完整的材料来实现100%的播放。为什么开发人员不写一个函数来保证数据的同步数组(跨越几个工具),这样人们就不用费心,白白浪费时间了?
毕竟MT5被定位为一个很酷、很方便的工具,对吗?
非常期待...
我们也一直建议,如果你在使用别人的时间框架--你应该每分钟从该时间框架获得一次OHLC(任何CopyXXXX功能)。这种情况一直存在。
斯拉瓦每两分钟说一次。懒得去找了,但我记得很清楚。
为什么开发人员不写一个函数来保证数据的同步数组(跨越几个工具),这样人们就不用费心,白白浪费时间了?
毕竟MT5被定位为一个很酷、很方便的工具,对吗?
我们正在等待...
是的,OnCalculate构造器用于计算所需的符号和时间段的数量。或者,在OnCalculate 之外,引入一个新的对象,例如 "MainCalculate",最大可容纳255个OnCalculate对象--不需要的人使用旧的OnCalculate,需要mtf和不同符号的人使用 "MainCalculate"。条形图的第一个和最后一个刻度对所有符号和重合的时间段都是一样的。因为OnCalculate已经建立并解决了,所以通过OnCalculate聚合输出所有对第三方符号和时间框架的调用是合乎逻辑的,不需要其他函数对时间框架和符号进行调解。
想一想,当你的指标慢得让人无法忍受,每个刻度线需要几百毫秒甚至几秒钟来接收/布置刻度线时,数据(尤其是保证数据)将在哪里可用。因此,在时间上没有足够的CPU来处理这些刻度线,这就转化为一个不断累积的赤字,并在图表历史中出现相应的停滞。
当你要求 "保证给予 "时,很可能是 "什么都不想知道,想继续按我的意愿写作,不想考虑性能和锁,只要给予 "的要求?
当你有数以百万计的条条框框可用时,想想你和其他人的指标的表现。一个写得不好的、昂贵的指标很容易使其符号图表的更新速度变慢。
对于初学者,开始测量 OnCalculate的响应时间,以微秒为单位。然后用1秒除以平均刻度线响应时间,得到指标的最大分解,单位为每秒刻度线。
这让人立刻清醒过来。
每两分钟,斯拉瓦说。我懒得去找了,但我记得很清楚。
我记得,但我总是用1分钟的时间间隔。这样做更可靠。
对不起,但在这种情况下,M15时间框架的历史深度是120条,怎么,对MQL5来说已经很关键了?
你没有提供任何可复制的材料。
我已经解释了为什么当别人的符号 上有弱智指标时,访问别人的数据的功能会被弱智化。你说的是你的特殊情况下的调用,完全忽略了图表上其他指标的存在。而他们才是你应该开始的,尤其是我明确地写到了这一点。
不要搞妖言惑众,完全没有技术事迹和专家指标清单的比较性发言。
请给我重现的代码。
***
那么,你如何回放它呢?请给我播放的数据。
当然,我不能把整个代码放在这里,但我已经指出了出现问题的部分,所以我再做一次。
要么整个代码,要么什么都不说。没有完整的代码,它只是一个很大的空气。
想一想,当你的指标令人难以忍受地缓慢接收/应用刻度线,为一个刻度线花费数百毫秒甚至数秒时,数据(越是这样越有保证)将在哪里出现。因此,在时间上没有足够的CPU来处理这些刻度线,这就转化为一个不断累积的赤字,并在图表历史中出现相应的停滞。
当你要求 "保证给予 "时,很可能是 "什么都不想知道,想继续按我的意愿写作,不想考虑性能和锁,只要给予 "的要求?
当你有数以百万计的条条框框可用时,想想你和其他人的指标的表现。一个写得不好的、昂贵的指标很容易使其符号的图表更新停滞。
首先测量OnCalculate的响应时间(微秒)。然后用1秒除以平均tick响应时间,得到指标的最大tick吞吐量,单位为每秒tick。
这让人立刻清醒过来。
你并不总是需要超快的速度,可用性是非常重要的,现在编写多货币指标 的过程就像 "手写日落",即使在MT4中也比较容易,因为在那里你总是可以通过i-function得到它,即使很慢,但你可以得到它,但在MT5中,数据要么有,要么没有,你需要自己创造一个特殊的代码。
另外,你应该记住,并不是所有的用户都是高级程序员,有些人只是需要一个方便可靠的工具,即使它不是超音速的,这样的速度通常不是组合系统所需要的,在这种情况下,最大的吞吐量并不关键,重要的是它的工作保证和容易,事实上,这是使产品更受欢迎和容易获得的因素。
mt5中i-functions的出现在一定程度上改善了情况,但它并没有解决问题,没有可能轻松简单地获得几个工具的同步数组,也许这不是每个人都需要的,也许它甚至不是一个优先事项,我可以理解,但尽管如此,还是有这样的任务存在。
函数:GetSyncData
输入:符号列表、时间框架、条形范围和/或日期范围
输出:具有MqlRates元素的数组,以便所有符号的索引对应于同一时间