Directional Movement Indicator Error?

[mbuta]

I absolutelly agree with you, about eSignal support people.

I complained about this even to their manager and the conclusion was that:
a/ They are too busy trading for their accounts and they don't give a damn about us.
b/ That they are under no obligation to give us support, for the money we pay. They respond only if they want, usually, stupid questions.
They work with a Russian team and almost nobody around here understand what is going on.

This is the message the manager of EFS support team conveyed to me.
Pretty sorry for us, but we deserve it, if we continue to pay.

Mihai Buta

[ScottJ]

Mihai,

I’m sorry to hear you’re frustrated about our support of EFS but I certainly can’t agree with your characterization of our attitude. While some of us do trade the markets, we would never let our trading interfere with our responsibilities.

In terms of supporting EFS, we’re actually quite proud of the community and support systems we’ve built to help our customers use eSignal and EFS to it’s maximum capacity. From building the EFS Library, partnering with consultants, building and supporting these forums and working with many dedicated users, we’ve been able to provide a host of ways to take advantage of EFS at little to no cost. Custom programming usually starts at $100 per hour so we’re pretty happy we’ve put all these mechanisms in place so users get help at no charge. We also have our in-house EFS Specialist (Jason) helping on the boards each day and our other programmers helping, when time permits, as well.

This post provides a more complete picture of what we’ve put together to support EFS.

In terms of troubleshooting existing built-in studies, we have seen many examples where users working together have sorted out the issues and resolved the problem. When that doesn't work, that's certainly when we do need to step in and handle directly.

Robert,

Our apologies for not responding to your posts of 11/8. We had read them and have been researching the issue internally. We should have a response ready in a day or two. Sorry again for the delay.

Thanks.

[mbuta]

I cannot aggree more with you that the "community" does a great job, but you just confirm my point: you do NOT provide support, you let us bang our heads.

For the money we play every month we deserve much more than "community" support. Not the community gets our money, you do.

[ScottJ]

While I appreciate your point of view, from our standpoint, we've done much more than just set-up these forums and step back. Here's just a few examples of the way we're directly supporting users and enhancing the success of these forums:

1. Jason ( our EFS Support Specialist ) regularly responds to questions on this board. He's moving towards 800 public posts and has responded to hundreds of other questions via PM and email. Jay also helps with EFS questions as well.

2. We've spent a great deal of internal energy working with EFS consultants like Chris Kryza and Brad Matheny, who both regularly contribute on this board as well.

3. We also work very closely with several of our "power users" ( like Garth, Dloomis and Alexis ) so they can take what they learn from our programmers and spread their knowledge to as many users as possible.

4. We have our web people updating the EFS library as often as possible.

5. We have held EFS WebEx and Chat classes to train users and plan to record a series of classes on using EFS in the near future.

6. Lastly, we are working on EFS2 for version 8.0 that we think will make using EFS easier than ever before.

In the end, we built our support for EFS around the one-to-many support model, versus the one-to-one model. You're right that we don't take the traditional call into our support group to answer the question "how can I build the XYZ study" but we do feel we've created a support system far more powerful than the traditional one-to-one model we could have provided. After all, the real power and creativity of EFS is in the hands of the users.

Thanks.

[Doji3333]

Can I jump in here???

I have a few questions and would like to offer my assistance...

first, you stated in your original post " I have written my own efs study from scratch using what I beleive is the correct methodology as given by Welles. However, when checking my results against the built in study there are a number of anomolies every so often seen in all 3 indicators (PDI, MDI & ADX)."...

What modifications from the standard formula have you adopted in your "correct methodology"?? I would think these would potentially be causing the variants in the two systems.

second, have you verified the data in your arrays?? Often, an error in the array count (adding an additional value or forgetting about another value will cause these type of problems).

Speaking of this.... it appears that once your logical variables (bADX_G, bTR_G, bPDI_G) get set to "true" - you quit updating your arrays. Is that what you want it to do??

I understand your code enough to know that you are "normalizing" the values of your indicator and may not want to continue updating the arrays. But I would strongly suggest you go back through your "Math" for these "normalizing" functions.

The other thing I noticed is that if you look at the "beginning" of your indicators results (the left edge of the chart) - you'll see that your indicator does not match the results of the eSignal indicator. These "non-matching" values to start with (when normalized" will probably result is incorrect values throughout the rest of your indicator. You know the old rule - "garbage in - garbage out".

Generally, it is a matter of debugging. You are very close to getting it perfect. I would suggest starting with a time template of about 30 bars. Match the items for these 30 bars so that they are perfect and verify the data from your system. Once you have identified any protential bugs, then apply it to larger amounts of data.

Trust me, I completely understand how frustrating it can be sometimes. I just completed a RT trading app (with NinjaTrader) for a client that was a combination of three different entry systems (each with its own PT/stop and reversal code). So, I had to create a means of handling all of this while running everything in "real-time" - and passing the proper order instructions over to NinjaTrader. Let me tell you about "debugging".... LOL.

I'll be here to help you if you need it.. My observations and comments are just that - my observations... I think you'll find variances in the way your system calculates the initial values for your indicator and possibly find variances in the way your indicator "normalizes" these values. These could be the root cause of your systems variances..

Hope this helps..

Brad

BTW, I find the esignal staff very supportive. Sure, sometimes it takes a day or two for them to reply to my detailed requests (maybe longer). Just my opinion again..

[mbuta]

Scott,

Thank you for keeping this discussion open.
I agree that Jason and all the other names you mention do their best to provide provide answers to others.
However, I am sorry to realize that you continue to defend a system (of support) that has obvious holes and leaves so many of your paying customers so frustated.

I am dissapointed that, like your manager, don't even want to consider that maybe the system is sub-par and needs to be improved.

From your own posts, Jason is the ONLY EFS Support Specialist from eSignal.
Is this all you can afford from our monthly contribution??????
Is this all we deserve for our montly contribution??????????

Here is where we disagree. I think we desrve and that you have an obligation to provide more for the money we pay.
History shows that companies which ignore this basic "customer satisfaction" issue, have their days numbered.
I hope eSignal wakes up in time!

Final note: Please keep in mind this. I pay more than the cable TV, or the phone service and that's ok, if you help us make money, but so far you don't (or very minimal). We spend 90% of my EFS coding time fighting EFS, rather than a trading system and this is unacceptable, in my view.

Thank you.

Mihai Buta

[rcameron]

Brad,

Thank you for your comments. As far as I can within my coding capabilities and understanding of the methodology concerning this indicator, I have correctly programmed the indicator as given by the referenced study (ADXMan.r.1.0.2.efs). I have checked my code methodology against other platforms such as Tradestation and in fact in great detail with Futuresource which uses a javascript like language to ensure that I am using the correct method of calculation as well as coding correctly. To summarize Wilder's method to derive PDI, MDI & ADX as well as the coding decisions I have taken:-

1. Calculate the differences between the current highs and lows against the previous highs and lows. If the current bar is an inside day or where the high and low differences are equal then no values will be recorded. Otherwise if the high difference is greater than the low difference the value is stored and vice versa. In my study the variables used are nDIP_M for the high differences and nDIM_M for the low differences.

2. Average the High differences, Low differences and True Ranges using Wilder's EMA Alpha. Therefore to minimize cpu load all you need is to keep the previous value to make the necessary calculation i.e:-

Wilder's Alpha = 1/Period
( Note: Tradestation uses 2/(Period-1) )

Formula to calculate Wilder's EMA (standard for all EMAs):-

Alpha*Current Value + (1-Alpha)*Previous Value

or more succinctly as used in the study:-

((Previous Value *(Period-1))+Current Value)/Period

However the issue is how to handle the initial bars to allow the computation to start. I have used the methodology of using SMA for the first "Period" bars. Furthermore as I wish the study to run precisely in real time and update on every tick, I added quite a complicated routine to cover the first "Period" bars which practically could be considered unnecessary as no one will ever see what happens in the first few bars of real data.

But as I perform all my testing on both real time data and playback data I wanted this to display absolutely correct with playback data as well. So the routines seen in my code are there for that reason. To summarize what happens is that an SMA is built with arrays flip-flopping between NEWBAR/CURRENTBAR states until "Period" has passed and an SMA is then calculated which will be used as the previous value for the next bar following "Period".

After this point no arrays are used nor are any SMAs performed, The averages of nDIP_M, nDIM_M, nTR_M (i.e. ATR) are then strictly calculated using Wilder's EMA methodology. So all we need is to keep the previous value and hold it in memory using NEWBAR state to ensure that any calculation is performed correctly in real time using tick data. The previous values are kept in the variables nPDI_P_G, nMDI_P_G, nTR_P_G. The current values are placed in nPDI_G, nMDI_G, nTR_G for further computation.

3. Compute PDI & MDI for "Period" using:-

PDI = (Average of Up Values / Average of True Ranges) * 100
MDI = (Average of Down Values / Average of True Ranges) *
100

Regarding the issue of display with playback data, the code exits until "Period" bars have passed to prevent garbage being displayed. Note that eSignal's built in study does not do this.

4. Compute a normalized DX as per Wilders:-

100 * Abs(PDI - MDI)
------------------
(PDI + MDI)

5. Compute ADX which is the average of DX using a smoothing period, where the methodology used is exactly as that described for PDI, MDI & TR. Again ADX is not displayed until ("Period" + "Smoothing Period") bars have passed again to prevent garbage being displayed at the beginning of a study. Again eSignal's built in indicator does not do this.

To conclude there are 2 areas where I can account for the differences between my study and the "canned" version:-

* Beginning of a data set.

* Where True Range has an affect especially where outside bars follow no range bars commonly found in short period futures intraday data.

Because I have found anomalies in the built in ATR study when I wrote my own indicator and then had confirmation from eSignal that there was indeed a bug in the canned study, I believe that this problem has continued in the ADX study and was the main reason I wrote my own study to see if there were differences.

As to calculating averages at the beginning of a data set, eSignal just does not display right unlike my study. In fact I have found this problem on a few of eSignal built in MA studies such as WMA, RSI so I have now wrote all my own replacement studies as I cannot trust eSignal ones anymore.

I believe eSignal's programmers have to explain whether or not they used the buggy built in ATR code within the ADX study and account for the problems displayed by their ADX at the beginning of the dataset and what methodology has been used to calculate the initial average. then we can compare "apples" with "apples" and see who is right. Ultimately I want a study that I can believe in as it is a key component in my trading decisions and I want it to be completely reliable.


Robert

[mbuta]

Brad,

Here are two parallel discussions: one about his ADX indicators, one about the level of support.

On the technical issue, I think you are right and you can see my post about this lower.

This is a classic MA vs WellesSum issue.

The way I resolved it is as follows:
if SourceArray.length < nInputPeriod => make a regular MA (sum/SourceArray.length)
else regular WellesSum.

I am sure that eSignal has taken this issue to resolve, as Scott said. This posting is been here for two weeks. If it takes them that long to respond, .... NO COMMENT!

Mihai

[Doji3333]

Thanks for the assistance..

I plan on going through this code more completely after the markets (trying to find any issues that may cause these problems). I know, from experience, that complex code often requires complex debugging.

I will continue to offer my assistance to people who need it. This is a good example of a user that has spent valuable time developing an indicator. Now, all of us should look at this as an exploration into proper debugging.

If we find that the code is 100% correct (no problems) - then we'll attempt to find a resolution to the errors by identifying and re-thinking our code instructions. It should be pretty simple to resolve (once I get into it).

Regarding the support issues that have been mentioned. I'm just going to speak from experience (my own personal experience).

I have worked with many other firms (not naming names). I find that esignal's response to technical issues is relatively fast. I know they have a good staff of people who are willing to help all of us - but not all of them are programmers.

Over the past 14 months (or so) - esignal has done quite a bit to assist all of us (the BB, Fileshare, weekly chats, support people, Jason as well as many of the other people who assist - me included).

But let's face it... Esignal provides EFS for us to develop and explore our own ideas - not to develop,debug and test the code for us. I look at it like this... I may pay a subscription to my cable TV company for the services they provide (including internet), but I don't expect them to help me develop my web site or develop some web application. If I have a problem with their "service" - I expect support. If I have a problem with something I created to use WITH their service - I expect a much lower level of support (sometimes NONE). EFS is supported by many means (including this BB) - which is far greater than "NO SUPPORT".

I can't speak for the programmers at esignal - but I would guess they are doing everything they can to resolve current issues and improve the application.

Also, regarding the people on this BB who offer assistance "out of the kindness of their hearts and willingness to help" - we need to give them "all the credit in the world". You know who you are.. These people are offering their time, knowledge and assistance to all of us.

Let me ask this question... Let's change the focus of this issue a bit. "What would you like to see esignal do to further support their EFS language and the users?". Remember, keep this to reasonable requests - what do you think would help all of the users?

Hope this helps..

Brad

[mbuta]

Brad,

You are one of those great guys volonteering their time and efforts to help others. I downloaded some of the files you shared and they helped me a lot.

Also, I never expected anybody to write code for me. If I wanted that, I would have hired you or an other specialist.

After I became somewhat familiar with EFs, I asked for help if, and only if, I did not find proper documentation.

Many of my questions, like this guy's question, never had been answered. If no charitable soul found an interest in my question, nobody in eSignal gave a damn.

So to respond to your question, I expect eSignal to provide the following two (2) things:

1. Proper documentation for what they put out and
2. Make sure that ALL our questions get answered, properly. They should step in if (a) nobody else provides a solution or (b) if they see that the response is incorrect (with all due respect for the "power programmers" I did get guesses and interpretations rather than straight answers).

Jason is the only one who tries to provide this function and it is too much for one soul.
I would expect them to have several applications engineers in charge of constantly improving the documentation, organize it and put out examples and building blocks. After all, we are traders not programmers.


Is this too much to ask?

sincerely and respectful for your energy and willingness to help others,
Mihai Buta

[Doji3333]

My reply...

Mihai,

As I'm not really qualified (or authorized) to speak on behalf of eSignal - I offer my reply again as my personal observations. I'm sure the proper (eSignal) people will reply to your post with their comments soon.

I agree with the "documentation" issue. I know there are some undocumented features within EFS currently and I expect the good people at eSignal will release updated information about these in the near future. I know they have not done this on purpose - they have gone through a huge development process over the past year (releasing more than 10 improved versions - about 1 per month to the best of my knowledge). The down-side to this is that sometimes documentation lags the products release - it happens alot in this "tech" industry.

Regarding your request to have all questions answered quickly - this raises some issues the I think eSignal will have to contend with..

1. Most EFS questions are easily answered by the staff at esignal - or by the good people on the BB.
2. Some questions are regarding BUGs or debugging questions - this falls into the catagory of "fixing non-esignal related issues for users".
3. Other questions are regarding "How do I do this?? and can someone help".. These fall into the catagory of "can esignal adequately address and resolve these ever growing requests.

I feel that #1 is a no-brainer and I feel that esignal is doing a good job of handling this aspect of "support".

#2 has fallen mostly onto Jason's shoulders (as well as the other good people of the BB). I will admit, sometimes questions go unanswered though. I don't think it is a matter that everyone chooses to ignore the request for help. I think it is more of a matter that the available staff can't debug every issue for every user. Plus, there is a fine line between helping someone debug a file and "fixing it for them". I trust you understand my point.

#3 is generally handled very well on this BB. Most people who are trying to accomplish something and can explain what they want are provided with suggestions, example code and sometimes "complete working EFS files". Again, sometimes these questions fall through the crack - into the "black hole".

Except for the Documentation issue, I feel esignal has more than adequately adopted a strong customer support value to their products. Of course, your requests won't fall onto deaf ears. I'm sure your request will be listened to and changes will come to address issues you have raised.

As a general rule - the BB and File Share should be everyone's first source for help and information (IMHO). The EFS HELP CENTER is a great source for additional information, but this BB is simply a great source for all of us.

Programming is something that is not "finite". It often takes many months of development to get something "perfect". Taking on a project of moderate complexity by yourself means you have to put in the effort and time to make it right. There are no real shortcuts when developing a system - it is normally ..

while (!perfect) {
Debug();
Develop();
Test();
}

The never-ending loop of developers.

Use the resources that are available and again I offer my assistance to anyone that needs help. Of course, I am only able to work about 15 hours a day (yeah - right!!). But I will do what I can to help most people. Remember though, I also do this as a business - so paying clients come first.

BTW, I appreciate your ability to discuss this with me. We are making positive progress.

B

[JayF]

ADX Issue

Robert,

Please be aware we are looking at the ADX issue (as Scott mentioned,) and once we have some firm details to report, we'll post again.

Thanks to all for the comments (both positive and negative.)

[rcameron]

Whilst we await the review of the ADX issue, I'd like to put in my '10 cents' input regarding documentation & support.

I have to admit that using EFS is very tough if you want to to anything fancy unlike other platforms which have a very easy to use macro language so for most users it is easy to create complex systems without much programming knowledge (or coding!).

However I like the power that EFS provides and unlike most platforms indicators update in real time on every tick which is a must if you are a "scalper" or intraday trade heavily where fractions of a point count in trading profitability.

I have now put in the requisite time and effort to be able to code complex routines and although BB provides many extremely useful pieces of information and example studies that help in the learning process, I believe that it should be a 'must' that eSignal provides complete and full documentation on every function used in the EFS language with copious examples. This should be made available through a centralized help file.

The best resource so far is the help file made by C. Kryza of Divergence Software, Inc. However, this should be the duty of eSignal to provide and update so that everyone can have access to one file which should be available as an automatic download as soon as a new version is released and available through eSignal program itself just like the current help file. Having to look through many BB to find something that helps is not the right solution.

Secondly, all the built in indicators must be fully documented showing the methodology of calculation used as there are so many variations on the same theme in some cases that it should be known precisely the way each indicator has been derived. Of course I am only talking about the basic studies, as I know that no one will release information on the proprietary studies available through eSignal. personally that is another issue which I don't want to go into depth on.

Finally, anyone posting a query should have it answered within 10 working days, whether something, or nothing will be done or the matter is pending, especially if it relates to the operation of eSignal and/or indicators/tools etc.. provided by eSignal. Requests for new studies does not count in this regard and should be handled separately.

Robert

[FibbGann]

I have no problem finding 95% of all information I am after for esignal. Is it all easy to find? Probably not... I would have to say you get what you put into it. I came to this website clueless about esignal and this website. After returning countless times, I consider this website to be an essential tool for my trading needs.


I want to thank everyone at esignal for the dedication, along with the countless hours others have dedicated to this site . You know who you are!

Sincerely,

Fibbgann

[mbuta]

I am glad to see that some people are happy with the support they receive from eSignal, but I have IBM mainframe school and there unless a product is completelly tested, validated and supported you wouldn't dare to bring it to market and ask anybody to pay for it.

I know that DOTCOM era changed the standards, but all have seen what happened to them.