开发人员。MT5终端的时间格式 - 页 2

 
Risk:

他们会感谢你的,因为你的鼻涕在MT4中很好,但我并不关心它,这一切都是为了交易。

冒着给你第二次警告的风险,不要再对别人大放厥词了。

 

朋友们,最重要的是,毫秒级的精确度是根本不可能的--互联网上的延迟要大几个数量级。此外,计算机的常规定时器仍在低频率运行(如果我没记错的话,大约是1/18秒),要获得更高的精度并不容易。

而且你说的很对,没有必要用毫秒的时间。

我认为数据时间格式是比较好的。

 
sergeev:

维亚切斯拉夫,但这不是真的;)

我想用这个建议联系支持部门,但我知道你必须创建一个新的时间格式才能做到这一点...我知道这样做是很无奈的。

也许真的是时候让终端在订单上提供这样的信息了?



正是如此。我们必须创造(不是新的时间格式)一种新的存储时间 的方式。并将其分散到我们所有的组件中。就连时间序列也是如此。这值得吗?绝对不是。

这里的毫秒信息更为重要。但这也不值得。因为这些信息在通过电线时完全失去了意义。

PS 斯坦尼斯拉夫,顺便说一下。

Документация по MQL5: Основы языка / Типы данных / Целые типы / Тип datetime
Документация по MQL5: Основы языка / Типы данных / Целые типы / Тип datetime
  • www.mql5.com
Основы языка / Типы данных / Целые типы / Тип datetime - Документация по MQL5
 
stringo:

正是如此。我们需要创造(不是一种新的时间格式)一种新的时间存储 方式。并将其分散到我们所有的组件中。就连时间序列也是如此。这值得吗?绝对不是。

是的,这个过程非常耗费时间

关于毫秒的信息更可行。但这也不值得。因为这些信息在通过电线时完全失去了意义。

这些信息对于即时决策来说并不那么重要,因为它是为了收集统计数据,也就是说,它不是为了相关性,而是为了恢复事件链,正如我所说的为供应商或服务器收集统计数据。

毕竟你几乎所有的东西都准备好了,把订单和交易的财产交给交易员,在ms。它们属于OrderGetInteger / DealGetInteger。 与ORDER_TIME_MSC / DEAL_TIME_MSC


PS 斯坦尼斯拉夫,顺便说一下。

收到,这只是斯拉瓦在你的资料中。
 
papaklass:

Renat说,MT5与Plaza相连,你说为什么是毫秒。

那么发送交易指令的异步功能是什么?你为什么要做这个?

MT5是一个证券交易平台,交易者需要的是毫秒。:)

所以,这就是了。毫秒是如何 "帮助你砍树 "的?(ц)

你问,你问--所有人都沉默不语。

 
stringo:

因此,就是这样。告诉我毫秒如何 "帮助你砍树"?(ц)

你问,你问--大家都不说。

我告诉过你--在交易中是没有办法的。因为很明显,从下订单 到交易的到来,要经过几十秒的时间。

至于进一步收集统计数据,供应商如何处理订单,也许他有bug,也许服务器变慢或互联网。

Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
  • www.mql5.com
Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров - Документация по MQL5
 
stringo:

因此,就是这样。毫秒是如何 "帮助你砍树 "的?(ц)

你问,你问--所有人都保持沉默。

他们对一分钟的TF的帮助就像秒针一样。当秒数不再有帮助时,我们会选择毫秒。)

 

我在MT4上交易。如你所知,时间与MT5相似。处理ping和其他毫秒级的废话。想知道我是否会在MT4中使用毫秒数据。而且,奇怪的是,回答是否定的。是的,毫秒级的数据在分析中有时是有用的,例如,OrderOpenTime。但在实践中,我很少需要它。我甚至可以说,这不是一种需要,而是一种分析一个交易细微差别的愿望,反正利润并不取决于此。

当然,毫秒主要是指滴答的需要。它可以实时分析价格的微小波动。但它对历史研究更有帮助:多货币系统只有在嘀嗒的毫秒历史上才能被正确分析。例如,没有这样的历史,就不可能构建一个合成的欧元兑英镑。但有几个问题。

  • 在MT4/MT5中,不可能在不跳过的情况下收集小数点。
  • 研究基础设施不具备自定义历史和蜱虫测试器的可能性。
  • 在实时性方面,平台本身在交易时给出了相当强的滞后性(我没有研究MT5的异步性,我不会撒谎)。

也就是说,对于那些拥有良好的研究基础设施的人来说,需要的是毫秒。通常来说,这是他们自己的解决方案。好吧,就像现在这样,用毫秒和其他信息获取蜱虫的问题也通过他们自己的方式解决了。

此外,如果我们看看谁真正需要这样的功能,就会产生这样的问题:是否真的值得因为这种可能性而创造出复杂的东西,这在实用性上是值得怀疑的。你必须了解MT4/MT5的对象是谁--大众用户。他们并不真正需要这些毫秒的时间。如果有人真的需要,他可以使用Stocksharp或FDK。

在实时情况下,即使是MT4,我也使用毫秒,有点像通过GetTickCount进行模拟。例如,在分析单位 时。

2012.09.14 21:21:15 3296(2)ms. 1898804512 BuyLimit = 1.31062 EURUSD Ticks = 2 ShiftAvg = 1.50 ShiftByTime = 0.33 VolumeByTime = 0.20 PriceByTime = 1.310623 FillTime = 21:21:15

或者,例如,更复杂的情况--从符号从不同的饲料中 合成堆栈。为了这些目的,在MT4/MT5的可能性范围内,这样的模拟已经足够。

综上所述,我认为在MT5中,在没有上述事情的情况下,没有必要给出毫秒数。

P.S. 我喜欢FXCM的做法。他们有一个测试者和蜱虫历史。每个人都可以自由地在现有的定期OHLCV历史上测试他们的策略。但如果有人需要tick历史和tick测试器,tick历史只能通过API获得。还有一个滴答测试器--只能通过SDK测试器。也就是说,计算的结果是,如果一个人想使用它不是为了好玩,他的资格必须是足够的。也就是说,他将同时了解他们的API(并将通过它进行交易)和SDK。

 
我们有一个订单中的真实毫秒字段,我们可以在MQL5中输出它。
 

在这里,我认为一瞬间的时间会有帮助。