Discussion of article "Applying OLAP in trading (part 1): Online analysis of multidimensional data" - page 2

New comment
 

The simplest methods of aggregation of data written in vectors:

1. Move along all property-vectors of a transaction perpendicular to their direction. It is possible to quickly aggregate all the data of one particular transaction. In this case, one simple loop is used.

2. If you move in the first cycle along the direction of the vectors, and in the second cycle perpendicular to the direction of the vectors - you can collect all the data of all the transactions.

Conclusion: With parallel-perpendicular movement, you can use any transaction selection filters.


Any value of any property can act as a search filter. A symbol, for example, is a transaction property. A specific symbol is a specific value of a transaction property and can be a filter for data aggregation. Lot, is also a transaction property. A specific value of lot can also be a filter. Complex filters are combinations of specific values of specific properties. There can be no restriction on the complexity and size of a filter in a universal aggregation method. Therefore, the main task is not to organise data parsing (which is always parallel-perpendicular), but to turn a tricky user-defined filter into an argument of an aggregate function.

 
Реter Konow:

...Therefore, the main task is not to organise data parsing (which is always parallel-perpendicular), but to turn a cunningly complex custom filter into an argument of an aggregate function.

How to turn a complex filter (a set of data selection conditions), containing not only specific values of transaction properties, but also ranges of these values, into a function argument?

1. Property vectors (storing the history of parameter values) must be indexed. Each transaction property should have a sequence number. By it, the required resource will be queried and data will be retrieved from it.

2. Each filter is a specific value of a specific transaction property, or a range of values.

So, to build a filter, the user needs to specify the indexes of properties on the vectors of which the loop should be made, and specify their specific values or ranges of values. This information can be written to a regular array and passed to the aggregate function. It will extract the necessary vectors from the resources and loop through their contents in a parallel-perpendicular motion using a filter from the array passed to it.

This is quite a simple and clear task.

 

To the author of the article: how OLAP is fundamentally different from an array of classes?

In fact, let a vector be a value of values or a complex of values characterising some point. But each point can be expressed through a class. In this case, all its properties can be written into a vector and vice versa:

class TradeDeal
{
   Symbol = EURUSD;
   TimeHold = 1 h,13 m,55 s;
   Profit = 21.52$;
   MAE = 1.243;
}; => {EURUSD, {1 h,13 m,55 s}, 21.52$, 1.243 };

I.e. an instance of an OOP class is essentially a vector in a multidimensional space or a point projecting its values onto a set of dimensions. Thus any selection by parameters will consist in a usual traversal of generic collection of such classes and selection of suitable instances.

 
Vasiliy Sokolov:

To the author of the article: how is OLAP fundamentally different from an array of classes?

In fact, let a vector be a value of values or a complex of values characterising some point. But each point can be expressed through a class. In this case, all its properties can be written into a vector and vice versa:

I.e. an instance of an OOP class is essentially a vector in a multidimensional space or a point projecting its values onto a set of dimensions. Thus any selection by parameters will consist in a usual traversal of generic collection of such classes and selection of instances suitable for the conditions.

This is approximately what has been done. Only besides classes-records we need classes for reading sources, classes-iterators on records, classes of aggregation functions, classes of getting results and visualisation (will be in the 2nd part). All this together gives you OLAP.

 
Maxim Dmitrievsky:

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 )).

Quite right, I have been thinking about it for a long time too.

 
Aleksandr Masterskikh:

Absolutely right, I've been thinking about this for a long time too.

Just write it down.
 
Artyom Trishkin:
Just write.

Artem, you don't understand, people need the "Dough" button:) And here they write about different OLAP... When will there be a description of the button...

 
Vasiliy Sokolov:

Artem, you don't understand, people need the "Money" button:) And here they write about different OLAP... When will there be a description of the button...

The most difficult article about such a button ;)
[Deleted]  
Vasiliy Sokolov:

Artem, you don't understand, people need the "Money" button:) And here they write about different OLAP... When will there be a description of the button...

What for, people just need pretty buttons and words.

 
Artyom Trishkin:
Just write.

I just wrote that recently articles about programming secondary things (services for processing ready-made trading results and so on) not related to analysing market dynamics have become prevalent, rather than about trading.

Of course, this is also necessary, but the main task is trading itself, searching for algorithms of market entry (and programming these algorithms).

123
New comment