チャンピオンシップに参加するためのヒント - ページ 11 1...45678910111213141516 新しいコメント Mikhail Skakov 2006.09.04 12:51 #101 VNIK писал (а): チャンピオンシップのオーガナイザーに軽率な質問をしてすみませんでした。 賞金の課税はどうなるのか(各賞の金額が非常に大きいので)。 受賞者は自分で税金を払う必要があるのでしょうか?(そしてその割合は?) それとも一元化されるのか?( つまり、税金はすでに考慮されている?)。 税金で賞金の半分をあきらめるのはもったいない! 私も同感で、あなたの賞品の半分を私の税金の支払いにあてるのは申し訳ないと思うのですが...。 本当は、まったく勝てないほうが悔いが残らないのですが......。 Renat Fatkhullin 2006.09.04 13:59 #102 VNIK: チャンピオンシップのオーガナイザーに軽率な質問をしてすみませんでした。 賞金の課税はどうなるのか(各賞の金額が非常に大きいので)。 受賞者は自分で税金を払う必要があるのでしょうか?(そしてその割合は?) それとも一元化されるのか?( つまり、税金はすでに考慮されている?)。 税金で賞金の半分をあきらめるのはもったいない! はい、受賞者は自分で税金を払います。これは、世界中の賞の標準的な慣習です。 Maestro 2006.09.04 14:53 #103 この注文の終了が 常に正しく機能するかどうかをテストする方法はありません。 while (OrdersTotal()>0) { OrderSelect(0,SELECT_BY_POS); if (OrderType()==OP_BUY) OrderClose(OrderTicket(),OrderLots(),Bid,3,Green); else if (OrderType()==OP_SELL) OrderClose(OrderTicket(),OrderLots(),Ask,3,Red); err=GetLastError(); if (err==135 || err==138) RefreshRates(); } 問題は、エラーコードが135や138でない場合、ループが発生するかということです。その場合、どのようにすれば注文が閉まることを保証した上で、これを回避することができるのでしょうか。 Renat Fatkhullin 2006.09.04 14:56 #104 MAEstro: この注文の終了が 常に正しく機能するかどうかをテストする方法はありません。 ここではエラーに次ぐエラーです。4つのエラーを数えましたが、いずれも致命的なものです。 アドバイスの記事をもう一度読んでみてください。 Maestro 2006.09.04 15:14 #105 このアドバイスは暗記しているのですが、ほとんど役に立っていないようです :( ループによるエラー制御を徹底的に無視 (エラー制御をしている、保留注文は使わない、ループの終了条件も作った方がいい?では、オーダークローズ保証はどうするのか?それとも、すべてのエラーコードを処理できていないのでしょうか? OrderSelectの制御不足 - 非同期処理の動作について (そう、Order_Selectが何を返すかはチェックしないのです!この場合、falseを返すとすると、ループの中で何が変わるのでしょうか、何が間違っているのでしょうか?注文を修正するのではなく、閉めるのです!) RefreshRates()によるマーケット環境更新機能のスキップ (私はそれをリフレッシュすると思います、すべてがここで大丈夫なはずです)。 もしかしたら、すべての注文をクローズするためのコードが用意されているかもしれません。 投稿していただけると幸いです。 P.S. Rosh が提案したhttp://www.alpari-idc.ru/ru/experts/articles/9.html は、注文を閉じることを保証するものではありません。 Renat Fatkhullin 2006.09.04 16:15 #106 5つのエラーまであります。 OrderSelectの 結果がチェックされない OrderClose()の結果が明示的にチェックされない。 GetLastError() は、取引操作がなくても呼び出すことができます (たとえば、保留中の注文に遭遇した場合など)。 RefreshRates()は常に呼び出されるわけではなく、障害が発生したときのみ呼び出される - これは重大なエラーである リストに未決済の注文がある場合、100%ループとなります。 結果:9行の中に5つのエラーがある - このコードは捨てられるしかない。 削除済み 2006.09.04 16:30 #107 Renat: 5エラーでも OrderSelectの 結果がチェックされない OrderClose()の結果が明示的にチェックされない。 GetLastError() は、取引操作がなくても呼び出すことができます (たとえば、保留中の注文に遭遇した場合など)。 ... 結果:9行の中に5つのエラーがある - このコードは捨てられるしかない。 しかも、それをなぜコンテストの専門家に詰め込むのか。ログを読むには? OrderSelect は必要な注文を選択し、OrderClose は必要な注文を決済する必要があります。 そして、エラーは発生しないはずです :-) あるいはクライアントの費用負担で :-) Maestro 2006.09.04 16:55 #108 Renat писал (а): 5つのエラーまであります。 OrderSelect は結果を明示的に チェックしないOrderClose()GetLastError() は取引操作なしで呼ばれることがある(例えば、保留中の注文に遭遇した場合)RefreshRates() は常に呼ばれるのではなく、失敗した場合のみ呼ばれる -リストに保留中の注文がある場合、100%ループする 重大なエラーとなる 結果:9行の中に5つのエラーがある - このコードは捨てられるしかない。 目的:すべての注文を100%保証して終了すること 制限事項:保留中の注文は使用しない 1.注文をクローズする必要があるのに、なぜ結果を確認する必要があるのですか?もしfalseを返したら、whileループが使われているので、次のパスでそれに戻る。 2.ポイント1参照。 3.そのためのエラーコードのチェックがあります。 4.常に更新されるのであれば、エラーチェックの意味がない :( 5.保留中の注文はない 私が検索したオーダークローズの例はすべてシングルパスで、サーバーに問題がなく、リクオートなどがない場合にのみ機能します。そして、それらはすべて、ある日突然、注文が成立しなくなり、良い利益が得られるということにつながるのです......。もし私が間違っていたら、訂正するか、私が間違っていると確信できるようなリンクを教えてください。 もちろん、私のコードがループを引き起こす可能性があることは十分承知していますが、私の意見では、注文が成立せず、深刻な経済的損失につながるリスクよりはましだと思います。 全ての注文が100%保証され、注文が滞留する可能性がないことが望ましいのですが、このようなコードを提供して欲しいです =)。 以下は、保留中の注文も考慮するように、少し修正したコードです。 while (OrdersTotal()>0) { OrderSelect(0,SELECT_BY_POS); if (OrderType()==OP_BUY) OrderClose(OrderTicket(),OrderLots(),Bid,3,Green); else if (OrderType()==OP_SELL) OrderClose(OrderTicket(),OrderLots(),Ask,3,Red); else OrderDelete(OrderTicket()); RefreshRates(); err=GetLastError(); if (err!=135 && err!=138 && err!=0) break; } 前作ほど「無謀」ではないのでは? この場合、なぜOrderSelectとOrderCloseをチェックするのか、まだ理解できていません。 Renat Fatkhullin 2006.09.04 18:04 #109 残念ながら、取引業務に関する保証は誰もしてくれません。上記のコードは、以前のものよりもはるかに優れています。 OrderSelectは必ずチェックすること、これはUseful Tipsに 明示されています。 OrderSelectの制御不足 - 非同期処理の動作について 通常、トレーダーは自分のプログラムをシングルタスクで唯一のものだと認識しています。しかし実際には、Expert Advisorの動作中に、取引口座で多くの非同期的な変更が行われます。 ポジションは変更、追加、削除されます。もし、各OrderSelect()呼び出しの結果が制御されていなければ、ある瞬間にエキスパートが間違った(ゼロ)データで動作し、間違った動きをすることが起こるかもしれないのです。 削除済み 2006.09.04 20:06 #110 Renat: 残念ながら、取引業務に関する保証はありません。上記のコードは、以前のものよりもはるかに優れています。 OrderSelectは必ずチェックすること、これはUseful Tipsに 明示されています。 OrderSelectの制御ができない - 非同期処理の動作中 ...ポジションの変更、追加、削除 ... あるポジションが修正されたとする。何らかの条件で注文を選びたいという要望がある。エラーが発生しました。何が変わるのでしょうか? 初期条件が次のティックで使えないかもしれないのに、なぜまた同じエラーになるのでしょうか? 追加と削除 "へのコメントはまだありません:-) OrderSelectを使ってOrderCloseTimeを取得するコードの動作例を教えてください。 1...45678910111213141516 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
チャンピオンシップのオーガナイザーに軽率な質問をしてすみませんでした。
賞金の課税はどうなるのか(各賞の金額が非常に大きいので)。
受賞者は自分で税金を払う必要があるのでしょうか?(そしてその割合は?) それとも一元化されるのか?( つまり、税金はすでに考慮されている?)。
税金で賞金の半分をあきらめるのはもったいない!
本当は、まったく勝てないほうが悔いが残らないのですが......。
チャンピオンシップのオーガナイザーに軽率な質問をしてすみませんでした。
賞金の課税はどうなるのか(各賞の金額が非常に大きいので)。
受賞者は自分で税金を払う必要があるのでしょうか?(そしてその割合は?) それとも一元化されるのか?( つまり、税金はすでに考慮されている?)。
税金で賞金の半分をあきらめるのはもったいない!
はい、受賞者は自分で税金を払います。これは、世界中の賞の標準的な慣習です。
問題は、エラーコードが135や138でない場合、ループが発生するかということです。その場合、どのようにすれば注文が閉まることを保証した上で、これを回避することができるのでしょうか。
この注文の終了が 常に正しく機能するかどうかをテストする方法はありません。
アドバイスの記事をもう一度読んでみてください。
ループによるエラー制御を徹底的に無視
(エラー制御をしている、保留注文は使わない、ループの終了条件も作った方がいい?では、オーダークローズ保証はどうするのか?それとも、すべてのエラーコードを処理できていないのでしょうか?
OrderSelectの制御不足 - 非同期処理の動作について
(そう、Order_Selectが何を返すかはチェックしないのです!この場合、falseを返すとすると、ループの中で何が変わるのでしょうか、何が間違っているのでしょうか?注文を修正するのではなく、閉めるのです!)
RefreshRates()によるマーケット環境更新機能のスキップ
(私はそれをリフレッシュすると思います、すべてがここで大丈夫なはずです)。
もしかしたら、すべての注文をクローズするためのコードが用意されているかもしれません。 投稿していただけると幸いです。
P.S. Rosh が提案したhttp://www.alpari-idc.ru/ru/experts/articles/9.html は、注文を閉じることを保証するものではありません。
- OrderSelectの 結果がチェックされない
- OrderClose()の結果が明示的にチェックされない。
- GetLastError() は、取引操作がなくても呼び出すことができます (たとえば、保留中の注文に遭遇した場合など)。
- RefreshRates()は常に呼び出されるわけではなく、障害が発生したときのみ呼び出される - これは重大なエラーである
- リストに未決済の注文がある場合、100%ループとなります。
結果:9行の中に5つのエラーがある - このコードは捨てられるしかない。5エラーでも
- OrderSelectの 結果がチェックされない
- OrderClose()の結果が明示的にチェックされない。
- GetLastError() は、取引操作がなくても呼び出すことができます (たとえば、保留中の注文に遭遇した場合など)。
- ...
結果:9行の中に5つのエラーがある - このコードは捨てられるしかない。OrderSelect は必要な注文を選択し、OrderClose は必要な注文を決済する必要があります。
そして、エラーは発生しないはずです :-)
あるいはクライアントの費用負担で :-)
5つのエラーまであります。
制限事項:保留中の注文は使用しない
1.注文をクローズする必要があるのに、なぜ結果を確認する必要があるのですか?もしfalseを返したら、whileループが使われているので、次のパスでそれに戻る。
2.ポイント1参照。
3.そのためのエラーコードのチェックがあります。
4.常に更新されるのであれば、エラーチェックの意味がない :(
5.保留中の注文はない
私が検索したオーダークローズの例はすべてシングルパスで、サーバーに問題がなく、リクオートなどがない場合にのみ機能します。そして、それらはすべて、ある日突然、注文が成立しなくなり、良い利益が得られるということにつながるのです......。もし私が間違っていたら、訂正するか、私が間違っていると確信できるようなリンクを教えてください。
もちろん、私のコードがループを引き起こす可能性があることは十分承知していますが、私の意見では、注文が成立せず、深刻な経済的損失につながるリスクよりはましだと思います。
全ての注文が100%保証され、注文が滞留する可能性がないことが望ましいのですが、このようなコードを提供して欲しいです =)。
以下は、保留中の注文も考慮するように、少し修正したコードです。
前作ほど「無謀」ではないのでは?
この場合、なぜOrderSelectとOrderCloseをチェックするのか、まだ理解できていません。
OrderSelectは必ずチェックすること、これはUseful Tipsに 明示されています。
通常、トレーダーは自分のプログラムをシングルタスクで唯一のものだと認識しています。しかし実際には、Expert Advisorの動作中に、取引口座で多くの非同期的な変更が行われます。 ポジションは変更、追加、削除されます。もし、各OrderSelect()呼び出しの結果が制御されていなければ、ある瞬間にエキスパートが間違った(ゼロ)データで動作し、間違った動きをすることが起こるかもしれないのです。
残念ながら、取引業務に関する保証はありません。上記のコードは、以前のものよりもはるかに優れています。
OrderSelectは必ずチェックすること、これはUseful Tipsに 明示されています。
...ポジションの変更、追加、削除 ...
追加と削除 "へのコメントはまだありません:-)
OrderSelectを使ってOrderCloseTimeを取得するコードの動作例を教えてください。