文章 "通用的之字转向指标"
既然我们终于有了一个 OOP 指标，既然我们可以在 Expert Advisor（iCustom）中创建一个计算指标对象，并通过特定运算符 [] 访问顶点，那么从 Expert Advisor（iCustom）中调用它又有什么意义呢？这样应该更快。
源数据中的刻度不够。也许，现在所有的文章（CopyTicks 的实现看起来既快又没有漏洞）都应该考虑到这一事实。我们不能假装只有条形图。
感谢您的文章。对于初学者来说，这可能是最好的。
1.既然我们终于有了一个 OOP 指标，既然我们可以在 Expert Advisor（iCustom）中创建一个计算指标对象，并通过某个运算符 [] 访问顶点，那么从 Expert Advisor（iCustom）中调用它又有什么意义呢？这样应该更快。
2.源数据中的刻度不够。也许，现在所有的文章（CopyTicks 的实现看起来既快又没有漏洞）都应该考虑到这一事实。我们不能假装只有条形图。
3.对于文章 谢谢。对于初学者来说，这可能是一篇好文章。
1. 这是一个错误的想法。该指标使用指标缓冲区 以及参数 rates_total 和 prev_calculate。指标的关键在于使用缓冲区。Expert Advisor 中没有指标缓冲区以及 rates_total 和 prev_calculate。
2.我不同意。这是个人问题。一般来说，重点只是我们应该在每个条形图上重新计算刻度。
3.这就产生了一个哲学问题--谁是初学者？
1. 这是一个错误的想法。该指标使用指标缓冲区 以及参数 rates_total 和 prev_calculate。指标的关键在于使用缓冲区。Expert Advisor 中没有指标缓冲区，也没有 rates_total 和 prev_calculate。
为什么 ZZ 对象不能成为 Expert Advisor 的正式数据源？要创建不同的实体（不同的程序），然后通过 iCustom 将它们连接起来 - 直接在 Expert Advisor 中创建对象更容易。细节 "越少，"机制 "就越可靠。
但这可能是一个永恒的争论。OOP 只会使其更加偏向一方。
2.我不同意。这是个人问题。不管怎么说，问题的关键在于刻度线应该在每个条形图上重新计算。
给定的刻度应被忽略。
3.一个哲学问题出现了--谁是初学者？
1.为什么 ZZ 对象不能成为 Expert Advisor 的完整数据源？要创建不同的实体（不同的程序），然后通过 iCustom 将它们连接起来 - 直接在 Expert Advisor 中创建对象会更容易。细节 "越少，"机制 "就越可靠。
2.但这可能是一个永恒的争议。OOP 只会使其更加偏向一方。
3.给了忽略的勾选。
谁可能从本文中受益？1.OOP 与解决这个问题毫无关系。此外，智能交易系统最完整的数据源是指标。Expert Advisor 不具备指标所具备的处理时间序列的功能。
2.2. OOP 的问题在于，许多成年程序员小时候没有学习过 OOP，因此很难理解和应用它。
3.刻度线图在哪里？必须有刻度线图。如果没有刻度线图，在刻度线图上创建指标 就是一个手工操作的过程。
4.对每个人都有用。这就是之字形的精髓：)在我看来，这篇文章的价值并不在于其中应用了 OOP。在我看来，文章的价值并不在于其中应用了 OOP。但文章的开头部分，即通过 "hi-lo "和 "cloze "创建指示器的部分，值得每个人阅读（除了极少数例外情况）。
1.OOP 与这个问题的解决无关。此外，对于 Expert Advisor 而言，最完整的数据来源是指标。Expert Advisor 不具备指标所提供的处理时间序列的功能。
至少有一个论点。他们唯一喜欢重复的是，在进入 OnCalculate 时，保证在指标中准备好时间序列。而 OnTick 并没有这样的保证。在 OnTick 中只有 99.99999999%，而不是 100%。
2.2. OOP 的问题在于，许多成年程序员小时候并没有学习过 OOP，因此很难理解和应用它。
指标就是一个对象。OOP 也允许创建对象。但不能以单独程序的形式创建额外的实体。
3.刻度线图在哪里？必须有刻度线图。如果没有刻度线图，在刻度线图上创建指标 就是一个手工过程。
刻度线图和刻度线形式的初始数据有什么关系？智能交易系统并不关心是否有图表。如果一个指标能够分析刻度线的历史，就意味着它是建立在刻度线基础上的。缺乏可视化是对 VPS 的一种问候。也就是说，在某些情况下并不需要可视化。
4.对每个人都有用。这就是人字形的精髓：)在我看来，这篇文章的价值并不在于其中应用了 OOP。在我看来，这篇文章的价值并不在于其中应用了 OOP。但文章的开头部分，即通过 "hi-lo "和 "cloze "创建指示器的部分，值得每个人阅读（除了极少数例外情况）。
至少有一个参数。他们唯一喜欢重复的是在进入 OnCalculate 时保证在指标中准备好时间序列。而在 OnTick 中却没有这种保证。在 OnTick 中只有 99.99999999%，而不是 100%。
指标是一个对象。OOP 也允许创建对象。但不要以单独程序的形式创建额外的实体。
刻度线图和刻度线形式的初始数据有什么关系？Expert Advisor 并不关心是否有图表。如果一个指标能够分析刻度线的历史，就意味着它是基于刻度线的。缺乏可视化是对 VPS 的问候。也就是说，在某些情况下并不需要它。
我马上就说了--适合初学者。1. 这是一个错误的想法。该指标使用指标缓冲区 以及参数 rates_total 和 prev_calculate。指标的关键在于使用缓冲区。Expert Advisor 中没有指标缓冲区，也没有 rates_total 和 prev_calculate。
德米特里，你错了。绕过 iCustom，通过类使用 Zig Zag 的想法是非常正确的。事实上，"之 "字形是一个线条列表，每条线条都有很多属性：
- 线条方向（向上/向下）
- 线开始所在条目的索引；
- 该线结束所在柱形的指数；
- 线开始的价格
- 线条结束时的价格；
- 线开始时间；
- 线结束时间；
- ...
我们需要创建一个类，自动计算所有可能的信息，并直接输入到智能交易系统或指标中，而不是通过缓冲区处理两位信息：有线或无线。同时，单个类应能处理不同类型的数据，例如条形图、收盘价或刻度线流。
总结：这对初学者很有用。但使用 OOP 还是会吓跑他们。
附注：在所有技术文献中，只有面向初学者的教科书才能成为畅销书。
根据定义，专家的作品不可能成为畅销书，因为专家很少。
为了以防万一，我不把自己算作专家。这篇文章是写给刚刚开始掌握或即将掌握的人看的。这很好。
为了正确理解，我将提供两篇文章的链接。
- 2016.10.06
- //www.mql5.com/en/users/marketeer">
- www.mql5.com
德米特里，你错了。绕过 iCustom，通过一个类来处理 "之 "字形的想法是非常正确的。从本质上讲，"之 "字形是一个线条列表，每个线条都有很多属性：
- 线条方向（向上/向下）
- 线开始所在条目的索引；
- 该线结束的条形图的指数；
- 线开始的价格
- 线条结束的价格；
- 线开始时间
- 线结束时间；
- ...
1.与通过缓冲区处理两位信息（有线或无线）相比，有必要创建一个类，自动计算所有可能的信息，并方便地直接输入到智能交易系统或指标中。同时，单个类应能处理不同类型的数据，例如条形图、收盘价或刻度线流。
2.总结：这对初学者很有用。但使用 OOP 还是会吓跑他们。
1.不会。这只是对指标的一个小修改。这篇文章已经够大了。我曾有过另写一篇文章的想法，就是为了做这样一个补充，并考虑建立一个求解公式的类（你会得到一个具有识别模式功能的人字形，其公式会写在属性窗口中）。但拉希德对这个话题并不感兴趣。而且一篇文章不可能囊括所有内容。如果有人注意到的话，我还有一个 "之 "字形的变体（基于从上一个最大/最小值开始的回撤），但文章中没有提到。
此外，这篇文章仍然涉及直接访问顶点值的方法。一般来说，OOP 与这个问题的关系非常间接，只是用什么包装它的问题，而且不用 OOP 也能解决这个问题，只需在顶点出现时，将它们按顺序放入一个额外的缓冲区，并在缓冲区的开头写入它们的编号。在这种情况下，访问任何顶点都只需两步--获取顶点的 数量和从末端获取给定的顶点。在接近顶点时，会出现类似 "之 "字形的情况（因为新射线会被取消），但这是可以解决的。但 OOP 与此有关吗？
2.为了防止有人被 OOP 吓到，本文由两部分组成，在 OOP 之前（创建两个指示器）--了解如何写之字形就足够了。
新文章 通用的之字转向指标已发布：
之字转向指标(ZigZag)是在 MetaTrader 5 用户中最流行的指标之一，本文分析了创建各种版本的之字转向指标的可能性，结果是一个可以使用各种方法扩展其功能的通用指标，它对EA交易和其他指标的开发会非常有用。
之字转向指标(图1)是在 MetaTrader 5 用户中最流行的指标之一，现今已经开发出了多种多样的之字转向指标。然而，它们其中的一些非常慢，这使得无法把它们用于创建EA交易。其他一些经常出错，这让用它们作观察都非常困难。对于那些运行速度快而且没有错误的指标，在使用它们开发EA交易或者另外的指标时使用还比较复杂，出现这种情况是因为展开和解释之字转向指标的数据还不是那么容易。
图 1. 之字转向(ZigZag)指标
作者：Dmitry Fedoseev