Умная логика обработки информации MQL - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Вы совершенно правы, самое сложное в работе это найти общий язык, на котором тебя будут понимать, поэтому мне и казалось, что наличие визуальной логики приблизит к лучшему пониманию.
А вопрос последовательного или выборочного исполнения кода программы нужно явно указать в ТЗ, но и проконтролировать это мне как то надо.
Дело в том, что я в советнике использую ряд фильтров, в том числе и на основе внешних пользовательских индикаторов, которые существенно замедляют работу, и если есть возможность прекратить проверку актуальности данных, если они уже отфильтрованы предшествующим фильтром, то я бы хотел этим пользоваться.
Что же касается скупости, то советник я пишу долго, вношу изменения, и готов платить за доработки, которые при соблюдении моей логики будут менее трудозатратны и быстры по исполнению. Поэтому доход от работы со мной будет стабильный, хоть и не большой...
При разработке автоматических торговых систем надо стремиться максимально использовать преимущества,
которое даёт объектно-ориентированное программирование.
Нужно стремиться все блоки вычислений оформлять в виде классов с формальным интерфейсом.
Например, те "тяжёлые" расчёты, которые вы используете в своих пользовательских индикаторах
можно оформить в виде классов.
Что это даст?
Это даст возможность перенести логику расчётов из индикатора в сам эксперт.
Меньше работающих программ MQL, которые составляют единую АТС - меньше мороки по согласованию этих программ.
Сам эксперт в таком случае будет представлять из себя "гигантский" класс-агрегатор, внутри которого "трудятся" другие классы-рабочие,
которые взаимодействуют между собой и с самим агрегатором при помощи своих формальных интерфейсов.
Подключить же этот класс-агрегатор к событиям, которые генерирует сам терминал при работе - дело несложное.
При разработке автоматических торговых систем надо стремиться максимально использовать преимущества,
которое даёт объектно-ориентированное программирование.
Нужно стремиться все блоки вычислений оформлять в виде классов с формальным интерфейсом.
Например, те "тяжёлые" расчёты, которые вы используете в своих пользовательских индикаторах
можно оформить в виде классов.
Что это даст?
Это даст возможность перенести логику расчётов из индикатора в сам эксперт.
Меньше работающих программ MQL, которые составляют единую АТС - меньше мороки по согласованию этих программ.
Сам эксперт в таком случае будет представлять из себя "гигантский" класс-агрегатор, внутри которого "трудятся" другие классы-рабочие,
которые взаимодействуют между собой и с самим агрегатором при помощи своих формальных интерфейсов.
Подключить же этот класс-агрегатор к событиям, которые генерирует сам терминал при работе - дело несложное.
В большинстве случаев ООП никакого преимущества не дает, только добавляет тормозов. Не надо врать.
-Aleks- 2014.04.13 10:53 RU
Я пишу ТЗ для советника на MT4 с приоритетом на ускоренную обработку данных.
Если нужна быстрая обработка то лучше не использовать ООП. ООП нужен только для унификации кода.
Запустите профилировщик, сразу увидите кто отжирает ресурсов.
ООП не дает особых тормозов, а вот преимуществ масса.
С учетом тотального инлайнинга и оптимизирующего компилятора код вырождается в достаточно плоский вид.
Конечно, если реализовать массовые вызовы с постоянной работой через хендлы и полезной расчетной нагрузкой, сравнимой со стоимостью вызовов, то можно получить заметный оверхед. Но такова цена модели безопасности системы.
Всем привет, нужна помощь или совет: нужен индикатор, задача которого заключалась бы в выводе цены разных валютных пар но в одном окне, окно типа стохастика или ССI или RSI, никаких просчётов быть не должно, просто состояние цени трёх или четырёх валютных пар на период закрытия по выбранному периоду. Есть одно предположение, буду весьма признателен!
В большинстве случаев ООП никакого преимущества не дает, только добавляет тормозов. Не надо врать.
Если нужна быстрая обработка то лучше не использовать ООП. ООП нужен только для унификации кода.
Запустите профилировщик, сразу увидите кто отжирает ресурсов.
Без ООП в более менее большом проекте Вы рано или поздно просчитаетесь в архитектуре приложения, что практически неминуемо повлечет поистине драматическое снижение производительности. Но его Вы уже не будете в состоянии исправить, т.к. без ООП, степень управляемости кода с ростом его объема будет неуклонно снижаться.
Никто не спорит о преимуществах ООП, но более менее больших проектов здесь и близко не видать.
Это примерно как гильотиной ногти постригать )
Никто не спорит о преимуществах ООП, но более менее больших проектов здесь и близко не видать.
Это примерно как гильотиной ногти постригать )
Я пишу ТЗ для советника на MT4 с приоритетом на ускоренную обработку данных.
Прошу Вас подсказать, имеет ли значение для ускорение работы последовательность выполнения расчета или выборочное (как правильно называется - репрезентативное?).
Прикладываю два варианта в виде картинок, на которых отображены блок схемы (примитивно).
Если можно, то напишите как должен выглядеть код, если выборочное исполнение блоков будет происходить - чисто примитивный макет, и даст ли это существенный прирост скорости если одно из промежуточных условий будет верно!?
Конечно, последовательная проверка с выходом после первого же невыполненного условия будет работать быстрее.
Весь вопрос в том - какого плана эти проверки.
Если, как в вашем примере (все касаются закрытых сделок), то ускорение будет незначительным, т.к. все равно придется прочесывать историю счета и искать нужную сделку (и можно найти сразу все проверяемые).
Если проверки простые (Open[1] > Open[2]), то ускорение тоже будет несущественным.
Тут нужно хорошо понимать, с какой скоростью что работает, и сразу правильно построить структуру программы.
Хорошо, что вы над этим думаете, но вряд ли вам удастся самостоятельно построить оптимальную схему.
Дайте больше конкретики или проконсультируйтесь у программиста.