-
-
Notifications
You must be signed in to change notification settings - Fork 71
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
Allow for log scale of the y axis #103
Comments
just some notes for myself:
ideas:
|
Also add ASCII art to illustrate definitions and layout. See #103.
We can't simply use Taking the log of a value <= 0 can also be a problem if we add a panel to the plot. We use the xts plot object So we may need to manually map in/out of log space. Here are some thoughts on what needs to happen if we go that route:
|
dont think the data itself should ever have values <= 0 . neither base nor quantmod plotting currently supports that kind of input. if more talking about negative ranges in the plot area introduced by the |
Hmm, guess that wasn't clear. I'm referring to when the raw data has negative values. And that causes EDIT: never mind. I don't know what made me think you could plot negative values in log-scale with |
Also add ASCII art to illustrate definitions and layout. See #103.
We need to control the y-axis line and label locations for each panel in order to support a log y-axis in a panel. See #103.
The yaxis_expr() function captured the first argument as an expression and substituted that argument symbol into the y-axis expression to render. This was more complicated than necessary. Put all the logic into one single expression, instead of building multiple expressions and concatenating them together based on arguments to new_panel(). This required adding 'use_get_ylim', 'draw_left_yaxis', and 'draw_right_axis' into the panel environment. Adding 'use_get_ylim' to the panel environment means get_ylim() is only called once. This improves performance because each call to get_ylim() calls update_panels(). See #103.
These values are the same for every point the function is called. See #103.
Multi-panel plots were the only time 'use_get_ylim' was TRUE. And the only time it had any effect was when 'is_ylim_fixed' was also FALSE, which was only true when 'yaxis.same' was TRUE. This was one of two times we had to re-calculate the 'ylim' based on every panel. The other time was when 'ylim' is NULL and 'multi.panel' was FALSE. And 'is_ylim_fixed' is also FALSE in that case, so we know to re-calculate 'ylim' whenever 'is_ylim_fixed' is FALSE. See #103.
It's hard for me to reason about doing something different when a boolean is FALSE. It's easier to reason about doing something different when the boolean is TRUE. Rename 'is_ylim_fixed' to 'use_global_ylim' and reverse the logic so we recalculate ylim when 'use_global_ylim' is TRUE. See #103.
This creates y-axis labels using the raw series values, instead of the log series values. So the labels and locations are in round values of the raw series, but rendered at the logged locations. See #103.
# xts 0.14.x (202x-xx-xx) * `plot.xts()` now renders all panels when 'x' has more than 8 columns and `multi.panel = TRUE`. Columns 9 and later didn't render because the default of `plot.xts()` is 'col = 1:8'. Thanks to Ethan Smith for the report and patch. ([#423](joshuaulrich/xts#423)) ([#424](joshuaulrich/xts#424)) * `plot.xts()` no longer errors when 'ylim' is constant and negative. Thanks to Ethan Smith for the report. ([#422](joshuaulrich/xts#422)) * Do not use `SET_TYPEOF()` in C because it is not part of the public R API. * `merge.xts()` no longer converts 'x' or 'y' from double to integer in the C code when they are not used in the result. This avoids an unnecessary and confusing warning. Thanks to Jeff Ryan for the report. # xts 0.14.0 (2024-06-05) * `addEventLines()` and `addLegend()` now draw on multiple panels when `on` is a vector. Thanks to Ethan Smith for the report. ([#420](joshuaulrich/xts#420)) * Replace `SET_TYPEOF()` in merge.c because it will error when it tries to convert a REAL to an INTEGER. Thanks to Kurt Hornik for the report! ([#419](joshuaulrich/xts#419)) * Fix crash when 'j' is not an integer and in [0, 1) (e.g. `j = 0.1`). Also throw a warning when 'j' is not an integer. ([#413](joshuaulrich/xts#413)) ([#415](joshuaulrich/xts#415)) * Fix plot header when `layout()` is used to draw multiple plots on a single device. Thanks to Dirk Eddelbuettel for the report and testing! ([#412](joshuaulrich/xts#412)) * Fix plot legend location when the y-axis is log scale. ([#407](joshuaulrich/xts#407)) # xts 0.13.2 (2024-01-21) * Print a message when `period.apply()` is called with `FUN = mean` because it calculates the mean for each column, not all the data in the subset like it does for all other functions. The message says to use `FUN = colMeans` for current behavior and `FUN = function(x) mean(x)` to calculate the mean for all the data. This information is also included in the help files. The option `xts.message.period.apply.mean = FALSE` suppresses the message. ([#124](joshuaulrich/xts#124)) * Fix error when `print.xts()` is called 'quote' or 'right' arguments. ([#401](joshuaulrich/xts#401)) * Fix `addPolygon()` so it renders when `observation.based = TRUE`. ([#403](joshuaulrich/xts#403)) * Print trailing zeros for index value with fractional seconds, so every index value has the same number of characters. ([#404](joshuaulrich/xts#404)) * Add ability to log scale the y-axis in `plot.xts()`. ([#103](joshuaulrich/xts#103)) * Actually change the underlying index values when 'tclass' is changed from a class with a timezone (e.g. POSIXct) to one without a timezone (e.g. Date). Add a warning when this happens, with a global option to always suppress the warning. ([#311](joshuaulrich/xts#311)). * Significantly refactor the internals of `plot.xts()`. ([#408](joshuaulrich/xts#408))
Allow for log scale of the y axis. This is supported by
base::plot
andPerformanceAnalytics::Chart.TimeSeries
so we should support it inplot.xts
as well. Thanks to Gei Lin for the feature request via R-SIG-Finance.The text was updated successfully, but these errors were encountered: