错误、漏洞、问题 - 页 2096

新评论
 
elibrarius:

嗯，发现它))))

int OnInit()
  {
   return(INIT_SUCCEEDED);
}

void OnTick()
  {
  int s[];
  CopySpread(_Symbol,_Period,0,1,s);
  Print(s[0]);
  }

那么，是谁告诉你，当前条形图的价差域等于当前的价差，或者说，等于最小值？

使用SymbolInfoTick，条形图是一个历史的雏形。

 
fxsaber:

那么，是谁告诉你，当前条形图的点差字段等于当前的点差或例如最低点？

使用SymbolInfoTick，条形图是一个历史的雏形。

CopySpread--记住了最低限度--说的是实践，在大多数情况下，这被证明是真理的标准。从中可以确定，bar 2017.10.23 01:00 CopySprea=-3，因为在检查ticks的时候没有少。

我把酒吧称为--分析过去的一个非常必要的工具。

SymbolInfoTick 是正确的，但它真的是让CopySpread出错的原因吗？我明白，1点。- 是一个小问题，我认为，并固定它的基本s=s-1。这就是全部 )

 
elibrarius:

SymbolInfoTick - 它显示正确，但真的有必要因为这个而让CopySpread出错吗？我明白，1点。- 是一个小事，我想，这是一个基本的纠正它s=s-1。这就是全部 )

在运行测试器之前，看一下酒吧的历史，看看它是否有一个负差。这是一个无关紧要的歪门邪道。

如果今天的开发者能想出MqlRates，就会有正常的字段而不是这种垃圾。但他们没有时间重新考虑这个结构，已经把它弄得一塌糊涂了。所以，我们已经有了这样一个历史的雏形。而现在他们将一直拉着这个负担。

 
elibrarius:

CopySpread--记住最低限度--说的是实践，在大多数情况下，这被证明是真理的标准。从中可以看出，bar 2017.10.23 01:00 CopySprea=-3，因为通过ticks检查时没有减少。

我把酒吧称为--分析过去的一个非常必要的工具。

SymbolInfoTick是正确的，但它真的是让CopySpread出错的原因吗？我明白，1点。- 是一个小问题，我认为，并固定它的基本s=s-1。这就是全部 )

如果你注意观察，你可以看到，当一个新条形图 出现时，点差的最后一个值会被记住。

 
Alexey Viktorov:

如果你仔细观察，你可以看到当一个新条形图 出现时，最后的价差值会被记住。

再仔细看看--我同意，但只是一部分。

专家的代码。

void OnTick() { 
  int s[];
  CopySpread(_Symbol,_Period,0,1,s);
  Print(s[0]);
  MqlTick last_tick;
  if(SymbolInfoTick(Symbol(),last_tick)) { Print(last_tick.time,": Bid = ",last_tick.bid, " Ask = ",last_tick.ask,"  SP = ",DoubleToString(last_tick.ask-last_tick.bid,5)); }
}

下面是一分钟的打印结果--首先是CopySpread的传播。然后从要价-出价计算

2018.01.01 11:55:00.478 2017.10.23 01:00:00 14
2018.01.01 11:55:00.478 2017.10.23 01:00:00 2017.10.23 01:00:00: Bid = 1.17715 Ask = 1.17729 SP = 0.00014
2018.01.01 11:55:00.494 2017.10.23 01:00:00 9
2018.01.01 11:55:00.494 2017.10.23 01:00:00 2017.10.23 01:00:00: Bid = 1.17715 Ask = 1.17724 SP = 0.00009
2018.01.01 11:55:00.510 2017.10.23 01:00:00 9
2018.01.01 11:55:00.510 2017.10.23 01:00:00 2017.10.23 01:00:00: Bid = 1.17716 Ask = 1.17726 SP = 0.00010
...........
2018.01.01 11:55:01.023 2017.10.23 01:00:30 1
2018.01.01 11:55:01.023 2017.10.23 01:00:30 2017.10.23 01:00:30: Bid = 1.17704 Ask = 1.17705 SP = 0.00001
2018.01.01 11:55:01.876 2017.10.23 01:00:30 -1
2018.01.01 11:55:01.876 2017.10.23 01:00:30 2017.10.23 01:00:30: Bid = 1.17707 Ask = 1.17705 SP = -0.00002
2018.01.01 11:55:01.893 2017.10.23 01:00:31 -3
2018.01.01 11:55:01.893 2017.10.23 01:00:31: Bid = 1.17707 Ask = 1.17703 SP = -0.00004
2018.01.01 11:55:01.909 2017.10.23 01:00:31 -3
2018.01.01 11:55:01.909 2017.10.23 01:00:31 2017.10.23 01:00:31: Bid = 1.17707 Ask = 1.17704 SP = -0.00003
2018.01.01 11:55:01.925 2017.10.23 01:00:32 -3
...........
2018.01.01 11:55:02.293 2017.10.23 01:00:48 -3
2018.01.01 11:55:02.293 2017.10.23 01:00:48 2017.10.23 01:00:48: Bid = 1.17702 Ask = 1.17707 SP = 0.00005
2018.01.01 11:55:02.309 2017.10.23 01:00:48 -3
2018.01.01 11:55:02.309 2017.10.23 01:00:48 2017.10.23 01:00:48: Bid = 1.17703 Ask = 1.17707 SP = 0.00004
2018.01.01 11:55:02.325 2017.10.23 01:00:49 -3
2018.01.01 11:55:02.325 2017.10.23 01:00:49 2017.10.23 01:00:49: Bid = 1.17707 Ask = 1.17707 SP = 0.00000

即：当前条形上的CopySpread值=最小值。

但在酒吧的历史上，最后的价值确实已经消失了。

<日期> <时间> <打开> <高> <低<关闭> <刻度线> <刻度线> <刻度线> <刻度线> <宽度
2017.10.23 01:00:00 1.17715 1.17720 1.17693 1.17707 64 0 0

大多数时候（至少检查了10次），但这里也有故障。
以下是上面描述的问题，在2017.10.23 00:53

在历史上。

2017.10.23 00:53:00 1.17685 1.17725 1.17685 1.17725 8 0 9

还有关于蜱虫的问题。

2018.01.01 11:54:59.009 2017.10.23 00:53:43 48
2018.01.01 11:54:59.009 2017.10.23 00:53:43 2017.10.23 00:53:43: Bid = 1.17724 Ask = 1.17733 SP = 0.00009
2018.01.01 11:54:59.025 2017.10.23 00:53:43 48
2018.01.01 11:54:59.025 2017.10.23 00:53:43 2017.10.23 00:53:43: Bid = 1.17725 Ask = 1.17736 SP = 0.00011
2018.01.01 11:54:59.041 2017.10.23 00:53:43 48
2018.01.01 11:54:59.041 2017.10.23 00:53:43 2017。10.23 10.23 00:53:43: Bid = 1.17725 Ask = 1.17737 SP = 0.00012 <<<<<<---------- last bar tick 2017.10.23 00:53
2018.01.01 11:54:59.057 2017.10.23 00:54:11 9
2018.01.01 11:54:59.057 2017.10.23 00:54:11 2017.10.23 00:54:11: Bid = 1.17728 Ask = 1.17737 SP = 0.00009 <<<<<<---------- 2017.10.23 00:54的 第一条刻度线 - 这里符合

检查了从下一个条形图的第一个点开始的价差进入历史的版本。尚未确认。

历史
2017.10.23 00:59:00 1.17717 1.17723 1.17709 1.17715 14 0 3

下一个条形图的第一个刻度
2018.01.01 11:55:00.478 2017.10.23 01:00:00 14
2018.01.01 11:55:00.478 2017.10.23 01:00:00 2017.10.23 01:00:00: Bid = 1.17715 Ask = 1.17729 SP = 0.00014

历史

2017.10.23 01:00:00 1.17715 1.17720 1.17693 1.17707 64 0 0

下一个条形图的第一个刻度
2018.01.01 11:55:02.342 2017.10.23 01:01:03 1
2018.01.01 11:55:02.342 2017.10.23 01:01:03 2017.10.23 01:01:03: Bid = 1.17707 Ask = 1.17708 SP = 0.00001

总而言之--一些混乱的传播(

 
elibrarius:

...

总而言之--关于价差的一些困惑(


 

MT4 b1090，在Market Watch里有几十个符号，打开了几个图表。终端.exe占用0-1%的CPU。

MT5 b1730，市场观察中只有GBPUSD MetaQuotes-Demo，没有图表。terminal64.exe占用2-3%的 CPU。

这是否正常？

 
fxsaber:

MT4 b1090，在Market Watch里有几十个符号，打开了几个图表。终端.exe占用0-1%的CPU。

MT5 b1730，市场观察中只有GBPUSD MetaQuotes-Demo，没有图表。terminal64.exe占用2-3%的 CPU。

这是否正常？

这个话题已经出现过好几次了。MT5的CPU密集度更高一些，因为它广播的信息更多。

但在1-2％内进行比较是不正确的。

 
Andrey Khatimlianskii:

这个话题已经出现过好几次了。MT5的CPU密集度略高，因为它广播了更多信息。

但在1-2％内进行比较是不正确的。

几个浏览器在阅读模式下有几十个打开的标签，吃的东西是零。当一个完全空的终端像洪流客户端一样消耗时，这很奇怪。而且，如果你拔掉电脑上的互联网插头，它也不会改变。

 
fxsaber:

几个浏览器在阅读模式下打开几十个标签，吃的东西是零。当一个完全空的终端像洪流客户端一样消耗时，这很奇怪。而且如果你把它从电脑上拔下来，它也不会改变。

把它与浏览器相比是不正确的。就我所见，背景标签根本不消耗资源。

而终端接收刻度线并建立时间序列，无论图表是否处于活动状态，因此当你切换到它时，它显示的是当前的信息，没有延迟。

但我并不是真的在为MT辩护，只是指出，从来没有人愿意用服务台的所有计算方法来做一个全面的比较。

1...208920902091209220932094209520962097209820992100210121022103...3184
新评论