setComputeOnClose and Back Testing

[Lancer]

If using setComputeOnclose(), would it still be correct to use CLOSE/THISBAR? (vs. MARKET/NEXTBAR)

[eSignal_JasonK]

Hello Lancer,

I don't recommend using setComputeOnClose() with back testing formulas. That function was created to force an EFS to only execute once per bar when processing real time data. When we back test, the EFS only executes once per bar regardless so setComputeOnClose() will only make the logic a more confusing.

[Lancer]

Got that, but setComputeOnClose() is useful to display a backtest formula's behavior on a chart. That being the case, would it still be correct to use CLOSE/THISBAR? (vs. MARKET/NEXTBAR)

[eSignal_JasonK]

Hello Lancer,

but setComputeOnClose() is useful to display a backtest formula's behavior on a chart

Can you elaborate on this? I'm not sure I understand how this is providing a benefit for you.

[Lancer]

The Strategy Analyzer computes on bar close. The use of setComputeOnClose() is intended to make entries/targets/stops for the same formula on a chart equivalent to what is accomplished in the Strategy Analyzer. When developing/improving strategies, its beneficial to view events and relationships on a chart don't you think?

[eSignal_JasonK]

Hello Lancer,

When back testing, the Strategy Analyzer only processes completed bars, which is essentially the same thing as processing on the close of the bar. The only thing setComputeOnClose() is going to do is shift the bar index by -1 in real time, which may require you to change your code logic a bit.

Viewing events and relationships on a chart is beneficial, I agree. Are you referring to drawing text and shapes on the chart to highlight entry and exit trades? This can be done with or without setComputeOnClose(). I still don't understand how setComputeOnClose() is beneficial to you in back testing. Perhaps you could post a formula you're working with and some chart images.

[Lancer]

setComputeOnClose() isn't of any use when running a backtest. Its for charting results to equal backtest results. What I am trying to get to the bottom of, is the correct use of strategy code combinations (MARKET/CLOSE/LIMIT with THISBAR/NEXTBAR) and bar# reference (-1,0,1) when using setComputeOnClose() in a backtestABLE formula. The question is not formula-specific, but standard practice. The objective is for charted results to equal backtest results.

Now I see from your comment that if setComputeOnClose() is not remarked out or made null when running a backtest, then the bar count will change. That's something new. From that comment I see the need to install a function parameter for setComputeOnClose On/Off switching in Edit Studies; On when charting, and Off when backtesting.

See why there is confustion? Some better documentation on this would help. Pending that, can you clearly lay out the rules?

[eSignal_JasonK]

Hello Lancer,

I think I understand what the problem here is. I should have thought of this earlier. Correct me if I'm wrong, but I think what you're trying to do is use one formula for back testing and real time processing.

There's no rule against doing that, but I don't recommend it because the problem you run into is that the code logic for back testing can be different from real time processing. I believe this is the heart of the issue we're discussing here. Also, the strategy functions are not useful in real time processing and just add inefficiency to your formula. Also, if the logic of your formula uses NEXTBAR and checks Strategy.isLong(), .isShort() or .isInTrade() to make decisions in your code, it may not work at all in real time mode since the "next bar" is in the future. This could cause these strategy functions to return false in real time where they would return true in back testing. The strategy functions simply pass data to the analyzer so it can generate its report, which is only done on the historical bars. I always recommend keeping back testing and real time formulas separate. I've found that it's much quicker than trying to write one set of code logic that is compatible for both back testing and real time mode. Back Testing is never going to be able to give you the same results as real time trading anyway because we don't have the ability to look at the intra-bar trades on the historical bars to make decisions based on the time stamps of those trades, which is what would have to be exposed to make that a possibility. Therefore, back testing should only be used to test the general idea of a strategy to get a quick result for testing its validity. Once you find that there is something of value you should then write a new formula based on the same rules that may be further tuned for handling real time decisions. This new formula should not include any Strategy object function calls. To go one step further, use this real time version with the paper broker for a while to see how it does in real time.

I see why you are trying to use setComputeOnClose() in an attempt to force code logic to work the same way for back testing and real time processing. As I see things, it could make it a little easier to do both in a single formula with setComputeOnClose, but it's still going to make your project much more complicated. You certainly would not be able to use any NEXTBAR combinations for entry or exit trades. I suggest that you focus on using the two sets of logic in separate formulas.

For the back testing formula, setComputeOnClose() will not change the outcome of the results, so just leave it out. Here's what you need to know to record the entry and exit prices based on the combinations of THISBAR/NEXTBAR with CLOSE/MARKET/LIMIT/STOP.

Strategy.THISBAR with:
Strategy.CLOSE = close(0)
Strategy.LIMIT = Your specified value passed to the strategy function on the current bar.
Strategy.STOP = Your specified value passed to the strategy function on the current bar.
Strategy.MARKET = open(0)

It's not recommended to use Strategy.THISBAR with Strategy.MARKET unless the conditions you're testing use the open of the current bar for your entry or exit rules.

Strategy.NEXTBAR with:
Strategy.CLOSE = close(1)
Strategy.LIMIT = Your specified value passed to the strategy function on the following bar.
Strategy.STOP = Your specified value passed to the strategy function on the following bar.
Strategy.MARKET = open(1)

When drawing objects on the chart to highlight the trades, use 0 for the x-coordinate when using THISBAR and 1 when using NEXTBAR. The y-coordinate would be the recorded value as described above.

[Lancer]

Re. the use of one formula for backtesting and real time processing; That's true, but only for checking/testing formula actions in the case of formulas having no intrabar triggers.

This is my original question:
"If using setComputeOnclose(), would it still be correct to use CLOSE/THISBAR? (vs. MARKET/NEXTBAR)"

That is in reference to this post:

http://forum.esignalcentral.com/showthread.php?s=&postid=60731#post60731

which states:
"Another alternative would be to change the entry to CLOSE/THISBAR."

Unfortunately EFS knowledgebase strategy documentation is silent on the question (and a lot of other things), so the question arises because of the direct conflict between recommendations in various forum posts, including yours below;

"if the logic of your formula uses NEXTBAR and checks Strategy.isLong(), .isShort() or .isInTrade() to make decisions in your code, it may not work at all in real time mode since the "next bar" is in the future. This could cause these strategy functions to return false in real time where they would return true in back testing......You certainly would not be able to use any NEXTBAR combinations for entry or exit trades. "

and this one, which also seems authoritative:

http://forum.esignalcentral.com/showthread.php?s=&postid=47434#post47434

which states:
"... the use of Strategy functions is critical to the outcome of your strategy's backtest... If you are using setComputeOnClose(true), then you should be using Strategy.MARKET, Strategy.NEXTBAR. Because the setComputeOnClose() function causes the EFS to run at the END of any current bar, you have to use NEXTBAR for entries."

So which is it... NEXTBAR or THISBAR when using setComputeOnClose?

Disregard any concern for intrabar triggers. The purpose of using setComputeOnClose is so there are no intrabar triggers. One might also run a 1-tick chart. In either case, there are no intrabar events, so backtest events would be the same as live, $Playback, or historical bars, right?

Then there is this new item from below: "...If setComputeOnClose() is not remarked out or made null when running a backtest, then the bar count will change. That's something new. From that comment I see the need to install a function parameter for setComputeOnClose On/Off switching in Edit Studies; On when charting, and Off when backtesting." What's the story with this? Do I need to install that function parameter and change setComputeOnClose to Off when backtesting?

[eSignal_JasonK]

Hello Lancer,

"If using setComputeOnclose(), would it still be correct to use CLOSE/THISBAR? (vs. MARKET/NEXTBAR)"

Yes. You could do either depending on the specific logic of your formula. You should avoid MARKET/THISBAR unless your condition is looking at the open of the current bar.

Unfortunately EFS knowledgebase strategy documentation is silent on the question (and a lot of other things), so the question arises because of the direct conflict between recommendations in various forum posts, including yours below;

"if the logic of your formula uses NEXTBAR and checks Strategy.isLong(), .isShort() or .isInTrade() to make decisions in your code, it may not work at all in real time mode since the "next bar" is in the future. This could cause these strategy functions to return false in real time where they would return true in back testing......You certainly would not be able to use any NEXTBAR combinations for entry or exit trades. "

and this one, which also seems authoritative:

http://forum.esignalcentral.com/sho...47434#post47434

which states:
"... the use of Strategy functions is critical to the outcome of your strategy's backtest... If you are using setComputeOnClose(true), then you should be using Strategy.MARKET, Strategy.NEXTBAR. Because the setComputeOnClose() function causes the EFS to run at the END of any current bar, you have to use NEXTBAR for entries."

So which is it... NEXTBAR or THISBAR when using setComputeOnClose?

Many times, the advice given is specific to the context of the logic in a particular formula. It's very difficult to give general advice that covers all possible combinations of code logic. For the most part you could use CLOSE/THISBAR. What you have to think about is that in real time, do traders have the ability to get the exact closing price of a bar for their entry price? No, because we don't know what the last trade will be until the first trade of the next bar has occurred or the amount of time for the interval has passed. In back testing I see most people use MARKET/NEXTBAR because that will give you a more realistic result. If your formula logic is looking at the close of the bar to trigger an entry then using MARKET/NEXTBAR will produce more realistic results for the back test. Imagine if you used MARKET/THISBAR, which would give you an entry price at the open of the bar. If you were looking at the close to trigger a long entry and it was .50 above the open you would be falsely adding .50 profit to the trade. If on the other hand you were using the open of the bar to trigger the long entry, then MARKET/THISBAR might be ok. The answer to your question in a general sense is that it completely depends on the formula logic in question.

Then there is this new item from below: "...If setComputeOnClose() is not remarked out or made null when running a backtest, then the bar count will change. That's something new. From that comment I see the need to install a function parameter for setComputeOnClose On/Off switching in Edit Studies; On when charting, and Off when backtesting." What's the story with this? Do I need to install that function parameter and change setComputeOnClose to Off when backtesting?

No, setComputeOnClose() will not change the results while back testing whether it's used or not. It only takes affect to a formula once it's processing real time data. setComputeOnClose() is only creating some confusion for you. Just leave it out of your back testing formulas.

[Lancer]

Jason, thanks for the info.

setComputeOnClose() is only creating some confusion for you. Just leave it out of your back testing formulas.

What's creating confusion is the conflicting recommendations and lack of documentation. Instead of disregarding some function for lack of understanding, I'd rather have some reference material explaining appropriate usage.

[ebr]

Lancer - if I may jump in and make a few suggestions here (if not, disregard ). I do a lot of EFS development of formulas that work in both real time and backtesting alike. Here are some of the things I do to be sure they both exhibit the same behavior/results:

1) use getCurrentBarIndex() (actually, I grab this at the beginning of the efs and store in a variable) to determine whether you are in a backtest or real time - a bar index of 0 means you are on the last bar on the chart and, therefore, are probably in real time (or the very last iteration of a backtest - if distinguishing between the two is important, check that the last two current indices were 0). Prefacing your logic with this test allows you to only call the strategy functions in backtest and do different things in real time.

2) use getBarState() and test for BARSTATE_NEWBAR to do things in real time the same way you would if you had setComputeOnClose(true).

3) always use THISBAR and LMT with a specific entry price that is a tic inside of your signal price. This will guarantee a realistic entry in all but the absolute fastest of market conditions (assuming a liquid market).

4) always test the return value of your Strategy.doLong() and Strategy.doShort() calls. A false return means that the price you attempted was not fillable on the bar you attempted it.

Perhaps those things will help by allowing you to code your formulas for dual purpose and not have to deal with the idiosyncracies of setComputeOnClose(true). I find this extra logic in the efs is preferable to trying to maintain separate formulas (and potentially introduce different errors in each of them).

Some of the documentation on this stuff is somewhat sparse I agree, but I have found that to be made up by the help of folks like Jason and others in these forums.

Good luck.

[Lancer]

By all means, jump in. Excellent advice; I have copied it to my EFS manual (constructed from bits and pieces found in these forums). Thank you.