Built In ATR Study Incorrect Computation?

[rcameron]

After checking the built in ATR study with 2 or 3 different efs studies I have found that the built in study differs on every bar and on every time period using matching study periods. All the efs studies I have used match each other and use the following formula:-

True Range for each bar :-

TodayRange = (high()- low());
nTdHYsC = Math.abs(high() - close9-1));
nTdLYsC = Math.abs(low() - close(-1));
nTR = Math.max(nTodayRange, Math.max( nTdHYsC, nTdLYsC))

Initial ATR = Simple Moving Average of the first nPeriod Bars

2nd ATR and onwards based on Wilders Average:-

(((Previous ATR*(nPeriod-1))+nTR)/nPeriod)

Has anyone got any idea why the built in ATR differs and how is it calculated if not based on the above formula.

I have also checked the built in ATR against other averaging methods such as a Simple and Exponential Moving Average still with no correlation.

Robert

[eSignal_JasonK]

Hello Robert,

Thanks for bringing this to our attention. I've verified the problem with our built-in ATR study and have reported the problem to our development team.

There are some bars that use an incorrect value for the True Range for the calculation of the ATR. The attached formula outputs each bar's True Range to the output window. If you set the length to 1 and apply the built-in ATR study (also with a length of 1) you can see the bars where the built-in ATR used the wrong True Range value.

[rcameron]

Thanks for confirming that the problem exists. I thought I was going a little crazy when I could not get the built in study to match a development I am doing which I used the built in study as a cross check.

It would be nice if the built in ATR study had some more options to make it more flexible. It is with these issues that I have to design my own indicator:-

1. Start of Calculation period to be other than 0 (Current Bar), ie to start -1 (previous bar) with x periods. This can help when checking the size of the current bar range with the previous period such as wide range bar in Coopers set ups.

2. Choice of different moving averages, in addition to Wilders method choice of EMA & SMA. This can help in use of different Keltner channel formulae.

3. Finally instead of just doing true range on each bar, an option to do each bar's high - low only, a slightly modified option of doing high-low only if the range is greater than 0 otherwise use the previous close as the high/low for the current bar. This will give 3 options in total. This can help with various set up parameters for Wide/Narrow Range Bar Reversal/Breakout Setup ups.

Robert

[eSignal_JasonK]

Hello Robert,

Please submit your ideas for modifying the ATR study to [email protected]. Our development team reviews that mailbox.

[rcameron]

When will this issue be resolved? Will there be a fix in the new release?

Robert

[eSignal_JasonK]

Hello robert,

This bug has not been fixed yet. Development told me that next set of fixes for EFS will arrive in 7.6 at the earliest.

[ckryza]

Robert:

Just as a follow-up on this issue..... it appears that the following code will duplicate the ATR that is currently being used in eSignal.

ATR_1 = nATR;

nV1 = Math.abs( high()-low() );
nV2 = 0; //should be Math.abs( close(-1)-high() );
nV3 = ( close(-1) - low() ); //should be Math.abs( close(-1)-low() );

nTrToday = Math.max( nV1, nV2, nV3 );

nATR = ( ( ATRPeriod-1 ) * ATR_1 + nTrToday )) / ATRPeriod;

As you have already pointed out, this is obviously not the correct ATR. I have a strange situation, however, where a trading system I am working on actually works better with the current eSignal ATR calculation (e.g., the calculation above) than it does with the true Welles Wilder calculation.

Chris

[rcameron]

As much of my trading platform is heavily dependant on Ranges whether in the form of range only or averaged ranges (i.e. such as that in ATR), I have had to delve into every formula that uses TR to see what effect if any, it has on my trading decisions. In fact I have now built ATR and Range Only functions where the following can be selected:-

1. Unmodiifed High-Low; Only the current HL range is taken into account.
2. Modified High-Low; If the current bar has no range (i.e. where the High = Low), then a True Range is calculated otherwise the current range is used as 1.
3. True Range; i.e. using the Wilder's methodology.

There are also some other more esoteric range selections but they have not improved any trading decision at this time (where one day I am hopeful I will stumble upon something that is better).

From these selections, either a Range Only result is obtained to compute for example a Narrow Range or Wide Range bar ala Crabel and/or Cooper, or find a Wide Range Extreme Close bar which is based on an ATR ala Rudd.

From these requirements, I have to say TR as per Wilder is the best. In fact I looked at different MA methods to compute the ATR and I could not see any improvement over using just an SMA for determining a Rudd WREC bar.

I can understand that in some particular circumstances a wrongly calculated formula may lead to better trading signals. I myself stumbled (and that should be taken literally!) in my early coding efforts in developing an RSI indicator that gives superior signals to that of the original based on a completely incorrect methodology. This indicator is a 'piece of treasure' to me now.

However when it comes to PDI/MDI/ADX which I have a separate thread going on as per:-

http://forum.esignalcentral.com/showthread.php?s=&threadid=5274

I believe that you must use the precise formula as that developed by Wilder which means that the ATR is calculated using Wilder's EMA methodology. This is because if you want to interpret the data correctly, then you must use Wilder's recommendations as the values were based on his observations.

Again I have been rigorously testing my developed formula against that of eSignal's and there are important differences but I do not know yet if they are as a result of the ATR function or some other factor. From my trading experience thus far as well as backtesting, there is an ever so slight edge in using the formula I posted. However it may give you a trading signal just one bar early and not every time. So the jury is out on this one.

Robert

[rcameron]

Has this been fixed in the new release of 7.5? If not will it ever be fixed?

Robert

[FibbGann]

rcameron,

The best way for you to address your issues is to contact esignal support VIA e-mail or telephone.

Fibbgann

[rcameron]

I thought that this was the only forum that eSignal deals with user problems as defined by ScottJ in a separate thread.

It perturbs me that eSignal continues to make new releases where fundamental indicators are left uncorrected nor does there seem to be any hurry to resolve them.

Right now I have found 3 clear errors with built in indicators & tools :-

- ATR study
- ADX study
- Linear Regression Channel Tool

When you do testing with playback data or go right to the beginning of a price series, many of the other built-in indicators display garbage because little or no error trapping routines were utilized to prevent incorrect display.

Such issues has forced me to write all my own replacement indicators as I do not trust any of eSignal ones anymore which has then resulted in a degradation of performance, which is now forcing me to program everything as dlls! Rather than having all the fancy features lets get the fundamentals right.

Please note all my comments (& frustration) is directed at eSignal Development & Support.

Robert

[FibbGann]

rcameron

To best of my knowledge this form (website) was built for the users to help one another. !!! Which I must admit, is much more than any other trading platform service has ever offered! If you want to address certain issues you have, it is best to directly contact Esignal support by email or telephone. This is the best way. Although, many Esignal employee's respond to this board, the best way for you to obtain results of your particular issues is by contacting them directly.

Fibbgann

[rcameron]

i have advised eSignal support about all the unresolved bug issues. I want to emphasize that as all my gripes are concerning built in tools and indicators where everyone should be made aware of the problems especially if they rely on them for trading decisions.

Robert

[pflash50]

Originally posted by rcameron
i have advised eSignal support about all the unresolved bug issues. I want to emphasize that as all my gripes are concerning built in tools and indicators where everyone should be made aware of the problems especially if they rely on them for trading decisions.

Robert

Most (if not all) of the companies that sell market charting products and market data have problems like this. I used to work for one of eSignal's competitors and they had parts of their product mix that were just flat incorrect in the technical sense.

Of course, most (if not all) of these same companies want very much to eliminate these "zits". The problem with doing so is that they fall into two broad categories - bugs and design mistakes. When a problem stems from a bug it is relatively straightforward (but not necessarily EASY) to fix it.

However, when a problem stems from a design mistake it can be very tricky or even literally impossible to correct without redesigning the entire system. Few companies have the resources to do that.

===

My current pet example of this, as far as eSignal is concerned, is their decision to skip zero-volume bars rather than display them. Now, I don't know what genius in the company figured out that zero-voulme bars can safely be ignored, but anyone that has actually traded money in the markets knows how wrong he is. Liquidity is one of the most important things you need to follow when trading. And there is the alignment issue when displaying multiple symbols.

The powers that be in eSignal are now aware that not displaying these bars (actually, not giving users control over their display) was a Really Dumb Idea, but I don't know if they will admit this in public yet. The continued existance of this problem is the source of my belief that it stems from a design issue rather than a bug.

This problem is my reason for learning to use DLLs. I'm now able to display a time series that trades sparsely or that only trades from 9:30 to 4:00 ET on the same chart with the ES starting at 8:00, and have the data align properly over several days by filling in the missing bars in my external history array. Of course if there is a bar missing in the ES data I still can't do anything about that.

===

Your indicator issues might also be the result of design problems rather than bugs (explaining why they are still around), but this actually doesn't seem very likely. Indicator functions are generally self contained and rather small. If properly designed. So I wonder what is going on?

[JayF]

.

Originally posted by rcameron
Has this been fixed in the new release of 7.5? If not will it ever be fixed?
Robert

Please know that these have been put on the list to review for 7.6. When these were first reported, we were unfortunately too far along in the beta process to go back to introduce any new code. We certainly appreciate the time spent on discovering these issues. Please also know that as with all data accuracy issues we take these seriously, and we will address them as soon as we can (i.e. 7.6 is our next release, and we'll try our darnedest to fix it in that version.)