Синхронизация mql5 и c++ реализаций классов. - страница 6
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Как правильно организовать синхронность с++ и mql5 реализаций одного и того же набора классов? Возможно, вопрос уже разбирался на форуме или в статьях, но не нашёл.
Не вижу никаких проблем. Оборачиваешь API терминала в свой виртуальный интерфейс, и дальше уже все действия совершаешь именно через этот интерфейс.
Если нужно перенести на другой терминал, платформу, ещё что-то - пишешь для нее реализацию этого виртуального интерфейса, всё остальное - начинает работать после перекомпиляции.
В чём проблема-то?
ROOT хорошо дружит с питоном, MQL - тоже. Может использовать питон как прослойку?
Тогда получается что вся торговая логика в питоне, поскольку из mql5 нельзя (простым способом) обратиться к питону. Но тогда получается что ROOT особо и не нужен, потому что в питоне всё и так уже есть - интерпретатор, графика, анализ данных.
Но идея торговать в питоне не особо привлекает. Поэтому идея в том, что советники на mql5, а ROOT - лишь как средство для отладки кусков mql5 кода со сложной логикой.
Вроде бы очевидно, что отладка в интерпретаторе намного удобнее. Например, всегда можно распечатать любую переменную без утыкивания кода принтами и постоянной перекомпиляции. В случае ROOT ещё можно построить каккие-нибудь графики или гистограммы для массивов и тд и тп.
Тогда получается что вся торговая логика в питоне, поскольку из mql5 нельзя (простым способом) обратиться к питону. Но тогда получается что ROOT особо и не нужен, потому что в питоне всё и так уже есть - интерпретатор, графика, анализ данных.
Но идея торговать в питоне не особо привлекает. Поэтому идея в том, что советники на mql5, а ROOT - лишь как средство для отладки кусков mql5 кода со сложной логикой.
Вроде бы очевидно, что отладка в интерпретаторе намного удобнее. Например, всегда можно распечатать любую переменную без утыкивания кода принтами и постоянной перекомпиляции. В случае ROOT ещё можно построить каккие-нибудь графики или гистограммы для массивов и тд и тп.
Не вижу никаких проблем. Оборачиваешь API терминала в свой виртуальный интерфейс, и дальше уже все действия совершаешь именно через этот интерфейс.
Если нужно перенести на другой терминал, платформу, ещё что-то - пишешь для нее реализацию этого виртуального интерфейса, всё остальное - начинает работать после перекомпиляции.
В чём проблема-то?
Который раз уже пишу, что нет идеи переноса в другую платформу (пока нет, по крайней мере). Так же нет идеи сопряжения МТ5 с какой-либо другой средой или платформой.
Есть идея создания более комфортной среды для отладки логики кода. ИМХО, такая среда должна быть а) интерпретатором, б) обладать языком максимально похожим на mql5, в) желательно обладать богатыми возможностями по анализу данными. По этим требованиям подходит ROOT. Остаётся "причесать" mql5 код, чтобы его куски можно было безболезнено перетаскивать из ME в ROOT и обратно. Нет никаких глобальных идей по переписыванию чего-либо.
Почему тогда R не использовать вместо ROOT-а? Вроде же сопоставимые вещи по части анализа и визуализации. И для R вроде есть прокладка от СанСаныча.
R не подходит для кастомной генерации таблицы признаков - слишком медленный. Да и размещение всей этой конструкции на VPS не внушает доверия. В идеале, итогом должен быть чистый *.ex5 файл, без всяких дополнений, а иначе не взлетит.
Тема ветки же про этап разработки.
Который раз уже пишу, что нет идеи переноса в другую платформу (пока нет, по крайней мере). Так же нет идеи сопряжения МТ5 с какой-либо другой средой или платформой.
Есть идея создания более комфортной среды для отладки логики кода. ИМХО, такая среда должна быть а) интерпретатором, б) обладать языком максимально похожим на mql5, в) желательно обладать богатыми возможностями по анализу данными. По этим требованиям подходит ROOT. Остаётся "причесать" mql5 код, чтобы его куски можно было безболезнено перетаскивать из ME в ROOT и обратно. Нет никаких глобальных идей по переписыванию чего-либо.
Понял, дошло наконец-то! Тугодум я )):
Ну тогда только - опыт, сын ошибок трудных. Скурпулезно проверять что в ROOT-е и MQL-е работает одинаково, а что поразному.
есть такие штуки, называются intermediate database(или software). Например RedisAI https://oss.redis.com/redisai/ и получаете хорошую масштабируемость и гибкость. Остаётся только данные вливать, а считать можно в облаках и кластерах. Но не будет работать на VPS (только на полной WinVDS)
есть такие штуки, называются intermediate database(или software). Например RedisAI https://oss.redis.com/redisai/ и получаете хорошую масштабируемость и гибкость. Остаётся только данные вливать, а считать можно в облаках и кластерах. Но не будет работать на VPS (только на полной WinVDS)
Глобальные решения вызывают что-то вроде аллергии) Сразу вспоминается анекдот про "а теперь попробуем со всем этим взлететь")
В идеале, всё должно быть впихнуто в ONNX модель, которая впихивается в екзешник советника как ресурс. Но пока это практически недостижимо.
Понял, дошло наконец-то! Тугодум я )):
Ну тогда только - опыт, сын ошибок трудных. Скурпулезно проверять что в ROOT-е и MQL-е работает одинаково, а что поразному.
Глобальные решения вызывают что-то вроде аллергии) Сразу вспоминается анекдот про "а теперь попробуем со всем этим взлететь")
В идеале, всё должно быть впихнуто в ONNX модель, которая впихивается в екзешник советника как ресурс. Но пока это практически недостижимо.
анекдот про "а теперь попробуем со всем этим взлететь это как раз про "сделать кусок C++ туда-сюда совместимый с MQL" :-)
на мой взгляд, вы не вполне правы.
технически всё впихивается в контейнер ONNX или подобный и рассчётная часть это всё дело решает/считает. Даже более того части которые источник данных, потребитель результата (исполнятор) и собственно рассчёт могут (и должны) быть автономны друг от друга. Ведь модель постоянно совершенствуется, это непрерывный процесс - при разделении ролей, ONNX перезаливается в рассчет и это не влияет на качество и стабильность источника данных и исполнятора.
Упихнуть большую рассчётную часть в один экзешник - это тупик,фиаско; сами же убедились что рассчёты могут быть долгие и требовать существенных вычислительных ресурсов, на одной машине хоть обвешанной спец-картами это не сделать.