これを考えてみよう："...thesize of the controlled change and the size of the controlled level of the object property value."（コントロールされる変化の大きさと、オブジェクトのプロパティ値のコントロールされるレベルの大きさ）。オブジェクトのプロパティの値の制御されたレベルの大きさ」とは何か？すなわち、1.オブジェクトのプロパティがある。2.その特性には管理されたレベルの値がある。3.管理されたレベルにはn個の値があり、....4.4.制御される変化の大きさもあり、それは様々である。エンティティの数が多すぎると思いませんか？これは、あなたの記事の哲学の海の一滴に過ぎない。
これを考えてみよう："...thesize of the controlled change and the size of the controlled level of the object property value."（コントロールされる変化の大きさと、オブジェクトのプロパティ値のコントロールされるレベルの大きさ）。オブジェクトのプロパティ 値の制御されたレベルの大き さ」とは何か？つまり、1.オブジェクトのプロパティがある。2.そのプロパティには制御された値のレベルがある。3.3.コントロールされたレベルにはn個の値があり、....4.4.制御される変化の大きさもあり、それは様々である。エンティティの数が多すぎると思いませんか？これは、あなたの記事の中の哲学の海の一滴に過ぎない。
オーダープロパティが得られる。ポジションのプロパティも取得できます。ポジションのプロパティからは、取引注文から決済までの全履歴を取得できます。ポジションの各取引では、取引に使用された注文を知ることができます。一般的に、ポジションの全履歴を簡単に取得することができ、すべての注文と取引を見つけることができます。
素晴らしい！
MT5の注文システムがどのように構成されているのか、ご存知なのですね（残念ながら、このフォーラムにはこのような情報を持っている人はほとんどいません）。
この資料を見つけることができる記事の番号を教えてください。
素晴らしい！
あなたがMT5の注文システムの仕組みについて知識を持っていることは知っています（残念ながら、このフォーラムにはこの情報を持っている人はほとんどいません）。
この資料がどこにあるか教えてください。
最初のパートでは、ライブラリの一般的な構造について説明します（説明されているものとほとんど変わりませんが、説明の過程で改良が加えられています）。
第2部では、注文とポジションのコレクションの作成が始まります。第4 部では、トレーディング・イベントが議論され始める......。そして、このすべてが第9回まで 続き、そこでMQL4との互換性への最終調整が始まる。
シュルレアリスムは、あなたの頭の中にしかない。
このような "理想的な計画 "を構築することの実用性を忘れて、あなたはあまりに深い哲学に入り込んでいる。 以下、いくつか引用しよう：
"今日はもう少し踏み込んで、このオブジェクトに、そしてライブラリの他のオブジェクトにも、どのプロパティの変更を外部から制御するか、制御される変更の大きさ、オブジェクトのプロパティの値の制御レベルの大きさを設定する能力を与えよう。"
これを考えてみよう："...thesize of the controlled change and the size of the controlled level of the object property value."（コントロールされる変化の大きさと、オブジェクトのプロパティ値のコントロールされるレベルの大きさ）。オブジェクトのプロパティの値の制御されたレベルの大きさ」とは何か？すなわち、1.オブジェクトのプロパティがある。2.その特性には管理されたレベルの値がある。3.管理されたレベルにはn個の値があり、....4.4.制御される変化の大きさもあり、それは様々である。エンティティの数が多すぎると思いませんか？これは、あなたの記事の哲学の海の一滴に過ぎない。
さらに
"ここでは、オブジェクトのプロパティの状態の変化を制御するのに適しています：整数と実数 - 各継承者クラスのためのそれらのリストは一意であり、イベントの識別子を 表すことになります。また、プロパティの値の増加または減少というプロパティの変化の方向も考慮する必要があります。イベントの識別子、その原因、変更の値は、オブジェクトのベース・イベントのシンプルなクラスに記録され、同時に発生したイベントのリストに保存されます。"
見つかったエンティティを列挙してみよう：
1.「オブジェクトのプロパティの状態変化」。つまり、オブジェクトにはプロパティがあり、プロパティの状態がある。表向き、プロパティの状態とはその値を意味する。しかし、その値は、そのプロパティを型と するオブジェクトとして 表現することができる。つまり、プロパティの状態（値）を整数型と実数型に分けるのだ。そして、そのクラスの後継者のオブジェクトの整数と実数のプロパティの状態を表すユニークなリスト（いつ登場したのか正確には知らない）への参照があった。
2.「2.プロパティの変化の方向"まあ、それははっきりしている。しかし、なぜ変化の方向が 事象の原因なのか。原則として、方向 そのものではなく、方向が変化する ことが事象の原因なのである。
3. 「イベントの識別子、原因、変化の値をオブジェクトのベース・イベントのシンプルなクラスに書き込んで、同時に発生したイベントのリストに保存する。
なるほど、これはすごい。イベント識別子がある。いいことだ。イベントの原因があり、何かの変化量（抽象的には変化量）がある。しかし、シンプルな基本イベントクラスがある！繰り返すが、シンプルなベース・イベント・クラスだ！抽象からの抽象。イベントは、 それ自体として、 そのクラスを見つけた！しかし、それはオブジェクト・イベントに過ぎない。だから、プロパティ・イベントやバリュー・レベル・イベント（プロパティ・ステート）もあり得る。
そしてケーキの上のチェリー：
4."そして、同時に発生したイベントのリストに格納する"。つまり、同時発生イベントのリストも存在する。そして、なぜか...。しかし、それなら、他のイベントとの相対的な時間差を管理したレベルのイベントのリストがあるはずだ。それは追加できるよね？)
これは、このシリーズの大きな記事のほんの一部に過ぎない。とてもシンプルだと思いますか？))私は、天職として哲学者になるはずだった人の興味深いプログラム実験として、あなたの記事を研究するつもりである))
そのような "理想的なスキーム "を構築することの現実性を忘れて、哲学に深入りしすぎている：
"今日はもう少し踏み込んで、このオブジェクト、ひいてはライブラリの他のオブジェクトに、どのプロパティの変化を外部から制御するか、制御される変化の大きさ、オブジェクトのプロパティの値の制御されるレベルの大きさを設定する能力を与えよう。"
これを考えてみよう："...thesize of the controlled change and the size of the controlled level of the object property value."（コントロールされる変化の大きさと、オブジェクトのプロパティ値のコントロールされるレベルの大きさ）。オブジェクトのプロパティ 値の制御されたレベルの大き さ」とは何か？つまり、1.オブジェクトのプロパティがある。2.そのプロパティには制御された値のレベルがある。3.3.コントロールされたレベルにはn個の値があり、....4.4.制御される変化の大きさもあり、それは様々である。エンティティの数が多すぎると思いませんか？これは、あなたの記事の中の哲学の海の一滴に過ぎない。
さらに：
「オブジェクトのプロパティの状態変化を制御するのに適しているのは、整数と実数である。また、プロパティの値の増加や減少といった、プロパティの変化の方向も考慮する必要があります。これをイベントの 原因と呼び、 オブジェクトのプロパティが変化 した値も 考慮する必要があります。イベントの識別子、その原因、変更の値は、オブジェクトのベース・イベントのシンプルなクラスに記録され、同時に発生したイベントのリストに保存されます。"
見つかったエンティティを列挙してみよう：
1.「オブジェクトのプロパティの状態の変化」。つまり、プロパティがあり、オブジェクトのプロパティの状態がある。プロパティの状態とは、その値を意味するらしい。しかし、その値は、プロパティを型と するオブジェクトとして 表すことができる。プロパティの状態（値）を整数型と実数型に分けたわけだ。それから、クラスの後継者であるオブジェクトのプロパティの整数と実数の状態を表すユニークなリスト（正確にはいつ登場したのかわからない）への参照があった。
2.「2.プロパティの変化の方向"まあ、値の増減が変化の方向であることは明らかだ。しかし、なぜ変化の方向が 事象の原因なのか。原則的には、方向が変わる ことが事象の原因であって、方向そのものが原因ではありません。
3. "イベントの識別子、その原因、変化の値は、オブジェクトの基本イベントの単純なクラスに記録され、同時に発生したイベントのリストに格納される。"
なるほど、これはすごい。イベントの識別子がある。いいね。イベントの原因があり、何かの変化量（抽象的には変化量）がある。しかし、シンプルな基本イベントクラスがある！繰り返すが、シンプルなベース・イベント・クラスだ！抽象からの抽象。イベントは、 それ自体として、 そのクラスを見つけた！しかし、それはオブジェクト・イベントに過ぎない。だから、プロパティのイベント、値のレベル（プロパティの状態）が存在しうる。
そしてケーキの上のチェリー：
4."そして、同時に発生したイベントのリストに保存する"。つまり、同時発生イベントのリストも存在する。そして、なぜそうしないのか...。でも、それなら、他のイベントとの相対的な時間差がコントロールされたレベルのイベントのリストがあるはずです。追加できるよね？）
これは、このシリーズの大きな記事のほんの一部です。とてもシンプルだと思いますか？))私は、天職として哲学者になるはずだった人の興味深いプログラム実験として、あなたの記事を研究するつもりです))
あなたの頭の中はなんと複雑なのでしょう。
あなたは自分で複雑さを作り出している。
私は説明するのがとても下手なのかもしれませんが...。
私たちには価格がある。価格はシンボルの特性です。価格には変化する能力がある。上昇する方向にも、下落する方向にも。その大きさ（価格の増減をコントロールし、設定する権利、これが「コントロールされた変化の大きさ」である）。そしてまた、価格は設定された（プログラムの中で私たちによってコントロールされた）値を越えることができます。
明確ですか？
私たちにはスプレッドがあります。スプレッドはシンボルのプロパティです。スプレッドは変化する可能性があります。増加する方向にも、減少する方向にも。大きさ（スプレッドが増加または減少した量、私たちは制御し、設定する権利を持っている - これは "制御された変化の大きさ"です）。また、スプレッドは設定値（プログラム内で私たちがコントロールする）を超えることができます。
お分かりいただけただろうか？
これらは同じオブジェクト、つまりシンボルの2つの異なるプロパティに過ぎない。現在のものとしましょう。異なるシンボルのプロパティであっても、オブジェクトは異なりますが、同じ種類のオブジェクトのプロパティは同じです。そして、同じ種類のオブジェクトの同じプロパティに対するコントロールも同じである。その通りだ。なぜなら、それはひとつの基本オブジェクトの中で実行され、すべてのオブジェクトはそれを受け継ぐからである。そして、それはすべてのオブジェクトにとって同じである-すべてにとって同じではないが、同じである。
つまり、1つの同じオブジェクトの異なるプロパティを異なる方法で制御することができる。各プロパティの制御メソッドを作ることもできるし、各プロパティの制御を記述し、それに頼ることもできる。あるいは、どのオブジェクトのどのプロパティでも制御できるように、1つのメソッドを書くこともできるし、各プロパティに対して何トンものコードを書くのではなく、すべてのプロパティに対して1つのメソッドだけを一度に書くこともできる。
そして、オブジェクトが自身のイベントをリストに記録した後（これらのイベントは基本イベントと呼ばれ、絶対にすべてのオブジェクトが持っている）、プログラムがイベントを送信する。本格的なイベントは、ユーザーがすでに処理して判断することができる。そして、それを明確に記述する。そのためのパラメータが3つある：
結論：私たちは、(1) イベントを送信したのがシンボルであること、(2) - プロパティが管理レベルより低くなったこと、(3) - このプロパティが入札価格であることを確実に知っています。
複雑？簡単なことだ。
簡単だ：
取引許可が出ました。取引許可は口座のプロパティです。取引許可は変更可能です。そしていくつかの値によって。サイズ（取引許可が変更された値を制御し、設定する権利を持っている - これは "制御された変更のサイズ"です）。そしてまた、貿易への許可は、我々はまた、設定することができます（プログラムで私達によって制御される）値を、交差することができます - これは "オブジェクトのプロパティの値の制御レベルのサイズ"であり、例えば - 買うためにポジションを開くことの禁止があります。
そして結局のところ、これは - 全く別のオブジェクトは、イベントが構築されているシンボルによって送信されたのと同じコードをプログラムに送信します。そして、このすべては、すべてのオブジェクトの1つのオブジェクトの基礎の1と同じ方法で行われます。
お分かりいただけただろうか？
そして一般的には、すべてのことは記事に書かれている。しかし、あなたはただ荒らしているように見えますか？:)このような質問をするためには、単純なデータの構成について掘り下げるのではなく、「ここではすべてがどのように実行されているのか」という姿勢で読むべきです。
...複雑？簡単なことだ。
記事の著者の典型的な間違いは、その内容が自分にとって明確であれば、誰にとっても明確であると考えることである。）しかし、そうではない。
あなたの説明で多くのことが整理されたので、それを記事の中に（例えば冒頭に）書いておけば、さらに明確になっただろう。それに、私はあなたを荒らしているわけではない。ただ、（正当で必要なことではあるが）抽象化の流れに具体性が混ざらず、互いに言及し説明し合わない（抽象化が優先され始める）と、上に述べたような意見が出てくるのだ。
S.F.一般的に、私が理解したように、あなたはアルゴ・トレーディングのすべてを一般化し、このライブラリに集めようとしています。
論文の著者の典型的な間違いは、その内容が自分にとって明確であれば、誰にとっても明確であると考えることである。）しかし、そうではない。
あなたの説明によって多くのことが整理されたのだから、それを記事の中に（例えば冒頭に）書いておけば、より明確になったはずだ。それに、私はあなたを荒らしているわけではない。ただ、（正当で必要なこととはいえ）抽象化の流れに具体性が混ざらず、互いに言及し説明し合わない（抽象化が優先され始める）と、上で述べたような意見が生まれるということだ。
S.F.一般的に、私が理解したところでは、このライブラリーではアルゴ・トレーディングのすべてを一般化して集めようとしていますね。
私がやりたいのは、どんな複雑なアルゴリズムでも簡単にプログラムを作成できるツールを提供することです。
このライブラリーは、いつも自分で書かなければならないルーチンをすべて引き受けてくれる。
ユーザーは、"質問をする-答えを得る-それを処理する "だけでいい。
そして、ライブラリ自身がその出来事を思い出させてくれる。つまり、原理的には、どのようなイベントが、どのようなオブジェクトから発生したかを確認し、その後、考え出されたロジックに従ってそれを処理するだけで十分なのである。
ユーザーは、最後のポジションがどのようにクローズされたかを尋ねることができる。
あるいは、最後に閉じたポジションを尋ねて、それを構成要素ごとに解析することもできます - ライブラリでは、ユーザーがライブラリデータから取得したポジションに関するすべてのデータを得ることができます。
または、このようにすることもできます：プログラムは、このようなシンボルでこのようなポジションがオープン/クローズされた、またはこのような注文が設定/削除されたというイベントを受信します。プログラムは何もリクエストを送信していないが、環境が変化した。
原理的には、いろいろなことを考え、実装することができる。自動的なもの - すべてがすでにそこにあり、自分で発明する必要はない - 準備して慎重に与えるだけでいい ;)
記事の著者の典型的な間違いは、その内容が自分にとって明確であれば、誰にとっても明確であると考えることである。）しかし、そうではない。
...そして、一部の読者の典型的な間違いは、読まずにすぐに質問をすることである :)
最初の記事から読み始めれば、そのような質問はないだろう。なぜなら、「哲学」のすべてがそこにあり、説明されているからだ。
アルテム、ありがとう！
やめないで、書き続けて。
ピーターとの議論、興味深く読んだよ。とても正しく、的を得ている。
私はプロセッサーの設計や 製造には携わっていませんが、皆さん、8nmプロセスはナンセンスです。
返事を待っているところだ。
そのような "理想図式 "を構築することの実際性を忘れて、あなたはあまりに深い哲学に入り込んでしまった．
ここでいう哲学とは、帰納法（特殊から一般へ）か演繹法（一般から特殊へ）かということだ。
アルチョムは帰納法を用いている。
主席：さて、グレブ・ゲオルギエビッチ、弾丸です。あなたの判断は
ゼグロフ：えーと、「知性」とでも言うんですか？
シャラポフ：弾丸は普通のピストルの弾丸と同じですが......。
チェグロフ：ええ、薬きょうを見つけるのがいいでしょう。
署長：武器そのものを調べたほうがいい。
ゼグロフ：そうです、つまり、バヤール式かオメガ式の6.35口径の輸入 銃から発射された弾丸ということです。
署長：どういう意味ですか？
弾丸だよ、セルゲイ・イパティッチ、弾丸。左の6本のライフリングの切り口、それだけです。
課長：それはどうでしょう。マークから判断して、カートリッジケースは我々のものだ。
ゼグロフ：はい、どこで見つかったのですか。
署長：あるべき場所にあります。死体の左側です。反射板は正常に作動しました。
チェグロフ：はい、薬きょうは我々のものです。そうか。じゃあ、謎の中に入れておこう。まだ武器を探さなければならない。ナデシュダ、この家に武器があったかどうか知ってる？
ナデシュダ：知らないわ。
[ワイナース 慈悲の時代]
アルテム、ありがとう！
やめないで、書き続けて。
ピーターとの議論、興味深く読んだよ。とても正しく、的を得ている。
私はプロセッサーの設計や製造には携わっていないが、君たちは8nmプロセスについてナンセンスな議論をしている。
返事を待っているところだ。
こんにちは、アレクセイ。
なぜ旅の始まりで立ち止まるのですか？考えるために立ち止まることはすでにすべて終わっている。）
さて、AMDからの返事はどうだったかな？