クラスター・アプローチによる市場開拓の実証... - ページ 4

 
ssd >> :

オープンポジションを上にした場合の条件。

if (Ind_0 > 0 && Ind_1 < 0)

オープンポジションを上向きにクローズする条件。

if (Ind_0 <= 0)

下向きにポジションを持つ条件

if (Ind_0 < 0 && Ind_1 > 0)

下方のオープンポジションをクローズするための条件。

if (Ind_0 >= 0)

この用語は、統計に基づくものではなく、議論を呼ぶものです。ロングを建てるには、第一通貨の指数がプラス、第二通貨の指数がマイナスであるだけでは十分ではありません。誤入力が多くなりすぎる。

また、ポジションを決済する際に、なぜ1つの通貨のみの指数の符号を考慮すればよいのかが明確ではありません。

また、小さなTFでの合成クロスは、実物と大きく異なるというsab1ukの指摘も正しい。

追伸:まだコードを見ていないのですが、自分も似たようなことをしようとしています。Semenychのアプローチは根本的に違うようで、今回のようにブレイクアウトではなくリバウンドで開くことを提案していますね。

 

私は1つのインデックスがその最大値(絶対値)に達し、反対方向に回転したときに最強の信号になると思いますし、第二指数もオンにする必要があります...これは、現在の時間枠での動きの主な方向の反転を示すべきである最強の信号です... そのような信号がない場合は、弱い信号に頼ることができます - インデックスチャートを横断するが、交差の前に、チャートが顕著な変化のダイナミクスを持つべきである、彼らはフラックスにサイドバイサイド "をクロールしていないこと。


上記と同じように別の信号を使用したい場合は、別の信号を作成する必要があります。

 
Mathemat >> :

この条件には賛否両論あり、統計に基づくものではありません。ロングを建てるには、第一通貨の指数がプラスで第二通貨がマイナスであればよいというわけではありません。誤入力が多くなりすぎる。

また、建玉を決済する際に、なぜ1つの通貨指標記号だけを考慮すればよいのか、その理由も不明です。

また、小さなTFでの合成クロスは、実物と大きく異なるというsab1ukの指摘も正しい。

追伸:まだコードを見ていないのですが、自分も似たようなことをしようとしています。Semenychのアプローチは根本的に違うようで、今回のようにブレイクアウトではなくリバウンドでオープンすることを提案していますね。

CL1i - この指標は、基準通貨の「クラスタ価格」と、この指標が作動している商品の気配値との 差を 示します。

このように

Ind_0は、バー0(現在のバー)における基準通貨と商品のクォート通貨の「クラスタ価格」の差です。

Ind_1 は、バー1(最初に通過したバー)における基準通貨と商品のクォート通貨の「クラスタ価格」の差です。


そうすると、例えば、基準通貨の「クラスタ価格」が引用通貨の「クラスタ価格」を上回り始めた 最初の 瞬間にオープンすることになるのです。


セメン・セメニッヒは、ポジションの開閉を同じシステムで行っていることを断言します。

 
sab1uk >> :

分足で見ると、合成ペアは自然ペアに不一致がある。

利用可能なすべての「ナチュラル」インストルメントを試しました(GBPNZDのみクロスがありません)。

しかし、パソコンにかかる負荷は、ほとんど仕事にならないほどでした。

 

Получается тогда, мы открываемся, к примеру, вверх, в самый первый момент, когда "кластерная цена" базовой валюты начинает превышать "кластерную цену" котировочной валюты.

ああ、そうだったのか。ssd さん、ありがとうございます。

しかし、パソコンにかかる負荷は、ほとんど仕事にならないほどでした。

まあ、もちろん実行可能ではあるのですが。コツは履歴のアップロード量です。あまり必要ないのでは?しかも、そこでの計算は非常にシンプルで、シングルコアでも扱えます。まあ、もちろん、すべてのティックで 計算しなければの話ですが。

しかし、私の入力基準はそこまで曇っていません。もし興味があれば、私にLINEをください。

 
ssd писал(а)>>

利用可能なすべての「ナチュラル」ツールを試した(クロスを介したモデリングで、唯一欠けているツールGBPNZDを使用)。

しかし、パソコンにかかる負荷は、ほとんど仕事にならないほどでした。

演算にサイクリック・バッファを使用することで、負荷が軽減される

 
Mathemat >> :

ああ、そうだったのか。ssdさん、ありがとうございます。

なぜかというと、仕事ができるのです。コツはダウンロードした履歴の量にある。あまり必要ないのでは?このシステムで数年分の必要分量は?

そうなんです、この手法で長話をするのは、ある意味不要なんです。

しかし、「エラー」であるERR_HISTORY_WILL_UPDATED 4066の 発生頻度は、インジケーターの読みに不確実性があるような ものであった。

つまり、コンピュータの負荷は実は小さく、ページングツールの待ち時間がすべての作業を遅らせていたのです。

28個のツールをすべて開いておくと、とても不便です。

 

開発者が対処法をアドバイスしているスレッドは こちらです。また、すべてのツールを開いておく必要はありません。Market Watchに掲載されているだけで十分です。

もう一度言いますが、すべての目盛りをカウントする必要はありません。本システムでは冗長です。計算に取り組むのは、たとえば1分間に1回で十分です。しかし、単純にiClose()などで各シンボルに頻繁にアクセスすることも望ましい。

 
Mathemat >> :

開発者が対処法をアドバイスしているスレッドは こちらです。

>> そうです!それです。>> ありがとうございます、見てみます。

 
ssd >> :

利用可能なすべての「ナチュラル」ツールを試した(不足しているGBPNZDツールのクロスのみでモデリングした)。

しかし、パソコンにかかる負荷は、ほとんど仕事に ならないほどでした。

同じ問題があった。最適化するのに3年かかりました。

今まで5分かかっていたものが、5秒でカウントされるようになったのです。