Unable to get +80, -80, +200, -200 patterns values

[Morningbull]

Hello! With original C code some patterns as engulfing, harami, haramicross and hikkake are returing values +80, -80, +200, -200 under certain conditions. Unfortunately I'm not able to get those types of values using this python wrapper, do you know why? Thanks!

[mrjbq7]

You have a test case that works in C (to return those values), but not in Python?

On Jun 5, 2022, at 6:15 AM, Morningbull @.***> wrote:

 Hello! With original C code some patterns as engulfing, harami, haramicross and hikkake are returing values +80, -80, +200, -200 under certain conditions. Unfortunately I'm not able to get those types of values using this python wrapper, do you know why? Thanks!

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[Morningbull]

So, I try to explain you how I arrived to that conclusion. At the beginning I connected my application to the website taapi .io to get the patterns values. When I discovered this wrapper for python I installed it including the library (I used this: https://github.com/afnhsn/TA-Lib_x64/blob/master/README.md, already compiled for 64bit). Comparing the results found with those different methods (website and library) I noticed that the only differencies are the lack of +80, -80, +200, -200 values. Making some searches I found the native code in C++ of those indicators and there I had confirmation that in the original code those values are really esisting, see below an extract from engulfing pattern:

/* Proceed with the calculation for the requested range. * Must have: * - first: black (white) real body * - second: white (black) real body that engulfs the prior real body * outInteger is positive (1 to 100) when bullish or negative (-1 to -100) when bearish: * - 100 is returned when the second candle's real body begins before and ends after the first candle's real body * - 80 is returned when the two real bodies match on one end (Greg Morris contemplate this case in his book * "Candlestick charting explained") * The user should consider that an engulfing must appear in a downtrend if bullish or in an uptrend if bearish, * while this function does not consider it */

I tried to use also the library from the page https://www.lfd.uci.edu/~gohlke/pythonlibs/#ta-lib but agan same result.

As test case, using the prices below from BTC/USDT I get 80 engulfing value with the website and 0 with the library:

open high low close 59806,2 60444 59401 60019,8 60019,7 60785 59025 59048,5 59048,5 60567 58786 60446,1 60446,8 60699,5 57422 57950,1

[Morningbull]

Yes, below an extract of my code for engulfing:

Function to calculate indicators

def indicators_calculation ():

# Load excel file
ws_hist = excel_preparation.wb1[Settings.history_data_sheet]
ws_hist_inv = excel_preparation.wb1[Settings.history_data_inverse_sheet]
max_row_hist = ws_hist.max_row
max_column_hist = ws_hist.max_column

# Put in a list the prices
open_list = []
high_list = []
low_list = []
close_list = []
for row in range(2, max_row_hist+1):
    # Exit from the loop if this is the last row (the

indicators/patterns values are every time referred to previous prices) if row == max_row_hist: break open_list.append(ws_hist.cell(column=2, row=row).value) high_list.append(ws_hist.cell(column=3, row=row).value) low_list.append(ws_hist.cell(column=4, row=row).value) close_list.append(ws_hist.cell(column=5, row=row).value)

# Transform the list in array and start patterns calculation
open_arr = numpy.array(open_list)
high_arr = numpy.array(high_list)
low_arr = numpy.array(low_list)
close_arr = numpy.array(close_list)

pattern_values = CDLENGULFING(open_arr, high_arr, low_arr, close_arr)

for value in pattern_values[::-1]:
       ws_hist.cell(column=column, row=row, value=value)
       ws_hist_inv.cell(column=column, row=row, value=value)
       row -= 1

And with the prices below I should get 80 for engulfing but I get 0: Data Open High Low Close 2021-03-14 17:00:00 59806,2 60444 59401 60019,8 2021-03-14 21:00:00 60019,7 60785 59025 59048,5 2021-03-15 1:00:00 59048,5 60567 58786 60446,1 2021-03-15 5:00:00 60446,8 60699,5 57422 57950,1

Il giorno dom 5 giu 2022 alle ore 15:27 Alexander Trufanov < @.***> ha scritto:

Could you provide a code sample in python?

— Reply to this email directly, view it on GitHub https://github.com/mrjbq7/ta-lib/issues/520#issuecomment-1146804499, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZPWOZFQTSDYD2O2JUL7XU3VNSTLBANCNFSM5X5BMDHQ . You are receiving this because you authored the thread.Message ID: @.***>

[trufanov-nok]

The python code

import talib
import numpy as np

o = np.array([59806.2,  60019.7, 59048.5, 60446.8]);
h = np.array([60444.0, 60785, 60567, 60699.5 ]);
l = np.array([59401.0, 59025, 58786, 57422]);
c = np.array([60019.8, 59048.5, 60446.1, 57950.1]);
talib.CDLENGULFING(o, h, l, c)

gives me array([ 0, 0, 80, -100], dtype=int32) is this expectable result? If so the problem isn't in wrapper. (lookback value for CDLENGULFING is constant 2)

[Morningbull]

Yes your result is correct, but I get instead [0, 0, 0, -100], I have more than 2 candles before so the lookback value is not the problem. Maybe I using an old/wrong version of ta-lib C++ library? Which one are you using in your code (I'm in 64bit)?

[trufanov-nok]

pip list says TA-Lib 0.4.25.

[Morningbull]

No the wrapper, I mean the dipendency ta-lib required. Which are you using, from here https://www.lfd.uci.edu/~gohlke/pythonlibs/#ta-lib, this one [ta-lib-0.4.0-msvc.zip] or something else? Sorry for all this question but I'm trying to understand where is my problem.

[trufanov-nok]

wrapper always downloads the same sources of TA-Lib C library and this library is not updated for years. So I'm pretty sure the version is the same. My suggestion is to populate my code sample with more historical data (as you said there are have more than 2 candles before ) and check if that influence the calculation somehow.

[Morningbull]

No that cannot be the problem, I have thousands of candles. The point is that I'm not getting 80 or -80 or even 200 or -200 at all, that reporter is just an example. I checked the version of my wrapper and I have TA-Lib 0.4.24, maybe is that the problem. And also, which version of python do you have, 32 or 64bit?

[mrjbq7]

You can print out the TA Lib version also, but that’s pretty much always 0.4.0.

Unless there’s something weird with the windows compiled version (you could verify linux or macOS gets the same result). Another possibility is the default “candle settings” which control some of the candle indicator behavior.

On Jun 5, 2022, at 2:06 PM, Morningbull @.***> wrote:

 No that cannot be the problem, I have thousands of candles. The point is that I'm not getting 80 or -80 or even 200 or -200 at all, that reporter is just an example. I checked the version of my wrapper and I have TA-Lib 0.4.24, maybe is that the problem. And also, which version of python do you have, 32 or 64bit?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[trufanov-nok]

@Morningbull 64 bit everything

[trufanov-nok]

>>> import talib
>>> talib.__ta_version__
b'0.6.0-dev (Jun  3 2022 00:21:00)'

Aren't you gettig 80 in results with my code sample?

[Morningbull]

Yes I tried your code but still same, 80 is missing, I think I found the problem, here I'm attaching two version of C++ dipendency. ta-lib-0.4.0-msvc: this is from 2007, it is the version indicated on the installation instructions of Ta-lib wrapper and is the version that I used until now ta-lib-code-r1562-trunk-ta-lib: this version I found here (https://sourceforge.net/p/ta-lib/code/HEAD/tree/trunk/ta-lib/), it is from 2013, all the indicators/patterns have some update and 3 indicators are new. I compare the code of engulfing and I found that only the version from 2013 include also +80/-80 values but not the version that I was using. Now I'm trying to compile it for 64bit but I'm getting problem for 2 of the new indicators, seems that they are not compiled. [ta-lib-code-r1562-trunk-ta-lib.zip](https:// ta-lib-0.4.0-msvc.zip github.com/mrjbq7/ta-lib/files/8840946/ta-lib-code-r1562-trunk-ta-lib.zip)

[Morningbull]

I'm curios to know which version you are using and where you downloaded.

[trufanov-nok]

Yeah, now I could reproduce your problem and you're right - I'm using an other than official realize zip sources of ta-lib. The version that acts like you described is

>>> talib.__ta_version__
b'0.4.0 (May 27 2022 20:01:47)'

I just didn't noticed I'm having not official released one on my drive. There are differences between last official release of ta-lib and its sourceforge code, I've described them here: https://github.com/trufanov-nok/ta-lib-rt/wiki/Compatibility-with-TA-Lib

[Morningbull]

Yes, exactely, the problem now is that I'm not able to compile it for 64bit, I'm getting following errors:

ta_regtest.obj : error LNK2019: unresolved external symbol test_func_avgdev referenced in function testTAFunction_ALL ta_regtest.obj : error LNK2019: unresolved external symbol test_func_imi referenced in function testTAFunction_ALL ta_libc_cdr.lib(ta_frame.obj) : error LNK2019: unresolved external symbol TA_AVGDEV referenced in function TA_AVGDEV_FramePP ta_libc_cdr.lib(ta_frame.obj) : error LNK2019: unresolved external symbol TA_AVGDEV_Lookback referenced in function TA_AVGDEV_FramePPLB ta_libc_cdr.lib(ta_frame.obj) : error LNK2019: unresolved external symbol TA_IMI referenced in function TA_IMI_FramePP ta_libc_cdr.lib(ta_frame.obj) : error LNK2019: unresolved external symbol TA_IMI_Lookback referenced in function TA_IMI_FramePPLB ..........\bin\ta_regtest.exe : fatal error LNK1120: 6 unresolved externals NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.32.31326\bin\HostX64\x64\link.EXE"' : return code '0x460' Stop. NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.32.31326\bin\HostX64\x64\nmake.exe"' : return code '0x2' Stop.

Did you remember how you solved them?

[trufanov-nok]

I was able to compile the sources on Linux without a problem:

svn checkout https://svn.code.sf.net/p/ta-lib/code/trunk ta-lib-code
cd ta-lib-code/ta-lib/
mkdir build
cd build/
cmake ..
make -j4

Are you building with some *,sln file from ta-lib/c/ide/ folder? Which one?

[Morningbull]

I'm following the procedure described here https://github.com/mrjbq7/ta-lib:

4. Build TA-Lib Library From Windows Start Menu, Start [VS2015 x64 Native Tools Command Prompt] Move to C:\ta-lib\c\make\cdr\win32\msvc Build the Library nmake

But with visual studio 2022, I don't know if there are other ways to do that in windows.

[trufanov-nok]

It seems makefiles in cdr\win32\msvc\ta_libc\ and cdr\win32\msvc\ta_func\ folders are missing references to ..\..\..\..\..\src\ta_func\ta_IMI.c and ..\..\..\..\..\src\ta_func\ta_AVGDEV.c. And makefile in cdr\win32\msvc\ta_regtest\ is missing references to ..\..\..\..\..\src\tools\ta_regtest\ta_test_func\test_imi.c and ..\..\..\..\..\src\tools\ta_regtest\ta_test_func\test_avgdev.c

Use the attached makefiles cdr.zip .

[Morningbull]

Thanksss!!!! Your code worked perfectly, it has been compiled without any problem! Thanks again for your help, I'm not very practical with C++