Discussing the article: "Developing a Replay System — Market simulation (Part 01): First experiments (I)"
What's the point of the following code?
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 ));If seconds were removed in line 53, then milliseconds and their use lose all meaning in line 54.
Although, you add them to the structure.
Timer events are generated independently. And each tick comes according to a timer, and not in milliseconds and seconds (which are deleted).
Milliseconds now weigh in the air, like extra memory space. And unnecessary operations for filling.
In addition, you have not solved another problem that allows you to reduce the construction of a minute bar.
For example, the times highlighted in red and blue are the same, where the last price may or may not be the same.
These ticks can be compressed and greatly reduce the time it takes to build a minute bar.
Which makes it impossible for you to perform this compression accurately. There is no binding of milliseconds to seconds - it has been removed.
Of course, there is a low probability that the millisecond value will move to the next second, and even continue in the next ticks. But it is there.
There is a 100% guarantee of accuracy only when moving from a minute bar to the next - there is a binding of milliseconds to minutes.
For example, the times highlighted in red and blue are the same, where the last price may or may not be the same.
These ticks can be compressed and greatly reduce the time it takes to build a minute bar.
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 88But, you removed the seconds on line 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 ));
And left milliseconds in line 54. Which makes it impossible for you to perform this compression accurately. There is no binding of milliseconds to seconds - it has been removed.
Of course, there is a low probability that the millisecond value will move to the next second, and even continue in the next ticks. But it is there.
There is a 100% guarantee of accuracy only when moving from a minute bar to the next - there is a binding of milliseconds to minutes.
Do you need milliseconds to compress ticks into the future? I understand correctly?
Well, “in the future” - for me - I haven't read further yet. For you, I suppose, this is already “in the past”...)))
If this is so, then I agree that the seconds can be removed - the probability of a coincidence is extremely low.)))
Well, “in the future” - for me - I haven't read further yet. For you, I suppose, this is already “in the past”...)))
If this is so, then I agree that the seconds can be removed - the probability of a coincidence is extremely low.)))
Oh, a miracle! If you compress milliseconds, then the formation time of the minute candle will be 00:01:06. Against 00:01:52 - without compression. We won 46 seconds!)))
As a result, with all the edits.
1153,809 movement positions were created.
Deleted ticks = 1066231
Checking the execution speed . 2023.12.02 01:52:21 ---- 2023.12.02 01:53:17
Time to build the first candle: 00:00:56 seconds.)))
We won 56 seconds!
Thanks for your great work!
I got a question. Is it possible to add rewinding option to the replay?? I mean going back to previous candles and playing again.
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Check out the new article: Developing a Replay System — Market simulation (Part 01): First experiments (I).
How about creating a system that would allow us to study the market when it is closed or even to simulate market situations? Here we are going to start a new series of articles in which we will deal with this topic.
This code will create bars with a period of 1 minute, which is the minimum platform requirement for creating any other chart period. The highlighted parts are not part of the code itself but are useful for analyzing the 1-minute bar. We need to check if it is really created within this timeframe. Because if it takes much longer than 1 minute to be created, we will have to do something about it. If it is created in less than a minute, this may indicate that the system is viable right away.
After executing this system, we will get the result that we show in the following video:
Author: Daniel Jose