Статьи об интеграции MetaTrader 5 с помощью языка MQL5

В этой шестой статье из серии о библиотеке Connexus мы сосредоточимся на полном HTTP-запросе, рассмотрев каждый компонент, из которого состоит запрос. Мы создадим класс, представляющий запрос в целом, который поможет нам объединить ранее созданные классы.

Обновляем панель управления торговлей (TradeManagementPanel), используемую в нашем советнике New_Admin_Panel. В новой версии будем использовать встроенные классы и получим более удобный интерфейс управления сделками. В частности, добавим кнопки для открытия позиций, а также элементы для управления открытыми сделками и отложенными ордерами. Кроме того, в панели будет встроенная система управления рисками, чтобы устанавливать значения стоп-лосса и тейк-профита непосредственно через ее интерфейс. В целом обновление улучшает организацию самого кода, что важно для таких больших программ, а также упрощает доступ к инструментам управления ордерами — в определенных моментах это будет сделать проще, чем через интерфейс терминала.

Неважно, какую программу SQL мы будем использовать: MySQL, SQL Server, SQLite, OpenSQL или другую. У всех есть что-то общее, а этот общий элемент — язык SQL. Даже если мы не собираемся использовать WorkBench, можно манипулировать или работать с базой данных непосредственно в MetaEditor или через MQL5 для выполнения действий в MetaTrader 5, но для этого вам понадобятся знания SQL. Итак, здесь мы выучим, как минимум, основы.

В данной статье мы рассмотрим, как решить некоторые проблемы и вопросы, возникающие при использовании кода, написанного на Python внутри других программ. А если говорить более конкретно, то мы покажем распространенную проблему, возникающую при использовании Excel в связке с MetaTrader 5, хотя для этого общения мы будем использовать Python. Однако у данной реализации есть небольшой недостаток. Это происходит не во всех, а только в некоторых конкретных случаях. Когда это происходит, необходимо понять причину. В сегодняшней статье мы начнем объяснять, как решить эту проблему.

В предыдущей статье мы рассмотрели пример реализации класса на MQL5 для обеспечения базовой поддержки. Его цель заключается именно в том, чтобы позволить хранить SQL-код в отдельном файле скрипта. Таким образом, нам не потребуется писать тот же SQL-код в виде строки внутри кода MQL5. Хотя данное решение функционально, в нём есть некоторые детали, которые мы можем и должны улучшить.

Исторические данные – вовсе не "мусор", а основа любого надежного рыночного анализа. В этой статье мы шаг за шагом пройдем путь от сбора истории до ее использования для обучения прогностической модели, а затем – до развертывания этой модели для прогнозирования цен в реальном времени. Давайте разберемся, как это сделать.

В настоящей статье мы продолжаем разработку библиотеки Connexus. В настоящей главе мы создаем класс CHttpClient, отвечающий за отправку запроса и получение ордера. Мы также рассматриваем концепцию моков (mocks), отделяя библиотеку от функции WebRequest, что обеспечивает большую гибкость для пользователей.

Ознакомьтесь с пошаговым руководством, которое упрощает извлечение, преобразование и организацию свечных данных из ответов API в среде MQL5. Это руководство отлично подходит новичкам, которые хотят улучшить навыки программирования и научиться эффективно управлять рыночными данными.

В сегодняшней статье мы начнём изучать использование SQL в коде MQL5. Мы также рассмотрим, как можно создать базу данных. Или, точнее, как создать файл базы данных в SQLite, используя ресурсы или процедуры, включенные в язык MQL5. Мы также увидим, как создать таблицу, а затем как установить связь между таблицами с помощью первичного и внешнего ключей. Всё это, опять же, с использованием MQL5. Мы увидим, как легко создать код, который в будущем можно будет перенести в другие реализации SQL, используя класс, помогающий скрыть созданную реализацию. И, что самое важное, мы увидим, что в разные моменты мы можем столкнуться с риском того, что при использовании SQL что-то пойдет не так. Это происходит так, потому что в коде MQL5 SQL-код всегда будет помещаться внутри строки.

В последней части этой серии мы выходим за рамки отдельных методов машинного обучения и переходим к проблеме “исследовательского хаоса”, с которым сталкиваются многие количественные трейдеры. Эта статья посвящена переходу от разрозненных экспериментов в Jupyter Notebook к продуманному пайплайну промышленного уровня, обеспечивающему воспроизводимость, отслеживаемость и эффективность.

Как мы объясняли в первой статье о SQL, нет смысла тратить время на программирование процедур для выполнения того, что уже включено в SQL. Однако, если не знать самых основ, вы не сможете ничего сделать с помощью SQL, чтобы воспользоваться всеми преимуществами, которые предлагает этот инструмент. Поэтому в данной статье мы рассмотрим, как выполнять основные задачи в базах данных.

GridSearchCV и RandomizedSearchCV имеют фундаментальное ограничение в финансовом ML: каждое испытание независимо, поэтому качество поиска не улучшается с ростом вычислительного бюджета. В этой статье Optuna — с использованием Tree-structured Parzen Estimator — интегрируется с кросс-валидацией PurgedKFold, ранней остановкой HyperbandPruner и соглашением о двух типах весов, которое разделяет веса обучения и веса оценки. В результате получается система из пяти компонентов: целевая функция с отсечением на уровне фолдов, слой преобразования/подстановки параметров, совместно оптимизирующий схему взвешивания и гиперпараметры модели, финансово откалиброванное отсечение, возобновляемый оркестратор на базе SQLite и конвертер в формат scikit-learn cv_results_. В статье также проводится четкое разграничение — на основе Тимоти Мастерса — между статистическими целями, где направленный поиск полезен, и финансовыми целями, где он вреден.

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

В предыдущей статье мы завершили необходимое введение в тему SQL. И то, что мы хотели показать и объяснить о SQL, на мой взгляд, мы разъяснили должным образом. Так было сделано для того, чтобы каждый, кто придет посмотреть на строящуюся систему репликации/моделирования, мог хотя бы получить представление о том, что там может происходить. Дело в том, что нет смысла программировать вещи, с которыми SQL справляется идеально.

В предыдущей статье я показал, как следовало действовать для добавления механизма запросов. Это было нужно для того, чтобы внутри кода MQL5 вы могли полноценно использовать SQL и получать результаты при выполнении команды SQL SELECT FROM. Но осталось рассказать последнюю функцию, которую нам необходимо реализовать. Это функция DatabaseReadBind. И, поскольку для правильного понимания требуется чуть более развернутое объяснение, было решено сделать это не в той предыдущей статье, а в сегодняшней. Итак, поскольку тема будет довольно объемной, перейдём сразу к следующему разделу.

В этой статье мы покажем, как визуализировать свечные данные, полученные с помощью функции WebRequest и API, в свечном формате. Мы будем использовать язык MQL5, чтобы считывать свечные данные из CSV-файла и отображать их на графике в виде пользовательских свечей, поскольку индикаторы не могут напрямую использовать функцию WebRequest.

Хотя многие считают, что мы можем без проблем встраивать SQL-код в другой код, обычно это не так. Причина заключается в том, что SQL-код включается в исполняемый файл в виде строки. И тот факт, что SQL-код внедряется в виде строки, хотя и не вызывает проблем в небольших фрагментах, в итоге это может создать нам немало головной боли.