Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Спасибо за лесные отзывы. К сожалению mql4 я не знаю, начал изучение сразу с mql5-го, но уверен если Вы посмотрите на код индикатора, то без труда сможете реализовать под 4-ку, там всё очень просто.
P.S В версии 1.01 добавлен атрибут для отключения потиковой перерисовки индикатора, чтоб только тогда когда бар закончился рисовался.
Ну всё, вроде намиксовал примерно то, за что доволен, по крайней мере не чувствую пазорчика. В общем пока видом доволен, теперь буду накручивать фильтр волатильности и тренда\флета, для того чтобы грамотно миксовать на переходах из тренда во флет и наоборот и сделать красивую адаптацию, а не уродство как классический АМА.
1.12 во вложении кому интересно. ZZ и цветной не делал с него, потому как это пока только начальный этап, когда придумаю как качественно адаптивность намутить то уже, выложу готовое.
Ну всё, вроде намиксовал...
Первый вариант лучше(который в кодобазе). В этом Вы уже ПЕРЕмиксовали… ИМХО
Только что прочел, ветка - услада! Спасибо огромное всем участникам, особенно топикстартеру. Фильтрами сам никогда не занимался, но подумать вслух немного на эту тему, думаю, будет приятно.
Тут неоднократно вставал вопроса поиска количественной характеристики качества фильтра. Действительно, что лучше, JJMA или EMA и насколько? Есть некая величина отставания фильтра, как ее померить и в чем ее польза? Вообщем, нормальные такие по своей логике вопросы.
Конечно, озвучили и простой метод через сумму колен ЗигЗагов, построенных на переломах фильтра. Все почти хорошо, но не совсем.
Уважаемые авторы, раз у вас есть методы сравнения фильтров, могли бы вы привести графические, табличные или иные технарские данные этих сравнений. Далее, если вы суммируете ЗигЗаги, то давайте отнимать от каждого колена величину спреда. Строить график количественной характеристики в зависимости от периода фильтра. Накладывать полученные графики разных фильтров друг на друга и оценивать плюсы и минусы того и другого.
И опять же, ну зачем вы все настолько сильно обобщаете: фильтр на все времена? Представьте, что ваш фильтр по вечерам ведет себя граально, а в другое время страшно ошибается. Ну ведь такой фильтр великолепен! Однако, из-за подхода средней температуры по больнице вы его забракуете.
Ладно, мысли льются, букв не хватает. Предлагаю также более обобщенный подход - Один из способов исследования:
Берется понравившийся кусок истории цВР. На нем выбираются понравившиеся интервалы, для которых суммарно будет проделываться нижеследующее. Например, берем крайний месяц, и рассматриваем далее только ночные интервалы.
Задача разложить данные по косточкам и написать ТС именно под этот кусок истории (точнее под выбранные интервалы в нем), чтобы на нем ТС показывала как можно больший профит.
Т.е. задача сводится к тому, чтобы обнаружить уже на известном куске истории закономерности для максимального профита.
Очевидно, что вычислить максимально-возможный профит на куске истории очень просто. Но надо создать такую ТС, у которой показатель Profit / Func(AmountIN) был бы максимален, где AmountIN - количество явных и неявных входных параметров ТС, а Func - некая функция (для простоты начала исследования - простейшая линейная: Func(X) = X).
Например, нескольким людям нравится какой-то замечательный флэтовый кусок, который эти люди считают чуть ли не классическим рыночным флэтовым (типовым) состоянием. Люди выкладывают этот кусок публично и устраивают свого рода соревнование по созданию оптимальной ТС для этого куска. Далее сравниваются характеристики полученных ТС, идеи в них заложенные. И уже исходя из этого анализа происходит некоторое понимание формализации флэтовости и более обобщенных понятий.
P.S. Написано очень примитивно, но основа подобных манипуляций позволяет уловить суть подходов и к исследованиям посложнее.
И еще настоятельная просьба, учитывайте различия цВР. Например, ваш фильтр может показывать полную ерунду на EURUSD и быть отличным на GBPJPY. Если наблюдаются такие различия, тода логично покопать тему EURUSDvsGBPJPY. Вообщем, мест для раскопок полно.
hrenfx:
Конечно, озвучили и простой метод через сумму колен ЗигЗагов, построенных на переломах фильтра. Все почти хорошо, но не совсем.
Уважаемые авторы, раз у вас есть методы сравнения фильтров, могли бы вы привести графические, табличные или иные технарские данные этих сравнений. Далее, если вы суммируете ЗигЗаги, то давайте отнимать от каждого колена величину спреда. Строить график количественной характеристики в зависимости от периода фильтра. Накладывать полученные графики разных фильтров друг на друга и оценивать плюсы и минусы того и другого.
И опять же, ну зачем вы все настолько сильно обобщаете: фильтр на все времена? Представьте, что ваш фильтр по вечерам ведет себя граально, а в другое время страшно ошибается. Ну ведь такой фильтр великолепен! Однако, из-за подхода средней температуры по больнице вы его забракуете.
И еще настоятельная просьба, учитывайте различия цВР. Например, ваш фильтр может показывать полную ерунду на EURUSD и быть отличным на GBPJPY. Если наблюдаются такие различия, тода логично покопать тему EURUSDvsGBPJPY. Вообщем, мест для раскопок полно.
Спасибо! Осознать и формализовать алгоритм вычисления эффективности фильтра, это цель рассуждений в этой ветке, сам фильтр это мелочи, именно критерий эффективности разных фильтров для разных рынков и кластеризация по нему, позволит вычислить точку перехода в тот или иной момент между разными ТС заточенными под разные настроения рынка. Таков план.
Про учет спреда в сумматоре я уже думал, это уже дополнительный наворот с учетом конкретного ДЦ и их котировок, я пытаюсь последовательно решать задачи, чтоб каждый элемент системы был в меру автономен, чтобы была возможность понимать так сказать «чистый вклад» каждого элемента, а потом уже анализировать совокупный эффект.
Но программист я пока очень слабый и скорость кодирования удручающая, постоянно борюсь с выходами за пределы масива и тем что не прописал новый буфер вычисления индикатора и тп. Поэтому 99,9% времени трачу на технические глюки а не размышления о архитектуре ТС, это печально, но видимо неизбежно.
Подскажите пожалуйста если не жалко, какие кто применяет методы или эвристики, для исключения обращения за пределы массива? Потому как постоянно думать какой цикл с какого и по какой элемент делать по моему не кошерно. Можно ли что бы например невалидные значения и обращения за пределы цикла не нарушали логику? Допустим чтобы деление на 0 давало не ошибку а к примеру большую величину 1000 допустим, а обращение за пределы массива давало элемент с того края массива ближнего к точке обращения?
Это так… мысли новичка, я понимаю что это наверно не мужественно, возможно даже позорно в этом направлении мыслить))) Но уж простите меня, я не очень внимательный, к сожалению. Мне легче даются придумывание структур, чем их реализация, но если по каждой мелочи буду заказывать кодирование, то я разорюсь. Мелкие тесты все таки лучше самому делать.
J.B:
какие кто применяет методы или эвристики, для исключения обращения за пределы массива?
Про учет спреда в сумматоре я уже думал, это уже дополнительный наворот с учетом конкретного ДЦ и их котировок, я пытаюсь последовательно решать задачи, чтоб каждый элемент системы был в меру автономен, чтобы была возможность понимать так сказать «чистый вклад» каждого элемента, а потом уже анализировать совокупный эффект.
Про спред сказал, чтобы стереотипы совсем уж не ломать. На самом деле спреда никакого нет. Есть просто Bid и Ask ВР. Строите также ЗигЗаги, но только вершинки откладываете на Bid ВР, а низинки на Ask ВР. Тогда сумма колен будет учитывать "плавающий спред". Это на самом деле не занудство, как может показаться. И не желание супер-точно вычислять там, где можно было бы и не делать. Тут принципиальный момент: слишком частые переломы, пусть и довольно точные - зло, т.к. невыгодно.
Но программист я пока очень слабый и скорость кодирования удручающая, постоянно борюсь с выходами за пределы масива и тем что не прописал новый буфер вычисления индикатора и тп. Поэтому 99,9% времени трачу на технические глюки а не размышления о архитектуре ТС, это печально, но видимо неизбежно.
Я тоже хреновый программист. Поэтому есть такая рекомендация, не проводить подобные исследования в MQL. Использовать MQL только, как источник данных и, как простую визуализацию. А для исследований взять мат. пакет. Очень много времени и сил сэкономите.
Bid и Ask-данные брать в FXOPEN ECN или в FXCM или в Dukascopy, либо из любого тикового источника. Брать только M1, как компромисс между скоростью и точностью. Понимаю, что вряд ли кто-то будет заморачиваться, и все равно останется в MQL-рамках. Но тут надо себе просто ответить, вам исследовать или поиграться.
Класс для создания кольцевого буфера
Благодарствую! Попробую))
Про спред сказал, чтобы стереотипы совсем уж не ломать. На самом деле спреда никакого нет. Есть просто Bid и Ask ВР. Строите также ЗигЗаги, но только вершинки откладываете на Bid ВР, а низинки на Ask ВР. Тогда сумма колен будет учитывать "плавающий спред". Это на самом деле не занудство, как может показаться. И не желание супер-точно вычислять там, где можно было бы и не делать. Тут принципиальный момент: слишком частые переломы, пусть и довольно точные - зло, т.к. невыгодно.
Я тоже хреновый программист. Поэтому есть такая рекомендация, не проводить подобные исследования в MQL. Использовать MQL только, как источник данных и, как простую визуализацию. А для исследований взять мат. пакет. Очень много времени и сил сэкономите.
Bid и Ask-данные брать в FXOPEN ECN или в FXCM или в Dukascopy, либо из любого тикового источника. Брать только M1, как компромисс между скоростью и точностью. Понимаю, что вряд ли кто-то будет заморачиваться, и все равно останется в MQL-рамках. Но тут надо себе просто ответить, вам исследовать или поиграться.
Спасибо за рекомендацию! На самом деле я ей уже следую задним числом)) Пользуюсь для численных исследований STATICTICA и Matlab, для визуализаций и некоторых необычных расчетов sideFX Houdini. Но всё равно что то совсем кастомное приходится кодировать на уровне векторов(массивов) и операций с их компонентами в циклах. Поэтому волей неволей придётся изучить mql5-й для mt5 и скорей всего ещё С#
Именно 5-й выбран по следующим соображениям в порядке важности для меня:
1)mql5 аналог С++
А С++ самый продвинутый на сегодняшний день язык программирования и даже в крайнем случае если mt5-й не приживётся из за неадекватностей маркетинга, то можно будет пересесть наименее безболезненно на чистый С++ кодинг. А такой опыт не пропадёт.
Ну естественно ООП в отличии от С-подобного 4-го, которое как мощность под капотом у крутой тачки, радует как потенциал возможности реализовывать структурно сложные проекты. На процедурном языке можно будет тронуться мозгом с учетом моей внимательности и планируемой мною структурной вложенности проектов.
2)Mt5-й последняя версия mt.
Большая вероятность что последующие версии mql будут также на основе плюсов, а mt5-й продвигают на биржи, что огромный безусловный плюс и то что ДЦ сейчас массово не переходят на 5-ку на мой взгляд временное явление.
В общем я чувствую необходимость в изучении mql5 и С# для реализации идей. Я уже имею опыт заказа кодерам некоторых идей, но пришёл к выводу что имеет смысл заказывать только оболочку. А блоки прогноза и ММ делать самому. Так что языки придётся изучить хотя бы что бы грамотно давать таски и верно истимировать\вести проекты. Это конечно только ИМХО на данный момент.
Честно говоря странное видение. Какое отношение исследование цВР имеет к какой-либо платформе или языку? Это просто исследование. Можно на бумаге, можно на C-подобном языке и, как верно было вами замечено, в некоторых мат. пакетах. При этом обладающих возможностями программирования и импорта сторонних данных и DLL. Исследования и торговля - это соврешенно разные деятельности.
Поиграться - это тратить свое драгоценное время на создание исследовательской инфраструктуры с нуля: через язык программирования.
Спорить и убеждать, конечно, не буду. Все же полагал, что ветка на тему исследований.