long A = AccountInfoInteger(ACCOUNT_LOGIN); // 661701long B = A;
long C = 661701;
Print(" A=",A," B=",B," C=",C);
long X =10000;
long L1 = A*X;
long L2 = B*X;
long L3 = C*X;
Print(" L1=",L1," L2=",L2," L3=",L3);
そして、その結果がこちらです。
L1=2322042704 L2=2322042704 L3=6617010000
A =661701 B =661701 C =661701
voidOnStart()
{
int A = 661701;
int B = A;
long C = 661701;
Print(" A=",A," B=",B," C=",C);
uint X =10000;
long L1 = A*X;
long L2 = B*X;
long L3 = C*X;
Print(" L1=",L1," L2=",L2," L3=",L3);
}
/* Вывод в лог (хронология - сверху вниз):
KO 0 1 (EURUSD,M15) 00:46:28 A=661701 B=661701 C=661701
OE 0 1 (EURUSD,M15) 00:46:28 L1=2322042704 L2=2322042704 L3=6617010000
*/
そして、元のコードの仕組みはこうなっています。
voidOnStart()
{
long A = 661701;
long B = A;
long C = 661701;
Print(" A=",A," B=",B," C=",C);
long X =10000;
long L1 = A*X;
long L2 = B*X;
long L3 = C*X;
Print(" L1=",L1," L2=",L2," L3=",L3);
}
/* Вывод в лог (хронология сверху вниз):
DL 0 1 (EURUSD,M15) 00:49:13 A=661701 B=661701 C=661701
HG 0 1 (EURUSD,M15) 00:49:13 L1=6617010000 L2=6617010000 L3=6617010000
*/
単純な 私は、同じ方法で、int型への明示的な変換を行いました。最大可能ロットは、ブローカーやディーラーによって、あるいは自己資金の大きさ によって制限されると想定していました。だから、intを使えば十分なはずです。この方法（intを使った底辺からの丸め込み）に落とし穴はないでしょうか？
実際の取引では、おそらく、そうですね、int/uintで十分だと思います。
ただ、テスターで動かすと、実験によっては物足りないかもしれませんね。
数式から得られる整数Nが0〜INT_MAXの範囲に収まり、オーバーフローしないことを保証すれば、MQL5の実装で次に起こりうる不具合以外に、落とし穴はありません。つまり、チェックを入れ替える
tmp < ULONG_MAX * stepvolまで
tmp < INT_MAX * stepvol実はint型は符号付きで、取り得る値の半分が負の数の領域内にあるのですが、ここでは常に非負の値になっています。非負領域に同じ大きさで2倍の範囲を持つunsigned uintがあるのに、intを使うのは不合理である。したがって、int/uintを使うのであれば、それぞれuintを使い、チェックをuintに置き換えた方がよいでしょう。
tmp < UINT_MAX * stepvolgumgum:
#property script_show_inputs実際の取引では、ほとんどの場合、int/uintで十分です。
...実はint型は 符号付きで、取り得る値の半分が負の数の領域にあり、ここでは常に非負になる。非負領域に同じ大きさで2倍の範囲を持つ符号なしintがあるのに、intを使うのは不合理である。したがって、int/uintを使うのであれば、それぞれuintを使い、チェックをuintに置き換えた方がよいでしょう。
バグではありませんが、タイプに関する興味深い観察です。
2の2倍、つまり2*2とは何だと思いますか？
と思っているあなた、もしかしたらそうかもしれませんよ
OK、こんなのはどうでしょう
にじゅうまんえん
200000 * 200000
小学生でも、2と4を掛け合わせ、ゼロを足して...。
40000000000.
では、機械の言語で簡単なコードを書いてみましょう。
long lots = 200000*200000;
変数のホスト型がlongであることに注意してください．
最小値は-9 223 372 036 854 775 808、最大値は9 223 372 036 854 775 807とする。
合計をプリントアウトすると
ロット = 1345294336
というのは、2×2で2が得られるというのとは大違いです。
型と型変換について、ヘルプを読み直しました。
通常の数値を正しい型に明示的にキャストする必要があるという情報は見つかりませんでした
然うは斯くやあらん
long lots = (long) 200000 * (long) 200000。
または、補助変数を追加で使用することもできます。
まだまだありますよ。
あるプロパティを大きな数で取得し、掛け合わせたい場合......。
以下はそのコードです。
そして、その結果がこちらです。
入力は同じでも結果が違うSHOOTER777:
そして、今度は機械語による簡単なコード
long lots = 200000*200000;
long変数の受信型はlongであることに注意。
最小値は-9 223 372 036 854 775 808、最大値は9 223 372 036 854 775 807です。
合計をプリントして取得
ロット = 1345294336
というのは、2×2で2が得られるというのとは大違いです。
型と型変換について、ヘルプを読み直しました。
通常の数値を特定の型に明示的にキャストする必要があるという情報は見つかりませんでした。
然うは斯くやあらん
long lots = (long) 200000 * (long) 200000。
また、補助変数を使用することもできます。
"普通の数字 "は定数表現で、型も持っている。この場合、int型である。
2つの部分式（それぞれint型）の掛け算からなる式もint型である。ここでオーバーフローが発生する。
そして、このときだけ、long型の変数を初期化する際に、int式の型からlong型への暗黙の変換が発生します。
ここではすべてがクリアになる。ちなみに、この場合の各オペランドは、long型にキャストする必要はない。1つ唱えれば十分で、2つ目は暗黙のうちに唱えられる。
まだまだありますよ。
いくつかのプロパティを取得して、大きな数字で掛け算をしたい場合...。
以下はそのコードです。
そして、その結果がこれです。
ソースデータは同じですが、結果は異なります。ログとコードがごっちゃになっているようです。上記のコードは、「きれいに」動作します。そして、このようなログを得るためには、変数AとBをint型またはuint型にし、変数Xをuint型に する必要があったのです。
そして、元のコードの仕組みはこうなっています。
ビルド314（2010年8月20日）。
例えば、あるインジケータの値を取得したい場合、教えてください。以前は内蔵機能で正確かつ確実に取得できていたのですが。今は、たくさんのコード、バッファ、ハンドルなどを使って、自分で書かなければなりません。でも、そんなことはどうでもいいんです。私にとっては、文字通り一行ごとにコードが不具合になることが最大の問題で、エラーが発生していないことを確認するために、一行ごとにこれをチェックしなければならないからです...。一般的に、これらの複雑さやクラス、初歩的なことなのに面倒で不便になったことは、スピードや信頼性などを高めるために行われていると考えていましたが......。20個の信号について記事を読んだのですが...。と書いてあります。
"インジケータ値の計算に時間がかかるため、作成直後にインジケータデータにアクセスすることはできません。したがって、OnInit() でインジケータハンドルを作成するのがよいでしょう。"
次に、各行に対するチェックがあります
"確認してみましょう。必要なデータより少ない場合は、コピーエラーが発生したことを意味し、データが格納されているはずの配列にそれ以上アクセスするとエラーになります。これを除外するために、機能を終了させます。"
だから、スピードアップする代わりに、この関数をループ（何回）して、最後に結果を出す必要があるんだ...。また、異なるインジケータの別々の行の個々の値が定期的に必要な場合....これは、各値に対応した個別の機能...余計な変数やコードが多いな...。
要するに、説明してください、リンク先を教えてください、私はこのすべての意味を理解したいのです、なぜそうであり、そうでないのか、信頼できるのか・・・。
そして、そのような質問に対する回答は、µl4からµl5への移行ヘルプのセクションに置くか、フォーラムに関連セクションを作り、議論なしで、特に質問と回答、そしてその理由の説明をしていただければ良いと思うのですが・・・。例えば、ここでは 時代について非常にわかりやすく説明されているので、初歩的な質問にも同じように回答してもらえると良いと思います
例えば、あるインジケーターの値を取得したい場合、教えてください。以前は内蔵機能できっちり確実に取得していました。今は、たくさんのコード、バッファ、ハンドルなどを使って、自分で書かなければなりません。でも、そんなことはどうでもいいんです。私にとっては、文字通り一行ごとにコードが不具合になることが最大の問題で、エラーが発生していないことを確認するために、一行ごとにこれをチェックしなければならないからです...。一般的に、これらの複雑さやクラス、初歩的なことなのに面倒で不便になったことは、スピードや信頼性などを高めるために行われていると考えていましたが......。20個の信号について記事を読んだのですが...。と書いてあります。
"インジケータ値の計算に時間がかかるため、作成直後にインジケータデータにアクセスすることはできません。したがって、OnInit() でインジケータハンドルを作成するのがよいでしょう。"
次に、各行に対するチェックがあります
"確認してみましょう。必要なデータより少ない場合は、コピーエラーが発生したことを意味し、データが格納されているはずの配列にそれ以上アクセスするとエラーになります。これを除外するために、機能を終了させます。"
だから、スピードアップする代わりに、この関数をループ（何回）して、最後に結果を出す必要があるんだ...。また、異なるインジケータの別々の行の個々の値が定期的に必要な場合....これは、各値に対応した個別の機能...余計な変数やコードが多いな...。
要するに、説明してください、リンク先を教えてください、私はこのすべての意味を理解したいのです、なぜそうで、それほど信頼できないのか・・・。
そして、そのような質問に対する回答は、µl4からµl5への移行ヘルプのセクションに置くか、フォーラムに関連セクションを作り、議論なしで、特に質問と回答、そしてその理由の説明をしていただければ良いと思うのですが・・・。例えば、ここでは 時代について非常にわかりやすく説明していますが、それと同じように、初歩的な疑問にも答えてもらいたいと考えています。
より信頼性が高いのでしょうか？初期化時のハンドルの取得が不安定なのはなぜですか？なぜ、必要なデータの入手状況を確認することが信頼できないのでしょうか？ましてや、チェックが入ることがなぜ信頼できないのか。
初心者の方には難しいかもしれませんが、時間が経つにつれて、だんだん分かってくると思います。
より信頼性が高い？初期化時のハンドルの取得が確実でないのはなぜですか？必要なデータの確認ができないのはなぜですか？ましてや、チェックを持つことは、なぜ信頼できないのか。
初心者の方には分かりにくいかもしれませんが、そのうち分かるようになると思います...。