Проект советника - страница 7
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
То есть как это "ATR не считаю за индикатор" ???
И как это "не годится, как сигнал для входа ??? А я-то дурень, использую вход "пробой волатильности" с использованием исключительно этого индикатора...
Я так подозреваю, что у вас свое, особое понимание сущности индикаторов... Для меня индикатор - это объект, который может выдавать некоторое изменяемое значение, в зависимости от времени. По сути, даже обычный свечной график цены - это тоже индикатор. А для вас это что-то другое... Соответственно, и понимание у нас разное.
если по существу то
индикатор = инструмент(прибор) показывающий какие либо изменения в чем либо.
с этой точки зрения АТР индикатор.
я же в моем посте подразумевал слово индикатор как поставщик сигналов для входа в рынок.(речь шла о тестировании индикаторов для торговли в режиме "постоянно в рынке"). как следствие они должны показывать сигнал для входа и разворота без тейков, стопов и сопровождения как такового). торговых систем очень много, я же искал возможность торговать чисто по индикатору находясь всегда в рынке. пробой волатильности, насколько мне известно торгуется с определенным тейком и стопом.
с уважением.
Я не вижу особой разницы - как я понимаю, WS (WareStore, вероятно ?) - это все тот же мой дата-провайдер.
Это аббревиатура от WorkSymbol. Короткое сокращение выбрано специально, из-за частого обращения к этому объекту.
Подозреваю, что в инициализации для объекта WS должны быть какие-то предварительные действия.
В WS - это экземпляр объекта CSymbol, конструктор по-умолчанию которого использует текущий символ Symbol(). Поэтому WS не требует инициализации из вне. Он просто создается вместе с классом стратегии.
В эксперте могут существовать много различных контейнеров разных символов и разных таймфреймов. Идеология дата-провайдера позволяет не дублировать их. Поскольку реально - все таймсерии хранятся именно в нем, а контейнеры - просто указывают на необходимые.
В итоге получается один мега-класс ядро, к которому обращаются классы-эксперты. Чем это отличается от базового MQL, когда есть ядро MetaTrader и сотни его функций, которые к нему обращаются?
Если считать за провайдер данных сам МТ4-5, а наш класс использовать только для обеспечения доступа - то, выходит, по вашему обращению к цене Open - мы должны вызывать функцию CopyOpen() для одного значения - мне это кажется неразумным.
Именно так. Только такое обращение гарантирует единство представления данных и полную синхронизацию состояний. Не надо делать каких-либо обновлений котировок (которые можно и забывать), не нужно использовать кучу дополнительных тумблеров, которые неизбежно возникают при создании посредника-хранилища данных. Не надо искать в базе данные, соответствующие запрошенным. Если мой эксперт делает:
То он гарантировано знает что WS.High[1] вернет ему предыдущий экстремум, не зависимо от того, как обновляется торговое окружение. Да, вызывать при каждом запуске CopyHigh и копировать одно единственное значение double накладно, зато 100% надежно. Раз классы-обложки не хранят данные, а лишь передают вызову системным функциям, то не может возникнут ситуации, когда хранимые данные не соответствуют текущему окружению.
Давать полный глобальный доступ ко всем переменным в любом месте программы я также считаю крайне неразумным, наоборот, я стараюсь в каждом месте программы иметь доступ исключительно только к тем структурам и данным, которые необходимы для данного действия. Все остальное - должно быть недоступно. Идеология дата-провайдера как раз позволяет контролировать этот доступ.
Георг, по факту ты уже создал этот глобальный доступ. У тебя есть один большой супер-класс провайдер, к которому обращаются все. Это и есть один большой глобальный пул объектов (индикаторов, таймсерий и пр. пр.) который собран под фантиком ООП. Т.е. ООП превратилось в примере с дата-провайдером в фикцию. Оно есть формально, но его нет в реальности.
Георг, по факту ты уже создал этот глобальный доступ. У тебя есть один большой супер-класс провайдер, к которому обращаются все. Это и есть один большой глобальный пул объектов (индикаторов, таймсерий и пр. пр.) который собран под фантиком ООП. Т.е. ООП превратилось в примере с дата-провайдером в фикцию. Оно есть формально, но его нет в реальности.
Нет, я сравнивал скорости работы, когда размещаю буффера в дата-провайдере, или получаю данные каждый раз по CopyXXX - у меня выходило в разы быстрее обращение к своему буфферу. Поэтому я и остановился именно на своих буфферах, ну а Дата-провайдер - это просто централизованное хранилище этих самых буфферов.
Действительно, наличие "прослойки" - этого самого дата-провайдера вносит опасность рассинхронизации данных. Но с такой проблемой я пока ни разу не сталкивался, а вот скорость дата-провайдер экономит достаточно явно. Собственно, по-моему, это испытание уже многие проводили - у всех получалось, что выгоднее при обработке тика один раз скопировать себе данные, и пользоваться ими, а не обращаться каждый раз к терминалу за данными.
Сейчас это по-другому ? И скорость ряда обращений через CopyXXX за каждым double значением такая же, как и одно обращение сразу за всем диапазоном, а потом - обращение в буффер за значениями ?
Нет, я сравнивал скорости работы, когда размещаю буффера в дата-провайдере, или получаю данные каждый раз по CopyXXX - у меня выходило в разы быстрее обращение к своему буфферу. Поэтому я и остановился именно на своих буфферах, ну а Дата-провайдер - это просто централизованное хранилище этих самых буфферов.
Действительно, наличие "прослойки" - этого самого дата-провайдера вносит опасность рассинхронизации данных. Но с такой проблемой я пока ни разу не сталкивался, а вот скорость дата-провайдер экономит достаточно явно. Собственно, по-моему, это испытание уже многие проводили - у всех получалось, что выгоднее при обработке тика один раз скопировать себе данные, и пользоваться ими, а не обращаться каждый раз к терминалу за данными.
Сейчас это по-другому ? И скорость ряда обращений через CopyXXX за каждым double значением такая же, как и одно обращение сразу за всем диапазоном, а потом - обращение в буффер за значениями ?
Спору нет, значительно быстрее скопировать все котировки за один раз во внутреннюю память эксперта (дата провайдер) и затем дергать от туда значения, чем постоянно вызвать CopyBuffer. Но такова цена системы построенной на состоянии. Вообще вся наша предметная область - написание советников, скриптов и т.д. это программирование систем на основе состояний: есть ордер - обрабатываем правила его сопровождения. Нет ордера - смотрим условия его открытия.
Что касается CopyBuffer, то копировать большие куски котировок и замерять прирост производительности получается только в синтетических тестах. На практике эксперт в 90% случаях работает с последним баром на каждом тике, либо в момент открытия нового бара. Следовательно данные о последнем баре запрашиваются всегда, и идет постоянный вызов CopyBuffer с копированием последнего бара в кеш.
Единственное реальное увеличение производительности будет в том случае, если эксперту требуется N последних баров, где N число существенно больше 1. Но что такое запрос N последних баров? Это работа в скользящем окне (99% всей работы эксперта). А скользящее окно, это кольцевой буфер по своей сути. Следовательно, при запросе N последних баров, в реальности требуется обновить, либо добавить лишь один, последний бар. Т.е. вся эта история с копированием блока данных - очень красивая история, но она не работает в той предметной области для которой она создавалась, а работают, при том весьма успешно, именно кольцевые буфера.
Сейчас мой CSymbol работает просто передавая нужный индекс. Но я могу модернизировать его таким образом, что он будет кешировать N последних баров, при том N будет выбираться самим CSymbol, в зависимости от максимально запрашиваемого индекса. И тогда, без всяких внешних изменений, CSymbol на некоторых задачах, будет работать в разы быстрее чем постоянный вызов CopyBuffer. Вот в этом и сила ООП. После накопления определенного оверхеда, связанного с использованием дополнительных обвязок, наступает качественный скачок, когда за счет адаптивных алгоритмов, можно в разы сократить использование памяти либо процессорного времени.
Здравствуйте.
Пишу огромные блоки кода занимающие сотни строк. Почти без комментариев. Без ООП. Код на русском. Все работает очень эффективно. Никаких проблем с орентированием в программе не испытываю, хотя имеется около 100 подключенных файлов. Наверное потому что уже привык и все давно запомнил. Поэтому главное - знать свою программу и хорошо ее понимать, остальное вторично. Имхо.
Пишу огромные блоки кода занимающие сотни строк. Почти без комментариев. Без ООП. Код на русском. Все работает очень эффективно. Никаких проблем с орентированием в программе не испытываю, хотя имеется около 100 подключенных файлов. Наверное потому что уже привык и все давно запомнил. Поэтому главное - знать свою программу и хорошо ее понимать, остальное вторично. Имхо.
Вы из 1С в MQL пришли?
Я самоучка. Первый язык программирования который освоил - MQL4. После немного попрактиковался на С# и С++.
Про 1с не слышал. А что это?
Что касается CopyBuffer, то копировать большие куски котировок и замерять прирост производительности получается только в синтетических тестах. На практике эксперт в 90% случаях работает с последним баром на каждом тике, либо в момент открытия нового бара. Следовательно данные о последнем баре запрашиваются всегда, и идет постоянный вызов CopyBuffer с копированием последнего бара в кеш.
Так ведь нам и нужна скорость работы вот именно в "синтетическом тесте" - скорость становится критичной при переборе вариантов в тестере стратегий. Именно тестер стратегий для меня является "бутылочным горлом", где требуется скорость.
Как раз, действительно, в реальной работе - с головой хватает скорости прямых обращений к данным через CopyXXX каждый раз. Но, для прогнов в тестере - разница в скорости очень важна.
Так ведь нам и нужна скорость работы вот именно в "синтетическом тесте" - скорость становится критичной при переборе вариантов в тестере стратегий. Именно тестер стратегий для меня является "бутылочным горлом", где требуется скорость.
Как раз, действительно, в реальной работе - с головой хватает скорости прямых обращений к данным через CopyXXX каждый раз. Но, для прогнов в тестере - разница в скорости очень важна.
Объясню проще: в самом основании твоего дата-провайдера находится функция CopyXXX, копирующая самый последний символ. В основании моего CSymbol лежит также CopyXXX, копирующая тот же последний символ. Обе функции работают медленно. Следовательно и твой и мой код - медленные, т.к. вызов CopyXXX обойти нельзя. Но мой код проще и меньше. Тогда зачем вся эта многоэтажная надстройка над CopyXXX, если она не решает саму проблему CopyXXX?