Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Axes and axes related enhancements for the OHLC chart #92

Open
DaTrader opened this issue Jan 20, 2024 · 5 comments
Open

Axes and axes related enhancements for the OHLC chart #92

DaTrader opened this issue Jan 20, 2024 · 5 comments

Comments

@DaTrader
Copy link
Contributor

DaTrader commented Jan 20, 2024

Content

  • Content overflow should be effectively hidden on both sides. Candles at the edges should have their overflowing halves hidden.

Value (Y) axis

  • The value axis is typically placed on the right side of the chart. Currently, changing the call in OHLC to Axis.new_right_axis/1 makes it lose the value labels or show them only partially (the amounts getting clipped) - this should be fixed.

  • There should be a way to configure the value label frequency. A typical setting is one in three lines.

Time (X) axis

  • There needs to be a fixed spacing format (in pixels) so the bars/candles do not stretch from left to right but only occupy the space demanded by their spacing and width. Any remaining empty room on the right should be kept as such (empty) while the X axis should show the time 'ticks' from edge to edge uninterrupted nevertheless.
    I added the spacing property as part of the zoom levels, but it takes propagating it to rendering the content (and possibly the time axis).

  • The axis should support time formatting (e.g. may introduce a dependence on the CLDR DateTime library). In any case, charts showing days and higher timeframes need to show the full date (either mm/dd/yyyy or dd/mm/yyyy) while the intraday charts (less than D1) should show time as dd/mm hh:mm or any localized variation thereof.

  • The time (tick?) label occurrence should be quite dense (with a character or two of whitespace between the labels).

@mindok
Copy link
Owner

mindok commented Jan 21, 2024

Time (X) axis

The axis should support time formatting (e.g. may introduce a dependence on the CLDR DateTime library). In any case, charts showing days and higher timeframes need to show the full date (either mm/dd/yyyy or dd/mm/yyyy) while the intraday charts (less than D1) should show time as dd/mm hh:mm or any localized variation thereof.

This is possible without adding a dependency in Contex by using a custom_formatter option in the chart construction.

There needs to be a fixed spacing format (in pixels) so the bars/candles do not stretch from left to right but only occupy the space demanded by their spacing and width. Any remaining empty room on the right should be kept as such (empty) while the X axis should show the time 'ticks' from edge to edge uninterrupted nevertheless.
I added the spacing property as part of the zoom levels, but it takes propagating it to rendering the content (and possibly the time axis).

So this a scale issue - the logic for mapping data to pixels should be contained within a scale. The "correct" way to handle this is most likely to introduce a new scale type that implements the behaviour you require. This would also allow you to specify the tick spacing logic - tick intervals are also calculated within a scale.

@DaTrader
Copy link
Contributor Author

Cool. So who's gonna do it (the scale thing)? You or me?

@DaTrader
Copy link
Contributor Author

DaTrader commented Jan 28, 2024

@mindok Take a look at this. Not bad for a start..

image

Need to introduce "steps" in the time axis to show every nth tick.

Btw, turns out there's 0 work required to have those weekend/holiday gaps (this is a daily chart and you can see the weekend candles missing owed to how your plotting based on time not the index). Flat bars have thus become full optional (and low priority). But having an indexed based chart (without the gaps) is another thing.

@mindok
Copy link
Owner

mindok commented Jan 29, 2024

Looking very nice @DaTrader! With the ticks, have you looked at changing the interval count for the time scale? The actual interval is calculated by looking up the nearest round time interval to the "raw" interval taken be dividing the total time domain by the interval count specified when the scale is created (defaults to 11). The logic is between Contex.TimeScale.nice and Contex.TimeScale.lookup_tick_interval

With the right hand margin (labels truncated), it looks like the logic for calculating the default margin is incorrect - it doesn't take into account whether the axis is left or right. See plot.ex around lines 400-420. It looks like the right hand axis is not currently created from anywhere. In theory (I haven't tried), you can manually override the right margin (~ line 388 shows the option being tested) if you want to see how a RH margin looks.

@DaTrader
Copy link
Contributor Author

Looking very nice @DaTrader! With the ticks, have you looked at changing the interval count for the time scale? The actual interval is calculated by looking up the nearest round time interval to the "raw" interval taken be dividing the total time domain by the interval count specified when the scale is created (defaults to 11). The logic is between Contex.TimeScale.nice and Contex.TimeScale.lookup_tick_interval

Thanks. I am already "overriding" that behavior, for otherwise the nice/1 function would have shrunk everything by automatically opting for a larger timeframe. So, in effect, I am enforcing the supplied tick_interval instead of the one looked up by the nice/.

See plot.ex around lines 400-420. It looks like the right hand axis is not currently created from anywhere. In theory (I haven't tried), you can manually override the right margin (~ line 388 shows the option being tested) if you want to see how a RH margin looks.

Thanks, will try that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants