Today I'd like to write a bit about the progress of the currently ongoing rewrite/restructuring of the software code. As I wrote in a former article after the v0.3.0 release I took some time to rethink about how I wrote the code and what design decisions I made (by the way... the very first code commit into the development repository was on April, 9th 2016- ichinscratchy just had its 2nd birthday :)). Now that I progressed a) as a programmer in general and b) as someone who implemented his first trading software I had several ideas how to improve the code and make it more modular and better extensible. Most important idea was to utilize some concepts of object oriented programming. This is not without irony, as at the beginning I did not really understand what oop was and how my specific problem domain would translate into oop programming concepts.
Ichinscratchy grew bigger and bigger, from being initially only a software that was able to analyze quote datasets according to Ichimoku rules and identifying Ichimoku entry signals, to a full blown trading system with risk management, portfolio tracking and some statistical analysis of the executed trades. All along this way I programmed additional features on top of the system as I needed them. This led to function declarations with the length of Tolkien´s Lord of the rings, where you can see the genesis of this routine pretty well (oh, for this feature I need another vector, and here another parameter, and there...). Pretty much like highway engineers build road intersections in the US: http://www.texasfreeway.com/elpaso/photos/stack_i10_us54/stack_i10_us54.shtml (El Paso, Tx has its place in my heart forever!)
The reliance on dates in the form of 2018-04-10 also turned out to be a real pita. In hindsight this was utterly stupid. The back-and-forth translation from a string containing this data into a so-called day number (which is an index of days beginning at 1900-01-01 until today) which is so much closer to the machine representation of data vectors and its indices made the code a) pretty ugly and b) very slow (compared to all calculations done directly with the day number as index).
Long story short, I broke down the problem into something that could be called classes, things that have a defined set of data and methods that manipulate this data.
Currently I implemented quotes, indicators, markets, signals and accounts as classes. Everything comes with its own memory management routines and a standard set of methods (like init_, destroy_, clone_, printTable_). Instead of passing a bazillion arrays between functions (and taking care of different lengths of them, handling all exceptions from the rule by hand) I now create instances of these classes. E.g. an instance of the class market that would hold all data related to my home market, the german DAX. This so called object holds the quote data, stores all indicator data, calculates its own translation currency vectors (to calculate p/l for markets in other currencies than the account currency) and so on.
The market objects holds indicator objects which in turn contain quote objects. A nice side effect is (besides the easier memory management and better -because more modular- testing abilities) that I can now do sanity checks on each individual level. This catches errors that do not live within the source code, but are runtime-errors that come from misconfiguration of the trading system (e.g. trying to calculate a set of x days indicator data by averaging a set of y days of quote data with y<x).
In the long run I want to separate the trading system logic from the infrastructure (aka the framework)- but this is still far into the future.
My gut feeling is that at the moment I am done like 75% of the rewrite. The next version won't have that much exciting new features, but will have a much mature and cleaner code base. Much decreased execution times and highly improved error-checking (with more verbose error messages) are a nice side effect of above mentioned design changes.
Ah.. If anyone is asking: Why the hell does he do that in C?! Starting purely procedural but now transforming into object orientation but still sticking to C is..not too smart. The answer is pretty short and identical to why I started writing my own software at all: because I can :-D
Comments powered by CComment