Alexandr Sokolov: そうですね、私のバリエーションはベストではないかもしれませんが、今までそれに関するものが見つからなかったので、自分で思いついたベストです、あなたが自分のバリエーションを提案しないのに対して、私は上でコメントしました。
これらのバリエーションを比較してみました。
int ds(double v){
string s=(string)v;
int l=StringLen(s);
int n=l-StringFind(s,".",0)-1;
if(StringSubstr(s,l-1,1)=="0")n--;
return(n);
}
int d(double x){
int n;
for(n=0;n<8;n++){
if(x==NormalizeDouble(x,n)){
return(n);
}
}
return(n-1);
}
そういうことでは全然ないんです。デュブルを文字列に変換して、その文字列の中の文字を数えるという発想は完全にナンセンスです。何をやってもダメ。
何が大変なんだ？今のところ、このオプションが最も速く、最も機能的で、正しいことが保証されています。選択肢は？
そうですね、私のバリエーションはベストではないかもしれませんが、今までそれに関するものが見つからなかったので、自分で思いついたベストです、あなたが自分のバリエーションを提案しないのに対して、私は上でコメントしました。
これらのバリエーションを比較してみました。
文字列のバリエーションは若干高速で、d()のように8桁に制限されることもありません。そして、正しさの保証は、端末の数値の表示方法によるカウントである。
私は、文字列に変換するバリアントを選択します。
何が大変なんだ？今のところ、このオプションが最も速く、最も機能的で、正しい選択であることが保証されています。選択肢は？
上記のアルゴリズムを応用したケースを少なくとも1つ挙げることができますか？
上記のアルゴリズムを応用したケースを少なくとも1つ挙げることができますか？
取引パネルで、テキストフィールドに正しい小数点 以下の桁数のロットサイズが出力されるケースが1件ありました。このケースだけです。
取引パネルで、テキストボックスに正しい小数点以下の 桁数のロットサイズが出力されるケースが1件ありました。このケースだけです。
つまり、1ロットの場合は "1"、0.01ロットの場合は "0.01 "と出力されるのでしょうか？
1ロットの場合は「1」、0.01ロットの場合は「0.01」と出力されるわけですね。
そうではありません。最小ロットとロットステップによります。最小ロットが0.01の場合、1は1.00と表示される
そうでもないんです。最小ロットとロット増分による。最小ロットが0.01の場合、1は1.00と表示される
O.O.
つまり、あなたの関数を使わずに、DoubleToString(LotSize, <some const value>)のような表示をしていることがわかりましたね。
o.o
つまり、あなたの関数を使わなくても、DoubleToString(LotSize, <some const value>)のようなものが出力されることがわかりましたね。
ただし、小数点以下何桁まで出力するかは知っておく必要があります。
ただし、小数点以下何桁まで出力するかは知っておく必要があります。
つまり、ユーザーが入力したmin.lot（またはlot increment）を使って、この値が小数点以下何桁なのかを判断し、将来の値を正規化するために保存するのでしょうか？
つまり、ユーザーが入力したmin.lot（またはlot increment）から、その値が小数点以下何桁であるかを判断し、将来の値を正規化するために保存するのですね。
何がわからないんだ？価格にはDigits() があるが、出来高にはない。このように計算されます。
なぜボリューム桁が必要なのですか？価格の桁が必要な理由と同じです