MQL4マスターに質問です。ダブルコンペアについてもう一度。 - ページ 2 123456789...11 新しいコメント Glaswegian 2007.09.09 23:40 #11 もう一度言います。 価格、ロット、お金......精度が決まっている。 インジケーターはフローティングです。 この違いは本質的なもので、doubleは両方を表すのに使われますが。実は「プログラミングスタイル」と呼ばれるものが決まっているのです。 繰り返しになりますが、「正しさ」の基準は人それぞれです。私の理解では、例えばNormalizeDouble()はとんでもなく非効率的で、結果的に絶対に不要な関数です。 Владимир 2007.09.09 23:49 #12 komposter: //--- Если value1 равняется value2 до precision знака после запятой, возвращает true, иначе - false. bool equal( double value1, double value2, int precision = 8 ) { return( nd( abs( nd( value1, precision ) - nd( value2, precision ) ), precision ) < nd( MathPow( 0.1, precision ), precision ) ); } コードは明快で、あなたの例はとても分かりやすいですね!そして、こちらはぼちぼち。 nd( MathPow( 0.1, precision ), precision ) に置き換えた方が良いのではないでしょうか? //--- Если value1 равняется value2 до precision знака после запятой, возвращает true, иначе - false. bool equal( double value1, double value2, int precision = 8 ) { return( nd(nd( abs( nd( value1, precision ) - nd( value2, precision ) ), precision )), precision ) == 0.0 ); } それとも、間違っているのでしょうか? Andrey Khatimlianskii 2007.09.09 23:51 #13 Irtron: 倍精度との数値比較の問題は、遠回しで、数学に対する基本的な無知からくるものです。 しかし、うらやましいほどの執念でフォーラムに登場します。 この「問題」を解決するための明確な指示を出すか、そのどちらかです =)。 イルトロン しかし、性能上の問題が出てきます。 何か提案はありますか(MT開発者レベルではなく、ユーザーレベル)? Glaswegian 2007.09.10 00:07 #14 komposter: 何か提案はありますか(MT開発者レベルではなく、ユーザーレベル)? 価格については、例えば競る、そこに、問う、止める。 int ComparePrice(double a, double b) { a -= b; b = Point / 2.; if (a > b) return (1); if (a < -b) return (-1); return (0); } ロットやレベルの計算はすべて整数で行った方が良い場合が多い。何倍も速く、原理的にサンプリング誤差がない。 Владимир 2007.09.10 00:07 #15 Irtron: もう一度言います。 価格、ロット、お金......精度が決まっている。 インジケーターはフローティングです。 この違いは本質的なもので、doubleは両方を表すのに使われますが。実は「プログラミングスタイル」と呼ばれるものが決まっているのです。 繰り返しになりますが、「正しさ」の基準は人それぞれです。私の理解では、例えばNormalizeDouble()はとんでもなく非効率的で、結果的に絶対に不要な関数です。 最近、どこかのスレッド(正確には覚えていませんが)で、Expert Advisorの動作がおかしいと文句を言っている人がいました。そして、彼の注文のためにサーバーから取った価格でさえ、まだ正規化する必要があることが判明したのです その後、NormalizeDouble()を必須プロシージャとして採用しただけです。私は本当にまだ、時々コードがどのように動作するのかよく理解していません。だからこそ、どのようにすべきなのかに興味があるのです。 また、NormalizeDouble()の代わりにどのような方法があるのでしょうか? Владимир 2007.09.10 00:11 #16 Irtron: komposter 何か提案はありますか(MT開発者レベルではなく、ユーザーレベルで)? 価格については、例えば競る、そこに、問う、止める。 int ComparePrice(double a, double b) { a -= b; b = Point / 2.; if (a > b) return (1); if (a < -b) return (-1); return (0); } ロットやレベルの計算はすべて整数で行った方が良い場合が多い。何倍も速く、原理的にサンプリング誤差がない。 そうですね、『オメガ』ではすべてがINTになっていました。まずMTですべてをINTに変換してから計算しろということでしょうか? P.S. そして、あなたのComparePriceはとても興味深いソリューションで、私もすぐに理解することができませんでした。 ComparePriceComparePrice Dmitry Fedoseev 2007.09.10 00:12 #17 Irtron: もう一度言います。 価格、ロット、お金......精度が決まっている。 インジケーターはフローティングです。 この違いは本質的なもので、doubleは両方を表すのに使われますが。実は「プログラミングスタイル」と呼ばれるものが決まっているのです。 繰り返しになりますが、「正しさ」の基準は人それぞれです。私の理解では、例えばNormalizeDouble()はとんでもなく非効率的で、結果的に絶対に不要な関数です。 まず、自分の注文でExpert Advisorを何本も書き、ストップロスが突然1ポイント間違っていたことが判明し、お客様の嵐を感じてください...。そして、NormalizeDouble()関数の不条理さを説明すると、どうなるんでしょうね=) Glaswegian 2007.09.10 00:17 #18 VBAG: そして、注文からサーバーから取り出した価格も、まだ正規化する必要があることが判明しました!!!! ありえない(c)。MTのガワはほとんどノーマライズできない。 昔も今も、理解できないヒストリカルデータでテストすると、EAのパフォーマンスが理解できない、という話はよくあります。 Andrey Khatimlianskii 2007.09.10 00:22 #19 Irtron: 価格については、例えば競る、そこに、問う、止める。 それはもう、何かの縁です。より具体的になってきましたね ;) 価格比較をするのであれば、私のようなオーバーロードの機能は必要ない。 そして、簡略化された形では、ComparePriceと同じように高速に動作する。 int start() { double a = 1.23450001, b = 1.23449999; int start1 = GetTickCount(), c1; for ( c1 = 0; c1 < 100000000; c1 ++ ) ComparePrice( a, b ); int end1 = GetTickCount(); int start2 = GetTickCount(), c2; for ( c2 = 0; c2 < 100000000; c2 ++ ) equal( a, b ); int end2 = GetTickCount(); Print( "ComparePrice: ", (end1-start1), ", equal: ", (end2-start2) ); return(0); } int ComparePrice(double a, double b) { a -= b; b = Point / 2.; if (a > b) return (1); if (a < -b) return (-1); return (0); } bool equal( double a, double b ) { return( MathAbs( a - b ) < Point ); } 2007.09.10 03:19:24 CheckCompareDoubleSpeed GBPUSD,Daily: ComparePrice:20922, equal:20453. Glaswegian 2007.09.10 00:25 #20 Integer: まずは自分の注文でExpert Advisorを何本か書いて、いきなりストップロスが1pip間違っていることが判明してお客さんの嵐を感じて...という感じです。そして、NormalizeDouble()関数の不条理さを説明すると、どうなるんでしょうね=) 秘密を教えてあげよう。 私はこれまで、必要以上に多くのカスタムExpert Advisorを作成してきましたが、購入する理由がないため、購入したいという衝動に駆られたことは一度もありません。私のプログラムでは、ストップロスはあるべき位置にあることが保証されています(「見える」のではありません)。そのため、特に特殊な機能については、お客様に説明する必要がありません。EAを書く意味は、そうしたクライアントへの疑問や説明をなくすことにあるように思います。 123456789...11 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
価格、ロット、お金......精度が決まっている。
インジケーターはフローティングです。
この違いは本質的なもので、doubleは両方を表すのに使われますが。実は「プログラミングスタイル」と呼ばれるものが決まっているのです。
繰り返しになりますが、「正しさ」の基準は人それぞれです。私の理解では、例えばNormalizeDouble()はとんでもなく非効率的で、結果的に絶対に不要な関数です。
に置き換えた方が良いのではないでしょうか?
それとも、間違っているのでしょうか?
倍精度との数値比較の問題は、遠回しで、数学に対する基本的な無知からくるものです。
この「問題」を解決するための明確な指示を出すか、そのどちらかです =)。
しかし、性能上の問題が出てきます。
何か提案はありますか(MT開発者レベルではなく、ユーザーレベル)?
ロットやレベルの計算はすべて整数で行った方が良い場合が多い。何倍も速く、原理的にサンプリング誤差がない。
もう一度言います。
価格、ロット、お金......精度が決まっている。
インジケーターはフローティングです。
この違いは本質的なもので、doubleは両方を表すのに使われますが。実は「プログラミングスタイル」と呼ばれるものが決まっているのです。
繰り返しになりますが、「正しさ」の基準は人それぞれです。私の理解では、例えばNormalizeDouble()はとんでもなく非効率的で、結果的に絶対に不要な関数です。
その後、NormalizeDouble()を必須プロシージャとして採用しただけです。私は本当にまだ、時々コードがどのように動作するのかよく理解していません。だからこそ、どのようにすべきなのかに興味があるのです。
また、NormalizeDouble()の代わりにどのような方法があるのでしょうか?
何か提案はありますか(MT開発者レベルではなく、ユーザーレベルで)?
ロットやレベルの計算はすべて整数で行った方が良い場合が多い。何倍も速く、原理的にサンプリング誤差がない。
P.S. そして、あなたのComparePriceはとても興味深いソリューションで、私もすぐに理解することができませんでした。
もう一度言います。
価格、ロット、お金......精度が決まっている。
インジケーターはフローティングです。
この違いは本質的なもので、doubleは両方を表すのに使われますが。実は「プログラミングスタイル」と呼ばれるものが決まっているのです。
繰り返しになりますが、「正しさ」の基準は人それぞれです。私の理解では、例えばNormalizeDouble()はとんでもなく非効率的で、結果的に絶対に不要な関数です。
まず、自分の注文でExpert Advisorを何本も書き、ストップロスが突然1ポイント間違っていたことが判明し、お客様の嵐を感じてください...。そして、NormalizeDouble()関数の不条理さを説明すると、どうなるんでしょうね=)
そして、注文からサーバーから取り出した価格も、まだ正規化する必要があることが判明しました!!!!
昔も今も、理解できないヒストリカルデータでテストすると、EAのパフォーマンスが理解できない、という話はよくあります。
価格については、例えば競る、そこに、問う、止める。
価格比較をするのであれば、私のようなオーバーロードの機能は必要ない。
そして、簡略化された形では、ComparePriceと同じように高速に動作する。
まずは自分の注文でExpert Advisorを何本か書いて、いきなりストップロスが1pip間違っていることが判明してお客さんの嵐を感じて...という感じです。そして、NormalizeDouble()関数の不条理さを説明すると、どうなるんでしょうね=)
秘密を教えてあげよう。
私はこれまで、必要以上に多くのカスタムExpert Advisorを作成してきましたが、購入する理由がないため、購入したいという衝動に駆られたことは一度もありません。私のプログラムでは、ストップロスはあるべき位置にあることが保証されています(「見える」のではありません)。そのため、特に特殊な機能については、お客様に説明する必要がありません。EAを書く意味は、そうしたクライアントへの疑問や説明をなくすことにあるように思います。