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 を使い分ける理由を正直に答えてください。5つの番号ではなく、8つの番号を格納する（バーと履歴のフォーマットは変更しにくい）？提供される履歴の量に大きな影響を与えるか？それとも、Askの価格履歴がないだけ？テスターのロジックが複雑になるのでは？さて、2つ目のケースではもっと単純で、スプレッドという概念は全くありません。何がそれを止めているのか、正直に言いなさい。
バー構造の大き さは、端末が消費する資源量に比例して影響する最も大きな特性である。
私たちは常に省資源という課題に直面しており、このような形での拡大は適切ではありません。
MqlRatesの サイズです。
イコール（私の記憶違いでなければ）46バイトです。
代替構造の大きさ。
76バイトに相当します。
つまり、履歴のダウンロード時のトラフィックと、端末とテスター（エージェントを含む）のメモリ消費量が、最悪の場合で65%増加するという話です。明らかに、いくつかの65％だけでは止められない。理由は明らかに違う。
相手の言葉を信じられなければ、話す意味がないのでは？
MqlRatesの サイズです。
イコール（私の記憶違いでなければ）46バイトです。
代替構造の大きさ。
76バイトに相当します。
すなわち、履歴ダウンロード時のトラフィックと、端末とテスター（エージェントを含む）のメモリ消費量が、最悪のケースで65%増加するという話である。明らかに、いくつかの65％だけでは止められない。理由は明らかに違う。
48バイトになった。
空売りが十分でないと言う人は、少なくとも一つの例を私に投げかけてください（証券取引所やFXの例です）。バー構造の大き さは、端末が消費する資源量に比例して影響する最も大きな特性である。
私たちは常に省資源という課題に直面しているので、このような形での延長は適切ではありません。
Renatさん、MqlRatesの 構造を最適化するような試みはありますか？例えば、OLHCの精度が小数点以下5桁までとなったのに、なぜ倍精度（8バイト）の値が必要なのでしょうか？これらの値を3桁または5桁のint型に正規化した値として格納すれば、メモリ使用量は半分で済むのではないでしょうか？
この方法で書ける最大 値は42949.67295です。
この限界を超えるようなOLHCのFXデータはあるのでしょうか？
この境界を超えるようなFXのOLHCデータはあるのでしょうか？
48バイトになった。
ショートでは十分でないと言う人は、少なくとも一つの例を私に投げかけてください（証券取引所やFXの例です）。つまり、履歴をダウンロードするためのトラフィックと、端末とテスター（エージェントを含む）のメモリ消費量が、最悪の場合65% 増加することを話しているのです。
Vladix:
例えば，OLHCの値に倍精度（8バイト）が必要な理由は，............................．
ちなみに、YESです。
に置き換わる可能性は大いにあります。そして、サイズは魔法のように46バイトに戻ります。）
48バイトになった。
ショートでは十分でないと言う人は、少なくとも一つの例を私に投げかけてください（証券取引所やFXの例です）。