Общая концепция терминала. У меня тупиковая ситуация?
Дано: поисковая машина для нахождения паттернов на заданном инструменте и заданном периоде.
Пользователь этой "машины" открывает одновременно необходимое ему количество инструментов (только инструментов, не периодов) - может быть скажем 200 (фьючерсы, вся сводная информация дополнительно визуализируется на отдельно открытом графике).
На каждый открытый график добавляется советник, который одновременно оперирует всеми заданными пользователем периодами (рекомендуется мною 16) данного инструмента. Приближённо можно считать, что пользователь просто открыл 200 х 16 = 3200 графиков.
Потребляемая оперативная память при этом на начальном этапе будет лимитироваться глобальным параметром - "Макс. баров в окне" (потом будет происходить расширение потребления).
Обычно на паттерных системах работают на N последних барах, посему здесь особо проблем не возникает - выставил минимальное количество баров 5000 и живёшь более-менее спокойно.
Но для паттерной системы необходим так же стат. анализ, да желательно бы и с визуализацией. И тут мы врезаемся в стену. Нам нужно для конкретно открытого графика не 5000 баров, а 1 000 000 (скажем минутки за пару-тройку лет).
Если мы изменим "Макс. баров в окне", то это отразится на 200-х сот открытых графиках (пусть не в данный момент, после перезагрузки терминала точно) и на наложенных на них индикаторах и т.д. чего нам не нужно.
Даже если оперативной памяти много и терминал x64 - на просчет дополнительных (стандартных и не стандартных) индикаторов требуется в разы больше ресурсов, чем на самом деле это необходимо пользователю в работе.
Так вот. Как же быть то? Или я где-то не прав и чего-то не знаю / не умею?
P.S. Моя точка зрения простая - каждый график должен иметь своё значение "Макс. баров в окне", тогда никаких проблем возникнуть не должно.
А ещё можно сосчитать все молекулы воды в океане и по их состоянию вывести прогноз погоды на ближайшие пять секунд :о)
Просто не верно ставите задачу, вот и выходит такое потребление ресурсов. Уберите всё лишнее и наверняка можно будет посчитать всё быстрее и с меньшими затратами памяти.
Просто не верно ставите задачу, вот и выходит такое потребление ресурсов. Уберите всё лишнее и наверняка можно будет посчитать всё быстрее и с меньшими затратами памяти.
P.S. Моя точка зрения простая - каждый график должен иметь своё значение "Макс. баров в окне", тогда никаких проблем возникнуть не должно.
Лишнее - это торговать на одном инструменте?
Нет, я не это имел в виду. Оптимизировать можно на потребление памяти или на быстродействие. Иногда и на то и другое. Но если под конец разработки уже всё оптимизировали, а всё равно в приемлемые рамки не влазит. То нужно выбирать на память или быстродействие. Я не знаю всех тонкостей вашей задачи. Но если в конце концов решение задачи по выбранной схеме не влазит в заданные ресурсы, то меняют схему решения задачи.
Помнится я как-то очень давно хотел посчитать коэф. всех гармоник находящихся в суммарной составляющей. До трёх гармоник подходил перебор. И была эйфория как всё просто решается, они все дураки (а я хозяин Форекса). Но когда увеличил количество гармоник комп завис. Сделал замеры оказывается что он не висит а считает. И считать он будет ещё 1486 лет :о) А задача решается через разложение Фурье. Вот так замена схемы решения (ну или назовите это моделью) приводит к приемлемому решению с использованием отведённых ресурсов.
Нет, я не это имел в виду. Оптимизировать можно на потребление памяти или на быстродействие. Иногда и на то и другое. Но если под конец разработки уже всё оптимизировали, а всё равно в приемлемые рамки не влазит. То нужно выбирать на память или быстродействие. Я не знаю всех тонкостей вашей задачи. Но если в конце концов решение задачи по выбранной схеме не влазит в заданные ресурсы, то меняют схему решения задачи.
Помнится я как-то очень давно хотел посчитать коэф. всех гармоник находящихся в суммарной составляющей. До трёх гармоник подходил перебор. И была эйфория как всё просто решается, они все дураки (а я хозяин Форекса). Но когда увеличил количество гармоник комп завис. Сделал замеры оказывается что он не висит а считает. И считать он будет ещё 1486 лет :о) А задача решается через разложение Фурье. Вот так замена схемы решения (ну или назовите это моделью) приводит к приемлемому решению с использованием отведённых ресурсов.
Тут понимаете в чём дело. Сам поисковый движок полностью оптимизированный, работает и отображается он только на последних N заданных барах.
Речь идёт про стандартные механизмы, вот нарисовал обычную ситуацию:
но для работы со статистикой нам мало 5 тыс баров и мы получаем вот такую картину:
Она говорит нам о том, что 200 открытых графиков используются всего на 0,02%, а индикаторы, к примеру стандартные там рассчитываются по всей истории.
Т.е. происходят не подконтрольные программисту процессы (а они требуют ресурсов)
Если бы для каждого графика можно было задать кол-во баров - это бы решило все проблемы.
P.S. Это единственная глобальная переменная, не пора ли от неё избавится?
Тут сложности возникнут не только при организации "Поисковой машины", но и при обработке результатов ее работы.Такой огромный массив выходной информации должен быть понятен не только пользователю но и торговым экспертам. Разумнее в таких случаях подключать внешние источники информации(БД) в которых будет собиратся и хранится все необходимая статистическая информация по каждому виду паттернов на любом инструменте для любого периода.
Была и у меня такая мысль. Например, индикатор считается на минутках (нужно очень много баров), а результат отображается на часовых барах или более старших таймфреймах, где достаточно и сотни баров. Одним из выходов может быть такой: позволить при помощи CopyХХХХ() получать значения за пределами параметра TERMINAL_MAXBARS.
Мои эксперименты
MqlRates Mas[]; int res = CopyRates("EURUSD", PERIOD_M1, 0, 200000, Mas);
и переменной "Макс. баров в окне" (с закрытием/открытием программы и графиков) показали крайне не стабильные результаты возврата.
Зачастую не получалось у функции вернуть за пределами TERMINAL_MAXBARS
Мои эксперименты
и переменной "Макс. баров в окне" (с закрытием/открытием программы и графиков) показали крайне не стабильные результаты возврата.
Зачастую не получалось у функции вернуть за пределами 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
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Дано: поисковая машина для нахождения паттернов на заданном инструменте и заданном периоде.
Пользователь этой "машины" открывает одновременно необходимое ему количество инструментов (только инструментов, не периодов) - может быть скажем 200 (фьючерсы, вся сводная информация дополнительно визуализируется на отдельно открытом графике).
На каждый открытый график добавляется советник, который одновременно оперирует всеми заданными пользователем периодами (рекомендуется мною 16) данного инструмента. Приближённо можно считать, что пользователь просто открыл 200 х 16 = 3200 графиков.
Потребляемая оперативная память при этом на начальном этапе будет лимитироваться глобальным параметром - "Макс. баров в окне" (потом будет происходить расширение потребления).
Обычно на паттерных системах работают на N последних барах, посему здесь особо проблем не возникает - выставил минимальное количество баров 5000 и живёшь более-менее спокойно.
Но для паттерной системы необходим так же стат. анализ, да желательно бы и с визуализацией. И тут мы врезаемся в стену. Нам нужно для конкретно открытого графика не 5000 баров, а 1 000 000 (скажем минутки за пару-тройку лет).
Если мы изменим "Макс. баров в окне", то это отразится на 200-х сот открытых графиках (пусть не в данный момент, после перезагрузки терминала точно) и на наложенных на них индикаторах и т.д. чего нам не нужно.
Даже если оперативной памяти много и терминал x64 - на просчет дополнительных (стандартных и не стандартных) индикаторов требуется в разы больше ресурсов, чем на самом деле это необходимо пользователю в работе.
Так вот. Как же быть то? Или я где-то не прав и чего-то не знаю / не умею?
P.S. Моя точка зрения простая - каждый график должен иметь своё значение "Макс. баров в окне", тогда никаких проблем возникнуть не должно.