Особенности языка mql5, тонкости и приёмы работы - страница 107
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Наверное, имелось в виду, что один проход может длиться дольше ~50 дней
не, Слава все правильно понял и сказал.
Плотность времени в тестере совсем другая. Не прокатит.
Был неправ.
Был уверен, что в тестере функция GetTickCount() эммулирует значения, исходя из времени теста.
Очень странно и не логично. Сюрприз для меня. Т.е. нужно понимать, что GetTickCount() попросту в тестере "замирает".
Был неправ.
Был уверен, что в тестере функция GetTickCount() эммулирует значения, исходя из времени теста.
Очень странно и не логично. Сюрприз для меня. Т.е. нужно понимать, что GetTickCount() попросту в тестере "замирает".
Почему нелогично?
В пределах одного вызова OnTick, OnCalculate, OnInit, OnDeinit etc вполне логично. Расчёты бывают очень разные по тяжести.
не, Слава все правильно понял и сказал.
Нет, не правильно.
Если пройдет ровно 50 суток с момента старта программы, то разница будет показывать несколько часов.
Но если использовать GetMicrosecondCount() вместо GetTickCount(), то время непереполнения будет уже не 50 суток, а 584542 лет
ЗЫ Точнее 583081 год, если учитывать Григорианский календарь ))
Почему нелогично?
В пределах одного вызова OnTick, OnCalculate, OnInit, OnDeinit etc вполне логично. Расчёты бывают очень разные по тяжести.
Ну да, логично только для замеров времени выполнения расчетов какой-то функции или блока кода. Для остального, как например, замер времени между какими-то событиями, функции GetTickCount() и GetMicrosecondCount() в тестере не годятся.
Нет, не правильно.
Если пройдет ровно 50 суток с момента старта программы, то разница будет показывать несколько часов.
такие промежутки не меряют
ну и честно говоря даже если такой случай учитывать, то КАК его учитывать - хз. привлекать еще один замерщик? тогда возможно gettickcount лучше вообще не использовать.
такие промежутки не меряют
ну и честно говоря даже если такой случай учитывать, то КАК его учитывать - хз. привлекать еще один замерщик? тогда возможно gettickcount лучше вообще не использовать.
Да нет, конечно можно не париться. 50 суток - это, действительно, выходит за грань практического применения. Ну если очень нужно тестировать более 50 суток , то лучше все же применять GetTickCount(), т.к. она более легкая, просто с контролем переполнения (будет дополнительная переменная).
На самом деле поднятая тема локального времени в тестере очень токсичная для честной конкуренции. Все шито белыми нитками.
Я бы на месте MQ закрыл бы эти все лазейки для определения локального времени, т.к. в тестере это не нужно, а нужно только для вешания лапши на уши доверчивым новоиспеченым трейдерам.
Ну, или, хотя бы снести данную тему из этой ветки и из других, если имеется.
На самом деле поднятая тема локального времени в тестере очень токсичная для честной конкуренции. Все шито белыми нитками.
Я бы на месте MQ закрыл бы эти все лазейки для определения локального времени, т.к. в тестере это не нужно, а нужно только для вешания лапши на уши доверчивым новоиспеченым трейдерам.
Ну, или, хотя бы снести данную тему из этой ветки и из других, если имеется.
Никакого обмана тема не может нести. Что же касается практического применения, то в КБ использую. Удобно.