記事「リプレイシステムの開発—市場シミュレーション（第1回）：最初の実験(I)」についてのディスカッション
次のコードのポイントは？
17 struct st00 18 { 19 datetime dt; 20 int milisec; 21 double Bid, 22 Ask, 23 Last; 24 long Vol; 25 uchar flag; 26 }st00 m_ArrayInfoTicks[];
53 m_ArrayInfoTicks[m_ArrayCount].dt = macroRemoveSec ( StringToTime ( StringSubstr (szInfo, 0 , 19 ))); 54 m_ArrayInfoTicks[m_ArrayCount].milisec = ( int ) StringToInteger ( StringSubstr (szInfo, 20 , 3 ));53行目で秒が削除されたのなら、54行目でミリ秒とその使用は意味を失う。
しかし、構造体には追加されている。
タイマー・イベントは独立して生成される。そして、それぞれの刻みは、ミリ秒や秒（これは削除される）ではなく、タイマーに従って行われる。
ミリ秒は、余分なメモリー領域のように、空中で重くなる。そして充填のための不必要な操作。
さらに、分足バーの構築を減らすことができる別の問題を解決していません。
例えば、赤と青で強調表示されている時間は同じで、最後の価格が同じかどうかはわかりません。
これらのティックを圧縮することで、分足バーの構築にかかる時間を大幅に短縮することができます。
これでは、この圧縮を正確に行うことは不可能です。ミリ秒と秒のバインディングはありません。
もちろん、ミリ秒の値が次の秒に移動する確率は低いし、次のティックでも継続する。しかし、それは存在する。
分バーから次のバーに 移動 するときだけ、100%の精度が保証されます。
例えば、赤と青で強調表示されている時間は同じで、最後の価格が同じかどうかはわかりません。
これらのティックを圧縮することで、分足バーの構築にかかる時間を大幅に短縮することができます。
449 2021.10 . 22 09 : 00 : 38.649 107900 107905 6 450 2021.10 . 22 09 : 00 : 38.651 107900 1.00000000 88 451 2021.10 . 22 09 : 00 : 38.651 107895 5.00000000 88 452 2021.10 . 22 09 : 00 : 38.651 107890 5.00000000 88 453 2021.10 . 22 09 : 00 : 38.651 107885 3.00000000 88 454 2021.10 . 22 09 : 00 : 38.651 107880 15.00000000 88 455 2021.10 . 22 09 : 00 : 38.651 107880 3.00000000 88 456 2021.10 . 22 09 : 00 : 38.651 107875 16.00000000 88 457 2021.10 . 22 09 : 00 : 38.651 107870 2.00000000 88 458 2021.10 . 22 09 : 00 : 38.654 107875 1.00000000 88 459 2021.10 . 22 09 : 00 : 38.654 107875 1.00000000 88 460 2021.10 . 22 09 : 00 : 38.654 107880 1.00000000 88 461 2021.10 . 22 09 : 00 : 38.659 107880 2.00000000 88 462 2021.10 . 22 09 : 00 : 38.659 107885 2.00000000 88 463 2021.10 . 22 09 : 00 : 38.660 107885 1.00000000 88 464 2021.10 . 22 09 : 00 : 38.660 107890 3.00000000 88 465 2021.10 . 22 09 : 00 : 38.662 107885 3.00000000 88 466 2021.10 . 22 09 : 00 : 38.662 107880 3.00000000 88 467 2021.10 . 22 09 : 00 : 38.662 107875 2.00000000 88 468 2021.10 . 22 09 : 00 : 38.662 107895 3.00000000 88 469 2021.10 . 22 09 : 00 : 38.662 107900 1.00000000 88 470 2021.10 . 22 09 : 00 : 38.664 107880 1.00000000 88しかし、あなたは53行目で秒を削除しました。
53 m_ArrayInfoTicks[m_ArrayCount].dt = macroRemoveSec ( StringToTime ( StringSubstr (szInfo, 0 , 19 )));
54 m_ArrayInfoTicks[m_ArrayCount].milisec = ( int ) StringToInteger ( StringSubstr (szInfo, 20 , 3 ));
そして54行目にミリ秒を残しています。 これでは、この圧縮を正確に行うことは不可能です。ミリ秒と秒のバインディングはありません。
もちろん、ミリ秒の値が次の秒に移動する確率は低いし、次のティックでも継続する。しかし、それは存在する。
分バーから次のバーに 移動 するときだけ、100%の精度が保証されます。
刻みを未来に圧縮するにはミリ秒が必要ですか？私は正しく理解していますか？
まあ、"未来に"-私にとっては-まだ先を読んでいない。あなたにとっては、すでに「過去」なのでしょうが...)))
もしそうなら、私はこの秒数を削除することができることに同意します - 偶然の一致の確率は極めて低いです)))
まあ、"未来に"-私にとっては-まだ先を読んでいない。あなたにとっては、すでに「過去」なのでしょうが...)))
もしそうなら、私はこの秒数を削除することができることに同意します - 偶然の一致の確率は極めて低いです)))
ああ、奇跡だ！ミリ秒を圧縮すると、分ローソクの形成時間は00時01分06秒になる。圧縮なしの00:01:52に対して。我々は46秒勝った！))
素晴らしい仕事をありがとう！
質問があります。リプレイに巻き戻しオプションを追加することは可能ですか？つまり、前のローソクに戻り、もう一度プレーするということです。
取引の機会を逃しています。
- 無料取引アプリ
- 8千を超えるシグナルをコピー
- 金融ニュースで金融マーケットを探索
新しい記事「リプレイシステムの開発—市場シミュレーション（第1回）：最初の実験(I)」はパブリッシュされました:
市場がしまっているときに研究したり、市場の状況をシミュレーションしたりできるシステムを作成してはどうでしょうか。ここで、このトピックを扱う新しい連載を開始します。
このコードは、1分の期間のバーを作成します。これは、他のチャート期間を作成するためのプラットフォームの最小要件です。強調表示された部分はコード自体の一部ではありませんが、1分足の分析に役立ちます。本当にこの期間内に作成されたかどうかを確認する必要があります。作成に1分を大幅に超える時間がかかる場合は、何らかの対応をしなければならないためです。1分以内に作成された場合は、システムがすぐに実行可能であることを示している可能性があります。
このシステムを実行すると、次のビデオに示す結果が得られます。
作者: Daniel Jose