Hi,
I actually made my own Heikin Ashi bars, based on the HA indicator hosted in the user contributed forums here. It plotted almost exactly the same as the user contributed one and worked very well. There was a drawback though. As it was not a native bar type, other indicators could not set bar colours, high/low etc were slightly out vs the hidden bar, etc. Performance a bit of an issue. It was perfect visually, but broken technically! So, I switched to trying to use the native HA bars in NT8. They are not formed the same and I suspect they may be incorrectly coloured etc. Looking at the code, the native HA bar type seems to set the high/low/close and inherit the rest? This includes bar colouring. So, for instance, NT8 native HA will colour a HA down bar green (up colour), when under the HA rules, it's still a down bar. Also, I notice differences in the opens, wicks, and closes. In looking at the code, the calculation formulas are written differently, but seem essentially the same, so I cannot see the reason for this.
So, couple things. Can your developers take a look at the HA bar type and check the bar colouring? (example below). If there were a way to look at the formula and determine why the indicator HA bars look so much nicer and closer to what would be expected in HA (IMO), that'd be good. I want the native bar type, but I want the indicator bars!
To replicate, you can just add 2 of the same data series to any chart. Leave one as a standard tick bar for instance, then add the HA indicator to it, then add the same tick data series to the same chart, but with the native HA type. They should be the same, assuming the calculations are correct, but they are not. Feel free to compare the same on another platform too. PRT for example, I tried.
The NT8 native ones look quite clunky and not smooth, like the NT8 indicator and HA on other platforms. The differences are subtle, but it does seem the NT8 indicator version is much more in line with what would be expected when I compare with other platform HA etc., and I certainly prefer it, visually etc.
[edit] some of the issues I am seeing, might be down to series rounding. I tested a version of the bar type without the 'roundtoticksize' calls, but it seems NT8 may simply internally round the bar numbers anyway, as this made no difference and I found other posts indicating same. Some of the errors arefar more than a tick or 2 though, particularly the odd body open/closes, so not sure this is the issue.
If it is, and there is no way to use precise numbers for bar high/lows etc., there might be a workaround (albeit with performance penalties) if I could retrieve dynamically set bar colour outlines and body colours on each tick and hide the original bar series, rather than making it transparent.This would allow other indicators to change the bar outline colour for example and for it to be correctly used when the bar is re-drawn in onrender by the indicator. I cannot however see this is possible.
Any comments?
Thanks.
I actually made my own Heikin Ashi bars, based on the HA indicator hosted in the user contributed forums here. It plotted almost exactly the same as the user contributed one and worked very well. There was a drawback though. As it was not a native bar type, other indicators could not set bar colours, high/low etc were slightly out vs the hidden bar, etc. Performance a bit of an issue. It was perfect visually, but broken technically! So, I switched to trying to use the native HA bars in NT8. They are not formed the same and I suspect they may be incorrectly coloured etc. Looking at the code, the native HA bar type seems to set the high/low/close and inherit the rest? This includes bar colouring. So, for instance, NT8 native HA will colour a HA down bar green (up colour), when under the HA rules, it's still a down bar. Also, I notice differences in the opens, wicks, and closes. In looking at the code, the calculation formulas are written differently, but seem essentially the same, so I cannot see the reason for this.
So, couple things. Can your developers take a look at the HA bar type and check the bar colouring? (example below). If there were a way to look at the formula and determine why the indicator HA bars look so much nicer and closer to what would be expected in HA (IMO), that'd be good. I want the native bar type, but I want the indicator bars!
To replicate, you can just add 2 of the same data series to any chart. Leave one as a standard tick bar for instance, then add the HA indicator to it, then add the same tick data series to the same chart, but with the native HA type. They should be the same, assuming the calculations are correct, but they are not. Feel free to compare the same on another platform too. PRT for example, I tried.
The NT8 native ones look quite clunky and not smooth, like the NT8 indicator and HA on other platforms. The differences are subtle, but it does seem the NT8 indicator version is much more in line with what would be expected when I compare with other platform HA etc., and I certainly prefer it, visually etc.
[edit] some of the issues I am seeing, might be down to series rounding. I tested a version of the bar type without the 'roundtoticksize' calls, but it seems NT8 may simply internally round the bar numbers anyway, as this made no difference and I found other posts indicating same. Some of the errors arefar more than a tick or 2 though, particularly the odd body open/closes, so not sure this is the issue.
If it is, and there is no way to use precise numbers for bar high/lows etc., there might be a workaround (albeit with performance penalties) if I could retrieve dynamically set bar colour outlines and body colours on each tick and hide the original bar series, rather than making it transparent.This would allow other indicators to change the bar outline colour for example and for it to be correctly used when the bar is re-drawn in onrender by the indicator. I cannot however see this is possible.
Any comments?
Thanks.
Attached Files
Comment