错误、漏洞、问题 - 页 891

 

很明显,归零是为了兼容,但不清楚为什么当未使用的枚举=WRONG_VALUE 被正确初始化时 它不能正确工作。这种方法缺乏可移植性,大大增加了隐藏错误的概率。

 
A100: 不清楚为什么当未使用的enum =WRONG_VALUE 被正确初始化时,它不能正确工作。

记得这个规则吗?

规则:如果一个命名的常量--枚举的成员没有明确指定一个特定的值,它的值将会自动生成如果它是枚举的第一个成员,将被分配值为0。对于所有后续成员,将根据前一个成员的价值加一来计算价值。

最有可能的是,检查查询字段的正确性是假设枚举成员的值不能是负数。没有考虑 到将WRONG_VALUE 分配给一个枚举成员的可能性。

 
Yedelkin:

然而,没有考虑 到给一个枚举成员分配WRONG_VALUE 的可能性。

我认为这正是这里的错误。如果不使用一个具体的枚举,那么它的值将是WRONG_VALUE,而不是例如实际=0的ORDER_TYPE_BUY,这是符合逻辑的。

最重要的是--没有什么能阻止你在保持兼容性的同时改变OrderCheck()和OrderSend()的逻辑。

 
A100: 我认为这正是这里的错误。如果不使用具体的枚举,那么它的值将是WRONG_VALUE,而不是实际=0的ORDER_TYPE_BUY,这是符合逻辑的

最重要的是,没有什么能阻止你在保持兼容性的同时改变OrderCheck()和OrderSend()的逻辑。

有一种方法可以了解开发者的意见--向服务台写下错误。
 

我发现了一个奇怪的 "错误"。

我在我的EA中使用这个代码。

void OnTradeTransaction(const MqlTradeTransaction &trans, const MqlTradeRequest &request, const MqlTradeResult &result)
  {
   if(trans.type == TRADE_TRANSACTION_DEAL_ADD)
    {
     if(trans.symbol == "EURUSD") EURUSD_K = 1;
    }    
  }

在测试器中单次运行没有问题,但是一旦我选择了带有完整搜索的参数,测试器就开始工作得慢了十倍或十倍。我不明白为什么在一次运行中速度是足够的,而在优化过程中却明显下降。此外,它还呈几何级数下降。你可以从百分比中看到,开始时一切都很好,但到了最后,速度不断下滑,越来越慢。我在我的代码中寻找问题,并寻找循环或什么,但未能找到。之后,我用我自己的算法替换了上面提到的代码,哦,我的天啊!我的天啊!"。现在,优化工作以正常、统一的速度运行。这使我得出结论,问题出在MQL5中,在OnTradeTransaction函数的 某个地方。我将要求开发商注意这一点。

p.s. 我不能发布专家顾问的代码。试着在你的任何一个EA中使用上述代码,看看OHLC M5中从2000年到今天的优化速度。

Документация по MQL5: Основы языка / Функции / Функции обработки событий
Документация по MQL5: Основы языка / Функции / Функции обработки событий
  • www.mql5.com
Основы языка / Функции / Функции обработки событий - Документация по MQL5
 
lordlev:

我发现了一个奇怪的 "错误"。

我在我的EA中使用这个代码。

在测试器中单次运行没有问题,但一旦我选择了具有完全搜索功能的参数,测试器就开始工作得慢十倍或十倍。我不明白为什么在一次运行中速度是足够的,而在优化过程中却明显下降。此外,它还呈几何级数下降。你可以从百分比中看到,开始时一切都很好,但到了最后,速度不断下滑,越来越慢。我在我的代码中寻找问题,并寻找循环或什么,但未能找到。之后,我用我自己的算法替换了上面提到的代码,哦,我的天啊!我的天啊!"。现在,优化工作以正常、统一的速度运行。这使我得出结论,问题出在MQL5中,在OnTradeTransaction函数的 某个地方。我将要求开发商注意这一点。

p.s. 我不能发布专家顾问的代码。试着在你的任何一个EA中使用上述代码,看看OHLC M5中从2000年到今天的优化速度。

在不同的参数下,专家顾问可能会在不同的时间工作。
 
Konstantin83:
对于不同的参数,EA可能运行不同的时间长度
在这种情况下,问题不在于专家顾问或参数。问题出在MQL5本身。
 
lordlev:

用你的算法替换上述代码后

也就是说,他们放弃了使用OnTradeTransaction()?- 那么速度增加是合乎逻辑的--它在每一个场合都被调用。
 
A100:
也就是说,他们放弃了使用OnTradeTransaction()?- 那么速度增加是合乎逻辑的--它在每一个场合都被调用。
拒绝使用它是很自然的。很明显,它在任何场合都被称为。只是不清楚为什么在单次运行中速度足够,而在优化过程中速度突然下降。这与参数本身没有关系,正如另一位朋友在上面写的那样,我彻底检查了十遍。这使我得出结论,开发人员在某处犯了一个错误。
 
lordlev:

是什么阻止了你做一个最小的测试案例并向服务台报告?