Скачать MetaTrader 5

Общая концепция терминала. У меня тупиковая ситуация?

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

Дано: поисковая машина для нахождения паттернов на заданном инструменте и заданном периоде.

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

На каждый открытый график добавляется советник, который одновременно оперирует всеми заданными пользователем периодами (рекомендуется мною 16) данного инструмента. Приближённо можно считать, что пользователь просто открыл 200 х 16 = 3200 графиков.

Потребляемая оперативная память при этом на начальном этапе будет лимитироваться глобальным параметром - "Макс. баров в окне" (потом будет происходить расширение потребления).


Обычно на паттерных системах работают на N последних барах, посему здесь особо проблем не возникает - выставил минимальное количество баров 5000 и живёшь более-менее спокойно.

Но для паттерной системы необходим так же стат. анализ, да желательно бы и с визуализацией. И тут мы врезаемся в стену. Нам нужно для конкретно открытого графика не 5000 баров, а 1 000 000 (скажем минутки за пару-тройку лет).

Если мы изменим "Макс. баров в окне", то это отразится на 200-х сот открытых графиках (пусть не в данный момент, после перезагрузки терминала точно) и на наложенных на них индикаторах и т.д. чего нам не нужно.


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


Так вот. Как же быть то? Или я где-то не прав и чего-то не знаю / не умею?

P.S. Моя точка зрения простая - каждый график должен иметь своё значение "Макс. баров в окне", тогда никаких проблем возникнуть не должно.

Документация по MQL5: Доступ к таймсериям и индикаторам / Bars
Документация по MQL5: Доступ к таймсериям и индикаторам / Bars
  • www.mql5.com
Доступ к таймсериям и индикаторам / Bars - Документация по MQL5
Nikolay Demko
12559
Nikolay Demko  
AlexSTAL:

Дано: поисковая машина для нахождения паттернов на заданном инструменте и заданном периоде.

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

На каждый открытый график добавляется советник, который одновременно оперирует всеми заданными пользователем периодами (рекомендуется мною 16) данного инструмента. Приближённо можно считать, что пользователь просто открыл 200 х 16 = 3200 графиков.

Потребляемая оперативная память при этом на начальном этапе будет лимитироваться глобальным параметром - "Макс. баров в окне" (потом будет происходить расширение потребления).


Обычно на паттерных системах работают на N последних барах, посему здесь особо проблем не возникает - выставил минимальное количество баров 5000 и живёшь более-менее спокойно.

Но для паттерной системы необходим так же стат. анализ, да желательно бы и с визуализацией. И тут мы врезаемся в стену. Нам нужно для конкретно открытого графика не 5000 баров, а 1 000 000 (скажем минутки за пару-тройку лет).

Если мы изменим "Макс. баров в окне", то это отразится на 200-х сот открытых графиках (пусть не в данный момент, после перезагрузки терминала точно) и на наложенных на них индикаторах и т.д. чего нам не нужно.


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


Так вот. Как же быть то? Или я где-то не прав и чего-то не знаю / не умею?

P.S. Моя точка зрения простая - каждый график должен иметь своё значение "Макс. баров в окне", тогда никаких проблем возникнуть не должно.

А ещё можно сосчитать все молекулы воды в океане и по их состоянию вывести прогноз погоды на ближайшие пять секунд :о)

Просто не верно ставите задачу, вот и выходит такое потребление ресурсов. Уберите всё лишнее и наверняка можно будет посчитать всё быстрее и с меньшими затратами памяти.


Aleksandr Chugunov
4920
Aleksandr Chugunov  
Urain:

Просто не верно ставите задачу, вот и выходит такое потребление ресурсов. Уберите всё лишнее и наверняка можно будет посчитать всё быстрее и с меньшими затратами памяти.

Лишнее - это торговать на одном инструменте?
Konstantin Gruzdev
14611
Konstantin Gruzdev  
AlexSTAL:

P.S. Моя точка зрения простая - каждый график должен иметь своё значение "Макс. баров в окне", тогда никаких проблем возникнуть не должно.

Была и у меня такая мысль. Например, индикатор считается на минутках (нужно очень много баров), а результат отображается на часовых барах или более старших таймфреймах, где достаточно и сотни баров. Одним из выходов может быть такой: позволить при помощи CopyХХХХ() получать значения за пределами параметра TERMINAL_MAXBARS.
Nikolay Demko
12559
Nikolay Demko  
AlexSTAL:
Лишнее - это торговать на одном инструменте?

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

Помнится я как-то очень давно хотел посчитать коэф. всех гармоник находящихся в суммарной составляющей. До трёх гармоник подходил перебор. И была эйфория как всё просто решается, они все дураки (а я хозяин Форекса). Но когда увеличил количество гармоник комп завис. Сделал замеры оказывается что он не висит а считает. И считать он будет ещё 1486 лет :о) А задача решается через разложение Фурье. Вот так замена схемы решения (ну или назовите это моделью) приводит к приемлемому решению с использованием отведённых ресурсов.

Ruslan Khasanov
3072
Ruslan Khasanov  
Тут  сложности возникнут не только при организации "Поисковой машины", но и при обработке результатов ее работы.Такой огромный массив выходной информации должен быть понятен не только пользователю но и торговым экспертам. Разумнее в таких случаях подключать внешние источники информации(БД) в которых будет собиратся и хранится все необходимая статистическая информация по каждому виду паттернов на любом инструменте для любого периода.
Aleksandr Chugunov
4920
Aleksandr Chugunov  
Urain:

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

Помнится я как-то очень давно хотел посчитать коэф. всех гармоник находящихся в суммарной составляющей. До трёх гармоник подходил перебор. И была эйфория как всё просто решается, они все дураки (а я хозяин Форекса). Но когда увеличил количество гармоник комп завис. Сделал замеры оказывается что он не висит а считает. И считать он будет ещё 1486 лет :о) А задача решается через разложение Фурье. Вот так замена схемы решения (ну или назовите это моделью) приводит к приемлемому решению с использованием отведённых ресурсов.

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

Речь идёт про стандартные механизмы, вот нарисовал обычную ситуацию:


но для работы со статистикой нам мало 5 тыс баров и мы получаем вот такую картину:


Она говорит нам о том, что 200 открытых графиков используются всего на 0,02%, а индикаторы, к примеру стандартные там рассчитываются по всей истории.

Т.е. происходят не подконтрольные программисту процессы (а они требуют ресурсов)

Если бы для каждого графика можно было задать кол-во баров - это бы решило все проблемы.

P.S. Это единственная глобальная переменная, не пора ли от неё избавится?

Aleksandr Chugunov
4920
Aleksandr Chugunov  
Kos:
Тут  сложности возникнут не только при организации "Поисковой машины", но и при обработке результатов ее работы.Такой огромный массив выходной информации должен быть понятен не только пользователю но и торговым экспертам. Разумнее в таких случаях подключать внешние источники информации(БД) в которых будет собиратся и хранится все необходимая статистическая информация по каждому виду паттернов на любом инструменте для любого периода.
Вот с этим то как раз проблем никаких нет....
Aleksandr Chugunov
4920
Aleksandr Chugunov  
Lizar:
Была и у меня такая мысль. Например, индикатор считается на минутках (нужно очень много баров), а результат отображается на часовых барах или более старших таймфреймах, где достаточно и сотни баров. Одним из выходов может быть такой: позволить при помощи CopyХХХХ() получать значения за пределами параметра TERMINAL_MAXBARS.

Мои эксперименты

   MqlRates Mas[];
   int res = CopyRates("EURUSD", PERIOD_M1, 0, 200000, Mas);

и переменной "Макс. баров в окне" (с закрытием/открытием программы и графиков) показали крайне не стабильные результаты возврата.

Зачастую не получалось у функции вернуть за пределами TERMINAL_MAXBARS


Konstantin Gruzdev
14611
Konstantin Gruzdev  
И я про это, нет такой возможности. А если бы была, то часть проблем была бы снята.
Nikolay Demko
12559
Nikolay Demko  
AlexSTAL:

Мои эксперименты

и переменной "Макс. баров в окне" (с закрытием/открытием программы и графиков) показали крайне не стабильные результаты возврата.

Зачастую не получалось у функции вернуть за пределами TERMINAL_MAXBARS


У меня всё работает. Количество данных в окне выставлено Unlimited

   int count=Bars("EURUSD", PERIOD_M1);
   MqlRates Mas[];
   int res = CopyRates("EURUSD", PERIOD_M1, 0,count, Mas);
   Print("res=",res," count=",count);
   Print("Mas[0]=",Mas[0].time," Mas[count-1]=",Mas[count-1].time);
2011.03.01 18:03:52     Листок 20 (EURUSD,M15)  Mas[0]=2010.03.01 00:00:00 Mas[count-1]=2011.03.01 17:03:00
2011.03.01 18:03:52     Листок 20 (EURUSD,M15)  res=370270 count=370270
1234
Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий