Patch 1217a

[mephistobooks]

I guess start index of output array is not correct (i.e., the results of C/C++ and ruby are not same).

Would you please read this report when you have a time. https://gist.github.com/mephistobooks/8027013

[rivella50]

Hello Masayuki, thank you for your enormous efforts. I will respond to your Analysis in the last Gist: a) ok, nothing to do from my side b) i did never encounter that problem, but it is possible. Since it seems to be a problem in TaLib (and which can be replaced by using TA_MACDEXT) i cannot change there anything in talib-ruby as well. c) BegIdx (out_start) is an index for the output array(s) and has nothing to do with input arrays (have you read this here: http://ta-lib.org/d_api/d_api.html#Direct%20call%20to%20a%20TA%20Function ?) I guess the only problem you have is that all results from the wrapper do not start at index 0, right ? My understanding of the wrapper is that it should pass all results from TaLib 1:1 as received back to the calling Ruby code, therefore i don't see it like you and i don't want to change this behaviour in the wrapper.

Btw. how can i call your .cc files on my Mac's command line ? I always get errors with

env ARCHFLAGS="-arch x86_64" g++ talib_macdext.cc 0 6 2 3 1 1

[mephistobooks]

Hello, rivella-san,

BegIdx (out_start) is an index for the output array(s) and has nothing to do with input arrays (have you read this here: http://ta-lib.org/d_api/d_api.html#Direct%20call%20to%20a%20TA%20Function ?)

Ahh...!, I read it so many times and I also understood it as you said, at first :). You are mentioning this part, right?

As an alternative example, if you would have requested to calculate only in the "125 to 225" range (with startIdx and endIdx), the outBeg will be 125 and outNbElement will be 100. (the "30" minimum required is not an issue because we dispose of 125 closing price before the start of the requested range...). As you may have already understand, the "out" array will be written only for its first 100 elements. The rest will be left untouched.

This paragraph has ambiguity at "... for its first 100 elements", and "The rest will be left untouched." So, the problem is: where is the left untouched to be placed? the head in the output array or the tail in the output array.

And concerning the actual running result in C/C++, I must say, "BegIdx is not for output array." It just points the start index (this is where the first output data can calculate) in input array. And output data is always populated from the index 0 into the specified output array (I think this TA-Lib's function behavior is for memory usage performance).

Btw. how can i call your .cc files on my Mac's command line ?

Sorry for confusing. It is C program. I am also Mac, so you can compile them just do with gcc:

gcc -L /usr/local/lib/ -o talib_macdext talib_macdext.cc -lta_lib
gcc -L /usr/local/lib/ -o talib_macd talib_macd.cc -lta_lib

Like this. Maybe library path is different from my environment. After compilation, you can execute talib_macdext 0 6 2 3 1 1, talib_macd 0 6 2 3 1. Could you compare the results between C/C++ and ruby.

Thank you.

[rivella50]

Ok now i see what you mean when running and comparing the C++ and Ruby tests, and it seems that you are right. Since the numbers are all equal it's really only a shifting "problem". I will check this tomorrow with some other indicators and if there isn't any problem i will change it in the code in order to be zero index based as it is returned from the ta-lib call already. Thank you again for your help, it's appreciated very much!

[rivella50]

Hello Masayuki, i've just committed the needed changes to master branch and documented in the README what the shifting change means. Before i deploy the updated gem (version 1.0.6) could you please double check if this is what you initially meant ? My tests were all successful, therefore it should be everything ok.

Thank you.

[mephistobooks]

Hello rivella,

Sorry for late but now I saw your latest 2 commits. That is nice. Great.

Thank you, and happy new year.