|
| Bad data in Renko feed |
|
scotpip
|
| Post subject: Bad data in Renko feed |
Post rating: 0
|
Posted: Fri 28 Mar, 2014, 12:54
|
|
User rating: 2
Joined: Thu 07 Nov, 2013, 12:15
Posts: 121
|
Hi I'm seeing bad data with the closing price in the Renko feed. Please note the opening price and closing price are the same: this happens every few bars. On a fairly small sample the Opening, High and Low have been correct, which means I can work out the closing price. But it would be nice to tidy this up - I had a baffling bug till I noticed the bad data. 11:22:29 Renko bar completed: StartTime: 2014-03-17 01:35:37.775 EndTime: 2014-03-17 01:44:42.718 O: 1.3907 C: 1.3907 H: 1.3908 L: 1.3907 V: 368.78 FEC: 141 of feed: FeedDescriptor [dataType=RENKO, instrument=EUR/USD, offerSide=Bid, period=7 Days, priceRange=ONE_PIP, ] Also, some of the O, C, H & L prices are not round pips and have 5 decimal places, which seems strange as the bar is formed on the rounded pip. I assume it's something to do with the way you handle gaps in the DoM? So far the fractional prices have always rounded to the correct pip, but will they do this reliably in fast markets? Thanks
|
|
|
|
|
 |
|
scotpip
|
| Post subject: Re: Bad data in Renko feed |
Post rating: 0
|
Posted: Fri 28 Mar, 2014, 13:05
|
|
User rating: 2
Joined: Thu 07 Nov, 2013, 12:15
Posts: 121
|
|
PS: bug seems to occur when the bars change direction.
|
|
|
|
|
|
|
scotpip
|
| Post subject: Re: Bad data in Renko feed |
Post rating: 0
|
Posted: Fri 28 Mar, 2014, 14:02
|
|
User rating: 2
Joined: Thu 07 Nov, 2013, 12:15
Posts: 121
|
PPS: Think I've also just found another, related bug, and this one is serious. onFeedData is being called when a new bar forms, but the bar in ITimedData feedData is not the bar that just formed and triggered the call, but the previous bar. So if the last bars on the chart were: 1 2 3 I'm not seeing the prices for 3 but the prices for 2. Unless I'm misunderstanding something this makes the feed pretty much unusable?
|
|
|
|
|
|
|
Platform Support
|
| Post subject: Re: Bad data in Renko feed |
Post rating: 0
|
Posted: Mon 31 Mar, 2014, 09:06
|
|
| JForex Master |  |
User rating: ∞
Joined: Wed 16 Sep, 2009, 18:23
Posts: 1049
Location: Geneva, Switzerland
|
|
ITimedData feedData returns only completed Renko bars. If you want the current, uncompleted bar, use context.getHistory().getFeedData(descriptor, 0);
Regardign the rounding. Only High and Low needs to be rounded to full points. Open and close may not be.
|
|
|
|
|
|
|
scotpip
|
| Post subject: Re: Bad data in Renko feed |
Post rating: 0
|
Posted: Mon 31 Mar, 2014, 13:41
|
|
User rating: 2
Joined: Thu 07 Nov, 2013, 12:15
Posts: 121
|
|
Hi guys
Don't feel that you've really addressed the issues I raised.
First - the closing price. It is surely a bug that the completed bars in the Renko feed are showing the same opening and closing price, as in the example I posted? As I said, this seems to happen when the direction of the Renko bars is changing - eg when a long bar follows a short bar, or a short follows a long.
Second - the relation of the data in the feed to the bars on the chart. I don't think I ever mentioned the current (unformed) bar - I was talking about bars newly formed on the chart as notified to onFeedData(). The callback onFeedData is called when a new bar forms on the chart, but the data in ITimedData feedData relates to the second-last completed bar rather than the bar which has just been completed and triggered the call to onFeedData(). I've just double-checked this again in a slow market and got the same problem. This makes the feed pretty unusable - I've had to give up and implement my own tracking of Renko events, but this means sacrificing volume data.
Another issue with Renko is the long lags I'm experiencing if I call history.getRenkoBar().
If I call history.getRenkoBar(defaultInstrument, OfferSide.BID, PriceRange.ONE_PIP, 1); from onTick it's taking around 2000 ms to respond.
Calls to history.getRenkoBar(defaultInstrument, OfferSide.BID, PriceRange.ONE_PIP, 0); are taking around 850 ms.
We have a fast dedicated line - the Ookla ping test averages 10 ms and we have 20 mbps dedicated download bandwidth.
These issues are surely enough to suggest that the Renko feed is unhealthy? It would be very much appreciated by our little team if you could investigate and fix these issue in the next release or two.
|
|
|
|
|
|
|
giorgio58
|
| Post subject: Re: Bad data in Renko feed |
Post rating: 0
|
Posted: Mon 31 Mar, 2014, 17:55
|
|
User rating: 0
Joined: Mon 31 Mar, 2014, 16:50
Posts: 21
Location: Italy, San Severino Marche MC
|
Good afternoon, I have implemented a strategy that works on the Renko chart. With the tester everything works ok, time RenkoBar getEndTime corresponds to the time of the corresponding tick. In live, instead, the time of endGetTime is earlier than the time of the tick and the completion of the corresponding bar is communicated to the platform several ticks after the closing of the bar itself. You can find a solution to this problem? Thank you. Example: Instrument: EUR/JPY feedData method: 2014-03-31 14:38:07:338 feedData: renko bar completed: StartTime: 2014-03-31 14:36:33.967 EndTime: 2014-03-31 14:36:33.968 O: 142.32 C: 142.29 H: 142.32 L: 142.29 V: 86.04 FEC: 67 ticktime: 2014-03-31 14:38:07:080OnBar method: 2014-03-31 14:38:07:338 onBar: renko bar start: 2014-03-31 14:36:33:967 bar end: 2014-03-31 14:36:33:968 ticktime: 2014-03-31 14:38:07:080 open: 142.32 high: 142.32 low: 142.29 close: 142.29 Another real data: Quote: 2014-03-31 14:38:28:742 tick: time: 2014-03-31 14:38:28:639 tick value: 142.266 tick volume: 3.57
2014-03-31 14:38:28:770 tick: time: 2014-03-31 14:38:28:712 tick value: 142.265 tick volume: 1.25
2014-03-31 14:38:29:064 tick: time: 2014-03-31 14:38:29:016 tick value: 142.259 tick volume: 1.0
2014-03-31 14:38:29:604 tick: time: 2014-03-31 14:38:29:555 tick value: 142.257 tick volume: 1.19
2014-03-31 14:38:31:167 tick: time: 2014-03-31 14:38:31:078 tick value: 142.256 tick volume: 1.5
2014-03-31 14:38:31:464 tick: time: 2014-03-31 14:38:31:332 tick value: 142.255 tick volume: 1.0
2014-03-31 14:38:31:530 tick: time: 2014-03-31 14:38:31:433 tick value: 142.251 tick volume: 1.25
2014-03-31 14:38:31:875 tick: time: 2014-03-31 14:38:31:787 tick value: 142.248 tick volume: 1.69
2014-03-31 14:38:31:975 tick: time: 2014-03-31 14:38:31:888 tick value: 142.245 tick volume: 2.44
2014-03-31 14:38:32:190 tick: time: 2014-03-31 14:38:32:141 tick value: 142.245 tick volume: 1.69
2014-03-31 14:38:32:575 tick: time: 2014-03-31 14:38:32:448 tick value: 142.245 tick volume: 2.25
2014-03-31 14:38:34:043 tick: time: 2014-03-31 14:38:33:998 tick value: 142.246 tick volume: 1.5
2014-03-31 14:38:34:199 tick: time: 2014-03-31 14:38:34:150 tick value: 142.246 tick volume: 2.25
2014-03-31 14:38:35:794 tick: time: 2014-03-31 14:38:35:695 tick value: 142.245 tick volume: 1.75
2014-03-31 14:38:35:893 tick: time: 2014-03-31 14:38:35:796 tick value: 142.245 tick volume: 1.75
2014-03-31 14:38:36:235 tick: time: 2014-03-31 14:38:36:150 tick value: 142.245 tick volume: 1.5
2014-03-31 14:38:36:527 tick: time: 2014-03-31 14:38:36:455 tick value: 142.242 tick volume: 1.25
2014-03-31 14:38:36:626 tick: time: 2014-03-31 14:38:36:556 tick value: 142.242 tick volume: 2.44
2014-03-31 14:38:36:824 tick: time: 2014-03-31 14:38:36:758 tick value: 142.238 tick volume: 1.5
2014-03-31 14:38:37:124 tick: time: 2014-03-31 14:38:37:011 tick value: 142.236 tick volume: 2.25
2014-03-31 14:38:37:224 tick: time: 2014-03-31 14:38:37:112 tick value: 142.237 tick volume: 1.88
2014-03-31 14:38:37:424 tick: time: 2014-03-31 14:38:37:314 tick value: 142.238 tick volume: 1.13
2014-03-31 14:38:37:921 tick: time: 2014-03-31 14:38:37:868 tick value: 142.24 tick volume: 1.0
2014-03-31 14:38:39:154 tick: time: 2014-03-31 14:38:38:759 tick value: 142.241 tick volume: 1.0
2014-03-31 14:38:39:232 tick: time: 2014-03-31 14:38:38:963 tick value: 142.237 tick volume: 2.25
2014-03-31 14:38:39:305 tick: time: 2014-03-31 14:38:39:267 tick value: 142.239 tick volume: 1.5
2014-03-31 14:38:39:638 tick: time: 2014-03-31 14:38:39:576 tick value: 142.242 tick volume: 1.13
2014-03-31 14:38:40:215 tick: time: 2014-03-31 14:38:40:082 tick value: 142.24 tick volume: 1.88
2014-03-31 14:38:40:673 tick: time: 2014-03-31 14:38:40:619 tick value: 142.24 tick volume: 4.13
2014-03-31 14:38:41:773 tick: time: 2014-03-31 14:38:41:701 tick value: 142.24 tick volume: 4.13
2014-03-31 14:38:42:646 tick: time: 2014-03-31 14:38:42:331 tick value: 142.24 tick volume: 1.5
2014-03-31 14:38:42:647 tick: time: 2014-03-31 14:38:42:533 tick value: 142.236 tick volume: 1.5
2014-03-31 14:38:42:894 tick: time: 2014-03-31 14:38:42:786 tick value: 142.236 tick volume: 2.25
2014-03-31 14:38:43:404 tick: time: 2014-03-31 14:38:43:291 tick value: 142.236 tick volume: 1.5
2014-03-31 14:38:43:605 tick: time: 2014-03-31 14:38:43:544 tick value: 142.236 tick volume: 1.0
2014-03-31 14:38:43:804 tick: time: 2014-03-31 14:38:43:696 tick value: 142.232 tick volume: 1.0
2014-03-31 14:38:44:005 tick: time: 2014-03-31 14:38:43:899 tick value: 142.233 tick volume: 2.07
2014-03-31 14:38:44:106 tick: time: 2014-03-31 14:38:43:950 tick value: 142.236 tick volume: 1.5
2014-03-31 14:38:44:204 tick: time: 2014-03-31 14:38:44:152 tick value: 142.236 tick volume: 2.25
2014-03-31 14:38:44:403 tick: time: 2014-03-31 14:38:44:303 tick value: 142.238 tick volume: 1.0
2014-03-31 14:38:44:865 tick: time: 2014-03-31 14:38:44:824 tick value: 142.238 tick volume: 1.0
2014-03-31 14:38:45:745 tick: time: 2014-03-31 14:38:45:712 tick value: 142.241 tick volume: 1.0
2014-03-31 14:38:47:234 tick: time: 2014-03-31 14:38:47:146 tick value: 142.24 tick volume: 1.5
2014-03-31 14:38:47:664 tick: time: 2014-03-31 14:38:47:610 tick value: 142.24 tick volume: 1.5
2014-03-31 14:38:48:174 tick: time: 2014-03-31 14:38:48:020 tick value: 142.24 tick volume: 1.5
2014-03-31 14:38:48:274 tick: time: 2014-03-31 14:38:48:172 tick value: 142.238 tick volume: 1.0
2014-03-31 14:38:48:795 tick: time: 2014-03-31 14:38:48:707 tick value: 142.237 tick volume: 1.0
2014-03-31 14:38:49:352 tick: time: 2014-03-31 14:38:49:268 tick value: 142.237 tick volume: 1.0
2014-03-31 14:38:49:874 tick: time: 2014-03-31 14:38:49:803 tick value: 142.237 tick volume: 1.0
2014-03-31 14:38:50:303 tick: time: 2014-03-31 14:38:50:221 tick value: 142.235 tick volume: 2.44
2014-03-31 14:38:50:520 tick: time: 2014-03-31 14:38:50:473 tick value: 142.235 tick volume: 1.69
2014-03-31 14:38:50:995 tick: time: 2014-03-31 14:38:50:814 tick value: 142.233 tick volume: 1.5
2014-03-31 14:38:51:496 tick: time: 2014-03-31 14:38:51:359 tick value: 142.232 tick volume: 1.0
2014-03-31 14:38:52:325 tick: time: 2014-03-31 14:38:52:226 tick value: 142.234 tick volume: 1.0
2014-03-31 14:38:53:763 tick: time: 2014-03-31 14:38:53:723 tick value: 142.234 tick volume: 1.0
2014-03-31 14:38:54:064 tick: time: 2014-03-31 14:38:53:976 tick value: 142.235 tick volume: 1.5
2014-03-31 14:38:54:165 tick: time: 2014-03-31 14:38:54:077 tick value: 142.235 tick volume: 1.5
2014-03-31 14:38:54:626 tick: time: 2014-03-31 14:38:54:380 tick value: 142.234 tick volume: 1.0
2014-03-31 14:38:54:924 tick: time: 2014-03-31 14:38:54:835 tick value: 142.235 tick volume: 4.5
2014-03-31 14:38:55:124 tick: time: 2014-03-31 14:38:54:987 tick value: 142.235 tick volume: 6.75
2014-03-31 14:38:55:223 tick: time: 2014-03-31 14:38:55:140 tick value: 142.235 tick volume: 3.75
2014-03-31 14:38:55:683 tick: time: 2014-03-31 14:38:55:646 tick value: 142.24 tick volume: 1.0
2014-03-31 14:38:56:244 tick: time: 2014-03-31 14:38:56:180 tick value: 142.24 tick volume: 2.25
2014-03-31 14:38:56:361 tick: time: 2014-03-31 14:38:56:282 tick value: 142.24 tick volume: 2.63
2014-03-31 14:38:56:464 tick: time: 2014-03-31 14:38:56:333 tick value: 142.242 tick volume: 1.75
2014-03-31 14:38:58:435 tick: time: 2014-03-31 14:38:58:196 tick value: 142.242 tick volume: 2.44
2014-03-31 14:38:58:791 tick: time: 2014-03-31 14:38:58:725 tick value: 142.244 tick volume: 1.0
2014-03-31 14:38:59:482 tick: time: 2014-03-31 14:38:59:443 tick value: 142.244 tick volume: 1.0
2014-03-31 14:38:59:583 tick: time: 2014-03-31 14:38:59:544 tick value: 142.242 tick volume: 1.69
2014-03-31 14:38:59:684 tick: time: 2014-03-31 14:38:59:595 tick value: 142.242 tick volume: 1.0
2014-03-31 14:38:59:784 tick: time: 2014-03-31 14:38:59:646 tick value: 142.241 tick volume: 1.0
2014-03-31 14:39:00:265 tick: time: 2014-03-31 14:39:00:159 tick value: 142.24 tick volume: 1.0
2014-03-31 14:39:00:773 tick: time: 2014-03-31 14:39:00:664 tick value: 142.24 tick volume: 1.0
2014-03-31 14:39:02:704 tick: time: 2014-03-31 14:39:02:637 tick value: 142.237 tick volume: 1.0
2014-03-31 14:39:03:209 tick: time: 2014-03-31 14:39:03:177 tick value: 142.236 tick volume: 1.25
2014-03-31 14:39:06:035 tick: time: 2014-03-31 14:39:05:850 tick value: 142.236 tick volume: 1.25
2014-03-31 14:39:06:135 tick: time: 2014-03-31 14:39:06:002 tick value: 142.231 tick volume: 4.32
2014-03-31 14:39:06:914 tick: time: 2014-03-31 14:39:06:816 tick value: 142.231 tick volume: 2.44
2014-03-31 14:39:07:415 tick: time: 2014-03-31 14:39:07:324 tick value: 142.231 tick volume: 1.5
2014-03-31 14:39:07:944 feedData: renko bar completed: StartTime: 2014-03-31 14:36:33.969 EndTime: 2014-03-31 14:38:28.712 O: 142.29 C: 142.265 H: 142.29 L: 142.26 V: 208.04 FEC: 127 ticktime: 2014-03-31 14:39:07:324
2014-03-31 14:39:07:945 onBar: renko bar start: 2014-03-31 14:36:33:969 bar end: 2014-03-31 14:38:28:712 ticktime: 2014-03-31 14:39:07:324 open: 142.29 high: 142.29 low: 142.26 close: 142.265
2014-03-31 14:39:07:946 tick: time: 2014-03-31 14:39:07:834 tick value: 142.23 tick volume: 1.25
2014-03-31 14:39:08:050 tick: time: 2014-03-31 14:39:07:986 tick value: 142.228 tick volume: 1.88
2014-03-31 14:39:08:585 tick: time: 2014-03-31 14:39:08:442 tick value: 142.223 tick volume: 1.69
2014-03-31 14:39:09:040 tick: time: 2014-03-31 14:39:08:991 tick value: 142.22 tick volume: 2.44
2014-03-31 14:39:09:594 tick: time: 2014-03-31 14:39:09:510 tick value: 142.22 tick volume: 1.69
2014-03-31 14:39:10:089 tick: time: 2014-03-31 14:39:10:023 tick value: 142.219 tick volume: 1.32
2014-03-31 14:39:11:514 tick: time: 2014-03-31 14:39:11:411 tick value: 142.217 tick volume: 1.32
2014-03-31 14:39:11:814 tick: time: 2014-03-31 14:39:11:714 tick value: 142.214 tick volume: 1.19
2014-03-31 14:39:12:125 tick: time: 2014-03-31 14:39:12:019 tick value: 142.21 tick volume: 1.57
2014-03-31 14:39:13:155 tick: time: 2014-03-31 14:39:13:105 tick value: 142.209 tick volume: 1.63
2014-03-31 14:39:14:444 tick: time: 2014-03-31 14:39:14:352 tick value: 142.209 tick volume: 1.63
2014-03-31 14:39:15:104 tick: time: 2014-03-31 14:39:14:969 tick value: 142.209 tick volume: 1.25
2014-03-31 14:39:15:405 tick: time: 2014-03-31 14:39:15:273 tick value: 142.203 tick volume: 1.69
2014-03-31 14:39:15:408 tick: time: 2014-03-31 14:39:15:324 tick value: 142.203 tick volume: 1.5
2014-03-31 14:39:15:746 feedData: renko bar completed: StartTime: 2014-03-31 14:38:28.713 EndTime: 2014-03-31 14:39:07.834 O: 142.26 C: 142.23 H: 142.26 L: 142.23 V: 134.7 FEC: 78 ticktime: 2014-03-31 14:39:15:324
2014-03-31 14:39:15:747 onBar: renko bar start: 2014-03-31 14:38:28:713 bar end: 2014-03-31 14:39:07:834 ticktime: 2014-03-31 14:39:15:324 open: 142.26 high: 142.26 low: 142.23 close: 142.23
2014-03-31 14:39:15:748 tick: time: 2014-03-31 14:39:15:653 tick value: 142.2 tick volume: 5.27
Problem with: JForex version 2.33.3 and earlier. Api 2.9.7.1 and earlier. Renko bar 3 pips.
|
|
|
|
|
|
|
Platform Support
|
| Post subject: Re: Bad data in Renko feed |
Post rating: 0
|
Posted: Wed 02 Apr, 2014, 10:18
|
|
| JForex Master | |
User rating: ∞
Joined: Wed 16 Sep, 2009, 18:23
Posts: 1049
Location: Geneva, Switzerland
|
scotpip wrote: First - the closing price. It is surely a bug that the completed bars in the Renko feed are showing the same opening and closing price
It is a normal situation if Open and Close of the same bar or candle is equal. Not only in Renko, it can happen with normal time based periods as well. scotpip wrote: I don't think I ever mentioned the current (unformed) bar - I was talking about bars newly formed on the chart as notified to onFeedData().
The last bar you see on the chart is uncompleted one. It cannot be received using onFeedData() scotpip wrote: The callback onFeedData is called when a new bar forms on the chart, but the data in ITimedData feedData relates to the second-last completed bar rather than the bar which has just been completed and triggered the call to onFeedData().
The last bar you see on the chart is uncompleted one. It cannot be received using onFeedData(). Bar is finished or completed ONLY when a new tick comes with price which is out of the bar's price range. Only then we can say that the bar is completed and can give it to the strategies. If new tick's price is in the range of the current bar, bar's values are updated (e.g. close price, volume). In other words, bar is uncompleted if any of bar's parameters can be changed in the future. scotpip wrote: I've just double-checked this again in a slow market and got the same problem. This makes the feed pretty unusable - I've had to give up and implement my own tracking of Renko events, but this means sacrificing volume data.
Bar is uncompleted and its volume can be changed. scotpip wrote: Another issue with Renko is the long lags I'm experiencing if I call history.getRenkoBar().
If I call history.getRenkoBar(defaultInstrument, OfferSide.BID, PriceRange.ONE_PIP, 1); from onTick it's taking around 2000 ms to respond.
Calls to history.getRenkoBar(defaultInstrument, OfferSide.BID, PriceRange.ONE_PIP, 0); are taking around 850 ms.
Our tests showed that the result is very similar. Please show the strategy source code to investigate.
|
|
|
|
|
|
|
Platform Support
|
| Post subject: Re: Bad data in Renko feed |
Post rating: 0
|
Posted: Wed 02 Apr, 2014, 10:37
|
|
| JForex Master | |
User rating: ∞
Joined: Wed 16 Sep, 2009, 18:23
Posts: 1049
Location: Geneva, Switzerland
|
giorgio58 wrote: With the tester everything works ok, time RenkoBar getEndTime corresponds to the time of the corresponding tick.
In live, instead, the time of endGetTime is earlier than the time of the tick and the completion of the corresponding bar is communicated to the platform several ticks after the closing of the bar itself.
We can complete the bar only when the new tick has been received as we cannot know in advance if the next tick will be in new bar or not.
|
|
|
|
|
|
|
giorgio58
|
| Post subject: Re: Bad data in Renko feed |
Post rating: 0
|
Posted: Thu 03 Apr, 2014, 13:38
|
|
User rating: 0
Joined: Mon 31 Mar, 2014, 16:50
Posts: 21
Location: Italy, San Severino Marche MC
|
|
Sorry but I can not understand:
From the real data:
If the bar is completed to 03/31/2014 14:38:28.712 (EndTime: 03/31/2014 14:38:28.712 on feedData)
Why OnFeedData event occurs at 31/03/2014 14:39:07:944 (ticktime: 31/03/2014 14:39:07:324)
after 77 ticks?
In the tester historical the event OnFeedData occurs exactly at the moment of reception of the last tick
Tester historical example:
feedData: renko bar completed: StartTime: 24/03/2014 14:35:26.059 EndTime: 03/24/2014 14:37:44.658 OR: 140.82, C: 140.85 H: 140.85 L: 140.82 V: 439.48 FEC: 216 ticktime: 03/24/2014 14:37:44:658
Is there any possibility to solve this problem?
thanks
|
|
|
|
|
|
|
scotpip
|
| Post subject: Re: Bad data in Renko feed |
Post rating: 1
|
Posted: Fri 04 Apr, 2014, 12:13
|
|
User rating: 2
Joined: Thu 07 Nov, 2013, 12:15
Posts: 121
|
Hi guys On opening and closing price being the same: Quote: It is a normal situation if Open and Close of the same bar or candle is equal. Not only in Renko, it can happen with normal time based periods as well. Sorry, but you are mistaken here. As you know, Renko is purely price based - time plays no part. So by definition a new 1 pip bar can only be formed if the closing price moves 1 pip or more from the opening price. If the price doesn't move, no new bar can be formed. It is logically impossible for the opening and closing price to be the same, so the typical data I posted must be a bug. Please check Nison on the construction of Renko charts. On the bar formation and data to onFeedData() being out of sync: Quote: The last bar you see on the chart is uncompleted one. It cannot be received using onFeedData(). Sorry, this is not the case. Unlike Sierra and other packages, JForex does not draw uncompleted bars. Bars are only drawn after they are complete (see screenshot). You can easily verify this for yourself. As I said more than once, the data in onFeedData() does not relate to the last completed bar, but to the bar before that. On feed performance: Quote: Our tests showed that the result is very similar. Please show the strategy source code to investigate. Not clear what you mean here? I would like the strategy to be able to work with historic Renko bars, but performance is so poor that this is impractical. Here is some demo code - it is taking around 45 seconds to read in the data from 20 historic bars, and as I've said, we have a very fast connection here: (echo() is my utility function for printing to console) Calling task from onStart(): RenkoTestTask renkoTest = new RenkoTestTask();
try{ context.executeTask(renkoTest); }catch(Exception x){echo(x.getMessage());}
Feed test task: private class RenkoTestTask implements java.util.concurrent.Callable<Object>{
public Object call() throws Exception {
try{
int n = 1;
IRenkoBar bar;
while( n <= 20){
bar = history.getRenkoBar(defaultInstrument, OfferSide.BID, PriceRange.ONE_PIP, n);
echo("Bar", bar.getHigh());
n ++;
}catch(Exception e){
echo(e.getMessage());
}
return null;
}
}
Please work with me on this guys - you really do have some problems with the Renko feed and I've spent quite a lot of time trying to bring them to your attention.
| Attachments: |
JForex Renko Formation.png [5.93 KiB]
Downloaded 175 times
|
|
DISCLAIMER: Dukascopy Bank SA's waiver of responsability - Documents, data or information available on
this webpage may be posted by third parties without Dukascopy Bank SA being obliged to make any control
on their content. Anyone accessing this webpage and downloading or otherwise making use of any document,
data or information found on this webpage shall do it on his/her own risks without any recourse against
Dukascopy Bank SA in relation thereto or for any consequences arising to him/her or any third party from
the use and/or reliance on any document, data or information found on this webpage.
|
|
|
|
|
|
|
|
Platform Support
|
| Post subject: Re: Bad data in Renko feed |
Post rating: 0
|
Posted: Fri 04 Apr, 2014, 13:38
|
|
| JForex Master | |
User rating: ∞
Joined: Wed 16 Sep, 2009, 18:23
Posts: 1049
Location: Geneva, Switzerland
|
scotpip wrote: So by definition a new 1 pip bar can only be formed if the closing price moves 1 pip or more from the opening price. If the price doesn't move, no new bar can be formed.
You are right in case of directional movement. But Open and Close can be equal in case of direction change. Quote: As I said more than once, the data in onFeedData() does not relate to the last completed bar, but to the bar before that.
The picture above explains a lot. Quote: Please work with me on this guys - you really do have some problems with the Renko feed and I've spent quite a lot of time trying to bring them to your attention.
We appreciate that very much. The answers given here will be added in wiki to avoid confusion in future.
|
|
|
|
|
|
|
scotpip
|
| Post subject: Re: Bad data in Renko feed |
Post rating: 1
|
Posted: Fri 04 Apr, 2014, 15:08
|
|
User rating: 2
Joined: Thu 07 Nov, 2013, 12:15
Posts: 121
|
Hi Thanks for the quick and detailed response, but I'm still baffled. One of us is misunderstanding something fundamental. On open and closing prices being the same: You are right in case of directional movement. But Open and Close can be equal in case of direction change. But a Renko bar is surely defined by its opening and closing price? If they are the same there wouldn't be a bar. And for a 1 pip Renko, the open and close have to be exactly 1 pip apart. For long bars, the open is the low and the close the high. For short bars, the open is the high and the close is the low. In your feed the high and low are never the same, as I believe is correct. Also, the open always equals the right high or low, which is correct. But the close is often different from the right high or low and is bugged. To clear up one possible source of confusion - Renkos can also have a wick high and low, which is available in the charting but not in the feed. This isn't documented, but the high and low in the feed are the opening and closing high and low, not the wick high and low. I've attached a diagram to illustrate my understanding of the high/low open/close relationship. If I am somehow mistaken, please explain and I will eat humble pie. But I've worked through the Nison definition of Renko formation to make my own implementation, so I'd be pretty surprised if I'm wrong. As to the bars changing once they have printed on the chart, please accept my assurance that this is mistaken. I've been working with JForex Renko for months and a formed bar never changes. A formed Renko bar can never change, surely, just as a formed candle can never change - it's a record of historic price data. Perhaps the source of confusion is that JForex doesn't show the new bar forming. It only shows the last completed bar. Some other charting packages, such as Sierra, show the partially formed Renko bar, which changes size till it is finally formed. JForex does this for candles but it most certainly doesn't do it for Renko. On JForex, I can assure you after many hundreds of hours of testing, Renko bars never change after they are formed. I think you are assuming that the rightmost bar is a bar in formation, like the rightmost candle. But this is mistaken. After a Renko bar is formed in JForex nothing changes on the chart while the price moves up and down until the next Renko bar is formed. There's no need for a disagreement about this - you can check it in 5 minutes using the historical tester in visual mode. I've got no argument with the chart - it works correctly. My argument is that the feed is bugged, perhaps based on a misunderstanding of how the chart was designed. If you guys are misunderstanding something fundamental about how the Renko chart works in JForex, that would explain my belief that the feed is bugged. If I am misunderstanding, I would very much appreciate a clear explanation with examples, and I will feel suitably stupid and apologise for wasting your time. As for the feed performance, should it really be taking thousands of milliseconds to give me a single historic bar? Or is something wrong? By the way there is a bug in your forum software - if you use the preview the image tags for the uploads lose the path they are enclosing.  
| Attachments: |
Dukas Renko Diagram.png [77.15 KiB]
Downloaded 864 times
|
Renko Direction Change - Open Close.png [23.92 KiB]
Downloaded 734 times
|
|
DISCLAIMER: Dukascopy Bank SA's waiver of responsability - Documents, data or information available on
this webpage may be posted by third parties without Dukascopy Bank SA being obliged to make any control
on their content. Anyone accessing this webpage and downloading or otherwise making use of any document,
data or information found on this webpage shall do it on his/her own risks without any recourse against
Dukascopy Bank SA in relation thereto or for any consequences arising to him/her or any third party from
the use and/or reliance on any document, data or information found on this webpage.
|
|
|
|
|
|
|
|
scotpip
|
| Post subject: Re: Bad data in Renko feed |
Post rating: 0
|
Posted: Fri 04 Apr, 2014, 15:20
|
|
User rating: 2
Joined: Thu 07 Nov, 2013, 12:15
Posts: 121
|
A postscript to my last post: 
| Attachments: |
Dukas Renko Price Sync Diagram.png [157.92 KiB]
Downloaded 873 times
|
|
DISCLAIMER: Dukascopy Bank SA's waiver of responsability - Documents, data or information available on
this webpage may be posted by third parties without Dukascopy Bank SA being obliged to make any control
on their content. Anyone accessing this webpage and downloading or otherwise making use of any document,
data or information found on this webpage shall do it on his/her own risks without any recourse against
Dukascopy Bank SA in relation thereto or for any consequences arising to him/her or any third party from
the use and/or reliance on any document, data or information found on this webpage.
|
|
|
|
|
|
|
|
Platform Support
|
| Post subject: Re: Bad data in Renko feed |
Post rating: 0
|
Posted: Fri 04 Apr, 2014, 15:58
|
|
| JForex Master | |
User rating: ∞
Joined: Wed 16 Sep, 2009, 18:23
Posts: 1049
Location: Geneva, Switzerland
|
scotpip wrote: I would like the strategy to be able to work with historic Renko bars, but performance is so poor that this is impractical. Here is some demo code - it is taking around 45 seconds to read in the data from 20 historic bars, and as I've said, we have a very fast connection here
We have checked the code. The problem is - you have not subscribed to the renko feed! 1) if not subscribed to the renko feed, it takes approx. 12 seconds, to load last 20 bars one by one. So long, because it loads buffer 20 times. If feed is not subscribed, no buffer is stored! 2) if is subscribed to the renko feed, it takes approx 400 milliseconds, to load last 20 bars one by one. to subscribe: context.subscribeToFeed(descriptor, new IFeedListener() {
@Override
public void onFeedData(IFeedDescriptor feedDescriptor, ITimedData feedData) {
}
});
|
|
|
|
|
|
|
giorgio58
|
| Post subject: Re: Bad data in Renko feed |
Post rating: 0
|
Posted: Mon 07 Apr, 2014, 08:26
|
|
User rating: 0
Joined: Mon 31 Mar, 2014, 16:50
Posts: 21
Location: Italy, San Severino Marche MC
|
|
Sorry, but I just want to know if there a way to have the same feedData.getEndTime tick.getTime in live chart as occurs in the tester.
thanks
|
|
|
|
|
|
|
Platform Support
|
| Post subject: Re: Bad data in Renko feed |
Post rating: 0
|
Posted: Tue 08 Apr, 2014, 09:15
|
|
| JForex Master | |
User rating: ∞
Joined: Wed 16 Sep, 2009, 18:23
Posts: 1049
Location: Geneva, Switzerland
|
|
I have made a little research of how we calculate Renko bricks in comparison to Nison's theory.
scotpip, you are right. Dukascopy Renko calculation approach on market reversals is different than that of Steve Nison.
Let us think what we can do about it.
|
|
|
|
|
|
|
scotpip
|
| Post subject: Re: Bad data in Renko feed |
Post rating: 0
|
Posted: Wed 09 Apr, 2014, 08:56
|
|
User rating: 2
Joined: Thu 07 Nov, 2013, 12:15
Posts: 121
|
|
Hi guys
Thanks for the suggestion on how to speed up access to the historical Renko data - I'll try it next week as soon as I have time.
I'm glad that we're making progress on the Renko logic bugs. I'll try and summarise my position.
First, bar pricing. Taking a long 1 pip Renko bar as an example:
1) The high and low price should always be exactly 1 pip apart, and should be exactly on the round pip prices. It should never be a fractional pip price. I think this is correct in the feed.
2) The open price should be exactly the same as the low price and the close price should be exactly the same as the high price. I think this is wrong in the feed.
Obviously, the argument is reversed for a 1 pip short bar.
Second, there is the question of the synch between the bar data passed to the feed callback method, and the newly formed bar on the chart that triggers the callback.
You have stated that the rightmost bar is not fully formed but this is incorrect. The JForex chart only shows the last completed bar, not the bar in formation. So when a new bar is formed on the chart and triggers a callback, the callback method should be passed the data for the rightmost bar. But, as you showed on your own screenshot, it is sent the data for the bar to the left of the rightmost bar.
Can you please confirm that you also accept that this is a bug?
I realise that you are in heavy development right now for your 4 release, and that Renko won't be a priority. But I suspect a fix will be relatively simple, so it would be good to know that it has at least made it onto the roadmap.
|
|
|
|
|
|
|
Platform Support
|
| Post subject: Re: Bad data in Renko feed |
Post rating: 0
|
Posted: Wed 09 Apr, 2014, 17:24
|
|
| JForex Master | |
User rating: ∞
Joined: Wed 16 Sep, 2009, 18:23
Posts: 1049
Location: Geneva, Switzerland
|
scotpip wrote: You have stated that the rightmost bar is not fully formed but this is incorrect. The JForex chart only shows the last completed bar, not the bar in formation. So when a new bar is formed on the chart and triggers a callback, the callback method should be passed the data for the rightmost bar. But, as you showed on your own screenshot, it is sent the data for the bar to the left of the rightmost bar.
It is different in our approach in comparison to Steve Nison theory. Just like we described in the screenshot. In the approach we will implement soon, which will be identical to the rules you wrote and which will correspond to Steve Nison theory, this should not be a problem anymore. The last completed bar will be returned using ITimedData feedData.
|
|
|
|
|
|
|
scotpip
|
| Post subject: Re: Bad data in Renko feed |
Post rating: 0
|
Posted: Wed 09 Apr, 2014, 18:53
|
|
User rating: 2
Joined: Thu 07 Nov, 2013, 12:15
Posts: 121
|
|
Excellent - this is a good outcome! I'll look forward to the fix - it will be useful for our current project.
Thanks for listening...
|
|
|
|
|
|
 
|
Pages: [
1, 2, 3, 4, 5
»
]
|
|
|
|
|
