Влияние исходных исторических данных на скорость и точность тестирования. - страница 2

Проще скачать и посмотреть... 

Простое предложение для разработчиков, как MT4-тестер сделать максимально точным при условии, что у пользователя имеется M1_Ask-история.

Надо всего лишь добавить в тестер флажок: использовать Volume-поле (в OHLCV), как данные о Low_Ask цене в режиме "по ценам открытия".

В таком случае любому желающему добиться практически максимальной точности на M1-данных "по ценам открытия" понадобиться всего лишь записать значение Low_Ask-цен в Volume-поле OHLCV.

А разработчикам эта добавка потребует внести только две примитивные строчки в свой тестер:

Было (грубо):

PriceLow = Low[1] + Spread;

if (BuyLimit <= PriceLow)
  ....

Станет:

if (FlagAsk)
  PriceLow = Volume[1];
else
  PriceLow = Low[1] + Spread;

if (BuyLimit <= PriceLow)
  ....

Т.е. можно использовать никчемные чаще всего double-данные тикового объема, как уже готовое поле для Ask-истории перед тестированием.

Конечно, поле тикового объема в редких случаях используется ТС в тестере - например, туда пишется реальный проторгованный объем. Но на 99% задач тестирования/оптимизации реализация предложения выше дало бы так важный результат точного тестирования без каких-либо затруднений.

Улучшить аналогично режим "по всем тикам" можно также, но это потребует от разработчиков написания более, чем двух строк. Поэтому упускаем.

P.S. Конечно, сейчас при некорректных значениях поля Volume бары не отображаются. Можно снять это ограничение, как рудимент.

P.P.S. Для наивысшей точности есть один нюанс с Open-ценами OHLCV, но, объясняя его, сделается ложное впечатление о сложности данного предложения. Поэтому рассказ о нем упускаем. Однако, по ссылке выше этот нюанс учтен.

Простое предложение для разработчиков, как MT5-тестер сделать максимально точным при условии, что у пользователя даже нет M1_Ask-истории.

Переписать легкий алгоритм формирования поля Spread бара.

Было:

Spread = Max(Spread, CurrentSpread);

Станет:

Spread = Low_Ask - Low_Bid; // во время формирования бара вычислятся не только Low_Bid, но и Low_Ask. В поле Spread пишется их разница. Low_Ask напрямую не запоминается.
// Spread = Max(Low_Ask - Low_Bid, 0); // вариант, если не хочется снимать ограничение отрицательного спреда (в агрегаторах иногда бывает моментальный/текущий спред в отрицательной зоне)

Такая реализация позволит не менять совершенно тестер "по ценам открытия" и структуру исторических данных. При этом достигнется точность модели HigBid+LowAsk (наивысшая для истории в виде таймфреймов/баров).

P.S.

Для MT4 аналогично в поле Volume хранить не Low_Ask, а разность Low_Ask - Low_Bid. Это позволить оставить текущее ограничение целого значения для поля Volume.

Важность наличия фильтра истории.

Грамотный тестер всегда имеет возможности работы с кастомной историей и кастомными символами.

Как правило, на плечи алготрейдера ложится написание фильтра для создания такой кастомной истории. Причина создания фильтра всегда проста - повысить на порядки скорость тестирования/оптимизации без существенного ухудшения качества результатов тестирования.

Т.е. трейдер перед запуском своей ТС в тестере/оптимизаторе обязан создать кастомную историю на основе своего фильтра.

Автоматическое нахождение оптимального фильтра истории.

В очень грамотных тестерах предлагаются также штатные (можно и кастомные) фильтры со своими настройками. И, главное, имеется механизм автоматического нахождения оптимального фильтра истории. Суть его проста:

• ставятся диапазоны входных параметров фильтра.
• запускается оптимизация по этим параметрам. Т.е. на каждом проходе создается кастомная истории с помощью фильтра, соответствующего данному проходу (набор входных значений фильтра) и затем прогоняется в тестере интересуемая ТС.
• На выходе получается оптимизационная матрица, где в каждой строке набор: фильтр, время тестирования по кастомной истории этого фильтра, Profit (или другой критерий) ТС на этой истории.
• Далее по оптимальному критерию выбора фильтра из полученной матрицы берется наиболее подходящая строка (фильтр).
• Сами критерии оптимального фильтра доступны, как штатно, так и могут быть написаны - кастомный критерий оптимального фильтра.
• На выходе имеем фильтр с оптимальным соотношением качества тестирования для конкретной ТС и временем ее тестирования.

Когда такой фильтр автоматически найден, создается на его основе кастомная история для непосредственного тестирования/оптимизации ТС.

Пример.

Представим, что вы хотите оптимизировать свою ТС. При этом она довольно чувствительна к историческим данным. Оптимизировать ее на чистой тиковой истории - безумие (долго). Поэтому стоит вопрос фильтра. Например, если у вас плохой пинг - фильтруете тики сильнее, хороший - слабее. Но помимо такой простой логики фильтра, вы начинаете прореживать тики все сильнее и сильнее, где на каждом участке смотрите, насколько результат вашей ТС отличается от эталонного (без фильтра). Ну и замеряете время прогона после каждого прореживания.

Видите, что проредив, например, в 1000 раз тики, получаете отличие на 1% от эталонного. При этом скорость тестирования увеличивается, соответсвенно, в 1000 раз. Тогда либо останавливаетесь на выборе фильтра, либо дальше ищите золотую середину.

Вот как раз очень грамотный тестер поможет вам найти такую золотую середину автоматически. И вы сможете оптимизировать свою ТС максимально быстро (иногда на несколько порядков), почти без влияния на качество тестирования.

P.S.