Обсуждение статьи "Разработка системы репликации - моделирование рынка (Часть 01): Первые эксперименты (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 секунд!)))
В результате, со всеми правками.
Было создано 1153 809 позиций для перемещения.
Удаленные тики = 1066231
Проверка скорости выполнения . 2023.12.02 01:52:21 ---- 2023.12.02 01:53:17
Время построения первой свечи: 00:00:56 секунд.)))
Мы выиграли 56 секунд!
Спасибо за вашу отличную работу!
У меня есть вопрос. Возможно ли добавить возможность перемотки в реплее? Я имею в виду возврат к предыдущим свечам и повторное воспроизведение.
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Опубликована статья Разработка системы репликации - моделирование рынка (Часть 01): Первые эксперименты (I):
Что вы думаете: создавать системы для изучения рынка, когда он закрыт, или создать систему, которая позволит моделировать рыночные ситуации? Здесь мы начнем новую серию статей, посвященных этому вопросу.
Данный код создаст бары с периодом в 1 минуту, что является минимальным требованием платформы для создания любого другого периода графика. Выделенные фрагменты не являются частью самого кода, но полезны для анализа 1-минутного бара. Они позволяют нам проверить, создается ли он в указанные таймфреймы. Если создание занимает гораздо больше, чем 1 минута, то с этим нужно что-то делать. Однако если он создается менее чем за 1 минуту, возможно, система жизнеспособна уже с самого начала.
После выполнения этой системы, мы получим результат, который показываем на следующем видео:
Автор: Daniel Jose