Multilple Renko Box Move and BARSTATE_NEWBAR state

[dwalther]

Example: Symbol: ES #F, Renko Box Size: 1 (point), Time Frame: 5 minutes

If the market moves 3 points in 5 minutes (and stays at 3 points when the 5 minutes is up), 3 Renko boxes will be drawn on the chart to sort of catch up with the move.

Within EFS, how many BARSTATE_NEWBAR events will I receive?

1 for the close of the last box or 3 for each box drawn?

This is important, because stochastics (or any other mathematical indicator) will give different results depending on whether 3 prices are passed or 1 price is passed, even if the final price passes is the same.

If 1 BARSTATE_NEWBAR event is raised, as I fear, would close(-1) and close(-2) refer to the previous boxes as seen visually on the chart, or would they refer to the box of the previous BARSTATE_NEWBAR event?

And if it (close(-1)) refers to the box of the previous BARSTATE_NEWBAR event, how can I retreive the closing prices of those 2 boxes?

Derek

[eSignal_JasonK]

Hello Derek,

There is a known bug with EFS on Renko charts that cause indicators to drift (EDL #5) out of alignment with the chart. Formulas do not process on each of the 3 Renko bars in your example in real time, only on the last one. Due to this bug, EFS cannot properly plot indicators on Renko chart in real time.

However, calls to close(-1), close(-2) etc. at NEWBAR should return the proper bar values of the prior two Renko bars, not the last instance of NEWBAR.

[dwalther]

Thanks, JasonK, for the quick reply.

I was able to find an example on the charts where 4 Renko boxes were drawn in one time interval and I did confirm that close(-1), close(-2), etc. were able to give me those skipped box closing prices and that only one NEWBAR event was raised.

In my particular example, I am looking at a stochastic on the Renko box close, but any indicator will have the same problem.

I'm creating my own custom stochastic formula, among other things, and have the logic to determine when a Renko skipping occurs and have the logic to find the correct stochastic answer using the skipped closing prices and the current NEWBAR price.

However, the problem I'm having is this: In the case where 4 Renko boxes are drawn in one time interval, how do I return the proper stochastic number for time (-3), (-2), (-1), and (0) all at the same time when I leave main()?

I can calculate the correct stoch for time (-4), and then skipped boxes are drawn for time (-3), (-2), and (-1). Now I'm at time (0), and I again can calculate the correct stoch. If I return this number, a long line will be drawn from time (-4) to time (0) in the non-price study pane. This may prevent me from seeing any crossovers, etc. (It's purely a visual thing, as I could detect cross-overs in code.)

So, the question is, how to modify the main() function's returned array? Can I go back in time, return some numbers, and then come back to the future, like the movie.

Derek

[eSignal_JasonK]

Hello Derek,

Try using the setBar() function.

[demarcog]

Originally posted by dwalther


I'm creating my own custom stochastic formula, among other things, and have the logic to determine when a Renko skipping occurs and have the logic to find the correct stochastic answer using the skipped closing prices and the current NEWBAR price.

Derek

Derek,

There are a number of us who have been struggling for a long time with figuring out a way to correct this renko "drifting" problem.

If you have figured out away of correcting this problem and would be willing to share the code fix I would greatly appreciate seeing your solution.

Thanks in advance,

Glen

[demarcog]

Originally posted by JasonK
Hello Derek,

Try using the setBar() function.

Jason,

I'm not sure reading this post if it is applicable, but will this setbar() function provide a possible solution to the renko "drifting" problem?

[eSignal_JasonK]

Hello demarcog,

Originally posted by demarcog
Jason,

I'm not sure reading this post if it is applicable, but will this setbar() function provide a possible solution to the renko "drifting" problem?

It could potentially resolve the display for the plot after the drift occurs, but not necessarily correct the logic problems associated caused by the missed BARSTATE_NEWBAR events.