MAMA indicator returning incorrect results
Brought to you by:
fortier
Hi
Using the Java version I'm getting results from the MAMA that are very different from the values in JForex. I've validated the MAMA in JForex against a couple of other platforms. The Mama is out by two or three pips, and the Fama can be wildly out.
Using the same price array and virtually the same code, I'm getting results for a number of other TA-LIB indicators that are correct to the micropip. So it looks as if I've run into a bug.
I have a very urgent need, so a quick response would be much appreciated.
Here is the method that's calling MAMA. Am I missing something here?
public static double[] runMama(double[] prices, double fastLimit, double slowLimit) { try { MInteger outBegIdx = new MInteger(); MInteger outNbElement = new MInteger(); int count = prices.length; Core core = new Core(); // We only need the most recent value. double[] outputFama = new double[1]; double[] outputMama = new double[1]; RetCode retCode = core.mama(count-1, count-1, prices, fastLimit, slowLimit, outBegIdx, outNbElement, outputMama, outputFama); if (retCode != RetCode.Success) { throw new RuntimeException("TA-LIB Mama has barfed!"); } return new double[]{outputMama[0], outputFama[0]}; } catch (Exception e) { Printer.printErr("Problem with MESA", e); return null; } }
It is likely that you are calculating over the whole range of data on other platforms, while you use TA-Lib to calculate only over a subset of your data.
That can make a significant difference for functions that are recursive (I also use the term function with memory and function with unstable period).
====
Think of the difference between SMA (no memory/not recursive) and EMA (memory/recursive). MAMA and FAMA are like EMA.
Have to be very very careful about using startIdx==endIdx for function that are recursive... because the function will not recurse more than once for calculating that single value.
In short, when in doubt, always set your startIdx to zero and the TA-Lib function will always use all the past data in its calculation. This is what most (may be even all) other platforms do. This is what I recommend to most people.
Note: TA-Lib still allow to calculate on a subrange for recursive function because I (and some others) want to use TA-Lib unique capability to balance between speed and accuracy. Although all past data influence future data, one might not want/need to calculate over, say, 10 years of data just to calculate the latest value.
\Mario
[bugs:#100] MAMA indicator returning incorrect resultsStatus: open
Group:
Created: Fri Feb 05, 2016 02:26 PM UTC by Geoff Caplan
Last Updated: Fri Feb 05, 2016 02:26 PM UTC
Owner: nobodyHiUsing the Java version I'm getting results from the MAMA that are very different from the values in JForex. I've validated the MAMA in JForex against a couple of other platforms. The Mama is out by two or three pips, and the Fama can be wildly out.Using the same price array and virtually the same code, I'm getting results for a number of other TA-LIB indicators that are correct to the micropip. So it looks as if I've run into a bug.I have a very urgent need, so a quick response would be much appreciated.Here is the method that's calling MAMA. Am I missing something here? public static double[] runMama(double[] prices, double fastLimit, double slowLimit) {
}
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/ta-lib/bugs/100/To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Related
Bugs: #100
Hi Mario
Thanks for the quick response - much appreciated!
I should have made it clearer that I've tried with the startIdx=0 and up to 400 historic bars. The results were no better.
As you say, Mama is an indicator with memory, but I'm getting Fama values that are up to 30 pips out, which surely can't be accounted for by the lookback? I'm pretty confident that's not the issue.
It won't be a data issue either, as I'm using Dukascopy historic data and the bars in my app are identical to the JForex charts I'm using to check the values.
I've double checked that the bars are in the right order, and fed them in back-to-front too just in case I had misunderstood something. By the way, I don't think the docs explain the order that TA-Lib is expecting (new-to-old or old-to-new) - perhaps that's something you might consider adding?
So I'm still baffled. How confident are you that the Mama is working properly? And if you think the issue is my end, what else could I try?
I've just re-read the docs and noted that your require a call to TA_Initialize(), which I'm not doing. I've never seen it in any example and the other indicators were working fine without it. Could that be the problem? I'll try it as soon as I have access to my work PC.
As far as I know, MAMA and FAMA that I wrote in C works correctly and outputs were compared with the value returned by the Tradestation code published by Ehlers. One possibility is that Java would not work the same. This is unlikely but possible. Unlikely because the way TA-Lib is design the C and Java are essentially the same source code (syntax differences are handled by a C pre-processor!)... but bugs are always a possibility.
Please publish here the output you get from both JForex and TA-Lib... and the corresponding 400 input values. Make 100% sure that you feed the same amount of input to both platform (no more, no less), furthermore verify that the number of output is the same (if not, then this is a good hint of a different implementation).
I will feed your input into the Excel version of TA-Lib (which uses the C++ implementation) and we can isolate further if there is an issue specific to the Java implementation.
Finally, be prepared that it won't be the first time that implementation differences are found between products and in the end you may have to make a choice about what to choose for reference.
\Mario
Hi MarioThanks for the quick response - much appreciated! I should have made it clearer that I've tried with the startIdx=0 and up to 400 historic bars. The results were no better.As you say, Mama is an indicator with memory, but I'm getting Fama values that are up to 30 pips out, which surely can't be accounted for by the lookback? I'm pretty confident that's not the issue.It won't be a data issue either, as I'm using Dukascopy historic data and the bars in my app are identical to the JForex charts I'm using to check the values.I've double checked that the bars are in the right order, and fed them in back-to-front too just in case I had misunderstood something. By the way, I don't think the docs explain the order that TA-Lib is expecting (new-to-old or old-to-new) - perhaps that's something you might consider adding?So I'm still baffled. How confident are you that the Mama is working properly? And if you think the issue is my end, what else could I try?I've just re-read the docs and noted that your require a call to TA_Initialize(), which I'm not doing. I've never seen it in any example and the other indicators were working fine without it. Could that be the problem? I'll try it as soon as I have access to my work PC. [bugs:#100] MAMA indicator returning incorrect resultsStatus: open
Group:
Created: Fri Feb 05, 2016 02:26 PM UTC by Geoff Caplan
Last Updated: Fri Feb 05, 2016 02:26 PM UTC
Owner: nobodyHiUsing the Java version I'm getting results from the MAMA that are very different from the values in JForex. I've validated the MAMA in JForex against a couple of other platforms. The Mama is out by two or three pips, and the Fama can be wildly out.Using the same price array and virtually the same code, I'm getting results for a number of other TA-LIB indicators that are correct to the micropip. So it looks as if I've run into a bug.I have a very urgent need, so a quick response would be much appreciated.Here is the method that's calling MAMA. Am I missing something here? public static double[] runMama(double[] prices, double fastLimit, double slowLimit) {
}
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/ta-lib/bugs/100/To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Related
Bugs: #100
OK - my bad! Please mark as solved.
I was making a couple of small mistakes that were compounding up. I'm now accurate to the micropip.
Thanks for helping to put me on the right track - much appreciated.