移動平均（およびその他の指標）と誤差の比較 - ページ 2

新しいコメント
 
gammaray:

これは原理的にmqlとは関係ない。抽象的なプログラミング言語を例にとろう。私が示したこの特定の例では、主な問題は、1つの同じバーのミューウイングの差の値が等しくないことです（最初の計算では2e-16、2番目の計算では正確に0）。この場合、この交差点はどのように決定されてもよい。mqlに戻ると、正規化とは、数値を丸める（というより、シシ関数のfloorのように、ある符号以降の数値を単純に全部落として、ある小数点以下の桁数にする）ことを意味します。 では、どの桁に正規化すればいいのか、どうすればいいのか。間違った桁を選択した場合、すべての値は常に正確に0に丸められる可能性があります。ですから、ここで正常化することは危険であり、一般的には問題を解決することはできません。

アレクセイ・レベデフが書いたことについては。はい、この方向で考えていました。しかし、両者の差を0以上で比較すると、誤信号が出る確率がある（例えば、隣り合うバー間のミュービングが全く同じ値である場合など、理論的にはあり得ること）。その場合、両者の差は符号を変えずに（クロスオーバーは発生しない）、クロスオーバーのための信号がプログラム的に決定されることになる。ご指摘のように、大なり小なりの比較対象を1つだけ置くこともできますね。しかし、問題は、この状況での計算では、まず0（2e-16）に等しくなく、次のバーでは正確に0になるが、厳密な比較になることです。

同じ差を異なるバーで計算すると、同じ結果にならない理由を理解することが重要である。もし結果が同じなら、厳密でない比較を1つ導入すれば、必ず問題は解決する。


正規化 する場合、はい、所定の小数点以下への丸めがあります。ある記号以降の数字をすべて捨てるのではなく、四捨五入する。

もし私がその文脈であなたを正確に理解するならば（私はあなたのスクリーンショット付きの最初の投稿と2番目の投稿の両方を取っています）、印刷時にDoubleToStringを 考慮することを含め、そのような方法での 様々な実験は、まだあなたを助けることができるだろうと思います。ロゾマから 先に聞いていたんですね。

を含む、任意のタスクで正規化するためにどのような図に自分で定義するのに役立ち、またはいくつかのケースでは正規化が必要であるかどうか（疑問の場合には、そのプログラムは、異なるDCで適用することができ、結果として、得られた計算値が異なることができる、など、関連要因のセットで適用するかしないかを、）。

私の見解では、タスクによっては、偽とみなされる信号が得られる危険性がありますが、それはちょうど正規化を適用しない場合（または何らかの小さな値のために最初の方法で比較しない場合）であり、何の害もないでしょう。

また、印刷時にDoubleToStringが 適用されないと、単に同じ差や同じ値でも結果が違うという誤解が生じる可能性があります。

/* 念のため、double 型の数値を印刷出力する場合は、数値をテキスト値に変換して出力するため、 DoubleToString を使用する必要があることを再度お伝えしておきます。そのため、この機能を使用しない場合、実際にはないエラーが表示されることがあります。

この関数の小数点以下の桁数は、もちろん正規化された値より少なくなることはありません。また、正規化されていない値では、小数点以下の桁数が大きくなる。

 
Aleksey Lebedev:

iMA関数の計算が最適化されている可能性が高いです。最初の値＝sum(close)/N、2番目＝MAの前の値＋(新しいclose-古いclose)/N。

では、一般的にiMAは1つの同じバーに対して、呼び出しの異なる時間に2つのミューウイングの 異なる値を与えることができるのでしょうか？
 
gammaray:
つまり、同じバーに対する一般的なiMAは、異なるコールタイムで2つのミューウィングの異なる値を与えることができるのですね。
チェックするか、ドライブするか？
 
Dina Paches:

正規化 する場合、はい、指定された小数点以下の四捨五入があります。それは四捨五入であって、ある小数点以下の数字をすべて捨てて いるわけではありません。

もし、私がその文脈であなたの言うことを正確に理解しているならば（スクリーンショット付きの最初の投稿と2番目の投稿の両方を考慮しています）、印刷時にDoubleToStringを 考慮することを含め、そのような方法での 様々な実験は、まだあなたの助けになると思います。

を含む、任意のタスクで正規化するためにどのような図に自分自身を定義するのに役立ち、または正規化は、いくつかのケースで必要であるかどうか（疑問の場合、そのプログラムは、異なるDCで、それぞれ、得られた計算値が異なることができることを含め、付随する要因のセットを使用するかどうかを使用すること）。

私の見解では、その時のタスクによっては、偽とみなされるシグナルが得られる危険性がありますが、それはちょうど正規化を適用しない場合（または何らかの小さな値のために最初のメソッドを比較しない場合）であり、損はないでしょう。

また、DoubleToStringを 適用せずに印刷すると、単に同じ差や同じ値でも結果が違うという誤解が生じる可能性があります。

/* 念のため、double型の数値を出力する場合は、数値をテキスト値に変換して出力するため、DoubleToStringを使用する必要があることを再度お伝えしておきます。従って、本機能を使用しない場合、以下のエラーが発生する可能性があります。

この関数の小数点以下の桁数は、もちろん正規化された値より少なくなることはありません。また、正規化されていない値では、小数点以下の桁数が大きくなる。

最後の有効桁が丸められてるのがよくわかる。しかし、例えば0.000016という数字に有効数字5桁を入れると0.00002となり、有効数字が少なければ必ず0となる。したがって、特定の桁に丸めることは常に不可能である。MA値は、タイムフレームだけでなく、バー自体にも依存します。そのため、一般的な場合、正規化時に有効桁数をどのように設定すればよいかは不明である。

無限小の値について理解できないのは、それをどのように適用するかということです。無限小（誤差）は、実数を0と比較する場合に使用します。一方、私は、その違いを比較する必要があります。この状況はさらに悪いかもしれない。例えば、あるイプシロンを設定した。その差がεより大きいとき、私はプラスと判断します。マイナスεより小さいとマイナスです。境界線内にあるときは0です。しかし、それでは差分の符号の変化はどのように判断するのでしょうか。例えば、2本の小節のムービングの差がイプシロン以内である。しかし、前者の場合はポジティブで、後者の場合はネガティブ（＝交差がすでに起きている）です。そして、私は、誤差の発生を考慮して、その差を0と見なし、符号の変更条件を変更する。条件的には、この場合、2つのMAが上から下へ交差する信号は、<0（だった）と>0（になった）の単純比較と、=0（だった）と>0（になった）の単純比較の両方になります。そして最も重要なことは、説明したケース（同じポイントでの値が異なる呼び出しで異なる場合）において、このエラーを導入しても役に立たないということです。この差は、どのεを選んでも、必ず信号が出ないようになる。

 
gammaray:

最後の有効桁が丸められてるのがよくわかる。しかし、例えば0.000016という数字に対して、5桁で正規化をかけると0.00002という数字になり、桁数が少なければ常に0になる。したがって、特定の桁に丸めることは常に不可能である。MA値は、タイムフレームだけでなく、バー自体にも依存します。そのため、一般的な場合、正規化時に有効桁数をどのように設定すればよいかは不明である。

無限小の値について理解できないのは、それをどのように適用するかということです。無限小（誤差）は、実数を0と比較するときに使用します。一方、私は、その違いを比較する必要があります。この状況はさらに悪いかもしれない。例えば、あるイプシロンを設定した。その差がεより大きいとき、私はプラスと判断します。マイナスεより小さいとマイナスです。境界線内にあるときは0です。しかし、それでは差分の符号の変化はどのように判断するのでしょうか。例えば、2本の小節のムービングの差がイプシロン以内である。しかし、前者の場合はポジティブで、後者の場合はネガティブ（＝交差がすでに起きている）です。そして、私は、誤差の発生を考慮して、その差を0と見なし、符号の変更条件を変更する。条件的には、この場合、2つのMAが上から下へ交差する信号は、<0（だった）と>0（になった）の単純比較と、=0（だった）と>0（になった）の比較の両方になります。そして最も重要なことは、説明したケース（同じポイントでの値が異なる呼び出しで異なる場合）において、このエラーを導入しても役に立たないということです。この差は、どのようなεを選んでも、信号が得られないような値になります。

何か特別な問題を解くとき、小数の有効桁の精度も頼りになると思います。倍では 有効数字15桁であることが、Documentationに記載されている。 正規化 精度のフォーマットで、0～8まで、Documentationによる。DoubleToStringは、精度フォーマットの特殊性を持っています。

また、iMAは、さまざまな場面で、さまざまな問題を解決するために、導き出される価値を考慮した機能であると私は考えています。そのため、出力される値もタスクによって異なる処理を行うことができる。

また、平均値の算出は数学的な計算である。例えば、こんな感じです。(1.20525 + 1.20598 + 1.2081)/3 = 1.2064433333...それに伴い、四捨五入の少ない計算値や拡張された計算値は、計算を適用する際の選択肢を増やすことができます。

念のため、iMAの代わりに、ターミナル標準パッケージに含まれるMovingAverages ライブラリの関数が使えることをお伝えしておきます。また、本ライブラリに含まれるものをベースにした独自の関数を使用することも可能です。

/* 数学の計算では，double 型の数値の扱いに特殊性が ある場合があります */。


一方、イプシロンについては、パスします。



P./S.：つまり、実験という のは、あなたの役に立つと思うんです。など、特定のタスクについて（大量のデータで）実践的な実験をしない理論的な推論は、混乱を招き、許容できる解決策から遠ざかってしまう可能性があります。

 
なんということでしょう。マスコットの比較は300日...。桁に 正常化し、悩まないで...。
 

Dina Paches:

...

ディナ、私はあなたの天使のような忍耐力に驚嘆しています ...
 
Artyom Trishkin:
なんということでしょう。マスコットの比較は300日...。桁に正常化し、悩まないで...。
直接、値を正規化することができます（差分-絶対ではありません）。しかし、その場合、MA比較のために与えられたアラベスクコードを変更し、とにかく非厳密な不等式を1つ入力しなければならないのです。また、異なる時刻に計算された場合、同じバー上のMA値が異なるという問題も残されています。これがさらに繰り返されると、正規化しても、非厳密な不等式を一つ導入しても、問題が完全に解決するかどうかわからない。さらに、1つのバー内のミューイングが2回交差する場合、ティックで分析するのではなく、新しいバーの オープニングで分析すると、キャッチできません。このような場合、あなたはどのように行動するのでしょうか？
 
gammaray:
値を直接正規化することができます（差分-まさか）。しかし、やはり、MAの比較のために与えられたアラベスクのコードを変更しなければならず、とにかく非厳密な不等式を入力しなければならないのです。また、異なる時刻に計算された場合、同じバー上のMA値が異なるという問題も残されています。これがさらに繰り返されると、正規化しても、非厳密な不等式を一つ導入しても、問題が完全に解決するかどうかわからない。さらに、1つのバー内のミューイングが2回交差する場合、ティックで分析するのではなく、新しいバーの オープニングで分析すると、キャッチできません。このような場合、あなたはどのように行動するのでしょうか？

まず、正規化された2つの値の差は、最終的に非正規化された値を与えることになります。正規化された差分を確認する必要があります。

次に、バー内のクロスオーバーをキャッチしたい場合は、ゼロと最初のバーのすべてのティックの値を取る - あなたは多くのことをキャッチすることができます...気をつけろよ

バーのオープニングでテストする場合、Expert Advisorは新しいバーのオープニングを明確に監視し、事実の後に、クロスオーバーをチェックする必要があります。

まず、バーのオープニングで取引するか、ティックごとに取引するかを自分で決め、それからコードを書いてください。そして、それに従って、同じようにテストする。

 
Artyom Trishkin:
Dinaさん、あなたの天使のような忍耐力には驚かされます・・・。

ありがとうございます。しかし、残念ながら、これにも限界があることがわかりました。

1234567
新しいコメント