Рациональные приемы (предложения) ускорения оптимизатора - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Нет, 2 вместо 20 нецелесообразно. А 200 вместо 2000 не получится.
В этом утверждении полностью отсутствует логика. Вы ошибаетесь.
Почему? Присутствует.
Экономия с 20 до 2 - за счет пропуска тиков. Но пустой проход не займет 2000 секунд, значит и экономить нечего.
А замерить скорость пустого прогона (с флагом, а не с функцией, как у вас), я предлагаю уже 4 страницы )
Почему? Присутствует.
Потому что если снизить частоту процессора в 100 раз, то будет 2000 vs 200.
Экономия с 20 до 2 - за счет пропуска тиков. Но пустой проход не займет 2000 секунд, значит и экономить нечего.
А замерить скорость пустого прогона (с флагом, а не с функцией, как у вас), я предлагаю уже 4 страницы )
Вы прочли пост по-диагонали и пытаетесь что-то утверждать. Вам разжевать пост или сами внимательно посмотрите (букв же немного и все там по делу)?
Советник запускается в режиме оптимизации на сотню проходов. В итоге такой перебор занимает 20 секунд. Если закомментировать вызов тела ТС (функция System), то время практически не уменьшается. Т.е. 20 секунд занимает вызов ~115 миллионов раз пустого OnTick с соответствующими внутренними проверками тестера. Иначе говоря, скорость тестера на моей машине не может превышать 6 миллионов баров в секунду, как ни крутись. Поэтому, если выбросить ~90% пустых вызовов, будет существенное уменьшение итогового времени на оптимизацию некоторых типов ТС и исследований.
Потому что если снизить частоту процессора в 100 раз, то будет 2000 vs 200.
Нет таких процессоров ;)
Вы прочли пост по-диагонали и пытаетесь что-то утверждать. Вам разжевать пост или сами внимательно посмотрите (букв же немного и все там по делу)?
Советник запускается в режиме оптимизации на сотню проходов. В итоге такой перебор занимает 20 секунд. Если закомментировать вызов тела ТС (функция System), то время практически не уменьшается. Т.е. 20 секунд занимает вызов ~115 миллионов раз пустого OnTick с соответствующими внутренними проверками тестера. Иначе говоря, скорость тестера на моей машине не может превышать 6 миллионов баров в секунду, как ни крутись. Поэтому, если выбросить ~90% пустых вызовов, будет существенное уменьшение итогового времени на оптимизацию некоторых типов ТС и исследований.
Прочитал нормально, но действительно не сделал акцента на переборе 100 комбинаций параметров. Но и это, имхо, ничего не меняет.
Завтра проведу исследование сам и поделюсь результатами.
Убил несколько часов на исследования, и понял, в чем ошибся.
Действительно, если "полезное" время программы значительно меньше времени, требуемого на проход пустых тиков, то эта функция даст ускорение. Ровно в столько раз, в сколько "полезное" время меньше "бесполезного".
По прежнему считаю, что таких задач очень немного (примера так и не увидел ;)), но признаю, что они есть.
Советник с применением программного пропуска тиков в прицепе (для истории). Работает так:
2015.04.15 03:37:19.308 Core 1 2014.01.01 23:00:00 TesterToDate: next launch scheduled to 2014.01.08 00:00:00 (pause = 522000 seconds)...
2015.04.15 03:37:19.308 Core 1 2014.01.08 00:00:00 TesterToDate: work restored at 2014.01.08 00:00:00
2015.04.15 03:37:19.308 Core 1 2014.01.08 00:00:00 instant buy 0.10 EURUSD at 1.36152 sl: 1.36052 tp: 1.36252 (1.36142 / 1.36152 / 1.36142)
2015.04.15 03:37:19.308 Core 1 2014.01.08 00:00:00 deal #2 buy 0.10 EURUSD at 1.36152 done (based on order #2)
2015.04.15 03:37:19.308 Core 1 2014.01.08 00:00:00 deal performed [#2 buy 0.10 EURUSD at 1.36152]
2015.04.15 03:37:19.308 Core 1 2014.01.08 00:00:00 order performed buy 0.10 at 1.36152 [#2 buy 0.10 EURUSD at 1.36152]
2015.04.15 03:37:19.308 Core 1 2014.01.08 00:00:00 TesterToDate: next launch scheduled to 2014.01.15 00:00:00 (pause = 604800 seconds)...
2015.04.15 03:37:19.308 Core 1 2014.01.08 01:22:21 stop loss triggered buy 0.10 EURUSD 1.36152 sl: 1.36052 tp: 1.36252 [#3 sell 0.10 EURUSD at 1.36052]
2015.04.15 03:37:19.308 Core 1 2014.01.08 01:22:21 deal #3 sell 0.10 EURUSD at 1.36052 done (based on order #3)
2015.04.15 03:37:19.308 Core 1 2014.01.08 01:22:21 deal performed [#3 sell 0.10 EURUSD at 1.36052]
2015.04.15 03:37:19.308 Core 1 2014.01.08 01:22:21 order performed sell 0.10 at 1.36052 [#3 sell 0.10 EURUSD at 1.36052]
2015.04.15 03:37:19.308 Core 1 2014.01.15 00:00:00 TesterToDate: work restored at 2014.01.15 00:00:00
2015.04.15 03:37:19.308 Core 1 2014.01.15 00:00:00 instant buy 0.10 EURUSD at 1.36737 sl: 1.36637 tp: 1.36837 (1.36728 / 1.36737 / 1.36728)
2015.04.15 03:37:19.308 Core 1 2014.01.15 00:00:00 deal #4 buy 0.10 EURUSD at 1.36737 done (based on order #4)
2015.04.15 03:37:19.308 Core 1 2014.01.15 00:00:00 deal performed [#4 buy 0.10 EURUSD at 1.36737]
2015.04.15 03:37:19.308 Core 1 2014.01.15 00:00:00 order performed buy 0.10 at 1.36737 [#4 buy 0.10 EURUSD at 1.36737]
2015.04.15 03:37:19.308 Core 1 2014.01.15 00:00:00 TesterToDate: next launch scheduled to 2014.01.22 00:00:00 (pause = 604800 seconds)...
Убил несколько часов на исследования, и понял, в чем ошибся.
Действительно, если "полезное" время программы значительно меньше времени, требуемого на проход пустых тиков, то эта функция даст ускорение. Ровно в столько раз, в сколько "полезное" время меньше "бесполезного".
По прежнему считаю, что таких задач очень немного (примера так и не увидел ;)), но признаю, что они есть.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Рациональные приемы (предложения) ускорения оптимизатора
zaskok, 2015.04.07 19:23
Если повторить, то есть очень много ТС, которые знают, когда они точно никаких торговых сигналов получать не будут. Например, ночные скальперы, так любимые Привалом. Они не получат никаких входных сигналов днем по определению. И бары пропускать или тики - неважно. Главное, чтобы они именно пропускались тогда, когда это разумно делать: автор ТС знает и вставляет это условие в свою ТС.
Советник с применением программного пропуска тиков в прицепе (для истории). Работает так:
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Рациональные приемы (предложения) ускорения оптимизатора
zaskok, 2015.04.10 12:00
OnTimer имеет смысл использовать в данном случае, если OnTick отсутствует напрочь. Но это не всегда возможно. Более того, если присутствует только OnTimer, то тики не пропускаются до следующего OnTimer, как могло бы подуматься.Что-то не получается у меня донести свои мысли )
1. Зачем пересчитывать историю?
Каждый бар нужно посчитать один раз, а рассчитанные значения нужно сохранить в индикаторные буферы, массивы или файл. Потом нужно только читать эти значения и, например, находить максимальное из них за последние Х баров.
Вроде дошло. Оптимизировать код в 2 приёма. Для эксперта сначала прогнать код для записи истории скажем в двухмерный массив histori [статистика, бары]. Затем оптимизировать код на том же интервале но уже не пересчитывая историю на каждом баре и прогоне а читать значения из массива. Спасибо!
--------------------------------------------------------------
zaskok :
" Если повторить, то есть очень много ТС, которые знают, когда они точно никаких торговых сигналов получать не будут. Например, ночные скальперы, так любимые Привалом. Они не получат никаких входных сигналов днем по определению. И бары пропускать или тики - неважно. Главное, чтобы они именно пропускались тогда, когда это разумно делать: автор ТС знает и вставляет это условие в свою ТС."
----------------------------------------------------------------
Недавно Привал, неправильно меня поняв, предложил мне в насмешку, торговать по звёздам. А что. Шутки шутками но не стоит пренебрегать практикой, которой десятки тысяч лет. Хотя бы исследования провести. И Ваша замечательная функция здесь бы пригодилась.
Было бы интересно обсудить как раз вот такие вот исследования.
Недавно была ветка, где предлагалось разделять систему на бай и селл, и оптимизировать параметры отдельно. Я как раз предложил делить на дни, часы, или сессиии, и подбирать параметры для каждой сессии отдельно.
Появился вопрос, насколько это рационально, и не подгонит ли это стратегию под историю еще плотнее. Интересно было бы попробовать на примере конкретной стратегии.
Было бы интересно обсудить как раз вот такие вот исследования.
Недавно была ветка, где предлагалось разделять систему на бай и селл, и оптимизировать параметры отдельно. Я как раз предложил делить на дни, часы, или сессиии, и подбирать параметры для каждой сессии отдельно.
Появился вопрос, насколько это рационально, и не подгонит ли это стратегию под историю еще плотнее. Интересно было бы попробовать на примере конкретной стратегии.
Хотя, если пытаться аргументировать, то подобный подход сложно объяснить. Но опять же, существует и применяется на практике иногда довольно успешно.
Что же касатеся классификации по временным интервалам. То здесь впереди планеты всей (по популярности) несколько часов до и после "полуночи" (европейской). Исследования показывают, что в это время относительно слабая волатильность, и при низких спредах и использовании лимитных приказов можно выжать неплохой по стабильности профит.
Такие ТС есть даже в Сигналах, но ссылок по непонятным соображениям привести не могу.
Что же касается подгона, то безусловно полностью нерабочую ТС на МАшках можно оптимизировать для каждого часа суток и получить результат разительно лучше, чем при оптимизации сразу на 24-х часах. Но этот вид подгонки сразу выявляется, как и другие: вне оптимизации будет виден облом.
На своих рабочих тех же ночниках было мало смысла 3-8 часов торговли разбивать на несколько и оптимизировать отдельно. Там явно прослеживалась попытка подгона, нежели подстройки под реальные изменения рынка в этих кусках времени.
Часто применяется практика, когда робот оптимизируется от более широкого интервала внутрь его границ - сужение. При этом при сужении получается рост профитфактора, мат.ожидания и прочих сладких показателей. Ну и чтобы не париться с выбором, в таких случаях запускают сборную солянку из таких "разных" ТС - с различными входными параметрами. Получается, что одни параметры вытягивают другие и наоборот. Диверсификация ТС, которую яростно не признает теоретик торговли Ренат.
Но все это оффтоп, TesterToDate востребована - здесь уже обоснования прозвучали. Не будет в MQL-тестере, так будет в других конкурентных решениях - закон рынка. А пока странно выходит, пишут все на C++, гордятся скоростными показателями платформы и тестера, в частности, а логичную и простую вещь ускорения вычислений игнорируют.
Ну и расчеты на каждом проходе в оптимизаторе того же коэффициента Шарпа - глупость несусветная. Может, одумаются.
ЗЫ В качестве продолжения оффтопа, полезно использовать подобный анализ. Можно свое или сразу на бук отправлять из тестера или еше лучше (инсрументарий анализа гораздо богаче) на блю.