Обсуждение статьи "Применение OLAP в трейдинге (Часть 1): Основы оперативного анализа многомерных данных"
Спасибо, наглядный пример применения получился. На коленке, если быстро нужно смотреть различные срезы, хорошо получилось.
Уровню абстракции завидую белой завистью.
ЗЫ В тексте статьи случайно затесался MarketInfo. В исходниках - норм.
Не в порядке критики, а по логике статьи:
правильнее было назвать статью "Применение OLAP в анализе результатов трейдинга", а то по названию создаётся впечатление, что будет анализ рыночной динамики. А выясняется, что эксперт неторгующий.
Но статья интересная, именно с точки зрения анализа нерыночных, конечных данных.
правильнее было назвать статью "Применение OLAP в анализе результатов трейдинга"
Что название неверное это точно.
Имхо, лучше было бы назвать как-нибудь так: "Работа с многомерными пространствами в трейдинге с помощью технологии OLAP". А так читаешь и думаешь: что за OLAP, и зачем это здесь?
Вообще на сколько понимаю, в статье предлагается некий класс-контейнер и соответствующая к нему инфраструктура, который удобно хранит вектора (вектор именно в статистическом значении: т.е. набор значений характеризующий точку в многомерном пространстве). В принципе и без этого контейнера можно сгруппировать данные так как нужно. Однако визуализировать многомерные пространства уже гораздо сложней. Но к сожалению в статье об этом не написано, однако я уверен, в OLAP есть инструменты визуализации.
Что название неверное это точно.
Имхо, лучше было бы назвать как-нибудь так: "Работа с многомерными пространствами в трейдинге с помощью технологии OLAP". А так читаешь и думаешь: что за OLAP, и зачем это здесь?
лучше бы про трейдинг статей побольше было
а так получается что программисты свои наработки из других областей скидывают. Непонятно зачем, непонятно кому
думаю, у многих вертелось на языке, просто озвучил ))
лучше бы про трейдинг статей побольше было
а так получается что программисты свои наработки из других областей скидывают. Непонятно зачем, непонятно кому
думаю, у многих вертелось на языке, просто озвучил ))
Ну не знаю, я уж лучше про OLAP почитаю чем статьи вроде "Мартингейл как основа долгосрочной торговой стратегии".
В статье представлены универсальные классы, с помощью которых можно анализировать любые числовые данные связанные с торговлей (про это упомянуто), потому в названии "трейдинг".
Считаю данный инструмент очень полезным для трейдинга, из разряда must have. Если кто-то хочет что-то более "трейдерское" - уж не знаю по каким критериям - оставляйте конкретные пожелания в соответствующей ветке на форуме, где есть таблица "хотелок".
Вот цитата из начала статьи:
//----------------------------
"Для торгового отчета может быть интересно получить разбивку прибылей по символам, дням недели, покупкам и продажам. Или, например, сравнить показатели нескольких торговых роботов (т.е. раздельно для каждого магического числа).
Конец цитаты.
//----------------------------
Это практическая задача, решение которой обуждается далее по тексту. След.цитата:
//---------------------------
"Для чтения записей из некоего абстрактного источника (которым в будущем может оказаться история торгового счета, CSV-файл, HTML-отчет или данные из интернета, полученные с помощью WebRequest) требуется другой класс — адаптер данных (DataAdapter). "
Конец цитаты.
//---------------------------
Значит, данные предпологается брать из различных источников (их формат заранее известен?). Но, допустим формат записи анализируемых данных един для всех отчетов. В этом случае, я бы предложил альтернативное решение, не требуещее сложной ООП и ОLAP организации.
Отчет описывает историю торгового счета. Любой торговый отчет имеет один смысловой центр - СДЕЛКУ. Свойства этого объекта - символ, дата, лот и бесконечное количество других вещей. Каждое свойство, это параметр, имеющий историю значений неопределенной глубины. Наша задача - быстрое нахождение данных по критериям вольной композиции. Их визуализация вторична. И так, каждое свойство - это параметер со своей историей значений. Эффективность извлечения данных, безусловно зависит от метода их хранения, но вот вопрос: Данные бесконечно разнообразны, потому что бесконечно разнообразны свойства главного объекта отчета - Сделки, и состояние каждого свойства (текущее значение параметра) может быть фильтром для поиска парралелей в истории значений других параметров. Иначе говоря, есть бесконечное разнообразие вариантов агрегации данных и попытки распределять и хранить историю в заранее подготовленных и структурированных комплексах не приведут ли к снижению эффективности извлечения и скорости агрегации? Безусловно, приведут.
Единственно универсальный метод записи и хранения данных, который я вижу, - это создание параллельных векторов (например ресурсов), каждый из которых будет содержать историю значений своего параметра. Поскольку Сделка привязана к конкретному времени, то она имеет порядковый номер, и следовательно, каждая Сделка, - объединяет любое количество свойств, история значений которых записывается в n-ном количестве векторов. В этом вся суть предлагаемого мною метода организации и хранения отчетных данных. Не вижу ничего более универсального.
Теперь, об агрегации данных. Безусловно, нужно использовать параллельность векторов всегда, когда возможно, ну а когда задача более сложная, использовать обычные циклы поиска. Для этого не нужны сложно структурированных системы, и универсальное решение сводится к созданию главной агрегатной функции использующей различные методы фильтрации данных. То есть, - один рабочий блок с пополняемым набором фильтров. Все.
//---------------------------
OLAP - хорошая техника, бесспорно.
но на мой скромный взгляд - основная фишка OLAP в интеграции. С хранилищами и другими источниками данных. Тогда резко расширяются возможности анализа. А внутри одного приложения с его-же наборами данных, не очень комильфо.
надеюсь в следующих статьях будут соответсвующие примеры.
Ах-да ! Статья классная, код отличный, редко тут такое бывает
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Опубликована статья Применение OLAP в трейдинге (Часть 1): Основы оперативного анализа многомерных данных:
В статье описываются общие принципы построения фреймворка для оперативного анализа многомерных данных (OLAP), его реализация на MQL и применение в среде MetaTrader на примере обработки торговой истории счета.Сегодня мы попробуем применить подход OLAP и реализовать многомерный анализ средствами MQL5. Но прежде чем приступить, необходимо определиться с тем, какие именно данные мы будем анализировать. Это могут быть, например, торговые отчеты, результаты оптимизации, показатели индикаторов.
Трейдерам часто приходится анализировать значительные объемы данных. Как правило, это — числа: котировки, показатели индикаторов, результаты из торговых отчетов. Из-за большого количества параметров и условий, от которых эти числа зависят, разбираться с ними лучше по принципу "разделяй и властвуй", то есть по частям, и рассматривая то под одним, то под другим углом зрения. В некотором смысле весь объем информации формирует виртуальный гиперкуб, в котором каждый параметр определяет собственную размерность, перпендикулярную всем остальным. Для обработки и анализа таких гиперкубов существует широко известная технология — OLAP, Online Analytical Processing.
Слово "онлайн" в названии вовсе не относится к сети Интернет, а означает оперативность (или интерактивность) получения результатов. Принцип действия заключается в предварительном расчете ячеек гиперкуба, после чего можно быстро извлечь и в наглядной форме увидеть любое сечение куба. Для иллюстрации это можно сравнить с процессом оптимизации в MetaTrader: сперва тестер обсчитывает варианты торговли (и это может потребовать долгого времени, т.е. неоперативно), а затем мы получаем отчет, в который сведены показатели в привязке к входным параметрам. Начиная со сборки 1860, MetaTrader 5 позволяет динамически менять просматриваемые результаты оптимизации, переключая различные критерии оптимизации. И это приближает нас к идее OLAP. Но для полноценного анализа хотелось бы иметь возможность оперативно выбирать многие другие сечения гиперкуба.
Сегодня мы попробуем применить подход OLAP в MetaTrader и реализовать многомерный анализ средствами MQL. Но прежде чем приступить, необходимо определиться с тем, какие именно данные мы будем анализировать. Это могут быть, например, торговые отчеты, результаты оптимизации, показатели индикаторов. В принципе, наш выбор на данном этапе не столь важен, потому что разрабатываемый фреймворк должен быть универсальным объекто-ориентированным движком, применимым на любых данных. Однако нам потребуется обкатывать его на чем-то конкретном, и одна из наиболее популярных задач — анализ торгового отчета. Так что остановимся на ней.
Автор: Stanislav Korotky