Составной частью алготрейлдинга является создание прибыльных торговых стратегий, дизайн и математическое содержание которых части бывает достаточно сложным. И прежде чем их кодить на S# важно исследовать лежащие в основе стратегии идеи на предмет их пригодности к реальной жизни. Для этого чаще всего используются внешние математические/статистические пакеты - Matlab, R и иные. Однако существенной проблемой при реальных исследованиях, например проведении WalkForward тестирования, является оперативная подгрузка необходимых данных в такие пакеты по ценных бумагам российского рынка. Для решения данной пробемы было создано простое API SDataExtract, которое позволяет работать с данными в хранилище S#.Data из внешних приложений, поддерживающих интеграцию с .NET API расположено в общем репозитарии https://github.com/lebedevsrg/SDataExtract/
评论 (8)
登录 或 创建账户, 登录或注册以发表评论
В настоящее время API способна предоставить в внешнее приложение 2 вида данных: список инструментов в хранилище и торговые данные по сохраненным данным (HLOCV) за указаный пользователем промежуток времени и по указанному тайм-фрейму
<u>1. Получение списка бумаг</u> Происходит путем первичного вызова функции GetList() и последующим считыванием массива строк из переменной SecArray. Далее полученный в внешнем приложении массив строк необходимо привести к внутреннему формату строковых массивов.
<u>2. Получение торговых данных </u> Шаг-1: вначале необходимо задать 5 переменных: Code - код инструмента из хралища S#.Data, DType - состав необходимых данных
Для тестирования решение содержит два дополнительных проекта: WPFtest - проект для тестирования через простое приложение MTBtest - пустой проект, содержащий в качестве ресурсов две m-функции для получения данных в среде Matlab
Можно для непосвященных? А в чем трабла то работа с хранилищем из МатЛаб, R и Python?
Могу сказать только за Matlab: прямая работа с компонентами S#.API там конечно возможна, но в реальности оболочка NET.invokeGenericMethod подглючивает и часто его не дает результатов при обращении к NET объектам, которые должны быть и которые нормально получаются при работе внутри проектов VisualStudio. Кстати, наткнулся на это еще в 2013 , 3 года прошло, но пробелема с NET.invokeGenericMethod так и остается)) Поэтому получается, что в конечном итоге проше завернуть всю работу с S#.API в промежуточную библиотеку, оставив на стороне пакета только вызов простейщих функций и конечную конвертацию из NET в свой внутренний формат.
Можно сохранять историю в CSV формат. Тогда и обращение к АПИ не нужно.
Про оболочку знаю, у нас же сам MatLab построен на оболочке.
Я вставлю свои 3 копейки - вызовы S#.API могут быть реализованы только через rClr библиотеку, но насколько она адекватно пашет - хз. Прямых же методов работы с базой S#.Data просто нет, насколько я понимаю. Т.е. если мне нужно, я не могу подключиться к S#.Data базе через ODBC или напрямую.
Гидра хранит данные как файлы. Обращаться через драйвера баз данных не нужно.
Конечно пост Rebelion насчет ODBC у S#.Data смахивает на детский лепет, но как известно устами младенца глаголет истина - с "потребительской" точки зрения системе S#.Data не хватает полноценного COM/API для раздачи данных во внешние приложения как локально, так и как по сети. В иделе конечно был бы еще и собтственый ODBC драйвер) При этом у S#.Data заявлен некий режим работы S#.DataServer но в чем он заключается нигде толком не описано, может быть сделаете на сайте статью по использоваию этого режима или хотя бы раздел в Справке?