anebotov
|
Date: 6/1/2010
Вся логика в роботе.
добавлять в робота название бумаги на которой он торгует, номер счета
и т.п. вещи считаю не верными (это кстати камень в огород s#). Даже
привязывать робота к таймфрейму нужно только в крайней необходимости.
WL позволяет оттестировать робота на многих бумагах / таймфреймах .
Сравнить несколько пар бумага-робот между собой. Сравнить по
нескольким параметрам, в удобной (часто графической) форме. Описывать
всё это в роботе считаю вредным. Робот должен уметь запускаться без
перекомпиляции на разных бумагах.
|
skzuev
|
Date: 6/1/2010
Ну тогда было бы логичным прикрутить к роботу внешние параметры ( файлы
конфигцрации, БД и т.п.) и управлять через них. Как мне кажется, читать из
файла конфигурации названия бумаги проще, чем прикручивать WL. Хотя я могу и
ошибаться.
С уважением,
Сергей Зуев
|
anebotov
|
Date: 6/1/2010
Сергей, опиши, как ты представляешь себе следующий процесс:
1) протестировать робота на 200 бумагах и пяти таймфреймах
2) оптимизировать его параметры на выбранных бумагах/таймфреймах
3) НЕ МЕНЯЯ РОБОТА запустить на бою на данных бумагах/таймфреймах
т.е. тебе в любом случае надо нечто управляющая роботом, некая
надстройка абстрагирующая робота от реальных названий бумаг и т.п..
Денис, спасибо, твои добавления в документ интересны. По поводу
редактора: WL позволяет запускать робота откомпелированного в студии.
Но на первом плане остается вопрос о судьбе стоимости/лицензии
продукта s#, написать адаптер под квик (опыт есть) займет у мена
столько же времени как и разбирательство с ITrader. КАКИЕ ПЛАНЫ У
ПРОДУКТА?
|
skzuev
|
Date: 6/1/2010
|
|
|
|
|
Я буду рассказывать в варианте AmiBroker'a, на WL у меня роботов нет :)
система реальная, ей сейчас пользуюсь.
Основную логику работы робота (входы/выходы+фильтры) делаем на Ami (там
Jscript подобный язык, вообщем терпимый). Получаем AFL файл с роботом.Робот
читает параметры из хранилища через COM интерфейс. Пишем на Jscript функцию,
которая через тот же COM дергает Ami, заставляя проводить бектест робота.
Один вызов робота для бектеста выглядит следующим образом:
main("RTS_01","SPFB.RTS","01.09.2009","30.12.2009",exportpath);
указываем код набора параметров, код инструмента, диапазон дат, путь для
вывода результатов. Результаты бектеста в CSV сливаем по вкусу в Excel или
MS SQL.
Оптимизация аналогично.
Мне удобнее за один раз гонять по одному инструменту.
Предположим, оптимизировали, протестировали и остались довольны
результатами.
Берем скрипт номер 2, ставим его на шедулер. Этот скрипт гоняет робота
похожим образом, но сбрасывает в файл вывод робота с последнего доступного
бара в режиме Explore (есть такой в Ami).
Из файла данные подтягиваются в QPILE (написано задолго до S#), где работает
исполнительный механизм, который ставит стопы, передвигает заявки и т.п.
Данные с финама и из квика грузятся в Ami через тот же Jscript.
Если Вы пишете с 0 и под WL, то сейчас конечно проще взять C# и делать на
нем. Всякие QPILE - отстой, я намучался с ним.
Про S# - библиотека отличная, автор молодец. Но не совсем корректно
требовать от него гарантий развития проекта и сохранения бесплатности. Это
все же результаты его труда, с которыми он может делать все, что захочет :))
Но S# плохо приспособлен для тех. анализа - нет там многих вещей,
естественных для Ami, WL и т.п.
Можно все это написать - но надо ли? Если хочется программировать - конечно,
лучше написать самому. Если хочется сделать рабочего робота - лучше еще раз
все взвесить.
С уважением,
Сергей Зуев
|