Виртуальное тестирование на реальном счете - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Пакет условно делится на следующие части:
1. БД. Зачем - понятно, я думаю
GenDB.sql - скрипт для генерации БД
2. Компоненты для записи в БД тиковых данных.
Включает в себя:
lr_ado.mq4 - советник. Вешается на символ, по которому надо писать тиковые данные в БД
fx_ado.mqh - файл заголовков функций DLL, используемых для записи в БД
fx_ado.dll - собственно DLL, пишущая в БД
3. Компоненты для эмуляции торговли.
et.mq4 - библиотека, подменяющая торговые функции - такие как OrderSend, OrderSymbol, OrderType и т.п. на, соответственно, _OrderSend, _OrderSymbol, _OrderType.
набор параметров в подмененных функциях идентичен исходным, кроме одного - первым параметром идет параметр trade, определяющий разрешена ли эксперту
реальная торговля (т.е. торговля с сервером ДЦ). Если параметр = false - торговля идет только в режиме эмуляции (на SQL сервер)
et.mqh - заголовок функций DLL для торговли
et_ado.dll - собственно DLL, раелизующуюя функции обмена данными с SQL сервером и частично - торговые функции
4. Дополнительные файлы
fx.udl - файл настроки доступа к SQL серверу. Должен лежать в корне на диске C:, пароль доступа на SQL сервер должен быть в нем сохранен. Используется всеми
другими компонентами для доступа к SQL серверу
test_et.mq4 - пример использования подмененных торговых функций.
Вызовы init_et(MAGICMA) перед использованием торговых функций обязателен, т.к. фактически он (в MAGICMA) задает номер виртуального (на SQL сервере)
счета. Вызов deinit() в настоящее время не делает ничего, но лучше ставить для совместимости - вдруг в будущем понядобится :)
wd.exe - простенький watchdog. Практически все функции пакета (записи тиков, торговые) ставят временную отметку о своем последнем вызове в специальную таблицу
на SQL сервере - dbo.WATCHDOG. wd.exe отслеживает, прошло ли с момента FACTIVE_TIME FDELTA секунд, и если прошло, то вызывает (ShellExecute) команду,
прописанную в FCOMMAND (прописывать надо руками прямо в таблицу). При этом запрещается повторный запуск FCOMMAND на FSTART_DELTA минут с момент FSTART_TIME.
Собственно, написал комплект для такого тестирования - библиотеку, DLL, БД (Firebird).
Идея думаю не нова, но реализаций я что-то пока нормальных (и не очень :) не нашел - подменяются функции типа OrderSend(..) на _OrderSend(bool trade=false,...)
и все остальные необходимые торговые функции.
Переменная trade собственно определяет, реально срабатывает функция или виртуально. Виртуальные срабатывания пишутся в БД для последующего анализа.
Для чего надо - думаю, понятно. Можно взять любого советника, поставить на реальный счет (условия на котором иногда здорово отличаются даже от демо-счета, я уж не говорю о тестере :)
с ЛЮБЫМ начальным балансом и смотреть как он сливается, но - виртуально :)
А в чём суть аналитического блока системы? Хорошо, мы увидели виртуально, как советник сливает депозит (точнее, не хорошо). Какие наши действия по анализу и устранению причин с помощью данных, собранных в SQL базе?
Собственно, написал комплект для такого тестирования - библиотеку, DLL, БД (Firebird).
Идея думаю не нова, но реализаций я что-то пока нормальных (и не очень :) не нашел - подменяются функции типа OrderSend(..) на _OrderSend(bool trade=false,...)
и все остальные необходимые торговые функции.
Переменная trade собственно определяет, реально срабатывает функция или виртуально. Виртуальные срабатывания пишутся в БД для последующего анализа.
Для чего надо - думаю, понятно. Можно взять любого советника, поставить на реальный счет (условия на котором иногда здорово отличаются даже от демо-счета, я уж не говорю о тестере :)
с ЛЮБЫМ начальным балансом и смотреть как он сливается, но - виртуально :)
А в чём суть аналитического блока системы? Хорошо, мы увидели виртуально, как советник сливает депозит (точнее, не хорошо). Какие наши действия по анализу и устранению причин с помощью данных, собранных в SQL базе?
Боюсь, что речи об аналитическом блоке тут вообще не было. Преполагается, что это все - инструмент для аналитического блока в голове пользующего. . А уж для чего и как :) Если серьезно - то для себя я в этом вижу в этом больше свободы для моделирования и тестирования, путем переноса большей части логики на свою сторону + работу на реальных данных, а не на том, что идет по демо-счету.
А вообще, господа.. Как показывает житейский опыт.. если вы не знаете, зачем это надо(?), то скорее всего так оно и есть :)
А какие Ваши действия по анализу и устранению причин после наблюдения виртуального слива на обычном демо счету? :)
Менять значения входных параметров и дотестировать конфигурацию. Но менять надо с умом, вот КАК подбирать - это вопрос, требующий автоматизации.
пакет переписан на MS SQL, ведет запись тиковых данных в БД, часть функций по отслеживанию статуса ордеров тоже перенесана в БД - типа StopLoss, TakeProfit.
Если есть желающие и имеющие возможность протестировать все это добро в реальных условиях - БЕЗВОЗМЕЗДНО (т.е. даром) дам все необходимое для установки..
Т.е. не совсем безвозмездно - за отчет о тестировании :)
Ссылку для скачивания сюда не дам, работать будем индивидуально.
Хотя ссылка выше на старый пакет и рабочая.. пока :)