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

新评论
 
fxsaber:

当低垫子的期望破灭时，结果就会出现。

在我看来，MOE 估计值不足以评估未来的 TC。

以下是 ZigZag MOE 的历史数据，MOE 远低于https://www.mql5.com/ru/forum/221552/page1630#comment_13582832。

在这篇文章中，您的 MOE 为 6.17。

我需要某种复杂的指标，就像测试者的平衡图和贸易平衡图之间的不匹配误差，但我还不知道在哪里能读到这样的资料。

 
multiplicator:

写续集。关于这几点

试图用简单的语言写这篇文章。似乎读者（尤其是其他语言的读者）并不理解。但出乎意料的是，最后我却为这种情况感到高兴。所以，我想，够了。

 
Igor Makanu:

我需要某种复杂的指标，比如测试仪平衡图和贸易平衡图之间的不匹配误差，但我还不知道从哪里可以读到这样的资料。

几乎为零。同步器工作得很好。只是佣金把它吃掉了。

 
fxsaber:

几乎为零。同步器工作得很好。它只是吃掉了佣金。

MO 就是 MO，我认为它是有史以来最没有价值的评估之一....。嗯，这是我的观点。）

您看过我关于 ZZ 的报告吗？请关注文章https://www.mql5.com/zh/articles/1492 和 Z-score。

我的 Z 分数： Z 分数： -17.44 (99.74%)。

您的 Z 分数： -3.52。

根据文章 "MATHEMATICS IN TRADING（交易中的数学）"，您的 Z 值数据很好，MO 值为正且高于 ZZ 值，但 ZZ 的 MO 值较低，Z 值却高出 5 倍（我所拥有的终端测试中的价差）。


在这里，我正在寻找问题的答案--如何正确评估 TS，但正如我在上面所写--MO 根本不是 TS 的评估指标，如果我没记错的话，MT4 上的测试仪 Grails ticks 的 MO 值是负的？- 我很久没看了，我需要在知识库中查找。

 
Igor Makanu:

MO 就是 MO，我认为是最没有价值的评估之一.....。嗯，这是我的看法）。

所以，MO 只是在说，当你必须支付成本（佣金、滑点等）时，会有多么困难。

您看过我的 ZZ 报告吗？请查看https://www.mql5.com/zh/articles/1492 和 Z 账户估值这篇文章。

我看过。它着眼于未来，所以我不太明白我需要看到什么。

我的 Z 值：Z 值： -17.44 (99.74%)。

你的 Z 值： -3.52。

根据 "交易中的数学 "一文，您的 Z 值数据很好，MO 值为正，且高于 ZZ 值，但 ZZ 的 MO 值较低，Z 值却高出 5 倍（在我的终端测试中的差值）。

我不太清楚为什么要与 ZZ-TS 进行比较。从内部看，应该没有任何不利因素。我记不清楚了，我想 MO 应该是 ZZ 最小膝部的两倍。

我从未听说过 Z 数。我看过定义。我得亲自看看这一系列交易。

我在寻找问题的答案--如何正确评估 TS，但正如我在上面写的--MO 根本不是 TS 的评估指标，如果我没记错的话，MT4 的 ticks 测试仪 grails 的 MO 为负值？- 我很久没看了，我需要在 KB 中查看一下。

MO 是平仓的平均利润。完全不是优化标准或类似的东西。只是信息。


ZY 对于遗传学，我曾经使用过这样的方法

sinput int inMinTrades = 0; // 最少交易次数（头寸）。

double OnTester()
{      
  return((TesterStatistics(STAT_TRADES) > inMinTrades) ? TesterStatistics(STAT_PROFIT) : 0);
}

可以过滤掉很多垃圾，并将 GA 引向或多或少有趣的极端。

 
fxsaber:

我不太明白你为什么非要拿它和 ZZTS 相比。从内部看根本不应该有减号。我记不太清楚了，我想 MO 应该是 ZZ 最小膝盖高度的两倍。

盈利交易（占全部交易的百分比）： 12217 (99.96%) 亏损交易（占全部交易的百分比）： 5 (0.04%)

这里没有亏损，只有收盘时的亏损 - 我懒得做。

fxsaber:

从未听说过 Z 账户。我读过定义。我需要亲眼看看这一系列交易。

文章中描述了计算公式，因此我认为可以在线计算 Z-账户，但我需要考虑测试人员提供的统计数据，以进一步了解 Z-账户的表现。

 

fxsaber:


这是一张在突出显示的红色区间内优化 TC 结果的图片。我无法准确再现当时的情况。但我记得，优化区间左侧的图片更令人愉悦--一条直线。这几乎是一个圣杯，它被放在真实的位置上，并获得了与测试仪中完全相同的结果。新年过后，系统性的亏损开始了，我有足够的智慧和经验关闭了交易。损失大约是之前收入的 10%。是什么原因导致我放弃交易还不清楚。

在这个故事中，重要的是，即使是graality也会导致流失。


也许是提供商扩大了点差？您可以下载这一时期的交易历史记录，查看新年前和新年后的平均点差大小。
 
fxsaber:

我从未听说过 Z 账户。我看过定义。我得亲自看看这一系列交易。

展示台

string ZToString( const double Commission = 0, const int Length = 80 )
{
  const int Size = OrdersHistoryTotal();
  string Str = NULL;
  
  StringReserve(Str, Size + Size / Length);
  
  for (int i = 0, Count = 0; i < Size; i++)
    if (OrderSelect(i, SELECT_BY_POS, MODE_HISTORY) && (OrderType() <= OP_SELL))
    {
      Str += (OrderProfit() + Commission> 0) ? "+" : "-";
      
      if (++Count >= Length)
      {
        Str += "\n";
        
        Count = 0;
      }
    }
    
  return(Str);
}


对于这笔交易（上线段不含佣金，蓝线段含佣金）。



Z 账户为 0.76（55.27%）--无佣金。看起来是这样的


显然，Z 值与佣金有关。我不会在分析中将其考虑在内。我还没有深入研究过交易分析这个话题。

 
fxsaber:

展示台

如何使用？- 真的需要它！

fxsaber:

Z 账户为 0.76 (55.27%) - 无佣金。看起来像这样

嗯，我想您已经证实了我的假设，即这与 MO 值低无关，而是与交易之间的相关性低有关，即交易的进入和退出几乎不取决于上一对和下一对输入和输出。也就是说，您的 TS 很可能通过实验（测试者的 GA）发现了与价格图表的随机相关性，并且这种相关性持续了一段时间。

这些是我的想法，如果是正确的，那么我们就应该更频繁地重新优化此类 TS，而盈利/亏损系列之间相关性较高的 TS 则应减少重新优化的频率.....。但似乎这里还需要监控 Z 账户的变化。


ZY：我想看看文章中测试者的完整报告，交易并不有趣，但帽子很有趣，我想与 ZZ 进行比较，如果你不介意，请分享一下。

 
multiplicator:

也许供应商扩大了点差？您可以下载这段时间的交易历史记录，查看新年前和新年后的平均价差大小。

下面是按周计算的时间加权平均价差（单位：点）。

2018.06.04 00:05:09   33.21
2018.06.11 00:05:11   41.86
2018.06.18 00:05:01   36.99
2018.06.25 00:05:19   45.40
2018.07.02 00:05:20   41.26
2018.07.09 00:05:21   39.09
2018.07.16 00:05:14   40.79
2018.07.23 00:05:19   36.06
2018.07.30 00:05:04   33.86
2018.08.06 00:05:17   33.03
2018.08.13 00:05:04   37.92
2018.08.20 00:06:08   40.94
2018.08.27 00:05:04   39.02
2018.09.03 00:05:13   37.99
2018.09.10 00:05:11   40.37
2018.09.17 00:05:16   42.10
2018.09.24 00:05:12   38.52
2018.10.01 00:05:13   32.12
2018.10.08 00:05:12   30.94
2018.10.15 00:05:16   35.96
2018.10.22 00:05:18   32.76
2018.10.29 00:05:02   36.59
2018.11.05 00:05:14   30.08
2018.11.12 00:05:09   30.41
2018.11.19 00:05:14   30.16
2018.11.26 00:05:32   34.95
2018.12.03 00:05:07   26.41
2018.12.10 00:05:15   25.50
2018.12.17 00:05:15   28.62
2018.12.24 00:05:13   33.06
2018.12.31 00:05:09   78.09
2019.01.07 00:05:11   49.78
2019.01.14 00:05:03   33.54
2019.01.21 00:05:20   43.68
2019.01.28 00:05:07   45.67
2019.02.04 00:05:12   44.24
2019.02.11 00:05:10   40.00
2019.02.18 00:05:20   40.66
2019.02.25 00:05:20   46.09
2019.03.04 00:05:15   41.78
2019.03.11 00:05:10   43.28
2019.03.18 00:05:03   44.42
2019.03.25 00:09:06   47.47
2019.04.01 00:05:12   44.14
2019.04.08 00:05:12   47.25
2019.04.15 00:05:09   45.61
2019.04.22 00:05:13   56.57
2019.04.29 00:05:19   48.09
2019.05.06 00:28:42   49.82
2019.05.13 00:05:13   58.00
2019.05.20 00:05:13   58.75
2019.05.27 00:05:12   60.43

用 Excel 绘制。用眼睛看，似乎增加了。这似乎就是原因所在。


// 每周的时间加权平均点差（点）。在测试器中以真实点数运行。
#define  MACROS(A, B)               \
  int Time##A( const datetime dt ) \
  {                                \
    MqlDateTime mdts;              \
                                   \
    TimeToStruct(dt, mdts);        \
                                   \
    return(mdts.B);                \
  }                                \
                                   \
  int A() { return(Time##A(TimeCurrent())); }

  MACROS(Day, day)
  MACROS(Month, mon)
  MACROS(Year, year)
  MACROS(DayOfYear, day_of_year)
  MACROS(DayOfWeek, day_of_week)
#undef  MACROS

void OnTick()
{
  static double SumSpread = 0;
  static long SumInterval = 0;  
  
  static MqlTick PrevTick = {0};
  static int PrevDay = 0;  
    
  MqlTick Tick;
  
  if (SymbolInfoTick(_Symbol, Tick) && (Tick.time - PrevTick.time) < 60)
  {
    const long Interval = Tick.time_msc - PrevTick.time_msc;
    
    SumSpread += (PrevTick.ask - PrevTick.bid) * Interval / _Point;
    SumInterval += Interval;    
  }

  const int Day = DayOfWeek();
  
  if (Day < PrevDay)
  {    
    if (SumInterval)
      Print(DoubleToString(SumSpread / SumInterval, 2));
      
    SumSpread = 0;
    SumInterval = 0;        
  }
  
  PrevTick = Tick;  
  PrevDay = Day;
}
1...111213141516171819202122232425...36
新评论