MQL5への願い - ページ 28

新しいコメント
 

すでに言われていることかもしれませんが...。

1）暗号化した状態でコンパイルする機能を追加し、コンピュータIDとリンクしたシリアルナンバーを生成する機能を追加する（armandillo packerに類似）。

これらはすべて、ソースからではなく、トランスレータの内部で実行されるべきです。

2) 他のプログラムから端末を管理し、サーバーへの接続/切断、サーバーへの接続確認、見積もりアーカイブの要求、注文などを可能にする、外部プログラムとのインタラクティブな作業の可能性を追加する。など

3）ティックに関係なく注文を出すことができる。

4) 複数のDT/アカウントでの同時作業への対応

5) DLLデバッグの復活

6) 少なくとも構造体のサポートを追加する。一般的には、可能性を広げ、c++ に近いものにすることが望ましい。

 

プログラムが提供するヘルプ（例えば、目的のテキストを表示するウィンドウを開くなど）とWebページへの実行可能なリンクを追加する必要があります。

もし、ユーザーが理解できないことをしたら、プログラムが「ここに状況についての相談があるから、ちゃんと読んで、もうバカなことはしないでね」と教えてくれるのです。

 

SK,

例えば、TP=2、SL=10を一度設定しておけば、あとは売買だけ、つまりピプシングが非常に便利になる。 この不便さから、最近は特にExpert Advisorを作り、売買をクリックしたら指定した値でTPとSLを設定するようにしている。

 

すべてのことに、たくさんの願いが込められています もう28ページ！？

どのような希望がすでに開発されているのか、実現しないのか、実現する可能性があるのか、開発者に聞いてみたいです。

そうでなければ、他のものを望むべきかどうか、私たちはフィードバックを見ることができないのです。

もちろん、タイミングも知りたい。ソフトウェアの発売時期を予測するのは、為替レートの 動きを予測するのと同じくらい簡単ではないこともあると理解しています。

少なくとも、この形では。「MT5のベータ版は、.........................よりも早くリリースされる予定です。 こんな句が書けるのだろうか。

 
Better:

それ以外は、何か希望があるのか不明で、フィードバックは見えません。


まあ、このトピックが修正されたということは、開発者がこのトピックを有用だと考えているということなのですが......。）
 
マジックを現役で再登板させるという話は出ていないのでしょうか？考え方は簡単で、複数期間の取引では、長いトレンドが あるときに、より高い時間枠に注文を渡すことが可能になります。
 
Cronex:
マジックを現役で再登板させるという話は出ていないのでしょうか？考え方は簡単で、多期間取引において、トレンドがロングである場合に、より高い時間枠に注文を 渡すことが可能になるのです。
もう少し具体的に教えてください。どういうことですか？
 
SK. писал (а):
Cronex：
マジックは現役で再赴任させるという話はないのでしょうか？考え方は簡単で、複数期間の取引では、長いトレンドがあるときに、より高い時間枠に注文を 渡すことが可能になります。
もう少し具体的に教えてください。どういうことですか？

簡単に言うと、私は4つの期間で同じ取引戦略を使用しています。つまり、1つのアルゴリズム（指標のセットとシグナルの種類）を使用して、エントリー/イグジット/トレーリングの原則ですが、指標のパラメータは各期間で異なっています（実際には1つのチャートに4つのEAです）、マジックで分割しています。その結果、低い時間枠では、市場の状況よりもずっと早くポジションを閉じるよう な兆候が見られますが（つまり、反対側に振れると利益を得ることになります）、高い時間枠では状況は非常に安定しています。指標上の相対的な変動率に影響を与える。上級の時間軸で安定した状況が発生した場合、下級の時間軸のオープンポジションはクローズせず、マジックを変更することで上級の時間軸のロジックに引き継ぐという考え方は明快だと思います。このアプリケーションは、実はタイムフレームだけでなく、他の処理ロジックへの転送にも使われているのです。証券会社にとっては、チケットは残っているし、利益も出るから問題はなさそうだ。
 
Cronex:
簡単に言うと、私は4つの期間について1つの取引戦略を使用しています。つまり、同じアルゴリズム（指標のセットとシグナルの種類）を使用して、エントリー/イグジット/トレーリング原則ですが、指標のパラメータは各期間で異なっています（実際には1つのチャートに4つのExpert Advisorです）、マジックで分割してください。その結果、低い時間枠では、市場の状況よりもずっと早くポジションを閉じるような兆候が見られますが（つまり、反対側に振れると利益を得ることになります）、高い時間枠では状況は非常に安定しています。指標上の相対的な変動率に影響を与える。上級の時間軸で安定した状況が発生した場合、下級の時間軸のオープンポジションはクローズせず、マジックを変更することで上級の時間軸のロジックに引き継ぐという考え方は明快だと思います。このアプリケーションは、実はタイムフレームだけでなく、他の処理ロジックへの転送にも使われているのです。DCにとっては、チケットは残るし、利益も出るかもしれないので、問題はなさそうです。


意味は明確です。

しかし、この考え方のために、端末とサーバー間の通信の言語や技術を変える必要はないと思います。結局のところ、必要なものはすべて端末側のプログラムに計上できるのです。しかも、マジックを変えるという発想そのものが、戦略、その基準が未整備であることの雄弁な証拠である。マジックは（あなたの例が明らかに示すように）注文を閉じたり開いたりするための一定の基準を負担しないし、できない。単純に、マジクは市場とは一切関係ないからです。

これがトレードにおける重要なポイントのひとつだと私は考えています。たまたま手にしたマジックを、それに結びつけました。実際には、新しいティックごとの状況は、前史（マーケットオーダーを開いた 時間や価格など、ゲームアカウント上のイベントの履歴）がない新しいものと考えるべきでしょう。

そして、マジックは、部分的には便利ですが、私の意見では、誰が何を知っているのか...を把握するためには、あまり便利なメカニズムではありません。注文を一意に特定できるようになれば（再開時、一部終了時）、マジックの意味が全くなくなると思います。

 
SK. писал (а):


ポイントははっきりしている......。

論破してみようと思って、端から見ていくと......。

私の考えでは、注文をオブジェクトとして受け入れるならば、現時点でのマジックは、SLやTPレベルと同様に、プログラミングの観点からこのオブジェクトの完全な可変プロパティである。間違っているかもしれませんが、現在のところ、ターミナルで実行されたコードに関連するMQLの注文を、その生活のすべての可能な段階（再開と部分閉鎖の間）で明確に識別することは不可能で、マジックはこの状況をかなり補うものです。マジックはマーケットに付けてはいけない。単に別の用途があり、その意味以外には意味がないのだ。

市場の状況を歴史のないものとして見るという立場には賛同しかねますが...。でも、これは私個人の意見です。もしこの注文が利益を生むものであれば、より高い時間枠を見て判断し、小さなプルバックを待ってより高い時間枠でこの注文を継続するか、あるいは利益を生まないためそのまま決済するか、どちらかを選択すべきです。

戦略の健全さ、貧弱さについて議論するつもりはありません。全く同感です...。しかし、私はそれに取り組んでいるのです :-)

サーバーと端末の間でやり取りする言語やプロトコルを変更するのは、まあ、どうでしょう・・・。現時点では、majic値はすでに存在し、注文時にサーバーが受け付けます。交換プロトコルの形式については知りませんが、何らかのデータ構造をトランスポートで一括送信し、その後の整合性検証を行っているのではないでしょうか。OrderModifyが 送信するデータ構造に、もう一つオプションのパラメータを追加するのは、それほど難しいことではないと思います。私は、開発者がアトミック交換プロトコルの道を歩み、その結果、バージョンアップのサポートという重いプロセスに自ら足を踏み入れたことを深く疑っています。

でも、一般的にはプランについて聞いただけなんですけどね :-)いいえ、そうではありません。

1...212223242526272829303132333435...131
新しいコメント