理論から実践へ - ページ 855

 
Aleksey Nikolayev:

残念ながら、そう簡単にはいきません。無限ドローダウン」という問題がある。どんな(どんなに大きな)ドローダウンでも、無限時間内に確率1で到達する。

だから、「無限の時間」を交換することはないだろう )
 
Maxim Kuznetsov:


PS. ほとんどの抽象的な「無限ゲーム」には、大きな欠陥があります - 負けの基準は定義されていますが(0に到達)、勝ち目はありません。

しかし、人は自分の中で勝敗の基準を決めているのだろうか。

 
Alexander_K:

あーあ...。議事録について...。いや、何も見つからずに立ち去りました。重要な情報が失われ、どれとは言えませんが、何かが永遠に失われる、それは事実です。

1分間にどれだけ価格が動いたか(スピード)。 1ティックは価格の最小変化 量です。10ティック - 10回の価格変動。どれだけの時間がかかったかわからない。ティックの欠点は、取引の強度を考慮に入れていないことです。
 
multiplicator:
だから、「無限の時間」は交換しない )

もちろん、そんなことはしない。十分に大きなドローダウンの後、このゲームは負けたと判断する。無限ドローダウン」発言のポイントは、「避けられない」ということです。

 
multiplicator:
分足は1分間にどれだけ価格が動いたか(スピード)、ティックは価格の最小変化 量です。10ティック - 10回の価格変動。どれだけの時間がかかったかわからない。ティックの欠点は、取引の強度を考慮に入れていないことです。

全くその通りです。

一般に、市場は確率過程のモデルによって、一定の制約のもとで合理的に記述されるが、データの取得と処理の問題が礎となる。

ブラウン粒子の運動を観察する古典的な方法は、一定時間ごとにデータを収集することである(30秒後)。(Perrinのように)、または10秒後。(化学実験室で今やっているように)。

しかし、ブラウン運動と価格運動の根本的な違いは、分子が連続的に動く(連続時間)のに対し、価格は動きに隙間がある(離散時間)ことである。

そのため、データ受信の選択された時間間隔と、重要なHIGH/LOWデータを失う可能性との間に、何らかのバランスが必要である。

某Bassは、ポテトを食べたことで、1秒ごとにデータを取ることを推奨し、それが新しいティックであったかどうかを判断しています。

しかし、根菜類で麻酔をかけた彼は、この場合、増分の分布が擬似引用符のためにゼロに「誤った」ピークを持つことになり、統計調査の威力は地獄に落ちることを忘れているのです。

したがって、最も正しい方法は、すべてのティックで動作させるか、妥協案として、DCに応じて、3〜5秒ごとに読み取ることです。

聖杯を探すという問題は確かに非常に複雑で、データの受信/処理方法も重要なものの一つです。

アレクセイ・ザ・ヤンガーやワーロックのようなニューラルネットワーカーの中には、これらの方法を絶対的に秘密にしている人もいるし、証券会社のフィルターなしでティッククォートを受け取るためにお金を払う人さえいます。想像できますか?クレイジーだ。

 
Alexander_K:......そして、お金を払ってDCフィルターなしのティッククォートを受け入れる人もいます。想像できますか?狂っているのです。

トレーダーは見積もりに対してお金を払うのではなく、見積もり側のスペースを借りるためにお金を払うのです。

ディーラーは見積もりでお金を払うから、彼からは勝てない。

 
multiplicator:
分足は1分間にどれだけ価格が動いたか(速度)、ティックは価格の最小変化 量です。10ティックは10回の価格変動です。 どれだけの時間がかかったかはわかりません。
速度が指数関数的に分布している場合、どうやって説明するのでしょうか。増分の量そのものと同じように、結果のないプロセスです。次のバスが来るまでの時間差が指数関数的に分布しているとき、バス停でバスを待つ立ち姿でバスの速度を計算することは可能でしょうか?依存関係はありません。
 
Novaja:
指数関数的に分布しているのであれば、どうやって速度を説明 するのか、増分自体もそうですが、後腐れのない処理です。バス停でバスを待つとき、次のバスが来るまでの時間差が指数関数的に分布している場合、バスの速度を計算することは可能でしょうか?関係がないのです。

あ、初歩的なことなんですけどね。

15分足を例にとり、終値のボリュームiVolumeを見ます。

で、各ティック 内部で、価格変動があればiVolume=1、なければ0(ゼロ)

速度=経路/時間=体積/時間

したがって、指数で 刻みを読んだり、1秒に1回読んだりしても、物理的には意味がありません。

意味は,価格が変化したティックを読み取ることのみであり,すなわち,単一のベクトルに関心を持っている

トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム

ビルド1485以降のCopyTicks()とCopyTicksRange()のバグと改善。

アレクセイ・ヴォルチャンスキー, 2016.12.01 02:57

Webのドキュメントにバグがあるだけで、MEではまだ本当に空っぽなんだと思います。または、機能がまだ開発中である。次に、1970年からどこかのデータを要求しているのに、なぜ前世紀のダニが返さないのか不思議です)!!!そこで何を吸っているんだ?

そういうことなんです。

void OnStart()
{
    datetime dt1 = D'2016.11.28 00:00:00', dt2 = D'2016.11.30 00:00:00';
    MqlTick ticks[];
    ulong start, msc;
    //--- Замеряем время старта перед получением тиков
    start=GetMicrosecondCount();
    int copied = CopyTicksRange( _Symbol, ticks, COPY_TICKS_ALL, dt1*1000, dt2*1000);
//--- Рассчитаем, за сколько мс получена история
    msc=GetMicrosecondCount()-start;
    Print("copied=", copied, "   msc=", msc);
    return;
}

// вывод
2016.12.01 04:52:08.134 TestCopyTicks (EURUSD.m,M15)    copied=333081   msc=1294871
2016.12.01 04:52:16.877 TestCopyTicks (EURUSD.m,M15)    copied=333081   msc=318596

***

このコードで、COPY_TICKS_ALLを COPY_TICKS_INFOに 変更します。
ticks配列に読み込まれます。
 
分単位の問題は、バー内の増分の絶対量を計算できないことです。iVolumeでは、ティックが異なることがあるので、役に立ちません。
 
Evgeniy Chumakov:
分足バーの問題は、バー内の増分値の絶対的な合計を数えることができないことです。

スピードに興味を持ったので、厚かましくならないように。

ただし、1分バーは毎分形成されるわけではない

だから、M15を提案したんです。

また、H4以上であれば、ほぼ無害であることが試験で確認されています。