talibrt CMO gives different result than talib

[mdukaczewski]

import talibrt
import talib
import numpy as np
import pickle

timeperiod = 4

closes = [4.3] + [4.1] * 60
closes = np.asarray(closes)

_, state = talibrt.CMO_StateInit(timeperiod=timeperiod)
_, talibrt_ret = talibrt.CMO_BatchState(state, closes)
talib_ret = talib.CMO(closes, timeperiod=timeperiod)
print("talibrt", talibrt_ret[-1], "talib", talib_ret[-1])

output talibrt -100.0 talib 0.0

[trufanov-nok]

Are you sure in this example? I'm getting equal results for talibrt and talib:

>>> print("talibrt", talibrt_ret[-1], "talib", talib_ret[-1])
talibrt -100.0 talib -100.0
>>> print("talibrt", talibrt_ret, "talib", talib_ret)
talibrt [  nan   nan   nan   nan -100. -100. -100. -100. -100. -100. -100. -100.
 -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100.
 -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100.
 -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100.
 -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100.
 -100.] talib [  nan   nan   nan   nan -100. -100. -100. -100. -100. -100. -100. -100.
 -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100.
 -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100.
 -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100.
 -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100.
 -100.]

[mdukaczewski]

Yes, I confirmed this on the second machine. The same output:

talibrt [  nan   nan   nan   nan -100. -100. -100. -100. -100. -100. -100. -100.
 -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100.
 -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100.
 -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100.
 -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100.
 -100.] talib [  nan   nan   nan   nan -100. -100. -100. -100. -100. -100. -100. -100.
 -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100.
 -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100.
 -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100. -100.
 -100. -100. -100. -100. -100. -100. -100. -100. -100. -100.    0.    0.
    0.]

md5 of my talib CMO source:

md5sum ta_CMO.c
ab97f823d458be9871765ce2a742bc3c  ta_CMO.c

[trufanov-nok]

Where you got the sources? Could you at least upload your ta_CMO.c somewhere?

[mdukaczewski]

From the official site: https://ta-lib.org/hdr_dw.html --> http://prdownloads.sourceforge.net/ta-lib/ta-lib-0.4.0-src.tar.gz

[trufanov-nok]

That's a "Version 0.4 (September 2007)" according to the changelog.txt. But the actual sources on sourceforge.net got several changes since that release. Their Changelog.txt says they are "Version 0.5 (Summer 2008)" and CMakeLists.txt contains version 0.6.0-dev.

When I forked the project I used some official Github Importer tool that automatically duplicates the codebase from sourceforge keeping commits history. Just after that I copied almost untouched sources as branch original. They are 0.6.0-dev. And I'm comparing talib-rt on my machine with talib compiled from this "original" branch.
There are few changes in ta_CMO.c between 0.4 and 0.6 but they don't look significant. I'll check if that's the reason of different results.

[trufanov-nok]

Hm, I was able to reproduce the bug with ta-lib 0.4 and it's not reproducible with ta-lib 0.6-dev. Surprisingly it's not reproducible if ta_CMO.c is copied from 0.4 to 0.6...

[trufanov-nok]

Well, I bisected a commit that turns CMO 0's to -100's. That's it: Fix for better comparison to zero with extremely small values (<0.00000001). Authors tweaked TA_IS_ZERO() macro to compare absolute value to 1e-14 from 1e-8. This increased TA-Lib sensitivity after version v0.5.0 is bumped. So:

1. I think that's not a bug.
2. I should use TA_IS_ZERO() to fix #14 instead of hardcoding 1e-13. And bugreport title that will not forget to post should be "Not using TA_IS_ZERO() in CCI".
3. You might better to switch to v0.6.0-dev, bcs as you're often testing funcs with arrays of constants you'll catch all these 1e-* from floating point operations and function result will be often depends on what TA-Lib defines as zero in TA_IS_ZERO().
4. There won't be easy way to provide some #define TALIB_LOGIC_COMPATIBLE if user expects compatibility with v0.4...

[mdukaczewski]

I didn't even know there was a newer version than 0.4. I've always used the official one. It makes more sense now. Good to know that has already been fixed :) thanks

You are right that there is no point in making the talibrt compatible with the version 0.4 of the talib if there is a newer one. However, I still see a sense of the compatibility between talibrt and last version of talib(0.6). As talib works much faster, it is recommended for offline calculations. Only the talibrt is suitable for real time calculations.

EDIT: Although it might make even more sense to fix bugs in the talib (creating a fork for the fixes) instead of adding a compatibility option to the talibrt.