Вот бы...
Выработать некую единую идеологию в обозначения символов.
Ибо и один доп.знак может значительно "эргономизировать" просмотр оных в маркетвоче...
Например знак #
что он означает? мало кто знает... видимо никто...
А вот записать в скрижалиях, что это группа CFD.
Как-то так в общем...
Да и про расскраску групп не забывайте раз уж не отдали это на откуп самим трейдерам.
"выключеные" символы никак не выделены, не "серые", путает...
Вот бы...
Сделать бары в МТ5 действительно эквитемпоральными.
Т.е. - НИКАКИХ ПРОПУЩЕННЫХ БАРОВ! Все бары, даже с нулевым объёмом должны отображаться на чартах и присутствовать при доступе по индексу.
Чтоб одинаковые индексы на разных валютных парах ГАРАНТИРОВАННО означали один и тот же datetime.
Единственное исключение (и то не обязательное) - выходные дни. Их можно и пропускать, но опять же ГАРАНТИРОВАННО синхронно по разным инструментам.
Сейчас это всё не так.
Если тиков не было - бары как и в MT4 просто-напросто отсутствуют!!
Нету никакой синхронности в котировках......
Мультивалютчики за бортом юзабилити...
Абсолютно ВСЕ индикаторы (включая встроенные) неумышленно привирают, расчитывая значениям по неполным котирам, даже не догадываясь об этом...
Такие вот грустные нынче дела.
В MQL5 есть возможность построить индикатор по значениям другого индикатора или массива. В разделе Input переменные сказано:
Пользовательские индикаторы вызываются при помощи функции iCustom(). При этом после имени пользовательского индикатора должны идти параметры в точном соответствии с объявлением input-переменных данного пользовательского индикатора. Если параметров указывается меньше, чем объявлено input-переменных в вызываемом пользовательском индикаторе, то недостающие параметры заполняются значениями, указанными при объявлении переменных.
Если в пользовательском индикаторе используется функция OnCalculate первого вида (то есть, индикатор считается на одном массиве данных), то в качестве последнего параметра при вызове такого пользовательского индикатора должно выступать одно из значений ENUM_APPLIED_PRICE либо хэндл другого индикатора. При этом все параметры, соответствующие input-переменным, должны быть явно указаны.
Кроме того, в описании функции OnCalculate сказано:
Функция OnCalculate() вызывается
только в пользовательских индикаторах при необходимости произвести
расчет значений индикатора по событию Calculate.
Обычно это происходит при поступлении нового тика по символу, для
которого рассчитывается индикатор. При этом индикатор не обязательно
должен быть прикреплен к какому-нибудь ценовому графику данного
символа.
Функция OnCalculate() должна иметь тип возвращаемого значения int. Существует два варианта определения. В пределах одного индикатора нельзя использовать оба варианта функции.
Первая форма вызова предназначена для тех индикаторов, которые могут быть рассчитаны на одном буфере данных. Пример такого индикатора - Custom Moving Average.
int OnCalculate (const int rates_total, // размер массива price[] |
P.S. Предлагаю вопросы по индикаторам обсуждать в разделе Технические индикаторы.
В продолжение предложения MetaDriver хотелось бы напомнить тему правильного представления шкалы времени в будущем.
Имея сведения о времени торговли инструментом следовало бы удалять со шкалы периоды времени, где данные будут отсутствовать.
Тогда геометрические построения будут корректны.
И еще одно предложение - может и преждевременное. Добавлено: Запоздалое похоже - хотя программ еще нет. добавить никто не мешает. тем более как следует из ответов всё строится на тиках и потом о них забываем.
Зря.
Нельзя ли расширить представление в стандартных сериях о баре информацией о среднем значении ASK & BID.
Для минуты это сумма цены тиков/ количество тиков. Нет тиков - цена открытия. Дальше проще...
В продолжение предложения MetaDriver хотелось бы напомнить тему правильного представления шкалы времени в будущем.
Имея сведения о времени торговли инструментом следовало бы удалять со шкалы периоды времени, где данные будут отсутствовать.
Тогда геометрические построения будут корректны.
Категорически не согласен. Отсутствие данных в связи с отсутствием торгов НЕ останавливает процессы изменения цен в реальности, следовательно геометрические построения будут гораздо корректнее при полной временной шкале. Когда-то я думал так же как и Вы, потом обнаружил что был грубо неправ. В общем я за строго равномерную временную шкалу.
Категорически не согласен. Отсутствие данных в связи с отсутствием торгов НЕ останавливает процессы изменения цен в реальности, следовательно геометрические построения будут гораздо корректнее при полной временной шкале. Когда-то я думал так же как и Вы, потом обнаружил что был грубо неправ. В общем я за строго равномерную временную шкалу.
Следуя Вашей логике. пропущенные нерабочие дни - заполнять данными закрытия?
Все индюки покажут кукиш. 80)
Следуя Вашей логике. пропущенные нерабочие дни - заполнять данными закрытия?
Все индюки покажут кукиш. 80)
Лишь те, что что используют данные (акромя цены закрытия) вчера.
Это и сейчас многие страдают по понедельникам, в дилингах что начинают не вровень с терминальным 00:00:00
Например про тот-же пивот...
А в целом, придерживаюсь своего мнения что на чарте должны быть все календарные бары!
пожелание к отчёту.
Неплохо было бы добавить в стандартный детализированный отчёт немного новых устоявшихся показателей.
Например, как по мне, не хватает данных о размере лота - среднего и максимально использовавшегося.
Анализ стейтмента упростился бы.
И следовало, наверно, изменить логику отчётов.
Простой отчет - итоговая картинка баланса, эквити и использованного депозита. далее статинфо.
Детализированный - всё тоже, а затем протокол сделок, открытые позиции и отложенные ордера.
И алгоритмы :)
153
Логическое продолжение темы:
http://forum.mql4.com/ru/8536