组织订单周期 - 页 2 123456789...15 新评论 fxsaber 2017.09.11 20:25 #11 Andrey Khatimlianskii:因为价格会移动，在每一次对OnTick的新调用中，都会满足对相同的、列表中第一个订单的新修改条件。特别是如果修改将持续5秒;)再次触及到相关性的问题。一个订单将永远是最新的。其他的将会是最新的。而你的变体，则是所有的订单都没有更新。这样的 "骨干 "会破坏一个EA在多个订单中工作的逻辑。如果它不会给有一个订单的系统带来任何好处，而且会破坏其他的订单，那还有什么意义呢？我很想理解你的意思，但我不能。我不认为 "如果等待时间已过，就更新交易环境 "的原则有什么问题。在处理订单之前，按成交量和/或与价格的距离进行排序是正确的做法。但我们不应该假设每个从论坛上复制代码的人都会实现它。 从这个意义上说，我的代码是比较安全的。嗯，这不是为新手写的。你和我在这里讨论得很好--没有水。 Andrey Khatimlianskii 2017.09.11 20:44 #12 fxsaber:再次提出相关性的问题。一个订单将永远是最新的。如果可能的话，其他的将会是最新的。你的选择是，所有的订单都不是最新的。实际--多少？2次买入，买入价为1.2345，两者的止损价为1.2344下一交易日：买入价在1.2350，第一单的止损在1.2349，第二单保持在1.2344。没有等待一个刻度：买入价在1.2375，第一个订单的SL被移动到1.2374，第二个订单仍然在那里。再走一步：买入价是1.2376，第一笔订单的SL被移到1.2375，第二笔订单保持原位。价格已经回到了1.2300，两个订单的SL（1.2374和1.2344）已经触发[为了简单起见，假设价格没有飞跃性地达到1.2300（那么两个止损点都会滑落到这个水平），但是价格一直在逐渐上升，但是我们的EA太忙于修改，此时没有时间做任何事情]。结果：第一笔订单+30点，第二笔订单+0点在我的变体中，这两个SL会在1.2375或最坏的情况下，在1.2374被修改。底线：两个订单都是+30点。fxsaber:很高兴能理解你的意思，但这并不可行。我不认为 "如果等待时间已过，就更新交易环境 "的原则有什么问题。你的算法固守在名单上的第一个订单，仅此而已。在某些情况下，这可能会对系统造成损害（我在实践中遇到过这种情况）。 fxsaber 2017.09.11 21:02 #13 Andrey Khatimlianskii:实际--多少？2次买入，买入价为1.2345，两者的止损价为1.2344下一交易日：买入价在1.2350，第一笔订单的止损点移至1.2349，第二笔订单仍在1.2344。没有等待一个刻度：买入价在1.2375，第一个订单的SL被移动到1.2374，第二个订单仍然在那里。再走一步：买入价是1.2376，第一笔订单的SL被移到1.2375，第二笔订单保持原位。价格已经回到了1.2300，两个订单（1.2374和1.2344）的SL已经触发[为了简单起见，假设价格没有飞跃性地达到1.2300（那么两个止损点都会滑落到这个水平），但是价格一直在逐渐上升，但是我们的EA太忙于做出改变，在这个时候没有设法做任何事情]。结果：第一笔订单+30点，第二笔订单+0点在我的变体中，这两个SL会在1.2375或最坏的情况下，在1.2374被修改。底线：两个订单都是+30点。在你的例子中的每一步，TS应该知道它的订单应该在哪里，没有任何交易订单。也就是说，TS不能以任何方式依附于其订单现在的位置。它只处理计算他们应该站在哪里，并通过交易订单使交易环境与它所计算的内容同步。然而，在你的例子中，TS的结果取决于OnTick是否已经到达高价。而正确的TS应该是完全达到这个水平。她看到了这样的价格（即使错过了与之相关的OnTick），因此她的SL应该被相应地放置。而同步化将100%完成其工作。而且我不明白你为什么一直说第二个人是站着不动的。即使没有同步逻辑，它仍然会以与你的变体相同的方式被修改。这不像是在NewTick事件中调用OnTick，而是作为一个正常的内部函数。 Andrey Khatimlianskii 2017.09.12 04:38 #14 fxsaber:在你的例子中的每一步，TS需要知道它的订单在没有任何交易订单 的情况下应该在哪里。也就是说，TS不能以任何方式与订单现在的位置相联系。它只处理计算他们应该站在哪里，并通过交易订单使交易环境与它所计算的内容同步。它确实如此，她知道。但它没有时间去同步--当一个修改正在通过时，价格进一步移动，一个新的计算条件告诉她再次修改第一个订单。而这种情况一直在发生。fxsaber:在你的例子中，TC的结果取决于OnTick是否已经到了高价位。而正确的TS应该正好在这之前。她看到这样的价格是（即使错过了与之相关的OnTick），这意味着她的SL应该被相应地放置。而同步化将100%完成其工作。它没有（在这个例子中，没有SL级别的计算）。而同步化不会做这个工作，因为它没有时间（见上文）。fxsaber:而且我不明白你为什么一直说第二个人站着不动。即使没有同步逻辑，它仍然会以与你的变体相同的方式被修改。这不像是在NewTick事件中调用OnTick，而是作为一个正常的内部函数。像往常一样，我理解它。然而，在修改过程中，价格已经发生了变化，OnTick的强制调用已经对新的价格起作用了，而第二笔订单仍然停留在初始水平。没有错误。也许对你来说太具体了（但同样，相当真实，来自生活）的情况。 fxsaber 2017.09.12 05:53 #15 Andrey Khatimlianskii:它知道，它知道。但它没有时间同步--当一次修改过后，价格进一步移动，新的计算条件告诉它要再次修改第一笔订单。而这种情况一直在发生。考虑到这个逻辑，你所发明的例子并没有给我们带来额外的损失。现在让我给你举个例子。假设我们在向上移动后跟踪买入限价，以便在必要的回撤时开盘。几乎是幸运的-TC。如果我们每次都拖着一座山的Limits，我们就不会用你的选项来抓回调。好吧，基于一个过时的交易环境给出交易指令 是很奇怪的。但你顽固地（像我一样）为不同的观点辩护。 Andrey Khatimlianskii 2017.09.12 06:42 #16 fxsaber:好吧，根据过时的贸易环境发出贸易指令 是很奇怪的。但你顽固地（像我一样）为不同的观点辩护。你必须两害相权取其轻。当然，在 "1个EA=每个方向1个订单 "的变体中，在价格后面伸展限价的例子更好实现。但一般来说，最好是把所有的订单都控制住。 fxsaber 2017.09.12 07:00 #17 Andrey Khatimlianskii:但一般来说，把所有的订单都控制住是比较正确的。也就是说，你不同意TS只在当前的交易环境下工作的要求。 Andrey Khatimlianskii 2017.09.12 08:03 #18 fxsaber:也就是说，你不同意TS只在当前的交易环境下工作的要求。如果你必须牺牲对所有TC订单的控制来做到这一点--当然。想象一下：你有一个由四辆卡车组成的车队。他们中的每一个人都在运送宝贵的货物从A点到B点。你需要监测路线。 你喜欢什么：是每分钟和其中一个人联系，还是每2分钟和所有的人联系？在第二种情况下，延误的时间会稍微长一些，如果你没有及时把它们的路线安排好，所有四个人可能要稍微绕道。但总的来说，这将比拥有一辆卡车而失去其他三辆卡车对企业更有利。 Stanislav Korotky 2017.09.12 08:14 #19 Andrey Khatimlianskii:如果你必须牺牲对所有TC订单的控制权来做到这一点，当然可以。想象一下：你有一个由4辆卡车组成的车队。它们中的每一个都携带着宝贵的货物从A点到B点。你需要控制路线。 你愿意每分钟和其中一个人联系，还是每2分钟和所有的人联系？在第二种情况下，延误的时间会稍长一些，如果你未能及时安排路线，四人可能都要稍作绕行。但总的来说，这将比花费一辆卡车而失去其他三辆卡车对企业更有利。+1.也许用OOP的方法就不会产生新的想法，在OOP的方法中，一个类似于订单蛮力的循环被隐藏在一些类似于经理的实体中，而不是直接调用OrderModify，而是生成一个修改命令（包括所有参数）并把它放到一个队列中，然后被处理。这个想法是在一些分析环境的实体和根据分析执行行动的实体之间划分责任（在这段代码中，责任被塞进一个循环）。 Andrey Khatimlianskii 2017.09.12 08:18 #20 Stanislav Korotky:也许这种想法不会出现在OOP方法中，当一个类似于循环的订单搜索被隐藏在一些实体中，比如经理，它不是直接调用OrderModify，而是生成修改的命令（包括所有参数），并将其放入队列，然后进行处理。这个想法是将责任（在这段代码中，责任被塞进一个单一的循环中）在分析环境的对象和根据分析进行行动的对象之间进行划分。避免这种情况的唯一方法是使用异步订单。否则仍会有一个待执行命令列表的循环，这实际上是一个订单的循环。只有在排队的情况下，你仍然必须做出规定，用较新的订单取代与之相关的较早的未执行的订单。否则，队列可能会溢出，订单会被送出队列--过时的。 123456789...15 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
因为价格会移动，在每一次对OnTick的新调用中，都会满足对相同的、列表中第一个订单的新修改条件。特别是如果修改将持续5秒;)
再次触及到相关性的问题。一个订单将永远是最新的。其他的将会是最新的。而你的变体，则是所有的订单都没有更新。
这样的 "骨干 "会破坏一个EA在多个订单中工作的逻辑。
如果它不会给有一个订单的系统带来任何好处，而且会破坏其他的订单，那还有什么意义呢？
我很想理解你的意思，但我不能。我不认为 "如果等待时间已过，就更新交易环境 "的原则有什么问题。
在处理订单之前，按成交量和/或与价格的距离进行排序是正确的做法。但我们不应该假设每个从论坛上复制代码的人都会实现它。
从这个意义上说，我的代码是比较安全的。
嗯，这不是为新手写的。你和我在这里讨论得很好--没有水。
再次提出相关性的问题。一个订单将永远是最新的。如果可能的话，其他的将会是最新的。你的选择是，所有的订单都不是最新的。
实际--多少？
很高兴能理解你的意思，但这并不可行。我不认为 "如果等待时间已过，就更新交易环境 "的原则有什么问题。
你的算法固守在名单上的第一个订单，仅此而已。
在某些情况下，这可能会对系统造成损害（我在实践中遇到过这种情况）。
实际--多少？
在我的变体中，这两个SL会在1.2375或最坏的情况下，在1.2374被修改。底线：两个订单都是+30点。
在你的例子中的每一步，TS应该知道它的订单应该在哪里，没有任何交易订单。也就是说，TS不能以任何方式依附于其订单现在的位置。它只处理计算他们应该站在哪里，并通过交易订单使交易环境与它所计算的内容同步。
然而，在你的例子中，TS的结果取决于OnTick是否已经到达高价。而正确的TS应该是完全达到这个水平。她看到了这样的价格（即使错过了与之相关的OnTick），因此她的SL应该被相应地放置。而同步化将100%完成其工作。
而且我不明白你为什么一直说第二个人是站着不动的。即使没有同步逻辑，它仍然会以与你的变体相同的方式被修改。这不像是在NewTick事件中调用OnTick，而是作为一个正常的内部函数。
在你的例子中的每一步，TS需要知道它的订单在没有任何交易订单 的情况下应该在哪里。也就是说，TS不能以任何方式与订单现在的位置相联系。它只处理计算他们应该站在哪里，并通过交易订单使交易环境与它所计算的内容同步。
它确实如此，她知道。但它没有时间去同步--当一个修改正在通过时，价格进一步移动，一个新的计算条件告诉她再次修改第一个订单。而这种情况一直在发生。
在你的例子中，TC的结果取决于OnTick是否已经到了高价位。而正确的TS应该正好在这之前。她看到这样的价格是（即使错过了与之相关的OnTick），这意味着她的SL应该被相应地放置。而同步化将100%完成其工作。
它没有（在这个例子中，没有SL级别的计算）。
而同步化不会做这个工作，因为它没有时间（见上文）。
而且我不明白你为什么一直说第二个人站着不动。即使没有同步逻辑，它仍然会以与你的变体相同的方式被修改。这不像是在NewTick事件中调用OnTick，而是作为一个正常的内部函数。
像往常一样，我理解它。
然而，在修改过程中，价格已经发生了变化，OnTick的强制调用已经对新的价格起作用了，而第二笔订单仍然停留在初始水平。
没有错误。也许对你来说太具体了（但同样，相当真实，来自生活）的情况。
它知道，它知道。但它没有时间同步--当一次修改过后，价格进一步移动，新的计算条件告诉它要再次修改第一笔订单。而这种情况一直在发生。
考虑到这个逻辑，你所发明的例子并没有给我们带来额外的损失。现在让我给你举个例子。
假设我们在向上移动后跟踪买入限价，以便在必要的回撤时开盘。几乎是幸运的-TC。如果我们每次都拖着一座山的Limits，我们就不会用你的选项来抓回调。
好吧，基于一个过时的交易环境给出交易指令 是很奇怪的。但你顽固地（像我一样）为不同的观点辩护。
好吧，根据过时的贸易环境发出贸易指令 是很奇怪的。但你顽固地（像我一样）为不同的观点辩护。
你必须两害相权取其轻。
当然，在 "1个EA=每个方向1个订单 "的变体中，在价格后面伸展限价的例子更好实现。
但一般来说，最好是把所有的订单都控制住。
但一般来说，把所有的订单都控制住是比较正确的。
也就是说，你不同意TS只在当前的交易环境下工作的要求。
也就是说，你不同意TS只在当前的交易环境下工作的要求。
如果你必须牺牲对所有TC订单的控制来做到这一点--当然。
想象一下：你有一个由四辆卡车组成的车队。他们中的每一个人都在运送宝贵的货物从A点到B点。你需要监测路线。
你喜欢什么：是每分钟和其中一个人联系，还是每2分钟和所有的人联系？
在第二种情况下，延误的时间会稍微长一些，如果你没有及时把它们的路线安排好，所有四个人可能要稍微绕道。但总的来说，这将比拥有一辆卡车而失去其他三辆卡车对企业更有利。
如果你必须牺牲对所有TC订单的控制权来做到这一点，当然可以。
想象一下：你有一个由4辆卡车组成的车队。它们中的每一个都携带着宝贵的货物从A点到B点。你需要控制路线。
你愿意每分钟和其中一个人联系，还是每2分钟和所有的人联系？
在第二种情况下，延误的时间会稍长一些，如果你未能及时安排路线，四人可能都要稍作绕行。但总的来说，这将比花费一辆卡车而失去其他三辆卡车对企业更有利。
+1.
也许用OOP的方法就不会产生新的想法，在OOP的方法中，一个类似于订单蛮力的循环被隐藏在一些类似于经理的实体中，而不是直接调用OrderModify，而是生成一个修改命令（包括所有参数）并把它放到一个队列中，然后被处理。这个想法是在一些分析环境的实体和根据分析执行行动的实体之间划分责任（在这段代码中，责任被塞进一个循环）。
也许这种想法不会出现在OOP方法中，当一个类似于循环的订单搜索被隐藏在一些实体中，比如经理，它不是直接调用OrderModify，而是生成修改的命令（包括所有参数），并将其放入队列，然后进行处理。这个想法是将责任（在这段代码中，责任被塞进一个单一的循环中）在分析环境的对象和根据分析进行行动的对象之间进行划分。
避免这种情况的唯一方法是使用异步订单。
否则仍会有一个待执行命令列表的循环，这实际上是一个订单的循环。
只有在排队的情况下，你仍然必须做出规定，用较新的订单取代与之相关的较早的未执行的订单。否则，队列可能会溢出，订单会被送出队列--过时的。