Question on getbarstate() for realtime strategy.

[demarcog]

The general technique for realtime strategies not when not specifying setComputeOnClose() is to in main:

if (gerbarstate()==BARSTATE_NEWBAR && getcurrentBarIndex ==0){ 
....then we are running realtime and perform tests for entry 

} 

If I am using a basic Stop and Reverse strategy that I wish to evaluate on every trade/tick would simply removing the test for getbarstate()==BARSTATE_NEWBAR allow my strategy to get executed for each trade?

If I'm getting control on each trade, would the calls to close(0), open(0), high(0), low(0) all return the same value, as for a given trade these values would be the same?

Can I specify setComputeOnClose() and still evalaute if a given price was traded intrabar?

The reason I ask is the more I get into converting a strategy object based strategy to realtime processing strategy the more I realize that for the most part IMHO, waiting for a NEWBAR may not be desirable. For example, if our stop price is hit, would anyone really what another 5, 15 or longer minutes to see where the bar closes prior to getting out. Most traders would probably not do that.

When I'm "discretionary" trading and I think this is generally true, for the most part, things like stops, profit targets, etc. most decisions about entry and exit are not delayed until a bar is completed but occur intrabar. This may or may not be the "wisest"
methodology but mimics more closely how most people trade.

I'm trying to modify my strategies to more accurately reflect this and it appears that the emphasis is geared toward the raising of this NEWBAR condition.

I would appreciate any suggestions, recomendations or comments from those who have perhaps been down this road.

Thanks

[AssetHound]

Re: Question on getbarstate() for realtime strategy.

if(getBarState()==BARSTATE_CURRENTBAR && . . .

If you are not using setComputeOnClose(), this should allow code within if statement to execute for each new tick as the current bar is building.
-----------------

[QUOTE]Originally posted by demarcog
[B]The general technique for realtime strategies not when not specifying setComputeOnClose() is to in main:

[php]
if (gerbarstate()==BARSTATE_NEWBAR && getcurrentBarIndex ==0){
....then we are running realtime and perform tests for entry

}

[eSignal_JasonK]

Re: Question on getbarstate() for realtime strategy.

Hello demarcog,

Originally posted by demarcog
The general technique for realtime strategies not when not specifying setComputeOnClose() is to in main:

if (gerbarstate()==BARSTATE_NEWBAR && getcurrentBarIndex ==0){ 
....then we are running realtime and perform tests for entry 

} 

If I am using a basic Stop and Reverse strategy that I wish to evaluate on every trade/tick would simply removing the test for getbarstate()==BARSTATE_NEWBAR allow my strategy to get executed for each trade?

Yes, as long as setComputeOnClose() is not being used.

If I'm getting control on each trade, would the calls to close(0), open(0), high(0), low(0) all return the same value, as for a given trade these values would be the same?

Only at the open of the new bar will these four prices be the same. As more trades occur at different prices they will not be the same. They would only remain the same if all the trades occurred at the exact same price during the interval.

Can I specify setComputeOnClose() and still evalaute if a given price was traded intrabar?

No. By definition, setComputeOnClose() prevents the formula from processing intrabar. It forces a formula to only process bars when they close.

The reason I ask is the more I get into converting a strategy object based strategy to realtime processing strategy the more I realize that for the most part IMHO, waiting for a NEWBAR may not be desirable. For example, if our stop price is hit, would anyone really what another 5, 15 or longer minutes to see where the bar closes prior to getting out. Most traders would probably not do that.

When I'm "discretionary" trading and I think this is generally true, for the most part, things like stops, profit targets, etc. most decisions about entry and exit are not delayed until a bar is completed but occur intrabar. This may or may not be the "wisest"
methodology but mimics more closely how most people trade.

I'm trying to modify my strategies to more accurately reflect this and it appears that the emphasis is geared toward the raising of this NEWBAR condition.

I would appreciate any suggestions, recomendations or comments from those who have perhaps been down this road.

Thanks

For the exit strategy, yes, you would want to exit as soon as the stop price (or profit target) occurs intrabar. When this event occurs set a global flag so that any subsequent trades that would also trigger this exit signal will not be executed again on the same bar. Then at NEWBAR of the following bar reset the flag back to false to allow the condition to evaluate again after another position is taken. You can still look for new entry signals at NEWBAR to get confirmed entry signals.

Those back test examples in the back testing tutorials simulate this type of logic. Entries are taken at NEWBAR but the stops and profit targets are recorded at a price level that assumes would have occurred intrabar. Remember the code logic that checks the open of the bar first to see if that was the trade that breached the stop or profit target level? If the open did not trigger the exit then the code looks at the high or low of the bar and if that price breached the stop or target, the strategy recorded the exit trade at the stop or target price. The back test formulas are not processing each intrabar trade but are making logical assumptions as to what occurred intrabar based on the relationship between the OHL prices of the completed bar and where they are in relation to the stop or target price.

[demarcog]

Re: Re: Question on getbarstate() for realtime strategy.

...

Originally posted by JasonK
Hello demarcog,



Yes, as long as setComputeOnClose() is not being used.



Only at the open of the new bar will these four prices be the same. As more trades occur at different prices they will not be the same. They would only remain the same if all the trades occurred at the exact same price during the interval.

OK...so if executing within a block of code controlled by NEWBAR, the bar is complete and barindex(0) refers to that completed bar.

If on the other hand I receive control for each trade, outside of a NEWBAR controlled loop, (CURRENTBAR...or simply falling through) then barindex(0) will return the values for the currently bar being build.

I was mistakenly picturing each trade in that case updating the barindex somewhat like a 1 tick chart might. Thanks for clearing that up.

No. By definition, setComputeOnClose() prevents the formula from processing intrabar. It forces a formula to only process bars when they close.

So for the most part setComputeOnClose accomplishes the same function as checking for NEWBAR, one difference being currentBarIndex of 0 is never returned when setComputeOnClose is specified.

I know you have explained this before, I apologize it seems to take awhile for me to internalize it sufficiently

For the exit strategy, yes, you would want to exit as soon as the stop price (or profit target) occurs intrabar. When this event occurs set a global flag so that any subsequent trades that would also trigger this exit signal will not be executed again on the same bar. Then at NEWBAR of the following bar reset the flag back to false to allow the condition to evaluate again after another position is taken. You can still look for new entry signals at NEWBAR to get confirmed entry signals.

Those back test examples in the back testing tutorials simulate this type of logic. Entries are taken at NEWBAR but the stops and profit targets are recorded at a price level that assumes would have occurred intrabar. Remember the code logic that checks the open of the bar first to see if that was the trade that breached the stop or profit target level? If the open did not trigger the exit then the code looks at the high or low of the bar and if that price breached the stop or target, the strategy recorded the exit trade at the stop or target price. The back test formulas are not processing each intrabar trade but are making logical assumptions as to what occurred intrabar based on the relationship between the OHL prices of the completed bar and where they are in relation to the stop or target price.

Thanks for clearing this up for me.

I've become thoroughly familiar with those tremendously helpful examples, and cannot thank you enough for them. I've been trying to modify them for realtime/generic broker processing but my EFS needs to get up to speed first.

One question I had was does the order of checking for stop or target breach matter?

The reason I ask is once the bar is complete, is there a way to tell (if the range of the bar is large enough to breach both the stop and target level) what occured first?

If I test for the stop first then the trade will show up as a loss rather then a profit which I guess is a more conservative way to code this?

More importantly however when running realtime if I'm interested in getting out as soon as the price is hit realtime what changes would I need to make to accomplish this?

Jason, as always thank you so much for all the help you, Alex SteveH, Brad, etc. and others provide.

I am well aware and appreciative of the fact that it is well above and beyond what we are entitled to, and certainly infinately more then we would receive with ANY other vendor.

I apoligize for all my posts and dumb questions, it's not my intent to monopolize your time and I hesistate to post until I hit a wall which is all too frequently.

[ACM]

demarcog
You should now be able to access the post to edit it.
Alex

[demarcog]

Originally posted by Alexis C. Montenegro
demarcog
You should now be able to access the post to edit it.
Alex

Thank you Alex.

[eSignal_JasonK]

Re: Re: Re: Question on getbarstate() for realtime strategy.

Hello demarcog,

Originally posted by demarcog
...


OK...so if executing within a block of code controlled by NEWBAR, the bar is complete and barindex(0) refers to that completed bar.

If on the other hand I receive control for each trade, outside of a NEWBAR controlled loop, (CURRENTBAR...or simply falling through) then barindex(0) will return the values for the currently bar being build.

I was mistakenly picturing each trade in that case updating the barindex somewhat like a 1 tick chart might. Thanks for clearing that up.

In real time, bar index of 0 always refers to the current bar. At NEWBAR you are at the first trade for bar 0. The bar that just closed will always be the previous bar, or bar -1.

So for the most part setComputeOnClose accomplishes the same function as checking for NEWBAR, one difference being currentBarIndex of 0 is never returned when setComputeOnClose is specified.

I know you have explained this before, I apologize it seems to take awhile for me to internalize it sufficiently

Essentially yes. With setComputeOnClose() the formula will process a newly closed bar only one time the moment it becomes bar -1, which is the same instance at BARSTATE_NEWBAR.

No need to apologize. We'll continue to cover these concepts as many times as needed. Other members may benefit from these threads as well so it's all good.

Thanks for clearing this up for me.

I've become thoroughly familiar with those tremendously helpful examples, and cannot thank you enough for them. I've been trying to modify them for realtime/generic broker processing but my EFS needs to get up to speed first.

One question I had was does the order of checking for stop or target breach matter?

The reason I ask is once the bar is complete, is there a way to tell (if the range of the bar is large enough to breach both the stop and target level) what occured first?

If I test for the stop first then the trade will show up as a loss rather then a profit which I guess is a more conservative way to code this?

If you're talking about real time analysis on a trade-by-trade basis, then you should be evaluating for a stop or profit target on each trade. If you do this, it will not be possible for the same trade to execute both conditions. Assuming your conditions are properly coded. In this case the order in which you check for a profit target or stop will not matter.

If you're talking about back testing and the range encapsulates both your stop and profit target, that would indicate to me that these values may be too tight for the chart interval that is being used. Regardless, for back testing the most conservative thing to do would be to test for the stop first and profit target second. There's no way to know in back testing, which would have occurred first so you have to make some assumptions in the back testing formulas.

More importantly however when running realtime if I'm interested in getting out as soon as the price is hit realtime what changes would I need to make to accomplish this?

Don't use setComputeOnClose() for one. Evaluate for the stop and profit exit signal on each trade and allow the position to be closed when these conditions occur. Your conditions should first check to see if there is an active position before allowing a closing trade to be executed. When an exit trade occurs set a global flag to true and use this flag in your initial exit conditions. At NEWBAR, reset the flag back to false if there isn't a position.

Jason, as always thank you so much for all the help you, Alex SteveH, Brad, etc. and others provide.

I am well aware and appreciative of the fact that it is well above and beyond what we are entitled to, and certainly infinately more then we would receive with ANY other vendor.

I apoligize for all my posts and dumb questions, it's not my intent to monopolize your time and I hesistate to post until I hit a wall which is all too frequently.

Thank you for your kind words. All your posts and questions are welcomed and beneficial to this community.

[demarcog]

Re: Re: Re: Re: Question on getbarstate() for realtime strategy.

Originally posted by JasonK
Hello demarcog,



In real time, bar index of 0 always refers to the current bar. At NEWBAR you are at the first trade for bar 0. The bar that just closed will always be the previous bar, or bar -1.

The best way for me to understand this was to load up BarStates.efs and BarIndexes.efs into the same chart and visually see what you are describing....it's actually pretty cool..

If you're talking about back testing and the range encapsulates both your stop and profit target, that would indicate to me that these values may be too tight for the chart interval that is being used.

You make a good point. I've tested some very short term systems maybe based on a osillator type crossover or acceleration on a 1 min chart of the ES looking for 4 or 5 ticks risking 1 or 2 which is a very narror range and perhaps best tested using tick replay.





Thank you for your kind words. All your posts and questions are welcomed and beneficial to this community. [/QUOTE]

Thanks for the help, kindness and encouragement.