CopyTicks」のテスト - ページ 23 1...161718192021222324252627282930...47 新しいコメント fxsaber 2016.10.18 14:21 #221 Renat Fatkhullin:自分にとって必要なものを一度ディープダウンして、あとは近くのキャッシュから新しいものだけをマイクロ秒単位でダウンロードするのが最適です。毎回ディープクエリーを作ってディスクに失敗していたら、それはもちろん自分の責任です。 9月第1週のティック履歴を最も最適に取得するためのコードを教えてください。 Renat Fatkhullin 2016.10.18 14:44 #222 fxsaber: 9月第1週目のティック履歴を取得するのに最適なコードを教えてください。自分で書く、それは難しいことではありません。正確な日付を照会し、ローカルの配列に保存します。キャッシュの外で作業しても最適化はされない。最適化は、キャッシュから最後の4096ティックをダウンロードするときにのみ意味があります。 fxsaber 2016.10.18 14:49 #223 Renat Fatkhullin:自分で書く、それは難しいことではありません。正確な日付のクエリを実行し、ローカル配列に格納します。これでは、必要な間隔に何回刻みがあったのか、事前に知ることができません。countパラメータを決定する方法はない。ここで問題です。9月に入ってからの全履歴をカウント=兆で汲み取ること、もちろん可能です。次に,バイナリサーチで配列の中の終了日を探し,切り捨てます.しかし、このトリロジーは、まったく技術的なアプローチではありません。関数に from, toをオーバーロード する必要があります。あるいはデータベースへのインデックスアクセス。 削除済み 2016.10.18 14:56 #224 Renat Fatkhullin:最適化が意味を持つのは、キャッシュから最後の4096ティックをダウンロードするときだけです。参考資料よりスピード出力: 端末は各シンボルに対して4096個の最後のティックをキャッシュに保存し、素早くアクセスできます(実行中のスタックを持つシンボルに対して - 65536個のティック)。 そして約65536ティック(スタックあり)......これはもう最適ではないでしょうか? Renat Fatkhullin 2016.10.18 19:08 #225 CopyTicksの改善は次のビルドで準備する予定です。高速キャッシュを128kティックまで自動拡張できるようにすれば、より簡単にプログラムを書くことができるようになるかもしれません(わざわざダウンロードする必要がなく、高速キャッシュから直接必要な容量を取得できる場合が多い)。この関数のバージョンを追加し、正確な日付で見積もりできるようにする予定です。 fxsaber 2016.10.18 19:54 #226 Renat Fatkhullin:CopyTicksの改善は次のビルドで準備する予定です。高速キャッシュを128kティックまで自動拡張できるようにすれば、プログラムを簡単に書けるようになる(ダウンロードに悩まされることなく、必要な容量を高速キャッシュから直接取得できるようになる)可能性がある。正確な日付で見積もりを取ることができるように、機能の追加バージョンを追加する予定です。ありがとうございました。から完全にロードされた履歴については、おそらく、ゼロGetLastErrorを 言うでしょう。なお、現在では(ご指摘の改善策の導入により)フロムタイム以前であるティックを取得することは極めて困難です。したがって、私はカウントとネガを作ることを提案します - 未来に(右へ)だけでなく、過去に(から== 0のように)刻みの要求。そうすれば、常に以前の履歴を照会するのが便利で最適な方法(あなたの実装)になります。 削除済み 2016.10.19 05:11 #227 fxsaber:ありがとうございました。履歴が完全にダウンロードされた場合、GetLastErrorが0になることがあります。なお、現在では(ご指摘の改良を導入して)フロムタイム以前であるティックを取得することは極めて困難です。したがって、私はカウントとネガを作ることを提案します - 未来に(右へ)だけでなく、過去に(から== 0のように)刻みの要求。そうすれば、常に以前の履歴を照会するのが便利で最適な方法(あなたの実装)になります。 CopyTicks()のオーバーロードは、他のCopy...()関数と同じように一度に行うようにした方がよいでしょう。 fxsaber 2016.10.19 05:15 #228 Alexey Kozitsyn: CopyTicks()のオーバーロードは、他のCopy...()関数と同じにした方がよいでしょう。 そうなると、デフォルトのcountとfromを捨てなければなりません。 削除済み 2016.10.19 05:45 #229 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[]// データをコピーする配列);以上です。 削除済み 2016.10.19 05:48 #230 fxsaber: そうなると、デフォルトのcountとfromを捨てなければなりません。最初はよく読まなかった...。はい、そうです。それがどうした?開発者がキャッシュを拡張する場合、それは十分な大きさのダニの履歴を ロードするときだけ遅くなり、多くの場合、それは行う必要はありません。また、リアルタイムの読み込みには一切影響を与えません(キャッシュから取得します)。デフォルトのパラメータを保存しようとするよりも、日付からロードすることの方がよっぽど重要だと思います。 1...161718192021222324252627282930...47 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
自分にとって必要なものを一度ディープダウンして、あとは近くのキャッシュから新しいものだけをマイクロ秒単位でダウンロードするのが最適です。
毎回ディープクエリーを作ってディスクに失敗していたら、それはもちろん自分の責任です。
9月第1週目のティック履歴を取得するのに最適なコードを教えてください。
自分で書く、それは難しいことではありません。
正確な日付を照会し、ローカルの配列に保存します。キャッシュの外で作業しても最適化はされない。最適化は、キャッシュから最後の4096ティックをダウンロードするときにのみ意味があります。
自分で書く、それは難しいことではありません。
正確な日付のクエリを実行し、ローカル配列に格納します。
これでは、必要な間隔に何回刻みがあったのか、事前に知ることができません。countパラメータを決定する方法はない。ここで問題です。
9月に入ってからの全履歴をカウント=兆で汲み取ること、もちろん可能です。次に,バイナリサーチで配列の中の終了日を探し,切り捨てます.
しかし、このトリロジーは、まったく技術的なアプローチではありません。関数に from, toをオーバーロード する必要があります。あるいはデータベースへのインデックスアクセス。
最適化が意味を持つのは、キャッシュから最後の4096ティックをダウンロードするときだけです。
参考資料より
スピード出力: 端末は各シンボルに対して4096個の最後のティックをキャッシュに保存し、素早くアクセスできます(実行中のスタックを持つシンボルに対して - 65536個のティック)。
CopyTicksの改善は次のビルドで準備する予定です。
CopyTicksの改善は次のビルドで準備する予定です。
ありがとうございました。
から完全にロードされた履歴については、おそらく、ゼロGetLastErrorを 言うでしょう。
なお、現在では(ご指摘の改善策の導入により)フロムタイム以前であるティックを取得することは極めて困難です。したがって、私はカウントとネガを作ることを提案します - 未来に(右へ)だけでなく、過去に(から== 0のように)刻みの要求。
そうすれば、常に以前の履歴を照会するのが便利で最適な方法(あなたの実装)になります。
ありがとうございました。
履歴が完全にダウンロードされた場合、GetLastErrorが0になることがあります。
なお、現在では(ご指摘の改良を導入して)フロムタイム以前であるティックを取得することは極めて困難です。したがって、私はカウントとネガを作ることを提案します - 未来に(右へ)だけでなく、過去に(から== 0のように)刻みの要求。
そうすれば、常に以前の履歴を照会するのが便利で最適な方法(あなたの実装)になります。
CopyTicks()のオーバーロードは、他のCopy...()関数と同じにした方がよいでしょう。
そうすると、デフォルトのcountとfromを捨てなければならない。
なぜ?CopyBufferを 例にとると、今はこんな感じです。
intindicator_handle,// インジケータ・ハンドル
intbuffer_num,// バッファ番号 のインジケータ
datetimestart_time。//date
intcount,// 何個copy
doublebuffer[]// データがコピーされる配列.
);
countとfrom(start_time)があります。
これを追加することを提案していますね。
intindicator_handle,// インジケータ・ハンドル
intbuffer_num,// インジケータ・バッファの番号
datetimestart_time,// どの日付から
datetimestop_time,// 何月 何日までか
doublebuffer[]// データがコピーされる配列.
);
つまり、両方向にコピーできるわけですね。ただし、datetimeの代わりにulong(マイクロ秒単位)。
今後、このオーバーロードを他の用途に追加していく予定です。
intCopyBuffer(
intindicator_handle,// インジケータ・ハンドル
intbuffer_num,// インジケータ・バッファ番号
intstart_pos,//どこから始めるか
intcount,// 何個コピー するか
doublebuffer[]// データをコピーする配列
);
以上です。
そうなると、デフォルトのcountとfromを捨てなければなりません。
最初はよく読まなかった...。はい、そうです。それがどうした?開発者がキャッシュを拡張する場合、それは十分な大きさのダニの履歴を ロードするときだけ遅くなり、多くの場合、それは行う必要はありません。また、リアルタイムの読み込みには一切影響を与えません(キャッシュから取得します)。
デフォルトのパラメータを保存しようとするよりも、日付からロードすることの方がよっぽど重要だと思います。