Pattern scanner and time for confirmation fix to count bars instead of days between timestamps

Technical Analysis
1

Course Name: Price Action Trading, Section 14 Unit 5

Fix that also supports any timeframe:

tb_scanner(min_max, minima_prices, maxima_prices, data):

window_size = 1 + data.index.get_loc(window.index[-1]) - data.index.get_loc(window.index[0])

…

tb_patterns_data['time_for_confirmation'] = tb_patterns_data.apply(lambda row: 1 - data.index.get_loc(row['bottom3_date']) + data.index.get_loc(row['confirmation_date']), axis=1)

2

The problem exists in all price action pattern notebooks and the same solution can be applied in all notebooks. It is a problem because the notebooks count days instead of bars between pattern points although the markdown cells specify bars instead of days. It also limits the notebooks to detecting the patterns only on a daily level. By applying the fix, the notebooks will capture the patterns in any timeframe and be compliant to the specification in the markdown cells, but cell outputs may change.

3

It is possible to avoid using apply in this case by using the get_indexer method which is more efficient for multiple index lookups. Here’s how:

bottom3_date_indices = data.index.get_indexer(tb_patterns_data['bottom3_date'])
confirmation_date_indices = data.index.get_indexer(tb_patterns_data['confirmation_date'])
tb_patterns_data['time_for_confirmation'] = 1 - bottom3_date_indices + confirmation_date_indices

This code does the same thing as the original code but should be faster because it avoids the use of apply, which can be slow on large dataframes. The get_indexer method returns an array of indices for the input values, which can then be used directly in calculations.
 
4

Hi Quantra team,



I would appreciate your position on this issue, because it affects many notebooks in the Price Action Trading Strategies course. Do you agree on my proposal or disagree and why?



Cheers,

Antonis

5

Hi Antonis,



First of all, thank you for taking the time to go through and suggest the code alternatives. The reason the existing code is in days, as you rightfully pointed out, is that we were using daily data and thus, it was fine. 

If, however, you are using minute-level data, then your code will be useful.



The same can be said for your comment on using 'get_indexer' instead of 'apply' as well. At Quantra, we tend to look at code as a tool to apply. If it can be simple, then it is better for someone to understand. Neverthless, your point still stands and could be an improvement as well.



We are glad that you are finding/mentioning ways to code in a manner to reduce computation time and appreciate your efforts.



Thanks.



 

6

Hi Rekhit,



Thank you for your response.



I insist that this issue is not an improvement of the Course notebooks but a needed fix. That is because counting calendar days instead of trading days yields different results. The specification in the markdown cells of the notebooks mention bars, which implies trading days on a daily timeframe. But the existing code in the notebooks counts calendar days. Thus, the python implementation does ot agree with the markdown specification. On the other hand, the implementation that I proposed agrees with the specification, and has the added value that works on any timeframe .



Based on the above, I would appreciate the course author's feedback on why not the course notebooks need to be corrected.



I am at your disposal for anything more that you might need.



Thanks

Antonis

7

Hi Antonios,



Rest assured that we have not closed this and are reviewing your feedback. We will be getting back with the response.



Thanks.

8

Hi Antonios,



Thank you for your suggestions. We will be updating the notebooks as necessary.



Thanks.

9

Hello Antonios,



Just an update, we have made the required changes in the notebooks wherever applicable. Thanks.