 |
| EURUSD M1 Chart with Renko Bricks |
In the following discussion, some of the points I make refer to the majority of Renko chart implementations made, including my own, using the Metatrader 4 platform. In some other systems, some of the limitations I describe in the caveats section CAN be overcome.
Caveat emptor!
Possibly the best (though in my opinion still not complete) description of Renko bars can be found in a (small) chapter of "Beyond Candlesticks" by Steve Nison. Renko (the name is thought to be from the Japanese word for bricks - Renga) charts show price movement away from a point, the bricks being drawn only when a certain price move has been made, not merely documenting the price change after a fixed time period, as with regular charts.
To avoid confusing myself and the reader, I refer to the source (regular) chart components as "candles", and the output (Renko) components as "bricks".
Figure 1 below shows a EURUSD M1 chart (top) with the corresponding Renko chart (bottom). Here you can see the clean angular movement of price, which allows for easy identification of the (minor) trend. Also, notice the difference in timescale, the Renko chart having fewer bricks than the source has candles.
 |
| EURUSD M1 Source Chart |
 |
| 5 Pip EURUSD Renko Chart |
Renko charts are traditionally drawn as follows.
1. Pick a base price (Nison does not say how or give any clue as to which to pick). [see Note 1]
2. If a future close (Nison used daily stock closes) touches or exceeds (base price + boxsize), draw an up brick. If a future close touches or exceeds (base price - boxsize), draw a down brick. In my Renko charts, I use red for down and green for up. Traditionally white and hollow bricks have been used respectively.
3. Once the first brick is drawn, record the high (HI) and low (LO) of that brick.
4. For subsequent candles, draw a new brick when the future close touches or exceeds (HI +boxsize) or (LO - boxsize). [see note 2]
One side effect of this is that when price oscillates within 2 range boundaries, alternate up and down bricks are not drawn. Price "noise" is thus eliminated.
In forex, we have easy access to tick-by-tick data for the latest candle, and so may wish to enhance the traditional Renko bricks by monitoring prices on a tick basis, and optionally (sometimes essentially) adding the highs and lows of the preceding period as per the source chart (See the section on Wicks).
With historic data, we have already lost irretrievable information, (being the tick sequence) and so we may partition our drawing algorithm into 2 distinct parts:
Instructions 2 to 4 above are repeated for all historic candles. Once we have processed all our historic information, we can continue processing realtime data tick by tick. For each new tick, check the Bid price against the previous HI and LO, and draw bricks as before.
There are a few caveats to using Renko:
Quantisation noise
(Where I indicate "soft" in the next paragraph I am referring to any stop loss or take profit that is managed by the client, rather than the broker's server. My position is that showing the broker your stops in a dealer-desk situation is like showing your hand in a poker game).
Quantisation noise refers to the information lost when data is sampled, and then attributed an arbitrary level (in our case we take a price move and our output can only ever be on a box boundary). This has implications for example when applying a (soft) trailing stop. The price may move against us by a shade less than the boxsize, and we will never know, since a new Renko brick is only drawn when price moves by the boxsize or more. A (soft) take profit which is not set to a boundary point will be triggered at a different price (i.e. the next boundary). A (soft) stop loss which is not set to a boundary point will also be triggered at a different price. If our money management strategy depends on the stop level being accurate, we may be risking a larger percentage of our equity than we had anticipated.
Volume
It is impossible (someone please contact me if I am wrong, I would love to hear from you) to accurately attribute volume to a Renko brick which is sourced from historic data, unless a Renko bar mapped 1:1 to a source bar. Some assumptions need to be made. For this reason, using any kind of volume indicator on a Renko chart may not give the desired results. [see note 3] Live bricks (those drawn after generator has processed all the historic information) are different, and volume can be attributed accurately. In any system where the volume/time relationship is important, beware that this relationship disappears with Renko, since bricks all have potentially different durations.
Timestamp
For historic data, when the price touches or crosses a box boundary the timing of the crossing is unknown. We can only be accurate to within the chart resolution (i.e. Metatrader 4 has minimum resolution of 1 minute). We only have the opening time of the historic bar [see note 4]. Again, Live bricks constructed from tick-by-tick data can be given accurate timestamps, since we know to the tick at which point the touch or cross was made.
Wicks
Wicks are interesting, since they can be displayed on the bricks and indicate (hard) stop triggers. Whilst I prefer "soft" stops, the gaming problem doesn't exist with ECN brokers, does it? Displaying the Renko bars on the main chart (as per the introductory diagram, also provides its challenges, but is invaluable in dtermining what happened in some scenarios.
Engulfing bars
A common "programmer decision" is to firstly look at each historic candle high. If the high has breached a boundary, then one or more up output bricks are drawn, else, if the low has breached a boundary, then one or more down bricks are drawn. Look at your Renko chart. Do you see "impossible bricks"? (The wick of a down brick is more than 2 bricks higher than its open, or the wick of an up brick is more than 2 bricks lower than its open). This is a direct result of the programmer decision made above and can be resolved as follows: If the close of the current bar is less than the open (we would draw a down brick as per the previous algorithm) we first look to see if the source bar had a high that would indicate we need to draw some "up" bricks first, since these must have occurred at some point before the down close. Similarly where the close is greater than the open, we draw any "down" bricks first. Note that we still cannot be certain that this was the case, since we cannot know the time sequence of the highs and lows within a single source candle boundary.
Notes
[1] The choice I made was to pick the oldest candle that contains a "boundary", and use that boundary as the base price. To calculate boundary prices, start from 0 and repeatedly add the boxsize. e.g. High=1.4222, Low=1.4211, box-size=0.0015: We count 0.0000, 0.0015, 0.0030, 0.0045, ..., 1.4205, 1.4220. Base price is now 1.4220 (In practice we use quotient * box-size). Had the first candle contained 2 or more boundaries, I could have immediately started drawing some Renko bars, although I would have to make some assumption as to which boundary occurred first in time, possibly using Open and Close price to disambiguate.
[2] Most existing software uses "exceeds" but not "touches". Drawing new bars when price touches a boundary results in surprisingly more output bars being drawn.
[3] Currently I assign volume of 0 to all my historic Renko bars.
[4] Currently I assign the bar opening time to the first Renko bar generated from the source data, and add 1 second if I need to generate another.
