Median Renko bars for Zorro

THE GOOD

The median renko is a variation of the regular renko chart. This chart type features wicks and initial transposing of the new bar's open value to the middle of the previous bar's body (the median), thus smoothing the chart and eliminating noise, which would otherwise be present on indicators applied to the chart.

THE BAD

I synthesized median renko bars from Dukascopy tick data for EUR/USD, from 2007-04-02 to 2013-06-14, inclusive. I went with 10 pips for bar size, that is a new median renko (MR) bar after every 5 pips price movement. Then I reused times from the original Zorro EURUSD_2012.bar and filled the new price data in. The choice for MR bar size was such that I could fit all data inside the original file and spare me quite some trouble converting date formats and fitting data in many files. Actually, I wanted to generate new times at first, but then it struck me that I would probably also need to skip weekends and what not, so I gave up on that idea, this was faster.

Here's what you'll need to do if you want to play with this:

- Download http://www.perltrader.com/zorro/EURUSD_2012.bar.zip zip archive. Unzip.
- Replace your original EURUSD_2012.bar in the Zorro History folder (backup it first!)
- Make sure you have these 3 lines near the top of your strategies:

StartDate = 2012;
EndDate = 20130101;
BarPeriod = 1;

Actually, only the first two lines are mandatory, lest you pull in the weird mix of standard candlestick bars and median renko bricks! You could play with the third one, but again you'll be backtesting a weird abomination of bars. You have been warned!

THE UGLY

Obviously, all this is a very ugly hack. Zorro doesn't have support for any kind of renko bars ATM, so while this is the fastest way to introduce and play with them, it's also cheating, and all kinds of weird things could happen!

- always have in mind that renko bars eliminate the time, all they care about is price movement! All dates/times of the renko bars that you'll encounter are artifical, or put even simpler: a lie!
- for the above reason many of the Zorro functions that care about specific time (of day, hour, etc...) simply won't work, don't use them!
- it would be hard to backtest a specific period of time (only year 2008, for example), you would need to decipher the artificial time period that encapsulates the real time (so, not impossible, but hard)
- the renko bars that I synthesized include the so called phantom bars. They exist where there were big price gaps in the original tick stream. I strongly believe that having phantom bars is the right way, because indicators can then be more responsive. Unfortunately, this probably also means that the strategies run on this data will give slightly better results on backtests, because they will occasionaly enter trades at better prices than they could in reality. I don't see a way around this, currently. Let's hope that the impact is reasonably small. Just have it in mind if you come up with the holy grail fast.
- there could be all kinds of other incompatibilites that we will encounter, so never forget that this is just a dirty hack! It's almost 4am here, and even I haven't had a chance yet to play with this data, but I wanted to share this early (pun intended). I'm pretty sure the ugly list will only get longer in the following days.

Still, have fun! Having even this little bit of renko magic available opens a whole new parallel universe to your strategies. I certainly can't wait to marry immense Zorro power with this data.

This is an interesting approach. The problem is that you can convert historic price data to Renko bars, but you can then not trade the system live.

An alternative would be to just generate Renko bars by script, like an indicator. You could run that system with 1-minute time frame, generate an array of Renko bars from the past 2 weeks or so, and evaluate trade signals not on any bar, but any time when the last Renko bar is closed.

Yeah, right. I forgot the main problem with the approach. You can use the bars only for backtesting, not for trading.



Sure. That will be in v2, if any decent strategy comes out from this test data. And I'm still learning programming in Lite-C... So far, so good.

Well, I was getting so decent results, that I first had to remove phantom bars, before continuing research. I guess I severely underestimated their impact on the profitability. So, a brand new history file is available to download, with the only difference that phantom bars are now removed (gaps are preserved):

http://www.perltrader.com/zorro/EURUSD_2012.bar-nophantom.zip

But, even with such (now very close to reality) data, I'm getting some unbelievably good results after backtesting even very simple and unoptimized strategies. The question now is have I uncovered the holy grail, or have I been bitten by yet another data leak from the future? History teaches me to be heavily inclined towards the latter view on the situation.

Unfortunately, I can't find any error in my calculations, so it's probably Zorro that is fooling with me now. Not that I find it guilty, the poor automaton was never designed for advanced concepts like median renko with gaps and tails.

Anyway, most of the strategy statistics I pasted below are certainly off because Zorro thinks it backtested only a year of data, when it was provided full 6 years of history. But even if we divide some numbers with 6, we are still left with a very decent performance. And look at the equity curve, can it get better than that?

BackTest AB_MR_win1 EUR/USD - performance report

Test period 02.01.2012-01.01.2013
Lookback time 800 bars (13 hours)
Assumed slippage 10.0 sec
Assumed spread 2.4 pips (roll -0.10/0.02)
Contracts per lot 746

Gross win/loss 6926$ / -4541$ (+31978p)
Average profit 2386$/year, 199$/month, 9.18$/day
Max drawdown -71$ 3% (MAE -79$ 3%)
Total down time 64% (TAE 96%)
Max down time 10 days from Jul 2012
Largest margin 5.00$
Trade volume 9288797$ (9289062$/year)
Transaction costs -1625$ spr, -609$ slp, -1.44$ rol
Capital required 128$

Number of trades 9074 (9074/year)
Percent winning 28%
Max win/loss 39$ / -15$
Avg trade profit 0.26$ 3.5p (+2.77$ / -0.69$)
Avg trade slippage -0.07$ -0.9p (+0.03$ / -0.16$)
Avg trade bars 41 (+104 / -18)
Max trade bars 1267 (21 hours)
Time in market 102%
Max open trades 1
Max loss streak 24 (uncorrelated 30)

Annual return 1945%
Profit factor 1.53 (PRR 1.48)
Sharpe ratio 8.46
Kelly criterion 3.83
OptimalF .207
Ulcer index 1%
Prediction error 17%

Portfolio analysis OptF ProF Win/Loss

EUR/USD:L .220 1.53 1262/3275
EUR/USD:S .194 1.53 1241/3296



I don't know how to proceed from here. Need some fresh ideas, suggestions...

I agree that something looks wrong with that equity curve. I suspect the conversion algorithm: Are you sure that it does not use any future peeking? Does any Renko bar absolutely not contain any info from prices used for the next bar? Any slight mistake here will generate such an equity curve.

If the bars are ok, then the next possible reason is in-sample testing an optimized system - this can also generate such an equity curve.

Empty your piggy bank & send it to the broker!

I also made first moves in this direction yesterday (actually, yesternight :D). This will be a tough nut to crack, if not impossible at all.

The problem is that I need renko bars to be the first class citizen in Zorro (read: a series) so that I can easily apply other Zorro indicators and heavy machinery to it. But all my attempts so far (read: dirty hacks) failed horribly because series like to tick at the exact BarPeriod * TimeFrame clock just as the documentation clearly states. So I wasn't able to push renko data in a series data type after some hours of experimenting.

Actually, now that I digged a little bit deeper in Zorro internals I see that I still don't understand quite a lot of underlying technology. For example, a series look a lot like the classic C array. But then how do you add new data in front of the array (at index 0)? If this was a C language array, you would then need to shift all the other elements one place to the right. With even a relatively long array it would become quite expensive (memory copy of all the arrays data every BarPeriod). So I don't believe it's working like that, but what are you doing, then? Are you playing games with the pointer to the array (maybe doing realloc() all the time to extend the array to the left)? Do you keep series in the reverse order in memory, but present it backwards to the scripts?

Anyway, I got to this point trying to manipulate a series so that I could fill it at a frequency that I control, but as I already said, my current attemps all failed. Lite-C seems to me like a sandbox that is not allowing such low-level alterations to happen.

I would appreciate your help at this point, jcl. Show me the right direction, before I'm lost completely.

Yes, you'll need a normal C array, not a series. And you must indeed shift the array by script for adding a new bar at the front. Zorro also internally shifts its series - this is pretty fast as long as the array fits into the Pentium cache. No pointer tricks involved. The series are stored in reverse order.

Yes, I'm pretty sure that the data is clean of future peeking. My conversion script is running linearly, tick by tick. What I suspect is that Zorro somehow peeks one bar into the future, but I don't know why and how. For example I can destroy the profitability if I use priceOpen() instead of priceClose() in the strategy, but that shouldn't be needed. That is an artificial one bar lag that can easily destroy any strategy.

But I'll recheck the data once again. Maybe I put here the conversion example of a few bars, so more eyes can peek at it and show me where I did something stupid. Data munging can be hard at times.



Sure, been there - done that.

Huh, this is the answer I wasn't expecting. If series are internally stored in reverse order, then you don't need to shift them, just append at the end, right? I don't see a reason to do both?

If I go with a normal C array, will I then be able to apply indicators (that work on series) on it?

Actually, the whole time I thought the series ARE the normal C array, but with a bit of added machinery to make it tick.

With 'reverse order' I meant from new to old. New data is appended at the begin of the series. Shifting them could theoretically be avoided with some tricks, for instance allocating a larger array and moving its pointer. However such tricks are not used in the current Zorro version. The shifting has not much effect on the backtest speed.

But, have you also noticed that the win rate of the strategy is only 28%? It's not that it's flawless, it's just that the wins are more than enough to cover for all the losses and then some. Yes, it's a trend following strategy. The simplest you could imagine, anybody can code it in a few minutes.

What if renko's are uncovering the truth behind candlesticks, which hide it pretty well all the time? What if I really need to empty the piggy bank?

It seems to me that 99% of traders/investors are trading with the candlesticks, and what do we usually say about following the herd? This fact, and some inherent positive capabilities of various other charting methods, is what wildly attracts me to them. I might stumble on some road blocks during the way, but I'm not giving up until I hit the wall.

Ah, I see. OK then, it seems that you don't think that it's impossible to implement renkos as things stand, so I'll continue hacking. I do have some new ideas now.

I only miss your answer on the topic of applying standard Zorro analytics tools (indicators etc...) on the normal C arrays? Can that work? Say, I implement a C array, order the elements as needed, can I then give it's pointer to the RSI() and have the calculations done, the same way as if I provided a series to the function? I think this is crucial.

Yes, all Zorro indicators can use normal C arrays. A series is also a normal C array, it's just shifted at every bar.

Cool, thanks! The future is bright again.

Unless this poor notebook dies of overheating...

Interesting thread, I enjoy reading things that inspire lateral thinking.

Good luck with this acidburn and keep us updated on your journey for the holy grail

Thanks, Geek!

I have some good news, and some bad news.

The good news is that I really made a nice progress with this, as you can tell by the attached code. The bad news is that I think this is not worth pursuing further. The problem is that Zorro is so centered on BarPeriod clock, that trying to break out of that concept is a world of pain! At moments it felt like I was rewriting the Zorro... in Zorro!

I mostly succeeded making the volatility based bars (not renko's, not CBR's, but conceptually close!). But the plots are still created at BarPeriod resolution, so they're just not useful to develop strategies on custom bars. Unless jcl chimes in with some breakthrough idea, of course, but even then I see lots of obstacles on the way. The slight problem is also that there's no realloc. And I also see how troublesome it would become to take care of the proper lookback for strategies with multiple indicators.

I heavily commented the code, so if anybody wants to continue with this, be my guest! I guess I just got tired of fighting the system. But, I learned a lot about Zorro in the process, so it was actually a time good spent.

And I almost forgot, I eventually found what was wrong with the EURUSD bars I attached earlier in this thread. It's not that the bars had knowledge of the future, but instead they allowed trading at the previous better prices, so trades would end up more profitable than it would be possible in reality. But the end result is the same, equity curves that are just too good to be true.

I've been bitten with a very similar thing before, I guess I never learn. Actually, I know very well how to avoid such mistakes in my home-made backtesting gear, but everytime I try to push such data to foreign platforms like Zorro, I repeat the same mistake. Oh, well...

I will surely continue investigating various strange bars, but after a slight pause...

Thanks for that script! It should work well for trading with Renko bars, only in the chart they are of course plotted with different width because the x axis is based on price bars, not on renko bars.

I do not believe that a profitable system is possible with Renko or similar artificial bars. But if you nevertheless want to pursue that further, we can implement a Zorro function for building price bars in a user defined way. Renko bars will then be plotted correctly and your above script will become somewhat simpler. Of course this method has many limitations, for instance you can have only one asset - portfolio trading is not possible. But let me know if you still want to continue with Renko research and we'll implement that.

I think I'll never stop being interested in this kind of artifical bars (or at least not before I conclude my research with them and possibly come to the same conclusion as you, that they're not really profitable). But to continue I'd really need a decent setup to work with. You're right, with the script I attached, it's almost possible to run various tests and strategies. Unfortunately without a proper charting support, it's not really comfortable. Proper visualization is absolutely required at this stage.

So, my answer is yes, if you can improve the support in Zorro for such kind of bars, I would gladly continue my research. The only question is how much effort on your part is needed to support them properly. I leave that decision up to you. Because for the first time it looks non trivial, and I certainly wouldn't want to distract you from all other great improvements that you're working on and adding to now my absolutely favorite platform for system deveopment.

About time I wake up this old thread. Take three!

The title of the thread isn't valid anymore, as I had to drop median renko idea because of the inherent problems while backtesting those beasts. Zorro executes run() function after every bar, then if you decide to open the position, it uses the open price from the next bar. Unfortunately, the open in the median renko is in the past, which allows for much better execution than would be possible in reality. If nothing else, it reveals how our trading would become extra profitable if we could add just a few pips to every trade we do.

So, having all that in mind, my new bar abomination is quite simple and allows for proper backtesting. If the price moves 5 pips in whatever direction, a bar is printed. There are wicks, but they should not be important. Bars are similar to renko, but different, because renko requires twice as much movement in the opposite direction before printing brick. I'll call this thing a grid bar. If I can make any progress with it. Also I reintroduced phantom bars. For example if there was a 20 pips gap in the original price data, there will be 4 bars (20/5) printed. It's good for indicators, but could also inflate backtest results. We can sort this out later, once again if the bars prove useful.

So far I have tested only a few simple things, without any results to show. But I haven't yet got even to the ever popular MA crossover, so there's still work to be done.

If you're going to play with this, I suggest:

• reading this whole thread to understand what all this is about
• renaming EURUSD_2011.bar, too, so you know when Lookback tries to go to 2011 data
• set Weekend = 0
• set Slippage = 0

Bars are based on 5 pips movement, synthesized from about last 5 years of Dukascopy EURUSD tick data.

http://www.perltrader.com/zorro/EURUSD_2012.bar-grid.zip

And I wanted to attach the screenshot, so you can see how the bars look, but this subforum doesn't allow attachments.

Very funny. Luxor trading system can be very easily "persuaded" to be profitable, but only after summer 2010. (before that it's flat). That's about where it became unprofitable on time-based candlesticks. I'll take this as evidence that big money switched to volatility bars few years ago. No wonder professional system traders have been losing money last few years (known fact).

AR is 308%, but it should be smaller in reality because backtest is over 3.5 years, but Zorro doesn't know that. Sharpe is 3.20 and that is really excellent. I don't know how to scale it (complex math). Still can't attach chart to show how it looks.

Anyway, this started looking promising. I need to study Luxor in depth, still don't understand all it's details. But, something in there is very very promising...

Oh, BTW, here's the script. Notice that it has Spread/Slippage/Roll at 0, I copied that from jcl's Luxor script. So eventually results will be worse. But as it took 15 minutes to get these, it's still impressive.

Thanks for the script - it's certainly an additional motivation to implement the user-defined bars soon.

Although, I have to warn right away before anyone starts celebrating that setting Spread = 0 will turn almost any strategy profitable with beautiful equity curves. Once again, if one can add only about 2 pips to every trade (i.e just remove the broker fee), suddenly every ugly duckling strategy becomes a swan.

The average win per trade was 1.1p without the spread. Add about 2 pips spread and suddenly it ends up at -1.1p. Winning strategy instantly turned losing by accounting for broker fees.

Mental note: to ignore the results unless average trade expectancy is at least a few pips, best if at least 5.

Important: as I've stuffed about last 5 years in 1 year worth of 1min records, synthesized bars could be roughly compared to standard 5min data.

I really like your findings so far with Renko bars acidburn. Please clarify... since you are using a synthetic .bar file, that means we cannot really use this in live trading yet until Zorro would implement Renko natively and on-the-fly, correct?

I think it will be very useful to separate price movement from time.

Yes, that is correct. This history is just for strategy research, nothing else. Before going live with this stuff, we'd need native support in Zorro or some other platform.



So far my feelings are mixed. It's true that bars like this reveal some oportunities that would be hard or impossible to exploit with time-based bars. But some of my expectations so far failed horribly. Time will show...

I've done a fair amount of research with price movement independent of time, albeit not in an automated trading environment. It was also not with Renko bars, although the concept of Renko is something that I think can accomplish that goal of price/time separation.

I think the concept of merging price and time could be fundamentally flawed, but it is used as a basis for almost all modern trading. Any time you force market price to be attached to a time boundary, you have created an artificial representation that could be misleading, or at least misinterpreted. That is my theory anyway.

The combination of Renko + Zorro could open a lot of doors. Price is all that really should matter, but due to limitations in most modern trading software, we don't have a good way to visualize the supply/demand independent of the time constraint.

It's nice to know that I'm not the only one that is wasting time on these things. So far I felt pretty lonesome, at least on this forum. First exotic bar type I played with were constant range bars (I still remember the excitement when I first discovered them), quickly followed by Renko, Median Renko, and finally with these latest one that I don't even know how to call.



And my theory exactly. Whenever I see 100 pips bar, surrounded by tens of 5 pips bars on both sides, I know it was a trading opportunity lost because all that happened on inadequate time scale. And 5 pips bars are better not traded, chop chop. When I try to remedy that by going down on the timescale, I immediately get drowned by sea of randomness, commissions eat all the profits and so on. Basically these discoveries are what fueled my research into exotic bar types so far. Bars now tick at my profit/loss frequency, they're in perfect sync. ATR is constantly constant etc, etc...



Doors are ajar with the data I provided. Not all is perfect, but chase for an elusive edge is already possible. Because, Zorro like most of other platforms is heavily time based, I guess it's not possible to implement support for timeless bars without a lot of effort. So I can understand that it could take a lot of time and/or lot more interest before it happens.

Speaking of supply/demand, basically we're in the wrong market (forex - no central volume) to be expecting that. We could switch to trading futures, but then some other problems emerge, like less liquidity, bigger capital requirements etc.. Don't know, seen many supply/demand theories, still nothing attracted me to dig deeper. Seems too complicated, no evidence of usefulness, etc... Unfortunately this industry is plagued with con artists, sometimes lots of time is wasted trying to pick sense, where there's none.

I think that it should not be "too difficult" to implement Renko bars in Zorro, though maybe I'm over-simplifying quite a lot here.

I *think* traditional indicators and performance metrics could survive and still work (because they are only looking at the price/trade series data). But I think you'd want to have additional indicators added to specifically support Renko.

For example, on a candle chart we may plot an MA crossover and say that when the short MA crosses the long MA, then that is a buy signal. However, since the MA function is based on price series, it would then not line-up correctly when overlayed on a Renko chart.

Instead, it seems like some sort of filter would need to be applied to the series, to group it into Renko bars instead of traditional candle bars. This filter would need to be applied *before* calculating the MA data point. Is that correct? You are still using the same signal to identify the trend change, but now you've abstracted time and have filtered price through the Renko rules. The effect is that you cluster prices together irregardless of time.

If you stop to think about it: Renko (or other time-independent methods) makes perfect sense. I think everyone would agree that the market moves on *its own* time schedule and will not allow itself to be boxed in like that. That is why I think time-based methods are flawed.

By the way, I'm only speaking about Renko in a general sense. I briefly studied Range Bars and determined that Renko was better. I have not heard of Median Renko yet.

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.

Hey gang,

Don't know if this sounds too far-fetched or not but...

Imagine if you could plot single ticks on a line chart, then train an algo to recognize the patterns at that low a level... Something along the lines of voice-recognition... You wouldn't be able to trade it all unless you had ultra-low spreads and commissions, but you would certainly see the paying moves coming.

Weird, but potentially wonderful.

I think it's still up for debate -- whether or not tick-level analysis is even a worthy endeavor. That may sound contrary to the typical trading buzz... but you have to consider the tradeoffs.

More trades is usually desirable because it (can potentially) lead to more wins. But there are tradeoffs in processing, quality of patterns vs noise, and execution constraints. I'm not convinced that it's a good game to try to play if you aren't a bank, for example.

If you could make the same rate of profit with a slower look at the market information, then it's easier. Easier to analyze, better quality patterns and easier to execute.

Small fry traders also have an advantage over banks and large institutional players in that we can move much more swiftly, usually even under-the-radar.

Hey Dusktrader,

It would take a hell of a lot of preparation for processing, for sure, but I think it would help get into the big movers sooner.

Having been stuck with mt4 for a couple of years, I've been looking for trend methods that can be used on any timeframe, so that I can get into a trend on the lowest viable timeframe, then, once they have some profit locked in, holding their stops back until the next timeframe up can take over the management.

Most trades will get their stops hit, but you'll get the odd few that will sneak past the retracements, and end up sitting on the weekly or monthly chart's management list.

The TMF functions in Zorro can enable us to do that sort of thing now, but still, I'd like to have the option of eradicating the time factor, and just concentrate on the waves.

I agree with everything you said, and that would certainly be a great bot if you build it!

But, I would argue that at some low level (say below 5 minutes), it no longer makes sense to try to trade that.

so just set it up so that it only activates above 5 minutes

Oh, I'll build it eventually... I just have to learn how to use Zorro decently first, then learn how to code from scratch... I've only done a bit of CPE coding in mql4, so I've got a fair bit of frack to bunt thinking to undo first, though

Dusktrader: I've been following your coding and testing threads, so that should make things much easier, thanks

I'd like to add our vote to the push for easier price based strrategies in Zorro.

You guys on the Zorro team seem unconvinced that price-based trading will add to the profitability of users, so have given Renko lower priority.

But like acidburn, we've been playing with Renko and P&F and finding it works very well to filter out the noise caused by time. As acidburn points out, it's not time movements that make profits, but price movements. The time dimension often simply obscures this.

In our tests, indicators and signal processing often work much better on Renko charts, and for building price action algos Renko bar patterns are much clearer and easier to define in code in comparison to candles.

Good features for price-based and volume-based bars, charting and reporting would help differentiate Zorro from the many mid market and even quant level platforms that seem to handle this badly.

For building accurate forex Renko histories, Dukascopy offer pretty clean tick-level price histories for free. They can be accessed easily with the free Tickstory utility.