CopyTicks」のテスト - ページ 23

 
Renat Fatkhullin:

自分にとって必要なものを一度ディープダウンして、あとは近くのキャッシュから新しいものだけをマイクロ秒単位でダウンロードするのが最適です。

毎回ディープクエリーを作ってディスクに失敗していたら、それはもちろん自分の責任です。

9月第1週のティック履歴を最も最適に取得するためのコードを教えてください。
 
fxsaber:
9月第1週目のティック履歴を取得するのに最適なコードを教えてください。

自分で書く、それは難しいことではありません。

正確な日付を照会し、ローカルの配列に保存します。キャッシュの外で作業しても最適化はされない。最適化は、キャッシュから最後の4096ティックをダウンロードするときにのみ意味があります。

 
Renat Fatkhullin:

自分で書く、それは難しいことではありません。

正確な日付のクエリを実行し、ローカル配列に格納します。

これでは、必要な間隔に何回刻みがあったのか、事前に知ることができません。countパラメータを決定する方法はない。ここで問題です。

9月に入ってからの全履歴をカウント=兆で汲み取ること、もちろん可能です。次に,バイナリサーチで配列の中の終了日を探し,切り捨てます.

しかし、このトリロジーは、まったく技術的なアプローチではありません。関数に from, toをオーバーロード する必要があります。あるいはデータベースへのインデックスアクセス。

 
Renat Fatkhullin:

最適化が意味を持つのは、キャッシュから最後の4096ティックをダウンロードするときだけです。

参考資料より

スピード出力: 端末は各シンボルに対して4096個の最後のティックをキャッシュに保存し、素早くアクセスできます(実行中のスタックを持つシンボルに対して - 65536個のティック)。

そして約65536ティック(スタックあり)......これはもう最適ではないでしょうか?
 

CopyTicksの改善は次のビルドで準備する予定です。

  • 高速キャッシュを128kティックまで自動拡張できるようにすれば、より簡単にプログラムを書くことができるようになるかもしれません(わざわざダウンロードする必要がなく、高速キャッシュから直接必要な容量を取得できる場合が多い)。
  • この関数のバージョンを追加し、正確な日付で見積もりできるようにする予定です。
 
Renat Fatkhullin:

CopyTicksの改善は次のビルドで準備する予定です。

  • 高速キャッシュを128kティックまで自動拡張できるようにすれば、プログラムを簡単に書けるようになる(ダウンロードに悩まされることなく、必要な容量を高速キャッシュから直接取得できるようになる)可能性がある。
  • 正確な日付で見積もりを取ることができるように、機能の追加バージョンを追加する予定です。

ありがとうございました。

から完全にロードされた履歴については、おそらく、ゼロGetLastErrorを 言うでしょう。

なお、現在では(ご指摘の改善策の導入により)フロムタイム以前であるティックを取得することは極めて困難です。したがって、私はカウントとネガを作ることを提案します - 未来に(右へ)だけでなく、過去に(から== 0のように)刻みの要求。

そうすれば、常に以前の履歴を照会するのが便利で最適な方法(あなたの実装)になります。

 
fxsaber:

ありがとうございました。

履歴が完全にダウンロードされた場合、GetLastErrorが0になることがあります。

なお、現在では(ご指摘の改良を導入して)フロムタイム以前であるティックを取得することは極めて困難です。したがって、私はカウントとネガを作ることを提案します - 未来に(右へ)だけでなく、過去に(から== 0のように)刻みの要求。

そうすれば、常に以前の履歴を照会するのが便利で最適な方法(あなたの実装)になります。

CopyTicks()のオーバーロードは、他のCopy...()関数と同じように一度に行うようにした方がよいでしょう。
 
Alexey Kozitsyn:
CopyTicks()のオーバーロードは、他のCopy...()関数と同じにした方がよいでしょう。
そうなると、デフォルトのcountとfromを捨てなければなりません。
 
fxsaber:
そうすると、デフォルトのcountとfromを捨てなければならない。

なぜ?CopyBufferを 例にとると、今はこんな感じです。

intCopyBuffer(
intindicator_handle,// インジケータ・ハンドル
intbuffer_num,// バッファ番号インジケータ
datetimestart_time//date
intcount,// 何個copy
doublebuffer[]// データがコピーされる配列

);

countとfrom(start_time)があります。

これを追加することを提案していますね。

intCopyBuffer(
intindicator_handle,// インジケータ・ハンドル
intbuffer_num,// インジケータ・バッファの番号
datetimestart_time,// どの日付から
datetimestop_time,// 何日までか
doublebuffer[]// データがコピーされる配列

);

つまり、両方向にコピーできるわけですね。ただし、datetimeの代わりにulong(マイクロ秒単位)。

今後、このオーバーロードを他の用途に追加していく予定です。

intCopyBuffer(
intindicator_handle,// インジケータ・ハンドル
intbuffer_num,// インジケータ・バッファ番号
intstart_pos,//どこから始めるか
intcount,// 何個コピー するか
doublebuffer[]// データをコピーする配列
);

以上です。

 
fxsaber:
そうなると、デフォルトのcountとfromを捨てなければなりません。

最初はよく読まなかった...。はい、そうです。それがどうした?開発者がキャッシュを拡張する場合、それは十分な大きさのダニの履歴を ロードするときだけ遅くなり、多くの場合、それは行う必要はありません。また、リアルタイムの読み込みには一切影響を与えません(キャッシュから取得します)。

デフォルトのパラメータを保存しようとするよりも、日付からロードすることの方がよっぽど重要だと思います。