"ダミー "からの質問 - ページ 13 1...67891011121314151617181920...277 新しいコメント 削除済み 2011.06.23 08:29 #121 stringo: 実は、メッセージには8バイトもの情報が付与されており、どのようにでも解釈できる。datetime、double、4short、8char、64bitをビット単位で指定することができる。 4の時は4バイトのマジックで何でもエンコードできましたが、今は8バイトです。必要なのは、願い事だけ。そうなんですよね、4で結構使ってましたし、記事も読みました(発想は結構好きです)。なぜ、異なる場所で異なるタイプが指定されているのか? Cron 2011.06.23 10:03 #122 TPとSLがあるポジションで、価格がTPに近く、今すぐ終了する必要がある場合、どのようにクローズ すればよいかアドバイスをお願いします。同じ数量の新規ポジションを建てる注文を出す。ほとんどの場合、うまくいきます。でも、時々、TPによってクローズする時間があるポジションが、クローズする代わりに、マーケットで新しいポジションを取得する状況があるのですが・・・。:(オープンしたポジションが既存のポジションのクローズであり、メインポジションが既にクローズされている場合、新しいポジションをオープンするのではないことを示すにはどうすればよいですか?クローズ前にSLとTPを外すとか、TPがクローズするのを待つとか、そういうオプションも考えられるけど、いい加減な解決策だよね。MT4のように、ポジションをCLOSEするような簡単な操作はできないのでしょうか? --- 2011.06.23 14:13 #123 CTradeクラスのPositionCloseを 検索してください。 ということになるのでしょう。結論は一つ、「他に道はない」です。しかし、私はあなたの要望を支持します。開発者の方々には、このバリエーションを検討していただきたいと思います。TRADE_ACTION_CLOSEの 操作タイプを追加- 指定されたシンボルのポジションを現在の 価格でその出来高で決済します。 Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров www.mql5.com Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров - Документация по MQL5 Yedelkin 2011.06.23 18:38 #124 stringo: 実は、このメッセージには8バイトの情報が詰まっていて、どうにでも解釈できるのです。datetime、double、4short、8char、64bitをビット単位で指定することができる。 4の時は4バイトのマジックで何でもエンコードできましたが、今は8バイトです。それは希望的観測に過ぎないだろう。 longとulongの8バイト程度はReferenceでクリアしていました。厄介なのは、マジックとの関連で、このタイプの使い分けに一貫性がないことです。 簡単な例として、取引要求の送信時に request.magic=ULONG_MAX-1 を指定してもよい。リファレンスマニュアルに、OrderGetInteger(ORDER_MAGIC )関数はlong型のみを返すと書かれているのはなぜですか?さらに、マジックはポジションとトレードの両方でロングタイプも返します。 では、もともとはどのように設計されていたのでしょうか。HistoryDealGetInteger(),PositionGetInteger(),OrderGetInteger() などは、LONG_MAXより 大きな整数値を返すことを意図していないため、MqlTradeRequest 構造 体にマジックがlong型であることを指定すべきかもしれませんね。 削除済み 2011.06.23 19:26 #125 Yedelkin: longとulongの8バイトは、リファレンスマニュアルからクリアしました。マジックとの関連で、これらのタイプの一貫性のない使い方は困ったものです。 簡単な例として、取引依頼を送信する際に、request.magic=ULONG_MAX-1を指定しても良いことになっています。リファレンスマニュアルに、OrderGetInteger(ORDER_MAGIC )関数はlong型のみを返すと書かれているのはなぜですか?さらに、マジックはポジションとトレードの両方でロングタイプも返します。 では、もともとはどのように設計されていたのでしょうか。HistoryDealGetInteger(),PositionGetInteger(),OrderGetInteger() などは、LONG_MAXより 大きな整数値を返すことを意図していないため、MqlTradeRequest 構造 体にマジックがlong型であることを指定すべきかもしれませんね。実際には、magikはlong 型です(これは、負のmagikと long 型の値域外の値を持つmagikを形成することで簡単に確認 することができます)。それを確認するために、Night Expert Advisorを少し修正します(標準ライブラリのクラスは使用しません)。実験をきれいにするために、 EA_Magicの パラメータタイプをlongに 変更し、履歴の最後の注文のマジックを解除 する必要があります(注文が正常に設定されている場合)。 Yedelkin 2011.06.23 19:40 #126 Interesting: В действительности магик имеет тип long (это легко проверяется формированием отрицательного магика и магика со значением выходящим за диапазон значений типа long). その場合、MqlTradeRequest 構造体の magic 要素の記述において、型名から "u" を削除して明確化する必要がある。 Документация по MQL5: Стандартные константы, перечисления и структуры / Структуры данных / Структура торгового запроса www.mql5.com Стандартные константы, перечисления и структуры / Структуры данных / Структура торгового запроса - Документация по MQL5 削除済み 2011.06.23 19:51 #127 Yedelkin: その場合、MqlTradeRequest 構造体のmagic要素の型名から "u"を削除し、その記述を明確にする必要がある。CTrade クラスにも変更を加えるのがよいでしょう(開発者が魔法値を正の値のみに制限したくない場合)。 --- 2011.06.23 21:06 #128 stringo: 実際には、8バイトもの情報が与えられており、自由に解釈することができる。datetime、double、4short、8char、64bitをビット単位で指定することができる。 4の時は4バイトのマジックで何でもエンコードできましたが、今は8バイトです。それは希望的観測に過ぎないだろう。実は、64ビットではなく、63ビットしかない(つまり8バイトの不完全な状態)のです。長い 範囲を全部使うと8バイトになります。しかし、残念ながら...。一方、MqlTradeRequest 構造体には、魔法のulongが渡さ れる。正の値しか設定できないことを意味する。一方、PositionGetInteger/OrderGetInteger関数は long 型を返します 。ulongレンジの半分がカットされるということです。実際にあるのは、上記の64ビットではなく63ビットです。実は、オーダーチェックの原則に大きな不都合が あるかというと、そうでもないのです。MT4と同じシステムで、サインでマジックを許可する方がよっぽど便利だと思うのですが。多くのトレーディングシステムは、まさにマジシャンのシンボルを使ったシンプルな原理に基づいているためです。1つのシステムを2つに分けて、通常のMathAbs( OrderMagicNumber() ) 関数を使って注文をフィルタリングする方がはるかに簡単なので。 Renat Fatkhullin 2011.06.23 21:56 #129 sergeev:実際には64ビットではなく、63ビット(つまり不完全な8バイト)しかないのです。8バイトは、長い 範囲全体を使用する場合である。あなたは勘違いしています。 64ビットが使われているので、どう使うかはあなた次第です。Long/ulongの違いはなく、全てはこの64ビットをどう解釈するかによります。longを符号付きlongとして使いたいなら-、符号なしulongとして使いたいなら-、問題なし。この64ビットで他のデータ型を使いたい場合は、そうしてください。これはまさにスラバが書いた通りだ。 Vladimir Gomonov 2011.06.23 22:21 #130 sergeev:実際には64ビットではなく、63ビット(つまり不完全な8バイト)しかないのです。8バイトは、長い 範囲全体を使用する場合です。しかし、残念ながら...。一方、MqlTradeRequest 構造体には、魔法のulongが渡さ れる。正の値しか設定できないことを意味する。一方、PositionGetInteger/OrderGetInteger関数は long 型を返します 。ulongレンジの半分がカットされるということです。全部で64ビットではなく、63ビットになりました。実は、オーダーチェックの原則に大きな不都合が あるかというと、そうでもないのです。MT4と同じシステムで、サインでマジックを許可する方がよっぽど快適だと思うのですが。多くのトレーディングシステムは、まさにマジシャンのシンボルを使ったシンプルな原理に基づいているためです。1つのシステムを2つに分けて、通常のMathAbs( OrderMagicNumber() ) 関数を使って注文をフィルタリングする方がはるかに簡単なので。正直困惑している。 君たちは大したことないのにやりすぎだよ。まったくもって、そんなことはありません。この問題は存在しない、あなたが作り出しただけです。型変換を最後まで整理する。下の作品があなたのお役に立てれば幸いです。それをスクリプトにコピーしてコンパイルし、 ターミナルで実行してから、よく考えてみてください。頑張ってください。void OnStart() { Print("//------ "); int i_A = -100; uint ui_B = uint(-100); Print(i_A," ",uint(i_A)); Print(int(ui_B)," ",ui_B); i_A = int(4294967196); ui_B = 4294967196; Print(i_A," ",uint(i_A)); Print(int(ui_B)," ",ui_B); //-- long l_A = -100; ulong ul_B = ulong(-100); Print(l_A," ",ulong(l_A)); Print(long(ul_B)," ",ul_B); l_A = long(18446744073709551516); ul_B = 18446744073709551516; Print(l_A," ",ulong(l_A)); Print(long(ul_B)," ",ul_B); } 1...67891011121314151617181920...277 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
実は、メッセージには8バイトもの情報が付与されており、どのようにでも解釈できる。datetime、double、4short、8char、64bitをビット単位で指定することができる。
4の時は4バイトのマジックで何でもエンコードできましたが、今は8バイトです。必要なのは、願い事だけ。
そうなんですよね、4で結構使ってましたし、記事も読みました(発想は結構好きです)。
なぜ、異なる場所で異なるタイプが指定されているのか?
TPとSLがあるポジションで、価格がTPに近く、今すぐ終了する必要がある場合、どのようにクローズ すればよいかアドバイスをお願いします。
同じ数量の新規ポジションを建てる注文を出す。ほとんどの場合、うまくいきます。でも、時々、TPによってクローズする時間があるポジションが、クローズする代わりに、マーケットで新しいポジションを取得する状況があるのですが・・・。:(
オープンしたポジションが既存のポジションのクローズであり、メインポジションが既にクローズされている場合、新しいポジションをオープンするのではないことを示すにはどうすればよいですか?
クローズ前にSLとTPを外すとか、TPがクローズするのを待つとか、そういうオプションも考えられるけど、いい加減な解決策だよね。MT4のように、ポジションをCLOSEするような簡単な操作はできないのでしょうか?
CTradeクラスのPositionCloseを 検索してください。
ということになるのでしょう。結論は一つ、「他に道はない」です。
しかし、私はあなたの要望を支持します。開発者の方々には、このバリエーションを検討していただきたいと思います。
TRADE_ACTION_CLOSEの 操作タイプを追加- 指定されたシンボルのポジションを現在の 価格でその出来高で決済します。
実は、このメッセージには8バイトの情報が詰まっていて、どうにでも解釈できるのです。datetime、double、4short、8char、64bitをビット単位で指定することができる。
4の時は4バイトのマジックで何でもエンコードできましたが、今は8バイトです。それは希望的観測に過ぎないだろう。
longとulongの8バイト程度はReferenceでクリアしていました。厄介なのは、マジックとの関連で、このタイプの使い分けに一貫性がないことです。
簡単な例として、取引要求の送信時に request.magic=ULONG_MAX-1 を指定してもよい。リファレンスマニュアルに、OrderGetInteger(ORDER_MAGIC )関数はlong型のみを返すと書かれているのはなぜですか?さらに、マジックはポジションとトレードの両方でロングタイプも返します。
では、もともとはどのように設計されていたのでしょうか。HistoryDealGetInteger(),PositionGetInteger(),OrderGetInteger() などは、LONG_MAXより 大きな整数値を返すことを意図していないため、MqlTradeRequest 構造 体にマジックがlong型であることを指定すべきかもしれませんね。
longとulongの8バイトは、リファレンスマニュアルからクリアしました。マジックとの関連で、これらのタイプの一貫性のない使い方は困ったものです。
簡単な例として、取引依頼を送信する際に、request.magic=ULONG_MAX-1を指定しても良いことになっています。リファレンスマニュアルに、OrderGetInteger(ORDER_MAGIC )関数はlong型のみを返すと書かれているのはなぜですか?さらに、マジックはポジションとトレードの両方でロングタイプも返します。
では、もともとはどのように設計されていたのでしょうか。HistoryDealGetInteger(),PositionGetInteger(),OrderGetInteger() などは、LONG_MAXより 大きな整数値を返すことを意図していないため、MqlTradeRequest 構造 体にマジックがlong型であることを指定すべきかもしれませんね。
実際には、magikはlong 型です(これは、負のmagikと long 型の値域外の値を持つmagikを形成することで簡単に確認 することができます)。
それを確認するために、Night Expert Advisorを少し修正します(標準ライブラリのクラスは使用しません)。
実験をきれいにするために、 EA_Magicの パラメータタイプをlongに 変更し、履歴の最後の注文のマジックを解除 する必要があります(注文が正常に設定されている場合)。
Interesting:
В действительности магик имеет тип long (это легко проверяется формированием отрицательного магика и магика со значением выходящим за диапазон значений типа long).
その場合、MqlTradeRequest 構造体のmagic要素の型名から "u"を削除し、その記述を明確にする必要がある。
実際には、8バイトもの情報が与えられており、自由に解釈することができる。datetime、double、4short、8char、64bitをビット単位で指定することができる。
4の時は4バイトのマジックで何でもエンコードできましたが、今は8バイトです。それは希望的観測に過ぎないだろう。
実は、64ビットではなく、63ビットしかない(つまり8バイトの不完全な状態)のです。長い 範囲を全部使うと8バイトになります。
しかし、残念ながら...。
一方、MqlTradeRequest 構造体には、魔法のulongが渡さ れる。正の値しか設定できないことを意味する。
一方、PositionGetInteger/OrderGetInteger関数は long 型を返します 。ulongレンジの半分がカットされるということです。
実際にあるのは、上記の64ビットではなく63ビットです。実は、オーダーチェックの原則に大きな不都合が あるかというと、そうでもないのです。
MT4と同じシステムで、サインでマジックを許可する方がよっぽど便利だと思うのですが。多くのトレーディングシステムは、まさにマジシャンのシンボルを使ったシンプルな原理に基づいているためです。1つのシステムを2つに分けて、通常のMathAbs( OrderMagicNumber() ) 関数を使って注文をフィルタリングする方がはるかに簡単なので。
実際には64ビットではなく、63ビット(つまり不完全な8バイト)しかないのです。8バイトは、長い 範囲全体を使用する場合である。
あなたは勘違いしています。
64ビットが使われているので、どう使うかはあなた次第です。Long/ulongの違いはなく、全てはこの64ビットをどう解釈するかによります。longを符号付きlongとして使いたいなら-、符号なしulongとして使いたいなら-、問題なし。この64ビットで他のデータ型を使いたい場合は、そうしてください。
これはまさにスラバが書いた通りだ。
実際には64ビットではなく、63ビット(つまり不完全な8バイト)しかないのです。8バイトは、長い 範囲全体を使用する場合です。
しかし、残念ながら...。
一方、MqlTradeRequest 構造体には、魔法のulongが渡さ れる。正の値しか設定できないことを意味する。
一方、PositionGetInteger/OrderGetInteger関数は long 型を返します 。ulongレンジの半分がカットされるということです。
全部で64ビットではなく、63ビットになりました。実は、オーダーチェックの原則に大きな不都合が あるかというと、そうでもないのです。
MT4と同じシステムで、サインでマジックを許可する方がよっぽど快適だと思うのですが。多くのトレーディングシステムは、まさにマジシャンのシンボルを使ったシンプルな原理に基づいているためです。1つのシステムを2つに分けて、通常のMathAbs( OrderMagicNumber() ) 関数を使って注文をフィルタリングする方がはるかに簡単なので。
正直困惑している。 君たちは大したことないのにやりすぎだよ。まったくもって、そんなことはありません。この問題は存在しない、あなたが作り出しただけです。型変換を最後まで整理する。
下の作品があなたのお役に立てれば幸いです。それをスクリプトにコピーしてコンパイルし、 ターミナルで実行してから、よく考えてみてください。頑張ってください。