Что значит не те данные?
Мы многократно описывали волновой алгоритм моделирования цен внутри бара для MetaTrader 3.
И потом, тестироваться на недельных графиках - это почти утопия если вдруг кто то захочет сделать тестирование идеальным (с точностью, близкой до минуток или 5ти минуток). Объяснить просто - данных таких просто нет или их размер просто чудовищен (попробуйте для примера посчитать сколько нужно пусть даже M5 за 10 лет, а потом посчитайте тоже самое для всех инструментов что есть в сервере, а потом подумайте о технической стороне). Встречная заявка: "брокер/разработчик _должен_ мне дать любую историю любой глубины - я требую!" отвергается.
В MT4 мы пошли по пути более точного моделирования баров путем использования данных более меньших периодов в качестве опорных точек. Именно опорных точек, а движения между опорными точками все равно будут моделироваться.
Пример:
1) тестируемся на дневках за 10 лет (260 баров в год * 10 лет = 2600 баров, совсем мало),
2) желательная точность:
а) потиковая - невозможна
б) M1 - практически невозможна (1440 баров в сутки * 260 рабочих дней * 10 лет = 3'744'000 баров
более 3х миллионов баров, что в байтах будет где-то 40 байт на бар *3744000 = 150Mb
ни один брокер не согласится у себя держать такую историю - они же не сумашедшие,
в MetaTrader Server 4 по умолчанию используется хранение около 16384 баров на каждый график
в) M5 - тоже почти невозможно, всего в 5 раз меньше места чем для M1
3) так что будем делать? на основе данных более низких периодов (H4, H1, M30 и тд) строим насколько можно детальные опорные точки для более точного тестирования дневного графика. Ну а там, где данных нет, идет стандартным волновым алгоритмом как и в МТ3. В отчете указываем - где началось более качественное моделирование.
В любом случае, тестирование слишком больших (больше Daily) периодов - это безумие. Результаты настолько недостоверны, что им просто доверять нельзя. Это как попытка выдать прогноз на год вперед. Прогноз на 1 день - еще куда ни шло. И проблема тут не в MetaTrader.
Мы многократно описывали волновой алгоритм моделирования цен внутри бара для MetaTrader 3.
И потом, тестироваться на недельных графиках - это почти утопия если вдруг кто то захочет сделать тестирование идеальным (с точностью, близкой до минуток или 5ти минуток). Объяснить просто - данных таких просто нет или их размер просто чудовищен (попробуйте для примера посчитать сколько нужно пусть даже M5 за 10 лет, а потом посчитайте тоже самое для всех инструментов что есть в сервере, а потом подумайте о технической стороне). Встречная заявка: "брокер/разработчик _должен_ мне дать любую историю любой глубины - я требую!" отвергается.
В MT4 мы пошли по пути более точного моделирования баров путем использования данных более меньших периодов в качестве опорных точек. Именно опорных точек, а движения между опорными точками все равно будут моделироваться.
Пример:
1) тестируемся на дневках за 10 лет (260 баров в год * 10 лет = 2600 баров, совсем мало),
2) желательная точность:
а) потиковая - невозможна
б) M1 - практически невозможна (1440 баров в сутки * 260 рабочих дней * 10 лет = 3'744'000 баров
более 3х миллионов баров, что в байтах будет где-то 40 байт на бар *3744000 = 150Mb
ни один брокер не согласится у себя держать такую историю - они же не сумашедшие,
в MetaTrader Server 4 по умолчанию используется хранение около 16384 баров на каждый график
в) M5 - тоже почти невозможно, всего в 5 раз меньше места чем для M1
3) так что будем делать? на основе данных более низких периодов (H4, H1, M30 и тд) строим насколько можно детальные опорные точки для более точного тестирования дневного графика. Ну а там, где данных нет, идет стандартным волновым алгоритмом как и в МТ3. В отчете указываем - где началось более качественное моделирование.
В любом случае, тестирование слишком больших (больше Daily) периодов - это безумие. Результаты настолько недостоверны, что им просто доверять нельзя. Это как попытка выдать прогноз на год вперед. Прогноз на 1 день - еще куда ни шло. И проблема тут не в MetaTrader.
а в чем проблева , при использовании тестирования на недельных данных загружать в качестве опорных точек дневки , часовки , пятиминутки ?По-моему , можно сделать !Или в чем я неправ. если для часовок сделали !?
Мы будем использовать опорные точки как я и сказал.
Теперь о том, в чем Вы неправы:
волатильность на недельках (а тем более на месячны барах) такова, что любая мелочь в моделировании (пусть даже и с опорными точками) выльется в большие погрешности. Настолько большие погрешности, что небольшая подгонка (даже непреднамеренная) эксперта может показать супер прибыльность. Вот после такого непонимания и появляются вопросы: "В предыдущих системах был такой баг ,что если тестить (например на недельных барах) эксперта ....".
Мы будем признательны Вам, если Вы потратите пару недель на раздумья и оценку возможностей, а потом предложите рабочий и реализуемый вариант тестирования без гарантии наличия полной потиковой или поминутной истории.
Теперь о том, в чем Вы неправы:
волатильность на недельках (а тем более на месячны барах) такова, что любая мелочь в моделировании (пусть даже и с опорными точками) выльется в большие погрешности. Настолько большие погрешности, что небольшая подгонка (даже непреднамеренная) эксперта может показать супер прибыльность. Вот после такого непонимания и появляются вопросы: "В предыдущих системах был такой баг ,что если тестить (например на недельных барах) эксперта ....".
Мы будем признательны Вам, если Вы потратите пару недель на раздумья и оценку возможностей, а потом предложите рабочий и реализуемый вариант тестирования без гарантии наличия полной потиковой или поминутной истории.
Проблема: тестовый терминал использует моделированные свечи, как следствие, несоответствие результатов тестирования и реальной торговли
Решение: при переходе к тестированию моделированные свечи должны заменяться реальными (тиковыми) свечами.
Реализация: тиковые свечи скачиваються офф-лайн с вашего FTP-сервера (НЕ с сервера брокера) и сохраняются отдельно от моделированных свечей. При тестировании, эксперту поставляеться поток тиковых данных из которых формируются свечи ЛЮБОГО периода от M1 и выше). Графическое представление результатов базируеться на моделированных свечах и остаеться без изменений.
Вывод: все, что надо сделать - это перестроить работу тестора с моделированных свечей на реальные.
Позволю одно предложение (заранее прошу прощение за несоответствие терминологии).
Создайте отдельный тестовый терминал, который будет В ТОЧНОСТИ повторять ход реальной торговли на тиковых данных и работать офф-лайн (если я правильно понял, то именно на тиковых данных, формирующих текущую свечу и работают эксперты). На этом терминале и можно будет производить тестирование на истории, но на реальной истории, как если бы производилась реальная торговля. Думаю, что тиковые данные
у Вас сохраняються на сервере или на серверах финансовых компаний - поставщиков услуг. По моим подсчетам по одному инструменту за 10 лет объем тиковых данных не превышает 200Мб (для FTP-Сервера это не объем)
Преимущества:
- нет проблем с трафиком (тиковые данные загружаються с тестового сервера офф-лайн)
- тиковые данные могут храниться в сжатом виде и/или в относительном изменении (из этих данных тестовый терминал формирует тиковые данные, на которых и будет тестироваться эксперт)
- при торговле на учебном и реальном счетах все остаеться без изменений
- моделирование свечей можно будет вообще убрать, чем еще повысить скорость работы основного терминала и уменьшить трафик, т.к. все свечи можно будет хранить в формате OHLC (без "наполнения", ведь на этих данных не будет производиться тестирование)
- лозунг "вы тестируете - как торгуете" будет на 100% реализован
- закончиться эпопея с моделированием свечей
- трейдеры получат инструмент для реального тестирования своих экспертов.
Кстати, в тестовый терминал можно будет встроить модуль оптимизации и создать на его базе
симмулятора работы на форексе, с возможностью управлять скоростью прихода котировок от пошагового (с отладкой эксперта) до ускоренного (ограниченного лишь возможностями железа компа).
Решение: при переходе к тестированию моделированные свечи должны заменяться реальными (тиковыми) свечами.
Реализация: тиковые свечи скачиваються офф-лайн с вашего FTP-сервера (НЕ с сервера брокера) и сохраняются отдельно от моделированных свечей. При тестировании, эксперту поставляеться поток тиковых данных из которых формируются свечи ЛЮБОГО периода от M1 и выше). Графическое представление результатов базируеться на моделированных свечах и остаеться без изменений.
Вывод: все, что надо сделать - это перестроить работу тестора с моделированных свечей на реальные.
Позволю одно предложение (заранее прошу прощение за несоответствие терминологии).
Создайте отдельный тестовый терминал, который будет В ТОЧНОСТИ повторять ход реальной торговли на тиковых данных и работать офф-лайн (если я правильно понял, то именно на тиковых данных, формирующих текущую свечу и работают эксперты). На этом терминале и можно будет производить тестирование на истории, но на реальной истории, как если бы производилась реальная торговля. Думаю, что тиковые данные
у Вас сохраняються на сервере или на серверах финансовых компаний - поставщиков услуг. По моим подсчетам по одному инструменту за 10 лет объем тиковых данных не превышает 200Мб (для FTP-Сервера это не объем)
Преимущества:
- нет проблем с трафиком (тиковые данные загружаються с тестового сервера офф-лайн)
- тиковые данные могут храниться в сжатом виде и/или в относительном изменении (из этих данных тестовый терминал формирует тиковые данные, на которых и будет тестироваться эксперт)
- при торговле на учебном и реальном счетах все остаеться без изменений
- моделирование свечей можно будет вообще убрать, чем еще повысить скорость работы основного терминала и уменьшить трафик, т.к. все свечи можно будет хранить в формате OHLC (без "наполнения", ведь на этих данных не будет производиться тестирование)
- лозунг "вы тестируете - как торгуете" будет на 100% реализован
- закончиться эпопея с моделированием свечей
- трейдеры получат инструмент для реального тестирования своих экспертов.
Кстати, в тестовый терминал можно будет встроить модуль оптимизации и создать на его базе
симмулятора работы на форексе, с возможностью управлять скоростью прихода котировок от пошагового (с отладкой эксперта) до ускоренного (ограниченного лишь возможностями железа компа).
Давайте посчитаем, на каждый тик (bid/ask + время = не меньше 12 байт)
в сутки примерно 20000-25000 тиков, в году рабочих дней (52 недели * 5) = 260 дней
в году 20000 * 260 = 5 млн 200 тысяч тиков
за 10 лет = 52 млн тиков
в байтах = 52 000 000 * 12 = 624 000 000 байт, грубо 620Mb на один инструмент.
620 Mb только на один символ. возьмем 10 символов = 6 Gb
Тики сжимаются очень плохо, но раза в 2 можно ужать.
Теперь отмасштабируйте это на десятки тысяч(а их даже больше) пользователей,
которые буду качать все это хозяйство...
Теперь вопрос - кому это нужно?
Держать такие объемы на своем сервере, забивать трафик и зачастую платить за него.
Другое дело, что теперь в MT4 можно импортировать себе например M5 или даже M1 за несколько лет, а потом тестироваться с использованием этих данных в качестве опорных. Качество и достоверность тестирования сразу же повышаются. Опорные точки из мелкие периодов позволяются точнее моделировать развитие более крупных баров.
в сутки примерно 20000-25000 тиков, в году рабочих дней (52 недели * 5) = 260 дней
в году 20000 * 260 = 5 млн 200 тысяч тиков
за 10 лет = 52 млн тиков
в байтах = 52 000 000 * 12 = 624 000 000 байт, грубо 620Mb на один инструмент.
620 Mb только на один символ. возьмем 10 символов = 6 Gb
Тики сжимаются очень плохо, но раза в 2 можно ужать.
Теперь отмасштабируйте это на десятки тысяч(а их даже больше) пользователей,
которые буду качать все это хозяйство...
Теперь вопрос - кому это нужно?
Держать такие объемы на своем сервере, забивать трафик и зачастую платить за него.
Другое дело, что теперь в MT4 можно импортировать себе например M5 или даже M1 за несколько лет, а потом тестироваться с использованием этих данных в качестве опорных. Качество и достоверность тестирования сразу же повышаются. Опорные точки из мелкие периодов позволяются точнее моделировать развитие более крупных баров.
Вы все время уходите от ответа на главный СТРАТЕГИЧЕСКИЙ вопрос: хотите ли вы реализовать тестовый терминал в точности повторяющий реальный рынок (т.е. работающий на тиковых данных).
Все ТЕХНИЧЕСКИЕ проблемы решаемы.
Возможные решения, лежащие на поверхности:
- сохранять тиковые котировки в опорных точках полностью (например поминутно) и между опорными точками в виде относительного изменения цены и времени (как следствие сохранение объема минимум в 3 раза)
- распространение архивов котировок возьмут на себя форумы и частные лица (как это сейчас де-факто сложилось)
Окончательные замечания.
Тестовый терминал нужен не для оптимизации (нахождения единственно верного набора параметров), а для отсеивания неправильных стратегий и получения палитры набора параметров, при которых можно получать прибыль (определения стабильности стратегии). Тестирование же на моделированных свечах приводит к обратному результату - отсеиваються прибыльные стратегии, а неприбыльные кажутся прибыльными и теряется огромное количество времени и денег на то, чтобы понять это в реальной торговле. Правильный подход к тестированию требует ПРАВИЛЬНОГО инструмента для тестирования.
Все ТЕХНИЧЕСКИЕ проблемы решаемы.
Возможные решения, лежащие на поверхности:
- сохранять тиковые котировки в опорных точках полностью (например поминутно) и между опорными точками в виде относительного изменения цены и времени (как следствие сохранение объема минимум в 3 раза)
- распространение архивов котировок возьмут на себя форумы и частные лица (как это сейчас де-факто сложилось)
Окончательные замечания.
Тестовый терминал нужен не для оптимизации (нахождения единственно верного набора параметров), а для отсеивания неправильных стратегий и получения палитры набора параметров, при которых можно получать прибыль (определения стабильности стратегии). Тестирование же на моделированных свечах приводит к обратному результату - отсеиваються прибыльные стратегии, а неприбыльные кажутся прибыльными и теряется огромное количество времени и денег на то, чтобы понять это в реальной торговле. Правильный подход к тестированию требует ПРАВИЛЬНОГО инструмента для тестирования.
Вы все время уходите от ответа на главный СТРАТЕГИЧЕСКИЙ вопрос
Я пытаюсь мягко указать на технические проблемы, чтобы Вы сами оценили масштаб задачи.
Если мы сделаем чисто тиковое тестирование по предоставленной тиковой истории, то гарантия 99% что никто не сможет ей воспользоваться из-за отсутствия таких данных или необходимых знаний и умений. Теоретические расчеты, которые я привел, показывают объем необходимых данных. Я что то не видел вообще нигде публичного предоставления таких данных и за такой(как минимум сопоставимый) период.
Кстати, тут нас иногда просят пару лишних килобайт в сутки сэкономить (а у нас все итак очень экономно), а Вы подразумеваете - "гигабайты трафика? Да нет проблем." Если вдруг окажется, что для простого тестирования надо выкачать пару компакт дисков из инета, то участь нашего софта определена :-)
распространение архивов котировок возьмут на себя форумы и частные лица
(как это сейчас де-факто сложилось)
(как это сейчас де-факто сложилось)
Сомневаюсь, что через месяц у частных лиц останется желание поддерживать такой архив. Ежедневно закачивать и обновлять архивы - это время и деньги. Грубо говоря - это отдельная и сложная задача, требующая вложения денег. Масштаб серьезный. И такую задачу нельзя доверить частным лицам, которые через некоторое время плюнут на все и перестанут обновлять данные (ато и вообще все закроют).
Что же делать?
В МТ4 мы используем компромиссное решение - моделирование с использование опорных точек, что кардинально улучшает результаты тестирования по сравнению с МТ3. Почему такое решение? Потому что оно будет работать у всех (именно у всех!), автоматически и не будет требовать наличия потиковой истории.
Одна из проблем базовой тиковой истории:
Брокер использует свои котировки, свои таймзоны, свои спреды, а базовая(эталонная) тиковая история не сходится с барами, взятыми от брокера. Кто виноват? Похоже что MetaQuotes Software, у которой "данные не сходятся".
Лев. Зачем Вы говорите, что мы уходим от ответа? Я позволю себе процитировать свой ответ Вам от 25 ноября 2004 года на тему "Re: Re[4]: Открытый проект: "Тестовый терминал""
===
Тема закрыта. У нас сейчас совсем нет времени её обсуждать.
Возможно, мы вернёмся к этой теме позже (не ранее, чем через полгода).
Но для этого во-первых, Вы должны строго доказать преимущества
тиковых данных перед смоделированными именно для тестирования.
Во-вторых, после того, как мы предложим моделирование на основании
данных более мелких периодов, аналогичные доказательства должны
поступить ещё от нескольких десятков человек. Тогда мы начнём
рассматривать эту идею. В противном случае реальное потиковое
тестирование будет считаться экзотикой. Ради одного-двух
человек мы не станем вносить серьёзные изменения в наши программы.
===
Я смею надеяться на то, что мой ответ был чётким: "В ближайшее время - однозначно нет.
В будущем - скорее всего нет"
===
Тема закрыта. У нас сейчас совсем нет времени её обсуждать.
Возможно, мы вернёмся к этой теме позже (не ранее, чем через полгода).
Но для этого во-первых, Вы должны строго доказать преимущества
тиковых данных перед смоделированными именно для тестирования.
Во-вторых, после того, как мы предложим моделирование на основании
данных более мелких периодов, аналогичные доказательства должны
поступить ещё от нескольких десятков человек. Тогда мы начнём
рассматривать эту идею. В противном случае реальное потиковое
тестирование будет считаться экзотикой. Ради одного-двух
человек мы не станем вносить серьёзные изменения в наши программы.
===
Я смею надеяться на то, что мой ответ был чётким: "В ближайшее время - однозначно нет.
В будущем - скорее всего нет"
Мужики, вы знаете сколько человеческих ресурсов отсутствие адекватного тестирования съедает у каждого более-менее обычного трейдера, - поиск в инете, нарытие какихто баз, тест, потом оказывается что базы кривые, своя доработка, чутьли не ручным вводом,и все заканчивается примерно одним - тест в реале по полгода.. полгода потестил-посмотрел, день подумал-исправил, еще полгода потестил еще день подумал..
да рассылайте на дисках эти котировки по 100$ за диск, если инет проблема..
а теперь еще кроме наработанной информации придется изучать ваши нововведения, с неизвестносколькипроцентной гарантией того что оно будет работать... на лицо упрощенный подход к выходу продукта с закрытием глаз на ОСНОВНУЮ проблему. так понимаю самих вас это мало касается, по этому мнение вы менять врятли будете...
да рассылайте на дисках эти котировки по 100$ за диск, если инет проблема..
а теперь еще кроме наработанной информации придется изучать ваши нововведения, с неизвестносколькипроцентной гарантией того что оно будет работать... на лицо упрощенный подход к выходу продукта с закрытием глаз на ОСНОВНУЮ проблему. так понимаю самих вас это мало касается, по этому мнение вы менять врятли будете...
DVDima, проблему знаем, многократно обсуждали.
Подумайте, пожалуйста, на несколько шагов вперед после первого желания - "хочу точную детальную историю". То есть, отойдите от первой мысли "мне нужны точные данные и точка!", подумайте о реализации, о потенциальных проблемах, о том как все это отмасштабировать на огромную массу пользователей, об трафике, об удобстве пользования, об необходимой квалификации пользователей и о затратах.
К сожалению окажется, что приложив титанические усилия и набрав огромную историю, Вы (а скорее всего мы как разработчики) вляпаетесь в 5 новых суперсерьезных проблем.
Фраза "если инет проблема" дает повод думать, что Вы не осознаете серьезность объемов. Да и вариант "диски с историей за 100$" абсолютно нерабочий. Кто-то будет напрягаться, а после первого диска хорошо известные "друзья" начнут все это продавать по 50$.
Мы постараемся представить полный отчет с примерами и детальными объяснениями как работает новый механизм моделирования и каковы его погрешности.
Подумайте, пожалуйста, на несколько шагов вперед после первого желания - "хочу точную детальную историю". То есть, отойдите от первой мысли "мне нужны точные данные и точка!", подумайте о реализации, о потенциальных проблемах, о том как все это отмасштабировать на огромную массу пользователей, об трафике, об удобстве пользования, об необходимой квалификации пользователей и о затратах.
К сожалению окажется, что приложив титанические усилия и набрав огромную историю, Вы (а скорее всего мы как разработчики) вляпаетесь в 5 новых суперсерьезных проблем.
Фраза "если инет проблема" дает повод думать, что Вы не осознаете серьезность объемов. Да и вариант "диски с историей за 100$" абсолютно нерабочий. Кто-то будет напрягаться, а после первого диска хорошо известные "друзья" начнут все это продавать по 50$.
изучать ваши нововведения, с неизвестносколькипроцентной гарантией
Мы постараемся представить полный отчет с примерами и детальными объяснениями как работает новый механизм моделирования и каковы его погрешности.
![MQL5 - Язык торговых стратегий для клиентского терминала MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Можно ли сейчас на истории работать с текущим баром ?
Как он грузит данные (например , среда текущей недели на недельном баре )?
Если такого пока нельзя делать , то когда появится программа , гда можно будет без проблем протестить на истории эксперта , работающего с текущим баром ?