Что нужно добавить для дополнительной поддержки универсальных математических расчетов в MQL5 и MQL5 Cloud Network? - страница 7
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
для использования моего ПК в облачных вычислениях в
MQL5 Cloud Network. Но вот проблема в моем аккаунте на сайте http://www.mql5.com не отображаются агенты, а значит плата капать не будет за использование моего ПК. В самом менеджере агентов МТ5 MetaTrader 5 Agents Manager название своего аккаунта ввел.
Но вот проблема в моем аккаунте на сайте http://www.mql5.com не отображаются агенты, а значит плата капать не будет за использование моего ПК. В самом менеджере агентов МТ5 MetaTrader 5 Agents Manager название своего аккаунта ввел.
Отсюда вопрос - какие еще функции надо включить, чтобы улучшить возможности расчетной сети?
Наверное методы классов, которые можно вызывать удаленно и получать их значения от агентов: Remote Procedure Call (RPC). Что то типа такого:
Тут конечно же вместе с вызовом метода придется передавать агенту и текущие значения полей объекта, который вызывает этот самый метод удаленно.
Суть в том, что главный экземпляр класса вызывает какой нибудь метод, а внутри метода вызываются создаются экземпляры других классов, которые и рассылают по облаку задания. Результат(ы) возвраща(ю)ется обратно.
Например, создается задание в виде просчета нескольких ходов в шахматы. В главном методе, который выполняется удаленно, создаются различные комбинации с просчетом на один ход в виде объектов некоего класса и рассылаются. Те в свою очередь, если ход не завершился результатом или глубина расчета не превысила лимит, опять вызывают тот же самый метод. И т.д. и т.п.
Без участия терминала это хорошо.
Кто будет формировать данные для этого "одного из агентов"? Скрипт или индикатор сможет это сделать?
Любой из агентов может формировать исходные данные для остальных. Может посылать или бродкастом всем или выбранному агенту.
Любой агент сможет посылать фреймы данных любым другим агентам.
Для чего нужна связь между агентами, просветите недалеких, если можно.
Для решения связанных задач, где нужно обмениваться данными/результатами предыдущих расчетов.
Не обязательно в клауде. Можно у себя в локалке сделать высокоскоростную сеть из агентов и запустить в нее сложную задачу и большим обменом данными.
В результате можно без всяких суперкомпьютеров у себя построить мощную вычислительную сеть.
Наверное методы классов, которые можно вызывать удаленно и получать их значения от агентов. Что то типа такого:
Тут конечно же вместе с вызовом метода придется передавать агенту и текущие значения полей объекта, который вызывает этот самый метод удаленно.Нет, рабочий и реальный вариант только один - обмениваться фреймами данных. Удаленное исполнение функций несерьезно, ибо никто в здравом уме не будет реплицировать информационное окружение.
В рамках работы с фреймами можно расширить функционал:
На всякий случай для информации:
Стоимость сетевых задержек такова, что для оптимизации общего процесса нужно заниматься явным пакетированием результатов и как можно реже передавать данные. Например, если есть скорострельная (в пределах долей секунды) математическая задача на 100 000 000 проходов, то лучше процесс оптимизации сразу же алгоритмически распределить порциями по 1 000-10 000 проходов и написать код групповой обработки с возвратом результатов в пакете. Это даст огромное преимущество по сравнению с 100 000 000 возвратов, где много времени потратится на сеть.
Мы со своей стороны сами серьезно помогаем в случаях скорострельных задач, пакетируя выдачу по десяткам и сотням проходов каждому агенту и также пакетируя ответы. Это дает огромную экономию на передаче по сети и сводит сетевую задержку к минимуму.
Нет, рабочий и реальный вариант только один - обмениваться фреймами данных. Удаленное исполнение функций несерьезно, ибо никто в здравом уме не будет реплицировать информационное окружение.
Не во всех задачах результаты можно пакетировать, т.к. в некоторых прикладных и очень ресурсоемких результат может быть единственный или вообще не будет обнаружен, а безрезультатные задания отбрасываются по ходу пьесы, т.е. отсутствующие результаты не надо даже возвращать.
Тогда можно по другому. Т.е., главная задача формирует задания на своей стороне, информирует об этом агентов. А агенты вызывают удаленные методы с заданиями, вычисляют и если получают результат, то вызывают удаленные же методы для возврата результатов.
Например, задача: поиск простых делителей чисел Ферма. Может получиться так, что результатов вообще не будет, может будет один, а может несколько. Суть в том, что перебор этих самых потенциальных делителей - задача весьма ресурсоемкая, т.к. сначала нужно создать объект в виде большого числа (в задании можно указать лишь два числа в виде целых чисел: основная и мантисса, чтобы уменьшить расходы по передаче информации). Потом это число проверить на простоту (выполняется упрощенная проверка, с помощью которой выявлятся, что число на 90 с лишним процентов не простое). А потом уже, если тест на простоту пройден успешно, в цикле, возводя в квадрат по модулю искать совпадение условий. Если условие до завершения цикла не совпадет, то результата нет и возвращать нечего. В этом случае агент должен удаленно запросить следующее задание, вызвав удаленно соответствующий метод у главного приложения. Если он обнаружил результат, то должен вызвать другой метод и передать этот самый результат.
Т.е. задачи бывают разные и фреймовые структуры не для всех адекватны. А стоимость сетевых задержек в приведенном примере также ничтожна мала, т.к. одно задание состоит из передачи двух целых чисел агенту.
Не во всех задачах результаты можно пакетировать, т.к. в некоторых прикладных и очень ресурсоемких результат может быть единственный или вообще не будет обнаружен, а безрезультатные задания отбрасываются по ходу пьесы, т.е. отсутствующие результаты не надо даже возвращать.
Если используете схему работы с фреймами, то просто не возвращайте пустые результаты на "серверного агента" или возвращайте просто флаг "пакет рассчитан, данных нет".
Вы в курсе, как работает режим фреймов? Головная часть эксперта запускается прямо в окне терминала и ждет ответов (фреймов данных) от удаленных агентов. То есть, серверная часть сидит на графике, получает данные и может что угодно визуализировать.
Почитайте и попробуйте сами: https://www.mql5.com/ru/code/914
Если используете схему работы с фреймами, то просто не возвращайте пустые результаты на "серверного агента".
Дык это же только базис. Основные задачи, причем весьма ресурсоемкие для вычислений - рекурсивные. А облако для таких задач не предназначено, т.к. оно сделано только лишь для полного перебора. Полным перебором во многих прикладных задачах не пользуются, т.к. он бесперспективен. Рекурсивные задачи нужны для поиска в глубину и в ширину и в глубину с шириной. Например, синтез молекул. Т.е. по ходу пьесы строится дерево потенциальных решений, каждая ветвь которых вычислительно ресурсоемка. Но не всякая ветвь результативна. Т.е. где-то поиск обрывается, но в это же время продолжается поиск по другим потенциальным ветвям в глубину или ширину.
Полный перебор практически нигде не используется, т.к. для большинства прикладных задач с его помощью не хватит времени для поиска решения (например, задача по анализу ходов шахматной партии). А рекурсивные методы с отсечением бесперспективных ветвей решений, дают высокую скорость, особенно в распределенных вычислениях. Поэтому если Вы хотите привлечь в облако прикладников, то нужно подстроить это самое облако под их задачи, а не думать, что они все бросят и будут перебирать все варианты подряд, независимо от их перспективности. Им проще будет свою сеть распределенных вычислений создать, пусть менее скорострельную по гигафлопсам и с меньшим количеством компьютеров, но зато более эффективную, т.к. она будет вести поиск только в перспективных направлениях и найдет нужное решение гораздо быстрее, чем Сloud Network. Причем во многих языках программирования для этого есть инструментарий, т.е. готовые реализации RPC.
Например, тот же самый поиск простых делителей чисел Ферма можно разбить на подзадачи. Главное приложение формирует задания. Следующий слой создает объекты и выполняет для них быструю проверку на простоту из оставшихся формирует задания. Следующий слой ищет условия, т.е. найден или не найден делитель числа Ферма. Из обнаруженных чисел опять формируются задания. Следующий слой выполняет полную проверку на простоту, и если число не простое, то формирует задания. Если простое, то возвращает результат главному приложению. Следующий слой факторизует непростые делители чисел Ферма и формирует из них задания для предыдущего слоя.
Получается конвейер, где на каждом слое агенты выполняют свои задачи. А будет ли найден результат - вилами писано. Важно, что в конвейере отбрасываются заведомо бесперспективные для дальнейшего поиска решений числа. Т.е. экономится куча вычислительных ресурсов, а не делается попытка навалиться тысячами агентов на бесперспективные задания и попытаться их перемолоть.
Дык это же только базис. Основные задачи, причем весьма ресурсоемкие для вычислений - рекурсивные. А облако для таких задач не предназначено, т.к. оно сделано только лишь для полного перебора. Полным перебором во многих прикладных задачах не пользуются, т.к. он бесперспективен. Рекурсивные задачи нужны для поиска в глубину и в ширину и в глубину с шириной. Например, синтез молекул. Т.е. по ходу пьесы строится дерево потенциальных решений, каждая ветвь которых вычислительно ресурсоемка. Но не всякая ветвь результативна. Т.е. где-то поиск обрывается, но в это же время продолжается поиск по другим потенциальным ветвям в глубину или ширину.
Ведите расчеты пакетами по 1 000-10 000 проходов, а возвращайте только значимые результаты. Это очень эффективный алгоритмический прием.
Я специально об этом писал выше.
Полный перебор практически нигде не используется, т.к. для большинства прикладных задач с его помощью не хватит времени для поиска решения (например, задача по анализу ходов шахматной партии). А рекурсивные методы с отсечением бесперспективных ветвей решений, дают высокую скорость, особенно в распределенных вычислениях. Поэтому если Вы хотите привлечь в облако прикладников, то нужно подстроить это самое облако под их задачи, а не думать, что они все бросят и будут перебирать все варианты подряд, независимо от их перспективности. Им проще будет свою сеть распределенных вычислений создать, пусть менее скорострельную по гигафлопсам и с меньшим количеством компьютеров, но зато более эффективную, т.к. она будет вести поиск только в перспективных направлениях и найдет нужное решение гораздо быстрее, чем Сloud Network. Причем во многих языках программирования для этого есть инструментарий, т.е. готовые реализации RPC.
Например, тот же самый поиск простых делителей чисел Ферма можно разбить на подзадачи. Главное приложение формирует задания. Следующий слой создает объекты и выполняет для них быструю проверку на простоту из оставшихся формирует задания. Следующий слой ищет условия, т.е. найден или не найден делитель числа Ферма. Из обнаруженных чисел опять формируются задания. Следующий слой выполняет полную проверку на простоту, и если число не простое, то формирует задания. Если простое, то возвращает результат главному приложению. Следующий слой факторизует непростые делители чисел Ферма и формирует из них задания для предыдущего слоя.
Прочтите выше про обмен данными и демонстрационный пример:
Предлагается дальнейшее расширение обмена данными так, что мастер-процесс может дополнительно передавать данные любому агенту любые дополнительные кастомные данные. В результате можно как раз считать частями, дораздавая новые кастомные условия удаленным агентам. В результате можно будет считать как угодно, хоть каждые раз меняя условия задачи.
Еще одно из возможных расширений, когда агенты могут не только получать задачи от мастера, но и сами перекидываться друг с другом данными. Можно конечно делать это через мастера (это может быть очень медленно, если данных много), но еще более эффективно и быстрее это можно сделать напрямую через клауд серверы.
Renat:
Еще одно из возможных расширений, когда агенты могут не только получать задачи от мастера, но и сами перекидываться друг с другом данными. Можно конечно делать это через мастера (это может быть очень медленно, если данных много), но еще более эффективно и быстрее это можно сделать напрямую через клауд серверы.
Вот это вот и нужно, т.е. рекурсивная передача данных от одних агентов к другим без посредства мастера, но с гарантированым возвратом результатов мастеру. Т.е. чтобы не получилось так, что агент взял задание и не выполнив его, прекратил работу, например, потому что компьютер выключили и при этом потенциально результативная ветвь решений оборвалась.
Т.е., например, задача по анализу шахматной партии. Мастер расставляет фигуры и формирует задания для цвета фигур, которые должны ходить сейчас, т.е. одна фигура - одно задание. Каждый агент, получив задание для своей фигуры, отбрасывает бесперспективные для дальнейшего анализа варианты, когда фигура не может ходить и формирует из оставшихся новые расстановки, которые передаются далее в виде заданий уже для фигур противника. И т.д. и т.п. до мата или пата или превышения глубины поиска.
Если такую задачу поручить текущей реализации облака, то можно лишь сформировать пакеты заданий для полного перебора. А на это у облака никаких агентов не хватит, да и вряд ли у мастера хватит памяти, чтобы все эти задания разложить по пакетам. Потому что нет механизма отсева бесперспективных вариантов. Ведь с каждым новым анализируемым ходом фигур, количество заданий растет в геометрической прогрессии, но и значительная часть их отбрасывается и не порождает бессмысленных заданий, как при полном переборе. А узнать на предмет перспективности можно только после погружения на некоторую глубину или ширину дерева решений. А глубина в данной реализации облака равна 1, т.е. от мастера к агенту и обратно.
Я к чему это говорю. Для трейдинга реализация рекурсивного поиска с отсечениями бесперспективных ветвей тоже нужна. Ведь лучше искать не один экстремум, а множество локальных (их там действительно множество). Причем пространство поиска всех возможных вариантов астрономическое, т.е. не хватит никаких агентов, взятых из всех сетей распределенных вычислений. Для этого, на каждом шаге перебираем ближайшие окрестности полученной из задания точки (координаты точки - входные параметры советника) на некотором расстоянии от нее и отстоящие друг от друга на некоторое угловое значение, на предмет, улучшают они результаты по сравнению с текущим или нет. Если какие-то из них ухудшают или вышли за пределы глубины поиска, то отбрасываем. Если улучшают, то рекурсивно ищем дальше и из улучшенных точек формируем пакет дальнейших заданий, которые раздаем агентам. Если нашли локальный экстремум (все точки в окрестности только ухудшают текущий результат), то возвращаем результат главному приложению. После того, как экстремумы найдены, передаем их мастеру и далее анализируем форвардными тестами.
В лоб решить такую задачу невозможно, т.к. вариантов астрономическое число. Генетический алгоритм тоже не ищет локальные экстремумы (он и в возле глобального останавливается в ближайших окрестностях), а показывает лишь промежуточные результаты, независимо от их экстремальности. Не говоря про то, что у генетического алгоритма и у полного перебора пространство поиска ограничено и дискретно. А нужен именно поиск максимального количества локальных экстремумов, но быстрый, т.е. с отсечением бесперспективных поколений заданий от мастера агентам и от агента другим агентам и неограниченный диапазонами( но так чтобы ограничения при необходимости можно было задать, например, глубина поиска в таких алгоритмах всегда ограничена). Была бы у облака реализована рекурсивная передача заданий, проблема была бы решена.