"Drifting" and Incorrectly plotted Study on Multiple Time Interval until study is reloaded - Back Test Reports Highly Inflated Profits

[demarcog]

When a simple indicator such as an EMA derived in a EFS using ema(20,inv(x)) is plotted on a loaded chart. The value for the higher time interval, such as a Weekly EMA 20 Value plotted on a Daily chart is not being plotted correctly in Real Time. The chart has to be reloaded inorder for the plotted values to be corrected.

This problem effectively means that although the documentation indicates one can access values from higher time frames in a loaded chart via the EFS using the getValue() and getSeries() functions this value is calculated incorrectly and cannot be relied upon for accurate results.

For example if a chart is loaded with a 15 minute interval and internally values such as ema(20,inv(60) are plotted.

In real time the 60 minute value is recalculated on every 15 minute NEWBAR and "drifts" into a narrowing range. This also results in a back test report showing a much higher net profit amount compared to when the strategy is run real time in an actual or Paper Trade Account. See the image below for (the left) the plotted indicators "drifting" as new bars occur on the smaller chart interval, and those values plotted after a efs reload.



If my understanding is correct, an EMA on a higher interval such as a the 60 minute should not change on each NEWBAR of the lower interval.

This problem which occurs whether the getSeries() or getValue() functions are used to access the values from the ema(20),inv(x)) object.

The eSignal documentation indicated that Multiple Time Intervals are supported, however in real time the values returned are incorrect and any strategy based upon utilization of these vitally important functions advertised is rendered totally ineffective, as I have learned that the hard way in actual automated trading.

The Attached image illustrates the problem in the first image the dots plotted are supposted to be an EMA on a higher time interval that the interval for the chart loaded. As can clearly be seen this value is calculated and plotted on each instance of a new bar on the chart interval. This could be a Monthly Time interval EMA and the chart could be a daily chart, or a hourly chart and it will recalculate on each NEWBAR on the hourly chart.

When the chart is reloaded (image on the right) the EMA on the higher time frame is recalculated and draw plotted correctly.

I have contacted support several times, provided, documentation, code, had it escalated and essentially told to post it to the Forum as EFS programming issues were not really supported via Customer Support.

As a 15+ year user of eSignal/AGET with 600+ posts this is truly astonishing that a major code issue that renders the product unusable for automated trading for strategies I have spent years developing is ignored. After pursuing this issue with support for weeks I was told that support was not the appropriate venue for resolving this issue and to post the problem to the Forum. I did this and no one at eSignal responded.

The fact that IMHO a serious code defect, as far as my use of the product is concerned has been found, documented and brought to supports attention and has been ignored is a major concern going forward with the use of what I consider the best product available for serious trading strategy development and has been for 20 years.

Hope this helps someone else avoid relying on inaccurate back testing reports, always verify in real time using the Paper Trading Accounts.



Good Luck,

Glen

[email protected]

[eSignal_AveryH]

Hello Glen,

Thank you for the post and we do truly apologize for the delay in getting back with you. We'll work with the EFS Developers and test what your reporting. To assist with troubleshooting the exact problems could you please forward the EFS you're using to [email protected]. Once we have the EFS we'll investigate and report back.


Thank you.

[demarcog]

Avery,

Thanks for the response, I will get that to you ASAP.

[email protected]

[eSignal_AveryH]

Hi demarcog,
Thank you for the code. So we've had our EFS Development team review the code and this is was the conclusion.

In short he is plotting values using the getValue() method which by definition is not synchronized on real time data. If that is the route he wants to take then, he himself needs to create his own efs routines necessary to do the synchronization. Please note that other users (including professionals such as Chris Kryza) who know how to code (and more importantly understand and know EFS) have no such problems.

His best option would be to contact an EFS consultant such as Chris Kryza and have them code the EFS if he is not able to do so himself

[demarcog]

Avery,

This is a extremely simple to explain and obvious bug.

Perhaps the support manager that dictated your response can understand this, in case their response was from a lack of understanding.

The functions getValue() and getSeries() as described in the product documentation simple do not return correct values when the multiple/external feature of these functions are used.

Here's the 3 lies of code:

xSMA = ema(20,inv(15));
INT15Sma = xSMA.getValue(0); <======== the getValue(0) or getSeries(0) returns incorrect data when the interval is external to the loaded chart interval

if (close(0, inv(15)) > INT15Sma

I am testing to see if the closing price of an external interval is above the 20 period moving average for that interval 15 minutes in this example. .The value returned is invalid and changes incorrectly on a new bar for the loaded chart interval (1 minute) and not a new bar of the 15 minute interval, an obvious error not in the EFS but the functions.

Now the manager out of ignorance or more likely their decision to not bother assigning the resources to fix the apparent bug instead hurls insults as a rationale for not fixing the problem.

His frustration is misdirected at the messenger, perhaps he should direct his code bashing exercise at the developer who wrote the getValue() and getSeries().

They simply are not working as designed and documented. There are ways as suggested to code around these defects but people are depending on and paying for the functionality advertised and described in the documentation, either fix the code, or correct the advertised/documentation, but attacking the user who gets hit with the bug stoops to new lows in my experiences with software products.

I have been associated with both the NYSE and ICE for decades and for every interaction I've ever had with any level of management or product support at many levels is flawlessly world class. I wish I could say the same for eSignal.

I very much appreciate your help on this and please thank Alexis, I know from our interaction that neither you nor Alexis are capable of this type of response and realize this new structure has effectively prevented people such as yourselves from providing the support you have in the past.

That does not bode well for the future of the product which was also a world class product and am saddened by the current situation.


glen

[email protected]

[ewdeg98]

Glen, Do you mind positing an EFS script that has the error present?

I'm using .getValue(0) a lot for real-time so I obviously want to check this out.

[demarcog]

This snippet easily reproduces the problem load it up on a 1 minute chart, the EFS is looking at returned values based on the 15 minute chart in the code below and if you plot the returned values they are all over the map every 1 minute. Those values should not be updated but ever newbar on the 15 minute and they are updated ever 1 minute, a massive bug in those functions.

if (getBarState() === BARSTATE_NEWBAR){ // only execute remainder of EFS script once on "NEWBAR",
if (getBarState() === BARSTATE_NEWBAR && getCurrentBarIndex() === nRTBarIndex){ bRealtime = true; }

xint1ema = ema(20,inv(15));
nint1ema = xint1ema.getValue(0);

if (close(0, inv(15)) > nint1Sma ){

///// GoLong(); relevant code from function copied below, actual functions obviously has a lot more logic regarding real time trade processing but essentially this is it

if (nBarState == BARSTATE_NEWBAR && !bRealtime && !Strategy.isLong()) {
Strategy.doLong("Long Entry", Strategy.CLOSE, Strategy.THISBAR, nQty );
}
if (bRealtime && nBarIndex == nRTBarIndex && nBarState == BARSTATE_NEWBAR){
buyCallback();
}


[email protected]

[ACM]

Glen

The original staff, Avery and Alexis care deeply about the product and customers they have not said so but I know their hands are basically tied in knots by the new short sighted l bean counters.

As I have stated many times before in these forums, I am not an employee of eSignal. Furthermore my hands are not tied in any way.
Anyhow, the reason returning a value (for plotting, drawing or what have you) works on historical bars but seemingly not on real time bars (it actually works also on real time bars as I will illustrate later in my reply) is that on historical bars the higher interval is completed so all the lower interval bars for the same time frame will retrieve only a single value (and specifically the same value) across all the bars that are included within that time frame.
In real time each lower interval bar will retrieve the higher interval's bar value AT THE TIME of the lower interval bar because the value of the higher interval changes as that bar is still developing.
Let us make an example using 1 minute (chart interval) and 15 minute (external interval) bars
On historical bars the 15 minute bar closes at 100 so when you plot that (again using the getValue() method) on a 1 minute chart that value of 100 will be the same across all fifteen 1 minute bars contained in that 15 minute bar.
In real time that does not happen by definition because at the end of the first minute the 15 minute bar may be at 101 so the value plotted on the 1 minute chart will be 101. Then at the end of the second 1 minute bar (still within the 15 minute time frame) the value of the 15 minute could be 99 and that gets plotted on the 1 minute chart. So now you have what is seemingly an unsynchronized plot. Actually it is synchronized in real time to the higher/external interval as that interval is still developing.
Now you have that effect that you incorrectly define "drifting" and that you think is a bug.
And to prove this, you suggest that if you now reload your script all the values will be at the same level on all 1 minute bars thereby failing to understand why that happened (see my above explanation about what happens on historical bars).
For the purpose of plotting alone, EFS offers the option to plot a series (either directly or by calling it using the getSeries() function - necessary when the series is within for example an initialization routine that executes one time only - which realigns in real time each value of the plot on the lower interval chart
To understand this just plot the following two scripts on a 1 minute chart and you will see exactly what I have explained above

function preMain(){
    setPriceStudy(true);
    setDefaultBarThickness(2,0);
    setDefaultBarFgColor(Color.red,0);
}
var x = null; //global variable
function main(){
    if (x==null) x = close(inv(15)); // assign Close series of 15 minute interval to global variable
    return x.getValue(0); //return to the chart the value of the 15 minute Close
} 

The above EFS will plot a single common value on all lower interval chart for all historical bars. However when it starts real time it will plot the Close of the 15 minute interval AT THE TIME each 1 minute bar ends.
If you let it run for the entire 15 minutes and then reload the efs all of a sudden you will see that all these different values will realign themselves to a single value ie that of the Close of the 15 minute bar since now each lower interval sees only a single value throughout that 15 minute time frame
As I mentioned before EFS offers a solution for plotting ie the getSeries() function.
So now plot the EFS that follows

function preMain(){
    setPriceStudy(true);
    setDefaultBarThickness(2,0);
    setDefaultBarFgColor(Color.red,0);
}
var x = null; //global variable
function main(){
    if (x==null) x = close(inv(15)); // assign Close series of 15 minute interval to global variable
    return getSeries(x); //return to the chart the series of the 15 minute Close
} 

With this EFS you will see that as the one minute bars develop the EFS also realigns in real time the prior plot on each 1 minute bar included within that 15 minute time frame
So, is this a bug? Absolutely NOT as has been explained multiple times in this forum by me and many others (including Steve, Garth, Chris, Jason and many more)
This is the intrinsic logic of EFS2.
Now I am well aware that you cannot use a series for some actions (for example drawing, coloring background etc.) and this is where you need to implement the suggestion that was given to you by Avery and that has been explained many times on this forum by myself and others
What you need to do is create your own routine that determines where on the 1 minute bars the higher 15 minute starts, then capture and store that (in whichever way you prefer) and then use that variable to loop back to on all the 1 minute bars to realign past values within that time frame (which you would do using the setBar() function) Once again this has been explained and demonstrated ad nauseam - by me included - in these forums
If - as it seems - you are unable to do that, then your other option is to do all your computations at the close of the higher interval which - based on the less than marginal sample code you posted - is NOT what you are doing.
You are using getBarState() but that is applied to the 1 minute interval not the 15 minute interval and so you are back to square one (ie the behavior I just explained above)
If I am wrong and that is not what you are doing, then post the entire script as any further discussion is everyone's waste of time
As an aside this whole thread should be moved to the Back Testing forum as you are seemingly not referring to Automated Trading functions.
Also, may I remind that these forums in general (and the EFS forums in particular) are fundamentally user-supported forums and eSignal intervenes only to verify whether a reported issue is a bug, which in this case it is NOT
Please understand that I do not intend to return on this topic so no point in addressing me or involving me further
Alex

The actual strategy is hundreds of lines that is used to trade actual accounts and I cannot legally post it to the public internet, nor would it make sense to do that.

We can take this offline if you like but the following snippet is not the actual strategy by any stretch but an example I put together for eSignal or anyone to show the code defect in the getValue() and gerSeries() functions.

I was shocked with the response I got from eSignal support when I reported the bug in another post that effectively was several paragraph of insults that were comical as it's clear that there is a blatant error in the values returned by these functions and whatever support manager wrote the response was clearly clueless, as I'm just taking the values returned by the functions and when plotted on a 1 minute chart for example the values based on a 15 minute chart should not be updating and drifting all over the for every one minute chart.

This drifting issue is an old know issue with eSignal indicators that they apparently gave up trying to correct and frankly it's time to find a product that is supported as eSignal is now a line item on NYSE/ICE's books and they are eliminating all remnants of support which does not bode well for the future of the product.

This snippet easily reproduces the problem load it up on a 1 minute chart, the EFS is looking at returned values based on the 15 minute chart in the code below and if you plot the returned values they are all over the map every 1 minute. Those values should not be updated but ever newbar on the 15 minute and they are updated ever 1 minute, a massive bug in those functions.

if (getBarState() === BARSTATE_NEWBAR){ // only execute remainder of EFS script once on "NEWBAR",
if (getBarState() === BARSTATE_NEWBAR && getCurrentBarIndex() === nRTBarIndex){ bRealtime = true; }

xint1ema = ema(20,inv(15));
nint1ema = xint1ema.getValue(0);

if (close(0, inv(15)) > nint1Sma ){

///// GoLong(); relevant code from function copied below, actual functions obviously has a lot more logic regarding real time trade processing but essentially this is it

if (nBarState == BARSTATE_NEWBAR && !bRealtime && !Strategy.isLong()) {
Strategy.doLong("Long Entry", Strategy.CLOSE, Strategy.THISBAR, nQty );
}
if (bRealtime && nBarIndex == nRTBarIndex && nBarState == BARSTATE_NEWBAR){
buyCallback();
}

If been in software development for decades and this bug should take someone a day to fix but they couldn't care less about paying customers. The original staff, Avery and Alexis care deeply about the product and customers they have not said so but I know their hands are basically tied in knots by the new short sighted l bean counters.

You have enough to reproduce the problem, getValue() and getSeries() work fine processing historical data, or when the chart and EFS interval is the same, when using multiple time intervals they return incorrect values and although touted, advertised and documented that eSignal supports multiple time intervals it's simply untrue and easily provable buy anyone who runes these 10 lines of code.

Look at their site regarding the Elite Advanced Get, "Mentoring Support" also a lie. They used to have personal mentoring years ago. I signed up for the elite package based upon that and told after paying, oh, we don't offer that anymore.

I have a work around but it involves GLOBALVALUES and is cumbersome to break a strategy up into separate pieces and can't be back tested accurately. So I'm trying to do the right thing by reporting the issues so eSignal can fix the issue for other users and the benefit of the product itself.

It's amazing that they don't get sued for false advertising as essentially they are stealing money from customers for bogus claims. Then when the bug is reported you get attacked!

The parent companies NYSE and ICE are regulated by the SEC, CFTC, the retail product the FTC, etc. I'm printing and documenting this post as being posted at this date and time and will be interesting to see if they take it down .

If they do writing a letter to the SEC and CFTC, and may do so anyway, about the issues and problems I am having, the response from eSignal and if they conspire to further deceive the public by removing unfavorable posts from the public forum they maintain by deleting a validly submitted perfectly legitimate post.

The SEC and CFTC can levy massive fines and do on a regular basis for this type of activity so I'd be amazed if they purposely remove the post. If their lawyers get involved they absolutely cannot take it down, if some technical person does, God help them if the lawyers get involved they will be gone in a flash. I worked in compliance for several Investment banks and know a little bit about this.

Good luck with you testing ping me via email if you want to take it offline.

[email protected]

[ACM]

ewdeg98
As I explained in my prior reply there is no bug.
With reference to your code sample see the explanation in my reply to Glen
With reference to your statement

However, we never use inv(), we always use open(), high(), low(), close() etc...

g_study = ema(20, close(sym("NQ #F,15")));

This has always worked for us (does not produce the drifting)

That is because I am assuming you are then returning g_study as a series and not a value
Try replacing in the return statement g_study with g_study.getValue(0) and see what happens.
By the way, sym() is conceptually the same as inv() with the only difference that you can also call a symbol.. There is a reason why it was done like that and I have explained it many a time already so search the forums if you are interested
Alex

You're right.

Using a 1 min chart with the following code

var g_study = null;

function main() {
if(g_init){
g_study = ema(20,inv(15));

g_init = false;
}

return g_study.getValue(0);
}

Produces a line that changes or "drifts" every 1 min.

However, we never use inv(), we always use open(), high(), low(), close() etc...

g_study = ema(20, close(sym("NQ #F,15")));

This has always worked for us (does not produce the drifting)

The bug could be isolated to inv() and not getValue() or getSeries()

[ewdeg98]

Alex,

You're right, we use

return getSeries(g_study);

which causes the entire current interval to move together. Thanks for your help!

[demarcog]

Alex,

Thank you for the response, I appreciate your help.

The other more troubling issue I would like to resolve is the highly inflated back testing results which I have documented and currently have an outstanding incident with support.

Apparently when back testing multiple time intervals this out of synchronization issue seems to manifest itself in a "look ahead" characteristic which seems to inflate the profits.

I did some work with Avery on this and he suggested using getSeries() which I did try and the back test results were the same as I recall using getValue() or getSeries().

I am just trying to back test strategies using multiple time intervals and cannot seem to figure out how to eliminate these overly reported profits documented in my posts.

I did send Avery the complete EFS strategy and will try any suggestion you have to ensure the back test results are aligned with the real time results.

Will changing getValue() to getSeries() on a multiple time interval back test potentially correct these inaccuracies?

Thank you again for the assistance I apologize if the tone was one of frustration as this is how I support my family and when a back test report which I rely upon shows thousands of dollars in profits which disappear when run real time is beyond problematic for me.

So please either let us know that the back test results when using multiple time intervals are 1) inaccurate and cannot be accurate or 2) how to correct these inaccuracies.using EFS.

glen