一度こういうのを作ったことがあるんですよ. - ページ 12

 

まあ、00年代と中盤の落ち込みは気にならないでもないですが。しかし、その統計的な有意性を目で見て判断するには ...無理だと思う。:-)

平均と分散を計算する必要がある。もしかしたら、その変動は数分の一かもしれないし、逆に数十分の一かもしれない。そうすれば、その意義も明らかになる。

追記

驚くべきは、ヒストグラムの上端が滑らかなことでしょう。これが純粋に統計的なものであれば、このエッジは凸凹の櫛のようなものでしょう。このままでは、増減がかなりまともになる。

 
前の返信を削除し、より情報量の多いバージョンを提供します :)

Prival:

あなたの統計から、私の理解が正しければ、50レベルは飛んでいるのですが、それでは私が提案したことと大差がありません。

そう、50も00も懐かしいことが判明したのです。

私のインジケータの条件をあなたのインジケータに置き換えて、この変種を買いタイプのエントリーのカウントと呼ぶのは簡単です。同様に、Sellのエントリーをカウントさせるのも簡単です。以下はすべてのバリエーションで、現在コメントされていないのは売り物タイプです。

      TLvl1 = NormalizeDouble(RLvl1+Delta*0.0001,Digits);
//      if (High[pos] >= TLvl1 && Low[pos] <= TLvl1) Cnt[Delta]++;
//      if (High[pos] > TLvl1 && Open[pos] < TLvl1) Cnt[Delta]++;
      if (Low[pos] < TLvl1 && Open[pos] > TLvl1) Cnt[Delta]++;
      TLvl2 = NormalizeDouble(RLvl2+Delta*0.0001,Digits);
//      if (High[pos] >= TLvl2 && Low[pos] <= TLvl2) Cnt[Delta]++;
//      if (High[pos] > TLvl2 && Open[pos] < TLvl2) Cnt[Delta]++;
      if (Low[pos] < TLvl2 && Open[pos] > TLvl2) Cnt[Delta]++;

そして、これが結果です。左の買い右の売り、ほぼ同じですが、統計が小さくなっているだけです。


 
Yurixx:

まあ、00年代と中盤の落ち込みは気にならないでもないですが。しかし、その統計的な有意性を目で見て判断するには ...無理だと思う。:-)

平均と分散を計算する必要がある。もしかしたら、その変動は数分の一かもしれないし、逆に数十分の一かもしれない。そうすれば、その意義も明らかになる。

追記

驚くべきは、ヒストグラムの上端が滑らかなことでしょう。これが純粋に統計的なものであれば、このエッジは凸凹の櫛のようなものでしょう。そのままだと、増減がかなりまともになる。

統計的に有意だと思います。だからといって、実用上重要な意味があるわけではありませんが......。)


追伸:目視で判断する必要はなく、インジケータがファイルにデータを書き込むので

 
実は、この棒グラフを実装するセンスある戦略が大問題なのです。
 
HideYourRichess:
実は、この棒グラフを実装するセンスある戦略が大問題なのです。
また文脈とフィルターに行き着くのではと思います :)
 

これは残念なことです。

一方、Hボラティリティを見ると、厳密には2ではなく、多少の波動性もある。

そしてもうひとつ。データにそのようなうねりがあるとすれば、それは例えばペンの中にあるのかもしれません。もし効果が大きいのであれば、ダッシュの方向の予測を改善するなどの工夫ができるかもしれませんね。しかし、それはどうでしょう。

 
HideYourRichess:

これは残念なことです。

一方、Hボラティリティを見ると、厳密には2ではないのです。

時間的なうねりか、ジグザグパラメータでのうねりか?

 
Candid:

そこで、簡単なスクリプトを紹介すると、「丸い」踏切の数とデルタポイントをカウントしてくれる。2004.06.16 10:55からEURUSD, GBPUSD, USDCSDで使用しました。その結果、予想外の面白さが生まれました。

スクリプトのテキストと質問の両方についてコメントを受け付けます :)


P.S. スクリプトは大きなDeltaに対応するが、結果の意外性を打ち消さないようにする。

IMHOはそうでもないです。指値注文は常に直近の「丸い」水準で発注されるとします。バーフォーメーションで指値注文を出したとします。すべてのオープンポジションが 次のバーの始値で決済されたとします。そして、HighまたはLowがLimit注文にタッチすると、一度だけトリガーされます。しかし、この場合のトリガーの結果は、品質ではなく、トリガーの数で計算されるなど、不正確なものです。


つまり、どのレベルのクロス数にもお金を払うブローカーはいないので、取引に適用するタスクは適切に設定する必要があります。


1.Highが最も近い「ラウンド」レベルに達した場合、このレベルと次のバーの始値との差を金額に加算します。

2.安値が直近の「ラウンド」レベルにタッチした場合、そのレベルと次のバーの始値の差を合計から差し引きます。


スプレッドを考慮しない結果を得ることができる。スプレッドを考慮しなくても結果がゼロに近ければ、明らかに獲るものがない。

 
Reshetov:

IMHOそれは少しずれています。常に最も近い「丸い」レベルで指値注文をすると仮定しよう。ここでは、バーが形成されたときに必ず指値注文を設定するとします。すべてのオープンポジションが次のバーの始値で決済されたとします。そして、HighまたはLowがLimit注文にタッチすると、一度だけトリガーされます。しかし、この場合のトリガーの結果は、品質ではなく、トリガーの数で計算されるなど、不正確なものです。

つまり、どのレベルのクロス数にもお金を払うブローカーはいないので、取引に適用するタスクは適切に設定する必要があります。

1.最も近い「ラウンド」レベルに当たったら、このレベルと次のバーの価格との差を合計に加えます。

2.もしLowが最も近い「ラウンド」レベルに当たったら、そのレベルと次のバーの始値との差を合計から引きます。

スプレッドを考慮しない結果を得ることができる。スプレッドを考慮しなくても結果がゼロに近いのであれば、明らかにここで捕らえるべきものはない。


いや、本当です :) ちょっとスレッドを見逃しただけです。あなたが書いたものは、スクリプトの進化の次のステップかもしれません(または、より良い、インジケータ、クロスオーバーの一部を失うことなく、より正確なコードがあります)。

このスクリプトは、強い水準では価格が遅れるはずだという前提で、水準の強さを正確に測定するために設計されたものである。次のステップは、ある程度詳細な取引のシミュレーションを行うことです。ここでは、さまざまな戦略が可能です。

あなたのバリエーションは、Privalが提案したものとほとんど同じです。一般的に、このアルゴリズムは最小限の時間枠、つまり分単位で動作する必要があります。だからこそ、彼が提案したように、1時間後など時間枠で閉じるべきでしょう。

例えば、Privalのような複雑な特性を計算するためには、より複雑なポジション会計を実装する必要がありますが、それは次の進化のステップかもしれません。

 
テキストを次のページに移動しました。このテーマは新しい展開を見せるようなものなので、トップに近いところに置いた方が理にかなっていると思います。
ファイル: