Тестирование Систем прогнозирования в реальном времени - страница 54

 

to forte928

В данный момент есть первый фактор на основании которого можно сделать вывод о боковом флете на паре евро доллар -

пара достигла уровня консолидации линия OP на уровне 1.4850..точно такие колебания наблюдались в точках 1.3437 и 1.3937 с последующим откатом, что соотвествует уровням 0.382, 0.618 и 1.00..

на втором рисунке тотже график но с расчетными уровнями роста относительно точки минимума - 1.4162 и текущий 1.4951 и если взять на основании этого графика цены уровни 1.4951 и 1.4851 то можно заметить что цена как раз находиться в точке баланса на среднем уровне колебаний этих показателей последние два дня..Далее на графике вниз индикатор насыщение уже правтически давно показывает уровень насыщености при котором должен произойти разворот..

но есть пару моментов которые не позволяют этому произойти :

1) дневной график показывает отнисительное движение роста (нижний индикатор)

2) дневной график достигнут уровень консолидации 0.382 на уровне 1.4877 по первому признаку

3) дневной график достигнут уровень консолидации COP на уровне 1.4892 по второму признаку

4) При этом идет активное противодействие направленому движениею вверх на графике Н4

5) наличие двух уровней консолидации относительно минимального уровня конца сентября OP и 0.236 (1.4931 и 1.4933) что является сильным признаком на наличие долгой коррекции

Продолжение следует..

Спасибо огромное за разъяснение, надо сказать, что я отказался от ТА несколько лет назад (для себя), но всегда интересно почитать грамотный анализ и сравнить его со своими прогнозами. Не могли бы пояснить термин "уровень консолидации" для большего понимания и во избежании путаницы в терминологии.


to lea

Вы не пробовали искать критические точки у временного ряда?

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


PS: Кстати, помниться Вы обещали улучшить свою линейную библиотеку и выложить новую версию...


to Yurixx

1. В МКЛ4 ты не можешь оперировать с массивом размер которого не задан. Если про объявлении массива ты не указал его размер, то в init() ты это должен сделать обязательно. Дальше, в процессе работы ты этот размер можешь изменить по потребности.


тут не очень понял. я этого не делаю и все работает, в смысле без инициализации в init()


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

Мне кажется не очень он практичный, поскольку совершенно очевидно наличие большего количества вычислений. К перечисленному можно добавить дополнительные циклы. Но все равно, нужно все проверить, вот если бы услышать рекомендации разработчиков ... :о)

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

Ну например (и это самый простой пример) поиск локальных экстремумов (не на графике) по условию y[n]>y[n+1] и y[n]<y[n-1] и соответственно для минимума. Я понимаю, что можно решить несколькими способами, например таким:

  • Создать массив такой же длины, как и исходный ряд, кодировать в нем 0 и 1 наличие экстремума.
  • Выполнить первую итерацию собрав расчет экстремумов
  • Пересчитать количество экстремумов
  • Инициализировать массив этой величиной
  • Записать значения в новый массив
Можно так, можно иначе, я же пытаюсь понять, как лучше :о)

В наперстки не играю. Но по виду мне больше нравится вариант 2. Или это мне просто хочется чтобы евра росла ? :-)

Как ты заметил, я и не предлагал наперстки как таковые. Все же открыто, просто было интересно твое мнение (я читал на соседней теме твой прогноз )

Но варианты 1 и 3 тоже ничего, хотя они мало чем друг от друга отличаются.

"Разнонаправленным вектором" смещением среднего значения цены


to Urain

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

MQL вроде нет статистических/динамических "указателей" на место хранения массива. Есть только один оператор инициализации, вопрос лишь в том, что многократное его применение может замедлить работу на большом массиве. Или не так? Или я опять чего то не понял?


to markeeteer

фильтруйте информацию с форума

О, это ценное качество. Могу Вас заверить - у меня стоят самые лучшие адаптивные фильтры. :о)

Если опишите задачку поподробнее (можно в личку), мы (я) прикинем, как это лучше реализовать

Я подумаю, но сейчас хочется самому разобраться. Ведь надо хоть что то понимать в MQL, что бы хоть как то объяснять задачу :о)

 
А была такая тихая веточка. (
 
Lord_Shadows >>:
А была такая тихая веточка. (

Думаю, такой останется. Коллеги просто еще в боевом режиме :о)

 
grasn писал(а) >>

to Yurixx

тут не очень понял. я этого не делаю и все работает, в смысле без инициализации в init()

Инициализация массива - это одно, а объявление размера другое. Если ты объявил массив как Arr[], то в памяти ему отводится один элемент. Можешь с ним работать сколько угодно, и система тебе ничего не скажет об ошибке когда ты будешь обращаться к элементам с номером >0, но вычисления будут некорректными. Чтобы все было хорошо нужно операцией ArrayResize() задать конкретный размер. При выделении памяти при этом все элементы будут забиты нулями, так что если ничего особенного не требуется можно даже не инициализировать (хотя хороший стиль этого требует).

.

Мне кажется не очень он практичный, поскольку совершенно очевидно наличие большего количества вычислений. К перечисленному можно добавить дополнительные циклы. Но все равно, нужно все проверить, вот если бы услышать рекомендации разработчиков ... :о)

Совет Леа не приводит к бОльшему количеству вычислений. Разберись с этим внимательней. А если ты еще и разработчиков привлечешь к этому элементарному вопросу, то будешь вообще героем. :-)

.

Ну например (и это самый простой пример) поиск локальных экстремумов (не на графике) по условию y[n]>y[n+1] и y[n]<y[n-1] и соответственно для минимума. Я понимаю, что можно решить несколькими способами, например таким:

  • Создать массив такой же длины, как и исходный ряд, кодировать в нем 0 и 1 наличие экстремума.
  • Выполнить первую итерацию собрав расчет экстремумов
  • Пересчитать количество экстремумов
  • Инициализировать массив этой величиной
  • Записать значения в новый массив

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

Сергей, начни лучше с самого сложного варианта. А то непонятно вокруг чего сыр-бор. :-)))

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

 
Yurixx >>:
grasn писал(а) >>

Ну например (и это самый простой пример) поиск локальных экстремумов (не на графике) по условию y[n]>y[n+1] и y[n]<y[n-1] и соответственно для минимума. Я понимаю, что можно решить несколькими способами, например таким:

  • Создать массив такой же длины, как и исходный ряд, кодировать в нем 0 и 1 наличие экстремума.
  • Выполнить первую итерацию собрав расчет экстремумов
  • Пересчитать количество экстремумов
  • Инициализировать массив этой величиной
  • Записать значения в новый массив

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

Эх, отклонились от темы совсем ;-). Обычно я стараюсь по максимуму использовать те возможности (API, библиотеки и пр.), которые уже существуют для конкретных задач. У частности, не продуктивнее ли для нахождения экстремумов пользоваться функциями ArrayMinimum/Maximum? Кроме того, выбор способа хранения экстремумов должен таки определяться последующими операциями, которые с ними планируется выполнять. В частности, я так полагаю, что по экстремумам нужно будет потом пройтись в каком-то расчете, и тогда тот способ, который предложил grasn самый оптимальный - он выполняется в одном цикле и потом позволяет легко итерировать экстремумы.
 
grasn писал(а) >>

to lea

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

PS: Кстати, помниться Вы обещали улучшить свою линейную библиотеку и выложить новую версию...

Понятно, спасибо за ответ.

Работу над библиотекой в принципе довёл до завершающей стадии ещё месяца два назад (выкинул лишние функции, переделал существующие). Правда, расчет степени обусловленности матриц так и не сделал. Недели через две стану посвободнее, тогда буду разбираться.

Статью тогда начал писать, но времени не хватало. В настоящее время готово 50% описаний функций (это 6 групп функций из 16; пока что напишу только документацию по функциям, позже будут примеры использования).

 

Что-то у меня плохо получается с прогнозами поэтому сегодня, с понедельника решил поэксперементировать с М1:

Не вижу основного графика :)

Зато переоптимизация каждую минуту и прогноз на 3 ч. вперёд.


 
Piboli >>:

Что-то у меня плохо получается с прогнозами поэтому сегодня, с понедельника решил поэксперементировать с М1:

Не вижу основного графика :)

Зато переоптимизация каждую минуту и прогноз на 3 ч. вперёд.



А как вы перептимизацию проводите? И прогнозы где получаете, не в дедукторе случайно?

 
mpeugep >>:

А как вы перептимизацию проводите? И прогнозы где получаете, не в дедукторе случайно?


бедный Piboli, его уже раза 4-ре спрашивали ^_^, да, прогнозы он делает в Дедукторе
 

прогноз более менее совпадает (тот у которого максимальная энтропия) :о) Небольшое уточнение, остаются следующие траектории, причем та, которая "канальная", наиболее вероятная.



to lea

Понятно

я старался :о)

Работу над библиотекой в принципе довёл до завершающей стадии ещё месяца два назад (выкинул лишние функции, переделал существующие). Правда, расчет степени обусловленности матриц так и не сделал.

но там написано

Код будет выложен позже.

а версия не изменилась :о(

Причина обращения: