誰が、どのようにか知らないが、私は独自の列挙を作成する際にID番号を明示的に指定することを好む(必要ではないが)。
例えばこのように:
enum Emagic { ENUM_DIGITAL_NAME = 0, // アドバイザーの名前(数字 ENUM_CODE_INTERACTION = 1, // インタラクションコード ENUM_EXPERT_SYMBOL = 2 // EAが起動されるシンボル };
これはMQL4から移行する際にも役立ちます。例えば、これは私が注文を扱う際に使用している列挙です。
//enum_mt4_order_type enum ENUM_MT4_ORDER_TYPE //トレーディング業務の種類 { OP_BUY = 0, //購入 OP_SELL = 1, //販売 OP_BUYLIMIT = 2, // 買い指値注文の保留 OP_SELLLIMIT = 3, //売り指値 OP_BUYSTOP = 4, //買い注文保留 OP_SELLSTOP = 5 //売り注文保留 };
この方法は便利です。なぜなら、列挙における識別子の位置に関係なく、そのコード(数値)は変わらないからです。
また、列挙に負の値を持つ識別子が含まれる場合にも、この方法は便利です。
追記
とても興味深い記事でした。
誰が、どのようにか知らないが、私は独自の列挙を作成する際にID番号を明示的に指定することを好む(必要ではないが)。
例えばこのように:
これはMQL4から移行する際にも役立ちます。例えば、これは私が注文を扱う際に使用している列挙です。
この方法は便利です。なぜなら、列挙における識別子の位置に関係なく、そのコード(数値)は変わらないからです。
また、この方法は、列挙に負の値を持つ識別子が含まれる場合に便利です。
追記
とても興味深い記事でした。
列挙を宣言するとき、値は自動的に順番に割り当てられるので、私にとっては重要ではありません、
とはいえ、あなたの方法の方がより明確であることには同意します(特に列挙が長い場合、たとえば3~4個以上になる場合)。
このようなマジシャンへのアプローチでは、ユーザーにも同じ指示を書く必要がある。そうすることで、ユーザーは、どのマジシャンが占有され、どのマジシャンが自由であるかを明確に知ることができる。Expert Advisorのユーザーは、1つの開発者のExpert Advisorだけを使用しているわけではなく、その方法がすべてのExpert Advisorの作成者によって使用される標準に含まれる可能性は低い。もし端末の開発者がこのulongをいくつかの変数に分割し、たとえば2バイトのものを4つ、といったように複数のmagesが存在するようにしていたら。
request.magic request.id1 request.id2 request.id3
あるいは、せめてターミナルをライブラリで完成させ、どうにかして標準規格に含めることができたかもしれない。
SetMagic(Magic,Id1,Id2,Id3)
このようなマジシャンへのアプローチでは、ユーザーにも同じ指示を書く必要がある。そうすることで、ユーザーはどのマジシャンが占有され、どのマジシャンが自由であるかを明確に知ることができる。Expert Advisorのユーザーは、1つの開発者のExpert Advisorだけを使用しているわけではなく、その方法がすべてのExpert Advisorの作成者によって使用される標準に含まれる可能性は低い。もし端末の開発者がこのulongをいくつかの変数に分割し、たとえば2バイトのものを4つ、といったように複数のmagesが存在するようにしていたら。
あるいは、せめてターミナルをライブラリで完成させ、どうにかして標準規格に含めることができたかもしれない。
ユーザーにとって、MAGIKでの作業に関するインストラクションを書くことが必要だという事実はまったくありません。たとえそうであっても、MAGIKがどのように形成されているかの説明を超えることはないでしょう......。
私自身は、777777や55555よりも深刻なレベルでMAGICをコーディングする支持者です。
ただ、構造体を使うことは(MQL4からコーディングの考え方はあったので)気がつきませんでした。
また、取引操作が 行われたシンボルに関する情報をMAGICに「書き込む」必要はないと思います(これは、この情報がすでに別の場所に保存されており、注文の瞬間からポジションの完全決済の瞬間まで変化しないためです)。また、マジック(セキュリティコードを使用しない場合)の下3桁をEXPERTのMARKER(またはMARKER、遺伝子工学でどのようになっているか正確には言いません)に割り当てるだけで十分だと思います。
というのも、これらの数字のうち最初の数字にはエキスパートの9~10の基本クラスをエンコードすることができ、残りの2つにはユーザーや開発者の視点から見た固有の番号をエンコードすることができるからである。その結果、通常900から1000の組み合わせが得られる。
また、エキスパート・アドバイザーが少なくともトレーダーが設定した注文を認識し、それに応じて注文をエンコードするアルゴリズムが望ましい。
追記
私は、複数のEAがコード化されたMAGICを混乱させることを恐れる必要はないと思います。少なくとも、あるアプローチをとれば、一見したところ、それほど危険ではない(おそらく可能性が高い)と思います。特に、これらすべての専門家が(たとえ異なる著者であっても)MAGICを暗号化するこの方法を支持し、互いの行動を考慮するならば、それは無関係になります。理想的には、一人の専門家だけが、このペアやあのペアで取引するのがよいのだが......。
この記事では、符号を使用する例を示しているが、すべての桁が使用されているわけではなく、符号化は明らかに過剰である、
必要であれば、これらの9ビットを圧縮することもできる。
マジシャン(それらの残りの9ビット)への識別に加えて、注文時の残高の状態を転送することができます。
残高が6ビット以上を取る可能性は低いので、任意のコーディングのための余地はまだあります。
この記事では、符号を使用する例を示しているが、すべての桁が使用されているわけではなく、符号化は明らかに過剰である、
必要であれば、これらの9ビットを圧縮することもできる。
マジシャン(それらの残りの9ビット)への識別に加えて、注文時の残高の状態を転送することができます。
残高は6ビット以上を取ることはほとんどありませんので、任意のコーディングのための余地が残っています。
この全てに1000か10000を加え、デコードの前に引くことで、あなたの方法によって占有されていないマジックの保証された範囲が存在するようにする必要があります。
このすべてに1000または10000を追加する必要があり、減算するデコードする前に、マジックのあなたの方法によって占有されていないの保証範囲があるように。
さて、どのように記事(ちょうど暗号化の範囲を拡大するために少し作業が必要)に記載されて痛みを伴わずにこれを行う、
私は何の問題も表示されません。
PS唯一の薄い場所は、残高を整数に変換することを忘れてはならないそうでなければ、コンマがグリッチを与えるだろう、それを行うには、バインディングで見る必要がありますアカウントセントは、そのような精度が必要でない場合は、トリミングとintに変換した後、100を掛けます。
まあ、手間をかけずにやる方法は記事に書いてある(ただ、暗号化の範囲を広げるために少し手を加える必要がある)、
特に問題はないと思う。
PS.唯一の薄いところは、残高を整数に変換することを忘れてはならない。そうしないと、コンマが不具合を与えるだろう。その方法は、口座がセントであれば100倍し、そのような精度が必要ない場合は、クリッピングでintに変換し、バインディングを見る必要があります。
問題がなければ、あなたのシステムでエンコードされたマジックとエンコードされていないマジックの非交差を保証する方法を、簡潔かつ明確に指示してください。
もし問題ないのであれば、あなたのシステムでエンコードされたマジックとエンコードされていないマジックの非交差を保証する方法を簡潔かつ明確に教えてください。
私の答えが言い訳に見えないように、この質問は考慮されていないが、許可されていることをすぐに言おう。
ここにulong 18 446 744 073 709 551 615それらの17 * 10^18の最大値は、すべての自由フィールドを持っています。Стоит добавить при кодировании 17 000 000 000 000 000 и поставить при декодировании проверку содержит ли 20 и 19 разряд числа 1 и 7 и вы гарантированно определите кодированный ли магик или нет.
//+------------------------------------------------------------------+ //| この関数は、入力データから組み立てられたプレハブのマジックを返す。 //+------------------------------------------------------------------+ ulong Cmagic::SetMagic_request(int digital_name=0,int code_interaction=0) { if(digital_name>=1000)Print("アドバイザーの数字名が正しく設定されていない(1000より大きい)"); if(code_interaction>=1000)Print("エイリアン・エイリアン識別コードが正しくない(1000より大きい)"); mag.digital_name =digital_name; mag.code_interaction =code_interaction; mag.expert_symbol =symbolexpert(); mag.magicnumber =17000000000000000000+// вот эта вставка даст 20 разрядов магику mag.digital_name*(int)pow(1000,2)+ mag.code_interaction*(int)pow(1000,1)+ mag.expert_symbol; return(mag.magicnumber); }
とデコーダーの中にある。
//+------------------------------------------------------------------+ //| この関数は、マジックを3桁の3つの部分に分割する。 //|| そして、カテゴリーが指す部分を返す。 //+------------------------------------------------------------------+ int Cmagic::decodeMagic_result(int category) { string string_value=(string)mag.magicnumber; int rem=(int)MathMod(StringLen(string_value),3); if(rem!=0) { rem=3-rem; string srem="0"; if(rem==2)srem="00"; string_value=srem+string_value; } int start_pos=StringLen(string_value)-3*category; string value=StringSubstr(string_value,start_pos,3); if(StringLen(string_value)!=20)return((int)StringToInteger("0"));//если магика не 20 разрядов значит не кодированный return((int)StringToInteger(value)); }
ディミトリは、やりたい人はチャンスを探し、やりたくない人は理由を探していることを忘れてはいけない、私はあなたの力で窓を開け、そこからドアを開けることもできるのだ。
ところで、私はこの
(int)pow(1000,2)
ただ、この記事では両方の方法を示したかったし、可能であれば有機的に適合させたかった(エンコードはint型、デコードは文字列型)。
そして一般的に、私は可能性を示したかったのであって、ブラックボックス化されたコンバーターを与えたかったわけではない(バケツ一杯のおかゆを与えるより、シャベルを与えた方がいい)。
PSはここで一つのことは、別のエンコードを言った(私はネットワークが定期的にノックアウトされるように雷雨を持っている)エンコードされたチェックは20と19桁で1と7ではなく、これらの非常に数字の存在は、マジックの20桁は、エンコードを使用することを意味しますが、あなたはチェックを再生することができます理解している場合、それらの。

- 無料取引アプリ
- 8千を超えるシグナルをコピー
- 金融ニュースで金融マーケットを探索
新しい記事 単一インスツルメント上で異なるExpert Advisorsを使ったトレーディングのためのORDER_MAGICの使用 はパブリッシュされました:
本稿は、異なるExpert Advisorsの自動トレーディングの分割、組立て、同期同様magic-identificationを使用したインフォメーションコーディングの疑問について考察します。本稿は、より経験を積んだトレーダー同様初心者にも興味深い内容となっています。その理由は、Expert Advisorsおよび様々な戦略の複雑なシステムの同期を実装するのに有用な垂直ポジションの疑問に取り組んでいるからです。
作者: Nikolay Demko