For real time trading is it preferable to use getSeries() versus getValue() ?

[demarcog]

I am having difficulty aligning back testing results that use STOP and LIMIT orders for entering and exiting trades with the real time results.

The discrepancy goes way beyond slippage and I have documented several times.

It was suggested earlier that there were advantages to using getSeries() to getValue().

I am trying to program a simple moving average that is utilized by several AGET strategies called a 6/4 Displaced moving average. It is a 6 period moving average displaced 4 bars ahead using both getSeries() and getValue() and expected to see the same values for both and am not.

Is anyone familiar with these two functions that can shed a little light?

Using getValue() my understanding was to use vMA6High.getValue(-4) and thought the equivalent was getSeries(vMA6High, 4)?


var vMA6High = null;
var bInit = false;
function premain(){
setComputeOnClose();

}
function main() {

if ( bInit == false ) {

vMA6High = sma(6, high()) ;

bInit = true;

}


return new Array( getSeries( vMA6High,4), vMA6High.getValue(-4) );

}


Thank you.

Glen

[LetUsLearn]

It doesn’t matter if you’re back-testing or trading in real-time, getSeries() and getValue() each do completely different things! You use getValue() to retrieve a single value, and you use getSeries() to retrieve a series object that gives you access to its value for any bar index on the chart…but ONLY if it’s properly defined as a series object! In recent times, I’ve given examples of how to create a series object from your own functions using efsInternal(), and you can basically use the same procedure to access the returns values of other programs that you have with efsExternal().

As for your example, getSeries(vMA6High, 4) is trying to retrieve the 5^th series object (0,1,2,3,4) in the return array of vMA6High...so if you used efsInternal() to create a series object from a function that returns 5 series objects, then your code would return the 5^th series object.

Did you think to put sma(6, high()) on a chart 2 times with the second one being offset forward by 4 bars so as to gain some insight into what you were trying to do with code? Do this and you’ll see that the current streaming bar index zero of the moving average that you displaced forward by 4 bars is equal to the -4 bar index of the moving average that you didn’t displace…after all, they’re the same moving average. So vMA6HighDISPLACED4.getValue(0) == vMA6High.getValue(-4)!!

So from main(), return [vMA6High.getValue(0), vMA6High.getValue(-4)];

Your NEXT step should be to put the moving averages onto a chart as I described above and try to understand what’s going on, then put your code into the chart and confirm that your code is matching up IDENTICLE to what eSignal’s moving averages are on the chart!

More important than any of the above, you NEED to go to eSignal’s glossary and find the functions that you’re having difficulty with and study over the definitions and the examples and work with them!! If you look at the getSeries() function you’ll see that the second parameter is nSeriesIndex (NOT bar index!!!), so it’s looking for an array index from a function that returned multiple values. If you look at the getValue() function, you’ll see that the second parameter is the nOffset (bar index).

Lastly, one thing that you mention in your other query (“variable as a series”), you are asking about BARSTATE_CURRENTBAR “which I've not seen before what is the purpose of that?”, you seem somewhat familiar with what the other two bar states do, maybe you should look up the getBarState() function in eSignal’s glossary and see what this one does!!!!!

You can point them towards the oasis, but no matter how parched a thirst is you can’t make them drink.

[demarcog]

LetUsLearn,

Thanks for the response. You have a great what of explaining things. Once again when I read the doc it was not clear and found your explanation very helpful. The glossary was a great tip also. Not sure why and others seem to have a similar issue but when I do searches in the Knowledge Base on keywords that abound it frequently comes back with no searches found.

The issue I had was not as it tuns out related to getSeries() vs getValue(). I was told by eSignal tech support on a indicator drifting issue I was having in real time to use getSeries() not getValue() and it ended up making no difference in that case.

I am trying to reconcile the difference between back testing results and real time results. As in Real time my strategy is triggering trades that do not show up in the back tester. I believe it is a logic issue which I've been trying to diagnose for the longest time and at my wits end. It may be related to using close(0) in determining trade entry when a strategy EFS gets control on each tick. close(0) after a completed bar is the closing price of the bar, whereas close(0) intra real time bar is the last tick so it may be meeting my trade entry criteria intra bar that is different from the conditions for entry on the close of a completed bar. What I don't understand is if I use (-1) on all indicators for entry they back tested results are much worse then barindex (0). By using Strategy.CLOSE, and Strategy.THISBAR and bar index 0 should be equivalent to Strategy.NEXTBAR (which is really the open of the next bar) using barindex -1.

Thanks again it it very much appreciated.

[email protected]

[LetUsLearn]

Welcome to my nightmare! What you’re talking about is the exact problem that I have with one of my systems where I use the closing price to trigger trades, and in back-test fairytale land where you only take the trade if the actual bar’s closing price triggers it, the program kicks A$$, but in the real world the closing price is the price that’s currently streaming and it triggers enough bad trades so as to seriously affect the profitability of the system. If I use the prior close to trigger the trades, then the fills are so adversely affected that it’s better to let the system take the bad trades and to suffer with that or to babysit the damn thing and manually deal with it. I’ve tried to program around it, like if the bar’s actual close wouldn’t have actually trigger a trade then to immediately close that trade, but a lot of times it’s going to happen anyhow and then you have an even worse fill…I’ve concluded that that system has no easy fix…so you work on a new mousetrap.

As for what you said in your last sentence, there may not be a big difference in back-test land between the two strategies, but in the real world with streaming data there is a big difference. Use my TradingLibrary to watch how your programs perform in real time, you don’t need to use real money to do that. Compare the back-test results to the streaming results and look for the extra trades that happen in real-time when you’re using a zero bar index.

Personally, I would never waste my time doing a search on eSignal’s pathetic website! Just go to the glossary and look up the function definitions, they’re a bit weak on detail but they give you the sad minimalist info that eSignal has to offer. For a company their size, I think that their (lack of) KnowledgeBase website is an insult to their customers…it’s rather pitiful that they don’t make the glossary available as a pdf that we can just download to our computers instead of having to navigate through some high school kid’s first website!

[demarcog]

LetusLearn,

I could not agree more and brilliantly stated. My searches frequently come up "not found" for items that I know are in there somewhere. The parent company ICE is the primer $6B+ exchange/clearing house on the planet. With ICE purchasing IDC/eSignal five years ago, one would have hoped that the resources required from the pool of 5,000 to bring the product up to the level of their many other products. Look at any other ICE offering they the best in class across the board.

I still think the product is the best there is and heavily invested in it's use and continued success. It is not my intention to criticize the product but concerned that if we don't speak up things will not improve and deteriorate further. I want this product to flourish successfully for another 20++ years. My fear is the level of customer satisfaction is such that the future of the product does not look too promising at this point. With the best market data in the business and their exchange presence, eSignal can be the shrink wrapped trading engine for large institutions, rather them employing armies of professional developers to do their automated trading.

I appreciate the suggestion on using your Trade Library and also you generously making that available. I will look into that, it requires some coding on my part and lately I've opted to use the eSignal paper trading Demo accounts. It's very easy to switch over to IB from that point and I've found that the fills are very close to the IB fills and in may cases better.

An what a night mare it is. The whole point of auto trading is not to have to baby sit the strategies for several reasons, one it defeats the whole purpose and introduces the fatal emotional component where it becomes a constant mental struggle not to override the system Even when you are strong enough and I frequently am not it becomes a source of mental tension.

How do we mitigate this nasty firing of BS trades? One serious aspect is a trade will fire and because the close(0) on the bar completion level did not occur the logic to invoke the strategy stop order and monitor breaching of the stop is not executed. One possible damage control solution Is using the OnExecutioncallback send send out a hard stop order calculated on the actual fill price rather then a strategy calculated stop. I'm sure you don't need it but I have a simple routine that does that, and also sends out a limit order in the unlikely event the orphan trade is actually profitable. For some reason error trades are 95% losing, should be 50/50 but call it bad luck, the Heisenberg Uncertainty Principle or the Law of Attraction (fear begets bad stuff happening) but everyone I know gets killed on errors, never makes money.

I attached a screen shot of a strategy that behaved flawlessly during US Prime Time trading. The screen shot shows the painting of the bar green when long with the associated buy and sell orde. When the position is closed the green background is turned off

One idea is that given these bad trades typically occur during "off" hours perhaps the narrow range can be a filter. These days the European and Asian trading sessions can be the best trades of the day so I need to be running 24/7. The days of 9:30 to 4:00 trading are gone forever on Stock Indices and futures in general.The times between the busiest US/EUR/Asia hours when the range is narrowest are the strategy killers when they are typically but not always quiet range markets.

Thankfully my strategies are relatively simple as that seems to produce the best results for me bit I did find this strategy in the auto trading forum section (see attached) the other night that is well beyond my and perhaps human understanding and incredibly complex. I actually loaded it up and ran a back test which weren't successful the markets I'm interested in trading. I've no idea for what market(s) it was intended. Let me know if you can make heads or tails of it and if you have any luck.

Thanks again I really appreciate the response and all the help you have provided to me and many others on the forum.

glen