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.