Dear Support,
Or anyone else, who played around with Renko bars.

I have a little issue with a strategy that prints a Renko bar's details (start-, end time, OHLC, etc.). As visible on the attached screenshot, the data on the Historical Tester's chart is not matching the data the is printed by the strategy. The different is in the start- and end times.



Why do I have such difference?

Not only you have difference. Take a look at https://www.dukascopy.com/swiss/english/forex/jforex/forum/viewtopic.php?f=85&t=50601.
And search forum.

Regards

We could not reproduce this, please make sure that the on-chart feed and the strategy feed parameters do match.

On the chart I am using a 10 pips custom Renko period.
In the strategy I am using:

public IFeedDescriptor renkoFeedDescriptor = new RenkoFeedDescriptor(Instrument.EURUSD, PriceRange.FIVE_PIPS, OfferSide.ASK);

as I don't know how the define the 10pips range.

However upon strategy start I am able to set 10pips:

22:29:07 Strategy "RenkoTest" Strategy ID: A07698C0FFB9AB83CCB0CB50A4EC5AD0 is started at 2014-01-14 22:29:07.668 GMT on the local computer with parameters ""=[FeedDescriptor [dataType=RENKO, instrument=EUR/USD, offerSide=Ask, period=7 Days, priceRange=10_PIPS, ]]

So I think I am using the same feed, right?

Try Custom renko aggregation

You can create 10 pips by using the PriceRange.valueOf method.

Thanks hebasto, I'll give it a try!

@Support:
Do you think it will make any difference? The strategy is starting with 10pips as configured Renko bar parameter, as visible on the quoted start message. That is just cosmetic to change the default parameter to 10pip instead of 5pip.
Are you able to replicate the issue? Or for you the chart and the strategy generates the same results?

Dear Support,

I've made little modification in the strategy. Using now context.subscribeToRenkoBarFeed. Result is still bad.

There is still a difference in the start- and end-time of the Renko bars between the strategy's calculation and the chart's value. Also, Volume is bad.


Please take a look on this. It is hard to believe that you cannot replicate this. Simply start the strategy in the Historical Tester...

Here is the slightly modified strategy.

Renko bars are price based, not time based. So, imho, the start- and end-time are not appropriate features for Renko bars. There is no standard definition of time limits of a Renko bar as well.

You shouldn't rely on time features of the price aggregated bars.

We already did look at this, for your convenience here is our printscreen:

@hebasto
Thanks, good point. Advise is taken!

@Support:
I appreciate your help.
If I may ask, is this made by running the strategy I've attached? If yes, could you help me find out why do I see a difference with the same strategy?
Based on hebasto's reply this is not a critical problem, but I am still curious why do I have such difference...
Also, the 2 attached strategy are using 2 different methods to subscribe to the Renko feed. Does it matter which one I use?

We ran the following:

public class RenkoTest implements IStrategy, IFeedListener {

    @Configurable("")
    public IFeedDescriptor renkoFeedDescriptor = new RenkoFeedDescriptor(Instrument.EURUSD, PriceRange.valueOf(10), OfferSide.ASK);

    private IConsole console;
    
    public void onStart(IContext context) throws JFException {
        this.console = context.getConsole();
        context.setSubscribedInstruments(java.util.Collections.singleton(renkoFeedDescriptor.getInstrument()), true);
        context.subscribeToFeed(renkoFeedDescriptor, this);
    }
    
    @Override
    public void onFeedData(IFeedDescriptor feedDescriptor, ITimedData feedData) {
        console.getOut().println(feedData);
    }

    public void onAccount(IAccount account) throws JFException {}

    public void onMessage(IMessage message) throws JFException {}

    public void onStop() throws JFException {}

    public void onTick(Instrument instrument, ITick tick) throws JFException {}

    public void onBar(Instrument instrument, Period period, IBar askBar, IBar bidBar) throws JFException {}
}

Dear Support,

What I've just discovered, is that the strategy generated values are the same as yours. For example if I compare my strategy's result with the screenshot you have attached, I see the same values:

22:27:29 renko bar completed: StartTime: 2008-01-01 17:47:28.229 EndTime: 2008-01-01 18:46:55.788 O: 1.46 C: 1.46001 H: 1.461 L: 1.46 V: 27995.25 FEC: 4182

However my chart does not contain the same information about this particular candle:



You have mentioned that I have to be sure that the chart and the strategy are using the same feed. As now the strategy is generating the same data as for you, how can I be sure that my chart is using the same (proper) settings?
Does it have to do anything with performance of the computer I am using? It seems that there are differences about start- and end time. As these parameters of the candles are calculated on the fly (just guessing), would a slower machine calculate different results? Or this is absolutely irrelevant?
Please give me tips, what to check, as this is not the way it should be.

Price based periods in the charts are calculated from the interpolated 1 Minute or 1 Hour period candles at the moment due to the performance reasons. Historical tester has been run on the ticks in these tests thus making the Renko caluculate from the ticks as well. Obviously you have run the test first and then switched the chart from Bid to Ask later, forcing the chart to show the Renko calculated from the interpolated Ask candles instead of the ticks. Hence the difference in the data. API support has switched the sides before the Renko have been drawn in the test, so it had everything correct.

I think I could be good to assist Hercule Poirot. Or maybe he could be my apprentice

Anyway, I hope this confusion with the Price based periods ends as soon as we offer calculating them from the ticks.
Would you be ready to spend a long time in calculating the Renko from the ticks data just to be sure that you have the most precise method used? After the calculation is complete, we could cache the data locally, so the second time you open it they wouldn't be recalculated.
If the answer is yes, we could get rid of the base periods as well and calculate them with the starting point set at the beginning of the ticks data. We have no other option than calculating them on your side as the custom price based periods are very many.

I think you pretty much nailed it.

Define 'long time'! .

Would that be an option to let the user select the calculation method for Renkos? Like an option in the platform's preferences.
We can see from time to time there are some questions here on the forum about the Renko's 'behavior', so there are user who would like to have this calculation modified. But probably there are other users out there who are satisfied with the way Renko's are drawn at the moment, so probably they will be unsatisfied, as they will see this just as a slowdown.
I would try to make both parties happy, and offer them the choice...


And some more brainstorming on this subject:
1) If that is an option to let the user select which Renko calculation he/she want to have, and if the calculation from tick data is time (processor) consuming, let system check what hardware the platform is running on, and only make the tick data calculation available, if the CPU is powerful enough to deal with such task.
2) How about involving some extra process power to calculate Renko's from tick data? OpenCL for example.

Dear Support,

Have you considered my reply? Are you planning to implement this other (better?) Renko chart calculation in the near future?


Please let me know.

Returning the result for price based periods could be divided in two parts. The first one is ticks data downloading, the second is calculation. The download time would vary very much depending on the download speed. The calculation time depends on the size of the period. e.g. Renko 1 pip or 2 pips is very fast. Few seconds. Our tests showed that Renko 100 pips could take up to 1 hour depending on the start point in time (base periods or the start of the history) and the hardware.

Yes, we plan to implement several calculation methods which would be set in Preferences.

Sounds interesting!
Any planned release dates?

Dear Support,

May we have an update about the release date of the new price-based calculations? I think I am not the only one who is looking forward for these.