記事"MetaTraderプログラムを簡単かつ迅速に開発するためのライブラリ(第17部): ライブラリオブジェクトの相互作用"についてのディスカッション - ページ 2

新しいコメント
 
Igor Makanu:

一連の記事で提案されている最小限の機能（シンボルの 印刷プロパティ）を使用することについて話しているのだ。

最小限のことは言えません。

TestDoEasyPart17.ex5
1 085 494 bytes - Release.
  644 140 bytes - Debug.

リソースがないからです。それらはアーカイバによって圧縮されないので、大量のテキストメッセージの結果ではないことは間違いない。

 
fxsaber:

最低限のことは言えない。

リソースがないので、ちょっと多いですね。それらはアーカイバによって圧縮されていないので、大量のテキストメッセージの結果ではないことは間違いない。

ありがとう！- インストールしたくないので、しばらく待ちます。

さて、あなたは不在のパフォーマンスを決定した - あなた自身がコンパイラがすべての不要なものを捨て、.ex5の重量はかなりまともであることが判明し、上に書いた。

オプティマイザーに連載記事の出来合いのライブラリ（クラス）を使うことに疑問はないだろうから、作業の結果が使い勝手につながることを祈るしかない。

ZY：テストにどれだけの労力と時間を費やしたか知らないが、KBのライブラリは本当にRAD（GUIなし）で動いている。

 
Igor Makanu:

あなたは上で、コンパイラーは不必要なものをすべて捨ててしまうと書いている。

私自身、少々驚いている。正しいベンチマークを行うためには、コンパイラが計測したフラグメントを捨てないようにコードを書かなければならなかった。そうでなければ、コンパイラの時間はゼロになってしまう。

 
fxsaber:

私自身も少々驚いている。正しいベンチマークを行うためには、コンパイラが測定した部分を捨てないようにコードを書かなければならなかった。そうでなければ、その時間はゼロになるはずだった。

各ライブラリ・コレクションは1つのオブジェクトで構成されている。各オブジェクトは、タイマーの中でオブジェクトをスクロールし、その中にあるオブジェクトへのポインタを参照する。不要なクラスはまだ無効にしていない。今のところ、必要な情報を収集するためのワークホースを作っているだけだ。
 
Artyom Trishkin:
今のところ、必要な情報を収集するためのワークホースを作っているだけだ。

記事の量は非常に多く、すべてを読むことはできないだろう。

まず第一に、私は取引操作と 注文サポートの方法論に興味がある - いつ待つべきか？

SUS：記事の閲覧数は、登録ユーザーのみから追加されるのですか、それともインターネットからの任意の閲覧から追加されるのですか？

 
Igor Makanu:

記事の量は非常に多く、全部を読むことはできない。

主に取引操作と 注文サポートの方法論に興味がある - いつ待つべきか？

SZY：唯一の登録ユーザーからの記事の閲覧数が追加され、またはインターネットからの任意の表示から？

1.すでに行われているすべてがすでに使用することができます。方法論 "質問-回答 "の助けを借りて、非常に単純ですが、作成された各クラスをテストするEAは、使用するために非常に適しているデータへのアクセスを示しています。
2-取引は途中です。間もなく登場する。しかし、1つの記事ではありません。
3.メンテナンスとはどういう意味ですか？すべてのトレード環境データはとっくにできている。注文やポジションで発生したイベントはプログラムに送られます。テスト用のExpert Advisorがあります。イベントへのアクセスもそこに表示されます。後で説明するように、シンプルで便利なものではありませんが、使用には適しています。もし気になることがあれば、ディスカッションで質問してみてください。
4.4.統計がどのように作られているのか分かりません。
 
Artyom Trishkin:

3.メンテナンスとは何か？取引環境に関するすべてのデータはとっくに終わっている。注文やポジションで発生したイベントはプログラムに送信されます。テスト用Expert Advisorがあります。イベントへのアクセスもそこに表示されます。後で説明するように、単純で便利ではありませんが、使用には適しています。実装方法に興味があれば、ディスカッションで質問してほしい。

メンテナンスというのは、未決済注文のプロパティ（取引注文、ポジションなど。）

また、この未決済注文のアクション（クローズ、トレイリング、部分クローズ....(さらに複雑にすれば、平均化などにもなるが、これはすでにトレーダーのフォーラムで考案された慣例である。）

 

私はアルゴリズムの取引には携わっていないが、著者のコードとアイデアを掘り下げてみることにした。最初の段落を読んで、著者はまずヘーゲルの『論理の科学』を読み直し、それをプログラミングすることにしたのだと感じた。すべてはコードによる哲学なのだ。あらゆるところから、戦車の艦隊のように、その威厳ある抽象化がやってきて、床を乱雑にし、著者の世界ではそこから、出来事、プロパティ、オブジェクトを交差させることによって生まれた新しい新しい実体が耕されている。プロパティはもはや単なるプロパティではなく、"オブジェクト "のランクにまで上がっていることに注目してほしい。自ら成長し、自らの特性を獲得すると主張している。しかし、そのプロパティが独立を主張し、自らのオブジェクトの大群を生み出さないという保証はどこにあるのだろうか。結局のところ、著者の世界では、すべての実体は物体になろうとし、すべての物体は特性の武器を増やそうとする。この原理に従って、物質は急速に膨張する。まるで哲学的なメカニズムが「行き詰まった」かのように。しかし結局のところ、この物質的なプリズムは、この美しく、超現実的で、はかない世界を、この資源の博物館作品に変えてしまうのではないかと私は恐れている。悪い頭の体操ではないが。私はこの記事を支持する。）


ZЫ.オブジェクトの 各派生プロパティの 状態リストについて忘れていた。そうなると、この連載に終わりはなくなる))
 
Igor Makanu:

メンテナンスとは、未決済注文のプロパティ（取引注文、ポジションなど）を取得することです。

また、この未決済注文を使ったアクション：クローズ、トレーリング、部分クローズ...。(さらに複雑にすれば、平均化などにもなるが、これはすでにトレーダーのフォーラムで考案された慣例である。）

注文のプロパティが取得できる。ポジションのプロパティも取得できる。ポジションのプロパティから、取引注文から決済までの全履歴を取得できます。ポジションの各取引では、取引に使用された注文を調べることができます。一般的に、ポジションの全履歴を簡単に取得することができ、その中にすべての注文と取引が含まれます。

ポジションに関するアクションはまだ整理されていません - 新規/決済/変更 - これらはすべて取引クラスで行われます。

 
Реter Konow:

私はアルゴリズムの取引には携わっていないが、著者のコードとアイデアを掘り下げてみることにした。最初の段落を読んで、著者はまずヘーゲルの『論理の科学』を読み直し、それをプログラミングすることにしたのだと感じた。すべてはコードによる哲学なのだ。あらゆるところから、戦車の艦隊のように、その威厳ある抽象化がやってきて、床を乱雑にし、著者の世界ではそこから、出来事、プロパティ、オブジェクトを交差させることによって生まれた新しい新しい実体が耕されている。プロパティはもはや単なるプロパティではなく、"オブジェクト "のランクにまで上がっていることに注目してほしい。自ら成長し、自らの特性を獲得すると主張している。しかし、そのプロパティが独立を主張し、自らのオブジェクトの大群を生み出さないという保証はどこにあるのだろうか。結局のところ、著者の世界では、すべての実体は物体になろうとし、すべての物体は特性の武器を増やそうとする。この原理に従って、物質は急速に膨張する。まるで哲学的なメカニズムが「行き詰まった」かのように。しかし結局のところ、この物質的なプリズムは、この美しく、超現実的で、はかない世界を、この資源の博物館作品に変えてしまうのではないかと私は恐れている。悪い頭の体操ではないが。私はこの記事を支持する。）


ZЫ.オブジェクトの 各派生プロパティの 状態リストについて忘れていた。それではこの連載に終わりはないだろう（笑)）。

シュルレアリスム、ピーター、それはあなたの頭の中にしかない。そしてすべてがシンプルなので、大きな機構の歯車に至るまですべてを1つの巨大な配列に詰め込んで記憶する必要がある手続き的な世界観のもとで研ぎ澄まされた頭脳では想像すらできない。

そしてここでは、すべてがその場所にあり、どの場所へのアクセスも、場所の座標だけでなく、必要なオブジェクト（ただし、これらはその座標である）の実質的に求められるプロパティのどれかを指定することによって、外部から行われる。

花輪を想像してみよう。想像しましたか？そのどの場所へのアドレスも、目的のオブジェクトの番号（プロパティ）で指定できる（これがライブラリーの基本）。他の花輪をオブジェクト（これはすでに2次元のテーブルである）、つまりオブジェクトのコレクションとして使用する。そして、これらのオブジェクトのガーランド-コレクションのそれぞれに、同じタイプのオブジェクトがある。オブジェクト1、オブジェクト2、オブジェクト3、...、オブジェクトN。これはすでに3次元のテーブルである。コレクションの型と探しているオブジェクトの型を指定すれば、どのオブジェクトにもアクセスできる。そして、必要なプロパティを取得する。

それだけだ。

戦車もエイリアン軍団もいらないよ、ピーター :)

そして一番面白いのは、すべてのオブジェクトにこの機能を追加するためには、たった一つのオブジェクトに追加するだけでいいということだ。

いかにシンプルかわかるだろうか？そうだろう？それなら、私はあえてあなたの考えを変えるつもりはありません。

そのようなオブジェクトはそれぞれ独立して、その状態をプログラムに通知することを忘れていた。

1234
新しいコメント