MT4はもう長くない - ページ 76

 
OnGoing:
個人的には、トレーディング・オペレーションのすべてが好きなわけではありません。シンタックス+実行。前者は複雑になりすぎ、後者は不器用になる。

トレードの 構文については、その通りです。もっと複雑なんです。一晩、二晩かけて解明してください。

それなら簡単です。結局、すべての設定は自分用に書かれた関数の中に隠されているのですから。ちなみに、私は取引には標準(ライブラリ)クラスを使っています。

そこに自分なりの便利な機能を追加して使っているだけなのです。

だるさについては、納得がいきません。ランタイムでは、すべてが非常に高速に飛びます。

ほとんどの場合、情報量や機能の多さから、主観的な印象にとどまっているのではないでしょうか。すべてが大きな、大きなことのように思えるのです。

そして、「大きいなら、知恵遅れだ」と直感するのです。理にかなっているように思います。しかし、そうではありません。すべてが非常に高速に動作します。非常に速い。4の時よりずっと速い。

テスターは基準ではありません。開発者のコンセプト上の誤算があったのです。もう直せ。

 
MetaDriver:
既成のクラスも使ったことがあります。しかし、この演奏は「ライブ」、つまりテスターではなく、デモを意味していたのです。
 
OnGoing:
既成のクラスも使ったことがあります。しかし、その実行は「ライブ」、つまりテスターではなくデモを意味していたのです。
そこからは想像もつかないほど、実行の速さが際立っていましたね。そこには、より速く取引を 行うための仕組みが実装されています。一般に、ファイブで質問すれば教えてくれるでしょう。もしかしたら、私でもそうなるかもしれません。)))
 
OnGoing:
既成の授業も使いました。しかし、実行は「ライブ」、つまりテスターではなく、デモを意味していたのです。

どうだろう。もちろん、実行は

1.ブローカー

2.Pingのことです。

ブローカーを揺さぶる - 彼は間違っている。最も可能性が高い。 念のため、Pingのチェックも...。

 
tol64:MT5では9 ヶ月間、アイデアを実行する上で、まだ限界に達することができません。

一般的にはそうですが、特に問題なのは、mql5で多次元の動的配列を扱うことができないことです。既製のCコードを移植するのは非常に困難です。

OnGoing:個人的には、トレーディング・オペレーションのすべてが好きなわけではありません。シンタックス+実行。前者は複雑になりすぎ、後者は不器用になる。

うーん、実際に取引業務を理解しようとしたことがあるのだろうか?周りの人が言ってるだけ?

このようなコードを書いてポジションを開くのは難しいのでしょうか?

CTrade order;
order.Buy(lot);
今度から 例えば、mql5ではカスタムインジケータを 作るのが大変だと書くと、それが真実のようになるでしょう。
 
こんにちは、mt5もGBOTの認証を受けていると読みました。トレーディング商品の歴史についてはどうでしょうか。取引所の会員であるブローカーがプラットフォームを購入し、そこに履歴をアップロードすること自体を待つしかないと思うのですが?
 
Mathemat:

...

そして、ビジュアル化されたものであれば、それもまた価値があるのです。何百ものトランザクションの結果を保存するよりも、このようにした方がずっと簡単です。

11.5千個のオブジェクトがあります。これは、ゼロ・ウインドウの紙面利益の曲線である。わかりやすく、図解で説明しています。ある瞬間にスクリーンショットを撮り、それを分析するのです。

同じCQGを使うことで、脳に負担をかけずに、すべてが素早く美しく仕上がると思っているのでしょうか?

ここに11,500ものオブジェクトは必要ありません。ここで必要なのは、バーの本数×2あたりのデータです。11,500個のオブジェクトが必要だとしたら、それは計算の問題ではなく、手法の問題です。
 

MetaDriver:
...
Так вот. В тех платформах, которые типа "для трейдеров", там тоже много чего не хватает. Причём, там это - невосполнимо.
Здесь же (MT4-MT5) я сам могу восполнить то, чего мне не хватает
...

要は、カスタマイズの選択肢が極限まで削られているわけで、この削減が今後も続かないという保証はない。例えば、明日起きたら、新しいMQハッピーレポートで、今後はソリューションの整合性を維持するために、サードパーティのDLLをプロジェクトにプラグインできないことを突然知ることになるでしょう。この不確実性とサードパーティ製品との統合を削減する明確な傾向により、MT5を大規模な取引 プロジェクト/インフラに統合する場合、MQのソリューションは非常にリスクが高いものとなっています。そして、「外」では、通常、このような厳しい制約がないため、これを補うだけなのです。なぜなら、これらはあまりにも異なる深刻な課題であり、それぞれの解決策はIT業界の全く異なる領域にあるからです。

 

誘い込まれたけど。寄生虫:))

しかし、ほぼ全員の参加者がMQに対して前向きな姿勢であることを見て、「MQはいいものだ。しかし、彼らの取引システムのコンセプトが理解できない、つまり、こうしなければならない、ああしなければならないという理由が理解できないことと相まって、私は二言三言言いたいのである。:)

1) MQはシステムを低レベルの言語とし、サードパーティの開発者がユーザーの様々なニーズに合わせてシステムを修正( カスタマイズ )する機会を与えた。

2) MQはシステムをより安全にすることで、ユーザーと「ブローカー」がより安心し、サードパーティの開発をより活用できるようにした。


そこで、私たちは、トレーダー向けに製品を作るためのベースとシステムを作りました。サードパーティの開発者が変えてはいけない(できない)部分を分離し、我々のシステムという形で実装したのです。このように、サードパーティがシステムを実装する方法を簡素化することで、当社のシステムの可能性を他社よりも大幅に広げることができました。私たちの課題は、環境を確保することであり、それを実現することでした。


:)上記の言葉はすべて、MQのために語っただけの私の言葉です。もし私が間違っていたら、彼らは訂正してくれるでしょう。しかし、彼らがIMHOを言わないのは、すでに繰り返すのに飽きているからにほかなりません。そして、この議論からわかるように、誰もがそれを理解しているわけではありません。


******************

一つのシンボルで複数のExpert Advisorや一部のEAを取引する「問題」については、当然ながら改善されません。実際問題、そうなのです。注文をグループ分けして、例えばグループ識別子のようなものを使って、セクションやフィルターを決定できるようにしなければなりません。

つまり、この部分もシステム部分に属するので、カスタム設定ではなく、システムの一部として実装する必要があります。

つまり、ユーザー側で何らかのクリアをすることです。

******************

ネットポジションや先入先出については、その本質や仕組みを理解していない人が多いのは自明の理である。この部分を明確にした方がいいように思います。

*********************

そしてもうひとつ、MQはユーザー(「ブローカー」ではない)を一部の金髪として扱うのをやめるべきだと思います。金髪は常にエッグヘッドにしか従わないからです。

***

久しぶりにMT5を見ましたが、取引システムが不便です。いろいろ入力しすぎて、ファイルで埋まってしまう。チャート上に注文を出す、マウスで注文を作成する、マウスで注文をコピーする、チャート上の注文を削除する、注文のグループ操作を行う場合。これは、私たちが持っているものではありません。

プロフェッショナルに見せるために、インターフェイスを修正しなければならないのです。現在のインターフェースは90年代のものです。

**

私個人としては(個人的に(!)もう一度)......紙の上で計算する別のシステムで取引しなければならないとしても、MTを使うことはないと思いますし、10%の指標はMTに存在しないものです。また、MTにあるインジケータの10%もないMTシステムを使うことになっても、他のシステムは使いたくありません。なぜ?おそらく、このようなことはトレードのメインではないのでしょう。これらはすべて、ここで言うところの「ボール」は、本当に必要ないものなのです。必要なのは、シンプル、クリア、人間工学的、迅速、直感的、そして目に見えることです。要するに、MQの皆さん、プログラムで一番大事なのは「インターフェイス」であることを理解してください、それはケースであり、キャッピングであり、スタイルである、eqlを見てください。

 
Mathemat:
今までのワラントの会計を台無しにしたネッティングというのが主な不満点でしたね。

これか?他に不満は?


以前、どこかのスレッドで、同じアカウントとインストルメントで2つのEAの例を書くと開発者が約束したことがありました。これができなかったんでしょうね。