getCurrentBarIndex() and getBarState() question.

[demarcog]

When running a strategy realtime using a Paper Trader broker or Live broker I'm uncertain as to the correct test to implement.

During the backtest of a candlestick chart:

 getBarState() == BARSTATE_NEWBAR 

was used to determine when a new bar was created.

For Renko backtesting the new bar test was a bit different:

getRawtime(0) != getRawtime(1), 

then in realtime for renko:

 getBarState() == BARSTATE_NEWBAR 

should replace the rawtime test.

Running realtime using the Generic Broker Functions, should I still check for getBarState == BARSTATE_NEWBAR or does the getCurrentBarIndex == 0, replace the getBarState() == BARSTATE_NEWBAR test for both bar charts and Renko charts?


What is the relationship between the values returned by getCurrentBarIndex() and setComputeOnClose, if any?


Thanks very much.

[eSignal_JasonK]

Re: getCurrentBarIndex() and getBarState() question.

Hello demarcog,

Originally posted by demarcog
When running a strategy realtime using a Paper Trader broker or Live broker I'm uncertain as to the correct test to implement.

During the backtest of a candlestick chart:

 getBarState() == BARSTATE_NEWBAR 

was used to determine when a new bar was created.

Correct.

For Renko backtesting the new bar test was a bit different:

getRawtime(0) != getRawtime(1), 

Correct.

then in realtime for renko:

 getBarState() == BARSTATE_NEWBAR 

should replace the rawtime test.

Correct, because rawtime(1) will return null in real time. The bar index of 1 is the next bar in the future, which does not exist in real time. We can used rawtime(1) in back testing because the data exists in the chart. Just be sure not to use bar 1 price data to base any trading signals on while back testing.

Running realtime using the Generic Broker Functions, should I still check for getBarState == BARSTATE_NEWBAR or does the getCurrentBarIndex == 0, replace the getBarState() == BARSTATE_NEWBAR test for both bar charts and Renko charts?

You need to use getBarState() to detect when the new bar(s) occur. getCurrentBarIndex() just returns the bar index that the formula is processing. In real time it will always return 0 regardless if the bar state is _NEWBAR or _CURRENTBAR.

What is the relationship between the values returned by getCurrentBarIndex() and setComputeOnClose, if any?


Thanks very much.

getCurrentBarIndex() will return the same bar index values on historical bars regardless of the use of setComputeOnClose(). In real time, setComputeOnClose() forces a formula to only process completed bars. Bar 0 will never be processed in this case, so getCurrentBarIndex() will never return 0. When a bar closes (same instance as _NEWBAR), the formula is processed once on bar -1, which is the bar that just closed. Any plotted series will update on bar -1 and then the formula waits until the current bar closes before the EFS is executed again.

[demarcog]

Jason,

NOW I understand, thanks for clearing up the confusion. The documentation you provided and in particular the programs BarStates.efs and BarIndexes.efs were very helpful.

I must confess I was a little preplexed about your statement that for SetComputeOnClose() in realtime will prevent getCurrentBarIndex from ever returning 0.

Becasue when I changed the BarIndexes.efs specifying SetComputeOnClose() I still saw a box with bar 0 drawn on top of the last bar, however it was misplaced on the screen indicating a definite difference between SetComputeOnCLose() and not specifying SetComputeOnCLose(). Having the cursor window display barindex 0 in either case was a bit confusing also..

When I changed the origional:

if (nState == BARSTATE_NEWBAR ) {
        for (var i = 0; i > -6; --i) {
            drawTextAbsolute(i, high(i), " "+i+" ", Color.blue, null,
                Text.BOLD|Text.BOTTOM|Text.FRAME|Text.CENTER, null, 14, i);
        }
    } 

to test for bar index 0 before drawing the box on the screen it no longer did.

if (nState == BARSTATE_NEWBAR && nIndex == 0) {
        for (var i = 0; i > -6; --i) {
            drawTextAbsolute(i, high(i), " "+i+" ", Color.blue, null,
                Text.BOLD|Text.BOTTOM|Text.FRAME|Text.CENTER, null, 14, i);
        }
    } 

Now I need to rethink the best way for implemeting this in a SAR strategy, testing whether to wait for a bar completion and executing a market order, or allowing limit orders once the SAR point is penetrated and how the barstate, bar indexes relate to this.

Thanks again for your help.

[eSignal_JasonK]

Hello demarcog,

You're most welcome.

The BarIndexes.efs was not coded for use with setComputeOnClose(). The text label with the 0 that you saw was not a value being returned by the getCurrentBarIndex() function. It was part of a for loop that starts on line 21. The for loop starts at a hard coded value of 0, which assumes setComputeOnClose() is not being used. Depending on the specific logic of a formula, you may not always be able to simply add setComputOnClose() to preMain(), as is the case for BarIndexes.efs. You need to be conscious of this when adding setComputeOnClose() to formulas not originally written for compute on close only logic.

The modification you made to the condition surrounding that for loop prevented the for loop from executing at all with setComputOnClose().

To make it compatible for use with setComputeOnClose() you just need to change the for loop from for (var i = 0 ... to for (var i = -1 .... .

[demarcog]

Is there anyway to back or forward test a strategy based on a Renko Chart

When I load a formula that paints the price bars when in a position and also plots a value I'm seeing very different results when the study is run in Tick Replay.

I have some strategies based on Renko charts that I'm trying to "forward test" using the Generic Broker Functions and Esignals Paper Broker prior to going live.

Alexis responded to an earlier "drift" problem and mentioned that the drifting would not effect the results of a backtest which I understand.

When I run the backtester, the prices reported by the strategy analyzer are not surprisingly highly inaccurate as the actual price can be and quite frequently is well away from the most current Renko brick especially for some fast moving symbols.

When I run it realtime I run into the "drift"problem where I rely on the indicator values being "drifted" or plotted incorrectly.

When I tried using tick replay I get drastically different results then when the strategy formula is simply loaded into the chart


I've worked on this for days now, my brain is fried, and I read every Renko post going back to 2002 and at a total loss for how to proceed and would appreciate any assistance.

[demarcog]

Jason,

I didn't mean to imply in anyway the barindex.efs had some programming error and that I was "correcting" it at all. I apologize if I gave you that mistaken impression.

My point was simply to experiment with the code so I could actually "see" the difference between setcomputonclose behavior and not specifying it....and just relating the experimenting I did that's all, and I appreciate the additional feedback.


I also noticed in a earler post that for realtime live broker trading that you suggest doing a test for:

if ( getCurrentBarIndex ==0 ) bRealtime = true;

I have a modified parabolic SAR strategy that uses setComputeOnClose() and when I put the "bRealtime" test in when converting to realtime it obviously didn't trade, so I left the bRealtime test intact and commented out setComputeOnClose?

For setComputeOnClose() is BARSTATE_NEWBAR a sufficient test for "realtimeness"?

How would removing SetComputeOnCLose() effect a SAR type strategy?

The only thing I noticed is that there is a test for barindex (-1) to draw a righthanded arrow indicating the next SAR point on the most current bar which I don't think displays when setcomputeonclose is commented out.

Do you have any suggestions for SAR type strategies, waiting for the bar to close above/below the SAR point or using stop orders to reverse midbar on a 1 tick penetration, etc? Alexis had a very slick btbasicparabolic that I think waited for the whole bar to be above or below the SAR point?

It's also a little tricky when running realtime because when the strategy is realoaded using the generic broker functions, a new order gets sent regardless of how long ago the SAR level was penetrated probably not a desirable thing to happen best to wait for the next cross over.


Also for the generic broker functions, using the esignal paper trader and tick replay is this identical to "realtime"?

It's actually pretty cool seeing the trades in realtime or tick replay hit the paper trading account, and moving from there to actual live trading is realtively straight forward?


I know you have mentioned using rawtime to backtest Renko charts, but for fast moving stocks the prices reported by the backtester are so far away from the "real market" that it's a real problem for me?

Any ideas how I could validate my Renko strategies, the backtester is off and realtime drifts so much I can'ttellwhats going on and even tick replay is generating signals way out of wack with simply loading the strategy formula?

I'm so burnt out from working on this for 3 days straight with very little sleep that I can't even think straight and would appreciate any suggeestions?


thanks glen

[eSignal_JasonK]

Hello demarcog,

Originally posted by demarcog
Jason,

I didn't mean to imply in anyway the barindex.efs had some programming error and that I was "correcting" it at all. I apologize if I gave you that mistaken impression.

My point was simply to experiment with the code so I could actually "see" the difference between setcomputonclose behavior and not specifying it....and just relating the experimenting I did that's all, and I appreciate the additional feedback.

No need to apologize. I was only explaining what was happening for educational purposes because you indicated that you were having some trouble understanding how getCurrentBarIndex() works with setComputeOnClose().

I also noticed in a earler post that for realtime live broker trading that you suggest doing a test for:

if ( getCurrentBarIndex ==0 ) bRealtime = true;

I have a modified parabolic SAR strategy that uses setComputeOnClose() and when I put the "bRealtime" test in when converting to realtime it obviously didn't trade, so I left the bRealtime test intact and commented out setComputeOnClose?

Remember that when a formula is using setComputeOnClose(), your formula code will not process data on bar 0 in real time as that bar is developing and is not closed yet. Therefore, getCurrentBarIndex() will not return a value of 0. Once the current real time bar closes it becomes bar -1. Then your formula code processes that bar one time. The variable bRealtime will never get set to true because the condition is looking for a bar index of 0 returned by getCurrentBarIndex(), which cannot return 0 when setComputeOnClose() is being used.

For setComputeOnClose() is BARSTATE_NEWBAR a sufficient test for "realtimeness"?

No it is not. When a formula is first applied to a chart, each historical bar is processed one time. Each bar returns BARSTATE_NEWBAR during this loading process. To check for the first bar that closes in real time while a formula is using setComputeOnClose(), create a global variable and set it to 0 initially. Then look for _NEWBAR and bar index of -1 and increment the variable by 1. Then change the condition for the bRealTime variable to the condition in the following example.

function preMain() {
    setComputeOnClose();
    ....
}

var nCntr = 0;
var bRealTime = false;

function main() {
    if (getCurrentBarIndex() == -1 && getBarState() == BARSTATE_NEWBAR) {
        nCntr++;
    }

    if (bRealTime == false && nCntr > 1) {
        bRealTime = true;
    }

    ....

} 

How would removing SetComputeOnCLose() effect a SAR type strategy?

The only thing I noticed is that there is a test for barindex (-1) to draw a righthanded arrow indicating the next SAR point on the most current bar which I don't think displays when setcomputeonclose is commented out.

It all depends on the specific logic of the formula code being used. Try adding a debugPrintln() statements to the code to see what code blocks are or aren't being executed. When you find a condition that is not being executed when you think it should be, analyze each piece of the condition in a debugPrintln() statement just above the condition. This will often uncover the reason why a particular condition is not evaluating to true.

Do you have any suggestions for SAR type strategies, waiting for the bar to close above/below the SAR point or using stop orders to reverse midbar on a 1 tick penetration, etc? Alexis had a very slick btbasicparabolic that I think waited for the whole bar to be above or below the SAR point?

Sorry, I can't give you any advice as to what logic to use to trade with. Hopefully some other members here will share their ideas with you.

It's also a little tricky when running realtime because when the strategy is realoaded using the generic broker functions, a new order gets sent regardless of how long ago the SAR level was penetrated probably not a desirable thing to happen best to wait for the next cross over.

This is most likely happening because your code is allowing a trade to be submitted on a historical bar while the formula is processing. Try implementing the check for real time I gave you above and see if that helps.

Also for the generic broker functions, using the esignal paper trader and tick replay is this identical to "realtime"?

It's as close as you can get. You should also test it with the paper broker and real time data.

It's actually pretty cool seeing the trades in realtime or tick replay hit the paper trading account, and moving from there to actual live trading is realtively straight forward?

Before using your code with your broker live, be sure to test it in demo mode with your broker. Also, I would highly recommend forcing manual confirmation of all orders submitted by your code while testing (and in live trading) to ensure that your code is performing as you intended.

I know you have mentioned using rawtime to backtest Renko charts, but for fast moving stocks the prices reported by the backtester are so far away from the "real market" that it's a real problem for me?

How are you comparing trade prices in the Strategy Analyzer to the "real market?"

Any ideas how I could validate my Renko strategies, the backtester is off and realtime drifts so much I can'ttellwhats going on and even tick replay is generating signals way out of wack with simply loading the strategy formula?

The indicator drift bug in real time is a known problem. Development has not been able to fix it yet. Unfortunately, there isn't a current solution for analyzing Renko in real time until this drift bug can be fixed.

As for the Strategy Analyzer results being "off," you'll need to provide more specifics.

[demarcog]

To check for the first bar that closes in real time while a formula is using setComputeOnClose(), create a global variable and set it to 0 initially. Then look for _NEWBAR and bar index of -1 and increment the variable by 1. Then change the condition for the bRealTime variable to the condition in the following example.

function preMain() {
    setComputeOnClose();
    ....
}

var nCntr = 0;
var bRealTime = false;

function main() {
    if (getCurrentBarIndex() == -1 && getBarState() == BARSTATE_NEWBAR) {
        nCntr++;
    }

    if (bRealTime == false && nCntr > 1) {
        bRealTime = true;
    }

    ....

} 

Thanks very much for that very useful example for setComputeOnClose().

For strategies that don't use setComputeOnClose() I will simply do the following:

 if (getCurrentBarIndex() == 0 && getBarState() == BARSTATE_NEWBAR) )  bRealTime = true; 

Thanks very much for your help, it is greatly appreciated.

[eSignal_JasonK]

You're most welcome.

[demarcog]

This post where JasonK generously explained how to test for a "real time" condition, required for executing the various Trade class methods (Trade.buyMarket() etc.) required to execute live trades was posted over 10 years ago.

Can some please verify if the following technique is still required:

function preMain() {
setComputeOnClose();
....
}

var nCntr = 0;
var bRealTime = false;

function main() {
if (getCurrentBarIndex() == -1 && getBarState() == BARSTATE_NEWBAR) {
nCntr++;
}

if (bRealTime == false && nCntr > 1) {
bRealTime = true;
}

....

}

In particular I am wondering if the test for nCntr being greater than 1 is still necessary.

The reason I am asking is I do not have setComputeOnClose() specified and do not see a difference in the detection of real time regardless of whether the nCntr variable is tested.

Does anyone run without specifying setComputeOnClose() in a real time live trading environment that can shed some light on this issue.

I am running into a indicator drifting issue when indicators for external intervals are returning invalid values in the Global windows and plotting incorrectly on the chart.

I need to reload the EFS for the values in the Global window and those plotted on the chart to be calculated and plotted correctly. This is preventing me from running this strategy real time.

My question to eSignal support staff is has the problem of "drifting indicators" that was well know and a problem some releases back been resolved??

thank you