+1 888 340 6572
MultiCharts Project Management
previous_open_issue.png
Go to the previous open issue
previous_issue.png
Go to the previous issue (open or closed)
star_faded.png
Please log in to bookmark issues
feature_request_small.png
Open Feature request MC-1485

Last bar in Renko charts

action_vote_minus_faded.png
4
Votes
action_vote_plus_faded.png
next_issue.png
Go to the next issue (open or closed)
next_open_issue.png
Go to the next open issue
Description

When I load a Renko chart the last bar there sometimes is not shown correctly. It usually fixes itself after an incoming tick but, I think, it may trigger wrong signals if the chart has a strategy attached to it.

Steps to reproduce this issue

I'm not sure how to reproduce this issue. I think it may be related to gaps in the regular price. It actually appears quite often right after I open a workspace with Renko charts. I attach the screen shots:  1 - Renko chart with a problem, 2 - the regular chart at that time, 3 - the same Renko chart after it fixed itself.

Comments (5)
#0
user-offline.png  Alex MultiCharts (Alex MultiCharts)
Oct 04, 2013 - 12:46

MultiCharts 8.0 implementation: in real-time no matter what resolution is specified, each next box of the specified size will be plotted once privious box is finished.
MultiCharts 8.1 and any further version implementation: depending on the selected resolution the current box may be huge in real-time and not match your box size, but when the selected in resolution bar (1 day for instance) is closed, you'll see a lot of boxes of the specified box size instead of that huge one.
Please descibe how you would like it to work and let other customer vote for it.

#0
user-offline.png  Argos (argos_888)
Oct 04, 2013 - 16:01

I think the MultiCharts 8.0 implementation was correct. Renko bars have nothing to do with resolution. Would you mind to explain (or provide a link) why the resolution is needed at all?

#0
user-offline.png  Alex MultiCharts (Alex MultiCharts)
Oct 07, 2013 - 13:08

Every chart type (regular, renko, point and figure, cumulative delta, volume delta and so on...) and chart resolution (points, contrcats, hours, weeks and so on...) are built out of 3 base data types coming from all supported data providers. Tick data is the most precise, as it gives all price increments/decrements, while the minute and daily data are simply the OHLC bars (so only 4 prices per bar). Renko chart type used to be based on tick data only. Such chart was precise, but it was very limited in the amount of historical backfilled data, since not many data vendors give a дще ща ticks through their APIs. The option to select the "base" resolution to constract Renko boxes was added in order to let customers have greater historical data range.

#0
user-offline.png  Argos (argos_888)
Oct 11, 2013 - 11:15

It looks like there is no good solution if one cannot use the tick data. I understand that using the minute data for historical boxes generation and the tick data for real-time boxes generation will create inconsistency (it may be impossible later to generate exactly the same boxes for the whole time interval based just on the minute data). From the other side, having that big bar creates a huge issue for real-time trading of strategies based on indicators. It may generate false entry/exit signals. What if you keep the 8.0 implementation as an option and let users to decide what they want to use? It can be just a check box in the properties, something like "Use tick data for real-time bars generation".

#0
user-offline.png  Alex MultiCharts (Alex MultiCharts)
Oct 14, 2013 - 11:54

Please change the description of the feature reuest to let other customers vote for it.

History
Issue basics
  • Type of issue
    Feature request
  • Category
    Stability
  • Targeted for
    Not determined
  • Status
    Under Review
User pain
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
Affected by this issue (2)
People involved
Times and dates
  • Posted at
  • Last updated
Issue details
  • Resolution
    Not determined
  • Severity
    Normal
Attachments (3)
Commits (0)
There are no code checkins for this issue
Duplicate issues (0)
This issue does not have any duplicates