structMqlRates
{
datetime time; // время начала периодаdouble Base; // базовая цена бара. Все остальные цены отсчитываются от базы в пипсах short openBid; // цена открытия Bidshort highBid; // наивысшая цена за период Bidshort lowBid; // наименьшая цена за период Bidshort closeBid // цена закрытия Bidshort openAsk; // цена открытия Askshort highAsk; // наивысшая цена за период Askshort lowAsk; // наименьшая цена за период Askshort closeAsk // цена закрытия Asklong tick_volume; // тиковый объемlong real_volume; // биржевой объем
};
你能诚实地回答使用OHLC Bid + Spread,与OHLC Bid + OHLC Ask的原因是什么?存储8个数字而不是5个(条形和历史格式很难改变)?它是否会对提供的历史数量产生重大影响?或者,也许你只是没有问价记录?测试员的逻辑是否变得更加复杂?那么,在第二种情况下,就更简单了--根本就没有传播的概念。是什么阻止了它,要诚实。
条形结构的大小 是最重要的特征,它按比例影响着终端所消耗的资源量。
我们始终面临着节约资源的任务,所以以这种形式进行扩张是不合适的。
MqlRates 的大小。
等于(如果我没有弄错的话)46个字节。
替代结构的大小。
等于76个字节。
也就是说,在最坏的情况下,我们谈论的是在历史下载期间流量增加65%,以及终端和测试人员(包括代理)的内存消耗。显然,只是一些65%的人不能阻止你。原因显然是不同的。
如果你不相信你的对手的话,那么说话还有什么意义?
MqlRates 的大小。
等于(如果我没有弄错的话)46个字节。
替代结构的大小。
等于76个字节。
也就是说,我们谈论的是在最坏的情况下,终端和测试人员(包括代理)在历史下载和内存消耗期间的流量增加65%。显然,只是一些65%的人不能阻止你。原因显然是不同的。
我得到了48个字节。
谁说做空是不够的--让他成为第一个向我抛出至少一个例子的人(无论如何,来自证券交易所或外汇)。条形结构的大小 是最重要的特征,它按比例影响着终端所消耗的资源量。
我们始终面临着节约资源的任务,所以这种形式的延期是不合适的。
Renat,是否有任何尝试来优化MqlRates 的结构?例如,如果现在的精度限制在小数点后五位,为什么我们还需要OLHC的双倍(8字节)精度值?为什么不把这些值存储为归一化的3位或5位int,这样占用一半的内存?
用这种方法可以写出的最大数值是 42949.67295。
是否有任何OLHC的外汇数据会超过这个限制?
是否有OLHC的外汇数据会超出这个界限?
我得到了48个字节。
谁说做空是不够的--让他成为第一个向我抛出至少一个例子的人(无论如何,来自证券交易所或外汇)。也就是说,我们谈论的是在最坏的情况下,终端和测试者(包括代理)下载历史和内存消耗的流量增加了65%。
Vladix:
例如,如果.....................,为什么OLHC值需要双倍(8字节)的精度?
这是顺便说一下,是的。
很有可能被以下内容取代而且没有人受到影响。然后大小神奇地恢复到46字节。)
我得到了48个字节。
谁说做空是不够的--让他成为第一个向我抛出至少一个例子的人(无论如何,来自证券交易所或外汇)。