Справка по языку MQL5 - страница 37

Новый комментарий
 
SK. >>:
...

** "модуль эффективного расчёта индикаторных массивов" может быть вызван любой прикл. программой.

Хм... (если я правильно понял Вашу мысль)

Давно уже не использую осцилляторы как графики. Ибо нечего там смотреть и занимать полезную площадь.

Тем более основная масса оных используется как сигнал по типу:

- если что-то там пересекается, иль достигнет уровня, иль "смотрит вниз"

Для получения этого сигнала вполне достаточно просто его считать и использовать по назначению.

Что считаю более эффективным и эргономичным чем созерцание линий...

//=== WPR ===========================================================
double valWPR=iWPR(NULL,0,14,0);
string commentWPR="R%: ";
string commentWPRAdd="Нет данных";
if (valWPR<-80)
commentWPRAdd ="состояние перепроданности (разумно дождаться поворота цен вверх) ";
if (valWPR>-20)
commentWPRAdd="состояние перекупленности (разумно дождаться поворота цен вниз) ";
commentWPR=commentWPR+commentWPRAdd;
 
kombat писал(а) >>

Хм... (если я правильно понял Вашу мысль)

Давно уже не использую осцилляторы как графики. Ибо нечего там смотреть и занимать полезную площадь.

Тем более основная масса оных используется как сигнал по типу:

- если что-то там пересекается, иль достигнет уровня, иль "смотрит вниз"

Для получения этого сигнала вполне достаточно просто его считать и использовать по назначению.

Что считаю более эффективным и эргономичным чем созерцание линий...

Речь идёт не о наших с Вами предпочтениях, а о том, чтобы разделить полномочия индикатора.

Считать инд. массивы должна считалка. Вот, пусть она и считает, если уж она такая математически оптимизированная и поэтому уникальная.

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

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

То же для экспертов и скриптов. Нужны данные для расчётов - вызывайте считалку и получайте данные. А нужно всё это вывести на экран - вызывайте индикатор и путь рисует.

--

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

 

Renat писал(а) >>

Архитектурно индикатор - это оторванная от графика расчетная сущность, которая умеет перемалывать предоставляемые числовые буферы с данными и отрисовывать результаты одним из стандартных вариантов визуализации.

Если же добавлять к нему возможность создавать и управлять объектами, то это заставит нас явно интерфейсно привязывать к графику, что создаст определенные ограничения в тестере.

Вопрос с созданием объектов из индикаторов остается открытым - окончательное решение еще не принято.

Индикатор - это графический элемент по определению этого слова; всякие попытки переопределения понятия ведут в болото. Это, надеюсь, понятно?

Графические объекты в MQL4 вообще не имели интерфейса вывода данных в тестер, поэтому не понимаю, о каких ограничениях здесь речь?

SK. писал(а) >>

По-моему, нужно оставить эти прикл. программы для расчёта инд. массивов, но называть их не индикаторами, а попроще - что-то типа "модуль эффективного расчёта индикаторных массивов". И должен появиться ещё один тип прикл. программы - рисовалка, которая:

1) сможет вызвать (в стиле iCustom) расчётный модуль, чтобы получить данные для отрисовки индикаторных линий

2) будет иметь право использования функций для управления графическими объектами.

3) будет называться индикатором.

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

Main - "главная" программа, (типа, в "пустом" окне) - высший статус - подчиняется только терминалу. Может вызывать любую прикл. программу в любое окно.

Эксперты - статус 1. Могут вызывать скрипты и индикаторы (в окно, в ктором сидит эксперт).

Скрипты - статус 2. Могут вызывать индикаторы (в то же окно).

Индикаторы - статус 3. Могут вызываться кем угодно. Вызывать не могут никого. (могут создавать подокно в окне вызвавшей прогр.)

** "модуль эффективного расчёта индикаторных массивов" может быть вызван любой прикл. программой.

Поддерживаю пункты 1-3. Модуль вывода индикаторных массивов можно, по аналогии с глобальными переменными терминала, назвать глобальными (индикаторными) функциями (global functions), или функциями данных (data functions). Хотя, конечно, с точки ООП, это должны быть объекты, связанные с данными (data binding classes).


Иерархии по праву вызова не поддерживаю. Всякие там "главные генералы" не стыкуются с ООП, органичивают гибкость и эффективность, а вот ввод нормальной иерархии namespaces для всех объектов, включая внутренние - IMHO the way to go. Вся архитектура должна заворачивать любой модуль в объекты (lightweight wrappers). Классы типа Terminal, Log, Window, Chart, Expert, Indicator, DataBinder, DataStore, DataFunction (DataTransformer), Tester, и т.п. Но тогда необходимо иметь интерфейсы (или, на худой конец, абстрактные классы).

 
pisara писал(а) >>

Иерархии по праву вызова не поддерживаю. Всякие там "главные генералы" не стыкуются с ООП, органичивают гибкость и эффективность, а вот ввод нормальной иерархии namespaces для всех объектов, включая внутренние - IMHO the way to go. Вся архитектура должна заворачивать любой модуль в объекты (lightweight wrappers). Классы типа Terminal, Log, Window, Chart, Expert, Indicator, DataBinder, DataStore, DataFunction (DataTransformer), Tester, и т.п. Но тогда необходимо иметь интерфейсы (или, на худой конец, абстрактные классы).

Возможно, Вы и правы.

Но мне всё же представляется, что индикаторы не должны иметь полномочий вызывать торгующие программы. И в одном окне должна исполняться одна торгующая программа - эксперт. Поэтому эксперты должны иметь право вызывать скрипты и индикаторы. А скрипты - только индикаторы.

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

Вообще же, многое из того, что Вы пишете, мне кажется разумным; и в целом Ваш лейтмотив я поддерживаю.

 

SK. писал(а) >>

Возможно, Вы и правы.

Но мне всё же представляется, что индикаторы не должны иметь полномочий вызывать торгующие программы. И в одном окне должна исполняться одна торгующая программа - эксперт. Поэтому эксперты должны иметь право вызывать скрипты и индикаторы. А скрипты - только индикаторы.

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

Вообще же, многое из того, что Вы пишете, мне кажется разумным; и в целом Ваш лейтмотив я поддерживаю.

Спасибо за поддержку. Конечно, индюки - для рисования, не для торговли. Всё это должна обеспечивать соответствующим образом разработанная структура классов, MQL5 framework. Скрипты по мне как процедуры, но можно, конечно, думать и так: 

new Script("CloseAllPositions").Run("EURUSD", PERIOD_M1);
или, почти то же самое в namespace Metaquotes.MQL5.Control со статическим методом Run класса Script так:
Metaquotes.MQL5.Control.Script.Run("CloseAllPositions", "EURUSD", PERIOD_M1);

В принципе, если рисующие на канвасе графика цен индикаторы никак на него не завязаны (кроме совмещения канваса, или лейера), то мне представляется, что торгующие эксперты и подавно должны быть полностью независимы от какого-либо графика, на который их вроде как кто-то должен зачем-то "закинуть". Представте себе многотаймфреймовый мультивалютник. ИМХО эксперты должны иметь в терминале специальное окно, где все они на листе, с возможностью вручную их отключать/включать, в т.ч. в определённые интервалы времени (календарь, с точн. до минуты). Конечно, почему бы не дать ещё и возможность запуска/остановки экспертов программно, скажем с управляющего эксперта-менеджера стратегий? Так же можно представлять и запускать скрипты.

 
pisara писал(а) >>

В принципе, если рисующие на канвасе графика цен индикаторы никак на него не завязаны (кроме совмещения канваса, или лейера), то мне представляется, что торгующие эксперты и подавно должны быть полностью независимы от какого-либо графика, на который их вроде как кто-то должен зачем-то "закинуть". Представте себе многотаймфреймовый мультивалютник. ИМХО эксперты должны иметь в терминале специальное окно, где все они на листе, с возможностью вручную их отключать/включать, в т.ч. в определённые интервалы времени (календарь, с точн. до минуты). Конечно, почему бы не дать ещё и возможность запуска/остановки экспертов программно, скажем с управляющего эксперта-менеджера стратегий? Так же можно представлять и запускать скрипты.

Примерно то же самое говрю и я (см. 'Справка по языку MQL5' от 14.08.2009 13:38 и 'Справка по языку MQL5' от 23.08.2009 12:36 ) .

Концепция прикрепления прикладной программы (пп - эксп, скр, инд) к графику тянется, как бабкины сарафаны, ещё с МТ 3. На стадии создания (первого касания, осознания) общей технологии МТ такое решение, вполне возможно, было оправдано. Сегодня (опять же, по моим представлениям) - это ничем не оправданный тормоз.

Сегодня, возможно, и следует сохранить за экспертом свойство "разрешение прикреплять вручную к конкретному графику", но только как второсортное. А первостепенной должна быть другая возможность - возможность вызова эксперта на исполнение сервисной программой (в моей случайной терминологии - Main). Эта серв. программа должна быть главенствующей и сидеть не в окне, а в терминале. В качестве средств управления она может иметь и лист, о котором Вы говорите, но не только. Она должна нести основные средства управления всем процессом торговли. Она может быть пустой (по умолчанию), но может и наполняться прикладным кодом.

Принятая в МТ 4 концепция закрепления отдельных (ни с кем другим не согласованных) пп сегодня не может считаться прогрессивной. Время разрозненных скриптов и индикаторов уходит, как время частных ремесленников, работающих без ГОСТа. Наступает время первых мануфактур и конвееров. Причём, наступает быстро.

Мне видится прибл. такая общая технология. Эксперт должен нести алгоритм стратегии (вычисления точек входа и выхода, вероятности успеха сделки, требуемых средств и т.д.). Всё это он должен сообщать в сервисную программу, в которой и принимается решение об удовлетворении запроса на торг. операцию того или иного эксперта.

Сервисная программа может нести свои уникальные свойства (см. аналог на моём сайте), в том числе, может собирать сведения о качестве экспертов (кто как себя ведёт, какие у кого показатели, и вычислять собственные приоритеты при распределении денежных средств между экспертами при (неминуемо) мультивалютной торговле). А для этой цели она может загружать и выгружать экспертов в окна, чтоб они могли определиться со своими просьбами, а те, в свою очередь, для своих нужд должны уметь подгружать индикаторы и скрипты.

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

--

А скрипты, рисующие граф. объекты, и простые отдельные индикаторы тоже были бы к делу - например, чтоб блондинка не скучала (пока сервисн. программа с подчинёнными экспертами занимаются делом), а могла "типа, посмотреть как это выглядит в графике" :) Ну, а.. если экспертов в окне много, а индикаторы не рисуют, то блондинка .. чё-нибудь и сломает..:)

 
pisara >>:

1. В рамках ООП - естественно нет. Но зато способствует разбрызгиванию объектного кода; ни Ява, ни C# такого буйства не разрешают. Спишем как издержки производства от C/C++ :)

2. А вот это уже делают не от хорошей жизни. Отсутствие в языке абстрактных классов или интерфейсов делает ООП оччень даже размытой и толкает на дурной дезайн софтины :((

3. Значит, объявив виртуал конструктору, компилятор завопит?

1) Синтаксис поддерживает реализацию методов в описании. У Вас будет выбор в оформлении кода (С++ или C#).
2) Приведите пример, в котором отсутствие абстракции классов сделает ООП очень размытой...
3) Да

 
pisara >>:

Типы событий графика


У этой пары констант либо некорректные названия, либо их описание, скорее всего оба :)

CHARTEVENT_MIN и CHARTEVENT_MAX по аналогии с например CHART_FIXED_MAX и CHART_FIXED_MIN, или _FIRST и _LAST, но уж никак не maximal last value, тогда где minimal last value?


CHARTEVENT_CUSTOM

Minimal сustom event value

CHARTEVENT_CUSTOM_LAST

Maximal last custom event value

Слово "last" убрано.

 
pisara >>:

1. мы о том же самом распределении говорим? капсула конкретного класса на конкретной ступеньке иерархии должна содержать в себе всю "черепаху", а не только её голову, лапы или панцирь.

Локализация вовнутрь капсулы класса. Ява и, позже построенный на её опыте острый Си, писАлись разными деятелями, причём все они плясали от имеющейся базы и опыта C/C++, навряд ли они были наивны или глупы.

Зачем человеку, который желает посмотреть на черепаху (только посмотреть, ну или погладить, покормить, завести дома), разгребать ее внутренности?

2. не, капсула, объект, класс, животное создание, возьми хоть что - не надо их резать и разрывать, прикрываясь логикой Буля, историческим наследием Си и т.п.

Ну если вы не понимаете разницу между резать и распределять, то говорить собственно не о чем.

3. грамотный объектный код содержит от 2 до 5 строк в теле метода/функции. Если же не охота вдаваться в нюансы ООП - пиши на здоровье "пахучие" расколбасы процедур с бесконечными вложенными и, порой, практически повторяющимися кусками кода и циклами if (!working)... каждому своё, ведь и разработчики MQL5 не сильно настаивают...

Грамотный код определяется не количеством строчек, а содержанием. В общем и в целом ни на что, кроме демагогии, вы не способны. Читайте маны, ну или соизвольте хотя бы закинуть мизерный скриптик в базу, дабы все могли воочию увидеть ээ "грамотный код". Удачи.

 

mql5 писал(а) >>

1) Синтаксис поддерживает реализацию методов в описании. У Вас будет выбор в оформлении кода (С++ или C#).
2) Приведите пример, в котором отсутствие абстракции классов сделает ООП очень размытой...
3) Да

1). ОК

2). Инвиняюсь, я не учитель по ООП. Однако надеюсь, что парням с Метаквотс не надо рассказывать о преимуществах абстрактных классов и интерфейсов в разработке сколь-нибудь серьёзных проектов. В этом контексте было бы интересно услышать мнение главного архитектора платформы MQL5, тогда каждый сможет делать свои выводы.

1...303132333435363738394041424344...62
Новый комментарий
Причина обращения: