移動平均（およびその他の指標）と誤差の比較 - ページ 4 1234567 新しいコメント Dina Paches 2015.07.30 21:30 #31 gammaray: もちろんアドバイスはありがたいのですが、Helpは自分で読むことができます。また、繰り返しになりますが、計算数学は特定のプログラミング言語に縛られるものではありません。計算ミスだけで、合格してしまうんです。ヘルプを読むだけでなく、理解できるのであれば、意図的なデマゴギーに従事していることになり、頑なにノーマライゼーションとその応用の可能性を軽蔑した精神で語り続けていることになります。その適用の危険性についての意図的なデマゴギーも含めて。ガマレイそして、私は利口なのではなく、反例をあげているのです（あなたの愛する正規化についても）。 デマゴギーがあった。正規化に関する反例はなかった。誰かが誤用する可能性があることは別として。そのため、イプシロンが誤って適用されることがあります。はい、そしてデマゴギーはすでに言及されています。P./S.：この記事は正規化についてのものなので、移動平均線については触れて いません。 そして、MAを使ったEAについては、そういう難しいことは私よりもアルテムさんの方がうまく手助けできると思います。 gammaray 2015.07.30 21:52 #32 Artyom Trishkin: すべてのティックでクロスオーバーを探します。何が問題なのか？ 私のTORが違うから）そしてまた、ダニの問題点はすでに書きましたね。チャート上にクロスオーバーが表示されない場合、ロボットが取引に入った理由を顧客に説明することはできません。 gammaray 2015.07.30 21:53 #33 Andrey Dik:2つの実数を比較するときに、正規化する必要はない。 数字が本当に等しければ、メモリに等しく格納 される。実は、この性質があるからこそ、計算機が存在できるのである。 したがって、if(a<b) または if(a==b) の形の比較はどんな場合でも正しく、正規化の必要はない。もし、研究者の探究心がこのルールに矛盾を見出したとしたら、それは彼の機械が故障しているか、彼の心が故障しているかのどちらかであろう。2つのうちの1つです。ヘルプやドキュメントはもちろん時々読むべきですが（それらも私たちのようなヒューマノイドによって書かれたものです）、自分なりの良識的な理由付けが必要なのです。 まったくもって同感です!これはまさに私が作り直したもので、同じ理由で非厳格な不等式を1つ導入しています。 gammaray 2015.07.30 21:58 #34 Dina Paches:ヘルプを読むだけでなく、理解できるのであれば、意図的なデマゴギーに従事していることになり、頑なにノーマライゼーションとその応用の可能性を軽蔑した精神で語り続けていることになります。その適用の危険性についての意図的なデマゴギーも含めて。デマゴギーがあった。正規化に関する反例はなかった。誰かが正しく使っていない可能性があることは含めない。そのため、イプシロンが正しく適用されていない可能性があります。そして、デマゴギーはすでに述べたとおりです。少なくとも、ここで指摘されているような差の正規化という点では）反例がある。何度も言いますが、正規化は微妙なところを掘り下げるのが嫌な人にとって一番簡単な方法なんです。彼はドキュメントを読み、それをすべて神妙に信じている。繰り返すが、計算数学の中のプログラミング言語は関係ない。ヘルプにこう書いてあっても、それが真実とは限らない（そうでなければ、あなたの大嫌いな計算数学もイプシロン問題も存在しない）。フェンスにもいろいろ書かれていますが、それが最後の手段で真実であるとは限りません。ハルプのオプションに満足するのは、当然のことです。でも、それは個人の自由です。そして、私がここで明らかにしようとした問題をすべて解決してくれるわけでもありません。また、単に理解したくないものをデマゴギーとみなすことは（これもあなたの権利です）、それ自体がデマゴギーであることを意味しません。私は人生の意味について修辞的な質問をしているわけではなく（その答えは単なるデマゴギー）、まだ遭遇していない何かを理解しようとしているだけなのです。ここでも、いつ計算しても同じ値だとしよう。そこでは、同じ計算数学から何かを得ることができるかもしれません。しかし、価値観も異なるとなると、メガ・グルでも普遍的なアルゴリズムは思いつかないでしょう。それに、ロボットがティックで動作しない場合、バー内で複数の交差を得ることは基本的に不可能であるという私の理解を確認しておきたいのです。それはもう純粋にmqlの複雑さに起因していると言えるでしょう。P.S. 無根拠に誰かに反論しているわけではなく、自分が常に正しい天才であるとは思っていないのです。ただ、実際に読まないで気の利いたことを書こうとする人が嫌いなだけです。これはあなた個人には関係ないことです。ご協力ありがとうございました。しかし、それでも、IMHOは、あなたがドキュメントで1つの視点だけを主張し（あなたが心から信じていて、代替の見解や例を受け入れない）、イプシロンがあなたの好みに合っていないのに、忍耐について何かを書くのは間違っていると思うのです。その前のあとがきで書いたことも、アルチョムに理解してもらえるといいんですけどね。皆さん、お返事ありがとうございました。どこかで辛気臭くなったかもしれませんが、お許しください。追伸：ある小数点以下への正規化は、実は同じ符号の順番でεの導入に似ている。P.P.P.S.このような熱い議論がある場合、適切な答え（特に私が気になる2、3の項目）が、実際には得られなかったので、この トピックであなたの経験を共有していただければ非常にありがたいです。いろいろな掲示板を見て回りましたが、「2ポイントは無理」という結論になりそうでした。それは非常に不快であるため、mqlの開発者は、このことについて考え、より柔軟性を提供することができます（他のプログラミング言語で動的にプログラムのインターフェイスを変更する機能があり、ここではそれがないことが判明（（（）））です。 Dina Paches 2015.07.31 04:50 #35 gammaray:少なくとも、ここで指摘されているような差異の正常化という点では）反例がある。何度も言いますが、正規化は複雑なことを掘り下げたくない人にとって、最も簡単な方法です。彼はドキュメントを読み、それをすべて神妙に信じている。繰り返すが、計算数学の中のプログラミング言語は関係ない。ヘルプにこう書いてあっても、それが真実とは限らない（そうでなければ、あなたの大嫌いな計算数学もイプシロン問題も存在しない）。フェンスにもいろいろ書かれていますが、それが最後の手段で真実であるとは限りません。ハルプのオプションに満足するのは、当然のことです。でも、それは個人の自由です。そして、私がここで明らかにしようとした問題をすべて解決してくれるわけでもありません。また、単に理解したくないものをデマゴギーとみなすことは（これもあなたの権利です）、それ自体がデマゴギーであることを意味しません。私は人生の意味について修辞的な質問をしているわけではなく（その答えは単なるデマゴギー）、まだ遭遇していない何かに対処しようとしているだけなのです。ここでも、いつ計算しても同じ値だとしよう。そこでは、同じ計算数学から何かを得ることができるかもしれません。しかし、価値観も異なるとなると、メガ・グルでも普遍的なアルゴリズムは思いつかないでしょう。それに、ロボットがティックで動作しない場合、バー内で複数の交差を得ることは基本的に不可能であるという私の理解を確認しておきたいのです。それはもう純粋にmqlの複雑さに起因していると言えるでしょう。P.S. 無根拠に誰かに反論しているわけではなく、自分が常に正しい天才であるとは思っていないのです。ただ、読んでもいないのに気の利いたことを書こうとするのが嫌なんです。これはあなた個人には関係ないことです。ご協力ありがとうございました。しかし、それでも、IMHOは、あなたがドキュメントで1つの視点だけを主張し（あなたが心から信じていて、代替の見解や例を受け入れない）、イプシロンがあなたの好みに合っていないのに、忍耐について何かを書くのは間違っていると思うのです。その前のあとがきで書いたことも、アルチョムに理解してもらえるといいんですけどね。皆さん、お返事ありがとうございました。どこかで辛気臭くなったかもしれませんが、お許しください。追伸：ある小数点以下への正規化は、実は同じ符号の順番でεの導入に似ている。P.P.P.S.このような熱い議論がある場合、適切な答え（特に私が気になる2、3の項目）が、実際には得られなかったので、この トピックであなたの経験を共有していただければ非常にありがたいです。いろいろな掲示板を見て回りましたが、「2ポイントは無理」という結論になりそうでした。それは非常に不快であるため、mqlの開発者は、このことについて考えている可能性があり、より柔軟性を提供する（他のプログラミング言語で動的にプログラムインターフェイスを変更する機能を持っており、ここではそれがないことが判明（（（）））です。NormalizeDouble 関数を使ったデータ変換で2倍 値を比較するのは、Documentationで規定されている2つの方法のうちの1つで、特定の条件をコードに記述するときに、プログラムの条件を意図したとおりに動作させるための方法です。 それが、先ほどの話です。し たがって、単にエラーをなくすだけではありません。また、あらゆる条件を満たすために、さまざまな工夫を凝らしてデータを変換しているのです。あなたが学び始めたばかりのプログラミング言語での個人的な実践経験をもとに、あなたにお伝えし、お伝えしています。そのため、このスレッドで何度も提案しているように、このような実用的な 使い方をすることです。ところで、この関数による正規化が、実型データの変換という点で、どのようなタスクに対しても最も簡単な方法であることに異論はないだろうと、一部同意の上で申し上げておくことにする しかし、実際の型のデータを変換する際に、Documentationで推奨されている2つの方法のどちらを使うかは、皆さんの判断にお任せします。 そして、そのどちらを選ぶかは、必要な機微を理解しようとする人であるか否かを決めるものではありません。 イプシロンが嫌いというのは、私の口から出た言葉ではありません。どの方法も適用しないことは、必ずしも好き嫌いを意味しない。また、2つの方法のうち2つ目だけを適用することにこだわったわけでもありません。double型の数字を扱う特殊性の実用化という点で、私の文字通りの言葉、です。追伸： たまたま、ドキュメントの最初の方法が、自分にとって使いにくいものであることがわかりました。その結果、私は最初の方法の経験があまりないのです。しかし、2番目の方法（条件演算子式で2つの実数の正規化された差を0と比較する 方法）を適用しても、一義的には問題が生じなかった。 しかし、正規化されていない数値の比較を行った場合（ここでは、最初の 方法も使用せずにという 意味です）、そう、double 型の数値の比較を基にした条件の動作に誤りがあることがわかったのです。それに、私はそのような説明も しました。追記：そうはいっても、念のため、もう一度はっきりさせて おくと、 ここに挙げた2つの方法のうち、 最初の方法で実数を比較する場合、数字の差をある小さな値で比較 すれば、比較のレベルを調整する必要がある場合 、私は 正規化を使うより悪いとは言えない （含、私にとっては、第2の方法がより便利だったので、実際の応用にもっと細かく考慮しなかったのだが)。つまり、ダブルデータを変換 する際の正規化という点では、最初の方法は必要なかっただけなのです。特に、様々な 問題を解決する際に（比較に限らず）NormalizeDouble 関数を使用することが私にとって便利なため。このサイトには、膨大な知識の蓄積があります。 MQL4を使って、さまざまな複雑な問題を解決してきた人たちがいます。MQL4がMQL5に近づいたことで、初代の可能性がさらに高まりました。ここのサイトに蓄積された知識ベースを無視せず、もっとこのプログラミング言語に精通するべきだと思います。実際に使用する経験を積む。そうして初めて、このプログラミング言語でのあらゆるアプリケーションとその能力に関して、自信を持って何かを語ることができるのです。 Artyom Trishkin 2015.07.31 08:12 #36 gammaray: 私は別のToRを持っています）そしてまた、ダニの問題についてはすでに書きました。チャート上でクロスオーバーが確認できない場合、ロボットが取引を開始した理由を顧客に説明することはできません。すべてのティックでゼロと最初のバーのMA値を取る - その時だけ、あなたはゼロのバーでMAのクロスオーバーを見つけることができます。そして、MAの値は、最初のバーが閉じられたときに存在したものであり、バーが形成されたときのものではありません。単にМАšekの価値観を読むのが遅いので、交差しているのが見えないだけなのです。ノーマライゼーションは関係ない。ところで、MAが価格値を表示しているのであれば、どの値まで正規化が必要なのかを推測するのではなく、その値を_Digitsに正規化すべきなのですが・・・。 Vladimir Karputov 2015.07.31 08:41 #37 フォーラムメンバーの皆様へ。この掲示板でいさかいを起こさないようにお願いします。スレッドのトピックにのみ Victor Nikolaev 2015.07.31 12:50 #38 Karputov Vladimir: フォーラム参加者の皆様へ。フォーラムでいさかいを起こさないようにお願いします。スレッドの主題にのみこのトピックは終了してもいいと思います。声明の著者（トピックではない）は、コンセンサスに至らなかった。排外主義的な言動が散見されましたが、これは歓迎されません。しかし、どちらも証明することはできていない。だからスレッドを閉じるのです。それ以上の議論は処罰の対象となる場合があります（最大で1日1回まで）。 普通の証拠が与えられるのであれば、それは歓迎すべきことですが。 ジャッジは私とヴォロディヤ。これは論外です。 Andrey Dik 2015.07.31 14:18 #39 なるほど。司会者の告発を聞く準備はできている（他の告発者については***はどうでもいい）。モデレーターがメッセージを段階的に分解してくれることを期待します。 Dina Paches 2015.08.01 05:39 #40 ここではそのすべてを見たわけではないので、このトピック内でどのような議論がなされたのかはわからないのですが。しかし、この投稿（およびこのスレッドの以前の投稿）における Artemの立場に近い私の立場を 証明することだと思うので、実数型を扱うときに正規化を一方的に適用すべきかどうかに関連して、以下の例の一つを挙げておきます。スクリーンショットとテストコードのバリアント付き。Artyomは上の投稿でこう書いています。И, кстати, раз МА показывают значения цены, то и нормализовать значения нужно до _Digits, а не гадать до какого же значения нормализация нужна...そして、これが最も一般的な 問題の方向性におけるシンプルで効果的な方法であると私も信じているので（他の多くの人もそうだと思いますが）、私自身はこの小さな追加だけを行います。を小数点以下何桁で表示するか、あるいは小数点以下何桁で計算するか（同じ比較）、小数点以下何桁で正規化（小数点以下何桁に丸めるか）することを想定しています。/*個々のタスクには「例外」が存在する場合があり、例えば、小数点以下が小さい値と大きい値を比較することで、望ましい結果を得るために変化させることができます。しかし、もしこれが目の前のタスクに必要であれば、上記の方法と同様に、必要に応じて、得られた値をプリントアウトし、チャート上に視覚的に表示されたレンダリングと比較することも十分にお勧めできると私は考えています。もし、double型の値をテキストとして出力する必要がある場合（Print、Comment、OBJ_LABELなど）、数値をテキストに変換したいので、DoubleToStringを 使用する必要があります。さて、入門的な説明からわかりやすさへ。スクリーンショットでは標準配信からターミナルまでの2本のMAのラインがチャートに表示されます。同じ設定で、チャートの小数点以下の桁数が1桁少ないMAを2つ（iMA 機能が適用されたインディケータで描画、このインディケータはKodobaseで 利用可能です。）この指標の表：MA値、MA値間の差分、MAそのもの（MAそのもの間の差分 - 表の最終行の下）。"データウィンドウ "に標準セットのMA値と上記の指標を表示した端末。取引端末の「Experts」ジャーナルにテストスクリプトのデータが表示されているのがわかると思います。テストスクリプトのデータは、iMA関数で得られたMA値（ドキュメントにある実数型を扱うための関数による変換あり・なし）です。データウィンドウとチャート上で、小数点以下が表示されている線が、チャートの現在のバーを除いた3本目のバーで値が等しくなっていることがわかります。また、チャートの小数点以下に描かれた標準セットから端末までのMA値が等しくなく、視覚的に少し前のチャートで等しくなっていることがわかります。 すなわち、スクリーンショットを拡大したり、添付のテストスクリプトやご自身のコードを使って実験を行うと、チャートと同じ小数点以下の桁数のMA線が少し早くクロスしていることがわかります。そして、それは理解できる。例えて言えば、3桁のグラフに2桁の引用符で描いた線より、小数の線は1つ少なくなる。端末の3桁や5桁の相場が広くない時代の「古い」ポイントで見ることができ、同時に取引用の拡張10進数相場の利点（スプレッドの狭さを含む）を持つことができるのです。つまり、小数点以下の数値に基づく線は、「ノイズ」が少ない。しかし、四捨五入が適用されない場合（この場合は正規化機能を使用）、特定の小数点以下の桁数に明確に限定された数値は、より問題となる。 あるいは、数字だけなら。123.4561と123.4556はイコールではありません。そして、その差はゼロではありません。しかし、切り上げれば、1番目と2番目の数字は、どちらも同じで123.456になる。従って、両者の差は0となる。結果の値を丸めるかどうかは、実行する作業によって、小数点以下が決まっている。Experts」のスクリーンショットでは、iMAを使って出力されたMA値を、ドキュメントに記載されている変換を行ったものと、結果の変換を行わなかったものを見ることができます。テストスクリプトのMA設定は、チャート上のインジケーターの設定と同じです。 2つ目のスクリーンショットでは、2つのMA値の間の差分を、変換あり・なしで見ることができます。以下、前述したように、小さなテストコードです。最適化されていませんが、一部のパラメータを変更するなどして、MA値で様々な実験が可能です。 その中のバーの本数はこの行で設定します。#define ARRAY_SIZE 9追伸： 添付のテストスクリプトを差し替えました。私の投稿で変種を間違えてしまいました。間違っている。すみません。以前添付したスクリーンショットは必須ではありませんので、そのままにしています。 ファイル: test_1.mq4 5 kb 1234567 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
もちろんアドバイスはありがたいのですが、Helpは自分で読むことができます。また、繰り返しになりますが、計算数学は特定のプログラミング言語に縛られるものではありません。計算ミスだけで、合格してしまうんです。
ヘルプを読むだけでなく、理解できるのであれば、意図的なデマゴギーに従事していることになり、頑なにノーマライゼーションとその応用の可能性を軽蔑した精神で語り続けていることになります。その適用の危険性についての意図的なデマゴギーも含めて。
そして、私は利口なのではなく、反例をあげているのです（あなたの愛する正規化についても）。
デマゴギーがあった。正規化に関する反例はなかった。
誰かが誤用する可能性があることは別として。
そのため、イプシロンが誤って適用されることがあります。はい、そしてデマゴギーはすでに言及されています。
P./S.：この記事は正規化についてのものなので、移動平均線については触れて いません。
そして、MAを使ったEAについては、そういう難しいことは私よりもアルテムさんの方がうまく手助けできると思います。
すべてのティックでクロスオーバーを探します。何が問題なのか？
2つの実数を比較するときに、正規化する必要はない。
数字が本当に等しければ、メモリに等しく格納 される。実は、この性質があるからこそ、計算機が存在できるのである。
したがって、if(a<b) または if(a==b) の形の比較はどんな場合でも正しく、正規化の必要はない。
もし、研究者の探究心がこのルールに矛盾を見出したとしたら、それは彼の機械が故障しているか、彼の心が故障しているかのどちらかであろう。2つのうちの1つです。
ヘルプやドキュメントはもちろん時々読むべきですが（それらも私たちのようなヒューマノイドによって書かれたものです）、自分なりの良識的な理由付けが必要なのです。
ヘルプを読むだけでなく、理解できるのであれば、意図的なデマゴギーに従事していることになり、頑なにノーマライゼーションとその応用の可能性を軽蔑した精神で語り続けていることになります。その適用の危険性についての意図的なデマゴギーも含めて。
デマゴギーがあった。正規化に関する反例はなかった。
誰かが正しく使っていない可能性があることは含めない。
そのため、イプシロンが正しく適用されていない可能性があります。そして、デマゴギーはすでに述べたとおりです。
少なくとも、ここで指摘されているような差の正規化という点では）反例がある。何度も言いますが、正規化は微妙なところを掘り下げるのが嫌な人にとって一番簡単な方法なんです。彼はドキュメントを読み、それをすべて神妙に信じている。繰り返すが、計算数学の中のプログラミング言語は関係ない。ヘルプにこう書いてあっても、それが真実とは限らない（そうでなければ、あなたの大嫌いな計算数学もイプシロン問題も存在しない）。フェンスにもいろいろ書かれていますが、それが最後の手段で真実であるとは限りません。ハルプのオプションに満足するのは、当然のことです。でも、それは個人の自由です。そして、私がここで明らかにしようとした問題をすべて解決してくれるわけでもありません。また、単に理解したくないものをデマゴギーとみなすことは（これもあなたの権利です）、それ自体がデマゴギーであることを意味しません。私は人生の意味について修辞的な質問をしているわけではなく（その答えは単なるデマゴギー）、まだ遭遇していない何かを理解しようとしているだけなのです。ここでも、いつ計算しても同じ値だとしよう。そこでは、同じ計算数学から何かを得ることができるかもしれません。しかし、価値観も異なるとなると、メガ・グルでも普遍的なアルゴリズムは思いつかないでしょう。
それに、ロボットがティックで動作しない場合、バー内で複数の交差を得ることは基本的に不可能であるという私の理解を確認しておきたいのです。それはもう純粋にmqlの複雑さに起因していると言えるでしょう。
P.S. 無根拠に誰かに反論しているわけではなく、自分が常に正しい天才であるとは思っていないのです。ただ、実際に読まないで気の利いたことを書こうとする人が嫌いなだけです。これはあなた個人には関係ないことです。ご協力ありがとうございました。しかし、それでも、IMHOは、あなたがドキュメントで1つの視点だけを主張し（あなたが心から信じていて、代替の見解や例を受け入れない）、イプシロンがあなたの好みに合っていないのに、忍耐について何かを書くのは間違っていると思うのです。その前のあとがきで書いたことも、アルチョムに理解してもらえるといいんですけどね。皆さん、お返事ありがとうございました。どこかで辛気臭くなったかもしれませんが、お許しください。
追伸：ある小数点以下への正規化は、実は同じ符号の順番でεの導入に似ている。
P.P.P.S.このような熱い議論がある場合、適切な答え（特に私が気になる2、3の項目）が、実際には得られなかったので、この トピックであなたの経験を共有していただければ非常にありがたいです。いろいろな掲示板を見て回りましたが、「2ポイントは無理」という結論になりそうでした。それは非常に不快であるため、mqlの開発者は、このことについて考え、より柔軟性を提供することができます（他のプログラミング言語で動的にプログラムのインターフェイスを変更する機能があり、ここではそれがないことが判明（（（）））です。
少なくとも、ここで指摘されているような差異の正常化という点では）反例がある。何度も言いますが、正規化は複雑なことを掘り下げたくない人にとって、最も簡単な方法です。彼はドキュメントを読み、それをすべて神妙に信じている。繰り返すが、計算数学の中のプログラミング言語は関係ない。ヘルプにこう書いてあっても、それが真実とは限らない（そうでなければ、あなたの大嫌いな計算数学もイプシロン問題も存在しない）。フェンスにもいろいろ書かれていますが、それが最後の手段で真実であるとは限りません。ハルプのオプションに満足するのは、当然のことです。でも、それは個人の自由です。そして、私がここで明らかにしようとした問題をすべて解決してくれるわけでもありません。また、単に理解したくないものをデマゴギーとみなすことは（これもあなたの権利です）、それ自体がデマゴギーであることを意味しません。私は人生の意味について修辞的な質問をしているわけではなく（その答えは単なるデマゴギー）、まだ遭遇していない何かに対処しようとしているだけなのです。ここでも、いつ計算しても同じ値だとしよう。そこでは、同じ計算数学から何かを得ることができるかもしれません。しかし、価値観も異なるとなると、メガ・グルでも普遍的なアルゴリズムは思いつかないでしょう。
それに、ロボットがティックで動作しない場合、バー内で複数の交差を得ることは基本的に不可能であるという私の理解を確認しておきたいのです。それはもう純粋にmqlの複雑さに起因していると言えるでしょう。
P.S. 無根拠に誰かに反論しているわけではなく、自分が常に正しい天才であるとは思っていないのです。ただ、読んでもいないのに気の利いたことを書こうとするのが嫌なんです。これはあなた個人には関係ないことです。ご協力ありがとうございました。しかし、それでも、IMHOは、あなたがドキュメントで1つの視点だけを主張し（あなたが心から信じていて、代替の見解や例を受け入れない）、イプシロンがあなたの好みに合っていないのに、忍耐について何かを書くのは間違っていると思うのです。その前のあとがきで書いたことも、アルチョムに理解してもらえるといいんですけどね。皆さん、お返事ありがとうございました。どこかで辛気臭くなったかもしれませんが、お許しください。
追伸：ある小数点以下への正規化は、実は同じ符号の順番でεの導入に似ている。
P.P.P.S.このような熱い議論がある場合、適切な答え（特に私が気になる2、3の項目）が、実際には得られなかったので、この トピックであなたの経験を共有していただければ非常にありがたいです。いろいろな掲示板を見て回りましたが、「2ポイントは無理」という結論になりそうでした。それは非常に不快であるため、mqlの開発者は、このことについて考えている可能性があり、より柔軟性を提供する（他のプログラミング言語で動的にプログラムインターフェイスを変更する機能を持っており、ここではそれがないことが判明（（（）））です。
NormalizeDouble 関数を使ったデータ変換で2倍 値を比較するのは、Documentationで規定されている2つの方法のうちの1つで、特定の条件をコードに記述するときに、プログラムの条件を意図したとおりに動作させるための方法です。 それが、先ほどの話です。し たがって、単にエラーをなくすだけではありません。また、あらゆる条件を満たすために、さまざまな工夫を凝らしてデータを変換しているのです。
あなたが学び始めたばかりのプログラミング言語での個人的な実践経験をもとに、あなたにお伝えし、お伝えしています。そのため、このスレッドで何度も提案しているように、このような実用的な 使い方をすることです。
ところで、この関数による正規化が、実型データの変換という点で、どのようなタスクに対しても最も簡単な方法であることに異論はないだろうと、一部同意の上で申し上げておくことにする
しかし、実際の型のデータを変換する際に、Documentationで推奨されている2つの方法のどちらを使うかは、皆さんの判断にお任せします。
そして、そのどちらを選ぶかは、必要な機微を理解しようとする人であるか否かを決めるものではありません。
イプシロンが嫌いというのは、私の口から出た言葉ではありません。どの方法も適用しないことは、必ずしも好き嫌いを意味しない。また、2つの方法のうち2つ目だけを適用することにこだわったわけでもありません。
double型の数字を扱う特殊性の実用化という点で、私の文字通りの言葉、です。
追伸： たまたま、ドキュメントの最初の方法が、自分にとって使いにくいものであることがわかりました。その結果、私は最初の方法の経験があまりないのです。
しかし、2番目の方法（条件演算子式で2つの実数の正規化された差を0と比較する 方法）を適用しても、一義的には問題が生じなかった。
しかし、正規化されていない数値の比較を行った場合（ここでは、最初の 方法も使用せずにという 意味です）、そう、double 型の数値の比較を基にした条件の動作に誤りがあることがわかったのです。
それに、私はそのような説明も しました。
追記：そうはいっても、念のため、もう一度はっきりさせて おくと、 ここに挙げた2つの方法のうち、 最初の方法で実数を比較する場合、数字の差をある小さな値で比較 すれば、比較のレベルを調整する必要がある場合 、私は 正規化を使うより悪いとは言えない （含、私にとっては、第2の方法がより便利だったので、実際の応用にもっと細かく考慮しなかったのだが)。
つまり、ダブルデータを変換 する際の正規化という点では、最初の方法は必要なかっただけなのです。特に、様々な 問題を解決する際に（比較に限らず）NormalizeDouble 関数を使用することが私にとって便利なため。
このサイトには、膨大な知識の蓄積があります。
MQL4を使って、さまざまな複雑な問題を解決してきた人たちがいます。
MQL4がMQL5に近づいたことで、初代の可能性がさらに高まりました。
ここのサイトに蓄積された知識ベースを無視せず、もっとこのプログラミング言語に精通するべきだと思います。実際に使用する経験を積む。そうして初めて、このプログラミング言語でのあらゆるアプリケーションとその能力に関して、自信を持って何かを語ることができるのです。
私は別のToRを持っています）そしてまた、ダニの問題についてはすでに書きました。チャート上でクロスオーバーが確認できない場合、ロボットが取引を開始した理由を顧客に説明することはできません。
すべてのティックでゼロと最初のバーのMA値を取る - その時だけ、あなたはゼロのバーでMAのクロスオーバーを見つけることができます。そして、MAの値は、最初のバーが閉じられたときに存在したものであり、バーが形成されたときのものではありません。単にМАšekの価値観を読むのが遅いので、交差しているのが見えないだけなのです。ノーマライゼーションは関係ない。ところで、MAが価格値を表示しているのであれば、どの値まで正規化が必要なのかを推測するのではなく、その値を_Digitsに正規化すべきなのですが・・・。
フォーラム参加者の皆様へ。フォーラムでいさかいを起こさないようにお願いします。スレッドの主題にのみ
このトピックは終了してもいいと思います。声明の著者（トピックではない）は、コンセンサスに至らなかった。排外主義的な言動が散見されましたが、これは歓迎されません。
しかし、どちらも証明することはできていない。だからスレッドを閉じるのです。それ以上の議論は処罰の対象となる場合があります（最大で1日1回まで）。
普通の証拠が与えられるのであれば、それは歓迎すべきことですが。
ジャッジは私とヴォロディヤ。
これは論外です。
ここではそのすべてを見たわけではないので、このトピック内でどのような議論がなされたのかはわからないのですが。しかし、この投稿（およびこのスレッドの以前の投稿）における Artemの立場に近い私の立場を 証明することだと思うので、実数型を扱うときに正規化を一方的に適用すべきかどうかに関連して、以下の例の一つを挙げておきます。
スクリーンショットとテストコードのバリアント付き。
Artyomは上の投稿でこう書いています。
И, кстати, раз МА показывают значения цены, то и нормализовать значения нужно до _Digits, а не гадать до какого же значения нормализация нужна...
そして、これが最も一般的な 問題の方向性におけるシンプルで効果的な方法であると私も信じているので（他の多くの人もそうだと思いますが）、私自身はこの小さな追加だけを行います。
を小数点以下何桁で表示するか、あるいは小数点以下何桁で計算するか（同じ比較）、小数点以下何桁で正規化（小数点以下何桁に丸めるか）することを想定しています。
/*個々のタスクには「例外」が存在する場合があり、例えば、小数点以下が小さい値と大きい値を比較することで、望ましい結果を得るために変化させることができます。しかし、もしこれが目の前のタスクに必要であれば、上記の方法と同様に、必要に応じて、得られた値をプリントアウトし、チャート上に視覚的に表示されたレンダリングと比較することも十分にお勧めできると私は考えています。
もし、double型の値をテキストとして出力する必要がある場合（Print、Comment、OBJ_LABELなど）、数値をテキストに変換したいので、DoubleToStringを 使用する必要があります。
さて、入門的な説明からわかりやすさへ。
スクリーンショットでは
テストスクリプトのデータは、iMA関数で得られたMA値（ドキュメントにある実数型を扱うための関数による変換あり・なし）です。
データウィンドウとチャート上で、小数点以下が表示されている線が、チャートの現在のバーを除いた3本目のバーで値が等しくなっていることがわかります。また、チャートの小数点以下に描かれた標準セットから端末までのMA値が等しくなく、視覚的に少し前のチャートで等しくなっていることがわかります。
すなわち、スクリーンショットを拡大したり、添付のテストスクリプトやご自身のコードを使って実験を行うと、チャートと同じ小数点以下の桁数のMA線が少し早くクロスしていることがわかります。
そして、それは理解できる。例えて言えば、3桁のグラフに2桁の引用符で描いた線より、小数の線は1つ少なくなる。端末の3桁や5桁の相場が広くない時代の「古い」ポイントで見ることができ、同時に取引用の拡張10進数相場の利点（スプレッドの狭さを含む）を持つことができるのです。
つまり、小数点以下の数値に基づく線は、「ノイズ」が少ない。
しかし、四捨五入が適用されない場合（この場合は正規化機能を使用）、特定の小数点以下の桁数に明確に限定された数値は、より問題となる。
あるいは、数字だけなら。
123.4561と123.4556はイコールではありません。そして、その差はゼロではありません。
しかし、切り上げれば、1番目と2番目の数字は、どちらも同じで123.456になる。従って、両者の差は0となる。
結果の値を丸めるかどうかは、実行する作業によって、小数点以下が決まっている。
Experts」のスクリーンショットでは、iMAを使って出力されたMA値を、ドキュメントに記載されている変換を行ったものと、結果の変換を行わなかったものを見ることができます。テストスクリプトのMA設定は、チャート上のインジケーターの設定と同じです。
2つ目のスクリーンショットでは、2つのMA値の間の差分を、変換あり・なしで見ることができます。以下、前述したように、小さなテストコードです。最適化されていませんが、一部のパラメータを変更するなどして、MA値で様々な実験が可能です。
その中のバーの本数はこの行で設定します。
追伸： 添付のテストスクリプトを差し替えました。私の投稿で変種を間違えてしまいました。間違っている。すみません。
以前添付したスクリーンショットは必須ではありませんので、そのままにしています。