错误、漏洞、问题 - 页 432

[Renat Fatkhullin]

gumgum:

总共290个，...上）。

总的来说，矫枉过正使得290。

我认为没有传球（真正的跑步），但它是固定的（如果有比赛）？

既然你选择了遗传算法，它就会建立自己的穿越计划和群体输出。遗传优化器的算法在相关文章中有所描述。

用这么少的（290次）传球来运行遗传学是不合理的。遗传算法在使用时应至少有几万，最好是几百万/几十亿/几万亿的初始列举变体。

[Andrew Petras]

MQL5参考手册 -标准库- 组织数据的类 - CArrayObj（在网站和帮助中）。

2.内存管理机制被禁用。

在这种情况下，CArrayObj不负责 内存的释放

[Andrey Vasiliev]

Renat:

是的，没有必要测试到最新的现有日期。

选择一个合理的固定 结束日期，形式为前一个工作日的00:00，甚至是前一个工作周的结束。如果你一直使用最后一天，日程结束 会定期浮动，特别是在使用远程或claud代理的测试过程很长的时候。

我把周日作为结束日期。还有什么地方是明智的？周日没有交易。有什么可以漂浮在那里？

[Vladimir Gomonov]

MoneyJinn:
我把周日作为结束日期。还有什么地方有意义呢？周日没有交易。有什么可以漂浮在那里？

那么也许问题就出在故事的另一端。你需要多长的历史才能使这些指标发挥作用？在测试开始时，根据我的理解，它被保证有一百个前导条。

如果你需要更多，你应该跳过专家顾问开始后的一部分历史，其长度大于[necessary_number_of_bars - 100]。这解决了我在测试器和优化器的结果之间的相关性问题。

[Andrey Vasiliev]

MetaDriver:

那么也许问题就出在故事的另一端。你需要多长的历史才能使这些指标发挥作用？在测试开始时，根据我的理解，它被保证有一百个前导条。

如果你需要更多，在专家顾问的开始后跳过一段长度大于[necessary_number_of_bars - 100]的历史。这解决了我在匹配测试器和优化器结果方面的问题。

谢谢，但从截图中我们可以看到，通过网络优化时，周五（24.06.11）的历史记录丢失了

[[删除]]

这不是一个关键问题，但仍然是。字符串串联。文档描述了两个函数StringAdd和StringConcatenate。

第一条说："StringAdd()函数比通过加法运算进行的字符串连接工作得更快、更节省内存。

第二段写道：" 由于没有使用字符串类型的临时变量，StringConcatenate()函数 比使用加法运算的字符串绑定工作得更快、更节省内存。

void OnStart() {
  string string1 = "sdfdsfjssdfads";
  string string2 = "bsadfasdfaaa";
  string string3 = "ssdfsdgasgsaggsda";
  string result;
  uint i, start, stop, length = 10000000;

  start = GetTickCount();
  for(i = 0; i < length; i++)
    result = string1 + string2 + string3;
  stop = GetTickCount();
  Print("№1 ", (stop-start), " milliseconds, i = ", i);
 
  start = GetTickCount();
  for(i = 0; i < length; i++) {
    StringAdd(result, string1);
    StringAdd(result, string2);
    StringAdd(result, string3);
  }
  stop = GetTickCount();
  Print("№2 ", (stop-start), " milliseconds, i = ", i);

  start = GetTickCount();
  for(i = 0; i < length; i++)
    StringConcatenate(result, string1, string2, string3);
  stop = GetTickCount();
  Print("№3 ", (stop-start), " milliseconds, i = ", i);
}

结果。

2011.06.26 19:10:55 test (EURUSD,H1)№12012 milliseconds, i = 10000000
2011.06.26 19:11:04 test (EURUSD,H1)#2 8269 milliseconds, i = 10000000
2011.06.26 19:11:10 test (EURUSD,H1)#3 6661 milliseconds, i = 10000000

不过，事实证明，通常的加法更快。

[Yedelkin]

voix_kas:

但事实证明，正常的加法是比较快的。

这个问题已经出现了：https://www.mql5.com/ru/forum/58/page13#comment_59630 看一下文中后面的讨论。对开发者来说：要得出的结论是，参考资料中缺乏对这个问题的报道。

[Renat Fatkhullin]

MoneyJinn:
我把周日作为截止日期。还有什么地方是明智的？周日没有托尔格。外面会有什么东西在漂浮？

由于这类问题需要细节，请在服务台创建一个票据，并提供额外的描述--我们会尽力解决。

当然，问题在于历史和它的同步性。

[Renat Fatkhullin]

voix_kas:

这不是一个关键问题，但仍然是。字符串串联。文档描述了两个函数StringAdd和StringConcatenate。

第一条说："StringAdd()函数比通过加法运算进行的字符串连接工作得更快、更节省内存。

第二段写道：" 由于不使用字符串类型的临时变量，StringConcatenate()函数 比使用加法运算的字符串绑定更快、更经济。

结果。

2011.06.26 19:10:55 test (EURUSD,H1)№12012 milliseconds, i = 10000000
2011.06.26 19:11:04 test (EURUSD,H1)#2 8269 milliseconds, i = 10000000
2011.06.26 19:11:10 test (EURUSD,H1)#3 6661 milliseconds, i = 10000000

但事实证明，普通加法更快。

这似乎是一个用+进行的字符串连接优化。

编译器正在进行一些严肃的修改，涉及到纳入长期预期的优化模式。我们将在一段时间内展示结果。

[[删除]]

Renat:

看起来是用+进行的字符串连接优化起了作用。

我们现在正在认真改变编译器，启用期待已久的优化模式。我们将在一段时间内向你展示结果。

我明白了，好吧，如果有可能的话，你就在论坛上明确描述一下（我尽量关注所有的主题）。

到目前为止，在算法中我已经留下了工作 "+"。