Скачать MetaTrader 5

хотелки

Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий
NTFS
656
NTFS  

День добрый всем присутствующим!

В связи с тем, что MQ5 по сравнению с 4кой стал на две головы выше, может быть пришло время подумать о визуальном MQ? Я к тому, что формы, поля для редактирования и прочее (в конце концов и шаблон эксперта, видимо) проще было бы добавлять из стандартных средств вроде того, как это сделано в других Visual языках (цепляем мышкой иконку эксперта и тащим на формочку). Но это как бы на удаленное будущее, а в рамках недель было бы неплохо иметь хотя бы _специальное окно_ для всевозможного вида управляющих панелей, таблиц. Сейчас приходится для этого создавать какой-нибудь "левый" график, затаскивать его в угол (например, ставить фиксированный масштаб 0.001 - 0.0001, убирать сетку, убирать OHLC и прочее ненужности). Минусом такого окна является то, что приходится отлавливать в циклах работающих со всеми окнами конкретно это и ставить доп.условие на пропуск окна. В общем хотелось бы услышать комментарии разработчиков, людей в теме. Ждать нам в ближайший год, например, Visual MQ или хотя бы некий отдельный полигон для отработки мультивалютных панелей, таблиц с методом onAnyTick() ;)

Спасибо!!! 

Андрей
262
Андрей  

Есть ряд разработок на тему графического MQL кодинга, например EA Tree с блочным драгндропом. Я тоже считаю что за узловыми системами будущее, но есть много НО, такая система должна быть гибридная, то есть обязательно должна быть возможность редактирования кода каждого узла\блока и создание кастомных узлов в текстовом режиме. Иначе это игрушка для малышей. Большинство высокоуровневых САПРов так работают, это в сотни раз ускоряет разработку шаблонных архетектур, и на тонкую кастомизацию по готовому скелету остаётся гораздо больше времени. Безусловно за такими решениями будущее.

Vasiliy Sokolov
28846
Vasiliy Sokolov  
gunia:

Есть ряд разработок на тему графического MQL кодинга, например EA Tree с блочным драгндропом. Я тоже считаю что за узловыми системами будущее, но есть много НО, такая система должна быть гибридная, то есть обязательно должна быть возможность редактирования кода каждого узла\блока и создание кастомных узлов в текстовом режиме. Иначе это игрушка для малышей. Большинство высокоуровневых САПРов так работают, это в сотни раз ускоряет разработку шаблонных архетектур, и на тонкую кастомизацию по готовому скелету остаётся гораздо больше времени. Безусловно за такими решениями будущее.

Чем плох на эту роль стандартный мастер стратегий в MQL5? Там тоже можно описать соответствующий модуль сопровождения позиции и использовать его в качестве кирпичика эксперта:

 

Андрей
262
Андрей  
C-4:

Чем плох на эту роль стандартный мастер стратегий в MQL5? Там тоже можно описать соответствующий модуль сопровождения позиции и использовать его в качестве кирпичика эксперта:

 

Стандартный хорош. Но есть куда расти.

Узловые редакторы давно применяются в производстве цифровой графики высокой сложности, это позволило в последнее десятилетие сделать прорыв в качестве и скорости.

Когда-то вообще считалось что и компьютеры это только для ученых)))

Должен быть баланс в скорости, простоте использования с одной стороны и кастомных возможностях с другой.

99% ТС это шаблоны. В узловой оболочке типа EA Tree классическая ТС на МАшках с примитивным ММ, «рисуются» за пару минут. С какой такой стати трейдер должен тратить больше времени или недай бог заказывать такой примитив? Но это вторично. Главное это то что графическое представление куда больше похоже по структуре на исходный алгоритм, чем тысячи строчек кода, понятна структура и соответственно быстрей идёт творческий процесс перебора вариантов, тестирования, поиска идей и тп.

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

NTFS
656
NTFS  
gunia:

Стандартный хорош. Но есть куда расти.

Узловые редакторы давно применяются в производстве цифровой графики высокой сложности, это позволило в последнее десятилетие сделать прорыв в качестве и скорости.

Когда-то вообще считалось что и компьютеры это только для ученых)))

Должен быть баланс в скорости, простоте использования с одной стороны и кастомных возможностях с другой.

99% ТС это шаблоны. В узловой оболочке типа EA Tree классическая ТС на МАшках с примитивным ММ, «рисуются» за пару минут. С какой такой стати трейдер должен тратить больше времени или недай бог заказывать такой примитив? Но это вторично. Главное это то что графическое представление куда больше похоже по структуре на исходный алгоритм, чем тысячи строчек кода, понятна структура и соответственно быстрей идёт творческий процесс перебора вариантов, тестирования, поиска идей и тп.

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

+1 к посту. Я вообще к тому начал, что прослеживается тенденция. МТ4 это как бы С, МТ5 это понятно С++, потом было Visual C++ и куча компонент к нему стала появляться. Так ждать vMQL5  или как? :) Компоненты могли бы в Маркете продаваться
MetaQuotes
Админ
25627
Renat Fatkhullin  

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

Звезда RAD средств закатилась много лет назад, к сожалению. Оказалось, что "таскать формочки" - это не массово, очень ограничено и никак не удовлетворяет потребителей.

NTFS
656
NTFS  
Renat:

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

Звезда RAD средств закатилась много лет назад, к сожалению. Оказалось, что "таскать формочки" - это не массово, очень ограничено и никак не удовлетворяет потребителей.

Подождите. как же так "закатилась", а что же сейчас рулит, если не RAD, а потом доработка получившегося кода?
Dmitriy Parfenovich
8216
Dmitriy Parfenovich  

Я тоже думал, что такая штука будет удобной. С возможностью просто вставлять свои блоки/код и также легко творить.

NTFS
656
NTFS  
fyords:

Я тоже думал, что такая штука будет удобной. С возможностью просто вставлять свои блоки/код и также легко творить.

"Продается в 70 странах...". Пожалуй аргумент в пользу того, что восстребованы подобные средства
MetaQuotes
Админ
25627
Renat Fatkhullin  
Много лет назад был хайп по рад средствам, очень было много надежд. Но когда начали появляться решения, массы не восприняли. Особенно после осознания, что обучение владением рад тулзой обходится не сильно дешевле обучения заменяемой базе.

На текущий момент продукты так и создаются большей частью в рукопашную. Да, компоненты и библиотеки сильно помогаю, но все остальное - только ручками.

Многие компании-разработчики рад систем на практике осознают результаты, а потом тихо сливают продукты.

Если говорить о замене программирования, то тут рады почти не помогают. Например, они понятия не имеют и не могут предложить способа экономного пересчета индикаторов. Без знания практик программирования никак. кроме того, обычно рады дают такой дикий оверхед по производительности, что результаты слабо применимы в тяжелых рассчетах.
Принципы экономного пересчета индикаторов
Принципы экономного пересчета индикаторов
  • 2010.06.29
  • Nikolay Kositsin
  • www.mql5.com
Вызовы пользовательских и технических индикаторов занимают совсем немного места в программном коде механических торговых систем. Зачастую какие-нибудь несколько строчек кода и всего-то. Но подчас именно эти несколько строчек кода съедают львиную долю всех затрат времени, которое будет истрачено на тестирование эксперта. Так что ко всему, что связано с расчетом данных внутри индикаторов, следует относиться гораздо более обстоятельно, чем оно могло бы показаться на первый взгляд. Именно об этом и пойдёт речь в данной статье.
Vladislav Andruschenko
112635
Vladislav Andruschenko  
fyords:

Я тоже думал, что такая штука будет удобной. С возможностью просто вставлять свои блоки/код и также легко творить.

наверно тут легче выучить язык, чем учить другую программу, Тем более MQ дает гибкие библиотеки, делай что хошь называется.

 

Идея с созданием такой системы и у меня была, но тут скорее всего сработал принцип СПРОС - ПРЕДЛОЖЕНИЕ, мало спроса, программа не будет иметь большую популярность. 

Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий