MetaTrader 5 позволяет во встроенном тестере стратегий моделировать автоматическую торговлю с помощью экспертов на языке MQL5. Такое моделирование называется тестированием экспертов, и может проводиться с использованием многопоточной оптимизации и одновременно по множеству инструментов. Для проведения тщательного тестирования требуется генерировать тики на основе имеющейся минутной истории. В статье дается подробное описание алгоритма, по которому генерируются тики для исторического тестирования в клиентском терминале MetaTrader 5.
亚历克斯，他们为什么不把多币种作为基本模式，让那些不需要的人去求DC，通过砍掉同步条来缩短他们的历史。
如果我想把终端作为单一货币的MQ使用，我就会错过多货币模式，问题就在于我把它定位为多货币的MQ，因此所有问题都随之而来。
模型或测试模型与此有什么关系？
该平台的意义在于明确接收和存储终端中的初始信息，其数量与服务器接收的信息相同。
开发商可能不会给出任何不偏不倚的信息!有多少关于蜱虫的信息就有多少。
如果多币种测试模型意味着每分钟都有一条，这不是服务器的模型，这是测试人员的模型。
如果 建立指标的模式意味着每分钟都有一个条形的存在，那么它就不是一个服务器工作模式，而是一个测试员 工作模式。
你不必乞求开发者改变服务器 以适应他们的历史认知或测试模型，这没有建设性。
如果你需要缺失的历史分钟，你必须要求你的经纪公司将每一个缺失的分钟的条形图添加到他们的历史中，并有一个单量。
要求你的经纪人绕过Metaquotes的拐杖？同样的拐杖也适用于单打。
你是否需要服务器将分栏的开始时间不是存储在:00秒，而是存储在第一个刻度到达的时间，例如:05或:24？
如果这就是你所需要的，而且这将解决很多测试问题--终端和你的测试人员的质量会提高很多吗？ 这样的几秒钟的偏移对于多货币测试来说是至关重要的吗？
不要忘了，测试者是用tick volume来模拟 一个柱子内的所有价格。如果第一个虱子如期而至，而其他所有的虱子都不像现实生活中那样出现，你会得到很多吗？
如果这种转变对下一个刻度没有影响，那么这种转变到底是为了什么？为了第一个正确的刻度？
在我看来，不对真实的蜱虫历史 进行测试--考虑到第一个蜱虫的真实时间和对随后的蜱虫进行建模--是一种想象的好处。
模型或测试员模型与此有什么关系？
该平台的意义在于明确接受并将原始信息按其出现和来到服务器的数量存储在终端。
开发商是不允许赠送任何东西的!蜱虫的信息量与收到的信息量相同--没有多一个字节，也没有少一个字节。
如果多币种测试模型意味着每分钟都有一个酒吧，这不是服务器的模型，这是测试人员的模型。
如果 建立指标的模型意味着每分钟都有条形的存在，那就不是一个服务器模型，而是指标 的模型
不要去乞求开发者改变服务器 以适应他们的历史认知或测试模型，这不是建设性的。
如果你需要缺失的历史分钟，那么你应该要求--你的DC，他们把每一个缺失的分钟的条形图添加到他们的历史中，并以单位体积为单位。
我们根据所需的思维过程来虚构事实 :)
服务器传输刻度，你在哪里看到刻度历史？
另一方面，终端接收历史记录，这是由服务器存储的，但为什么认为以这种格式在服务器上存储历史记录是正确的，而不是以同步条的形式？
为什么服务器本身没有频率发生器？
为什么按时间切条被认为是正确的，而引入频率发生器就不再正确了呢？
那我们就把时间完全去掉，改成十字和零。那里基本上没有时间的概念。
你想让服务器不在:00秒内存储分栏的开始时间，而是在第一个刻度的时间存储，例如:05或:24？
不，这不是关于那个。唯一要做的是使条形图的开盘价与一分钟开盘时真实账户上的价格相对应。也就是说，测试者在显示分时开盘的条形图的开盘价时不应该说谎。
这种几秒钟的转变对测试多货币专家顾问系统至关重要吗？
是的，它是，因为它导致了明显的不同步。例如，它在开盘价的几个相关符号之间创造了几乎恒定的套利局面。
不要忘了，测试者使用tick volume对一个条形图内的所有价格进行建模 。如果第一个虱子如期而至，而其他所有的虱子与现实生活中的虱子完全不一样，你会有多大收获？
比以前要多得多--同步将不仅是收盘价之间，也是开盘价之间。此外，多货币条将被同步化，这将在优化过程中释放出大量的计算资源，现在这些资源被花在每一次的相同操作上--同步。
在我看来，如果不对真实的tick历史 进行测试--考虑到第一个tick的真实时间并模拟接下来的tick--就是一个想象中的利润。
储存多币种历史的任务与储存视频的任务非常相似。你需要存储一个有效的同步框架，并保存其中的变化。
目前，根本没有同步框架，只有同步线。每一行（货币对）都存储其变化，甚至各行都没有同步点。
我们不能可靠地说，价格正是在这一点上（酒吧开业）。
由于条形图开盘时间为xx:yy:00，开盘时间为xx:yy:12。
由于酒吧开业时间为xx:yy:00，开业时间为xx:yy:12。
为了以这种方式存储，你需要投入大量的精力来说服开发商，让他们相信这样做是正确的，每个人都会受益。
但这是可行的（我指的是技术方面）。 你只需要说服他们重写服务器引擎（也包括终端引擎）来存储和处理酒吧 :)
在这种情况下，更多的阻力（80%）将在说服的第一个阶段。而在那之后，就取决于程序员了。
愿Veles和Ganesh帮助他们
你不能可靠地说在这一点上（酒吧开业），价格正好在那里。
因为酒吧开业时间是xx:yy:00，开业时间是xx:yy:12。
如果你只针对收盘价，你可以。但要做到这一点，你需要跟踪分钟（而不是条形）收盘事件，将Close[1]作为当前价格。
这样的变通方法完全是开发者使用的人为拐杖，但这是一个后门解决方案。
即使开发人员改变了情况，模拟的Ask价格仍然会给出不同步的情况，在测试器中的真实和多货币分析都是如此。
是的，因为它给出了严重的不同步性。例如，它在几个相互关联的符号之间创造了一个几乎恒定的 开盘价 的套利局面。
...这其实并不存在，但测试者在测试者中产生了套利存在的错觉。
对吗？
...这并不真正存在，但测试者给人的错觉是仲裁存在。
对吗？
很对。现实生活中没有套利，而测试者在看似准确（不是模拟）的历史数据上显示套利价格--开盘价。
这不是好事...
在这里，我脑子里总觉得应该避免多币种分析，否则会被耙子打到额头。看来，我避开它是有原因的。