I'm trying to learn R on my own and a doing my best to follow along the 'R for Data Science' book from O'Reilly.
I've made it to an exercise where I want to create a binned boxplot plot of a subset of data from the 'Diamonds' data set in the 'Tidyverse' package. When I run the code in Bootcamp (Windows 10) I get the result I expect with vertical boxplots in the set bin width. When I run it in Mac OS the boxplot appears to be horizontal and I can't for the life of me figure out why! See my result here:
I'm sure there are folks who will say just work in Windows, but my stubborn 2016 Macbook Pro in Windows 10 mode doesn't like connecting to my external, wired monitor. The monitor works perfectly in Mac mode though, so I don't really care to sink any more time into figuring out why the monitor connection is so unreliable in Windows 10 mode.
Personal problems aside, below is the identical code I've been using in RStudio for Mac and Windows modes. Attached/linked above is the output plot I'm getting when I run RStudio in Mac. The boxplots should be oriented vertically. Hoping someone can help me understand how to fix this weird occurrence when running RStudio and R in Mac mode!
Sorry if referring to mac/windows as different 'modes of operation' is incorrect. That's the only way I know to convey the difference!
Here's my code:
library(tidyverse)
smaller <- diamonds %>% filter(carat<3) # just want to see carats less than 3
ggplot(data=smaller,mapping=aes(x=carat,y=price))+
geom_boxplot(mapping=aes(group=cut_width(carat,0.1)))
In R-devel under linux I get the same result.
It works, though, if you do:
library(tidyverse)
smaller <- diamonds %>% filter(carat<3) # just want to see carats less than 3
ggplot(smaller, aes(x=carat,y=price))+
geom_boxplot(aes(x=cut_width(carat, .1)))
Alternatively, you could just plot it like this:
library(tidyverse)
diamonds %>% filter(carat<3) %>%
mutate(carat = cut_width(carat,0.1)) %>%
ggplot(., aes(x=carat, y=price))+ geom_boxplot()+
theme(axis.text.x = element_text(angle = 90, hjust = 1))
Created on 2020-04-09 by the reprex package (v0.3.0)
Related
Saving the output of one of R's built-in examples for the filled.contour function to PDF:
pdf('test.pdf')
require("grDevices")
filled.contour(volcano, asp = 1)
dev.off()
produces a discretised result (see below). Is there any way to fix this? System info:
> sessionInfo()
R version 3.6.3 (2020-02-29)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04.1 LTS
Edit after the accepted answer:
The problem is actually reported in the documentation of the pdf function:
If you see problems with PDF output, do remember that the
problem is much more likely to be in your viewer than in R ...
Symptoms for which the viewer has been at fault are apparent
grids on image plots ...
Unfortunately the default viewers on most Linux and macOS
systems have these problems, and no obvious way to turn off
graphics anti-aliasing.
It's an odd place to document the problem because the subdivision into rectangular segments is clearly caused by filled.contour and not by pdf. Otherwise ggplot2's output would also suffer from the same issue.
That is likely a result of antialiasing: when you display the image, it draws squares one at a time. As they are being drawn, the edge is a mix of the square colours and the white background, so it is drawn lighter.
Unfortunately, this isn't something that's really under your control. It's the PDF previewer that is introducing the artifacts. See this page https://codedocean.wordpress.com/2014/02/03/anti-aliasing-and-image-plots/ for a discussion.
The recommendation there worked for me: use the png() device with type = "cairo". This gives bitmapped output rather than the vector output of a pdf().
png('test.png',type="cairo")
filled.contour(volcano, asp = 1)
dev.off()
Edited to add:
I don't think you can do better with filled.contour, but if you are willing to switch to ggplot2 graphics you can. When it draws filled contours it appears to do it using polygons, not the image style plot that filled.contour uses. This still shows the same antialiasing bugs in the previewer, but now the lines appear along the borders between colours, which is much less irritating. For example:
df <- data.frame(x = as.numeric(row(volcano)-1)/(nrow(volcano)-1),
y = as.numeric(col(volcano)-1)/(ncol(volcano)-1),
z = as.numeric(volcano))
pdf('test.pdf')
library(ggplot2)
ggplot(df, aes(x=x, y=y, z=z)) +
geom_contour_filled()
dev.off()
I don't know how to get the same palette as filled.contour uses, i.e. function(n) hcl.colors(n, "YlOrRd", rev = TRUE). Maybe someone else can show us in a comment.
I am trying to visualize several hours of neuronal recordings sampled at 500Hz using R in Ubuntu 16.04. Simply I want to have a 2D plot that shows a value (voltage) over time. Its important for to have the plot in an interactive way. I need to have an overall look, compare different times and zoom in and out, therefor I don't want to split my data into different parts and visualize them separately.(Also I can not use the normal R plot since zooming there is a pain and sometimes impossible) What I came up with so far is to use "plot_ly" with scatterrgl type to get started and I could successfully plot 300'000 data points. But that is the limit I can get so far. Above this amount of data the whole R software freezes and exits. The frustrating part is that this can be done easily in MATLAB and with R it seems impossible. Is there any alternative to plot_ly for plotting large data in R?
You might try the dygraph package, working fine here with 500k points:
library(dygraphs)
my_data = data.frame(x = 1:500000, y = rnorm(500000))
dygraph(my_data) %>% dyRangeSelector()
I'm running R version 3.0.1 and ggplot2 version 0.9.3.1 on a Windows machine and getting aberrant behavior from color bar legends -- the legend labels appear but the color bar mysteriously does not.
For example, if I run the following code:
d <- data.frame(x=rnorm(100), y=rnorm(100), z=rnorm(100))
ggplot(d, aes(x, y, color=z)) + geom_point()
I get this plot:
whereas on my other machine (a Mac running R version 2.15.2 and ggplot 0.9.3.1) the same code gives me this:
The behavior seems to apply only to color bars for continuous numerical variables -- legends for discrete factors appear as expected. I've tried reinstalling ggplot2. Anybody have thoughts on what's going on here? Thanks!
I found the problem, and a working solution, here. It's an issue with color rendering when accessing a server via Remote Desktop, and can be fixed in host settings.
Why lines in a chart generated from ggplot2 on Mac looks so smooth and round, but on Windows they look so sharp and edgy. Is there any option to fix that on Windows instead of going to the Apple Store?
For example, chart generated on Mac:
and a chart generated on Windows:
Edit:
Due to #thestatnoob answer, this is a plot generated from iris dataset on R 3.0.2, RStudio 0.99.486, chart resolution: 640x480.
data(iris)
library(ggplot2)
ggplot(data = iris) +
geom_density(aes(x = Sepal.Length, y = ..scaled.., fill = Species), alpha = 0.5)
Anti-aliasing options from the Cairo package in R solved the issue
This might be due to a rendering error rather than anything else. R graphics do look more low res and "edgy". Try plotting the exact same dataset in both OS's with the same settings, e.g. PNG/PS/PDF with identical resolution. If it turns out that the Windows plot doesn't look great, an alternative solution would be to:
Use RStudio, which is a GUI for R and produces "smooth" graphics, even on Windows
Use R in a MS PowerShell/command prompt
While SO is not usually used for help with bugs, this one shows particularly simple and particularly annoying behavior. If you are a ggplot2 user, you can reproduce it in 10 seconds or less.
As this GitHub issue: ggplot_gtable creates blank display says, the following code
library(ggplot2)
stat = qplot(Sepal.Length, Petal.Length, data = iris, color = Species)
ggplot_gtable(ggplot_build(stat))
will produce a blank device. Note that since ggplot2 is a graphics library, some commands can bring up a graphics device to show the relevant plot. Specifically, just running ggplot_build(stat) will bring up a plot. But that doesn't explain this behaviour.
I'm not sure how to debug this (print statements don't really seem appropriate or useful), and the ggplot2 development community seems to be on vacation or something, so if any experienced R user can offer suggestions on how to debug this effectively, I would appreciate it. This is a trivial but incredibly annoying bug. Every time I run code which looks like the snippet, it brings up a blank device which the display switches focus to, and so I have to click it away before I can continue.
It is possible that I'm doing something horribly wrong and am the only person who can reproduce this bug. It is also possible, for some reason I can't imagine, that this is normal behavior. If you think either of these things are true, please let me know.
I'm using ggplot2 0.9.3.1 (latest release) on Debian squeeze.
Some grid grobs have units that can only be resolved at drawing time, that is to say once a device window is open. This is the case of text grobs, for instance, as their size can depend (in the most general case) of the cex and fontsize arguments of the parent(s) viewports (which can be nested, etc.)
library(grid)
widthDetails(textGrob("hi"))
The current version of ggplot2 appears to use widthDetails in the code to build the legend grobs (guides_build function). It is conceivable that this could be replaced by grobWidth, unless the grob size is too convoluted.
I wonder if it is related to this thread from 3 years ago on R-Help with this workaround from #G.Grothendieck (copied material follows)
https://stat.ethz.ch/pipermail/r-help/2010-December/263754.html
library(lattice)
library(zoo)
df <- data.frame(y = matrix(rnorm(24), nrow = 6), x = 1:6)
xyplot(zoo(df[1:4], df$x), type = "p")
plot.object <- xyplot(zoo(df[1:4], df$x), type = "p")
# problem: a Quartz device is opened (on Mac OS X 10.6)
Grothendieck wrote in response:
This also opens up a window on Windows. It occurs within lattice
when lattice issues a trellis.par.get . A workaround would be to open
a device directed to null. On Windows this would work. I assume if
you use "/dev/null" it would work on your machine.
png("NUL")
plot.object <- ...
dev.off()
I am still having this issue with R 3.6.1 in 2019.
My lack of reputation doesn't allow me to comment. So I am writing yet another answer:
Things become a bit tricky if your plot uses non-standard fonts, say
library (ggplot2)
stat = qplot(Sepal.Length, Petal.Length, data = iris, color = Species) +
theme(text = element_text (family="DejaVu Sans"))
As was explained in the answer by baptiste, the output device is needed in order to determine some text dimensions. With the non-standard font, however, you need the appropriate output device. If you just use a pdf(file=NULL) as baptiste said, you get the dimensions wrong (and a warning that 'DejaVu Sans' was substituted by another font which is responsible for the false dimensions). In order to resolve this, I had to open an output device that is able to render the non-standard font (with a temporary file, say):
cairo_pdf (tempfile (fileext=".pdf"))
grob = ggplot_gtable (ggplot_build (stat))
dummy = dev.off ()
Hope this information is useful.
Problem seems to be caused by "color = Species".
If replaced by "group = Species", then no more blank display device.