Backtester Development (Part 5)

I am extremely happy to say that since this post, I have revamped the Python code into what seems to be a properly working backtester! Today I will begin to review the logic.

While not easy, the process of dropping an existing framework into a slightly altered skeleton was not as difficult as once feared. When I first ran the revised program on a Wednesday afternoon, I wondered how many hours the debug process would take. I imagined it taking days! Previous experience had shown program fixes to not fix and when they do, to be followed by other things in need of fixing. Total debug time ended up being six hours. I had bugs, but I was able to seek and destroy.

One of my biggest struggles was organizing the variables. This literally made my head spin and kept me paralyzed for a good 60 minutes. I still don’t have a good solution except to say time working with the program breeds familiarity. I would still like to include all variables in a function and just call the function to reset and manage. That may not be practical. What I now have for variables is much different than the original key shown here. At some point, I should probably update that index.

For variable initiation and reset, I was able to condense code length by zeroing out multiple variables in a single line:

     > var_a = var_b = var_c = var_d = 0

This is legit.

It took me a couple hours, however, to realize this is not:

     > list_a = list_b = list_c = list_d = []

While the labels are different, each actually points to the same exact list. Changing any of them will result in a change to all, which was a real mess. A proper way to initiate multiple variables as separate lists is:

     > list_a, list_b, list_c, list_d = ( [] for i in range(4) )

Precision is very important, too. The following does not yield the same result:

     > list_a = list_b = list_c = list_d = ( [] for i in range(4) )

Instead of all pointing to an empty list, which is not even I wanted, done this way they all point to a generator object.

The first two paragraphs of Part 4 explain why I needed to revamp the program with regard to inconsistent DTE selection, etc. I will now proceed to describe the restructuring in words.

The basic backtesting approach remains as described in the third paragraph here. It will become evident why I was able to reduce the number of control branches to ‘find_spread,’ ‘update_long,’ and ‘update_short.’ The wait_until_next_day loop remains at the top albeit with more limited application in the current version (14).

I will continue next time.