服务器上是否有打勾历史? - 页 2

 
但是,为什么不仅要按时间段形成历史,还要按几个点形成历史呢? 比如10、100、500、1000等等。在这种情况下,它变成了一个缩小到体积的时间图。你不能否认,成交量是一个非常重要的分析指标。这将是非常清楚的。此外,你可以根据你的需要,通过刻度数或时间指标来形成历史。积累的数据可以在论坛上分享--谁收集了什么。我认为以编程方式提供这种服务并不困难。为了补充缺失的数据(终端被关闭),你可以在服务器上存储一小段时间的tick历史(比如1-3天)。
 
你不能否认,成交量是一个非常重要的分析指标。这将是非常直观的。


显然,开发商只需要在明显的地方用大字钉住网站就可以了。"没有蜱虫,也不会有任何蜱虫!"。 对蜱虫的讨论以及对经纪人的讨论将从论坛上删除" :o)))。否则,一切都会周而复始。仅仅是患者的话语,没有任何详细的证据表明需要保持蜱虫...
 
你能更具体地说明我们正在谈论的是哪些虱子吗?
如果能看到真实账户 的打勾历史,那就很有意思了。
文学界对图表的热情很高,以至于人们在使用EA进行真实交易之前不得不三思而后行。
而且我没有在任何地方看到经纪人公布了真实的蜱虫档案--所以我开始想,也许真的有什么东西要隐藏?
 
现在,这就是你被抓住的地方。我具体地说--证明分钟内的建模有严重的差异。特别是10分。只要拿着数据,做研究,公布所有的调查结果(包括历史档案),把我们钉在墙上。<br / translate="no">。
我认为,分钟建模的误差范围在1-2个点之内。而这种错误是完全可以接受的,也是正常的。

雷纳特
我不会证明它,因为我绝对同意你的观点。此外,我不打算把任何人钉在墙上。我宣布。我对测试器中的蜱虫模型 相当满意。我对它绝对没有任何抱怨。

同时,我再一次重复。
勾选历史的需要与测试器中的建模没有关系。

为了证明其必要性,我可以说的都在上面说了。

solandr,
如果用户不主动、不坚持向开发者解释他们的需求,用户和开发者都会受到影响。
如果开发者在开发产品时不表现出耐心、理解,同时也不采取战略方法,用户和开发者都会受到影响。
我希望你能理解这一点。
 
...还有,我们正在谈论MT5,Renat,它计划何时发布?
它将与MQL4兼容,还是将成为新的东西?
...它将与MQL4兼容,还是将成为新的东西?
 
现在,这就是你被抓住的地方。我具体地说--证明分钟内的建模有严重的差异。<br / translate="no"> 我认为,分钟建模内的误差在1-2分之内。而这种误差幅度是完全可以接受的,也是正常的。

你一直在谈论市场的价格方面。在这里,你无疑已经成功了,而且PRICE模型中的错误是微不足道的。
然而,报价流还有其他参数被建模完全破坏,特别是在新闻运动时期。
在我看来,你只需要tick历史,你可以从中获得任何时间段,不仅是时间段,还有tickframes(例如,在一个蜡烛中,10个tick)和cagi图表和交叉点和零点。
也就是说,所有与时间框架有关的人为限制都被取消。
 
在我看来,我们只需要tick历史,我们可以从中获得任何时间段,不仅是时间段,还有tick-frames(例如,在一个蜡烛中,10个tick)和cage图表和tic-tac-toe。<br / translate="no">也就是说,所有与时限有关的人为限制都被删除。



绝对同意这一点。开发者真的需要证明 "勾股 "与 "时间 "有同样的存在权利吗?如果因为任何重要时间段的数据量大,存储ONLY tick历史有困难,那么你至少可以存储固定的tickframes,就像现在的时间段那样。这是我的愿望,与测试人员、专家顾问和其他胡言乱语没有关系。我已经在真实账户上 交易了大约一年,我只做手动交易。如果有某种价格运动,那么交易获利是很基本的,但如果价格只是在一个地方来回漂移,没有专家顾问会帮助。并让计算机为自己做决定--上帝保佑。
因此,我认为滴答框架更准确地反映了价格走势,而且我个人会对其感到更舒服。这能有多难?
 
在我看来,储存历史的最好方法是将其储存在高质量的分钟中。
你可以从它们中建立任何框架(甚至是时间框架,甚至是井字形,甚至是
,以根据其他一些标准将它们最小化)。
真正重要的是MT4主要图表的轴的均匀性
,这些图表是基于恒定时间间隔收集的数据...

但这可能只有在下一个MT版本中才能解决
......那么你至少可以一次看到图片
,在波浪中(我不写艾略特,因为有波浪,但其结构非常值得怀疑?)
总的来说,我赞成以高质量的分钟为基本故事。
 
我想没有人会认为时间不是设定价格的最佳变量,价格更多的是取决于操作的次数和数量,而tick量 是这些参数的函数(或接近于此的参数)。这就是为什么对研究来说,刻度线框架比时间框架更有趣。
在任何情况下,如果对那些在这个分支中表达过的人做一个简单的估计,有绝对多数的人愿意这样做。
 
如果 我在制作自己的终端=))),我会这样做。
在服务器上,我将只存储刻度线,并且只允许下载它们。
在客户端,我将从ticks制作所有必要的TimeFrames(和TickFrames)。

因此,要获得任何(任何)TF一年的图表,你需要35.7Mb的流量(Yurixx的计算结果)。
现在,MT4将需要约20.763 Mb的历史记录,用于同一时期的所有TFs(15.71 + 3.142 + 1.047 + 0.524 + 0.262 + 0.065 + 0.011 + 0.002)。

一句话,蜱虫历史的 优点
- 用户自己决定他想要哪些TFs,并可以随时自己建造它们。
蜱虫病史的缺点
- 消耗的流量增加了1.7倍(与所有TF的下载量相比)。
- 它增加了处理器的负载(用于不断构建必要的TFs)。


如果 我自己做终端,我会先仔细考虑....。