Discussion of article "Applying OLAP in trading (part 1): Online analysis of multidimensional data"
Thanks, a clear example of the application worked out well. On the knee, if you need to look at different slices quickly, it worked out well.
I envy the level of abstraction with white envy.
ZЫ MarketInfo accidentally appeared in the text of the article. In sources - normal.
Not as a criticism, but according to the logic of the article:
It would have been more correct to call the article"Application of OLAP in analysing trading results", because the title gives the impression that it will analyse market dynamics. But it turns out that the expert is a non-trader.
But the article is interesting from the point of view of analysing non-market, final data.
The correct title of the article should have been "Application of OLAP in analysing trading results".
The title is wrong, that's for sure.
Imho, it would be better to call it something like this: "Working with multidimensional spaces in trading using OLAP technology". And so you read and think: what is OLAP, and why is it here?
In general, as far as I understand, the article proposes a certain container class and the corresponding infrastructure, which conveniently stores vectors (vector in the statistical sense: i.e. a set of values characterising a point in a multidimensional space). In principle, even without this container it is possible to group data as needed. However, it is much more difficult to visualise multidimensional spaces. But unfortunately it is not written in the article, but I'm sure OLAP has visualisation tools.
That the name is wrong, that's for sure.
Imho, it would be better to call it something like this: "Working with multidimensional spaces in trading using OLAP technology". And so you read and think: what is OLAP, and why is it here?
It would be better if there were more articles about trading.
and so it turns out that programmers are throwing their developments from other areas. I don't know why, I don't know to whom.
I think it was on many people's tongues, I just voiced it ))
It would be better if there were more articles about trading.
and so it turns out that programmers dump their developments from other areas. It's unclear why, it's unclear to whom.
I think it was on many people's lips, I just voiced it )).
I don't know, I'd rather read about OLAP than articles like "Martingale as a basis for long-term trading strategy".
The article presents universal classes, which can be used to analyse any numerical data related to trading (it is mentioned), hence the name "trading".
I consider this tool very useful for trading, from the category of must have. If someone wants something more "traderly" - I don't know by what criteria - please leave specific requests in the corresponding thread on the forum, where there is a table of "wants".
Here is a quote from the beginning of the article:
//----------------------------
"For a trading report, it can be interesting to get a breakdown of profits by symbol, day of the week, buys and sells. Or, for example, to compare the performance of multiple trading robots (i.e. separately for each magic number).
End quote.
//----------------------------
This is a practical problem, the solution to which is taught further down the text. End quote:
//---------------------------
"To read records from some abstract source (which in the future may be a trading account history, a CSV file, an HTML report or data from the Internet obtained using WebRequest), another class is required - a DataAdapter. "
End quote.
//---------------------------
So, the data is supposed to be taken from different sources (their format is known in advance?). But let's assume that the format of the analysed data record is the same for all reports. In this case, I would suggest an alternative solution that does not require complex OOP and OLAP organisation.
A report describes the history of a trading account. Any trade report has one semantic centre - a TRADE. The properties of this object are symbol, date, lot and an infinite number of other things. Each property, is a parameter that has a history of values of indeterminate depth. Our task is to quickly find data based on free composition criteria. Their visualisation is secondary. And so, each property is a parameter with its own history of values. The efficiency of data retrieval, of course, depends on the method of its storage, but here's the question: The data is infinitely diverse, because the properties of the main object of the report - Transactions - are infinitely diverse, and the state of each property (the current value of the parameter) can be a filter to search for parallels in the history of values of other parameters. In other words, there is an infinite variety of options for data aggregation and attempts to distribute and store history in pre-prepared and structured complexes will not lead to a decrease in the efficiency of extraction and speed of aggregation? Absolutely, they will.
The only universal method of recording and storing data that I can see is to create parallel vectors (e.g. resources), each containing a history of its parameter values. Since a Transaction is tied to a specific time, it has a serial number, and therefore, each Transaction - combines any number of properties, the history of values of which is recorded in n number of vectors. This is the whole essence of my proposed method of organising and storing reporting data. I don't see anything more universal.
Now, about data aggregation. Of course, you should use parallelism of vectors whenever possible, and when the task is more complicated, you should use usual search cycles. We don't need complex structured systems for this, and the universal solution is to create the main aggregate function using different methods of data filtering. That is, - one working block with a replenishable set of filters. All.
//---------------------------
OLAP is a good technique, undoubtedly.
But in my humble opinion - the main feature of OLAP is integration. With storages and other data sources. Then the possibilities of analyses expand dramatically. And inside one application with its own data sets is not very comical.
I hope in the next articles there will be corresponding examples.
Ah-da ! The article is great, the code is excellent, it is rare to find such a thing here
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
New article Applying OLAP in trading (part 1): Online analysis of multidimensional data has been published:
The article describes how to create a framework for the online analysis of multidimensional data (OLAP), as well as how to implement this in MQL and to apply such analysis in the MetaTrader environment using the example of trading account history processing.
Traders often have to analyze huge amounts of data. These often include numbers, quotes, indicator values and trading reports. Due to the large number of parameters and conditions, on which these numbers depend, let us consider them in parts and view the entire process from different angles. The entire amount of information forms kind of a virtual hypercube, in which each parameter defines its own dimension, which is perpendicular to the rest. Such hypercubes can be processed and analyzed using the popular OLAP ( Online Analytical Processing) technology.
The "online" word in the approach name does not refer to the Internet, but means promptness of results. The operation principle implies the preliminary calculation of the hypercube cells, after which you can quickly extract and view any cross section of the cube in a visual form. This can be compared to the optimization process in MetaTrader: the tester first calculates trading variants (which may take quite a long time, i.e. it is not prompt), and then outputs a report, which features the results linked to input parameters. Starting from build 1860, the MetaTrader 5 platform supports dynamic changes of viewed optimization results by switching various optimization criteria. This is close to OLAP idea. But for a complete analysis, we need the possibility to select many other slices of the hypercube.
We will try to apply the OLAP approach in MetaTrader and to implement multidimensional analysis using MQL tools. Before proceeding to implementation, we need to determine the data to analyze. These may include trading reports, optimization results or indicator values. The selection at this stage is not quite important, because we aim to develop a universal object-oriented engine applicable to any data. But we need to apply the engine to specific results. One of the most popular tasks is the analysis of the trading report. We will consider this task.
Author: Stanislav Korotky