支持MG4脚本和顾问的测试人员 - 页 10 1...34567891011 新评论 [删除] 2014.11.17 15:47 #91 Renat:我没有这么说。我根本没有触及这个话题，也不打算参与。显然，在我看来。雷纳特。而综合的止损点和止盈点实际上是虚拟的，在时机成熟时被抛出，在市场上执行。这种解决方案有好的一面--它节省了CS（抵押品、保证金）。 上述问题已被补充。 Vasiliy Sokolov 2014.11.17 15:54 #92 Renat:想一想新的数据访问功能提供了什么，为什么会这样。MetaTrader 4的历史深度有限，有独立的时间框架，可以通过开盘/高/低/收盘/时间[xxx]直接访问其符号的条形图。这种直接访问在资源和CPU成本方面的实现非常昂贵。考虑到每个专家顾问都有自己的该数据的本地拷贝，以避免与其他专家顾问和终端本身的冲突。当符号数量增加时（例如，在MT5中，你可以有5 000-10 000个符号），并使用一分钟的深度历史作为所有时间框架的基础，原则上不再可能使用MT4的方法。没有足够的内存，而且复制大块的数据会影响性能。这就是为什么MT5不再为每个ecpert自动维护一个隐藏的、昂贵的图表副本。相反，我们已经转向了非常经济的CopyXXX函数，在这个函数中，开发者正好向本地数组请求他需要的数据，而不是整个可用的图表。接下来是最快的本地数据处理（而不是以前相当昂贵的Open/High/Low/Close/Time[xxx]），另外作者可以缓存这些数据，并在下次调用时节约使用。内存和CPU的节省是巨大的。此外，该平台本身对管理庞大的数据库特别放手--对它们的访问总是按需进行的（而不是无监督的直接访问），这允许对缓存进行灵活管理。还应注意的是，MQL4中的Open/High/Low/Close/Time[xxx]调用的简单性仅限于当前符号和时间框架，其他符号和时间框架的所有其他数据都是使用iClose/iLow(...)函数获得的，这造成了严重的延迟。在MQL5中过渡到一个单一的CopyXXX函数模型，从根本上改善了这种情况，允许开发人员通过一个请求获得所需的数据块，而不需要进行多次阻塞调用（想想每次调用iClose时的所有阻塞）。...CopyXXX的性能如何？在节省内存方面--没有问题。但是，为每个tick 调用CopyXXX比把一个数组的报价复制到缓冲区一次，并通过Rates[X]类型的直接索引访问它更昂贵。这里我们有一个经典的编程困境："节省内存与节省CPU时间"。 [删除] 2014.11.17 17:50 #93 lob32371:不亚于MT5。现在向自己提出同样的问题，只是把B换成A。去学习什么是MARKET!交易员，你知道....所以你是说，MT4可以，比如说，存储点差历史或 "知道 "真实交易量（没有所有的拐杖和其他完全不合适的解决方案）？你是否同意，在真实的市场上，价差显然不是固定的？在MT4测试器中尝试在可变点差的报价上测试该EA，然后我们再谈。 [删除] 2014.11.17 17:58 #94 RickD:我并不像关心世界其他地方那样关心具有复杂逻辑的专家的发展利益。;)折中的解决方案是在MT5层面组织虚拟订单。那么既会有有人需要的网状物，也会有与订单合作的旧逻辑。你会承担这种 "可视化 "的风险吗？在MT5中，每个想做的人都长期使用这种解决方案，用具有高度关联性的不同工具的交易进行对冲。是的，这可能需要比MT4多得多的保证金，但常识告诉我们这是正确的。当然，在这种情况下，没有人取消 "虚拟 "计划。 [删除] 2014.11.17 18:21 #95 Interesting:那么你是说，MT4可以，比如说，存储点差历史或 "知道 "真实交易量（没有所有的拐杖和其他不适当的解决方案）？你是否同意，在真实的市场上，价差显然不是固定的？在MT4测试器中尝试在点差变化的情况下测试该EA，然后我们再谈。 我和你之间有一条不可逾越的鸿沟。你只是在浪费你的时间，祝你好运! [删除] 2014.11.17 21:49 #96 Interesting:你会承担这种 "视觉化 "的风险吗？在MT5中，每个想要的人都在使用对冲方案，通过使用具有高度相关性的不同工具的交易。感谢上帝，现在还有MT4。:)如果你愿意，你可以在一件乐器上使用它。你可以使用不同的工具。你认为有什么风险？ Renat Fatkhullin 2014.11.18 08:26 #97 C-4:CopyXXX的性能如何？在节省内存方面--没有问题。但是，为每个tick调用CopyXXX比把一个数组的报价复制到缓冲区一次并通过Rates[X]类型的直接索引来访问它更昂贵。这里我们有一个经典的编程困境："节省内存与节省CPU时间"。CopyXXX的速度 与iClose/iOpen/iXXXX功能相同。只有iXXX一次返回一个元素，而CopyXXX返回许多元素，因此效率更高，速度更快。也许，您没有考虑到，在每个tick处理程序启动之前， MT4会将 本地图表的所有历史记录强行复制到 本地（缓存）EA的市场环境中。而这是非常昂贵的，尽管我们有一种方法可以经济地更新这些信息。MQL4中的特殊函数RefreshRates 会导致强制刷新本地图表的缓存和历史。调用CopyXXX的效率更高，开发者有一个非常准确和精确的机制来缓存以前请求的数据。例如，你不需要在每次勾选时重新请求深层历史，而是将其存储/写入本地，并尽可能快地访问它。如果我们比较一下 "直接"（实际上不是直接访问）访问Open/High/Low/Close的老方法和使用本地数组double local[xxxx]的工作，后者要快很多倍。因此，最好是复制到自己本地，然后在本地快速访问重复查询的数据。 [删除] 2014.11.18 09:56 #98 RickD:感谢上帝，现在有了MT4。:)有了它，你可以一次使用一种乐器。你可以使用不同的工具。你认为有什么风险？在开发/使用 "交易平台 "时，存在一定的成本和风险，最终有人承担了这些风险。至于其他开发商的软件中的 "虚拟化 "问题这是一件好事，只要一切都为自己所用，而且实施解决方案的人明白他们在做什么。主要成本将是：开发系统的钱，保持系统运行的钱和实施项目 的时间。主要风险：为实施一个可行的项目将花费太多的时间或金钱（项目不会有回报），与其他解决方案相比，项目不会有效，在项目实施过程中会出现代码或算法的隐藏错误。是的，银行和其他市场参与者求助于开发具有必要功能的软件，但他们花费了大量的时间和资源。同时，他们绝对承担所有的风险。关于MT5的工作（使用MT5的不同变体）这里当然是MQ做了大部分的工作，但也引入了对功能的某些限制。主要的成本将是：为维持系统的性能所花的钱和实施项目的时间。主要风险：与其他解决方案相比，项目的效率不高，在实施项目时，代码或算法中会有隐藏的错误，你必须不断监测整个系统的性能（保护它不受软件和硬件问题的影响；监测通信质量、电力供应、数据安全等）。 当然，你可以考虑商业应用（允许其他人使用），有一定的限制和注意事项。 [删除] 2014.11.18 13:09 #99 Vinin: 我想看一看这里有一个例子，在编写简单程序时，你可以特别看到OOP的简单性和易用性。 Victor Nikolaev 2014.11.18 14:13 #100 lob32371:这里有一个例子，在编写简单程序时，OOP的简单性和易用性特别明显。 这不是一个指标 1...34567891011 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
我没有这么说。
我根本没有触及这个话题，也不打算参与。
显然，在我看来。
而综合的止损点和止盈点实际上是虚拟的，在时机成熟时被抛出，在市场上执行。这种解决方案有好的一面--它节省了CS（抵押品、保证金）。
想一想新的数据访问功能提供了什么，为什么会这样。
MetaTrader 4的历史深度有限，有独立的时间框架，可以通过开盘/高/低/收盘/时间[xxx]直接访问其符号的条形图。这种直接访问在资源和CPU成本方面的实现非常昂贵。考虑到每个专家顾问都有自己的该数据的本地拷贝，以避免与其他专家顾问和终端本身的冲突。
当符号数量增加时（例如，在MT5中，你可以有5 000-10 000个符号），并使用一分钟的深度历史作为所有时间框架的基础，原则上不再可能使用MT4的方法。没有足够的内存，而且复制大块的数据会影响性能。这就是为什么MT5不再为每个ecpert自动维护一个隐藏的、昂贵的图表副本。
相反，我们已经转向了非常经济的CopyXXX函数，在这个函数中，开发者正好向本地数组请求他需要的数据，而不是整个可用的图表。接下来是最快的本地数据处理（而不是以前相当昂贵的Open/High/Low/Close/Time[xxx]），另外作者可以缓存这些数据，并在下次调用时节约使用。内存和CPU的节省是巨大的。此外，该平台本身对管理庞大的数据库特别放手--对它们的访问总是按需进行的（而不是无监督的直接访问），这允许对缓存进行灵活管理。
还应注意的是，MQL4中的Open/High/Low/Close/Time[xxx]调用的简单性仅限于当前符号和时间框架，其他符号和时间框架的所有其他数据都是使用iClose/iLow(...)函数获得的，这造成了严重的延迟。在MQL5中过渡到一个单一的CopyXXX函数模型，从根本上改善了这种情况，允许开发人员通过一个请求获得所需的数据块，而不需要进行多次阻塞调用（想想每次调用iClose时的所有阻塞）。
...
CopyXXX的性能如何？
在节省内存方面--没有问题。但是，为每个tick 调用CopyXXX比把一个数组的报价复制到缓冲区一次，并通过Rates[X]类型的直接索引访问它更昂贵。这里我们有一个经典的编程困境："节省内存与节省CPU时间"。
不亚于MT5。现在向自己提出同样的问题，只是把B换成A。
去学习什么是MARKET!交易员，你知道....
所以你是说，MT4可以，比如说，存储点差历史或 "知道 "真实交易量（没有所有的拐杖和其他完全不合适的解决方案）？
你是否同意，在真实的市场上，价差显然不是固定的？在MT4测试器中尝试在可变点差的报价上测试该EA，然后我们再谈。
我并不像关心世界其他地方那样关心具有复杂逻辑的专家的发展利益。;)
折中的解决方案是在MT5层面组织虚拟订单。那么既会有有人需要的网状物，也会有与订单合作的旧逻辑。
你会承担这种 "可视化 "的风险吗？
在MT5中，每个想做的人都长期使用这种解决方案，用具有高度关联性的不同工具的交易进行对冲。
是的，这可能需要比MT4多得多的保证金，但常识告诉我们这是正确的。
当然，在这种情况下，没有人取消 "虚拟 "计划。
那么你是说，MT4可以，比如说，存储点差历史或 "知道 "真实交易量（没有所有的拐杖和其他不适当的解决方案）？
你是否同意，在真实的市场上，价差显然不是固定的？在MT4测试器中尝试在点差变化的情况下测试该EA，然后我们再谈。
你会承担这种 "视觉化 "的风险吗？
在MT5中，每个想要的人都在使用对冲方案，通过使用具有高度相关性的不同工具的交易。
感谢上帝，现在还有MT4。:)如果你愿意，你可以在一件乐器上使用它。你可以使用不同的工具。
你认为有什么风险？
CopyXXX的性能如何？
在节省内存方面--没有问题。但是，为每个tick调用CopyXXX比把一个数组的报价复制到缓冲区一次并通过Rates[X]类型的直接索引来访问它更昂贵。这里我们有一个经典的编程困境："节省内存与节省CPU时间"。
CopyXXX的速度 与iClose/iOpen/iXXXX功能相同。只有iXXX一次返回一个元素，而CopyXXX返回许多元素，因此效率更高，速度更快。
也许，您没有考虑到，在每个tick处理程序启动之前， MT4会将 本地图表的所有历史记录强行复制到 本地（缓存）EA的市场环境中。而这是非常昂贵的，尽管我们有一种方法可以经济地更新这些信息。MQL4中的特殊函数RefreshRates 会导致强制刷新本地图表的缓存和历史。
调用CopyXXX的效率更高，开发者有一个非常准确和精确的机制来缓存以前请求的数据。例如，你不需要在每次勾选时重新请求深层历史，而是将其存储/写入本地，并尽可能快地访问它。
如果我们比较一下 "直接"（实际上不是直接访问）访问Open/High/Low/Close的老方法和使用本地数组double local[xxxx]的工作，后者要快很多倍。因此，最好是复制到自己本地，然后在本地快速访问重复查询的数据。
感谢上帝，现在有了MT4。:)有了它，你可以一次使用一种乐器。你可以使用不同的工具。
你认为有什么风险？
在开发/使用 "交易平台 "时，存在一定的成本和风险，最终有人承担了这些风险。
至于其他开发商的软件中的 "虚拟化 "问题
这是一件好事，只要一切都为自己所用，而且实施解决方案的人明白他们在做什么。
主要成本将是：开发系统的钱，保持系统运行的钱和实施项目 的时间。
主要风险：为实施一个可行的项目将花费太多的时间或金钱（项目不会有回报），与其他解决方案相比，项目不会有效，在项目实施过程中会出现代码或算法的隐藏错误。
是的，银行和其他市场参与者求助于开发具有必要功能的软件，但他们花费了大量的时间和资源。同时，他们绝对承担所有的风险。
关于MT5的工作（使用MT5的不同变体）
这里当然是MQ做了大部分的工作，但也引入了对功能的某些限制。
主要的成本将是：为维持系统的性能所花的钱和实施项目的时间。
主要风险：与其他解决方案相比，项目的效率不高，在实施项目时，代码或算法中会有隐藏的错误，你必须不断监测整个系统的性能（保护它不受软件和硬件问题的影响；监测通信质量、电力供应、数据安全等）。
当然，你可以考虑商业应用（允许其他人使用），有一定的限制和注意事项。我想看一看
这里有一个例子，在编写简单程序时，OOP的简单性和易用性特别明显。