[ARCHIVE]フォーラムを乱立させないために、どんなルーキーの質問でも。プロフェッショナルの皆さん、通り過ぎないでください。あなたなしではどこにも行けない - 5. - ページ 352 1...345346347348349350351352353354355356357358359...432 新しいコメント Рустам 2013.05.21 16:07 #3511 括弧の間違いを指摘したのは私です。 削除済み 2013.05.21 16:11 #3512 hoz: そのため、有効な注文の終値は論理的にゼロになりますが(決済されていないため)、すでに決済された注文の終値はゼロではありません(終値は削除された時点のものとなります)。論理的に考えて、これが閉店時間?注文がクローズされるのではなく、削除されるのは理解できるのですが、他にどのように実装すればよいのでしょうか。MODE_TRADES (デフォルト) - 注文は未決済注文と保留注文の 中から選択されます。 MODE_HISTORY - 注文は決済済み注文と削除済み注文の中から選択されます。 Рустам 2013.05.21 16:13 #3513 彼は正しく理解したが、括弧がすべて間違っている。2hoz- 私からのアドバイスですが、このアルゴリズムは捨ててください。なぜ、保留中の注文の束をチャートの周りにドラッグする必要があるのでしょうか? ペンダントの数だけなら、グリッドダーでも大丈夫です。1) 最初に一組の逆指値注文を出します。2)1枚がトリガーしたら、その直後に(必要な距離で)もう1枚を露光する。反対側のものは、必要な距離で価格に引き寄せられる。以上です。このため、常に2つの注文を保留しておくことができ、再計算の手間も省けます。 Сергей 2013.05.21 17:17 #3514 みんな、何かアドバイスがあったら助けてくれ! https://www.mql5.com/ru/forum/142582/page351 Viktar Dzemikhau 2013.05.21 19:29 #3515 FAQ: 括弧の間違いを指摘したのは私です。 はい、すでに全体を作り直しました。また、関数の最初にある極端な価格の変数がヌルになるバグがありました(つまり、以前は2でしたが、今は4になっています)。すべての作品、ありがとうございました。よくある質問彼はすべてを正しく行っているが、ブラケットをすべて間違えている。2hoz- 私からのアドバイスですが、このアルゴリズムは捨ててください。なぜ、保留中の注文の束をチャートの周りにドラッグする必要があるのでしょうか? ペンダントの数だけなら、グリッドダーでも大丈夫です。1) 最初に一組の逆指値注文を出します。2)1枚がトリガーしたら、その直後に(必要な距離で)もう1枚を露光する。反対側のものは、必要な距離で価格に引き寄せられる。以上です。このため、常に2つの注文を保留しておくことができ、再計算の手間もかかりません。 そのようにすることも可能ですが、私の考えでは、保留中の注文のステップが小さいと、保留中の注文の時間が足りなくなる可能性があります。私の意見に反対ですか?結局のところ、保留中の注文が設定されれば、それがトリガーされることになる。また、ステップが小さいと設定しなければならないので、やはり、必要な場所にオーダーが近いとは限らないので、スリッページの可能性が出てきます。それに、私は常に全部のグリッドを配置するわけではありません。実際には、極端な注文は1つだけ削除され、2つの注文が設定されます(1つはショート、もう1つはロング)。このように、同じイコールコンディションであれば、強い手でも全部の手をつかむことができるので、良い結果になることがわかります。 Serg16 2013.05.21 21:06 #3516 iHigh(Symbol(),timeframe,shift)のシフト値の上限が 1000に 制限されている問題を解決 する方法を教えてください。iTime(Symbol(),timeframe,1001)は1970.01.01 00:00を与える。 Рустам 2013.05.21 21:22 #3517 hoz: すでにすべてを変更しましたが、関数の最初の方で価格変数のヌル化に問題がありました(つまり、以前は2でしたが、今は4になっています)。すべてうまくいきました、ありがとうございます。この方法でもいいのですが、私の理解では、ポーズ間のステップが小さいと、ポーズが設定される時間が足りなくなる可能性があります。賛同していただけないのですか?結局のところ、保留中の注文が設定されれば、それがトリガーされることになる。また、ステップが小さいと設定しなければならないので、やはり、必要な場所にオーダーが近いとは限らないので、スリッページの可能性が出てきます。それに、私は常に全部のグリッドを配置するわけではありません。実際には、極端な注文は1つだけ削除され、2つの注文が設定されます(1つはショート、もう1つはロング)。したがって、同じイコールコンディションであれば、強い手でも全部の手をつかむことができるので、良いということになるのです。 1) あなたはそれを信じますか?信じられるか? そう、リアルでいい動きをすると、ブローカーは注文の半分を値段でずらし、一斉に、しかもテイクプロフィットを超えてオープンし、すぐにストップで決済し、残りは全くオープンしないこともあります。そして、彼は正しいでしょう。2) まだ、EAが注文を保留していないような良い動きを見たことがない。でも、この状況でブローカーに対するクレームがワンサカと出てくるんですよね。懸案事項のない、これほど良い動きは見たことがない。 Alexander 2013.05.21 22:44 #3518 Fox_RM: みんな、何かアドバイスがあったら助けてくれ! https://www.mql5.com/ru/forum/142582/page351 ここに問題があると思います。 for (i=0; i<=colbr; i++) {VLUP += MathAbs(iVolume(NULL,0, shift+i));} } Comment("Vol_",VLUP,prlw_e,prhgh_e); for(i=0; i<limit; i++) { SetText("Awesome_super_volumes"+Close[i], DoubleToStr(VLUP,0), tmlw, AO_dn, Black); } リミットチャートを開くとバーの本数と同じになるので、まずVLUPの金額を数えて、それをシャンブルですべてのポイントに入れるだけです。きっとその後、正しくカウントされることでしょう。 Alexander 2013.05.21 22:52 #3519 Serg16:iHigh(Symbol(),timeframe,shift)のシフト制限で 1000という数字に 制限されている問題を解決して ください。 iTime(Symbol(),timeframe,1001)は1970.01.01 00:00を与える。 サービス」→「設定」→「グラフ」を開きます。チャートに許容されるバーの本数を確認します。2000と3000で動作させています。 mikhail12 2013.05.21 23:21 #3520 1ヶ月で2回目、ナビからの請求書が全て端末で消えてしまい、端末のマイレボから復元しなければならない、前回はマイレボが空だった・・・、こんなバカなことがあるのか、誰か経験したことある人いる? 1...345346347348349350351352353354355356357358359...432 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
そのため、有効な注文の終値は論理的にゼロになりますが(決済されていないため)、すでに決済された注文の終値はゼロではありません(終値は削除された時点のものとなります)。論理的に考えて、これが閉店時間?
注文がクローズされるのではなく、削除されるのは理解できるのですが、他にどのように実装すればよいのでしょうか。
MODE_TRADES (デフォルト) - 注文は未決済注文と保留注文の 中から選択されます。
MODE_HISTORY - 注文は決済済み注文と削除済み注文の中から選択されます。
彼は正しく理解したが、括弧がすべて間違っている。
2hoz- 私からのアドバイスですが、このアルゴリズムは捨ててください。なぜ、保留中の注文の束をチャートの周りにドラッグする必要があるのでしょうか?
ペンダントの数だけなら、グリッドダーでも大丈夫です。
1) 最初に一組の逆指値注文を出します。
2)1枚がトリガーしたら、その直後に(必要な距離で)もう1枚を露光する。反対側のものは、必要な距離で価格に引き寄せられる。
以上です。このため、常に2つの注文を保留しておくことができ、再計算の手間も省けます。
括弧の間違いを指摘したのは私です。
はい、すでに全体を作り直しました。また、関数の最初にある極端な価格の変数がヌルになるバグがありました(つまり、以前は2でしたが、今は4になっています)。すべての作品、ありがとうございました。
彼はすべてを正しく行っているが、ブラケットをすべて間違えている。
2hoz- 私からのアドバイスですが、このアルゴリズムは捨ててください。なぜ、保留中の注文の束をチャートの周りにドラッグする必要があるのでしょうか?
ペンダントの数だけなら、グリッドダーでも大丈夫です。
1) 最初に一組の逆指値注文を出します。
2)1枚がトリガーしたら、その直後に(必要な距離で)もう1枚を露光する。反対側のものは、必要な距離で価格に引き寄せられる。
以上です。このため、常に2つの注文を保留しておくことができ、再計算の手間もかかりません。
そのようにすることも可能ですが、私の考えでは、保留中の注文のステップが小さいと、保留中の注文の時間が足りなくなる可能性があります。私の意見に反対ですか?結局のところ、保留中の注文が設定されれば、それがトリガーされることになる。また、ステップが小さいと設定しなければならないので、やはり、必要な場所にオーダーが近いとは限らないので、スリッページの可能性が出てきます。
それに、私は常に全部のグリッドを配置するわけではありません。実際には、極端な注文は1つだけ削除され、2つの注文が設定されます(1つはショート、もう1つはロング)。このように、同じイコールコンディションであれば、強い手でも全部の手をつかむことができるので、良い結果になることがわかります。
iHigh(Symbol(),timeframe,shift)のシフト値の上限が 1000に 制限されている問題を解決 する方法を教えてください。
iTime(Symbol(),timeframe,1001)は1970.01.01 00:00を与える。すでにすべてを変更しましたが、関数の最初の方で価格変数のヌル化に問題がありました(つまり、以前は2でしたが、今は4になっています)。すべてうまくいきました、ありがとうございます。
この方法でもいいのですが、私の理解では、ポーズ間のステップが小さいと、ポーズが設定される時間が足りなくなる可能性があります。賛同していただけないのですか?結局のところ、保留中の注文が設定されれば、それがトリガーされることになる。また、ステップが小さいと設定しなければならないので、やはり、必要な場所にオーダーが近いとは限らないので、スリッページの可能性が出てきます。
それに、私は常に全部のグリッドを配置するわけではありません。実際には、極端な注文は1つだけ削除され、2つの注文が設定されます(1つはショート、もう1つはロング)。したがって、同じイコールコンディションであれば、強い手でも全部の手をつかむことができるので、良いということになるのです。
1) あなたはそれを信じますか?信じられるか? そう、リアルでいい動きをすると、ブローカーは注文の半分を値段でずらし、一斉に、しかもテイクプロフィットを超えてオープンし、すぐにストップで決済し、残りは全くオープンしないこともあります。そして、彼は正しいでしょう。
2) まだ、EAが注文を保留していないような良い動きを見たことがない。
でも、この状況でブローカーに対するクレームがワンサカと出てくるんですよね。懸案事項のない、これほど良い動きは見たことがない。
みんな、何かアドバイスがあったら助けてくれ! https://www.mql5.com/ru/forum/142582/page351
リミットチャートを開くとバーの本数と同じになるので、まずVLUPの金額を数えて、それをシャンブルですべてのポイントに入れるだけです。きっとその後、正しくカウントされることでしょう。ここに問題があると思います。
iHigh(Symbol(),timeframe,shift)のシフト制限で 1000という数字に 制限されている問題を解決して ください。
iTime(Symbol(),timeframe,1001)は1970.01.01 00:00を与える。サービス」→「設定」→「グラフ」を開きます。チャートに許容されるバーの本数を確認します。2000と3000で動作させています。