The devil is in details, usually. For example charting is heavily based on time on x axis, but all range bars don't work that way. Yet proper visualization is absolutely essential in the strategy development stage, where most time is spent. That's why I did this history trick, to cheat charting and be able to at least visualize properly.

Most of indicators should continue to work unchanged, but not all. But for indicators that depend on time heavily, counting bars in many ways represents time, but market time, not wall clock time. Yet, all that code would probably need to be carefully screened and adapted where necessary. For example, Slippage is very cleverly implemented right now in Zorro, because it's based on time, but it would then obviously need to be adapted to fit range bars. Finally, even though for example renko bricks are OHLC, essentially only 2 prices make sense, possibly even only 1 (close) so one needs to be very careful. Actually, I think standard renko bricks could be problematic for all the same reason why I discarded median renko as an option. Zorro trades on open price of the next bar, and I'm not sure that when renko reverts direction, that the open price is really tradable.

So, lots of details really, what I wrote above is probably just a tip of the iceberg.

No. MA crossover can run on Renko or any other range bar completely unchanged.

With standard bars, when bar is finished, your run() function gets to run, you recalculate MA's, check if they crossed and decide whether you want to open a position or not. If you do, the position is executed at the open price of the next bar.

With range bars, everything said above stays exactly the same.

Of course, you can't reuse the exact MA parameters, strategies have to be re-tuned and re-optimized, but generally, exactly the same algorithm and procedure works for both standard and range bars, in this simple MA crossover example.

When I said to apply a filter before calculating a data point... I think that would already have been done by whatever implementation Zorro uses to deal with BarPeriod.

The current BarPeriod (grouping of ticks/bars) is based on time, whereas a Renko BarPeriod would be based on price. If that was handled properly, then I do think any indicator would still work and even display properly.

Since Renko implementation is really just a different grouping of price clusters, that is why I said it "should not be too difficult" to implement. Zorro is already handling price clustering bounded by time (for example tick data). This implies a multiple random number of datapoints could compose each single bar for the chosen BarPeriod. A Renko BarPeriod would be the same thing, only grouped by price range not timestamp.

Ah, I see what you mean, how to construct higher BarPeriod's with range bars? To be honest, I haven't thought about that so far, but it gets messy, you're right. That's why until now I have exclusively used what I synthesized (with BarPeriod = 1), and if I would get unhappy with something, I would simply create new bars. For example if and when I become unhappy with 5 pips bars I provided in last uploaded zip, I will not increase BarPeriod, but resynthesize new bars with say 10 pips range and just replace bar file. Then simply continue with research on "a higher timeframe".

I'll open ancillary topic in some other subforum and upload some pics. It's hard to explain something that is basically visual. And we're probably all visual types. What we don't see, it doesn't exist. For example I never saw tick data anywhere in Zorro, therefore it doesn't exist.

Funky charts: http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=435538#Post435538

Maybe when Zorro implements, it will be as easy as a command like:
RenkoBrick = 20;
(to indicate a brick size of 20 pips)

Also, I forgot to mention... in some implementations of Renko bars I've seen, they've left the wicks intact. I think strict Renko does not have wicks, but there seems to be arguments about whether or not wicks could be useful.

A wick represents price clustering outside of an established brick's boundaries, where the Renko strength was not enough to form a new successive brick yet. Therefore, they would only ever appear on the current brick, or on reversal bricks I think.

Yes, wicks are easily implemented and your explanation is correct. Yet, I personaly haven't so far looked at them as something useful. They exist even in my grid bars, but only because it's so easy to calculate/add them, so I thought, why not. Maybe somebody finds use for them, one never knows... people have been known to do even sillier things like looking at moon phases and trade accordingly.

They can appear on any brick, but only on one side of the brick, by definition.

Hi folks,

Been offline for a while apologies for jumping in.

A couple of questions strike me about this discussion, and forgive me for any ignorance displayed.

1) Why do you need to construct renko charts? I would have thought that any renko, grid or range bar type strategy could be implemented in code with variables and arrays focusing on the rules without having to shoehorn it into zorros bars? The advantage of this is it allows an evaluation of any renko entry/exit signal vs what the actual bar price is doing. I've toyed with Renko and Kagi charting on my discretionary trading and the big problem for me was where the price really was when the signal fired on the Renko/Kagi. I actually found them more useful for exits than entries, but drifted out of using them.

2) In abstracting time from price, why not start with fixed number of tick bars, i.e. zorro creates a new bar when it receives a fixed number of ticks. You would obviously need good quality tick data for any backtest. To me conceptually this makes more sense, as more bars will be drawn when something is actually happening, and few will be drawn when nothing is happening. I think this approach would be more compatible if the ultimate aim is not just the renko,kagi,strategies themselves but in applying the rest of zorro's tools and indicators.

3) what is the trade frequency you are looking for? (I'd like to ask what timeframe but that makes no sense ;-) ) i.e. strategies with the same trading frequency as say a daily or a 1 min traditional price/time strategy. If it is the latter my gut tells me that time of day would still matter.

Hey swingtraderkk (I knew I missed somebody ) and thanks for stopping by! Your comments are not ignorant, find my answers below.



Having renko implemented as indicator is certainly not a bad advice, and could be done relatively easily. You even have my demo code somewhere in this thread that you could polish a bit and do exactly that. But here's the problem. Consider what you do in the research phase, for example if you want to develop new strategy based on classic bars and RSI (MACD, or whatever). On the screen you have price chart above, and indicator chart below. You look at both and decide for example to buy if RSI is below 10, and sell if it's above 90. You enter the data into your script, backtest, get lousy results , then get back to the chart and try to deduce what went wrong. you retune based on your findings, maybe add another indicator, rinse and repeat. But the whole time you're quite dependent to have both price and indicator on the screen and in sync (time wise) to be able to develop your strategy.

Now consider classic price data + indicator based on renko. You tehnically cannot chart them based on the same X axis (time). Sometimes your renko indicator would keep it's value for many bars in the chart window, sometimes it would like to print 5 bars during the same price bar (when there are rapid market movements) and that is just impossible to chart. The reality is that classic bars and renko (even as indicator) are clocked so differently that you just can't chart them together. And if you can't see them, you can't research.

Of course, if you already have renko based strategy (do you?) you could implement it the way you suggested, visualization is not required if you're just trading it.



Bars that are clocked on number of ticks is yet another type of bars. I considered them in the past, but discarded the idea as not easily implemented for forex market specifically. The reason being I do have reasonable quality tick data and I can see from it how market drastically changed between 2007. and 2013. I.e. the liquidity improved, spreads narrowed, so there's a whole lot more ticks per time period in recents years than before. So I think it would skew the bars. Of course, some kind of heuristics could be implemented to use different threshold for different years, but it still looks like too much magic to me.

Finally, even if I claim that tick data I have is of reasonable quality, I'm not forgetting that it's the data from one specific broker. Only one! So those are ticks that depend on what liquidity providers that one broker had in various time periods, how many customers etc... I just don't believe that number of ticks in specific time periods is really a good representation of the entire forex market. That's why I discarded your idea in the beginning and don't intend to pursue reseraching bars that tick on number of price ticks ever. At least not to trade forex market... I reserve the right to reconsider if I switch to futures market any time soon.



It still makes some sense to be interested in the timeframe, because statistically you can determine the average time period of each range bar. As I already shared, for the bars that I synthesized last, for exactly that kind of bars and exactly 5 pips chosen as a parameter, it's quite easy to estimate that they tick at about 5 minute frequency. Previously I also played with 10 pips renko and CBR bars.

If you ask me personally what I look for, well I don't know. I'm looking for a timeframe that is most profitable. Jokes aside, I'm looking for a lower timeframe so I have more data available for backtesting, therefore statistically more valid results, more market conditions covered etc... Also, it's easier to later monitor how that system works in a live market if you have say 10 trades a day than if you have 1 or 2 trades a week. We're getting old on a daily timeframe, if you understand what I mean. So, the lower timeframe the better, although I'm not stupid, the lower we go it seems harder (or impossible?) to find market inefficiencies and extract alpha from them (commissions are more important, slippage etc..). I would generally be very happy to someday have a system that works somewhere in the 15min - 1hour timeframe.

You now reminded me of one frightening fact that I discovered while playing with all these interesting bars. If 5pips bars of my current type are about 5min, could you tell the average timeframe of 10pips sized bars? It's simply (10/5)^2 * 5min = 20 min EXACTLY. The precision goes way below 1% error and it's consistent in a very wide range of values. This goes to explain how random forex market really is and what we are up against. When I first discovered this rule (by an accident, of course) I was in a bad mood for the rest of the day.

Veeeery interesting!

The way I see it, a Bar should just be a place-holder, like a mount-point in Linux, or a cup, which we can fill with whatever we want.

If you want to put a single tick on a bar, then line-chart it and zoom in or out to check out the waves, then go for it. Want a dozen ticks per bar, or a thousand? Easy enough.
Bar = Ticks(However_Many_You_Want);

Prefer seconds, minutes, hours, etc?
Bar = Time_Unit(However_Many_You_Want); // The most artificial bar that was ever invented! Also, the most deceptive!

Range bars or Renko?
Bar = RangeBar(Whatever_Range_You_Want);
Bar = Renko(Whatever_Number_Of_Pips_In_One_Direction_You_Want);

The bugger is that it will increase training/testing times when you first use them, as they will have to be built on the fly... If they're saved after the first test, though, it becomes quicker to add fresh data to them.

Ticks tell us everything we need to know, (unless you're getting them from crapt4), and analysing the information they hold is much easier if you leave the tocks in the clocks.

Anyways, that's my 2 shoes' worth.