文章 "攫取盈利至最后的点位" - 页 14

新评论
 

有人问我（我不是在提问）。回答。


翻译是 MetaQuotes 在很短时间内主动完成的。我想这应该是出于监控的需要。

文末有一个不小的结论，您可以读一读。这里没有任何神圣性，一切都是公事公办。


复述这篇文章没有任何意义。简而言之。

  • 在进行任何研究之前，有必要对历史资料来源的选择采取合理的方法。评估标准已给出，包括源代码。
  • 使用刻度线数据。由于它们数量众多，可以进行筛选。建议使用源代码中的一个选项。
  • 不只探索一个符号，而是探索所有符号。即为优化创建洗牌。为此，MT5 的一个现成工具再次提供了源代码。
  • 它显示了测试器可能包含的陷阱。建议设置测试器的步骤，以减少自欺欺人的可能性。
  • 建议编写跨平台 TS。MT4 是交易 API 便捷性的基准。我们为 MT5 提供了该 API 的封装（源代码）。通过类比，我们可以为任何平台制作类似的封装程序。
  • 我们讨论了 Mat.期望值的重要性以及提高期望值的方法。
  • 前向优化不可取的原因。
  • 强调一天中时间对市场模式的重要性。提出了一种从源代码中即时找到最佳日间隔的简单方法。这将优化速度提高了几个数量级。
  • 讨论了经纪商执行质量的重要性。
  • 提供了一种使用源代码的方法，以解决真实结果（重定向、部分成交、连接失败等）与测试结果不一致的复杂问题。
  • 解释了低期望矩阵 TS交易信号 难以盈利复制的 原因。
  • 简要确认 MM（马丁、网格等）不会提高盈利能力。
  • 建议使用相同的 TS 创建投资组合。在监控中可以看到。
  • 以实际交易为例，说明限价订单的正滑点对总体结果的影响。
  • 事实证明，平庸的交易条件经常迫使潜在盈利 TS 的作者将其扔进垃圾桶。
  • 这篇文章清楚地介绍了一个真实案例，即在之前发布的开源工具包的帮助下，找到了一个盈利的 TS（迄今为止）。有了这样一个案例之后，我们萌生了撰写一篇配方文章的想法，并从一开始就进行了监测。MetaQuotes 完全支持这一想法，并尽快对文章进行了审核。 从检测到 TS 的那一刻起（在 MultiTester 的帮助下，几乎立即就找到了 TS），文章和屏幕在几天内就准备就绪。

编写自动 TC 的资质越高，文章就越有趣。


对于 "作者为什么需要它？

我缺乏只为自己制作交易工具的毅力。当我分享这些工具时，我会强迫自己清晰地表述我的结果，并将其置于方便的状态。这对我很有帮助。

我还会收到错误报告、新想法和建议等形式的反馈。利益相关者与我联系，有时会给我提供有用的信息。

 

2019 年 9 月：+51%。


 

一只黑天鹅飞向了八个 TC 中的一个。下面是以点为单位的结果，似乎有点。


但以 MM 的资金为代价，它看起来就像一个普通的扑克牌。


一个典型的市场情况发生了。它没有达到止盈的两个点，并在数字上没有任何逆转的情况下倒退。

在持续时间分布中，这样的天鹅比较突出（在这里 可以看得更清楚），如下图所示。

为什么会发生灾难？因为它是测试器中最有利可图的组合之一（也是实盘中最好的组合）。如果这套牌是经典的，那么账户就会出现创纪录的缩水，尽管利润可能会更高。

正是因为出现了这种不走运的情况，当一两个点没有达到收盘点位时，从相同的 TS 开始运行投资组合才是合理的。

 

真实 VS 测试仪。

红色 - 无滑动。蓝色 - 有滑动。


由于推出后没有任何变化，我们可以比较每个 TS 在 Tester 和 Real 中的结果差异。

红线显示的是没有滑动的结果。每个 TS 的重合度都很高。

蓝线显示的是滑点。这有点不寻常，因为在测试仪中可以看到滑动，在实际中也可以看到滑动。这两条线同样非常接近。


应该考虑到重定向和连接中断的情况（每天 50 次，每次 10-20 秒）。


使用 Graphics.mqh 和 Report.mqh 绘制了图表。

 

设置 TS 时有两种方法

  1. 以固定手数进行交易。
  2. MM，作为自由资金（或余额）的一部分。

第一种情况很好，因为您可以看到所用模式的期望矩阵值。似乎期望值越高越好。但是，在对稳健的 TS 进行再投资时，可能发生的情况是，较多的小额交易比较少的大额交易更有利。

例如，在点数上，两次交易的结果可能是一样的。但交易次数较多的交易可能更有利于再投资。


因此，最好有一个再投资的优化标准。

我采用了以下标准：在严格规定的最大相对缩水情况下，能获得多大的相对收益率。

你可以在这里 看到计算这种盈利能力的算法。

sinput double inMaxDD = 0.3; // 我应该计算多大的最大缩减风险？

double OnTester()
{
  double SumGain, MaxDD, RF;
 
  // https://www.mql5.com/ru/forum/170953/page21#comment_13448682   
  return(GetSumGain(GetRisk(inMaxDD, 0.01, _Symbol), SumGain, MaxDD, RF, _Symbol) ? SumGain : 0);
}

有了这种计算方法，在测试人员的 TS 中就完全不用考虑 MM 了。一切都会像有 MM 一样运行。


当然，在 OnTester 中还添加了一个额外的条件，即负值交易的存在及其数量。

1...789101112131415161718192021...36
新评论