Have Geek Brain

Design view for evaluating expression tree with time series data

I have a (C #) genetic program that uses financial time series data and is currently working, but I want to redesign the architecture to be more robust. My main goals:

  • sequentially represent time series data into expression trees.
  • allow expression trees to refer to previous rows of data as needed.
  • to optimize data access performance when evaluating expression trees.
  • maintain a common interface so that different data types can be used.

Here are the possible approaches I was thinking about:

  • I can evaluate an expression tree by passing a string of data to the root node and let each child node use the same string of data.
  • I can evaluate an expression tree by passing in a row of data into the index and letting each node get a row of data from the general DataSet

    (currently I am passing in a row index and going through multiple synchronized arrays to get data).
  • Hybrid: An immutable dataset is available for all expression trees, and each expression tree is evaluated by passing in a data string.

The advantage of the first approach is that the row of data is passed into the expression tree and no more query is made on the dataset (which should improve performance in a multi-threaded environment). The disadvantage is that the expression tree does not have access to the rest of the data (in case some of the functions must perform calculations using the previous data lines).

The advantage of the second approach is that expression trees can access any data up to the last row of data, but if I don't specify which row it is, I'll have to iterate over the rows and figure out which is the last.

The advantage of a hybrid is that it generally performs better and still provides access to earlier data. It supports two main "views" of data: the last line and the previous lines.

Do you guys know any design patterns or do you have any hints that might help me build this type of system? Should I use a DataSet to store and present data, or are there better ways to represent rows of data while maintaining a simple interface?

FYI: All my code is written in C #.

+2


a source to share


1 answer


You mainly talked about operations, which shouldn't be the first initiative for OO development. I suggest you create a RowObject that maps each row of the data table and creates another RowObjectManager class that contains the RowObject collection and associated operations such as invoking an algorithm. This is very similar to the Facade pattern, and you can encapsulate the algorithm in another class and invoke the algorithm using a dependency injection technique that can be decoupled from the RowObjectManager class.



Then you have to pass OBJECT, not object properties like index, to the algorithm, and the algorithm can return the result to the caller.

+1


a source






More articles:


All Articles