Машинное обучение в трейдинге: теория, модели, практика и алготорговля - страница 2441
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Мы уже говорили, что идем в сторону внедрения машинного обучения в MQL5.
Скоро мы выпустим нативную поддержку комплексных чисел(готовы), скоростных векторов и матриц. Это именно нативная функциональность языка, а не библиотеки.
Далее мы включим большой набор ML механик и дадим функционал, аналогичный TensorFlow. Это позволит писать нативных роботов совершенно другого уровня.
Вы будете использовать WinML или DirectML или какое-то своё решение?
Будет ли поддержка ONNX?
Мы уже говорили, что идем в сторону внедрения машинного обучения в MQL5.
Скоро мы выпустим нативную поддержку комплексных чисел(готовы), скоростных векторов и матриц. Это именно нативная функциональность языка, а не библиотеки.
Далее мы включим большой набор ML механик и дадим функционал, аналогичный TensorFlow. Это позволит писать нативных роботов совершенно другого уровня.
Renat Fatkhullin:
Скоро мы выпустим нативную поддержку комплексных чисел(готовы), скоростных векторов и матриц.
Очень нужна возможность работать с массивами без циклов, как в matlab и numpy (умножение на число, поэлементное умножение, слайсы).
Очень нужна возможность работать с массивами без циклов, как в matlab и numpy (умножение на число, поэлементное умножение, слайсы).
Это уже есть на уровне языка.
Вы будете использовать WinML или DirectML или какое-то своё решение?
Будет ли поддержка ONNX?
Сначала мы делаем нативную поддержку новых типов данных и операций над ними прямо в языке.
Ускорение операций через OpenCL/многопоточность будет скрыто и прозрачно для разработчиков.
Над WinML/ONNX будем думать позже.
Мы планируем автоматически и прозрачно применять OpenCL в матричных и ML операциях.
Фактически, мы собираемся выжимать максимум без применения тонн монстроидально конфигурируемых CUDA и тензорфлоу библиотек.
А для векторов не будет автоматически применятся OpenCL ?
То есть если работаем с несколькими векторами, рациональней будет использовать матрицу?
Или вектора тоже будут поддерживаться в OpenCL?
Добавлено.
Аппаратный ресурс CPU или GPU, так же будет выбираться автоматически из того, что доступно?
Или можно будет самому определять, какой ресурс задействовать?
А для векторов не будет автоматически применятся OpenCL ?
То есть если работаем с несколькими векторами, рациональней будет использовать матрицу?
Или вектора тоже будут поддерживаться в OpenCL?
Добавлено.
Аппаратный ресурс CPU или GPU, так же будет выбираться автоматически из того, что доступно?
Или можно будет самому определять, какой ресурс задействовать?
Для одиночных векторов мало смысла применять высокозатратный OpenCL.
Где найдем эффект, там будем применять. OpenCL - не самоцель.
Сначала подождите бета-версий матричных операций без OpenCL. Как отладим базовый функционал, перейдем к ускорению.
Все обязательно будет покроем стресс-тестами и бенчмарками.
может кому то будет скучно
https://www.econometrics-with-r.org/16-4-volatility-clustering-and-autoregressive-conditional-heteroskedasticity.html
Сначала подождите бета-версий матричных операций
А какие примерно сроки?
Есть ли в планах возможность загрузки моделей, сохранённых в tensorflow?