MT5への願い - ページ 23

[Вадим]

プログラムの最後に授業の内容を説明できず、最初にしか説明できないのは不便だ。

[Вадим]

Wordのように、編集ウィンドウを独立した2つのウィンドウに分けるスライダーをエディタに作ると良いと思います。番組の2つのコーナーをコピーして書き、同時に見ることができると便利です。

[Yuriy Zaytsev]

MetaDriver:

願わくば...

ただし、週末だけは例外で、省略することもできますが、異なる楽器間の同期が保証されています。

週末になるとFXが稼働することをご存知ですか？

ただ、ほとんどのブローカーはうまくいかない。

---

また、週末に見積もりをして、注文の作業をさせてくれるところもあります。

は、とても便利です。

週末は流動性がないのでスプレッドを広げることができる

とはいえ、ごまかしもあり、変えもあり

[Вадим]

という形の文字列を扱う関数を標準ライブラリに 追加するのが良いだろう。文字列を "begin", "end "で限定したモジュールに分解し、文字列の配列に書き込む。例：int count=(string, array,"<h1>","</h1>",flag); stringは入力文字列、arrayは出力文字列の配列、"<h1>" は出力文字列。- 文字列の中のモジュールの始まり、"</h1>"- モジュールエンドを文字列で表す。flag - 出力配列の文字列にモジュールリミッターを含めるかどうかを指定します。 count - 見つかったモジュールの数。

この場合、int count=(string, array,"<h1>","</h1>",flag); - 文字列に含まれるすべてのヘッダーの配列を作成します。

[Rashid Umarov]

これは既存のツールでも可能です。MQL4でHTMLを解析する 記事を参照してください。

[Вадим]

Rosh:
これは既存のツールで可能です。MQL4ツールでHTMLを解析 する記事を参照してください。

まあ、既存のツールでステップバイステップでできることは確かなんですけどね。でも、2ページ分のコードを書くより、すべてを一度にやってくれる既成の関数が1つあったほうがいいですよね......。

[Dmitry Voronkov]

Rinng:
まあ、使えるツールで段階的にやっていくのは理解できるんですけどね。でも、2ページ分のコードを書くより、すべてを一度にやってくれる既成の関数があったほうがいい......。

ライブラリやmqhファイルに追加すれば問題なし ;))

[Вадим]

エディターでは、プログラムコードのいくつかのブロックを隠したり開いたりすることができると便利です。例えば、「関数」、「定義」、「クラス」などです。また、for、ifなどのサブコードを隠したり開いたりすることができます。

[x572intraday]

Rosh писал(а) # :
データアクセスのオーガナイズを 読むと、正しい履歴の要求の仕方が書いてあります。

報告する。と仕切られた。そして、私がマスターしたもの。必要であれば、把握することは十分に可能です。私はまだMQLを学んでいないので、この言語に関する質問はほとんど馬鹿馬鹿しいものになる恐れがあります。

もうひとつわからないことがあります。「パラメータ "Max bars in charts" は、HC形式のチャート、インジケータ、mql5-プログラムで利用可能なバーの数を制限します。この制限はすべてのタイムフレームデータに適用され、主にリソースを節約するために設計されています。

このパラメータを高く設定する場合、低い時間枠の価格データの履歴が十分に深い場合、時系列と指標バッファを格納するためのメモリ消費量が数百メガバイトに達し、クライアント端末プログラムのメモリ制限（MS Windowsの32ビットアプリケーションでは2GB）に達することがあることを忘れてはいけません。

おそらく、このエピソードで何が何だかよく理解できていないと同時に、今ここでMQLプログラムについて質問するつもりはないことを改めて強調しておきますが、上記のリソース節約の動機は、チャートを直接手動で操作する際にターミナルが自動的に履歴を要求することと関連して違和感があるようです。あなたのコードは閉じているので、どのように動作しているのか判断できません。各ローソク足が、大量のプロパティや属性を持つ実オブジェクトなのか、それとも市場の構造イメージを簡略化したグラフィック描画/レンダリングなのかは分かりませんが。失われた歴史をダウンロードするという話題を省き、すでにある歴史に注目すると、描画方法の合理性に疑問を投げかけることになるのです。設定でチャートのバーを一定かつ大量に設定しても、チャートのバーを針で圧縮しても、モニターの解像度を非常に高くしても、履歴DBMSから画面に正しくバーが読み込まれていれば、全体像がRAMを使うとは思えません。後入れ先出しの原則を採用していますか？チャートのバーの最大数は無限に増やせますが、画面の後ろにあるもの（左右両方）は一切メモリに入れず、スクロールするときはメインメモリにロードして瞬時にアンロードする必要があります。これは、ネットワークではなく、ローカルにある履歴だけを操作しているためです。どんな恐ろしい2Gbの制限があるんだろう？

...おそらく、私はとても蚊帳の外なので、あらかじめ赤裸々なことを許してください。

[Renat Fatkhullin]

各価格バーはMqlRates 構造体（他の特性はなし）で記述され、サイズは52バイトである。

struct MqlRates
  {
   datetime time;         // время начала периода
   double   open;         // цена открытия
   double   high;         // наивысшая цена за период
   double   low;          // наименьшая цена за период
   double   close;        // цена закрытия
   long     tick_volume;  // тиковый объем
   int      spread;       // спред
   long     volume;       // объем
  };

作業用データベースのサイズを見積もるには、/bases/サーバー名/symbol/という ディレクトリを見る必要があります。例えば、EURUSDの場合、以下のように表示されます。

このディレクトリには、取引サーバーから提供されたオリジナルの圧縮された分コンテナが置かれています。分コンテナは、1年間で平均約15MBかかることがわかります。これはトラフィックを最小限に抑えるための非常に特殊な圧縮形式です。

cacheディレクトリには、必要に応じて圧縮された作業用データベースが格納されています。

ご覧のように、1993年以降、分（実際には1999年までは分の代わりにdaypartsを使用）は約231メガバイトに圧縮されずにそのまま使用できる状態になっています。隣接するクロックはわずか4mbしか消費しません。

52バイトに4 400 000バーをかけると、約230MBになります。1つの作業バッファ（2倍）を持つ単純な移動平均インジケータは、4 400 000 * 8 = 35メガバイトのメモリを必要とします。

トレーダーが端末の設定で「ウィンドウ内の最大バー数」を設定する際、「作業用にメモリに読み込むバー数は指定した数まで」と明示的に指定しています。分履歴全体がロードされ（私たちはM1チャートで作業します）、いくつかの重いマルチバッファインジケータが適用され、Expert Advisorが使用される場合、メモリコストが大きくなる可能性があります。また、「1つのウィンドウで作業して500本のバーを見ているから、残りをアンロードすればいい」という考え方もできません。インジケータ、Expert Advisorなどは、このデータ上で動作しているため、アンロードすることはできません。

データと指標を常に一つの数値で保存する場合、非常に効果的なキャッシュモデルを実装しています。つまり、EURUSD:M1で5つのウィンドウを開いても、5つのデータバッファを作成する必要はなく、パラメータが完全に等しい複数のインディケータが1つのコピーを持つだけでよいのです。指標やチャートを長期間使用しない場合、そのデータは自動的に解放され、必要に応じて復活させることができます。

また、クライアント端末は64ビット版を用意し、膨大な履歴を制限なく扱えるようにしています。このバージョンは、MQL5の64ビット環境でのテストが終了次第、リリースされる予定です。