Скачать MetaTrader 5

хотелки

Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий
Пополняй счет удобным способом. Здесь их 4!
NTFS
650
NTFS 2013.05.14 13:14 

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

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

Спасибо!!! 

gunia
224
gunia 2013.05.14 13:45  

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

Vasiliy Sokolov
21696
Vasiliy Sokolov 2013.05.14 16:35  
gunia:

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

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

 

gunia
224
gunia 2013.05.14 17:13  
C-4:

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

 

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

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

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

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

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

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

NTFS
650
NTFS 2013.05.14 17:58  
gunia:

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

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

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

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

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

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

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

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

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

NTFS
650
NTFS 2013.05.14 18:04  
Renat:

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

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

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

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

NTFS
650
NTFS 2013.05.14 18:20  
fyords:

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

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

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

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

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

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

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

 

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

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