複数DCの多通貨分析に基づく効果的な取引戦略 - ページ 14

 
Mak:
まあただ、どんな「ティック分析」をしているのか理解できないのですが.:))
特に、このスレッドは「...に基づく効果的な取引戦略」ということなので。"

xnsnetがやって いることは、トピックと矛盾しているのではなく、建設的に補完しているのです。

("サーバー時間" - "クライアント時間") --- それは定数ではないか?
ティックごとの価格増分を格納できるのに、なぜ価格を格納するのですか?


また、接続の中断や干渉があった場合、どのような増分を基準にするのでしょうか?

そして、もうひとつの疑問は、「これって何のため?
(引用符をミリ秒にバインド)
異なる商品、異なるブローカーからのティックをさらに同期させるために。

xnsnet- 私見ですが、ティック情報(タイムコード、インターバルなど)の圧縮は、より困難になると思います。
の後処理を行う。異なる商品、異なるブローカー、もっと言えば情報機関のティックを、時間で同期させた一つの流れを作る必要があります。そうでなければ、処理中に再びデコードして1つのフローに展開しなければならず、余分な作業が発生しますし、さらに、コード化された情報を理解し体系化することが非常に難しくなります。

 

はい、ピルグリムさん、よくわかりました。情報の圧縮というのは、複数のクライアントからのデータを、同じDCサーバーやデモサーバーに最終的に統合するという意味です。もちろん、圧縮アルゴリズムを適用するつもりはなかったのですが:)今後は、例えば1ヶ月前の履歴をずっと前に処理する、このような行動を収束と呼ぶことにします。
例えば、データを提供するクライアントが悪い場合、このデータは役に立たないものとして捨てられますが、その良し悪しは、他の複数のクライアント、例えば異なるIPアドレスやアドレスレンジのクライアントから同じデータを受信することによって確認されます。見た目ほど複雑ではなく、開発者である私がこれらの手順をすべて把握していますので、安心してください。

コメント:このようなサーバーの実現可能性におけるもう一つの結論です。当初、私は自分自身で何ができるか、つまり自分で情報を集められるかを考えていましたが、他のクライアントからのデータを使ってこれを行うグローバルサーバーの結論に至りました。その結果、自社の努力なしに他の証券会社をモニターする機会を得ることができるのです。この場合、情報はすべてのクライアントから吸収されるのではなく、サーバー自身が選択したものからしか吸収されない。ソース選択の方法は、クライアントの数と多様性、およびそのアーマー(吸収率と供給量)に依存し、一般的に最も重要なパラメータである。

1台のサーバーで複数のベンダークライアントに対応できないので、デリゲーションを考えたり、クラスターで実装したりする必要もあると理解しています。でも、今はそれほど重要ではありません:)本質がはっきりしている:)プロジェクトは まだ存在しないと開始されなかったことに注意してください、私はすでにのように、ここで話されているので、私の頭の中で一般的なアイデアと同時に、このスレッドで形成する。Aa プロジェクトを始めるのですか?はい?そうですね。面白い:)むしろ、始める前に値が決まっているのですが、すでに明らかになっていることも多いのです:)すでに何度も始めては行き詰まりましたが、明るい兆しもあり、遅かれ早かれ、長い時間をかけても、他の人の果実を使うようになります:)私が最初でも最後でもないと思います:)プロジェクトに着手する前に、すべてを詳細に考える必要があるため、つまずきはすでに嫌になっている、特に「失速」のような言葉は、ある理由または別の習慣になっている場合:)だからこそ、話題を発展させ、巻き込み、議論し、真実を推し量り、様々な矛盾と戦う必要があるのです。これこそ、みんなが感謝していることだからです。もしかしたら、一緒にプロジェクトの意義が決まるかもしれませんね:)念のため申し上げておきますが、内容を勉強した上でなら、どんな意見も重要です。このプロジェクトは、どちらかというと、非商用でオープンな形で公開される予定です、サーバー部分は確実に:)。私は実際にほとんどすべての最近のオープンで、私はそれに大きな期待を持っています:)。私は1つだけのプログラム、寄付をサポートします場合は、すべての参加者は、寄付のシェアで報われる、私は寄付を意味する:)を必要としないライセンスを制御します。何かを売るためには、会社を作る、人を集めるなど、この事実を否定するものではありません。ビジネス環境では、このプロジェクトはトレーダーから支持されるかどうかだと思います。それ以外の部分については、よく理解できたと思います。オープンプロジェクトは、特にスターターが一人で、サポートがない場合、開発が早く、実装が早いなどの特徴があります。正直、誰がやるか、どうやるかが重要なタスクのレベルではなく、やることがメインなんです:)

 
elritmo:
Piligrimm:
ウィンドウ内のツールのクローズラインはMTでは緑で描画されます。その他は、再スケーリング後に適用されます。添付ファイルに例がありますが、ウィンドウにコードとして読み込むことができませんでした。ファイル自体は他の作業を想定しているのでクセがあり、しかもMQLを知らないので非常に雑に書いている。
これは、インジケータ・ウィンドウで、インジケータ・コードのすべてを描画します。

そうですね、でも、楽器のチャートを表示するのと同じようなウィンドウを自分で作ればいいのですが、やり方がわからないんです。これは、異なる楽器のスケーリングチャートを 一つのウィンドウに表示するだけでなく、時間的に同期させるために必要です。一度のスケーリングでは、完全な客観像を得ることはできません。異なるツールの異なる場所での省略のために、異なるツールのチャートは互いに相対的にずれるので、知覚像とさらなる計算の精度の両方を乱すことになるのです。 現在、同期プログラムの作成に着手していますが、残念ながら今日はデバッグを終える時間がなく、明日から1週間、インターネット接続ができないので、結果の表示は1週間後となります。皆さんとは当分お別れです。
 
私が拡張機能で何をしているのか見たくないという人のために説明すると、実は特別なことはなく、チックはチック、ただ角度が違うだけなのです:)
それ以外は、サイトの動画機能を確認しました:)正直なところ、snagitは私のコンピュータの最後のリソースを奪います。おそらく、サービスによる過負荷と20から50パーセントまでの一定のCPU負荷、または2つのモニタのため、私は知っていればいいのに。録音を開始するのに十分な、すべてが見知らぬ人のようにラグ、どんなサイズの地域や画面に関係なく、デスクトップ全体が原則的に、はい、しかしどのように他のキャプチャかのように、常に同じラグ:)。

 
サーバーの考え方は、このような理由から、「チック:振幅と遅延の分布」が取り上げられています。