结构规则。 学习如何构建方案，探索可能性、错误、解决方案等。 - 页 18

新评论
 
C-4:

哦，弗拉基米尔，有了你的电路就不那么容易了。你是说，你只需要重写驱动程序？但我数了一下，还有很多依赖于平台的部分。

你将如何获得市场历史和交易历史？而且，关于当前位置的信息不会从终端获取，有没有可能？如果你必须实现波动性模块--多一个依赖平台的API？

你会不会写适配器？他们会有多少人？因此，最终将有两倍的模块，以及相同数量的平台依赖代码。

我不是这样看待这个问题的。

只是红色的一切都相当稳定，所有来自平台的东西多年来没有变化，如果你需要其他平台，也有一个完善的API，重写没有问题。

但所有带绿色箭头的模块都是自己的，而且几乎都是主动返工的（理想是没有限制的）。

方向性的预测书写完了，接着又有了新的想法，要深化和扩大，好吧，就像现在是买入，但我们要做好卖出的准备，慢慢减少量。

所以我开始使用两个模块。

MM校正器也是一个动态方案，现在它对头寸起作用，然后突然有了一个想法，决定对多头头寸进行改变（顺利入市）。

市场驱动力应该是稳定的，因为它有输出到依赖于平台的API，因此形式化是明确的，但会有很多扭曲，因为API提供了很多可能性。

 
Urain:

我不是这样看待这个问题的。

尼古拉，你的帖子很有道理，但我要为提议的方案（其普遍性）辩护。


只是红色的一切都相当稳定，来自平台的一切多年来都没有改变，如果你需要它用于其他平台，也有一个完善的API，重写它是没有问题的。

我同意，我只想为Vasily澄清（在这个场合）。 方案中的一个重要想法不是依赖于平台的部分的数量，而是它们的严格本地化。即：TS本身（预测器+MM模块）--它是一个独立于平台的设计，但数据来源是指标和市场驱动力，分别依赖于（交易历史，反馈到建议校正器的输入--本质上也是指标）。


1.移徙。

2.改进TS，特别是缩放。

但所有带绿色箭头的模块都是自己的，而且几乎都是积极的重新设计（理想是没有限制的）。

但是，如果我们小心翼翼地在平台依赖/独立的部分对方案进行任何修改，那么，例如在我们目前的情况下，我们可以很容易地支持两个平台（MT4/5）的EA的开发，这对于平台依赖的EA来说，是非常痛苦的。

方向性的预测书写完了，接着又有了新的想法，要深化和扩大，好了，像现在是买入，但我们要准备卖出，慢慢减少成交量。

所以我开始使用两个模块。

在方案中标明的组件中可以有任何数量的模块。 这很正常。 我认为只有它们明确的管道安排才是有用的。 没有绝对不可避免的必要，它们不应该被混入代码中。你应该尽可能地避免洗牌。 这让你在向多工具扩展时总是有明确的、方便的 模块对接点。 从这个角度看方案，你自己会发现的。


MM校正器也是一个动态方案，现在它与头寸一起工作，然后突然间它变得聪明起来，决定改变它的股权（顺利入市）。

见上文。//但MM校正器的输入是将单一货币（更准确地说是单一工具）预测器云整合到多货币（多工具）厨房的最方便之处。


市场驱动力应该是稳定的，因为它有输出到依赖于平台的API，因此形式化是明确的，但会有很多混乱，因为API提供了很多功能。

没有人承诺没有复杂的问题:) 但想想看，如果所有这些直接的API调用都不在驱动程序里，而是与预测器和MM-模块的代码混合在一起，.............

;)

 
MetaDriver:
尼古拉，你的帖子很有道理，然而我承诺为提议的方案（其普遍性）进行辩护。


我同意，我只想为Vasily澄清（在这个场合）。 方案中的一个重要想法不是依赖于平台的部分的数量，而是它们的严格本地化。即：TS本身（预测器+MM模块）--它是一个独立于平台的设计，但数据来源是指标和市场驱动力，分别依赖于（交易历史，反馈到建议校正器的输入--本质上也是指标）。


1.迁移。

2.改善TS，特别是扩大规模。

然而，如果我们仔细坚持划分系统的平台依赖/独立部分，那么例如在我们目前的情况下，我们可以很容易地支持两个平台（MT4/5）的EA开发，这在平台依赖的交易系统中是很麻烦的。

在方案中标明的组件中可以有任何数量的模块。 这很正常。 我认为只有它们明确的管道安排才是有用的。 没有绝对不可避免的必要，它们不应该被混入代码中。你应该尽可能地避免洗牌。 这让你在向多工具扩展时总是有明确的、方便的 模块对接点。 从这个角度看方案，你自己会发现的。


见上文。//但MM校正器的输入是将单一货币（更准确地说是单一工具）预测器云集到多货币（多工具）厨房的最方便之处。


没有人承诺完全没有复杂性。 :) 但想想看，如果所有这些直接的API调用都不在驱动中，而是与预测器和MM-模块的代码混合在一起，.............

;)

好吧，让我们以这个为基础（但要增加一个停止模块，似乎是合理的，没有人反对）。

并思考这个方案中还缺少什么，或者重新做。


 
Urain:

好吧，让我们把它作为一个基础（但要增加一个模块来处理停止，因为这似乎是合理的，而且没有人反对）。

并思考这个电路中还缺少什么，或者重新加工。

我将考虑返工-改进（让它煮熟）。

欠缺的地方更明显--这个方案显然缺少GUI（可视化监控/控制子系统）。 我想开发一个统一 的（和方便的！）专家顾问与GUI的互动方案。 到目前为止，我在这个问题上是自发的，这真的让我很恼火。我想实现同样的目标（两个方向的完全数据抽象）。这就是为什么我建议将EA/GUI界面的任务用于培训，我对它的商业化感兴趣，我想从公众那里得到一些想法。

 
MetaDriver:
在方案组件中可以有任何数量的模块，这是正常的。 我认为只有明确的管道安排才是有用的。 如果没有绝对不可避免的必要，就不应该在代码中进行洗牌。 即这使你在向多用工具扩展时总是有明确的、方便的 停靠点。 从这个角度看图，你会自己发现。

无限的模块蔓延会导致未来的严重问题。你有专家顾问的逻辑实际上分散在不同的模块中。这些模块本身会相互影响，而且不能保证它们之间的联系不会成为一种纠结。我认为，所有标记为绿色的方块都是一个交易系统的要素。将它们分解成不同的模块违反了主要的编程原则之一：将数据和方法封装在一个任务中。

既然大家都开始发表自己的计划，我也会继续。这一次是更加抽象的方案。

黑色箭头描述了刚性的关系。灰色的是模块内部的私人相互关系，它们并不重要。另外，交易机器人类可以直接处理平台的API，但平台的不依赖性被降低。

 
C-4:

无限的模块蔓延会导致未来的严重问题。你有专家顾问的逻辑实际上分散在不同的模块中。这些模块本身会相互影响，而且不能保证它们之间的联系不会成为一种纠结。我认为，所有标记为绿色的方块都是一个交易系统的要素。将它们分解成不同的模块违反了主要的编程原则之一：将数据和方法封装在一个任务中。

既然大家都开始发表自己的计划，我也会继续。这一次是一个更加抽象的计划。

黑色箭头描述了刚性的关系。灰色的是模块内部的私人相互关系，它们并不重要。另外，交易机器人类有权直接访问平台的API，但这降低了平台的独立性。

如果API是通过访问模块访问的呢？ 那么通过改变一个模块就可以改变平台。
 
MetaDriver:

在重新设计-改进方面，我会考虑一下（让它酝酿）。

欠缺的地方更明显--这个方案显然缺乏GUI（可视化监控/控制子系统）。 我想开发一个统一 的（和方便的！）专家顾问和GUI之间的互动方案。 到目前为止，我在这个问题上是自发的，这真的让我很烦。我想实现同样的目标（两个方向的完全数据抽象）。这就是为什么我建议将EA/GUI界面的任务用于培训，我对它的商业化感兴趣，我想从公众那里得到一些想法。

从任务中走出来。GUI中最需要的任务是什么？

从那里开始。描述你想得到的东西，选择常见的标题，做一个框架，然后再添加一些东西，看看改变框架有多容易。

然后你会明白应该如何，重新写一遍。我是这样看的。

 

MetaDriver 说得很对，他的系统是正确的。Dick_fx还想补充一点，"交易驱动 "应该与10-20个平台合作，以使用最佳价格。

但是，使用这样一个正确的系统只有在理想的条件下才是方便的--没有策略上的错误，没有用户的干预，没有不可抗力......。而在现实中，这种情况很少发生。

让我举一个dick_fx的例子：25个策略在工作，聚合器（交易驱动）将它们收集成一个净头寸并投入市场，一切正常。突然间，17-th策略出了问题，它给出了不健康的预测--它说以50%的存款开盘。专家顾问顺从地打开。

一个琐碎的储物柜，如MT4，是做什么的。

  • 从图表中删除第17个EA（通过交易中的魔法很容易找到它）。
  • 关闭相应的头寸（就MT4而言）或部分头寸（就MT5而言）。
  • 读取由该EA创建的日志，以分析情况。

现在让我们继续讨论 "正确的会计"。交易者应该怎么做才能纠正这个错误（50%的保证金交易--一个明显的逻辑错误）？

  • 找出是哪个策略产生的（如何产生的？从日志中？）
  • 找到适当的代码并编辑它（return(0)?）。
  • 或在仓位求和循环中，与所需策略相反（数字不应搞错！），放继续。
  • 编译专家顾问（如果是MT4 - 首先关闭终端，或在编译后，指定正确的设置）。
  • 对形势的分析--是一首单独的歌曲（如果没有提供自己的日志与分成策略）。

问题是：哪个更容易？很明显，带有MT4的变体。

那么什么是更便宜的呢？很明显，净值化选项。

结论是什么？用MT4的GUI做一个市场驱动；)

 

还有一件事。

这都是 "正确的 "交易者，甚至是程序员的推理。如果他们是为了自己的乐趣，在有良好存款的账户上，那么这是唯一的方法。

如果我们触及专家写作，事实证明，没有人需要它 "正确"。贸易商-客户的人群是无法改变的，所以必须写 "为他们"。

接受 "放弃我的工作 "的选项!=)

 
komposter:

还有一件事。

这都是 "正确的 "交易者，甚至是程序员的推理。如果他们是为了自己的快乐，在有良好存款的账户上，那么这是唯一的方法。

如果我们触及专家写作，事实证明，没有人需要它 "正确"。贸易商-客户的人群是无法改变的，所以必须写 "为他们"。

接受 "放弃我的工作 "的选项!=)

我几乎同意。 这个方案不是为工作而制定的。供我自己使用。也就是说，产出应该是在外汇/汇兑上的工业规模的交易，而不是在市场或工作中......)
1...11121314151617181920
新评论