Kaufman Adaptive Moving Average KAMA Problem
Forums › ProRealTime English forum › ProBuilder support › Kaufman Adaptive Moving Average KAMA Problem
- This topic has 12 replies, 2 voices, and was last updated 3 years ago by VN.
-
-
02/20/2021 at 6:15 PM #162116
Hi I am using the KAMA code which Nicolas has shared https://www.prorealcode.com/prorealtime-indicators/kaufman-adaptive-moving-average-kama/ here on a 1 min chart for S&P 500.
Something in the code does not appear to be working correctly as shown in the attached image when plotting the indicator for some reason after 12th Feb 21 ( I am using 10000 units at 1 min ), the average returned just stays constant for the remainder of the period. Interestingly, if I switch to a greater period, say 2 mins, the problem goes away.
I am using exactly the same settings as per Nicolas’s code i.e. Period = 10, FastPeriod=2, SlowPeriod=30.
Any assistance in fixing this would be appriciated!
KAMA code1234567891011121314151617Period = 10FastPeriod = 2SlowPeriod = 30Fastest = 2 / (FastPeriod + 1)Slowest = 2 / (SlowPeriod + 1)if barindex < Period+1 thenKama=closeelseNum = abs(close-close[Period])Den = summation[Period](abs(close-close[1]))ER = Num / DenAlpha = SQUARE(ER *(Fastest - Slowest )+ Slowest)KAMA = (Alpha * Close) + ((1 -Alpha)* Kama[1])endifreturn kama02/20/2021 at 6:19 PM #16211702/20/2021 at 6:21 PM #162118There’s no pic attached.
02/20/2021 at 6:31 PM #16212102/20/2021 at 6:33 PM #162123I’ll try to spot what it is all about.
02/20/2021 at 7:18 PM #162128Thanks for looking Roberto!
I just noticed that if I load the pre-loaded Adaptive MA indicator straight into the price chart (red line of the image) and i keep the same parameters, it works and it matches exactly the indicator using Nicolas’s code e.g. at the snapshot i have taken on 12/02/21 @ 05:22 the KAMA is at 3,910.39915 on Nicolas’s code (circled in red) and also on the pre-loaded indicator (circled blue).
But then you can see that from about 6:00 the KAMA from Nicolas’s code starts to be a constant where as the pre-loaded KAMA continues to move as the price changes.
Very odd.
02/20/2021 at 7:55 PM #162130It returns wrong values up to 69-second TF.
It seems that up to (and including) OpenMinute 06.53am (Utc+1 or CET) OHLC data are reported and candlesticks plotted on the chart, while AFTER that time candlesticks are plotted but OHLC data are NOT plotted with the following code:
1234567891011121314151617181920212223242526272829303132defparam drawonlastbaronly=truePeriod = 10FastPeriod = 2SlowPeriod = 30Fastest = 2 / (FastPeriod + 1)Slowest = 2 / (SlowPeriod + 1)if barindex < (Period + 1) thenKama = closeelseNum = abs(close-close[Period])Den = summation[Period](abs(close - close[1]))ER = Num / DenAlpha = SQUARE(ER *(Fastest - Slowest ) + Slowest)Kama = (Alpha * Close) + ((1 - Alpha) * Kama[1])endify=2662 //I used this indicator: RETURN BARINDEXIF BarIndex > 8000 thenx =(barindex - y)z =3913//kama[x]z1=open[x]z2=high[x]z3=low[x]z4=close[x]drawtext("O #z1#" ,y,z*1.0004)drawtext("H #z2#" ,y,z*1.0007)drawtext("L #z3#" ,y,z*1.0010)drawtext("C #z4#" ,y,z*1.0013)drawtext("x #x#" ,y,z*1.0016)j=kama[7838]//drawtext("j #j#" ,y,z*1.0019)endifreturn Kamasomething happened on Friday Feb. 12th, 2021 at 06:54 (Utc+1, or CET) on TF’s lower than 70 seconds.
02/20/2021 at 8:02 PM #162133I forgot to attach a couple of screenshots.
02/20/2021 at 9:24 PM #162138Hi Roberto, thank you for the explanation, but how is it that the built in Kama indicator (adaptive moving average in the PRT platform) is working fine but the code version is not. I attached a screenshot in my last post which shows the comparison between the the two indicators in action. At around the 6am time point the code version from Nicolas starts to break down and stay at constant value, but the built in indicator continues to follow the price action. I don’t know if you saw my post 162128?
02/21/2021 at 1:42 AM #162147I couldn’t find the reason, but I found out that up to 7K units it works like a charm even on a 1-minute TF, while with 10K or 15K units it doesn’t!
I read your posts and I don’t know why PRT’s works (despite it is slightly different), and Nicolas’ doesn’t (I also tried the same formula in a slightly different way, but didn’t work either).
02/21/2021 at 12:27 PM #162169thanks Roberto for looking again. At least we both see the same issue.
Do you think some fail-safe code can be put in place to circumvent this given what you have found about the OHLC?
I tried inserting in something like, IF KAMA = KAMA[1] then set KAMA = KAMA[2] in the hope that it will by pass the bad market data, but this did not work.
Can something like this be done that you think could get round the problem?
02/21/2021 at 12:36 PM #162173No, it’s something unpredictable. Maybe next time it happens on a 10-minute TF on CAC40, who knows?
It’s much better if you open a ticket with PRT (key combination Ctrl+M on your keyboard). There must be a reason which is better to find out.
If you do, please share any answer you might receive, no matter when.
02/21/2021 at 1:01 PM #162177I have just raised the issue as you suggested, but I am not getting my hopes high as who knows when they will look at it..
if it’s bad market data at one specific point in time, then why is it not possible to do a tactical error handler, at least whilst the developers look at fixing it?
surely by saying something like, if the current price close is a “bad one” then calculate the KAMA on the prior (or whichever one is a good one from past) close and then continue?
i will wait until someone from PRT responds but just need something in the meantime. Thanks again!
-
AuthorPosts
Find exclusive trading pro-tools on