使用iClose/iOpen时间序列访问等工作时的MQL5错误。 - 页 8

新评论
 
Slava:

有可能尝试确定。

如果是分钟，你可以用TimeCurrent()比较上一个条形的时间。如果不是M1，你可以询问iTime(_Symbol,PERIOD_M1,0)并与TimeCurrent()比较。

你可以将买入价或最后价格（取决于符号）与上一栏的收盘价进行比较。你可以直接向SymbolInfoTick询问当前符号。除了买入和卖出之外，还有勾选时间

谢谢，至少提供了一些信息，说明如果出了问题，在哪里以及如何寻找错误。

但我认为，同样需要嵌入函数来检查状态，或者最好是一个标志，比如int _LastError，它将存储错过的点数，在调用OnCalculate()时将很方便--在复杂的计算中，立即返回，以释放符号流。

 
Igor Makanu:

谢谢，至少提供了一些信息，说明如果出了问题，在哪里以及如何寻找错误。

但我认为，所有这些都需要嵌入式函数来检查状态，或者更好的是，它将是一个标志，像int _LastError，它将存储错过的点数，在调用OnCalculate()时将很方便--在复杂的计算中立即返回，以释放符号流。

思考，思考....这不是解决方案。对错过的刻度的认识将是什么（Slava说，它保证指标接收所有的刻度，这一事实导致所有的挂，不仅是MQL-程序，甚至是客户终端）？在任何情况下，这些刻度将不得不被收集和处理，这意味着，如果我们错过了一个刻度，为什么突然期望下一次它会被完成？- 这是一个恶性循环。

我在想...也许开发者应该引入一些类似于异常的东西？ 新的tick的到来应该中断所有的操作，在那一刻指标的计算，任何标准的MQL函数在其执行过程中应该返回一个错误，如果在那个时候有一个新的tick出现......。对于其他类型的程序（脚本、专家顾问）来说，这几乎是不必要的。

还有对指标中的蜱虫进行各种检查，以确定其相关性--说句不好听的，这并不是解决办法。

 

我们有一个想法，对于不包含#property tester_everytick_calculate标志的指标，可以在收到一包ticks的基础上加入计算模式，而不是在每个tick 上。

这将从根本上解决慢速指标的问题，保留了保证处理某些指标的每个tick的可能性。

 
Renat Fatkhullin:

我们有一个想法，对于不包含#property tester_everytick_calculate标志的指标，可以在收到一包ticks的基础上加入计算模式，而不是在每个tick 上。

这将极大地解决指标延迟的问题，保留了对某些指标的每个tick进行保证处理的可能性。

那么，有了这样的设计，你就能有一个非常快的指标了？

//+-------------------------------------------+
int OnInit() 
  {
  EventSetMillisecondTimer(200);
//-
  return(INIT_SUCCEEDED);
 }

//+-------------------------------------------+
int OnCalculate (const int rates_total,
                 const int prev_calculated,
                 const datetime& time[],
                 const double& open[],
                 const double& high[],
                 const double& low[],
                 const double& close[],
                 const long& tick_volume[],
                 const long& volume[],
                 const int& spread[])
 {
  // Здесь ничего не делаем, нам не нужен в данном случае OnCalculate
  return(rates_total);
 }

//+-------------------------------------------+
void OnTimer()
 {
  // Здесь расчёты, и вывод информации на график в виде графических объектов
 }

如果是这样，这是个好消息。

 
Renat Fatkhullin:

我们有一个想法，对于不包含#property tester_everytick_calculate标志的指标，包括基于ticks pack reception的计算模式，而不是基于每个tick。

这将从根本上解决慢速指标的问题，保留了对某些指标保证处理每个刻度的可能性。

而如果你做一个标准函数来获取一个同步的多币种数组，这将是一个真正的节日。

 
Renat Fatkhullin:

我们有一个想法，对于不包含#property tester_everytick_calculate标志的指标，可以在收到一包ticks的基础上加入计算模式，而不是在每个tick 上。

这将从根本上解决慢速指标的问题，保留了对某些指标的每个tick进行保证处理的可能性。

好主意!

而且最好是在没有任何#property的情况下默认 工作。

如果有人需要它，那么就让他们把#property 放进去。

 
如果我们不需要实时，那么以包为单位接收点数的解决方案是好的，而且可能不是很贵（但不清楚EA将如何与以 "昨天 "价格工作的指标一起工作，但不要紧）。

但还有另一类问题--实时的，在每一次勾选中。在这种情况下，你要么有时间在下一个tick之前的tick之后进行计算，要么没有，那么交易方案就没有意义了（没有第三种方法）。这就是为什么只有一个正确的方法来解决这个问题--中断所有当前的计算，并在新的tick出现时返回错误。否则，人们可以忘记实时性。现在蜱虫的速度一天比一天快，而且还有很长的路要走，所以有必要为未来做计划，更何况现在不可能在时间上没有滞后地处理所有蜱虫。

 
_o0O:
如果我们不需要实时，那么以包为单位接收点数的解决方案是好的，而且可能不是很贵（但不清楚EA将如何与以 "昨天 "价格工作的指标一起工作，但不要紧）。

但还有另一类任务--实时的，在每一次勾选中。你要么有时间在收到嘀嗒声后进行估算，要么就没有，而交易方案将是不相关的（没有第三个选择）。这就是为什么只有一个正确的方法来解决这个问题--中断所有当前的计算，并在新的tick出现时返回错误。否则，我们可以忘记实时性。现在蜱虫的速度一天比一天快，而且还有很长的路要走，所以有必要为未来做计划，更何况现在不可能在时间上没有滞后地处理所有蜱虫。

大部分指标EA都是在闭合的bar[1]下工作的，这就是为什么跳过ticks并不重要，这对于使用ticks的指标来说是实际的，但是它们并不多，对于它们来说，可以分配"#属性tester_everytick_calculate"。

再说一遍，如果你需要超级跳动，你不需要一个指标，所有这些都可以写在专家顾问的代码中。因此，为了每一个刻度而减慢指标的工作是不合理的。

我们等待"#property tester_everytick_calculate"。

 
Vitaly Muzichenko:

大部分指标EA都是在闭合的bar[1]下工作的，这就是为什么跳过ticks并不重要，这对于使用ticks的指标来说是实际的，但是它们并不多，对于它们来说，可以分配"#属性tester_everytick_calculate"。

再说一遍，如果你需要超级跳动，你不需要一个指标，所有这些都可以写在专家顾问的代码中。因此，为了每一个刻度而减慢指标的工作是不合理的。

等待"#属性tester_everytick_calculate"


好吧，你说的和我说的有什么不一致？
 
它可能对某人有用。我有一个多货币指标，所以主要的电容计算我是在初始化块中进行的，只有渲染到oncalculus中。 但这是针对指标行本身不包含复杂计算的情况的解决方案。 在我的例子中，它是一个投资组合指标，显示投资组合行为的图表。
12345678910
新评论