MQL4マスターに質問です。ダブルコンペアについてもう一度。 - ページ 7 1234567891011 新しいコメント Владимир 2007.09.17 12:57 #61 SK. писал (а): この会話はいつまでも続くようだ。新しいユーザーが適切な経験と知識を得るまでに、通常、何度か正常化にぶつかることがあります。 MT5では、比較演算を行う際の実数の精度を強制的に小数点以下8桁に制限する（つまり、強制的にdigit=8でNormalizeDouble()を実行する）ことに意味があるのかもしれません。 あなたには期待してないわよ。絶対にダメです! 比較演算が繰り返し使用される場合（再帰計算など）、入力で8桁に丸めれば、出力誤差を1に見合うものにできる。 SmoothedAvaregeの計算については、1年前に自分のアプリケーションで計算して、そんな経験をしました。その上で、替え玉の桁数に影響を与えないような働き方を選択するようにしています。 あるいは、gravity001 さんが提案されたように、INTamに切り替える（これは、ご理解の通り、非常に手間がかかります）。 Candid 2007.09.17 13:04 #62 SK. писал (а): MT5では、比較演算を行う際の実数の精度を、例えば小数点以下8桁に強制的に制限する（つまり、強制的にdigit=8でNormalizeDouble()を実行する）ことに意味があるのかもしれません。 しかし、ユーザー定義の操作だけでなく、端末に隠されている操作でも遅くなる。単純にComparePrice関数を言語に導入することが望ましいと思われます。ちなみに、私もIrtronさんと同じく、Point/2は自然な尺度だと考えています（Point *0.5の方がいいかもしれません）。毎回割り算・掛け算をしなくて済むように、この半分をあらかじめ変数にしておくことができます。それが存在しないまでは、そのような変数を自分で入力し、最初の起動時に一度だけ計算することができます。しかし、開発者は、あらかじめ定義された精度で二重比較の機能を作ることができる、つまり、同じだが、Point/2の代わりに桁を使うことができる。 Владимир 2007.09.17 13:07 #63 Depfy: せっかく作ったのに...。:) 浮動小数点数の比較は、差のモジュラスを小さな閾値と比較することによって行われます。 例えば、（fabs(d1-d2) < 1e-10）を返す。 何をお茶を濁すんだ・・・。NormalizeDouble(...)関数は、見栄えの良いレポートのためだけのものです。 例を挙げていただきありがとうございます。 でも、論点がずれている、もっとよく読めよ。質問の本質は、一般的なプログラミングスタイルと、MT4という特殊なケースでのプログラミングスタイルです。 削除済み 2007.09.17 13:26 #64 VBAG: デプフィー あなたは物事を混乱させた...:) 浮動小数点数の比較は、差のモジュラスを小さな閾値と比較することによって行われます。 例えば、（fabs(d1-d2) < 1e-10）を返す。 何をお茶を濁すんだ・・・。NormalizeDouble(...)関数は、見栄えの良いレポートのためだけのものです。 例を挙げていただきありがとうございます。 でも、論点がずれている、もっとよく読めよ。質問の本質は、一般的なプログラミングスタイルと、MT4という特殊なケースでのプログラミングスタイルです。 この質問の意味を教えてほしい。それ以外のヒント - 私は！理解していない) 速度の話をするならば、最近のプロセッサは浮動小数点演算を実行する は整数のものとほぼ同じ速さです。STYLEに関しては、申し訳ないが、実利主義が優先される...。 ASHIPSがある時点で、どういうスタイルなのか...。ただ、機能さえすればいいんです ... そうでなければ、2つの数字を比較すること以外に問題はない :)))))))))))))))))))))))))))))))))))) Сергей Ковалев 2007.09.17 13:35 #65 VBAG: そんなことを言われるとは思ってもいませんでした。どんな場合でも、そんなことはしてはいけないのです 比較演算が繰り返し使用される場合（再帰計算など）、入力で8桁に切り上げれば、出力誤差は1に見合うものになります。 SmoothedAvaregeの計算については、1年前に自分のアプリケーションで計算して、そんな経験をしました。その上で、替え玉の桁数に影響を与えないような働き方を選択するようにしています。 あるいは、gravity001 さんが提案されたように、INTamに切り替える（これは、ご理解の通り、非常に手間がかかります）。 ちょっと待てよ。結論を急ぐ必要はないのです。 まず最初に。実数変数の実際の値そのものを無理に丸めることは提案しない。比較演算の結果を計算する際に、変数の比較値（コピー）を強制的に丸めることを提案します（デフォルトの場合）。もちろん、実際の変数の値にも触れてはいけない。この場合、比較演算に使用した変数の元の値が保持されるため、他の演算値には影響がなく、循環演算の誤差が蓄積されることはない。 2番目。私は、より厳しい結果を伴うエラーをなくすためには、このような方法があると言いました。しかし、より高度な計算を提供するためには、パラメータを指定してNormalizeDouble() 関数を使用する可能性を残しておく必要があります。 ですから、私の提案は、言語の能力を制限するものではなく、それを拡張するものなのです。 しかし、比較演算では原則として価格値（桁＝4）を使用することを考慮すると、ほとんどの場合、このエラーは発生しない。したがって、提案する技術を使用することで、予測できない結果につながるミスを減らすことができます。 Сергей Ковалев 2007.09.17 13:47 #66 lna01: これがない場合は、このような変数を入力し、最初のスタート時に一度だけ計算すればよい。 無理でしょう。 というか、プログラムの文字列は書けても、この変数の値がEAの寿命まで厳密に変わらないという保証は（開発者を含めて）誰もしてくれない。 プログラムコードの正確さではなく、計算の技術的特徴や変数の値を保存する技術的ルールが問題なのである。そうでなければ、この問題は存在しないも同然です。 現状では、初期値である123.00000000000の変数が、計算で使われた瞬間に122.9999999999と表示されることがあるのだそうです。これは、その変数の値が作成以来一度も変化しておらず、プログラムが他の計算に参加するために呼び出しただけであるにもかかわらず、である。 実はこれが、今回の騒動の理由です。そのため、NormalizeDouble()はできるだけ実際の計算の近くで、できればif, for, while文の条件で直接使う必要性が生まれました。 削除済み 2007.09.17 14:00 #67 SK. писал (а): lna01 です。 また、それが使えない間は、自分でそのような変数を入力し、最初のスタート時に一度だけ計算することも可能です。 無理でしょう。 というか、プログラムの文字列は書けても、この変数の値がEAの寿命まで厳密に変わらないという保証は（開発者を含めて）誰もしてくれない。 プログラムコードの正確さではなく、計算の技術的特徴や変数の値の保存の技術的ルールが問題なのである。そうでなければ、この問題は存在しないも同然です。 現状では、初期値である123.00000000000の変数が、計算で使われた瞬間に122.9999999999と表示されることがあるのだそうです。これは、その変数の値が作成以来一度も変化しておらず、プログラムが他の計算に参加するために呼び出しただけであるにもかかわらず、である。 実はこれが、今回の騒動の理由です。そのため、NormalizeDouble()を実際の計算のできるだけ近くで、できればif, for, while文の条件のすぐ近くで使う必要がありました。 ゴリー、この騒ぎの意味が分かってきたような気がする...。 すべてにおいて、何も作らなくていいということですね。全ては状況次第です。目標は何ですか？仮数0.1が異なる2つの数字があり、それがCRITICALなら1つ、重要でなければ別物です。何を比較対象としているかにもよりますが。しかし、飾り気のない本物のコンパイラが与えてくれる柔軟性は、本物であり、必要なものであると思います。 :) Candid 2007.09.17 14:08 #68 SK. писал (а): ここで問題になるのは、プログラムコードの正確さではなく、計算の技術的特徴や変数値の格納の技術的ルールである。そうでなければ、この疑問は生じなかったでしょう。 計算についてはそうなのですが、何事も収納があったほうがいいに違いないと思えたのです。また、桁数＝4とした場合、15桁目の差は関係ないはずです。 Сергей Ковалев 2007.09.17 14:09 #69 Depfy: ゴリー、この騒ぎの意味が分かってきたような気がする...。 一般的には、anythingを作ることはないと思います。なぜなら、すべては具体的な状況によって決まるからです。目標は何ですか？仮数0.1が異なる2つの数字があり、それがCRITICALなら1つ、重要でなければ別物です。何を比較対象としているかにもよりますが。しかし、飾り気のない本物のコンパイラが与えてくれる柔軟性は、本物であり、必要なものだと思います。 :) 作り込み」については答えられない。どうやら、何を考えるか次第のようです:) 例えば、Point/2 のような発明で、本当にある程度の精度で計算できる場合もありますが、開発者の推奨、つまり、比較演算を行う場合は、一旦（新しいドキュメントまで）NormalizeDouble() 関数を使うことをルールとした方がよいでしょう。 Сергей Ковалев 2007.09.17 14:10 #70 lna01: SK.は(a)を書いた。 ここで問題になるのは、プログラムコードの正確さではなく、計算の技術的特徴や変数値の格納の技術的ルールである。そうでなければ、この疑問は生まれなかったでしょう。 計算上はそうなのですが、保存用としてはもっといいはずだと思ったのです。また、桁数＝4であれば、15桁目の差は問題にならないはずです。 NormalizeDouble()を使っても問題ないでしょう。使わなければ運次第ですしね。 1234567891011 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
この会話はいつまでも続くようだ。新しいユーザーが適切な経験と知識を得るまでに、通常、何度か正常化にぶつかることがあります。
MT5では、比較演算を行う際の実数の精度を強制的に小数点以下8桁に制限する（つまり、強制的にdigit=8でNormalizeDouble()を実行する）ことに意味があるのかもしれません。
比較演算が繰り返し使用される場合（再帰計算など）、入力で8桁に丸めれば、出力誤差を1に見合うものにできる。
SmoothedAvaregeの計算については、1年前に自分のアプリケーションで計算して、そんな経験をしました。その上で、替え玉の桁数に影響を与えないような働き方を選択するようにしています。
あるいは、gravity001 さんが提案されたように、INTamに切り替える（これは、ご理解の通り、非常に手間がかかります）。
MT5では、比較演算を行う際の実数の精度を、例えば小数点以下8桁に強制的に制限する（つまり、強制的にdigit=8でNormalizeDouble()を実行する）ことに意味があるのかもしれません。
しかし、ユーザー定義の操作だけでなく、端末に隠されている操作でも遅くなる。単純にComparePrice関数を言語に導入することが望ましいと思われます。ちなみに、私もIrtronさんと同じく、Point/2は自然な尺度だと考えています（Point *0.5の方がいいかもしれません）。毎回割り算・掛け算をしなくて済むように、この半分をあらかじめ変数にしておくことができます。それが存在しないまでは、そのような変数を自分で入力し、最初の起動時に一度だけ計算することができます。しかし、開発者は、あらかじめ定義された精度で二重比較の機能を作ることができる、つまり、同じだが、Point/2の代わりに桁を使うことができる。
せっかく作ったのに...。:)
浮動小数点数の比較は、差のモジュラスを小さな閾値と比較することによって行われます。
例えば、（fabs(d1-d2) < 1e-10）を返す。
何をお茶を濁すんだ・・・。NormalizeDouble(...)関数は、見栄えの良いレポートのためだけのものです。
でも、論点がずれている、もっとよく読めよ。質問の本質は、一般的なプログラミングスタイルと、MT4という特殊なケースでのプログラミングスタイルです。
あなたは物事を混乱させた...:)
浮動小数点数の比較は、差のモジュラスを小さな閾値と比較することによって行われます。
例えば、（fabs(d1-d2) < 1e-10）を返す。
何をお茶を濁すんだ・・・。NormalizeDouble(...)関数は、見栄えの良いレポートのためだけのものです。
でも、論点がずれている、もっとよく読めよ。質問の本質は、一般的なプログラミングスタイルと、MT4という特殊なケースでのプログラミングスタイルです。
この質問の意味を教えてほしい。それ以外のヒント - 私は！理解していない)
速度の話をするならば、最近のプロセッサは浮動小数点演算を実行する
は整数のものとほぼ同じ速さです。STYLEに関しては、申し訳ないが、実利主義が優先される...。
ASHIPSがある時点で、どういうスタイルなのか...。ただ、機能さえすればいいんです ...
そうでなければ、2つの数字を比較すること以外に問題はない :))))))))))))))))))))))))))))))))))))
そんなことを言われるとは思ってもいませんでした。どんな場合でも、そんなことはしてはいけないのです
比較演算が繰り返し使用される場合（再帰計算など）、入力で8桁に切り上げれば、出力誤差は1に見合うものになります。
SmoothedAvaregeの計算については、1年前に自分のアプリケーションで計算して、そんな経験をしました。その上で、替え玉の桁数に影響を与えないような働き方を選択するようにしています。
あるいは、gravity001 さんが提案されたように、INTamに切り替える（これは、ご理解の通り、非常に手間がかかります）。
ちょっと待てよ。結論を急ぐ必要はないのです。
まず最初に。実数変数の実際の値そのものを無理に丸めることは提案しない。比較演算の結果を計算する際に、変数の比較値（コピー）を強制的に丸めることを提案します（デフォルトの場合）。もちろん、実際の変数の値にも触れてはいけない。この場合、比較演算に使用した変数の元の値が保持されるため、他の演算値には影響がなく、循環演算の誤差が蓄積されることはない。
2番目。私は、より厳しい結果を伴うエラーをなくすためには、このような方法があると言いました。しかし、より高度な計算を提供するためには、パラメータを指定してNormalizeDouble() 関数を使用する可能性を残しておく必要があります。
ですから、私の提案は、言語の能力を制限するものではなく、それを拡張するものなのです。
しかし、比較演算では原則として価格値（桁＝4）を使用することを考慮すると、ほとんどの場合、このエラーは発生しない。したがって、提案する技術を使用することで、予測できない結果につながるミスを減らすことができます。
これがない場合は、このような変数を入力し、最初のスタート時に一度だけ計算すればよい。
無理でしょう。
というか、プログラムの文字列は書けても、この変数の値がEAの寿命まで厳密に変わらないという保証は（開発者を含めて）誰もしてくれない。 プログラムコードの正確さではなく、計算の技術的特徴や変数の値を保存する技術的ルールが問題なのである。そうでなければ、この問題は存在しないも同然です。
現状では、初期値である123.00000000000の変数が、計算で使われた瞬間に122.9999999999と表示されることがあるのだそうです。これは、その変数の値が作成以来一度も変化しておらず、プログラムが他の計算に参加するために呼び出しただけであるにもかかわらず、である。
実はこれが、今回の騒動の理由です。そのため、NormalizeDouble()はできるだけ実際の計算の近くで、できればif, for, while文の条件で直接使う必要性が生まれました。
また、それが使えない間は、自分でそのような変数を入力し、最初のスタート時に一度だけ計算することも可能です。
無理でしょう。
というか、プログラムの文字列は書けても、この変数の値がEAの寿命まで厳密に変わらないという保証は（開発者を含めて）誰もしてくれない。 プログラムコードの正確さではなく、計算の技術的特徴や変数の値の保存の技術的ルールが問題なのである。そうでなければ、この問題は存在しないも同然です。
現状では、初期値である123.00000000000の変数が、計算で使われた瞬間に122.9999999999と表示されることがあるのだそうです。これは、その変数の値が作成以来一度も変化しておらず、プログラムが他の計算に参加するために呼び出しただけであるにもかかわらず、である。
実はこれが、今回の騒動の理由です。そのため、NormalizeDouble()を実際の計算のできるだけ近くで、できればif, for, while文の条件のすぐ近くで使う必要がありました。
ゴリー、この騒ぎの意味が分かってきたような気がする...。
すべてにおいて、何も作らなくていいということですね。全ては状況次第です。目標は何ですか？仮数0.1が異なる2つの数字があり、それがCRITICALなら1つ、重要でなければ別物です。何を比較対象としているかにもよりますが。しかし、飾り気のない本物のコンパイラが与えてくれる柔軟性は、本物であり、必要なものであると思います。
:)
ゴリー、この騒ぎの意味が分かってきたような気がする...。
一般的には、anythingを作ることはないと思います。なぜなら、すべては具体的な状況によって決まるからです。目標は何ですか？仮数0.1が異なる2つの数字があり、それがCRITICALなら1つ、重要でなければ別物です。何を比較対象としているかにもよりますが。しかし、飾り気のない本物のコンパイラが与えてくれる柔軟性は、本物であり、必要なものだと思います。
:)
作り込み」については答えられない。どうやら、何を考えるか次第のようです:)
例えば、Point/2 のような発明で、本当にある程度の精度で計算できる場合もありますが、開発者の推奨、つまり、比較演算を行う場合は、一旦（新しいドキュメントまで）NormalizeDouble() 関数を使うことをルールとした方がよいでしょう。
NormalizeDouble()を使っても問題ないでしょう。使わなければ運次第ですしね。