Incorrect PSAR in Super DOM Using Ticks

[hotdog]

When adding the PSAR indicator to a tick chart (233 ticks) in Super DOM the calculation of PSAR is not correct. When using a minute chart (15 min) it seems to be fine.

[NinjaTrader_ChelseaB]

Hello hotdog,

I tested adding the Parabolic SAR indicator to a chart and to the SuperDOM, but I found these have the same value.

Below is a link to a video of this test

http://www.screencast.com/t/QVtbWI1kz

Using the same steps outlined in the video, are you getting different behavior?

Are you using the latest version of NinjaTrader 8 (8.0.2.0)? (You can check this in Help -> About...)

[hotdog]

I am not questioning whether the values are the same in charting and DOM. In fact, I would assume they would be. My post claims that the calculations are incorrect for PSAR when using TICK data. After further observation, it seems they are also incorrect for minute data as well. Yes, I am using the latest version 8.0.2.0.

I use several other programs other than NT8. When using PSAR in NT the PSAR values are no where near to the values displayed in other programs. In addition, I would note that there have been numerous Internet posts in the past complaining about NT PSAR calculations. I have been unable to find similar complaints about PSAR in any of these other programs which are industry bellwethers and have been stable for a very long time.

I have used NT default parameters for both minute and tick data. However, I have tried playing with the variables you offer for PSAR which has not proven to be of any help. My expectation is that your PSAR should follow Wells Wilder's calculations exactly Could the problem be that you are using three factors in acceleration where others are only using the standard AF and Acc Limit?

[NinjaTrader_ChelseaB]

Hello hotdog,

I cannot comment if the algorithm of the ParabolicSAR is correct or incorrect.

However, I have created a video that shows the value of the ParabolicSAR has not changed from NinjaTrader 7 to NinjaTrader 8.

http://www.screencast.com/t/P5oJxsnD

If you have an alternative algorithm you would prefer, you can add this to a custom coded indicator and use this indicator instead.
I am also happy to submit a feature request on your behalf for the NinjaTrader Development to consider using your alternative algorithm. Please supply an alternative algorithm if you would like me to do this.

[hotdog]

Thanks for the reply. The standards you mention are not "my" standards that need to be adhered to - they are the industry standard as per the developer, J. Welles Wilder. Any other calculation is erroneous and prevents the accurate use of the indicator the way it was intended.

Unfortunately, there have been complaints about NT's PSAR calculation for years in NT7. Many people complained and tried to get NT folks to do something to fix the calculations. After many months of frustration and no change, many of us simply moved to another platform. With the advent of NT 8, I thought I would take another look.

Here are links all the way back in 2008 and 2014 complaining about the NT PSAR calculations...

https://futures.io/ninjatrader/31700-bugs-ninjatrader-parabolic-code.html

http://mobile.ninjatrader.com/support/forum/showthread.php?p=68014

I am not a programmer of indicators, however, I can tell you that a bulletproof example of what works correctly can be found in the coding used by TOS and Tradestation.

Here is the TOS code. It is not proprietary as the algorithms are public domain.


input accelerationFactor = 0.02;
input accelerationLimit = 0.2;

assert(accelerationFactor > 0, "'acceleration factor' must be positive: " + accelerationFactor);
assert(accelerationLimit >= accelerationFactor, "'acceleration limit' (" + accelerationLimit + ") must be greater than or equal to 'acceleration factor' (" + accelerationFactor + ")");

def state = {default init, long, short};
def extreme;
def SAR;
def acc;

switch (state[1]) {
case init:
state = state.long;
acc = accelerationFactor;
extreme = high;
SAR = low;
case short:
if (SAR[1] < high)
then {
state = state.long;
acc = accelerationFactor;
extreme = high;
SAR = extreme[1];
} else {
state = state.short;
if (low < extreme[1])
then {
acc = min(acc[1] + accelerationFactor, accelerationLimit);
extreme = low;
} else {
acc = acc[1];
extreme = extreme[1];
}
SAR = max(max(high, high[1]), SAR[1] + acc * (extreme - SAR[1]));
}
case long:
if (SAR[1] > low)
then {
state = state.short;
acc = accelerationFactor;
extreme = low;
SAR = extreme[1];
} else {
state = state.long;
if (high > extreme[1])
then {
acc = min(acc[1] + accelerationFactor, accelerationLimit);
extreme = high;
} else {
acc = acc[1];
extreme = extreme[1];
}
SAR = min(min(low, low[1]), SAR[1] + acc * (extreme - SAR[1]));
}
}

plot parSAR = SAR;

I would think your programmers could easily convert this to a NT script that would work correctly. Any help in correctly resolving this long-standing issue would be greatly appreciated.

[NinjaTrader_PatrickH]

Hello hotdog,

Thank you for your patience.

The ParabolicSAR in NinjaTrader 7 and 8 has been confirmed as correct for Day, Minute, and Tick based series. If you have a specific calculation that you would like to see used instead you can develop a custom indicator for your preferred calculation.

[hotdog]

NinjaTrader PSAR Calculation Incorrect

Thanks for the reply. That is an unfortunate, but expected answer. Although NT continues to claim the formulas are working correctly, comparison to many industry-leading platforms clearly shows otherwise. In fact, the big confirmation of this is that when the markets hit the PSAR values in other platforms, there is much reaction in price. With the NT PSAR - no real change in market behavior. A second confirmation is that many web references to PSAR calculation problems can be found but interestingly, not so for other platforms.

I am not sure why NT people refuse to really dig into this after many years and multiple complaints, but it essentially renders the product useless for any serious PSAR traders. We had high hopes with the new Super DOM indicator tie in, but now that appears dashed.

To continue to say. "Build your own indicator if you don't like ours" is quite frankly, insulting. If you include an indicator with its original given name, it should be programmed exactly like the inventor designed it. Otherwise, it is clearly misleading to the public and should be named differently.

The most unfortunate aspect of this issue of not being really willing to dig into NT code when a problem is clearly identified by the users is that all other indicator calculations become suspect. As stated earlier, I moved away from NT 7 because of this same issue. It now appears I have to also move away from NT 8 as well.

[NinjaTrader_Brett]

Hello,

Thanks for providing details on what you found.

For some context: We find that many indicators have different implementations between platforms. Therefore comparing platform implementations is of little to no value since its expected they can disagree since there often is not industry consensus on formulas. The only true method is using the authors original publication for the information needed and unfortunately the original publications especially on older indicators don't go into needed depth on how to process indicators e.g. intraday or intra bar and can even have some ambiguity in the details that there is no way to truly rectify without talking to the author for clarity. Which is the reason why there can be differences and is no consensus on some indicators. We tend to use the following resource as our primary reference source since its done us well in the past: http://www.fmlabs.com/reference/default.htm

Without strong reason we likely would not change the implementation. Since changing the implementation will change many users charts who have relied on the implementation for now many years. Such a change is not to be done lightly and only done if something is found is clearly wrong.

If you would have time to help me zero in on an analysis if something clearly is wrong. Could you point me to a behavior which you don't see in NT that you see in another application. I could look into that area specifically if there is something you could put your finger on there. However please note that it might not be the indicator formula and could be from another reason such as 'input data being different', or 'break at end of day' on tick charts, or session template being used on a chart, etc. These items do matter on SAR which use results of a previous bar into the next. There are two ways to get a different result: Different formula and different data.

-Brett

[hotdog]

NT PSAR Issues with TICKS

Brett,

Thanks for the more considered response on this issue. Although I definitely understand that the issues you mentioned can have an impact on the indicators, the reality is that I have not found changing them in real time causes any real variance.

As an example, I have changed 1) Maximum Bars Look Back, Break at EOD and Days Back and not one of them changed the indicator value even 1 tick when plotting a 233 tick in SuperDom. However, changing from EVERY TICK to ON PRICE CHANGE did move the NT indicator closer to TOS by 1 tick.

In comparing the results of the NT implementation with other platforms, there is sometimes a 12-15 TICK difference when viewing the indicator in ticks. This tells me that at least one platform is not even close to implementing the formulas correctly.

To try and debug this for you is a major task as it requires constant watching and evaluation over multiple markets and comparing it with the movements of other platform implementations. However, I can tell you this from observation so far:

1) Using a 30 minute period seems to very closely approximate other platforms, at least in a slow market. As an example, in /GC today, using a 30 minute period I see a PSAR in TOS of 1141.0895 and in NT 1141.1. Certainly within the rounding margin of error and insignificant. This tells me that up to a point, the implementations are the same.

2) However, when I apply a 233 tick period to both, I get 1136.8018 in TOS and 1138.3 in NT! That's like MILES apart. And, using the exact same parameters that were used in the 30 minute.

3) In addition, if I try to change parameters on NT for no Break at EOD, every time I go back to the indicator parameter screen the EOD is re-checked, even though I just saved it with no EOD. Sometimes, when adjusting parameters the PSAR DOM marker just disappears completely and won't come back until killing that DOM and starting a new one. This is in tick mode, not minutes, as far as I can tell at this stage.

4) The longer a market is at rest, the closer the NT PSAR gets to the TOS implementation value. This certainly seems to be related to a huge difference in the acceleration implementation of the indicators.

5) When the two implementations are in agreement and the market is at rest and the PSARs flip, they also generally agree at the initial stage. It is when the market begins to accelerate that the NT indicator seems to deviate greatly from the expected.

6) In conclusion, the TOS implementation in Ticks seems to work as expected throughout the entire cycle whereas the NT implementation seems to become erratic as acceleration factors kick in. This may be due to the bugs in the PSAR parameter implementations or in the coding of the acceleration factors. I also have to say that, at least from an introspective standpoint, I would think you would want to consider that there continues to be complaints about the NT PSAR implementation in the community but seem non-existent for other platforms. Finally, I would think that your team could do some comparisons with the stable platforms that have been in the market for many years and watch for yourselves what I am seeing Surely you want to know for sure what is really going on here.

[NinjaTrader_Brett]

Thanks for taking the time to reply, if you didn't care about NT you wouldn't have taken the time so I appreciate it.

I would agree your fact pattern does deserve some checking into. I'll add an item to our backlog to check into this and get back, appreciate you providing the extra details which would allow my to focus in my analysis on a specific area.

Number 3 on your list might be a separate bug though, I'll check into that separately.

-Brett