[ARCHIVE]フォーラムを乱立させないために、どんなルーキーの質問でも。プロフェッショナルの皆さん、通り過ぎないでください。あなたなしではどこにも行けない - 5. - ページ 94

新しいコメント
 

アリス
アリス


やり方さえ分かれば...。から削除されました。

//if (OrderModify(OrderTicket(), OrderOpenPrice(),OrderStopLoss(), price + koef*325*Point, 0))

if (OrderModify(OrderTicket(), OrderOpenPrice(), price + koef*325*Point, 0))

間違いがたくさん散りばめられていますね...。


チェックとはどういう意味ですか？そして、OrderStopLoss()を投げるべきではありませんでした。関数OrderModify()のパラメータの量と順序に違反した。それゆえ、エラーが発生するのです。

 
PapaYozh:
隙間に大きなスリップが発生する可能性があります。
このような場合、TSのロジックを知らなければ、正しい答えを出すことは難しい。このような状況に対して追加のアラートを導入することができます。ポジションがストップ（買い）の値より下に、またはストップ（売り）の値より上に閉じられた場合、履歴から最も近い価格変化を探し、ギャップがあったかどうかを判断し、あった場合はポジションがギャップで閉じられたことをメッセージで表示するのです。そうでない場合 - 別の方法で対処する...繰り返しになりますが、TSの知識がないと、何かをアドバイスするのは難しいのです。しかし、そのような事態に対処することは必要です。
 

こんにちは、ある配列があったとして、その中から最も近い数字を引き出す方法を教えていただけないでしょうか。

double Mass_data1[] = { 0.5,1.5,3.0,5.3,7.5,7.0};

とある数字。

double CurrValue = 5.5;

5.5から最も近い小さい数字、つまり5.3を取り出す必要があるのです。どうすればいいか教えてください。

 
配列の要素を ループして、目的の数より大きくなければ、それを検索結果の候補として保存するのです。次の数字が目的の数字より大きければ、ループを中断する。
 
Sepulca: チェックに限定とはどういう意味ですか？そして、OrderStopLoss()を投げ出してはいけないのです。関数OrderModify()のパラメータの量と順序に違反した。それゆえ、エラーが発生するのです。


私の要望を放置せずに聞いていただき、ありがとうございました誰もが女の子に忍耐力があるわけではありません。

私が本当に必要としているのは、Sova が既に開いている注文の SL を変更しないことなのです。

なぜなら、このような仕組みになっているからです。

1.アルゴリズムに従って、通常のSLとTPで注文を出します。

2.SLレベルで指値または逆指値の返信注文が発注されます。

3.その後、不可抗力による計画的な処理(通信障害により計画されていない場合もあります)が発生すると、Sova は保留中の注文を全て削除し、正しい TP と SL で再び注文を出します。

4 そして、ソバは、なぜかオープンオーダーのSLを、正しくないと判断して変更するらしい・・・。

5.それに伴い、オープンオーダーのSLがリターンオーダーと一致しなくなり、混乱が始まった......。

目標は、Owlから未決済注文を修正する能力を奪うか、少なくとも不可抗力の予定処理を禁止することです。

 
MikeM:
配列の要素をループして、探している数値より大きくなければ、それを検索結果の候補として保存するのです。次の数字が目的の数字より大きければ、ループを解除する。

ありがとうございます、わかりやすいようです、これからやってみます))
 
Allis:


私の要望を無視しないでいただき、ありがとうございましたみんながみんな、女の子に我慢しているわけではありません。

私は、Sova が既に開いている注文の SL を変更しないようにすることが絶対に必要です。

以下のような状況なので、オープンした注文のSLを変更してはいけませんでした。

1.アルゴリズムに従って、通常のSLとTPで注文を出します。

2.SLレベルで指値または逆指値の返信注文が発注されます。

3.その後、不可抗力による計画的な処理(通信障害により計画されていない場合もあります)が発生すると、Sova は保留中の注文を全て削除し、正しい TP と SL で再び注文を出します。

4 そして、ソバは、なぜかオープンオーダーのSLを、正しくないと判断して変更するらしい・・・。

5.それに伴い、オープンオーダーのSLがリターンオーダーと一致しなくなり、混乱が始まった......。

目標は、Owlから未決済注文を修正する可能性を奪うか、少なくとも不可抗力の予定された処理を禁止することです。


EAのロジックはわかりませんが、1つ注文があったとして、それがSLで決済されれば、すぐに次の注文が入るのではと予想しています。つまり、常に複数のオープンオーダーが存在するわけではないのでしょう？不可抗力の事態が発生し、保留中の注文を入れ直した場合、その場合はすべてが正しく、新しい保留中の注文を設定する際に、新しい保留中の注文の始値に合わせて、オープンSLを修正する必要があります。おそらく、オープンの修正に伴うSLの再計算は正しくないのでしょう。同様に、使用する場合は、TPで。
 
artmedia70:

ありがとうございます ...:)

たいていは、自分のコードから気晴らしが必要なときにやっています。思考の整理に役立つ。

喜びの声、応援します！チンザノを注いで...。あなたとあなたの幸せに乾杯!!!:)

はねるほど親切にお願いします!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

チンザノ！Une Momento !!!!!!!

;-)

 
Sepulca:

EAのロジックはわかりませんが、1つの注文があり、それがSLで決済された場合、別の注文が発注されたことを示唆したいのです。つまり、常に複数のオープンオーダーが存在するわけではないのでしょう？不可抗力の事態が発生し、保留中の注文を入れ直した場合、その場合はすべてが正しく、新しい保留中の注文を設定する際に、新しい保留中の注文の始値に合わせて、オープンSLを修正する必要があります。おそらく、オープンの修正に伴うSLの再計算は正しくないのでしょう。同様に、使用する場合は、TPで。


いいえ、オープンオーダーにはSLがあり、そのオーダーは単独ではありません。

そのSLのレベルでの各注文には、リミットまたはブレイクアウトのカウンターオーダーが付きます。SLでオープンオーダーが出るときにマーケットからオープンされるのではなく、すでにそこにある。

そして、上に書いたように...

EAの動作のロジックがわからない。

 
Roman.:
つまり、私の相棒なん です！（笑つまり、私たちは幸運で、すべてがうまくいっていて、取引所でお金を稼ぐ方法を知っているということなのです

デモはデタラメばかり...。1月2日のデモのスクリーンショットですhttp://clip2net.com/s/2Iziy
1...87888990919293949596979899100101...432
新しいコメント