[Rd] Providing R binaries compiled against a multithreaded BLAS like Intel MKL by default?
threads equal to the nr of physical cores... I was wondering if any of you would have any thoughts about which of these two methods would be most recommended? After restarting RStudio we can check that it works, e.g. using a small SVD benchmark on my Intel Core i7-4700HQ 2.4GHz 4 core/8 thread laptop: getMKLthreads() 4 # Singular Value Decomposition m <- 1 n <- 2000 A <- matrix (runif (m*n),m,n) system.time (S <- svd (A,nu=0,nv=0)) user system elapsed 15.200.644.17 > sessionInfo() R version 3.6.2 (2019-12-12) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 10 x64 (build 18362) Matrix products: default locale: [1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252 LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] RevoUtils_11.0.3 RevoUtilsMath_11.0.0 loaded via a namespace (and not attached): [1] compiler_3.6.2 tools_3.6.2 That same benchmark without Intel MKL installed ran at user system elapsed 35.110.10 35.21 Unfortunately calling the RevoUtilsMath::setMKLthreads() function crashes RStudio (this was already the case in MRO 3.5.3 as well though), but it does work OK when called from the R console. If any of you would happen to know of a better non-crashing alternative, please let me know! In general I think it would be really handy if R binaries, compiled against some optimized BLAS like Intel MKL or OpenBlas would be readily available on all systems, including Windows, as this partly determines how one would develop packages (e.g. veering towards the use of RcppEigen, which uses multithreaded matrix algebra on all systems independently of the BLAS one has installed, or RcppArmadillo, which uses whatever BLAS one has compiled R against, but which is only a good option then if R versions with multithreaded BLAS are readily available on all systems). Or even, if it could be made possible to switch the type of BLAS used also on Windows, as is possible on Ubuntu... Any thoughts most welcome! cheers & happy holidays, Tom Prof. Tom Wenseleers Laboratory of Socioecology and Social Evolution Dept. of Biology University of Leuven Naamsestraat 59 3000 Leuven Belgium https://bio.kuleuven.be/ento/wenseleers/twenseleers.htm [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Support for transparency in metafile export & support for export to Powerpoint
Dear all, For vector-based output, PDF export of R graphs works well, but unfortunately Office on Windows provide poor support for PDF and importing & exporting to other formats using Inkscape can be buggy. Enhanced metafile export in turn does not support transparency (also not in package devEMF - are there any plans to support this perhaps in the future?). And rasterising graphs to a PNG I often find dissatisfactory, as vector-based graphs should ideally stay in vector format, especially when it comes to axes and axes labels etc. So this means that by default, there are rather few good options left to export all those beautiful R graphs in high-quality vector format. I recently discovered that package ReporteRs provides near-perfect export of R graphs in fully editable vector format to Powerpoint or Word using the Office native DrawingML format, with full upport for transparency, in a much better quality than what is provided by default in grDevices. This made me wonder if exporting a graph to Powerpoint could perhaps also be supported in grDevices? In ReporteRs the code e.g. to export a ggplot would be library( ReporteRs ) require( ggplot2 ) mydoc = pptx( ) mydoc = addSlide( mydoc, slide.layout = "Title and Content" ) mydoc = addTitle( mydoc, "Plot examples" ) myplot = qplot(Sepal.Length, Petal.Length , data = iris, color = Species , size = Petal.Width, alpha = I(0.7) ) mydoc = addPlot( mydoc, function( ) print( myplot ), vector.graphic=TRUE) writeDoc( mydoc, file = "test plot.pptx" ) I was thinking it could be nice though to provide this capability also in base R - so that e.g. windows() plot(...) File...Save as...would also provide an option to save as Powerpoint, with options for the width, height, font and font size used for export, or that there would be an extra command dev.copy2ppt or a combination of ppt ( ) and dev.off() to export to Powerpoint, using the code available in ReporteRs. Especially for use in the classroom this would be super handy, as windows users are now pretty much tied to using bitmap-based PNG, thereby limiting the ease with which the final layout of R graphs can be edited ! best regards, Tom Wenseleers Prof Tom Wenseleers University of Leuven Naamsestraat 59 3000 Leuven, Belgium https://bio.kuleuven.be/ento/wenseleers/twenseleers.htm [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Support for transparency in metafile export & support for export to Powerpoint
Dear all,
Further to my previous message I now made a one-line convencience function to
export your currently active graphics window/plot to either Word or Powerpoint
in Office-native vector-based DrawingML format using either
export2ppt(file="plot.pptx")
or
export2doc(file="plot.docx") :
see
http://stackoverflow.com/questions/31212659/r-function-to-capture-r-plot-in-current-graphics-device-and-export-it-to-powerp/31221813#31221813
(analogous in syntax to function dev.copy2pdf in grDevices)
The code of the function is:
export2office = function(file = "plot", type="PPT", scaling = 90, aspectr=NULL,
vector.graphic = TRUE, fontname = "Arial", pointsize=20) {
file=sub("^(.*)[.].*", "\\1", file)
if (type=="PPT"|type=="PPTX") {ext=".pptx";type="PPT"} else
{ext=".docx";type="DOC"}
require(ReporteRs)
captureplot = function() {p = invisible(recordPlot())
dev.copy()
return(p)}
p = captureplot()
plotsize = dev.size()
plotaspectr = plotsize[[1]]/plotsize[[2]]
if (!is.null(aspectr)) plotaspectr=aspectr
myplot=function(pl=p) print(pl)
if (type=="PPT") {doc = pptx();doc = addSlide(doc, slide.layout =
"Blank");pagesize = dim(doc)$slide.dim} else {doc = docx();pagesize =
dim(doc)$page-dim(doc)$margins[c(4,3)]}
pageaspectr = pagesize["width"]/pagesize["height"]
if (pageaspectr>plotaspectr) {xf=plotaspectr/pageaspectr;yf=1} else
{xf=1;yf=pageaspectr/plotaspectr}
w = (scaling/100)*pagesize["width"]*xf;
h = (scaling/100)*pagesize["height"]*yf
if (type=="PPT") {doc = addPlot( doc, myplot, vector.graphic =
vector.graphic, fontname = fontname, pointsize = pointsize,
offx = (pagesize["width"]-w)/2, offy =
(pagesize["height"]-h)/2,
width = w, height = h) } else {doc = addPlot( doc, myplot,
vector.graphic = vector.graphic, fontname = fontname, pointsize = pointsize,
width = w,
height = h)}
writeDoc( doc, paste0(file,ext) )
}
export2ppt = function(type="PPT", ...) export2office(type=type,...)
export2doc = function(type="DOC", ...) export2office(type=type,...)
# Examples:
require(ggplot2)
qplot(Sepal.Length, Petal.Length, data = iris, color = Species, size =
Petal.Width, alpha = I(0.7))
export2ppt(file="plot.pptx")
export2ppt(file="plot.pptx",aspectr=1.7,fontname="Times New Roman")
heatmap(as.matrix(eurodist))
export2ppt(file="heatmap.pptx")
In Powerpoint you can then right click on the graph and Ungroup it, thereby
allowing you to make minor changes to the layout if need be, before saving it
as PDF from PPT. The quality is much better than what you get if you try to do
the editing in the PDF version using Inkscape. It works with ggplot2 and
lattice plots as well as base R plots and also fully supports transparency
(unlike e.g. EPS or EMF export in R - EMF in the meantime I found out does not
support transparency at all, and can only deal with it by rasterizing all
semi-tranparent graphics elements).
Given the widespread use of Office/LibreOffice/OpenOffice I think it would be
very handy if this kind of functionality were provided as part of base R at one
stage or another (as would Excel import and export, for that matter). So if
anyone on this list thinks it would be a good idea to incorporate this function
in grDevices or something, please do! (would be handy e.g. if powerpoint export
also showed in the File...Save as... interactive graphics devices, like
windows() )
Otherwise I'll be in touch with the ReporteRs author to try to convince him to
add it there.
cheers,
Tom
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Support for high DPI 4K screens
I was recently testing R and RStudio on a high dpi 4K monitor under Windows and noticed that the plot window cannot be scaled or zoomed without affecting the relative sizing of all plot elements (line widths, font sizes, legend spacing etc). RStudio seems to try to overcome this by enabling dpi scaling for the plot window on high dpi screens, but this results in really fuzzy text and graphics (e.g. causing colour fringing when using Cleartype). This made me wonder if the assumed dpi of the screen could perhaps be set using some global option, so that all graphics could be made to scale their contents in a correct way, without affecting the size relative to the size of the plot window (I think now it is always assumed to be 72 dpi)? I recently asked a related question re how to scale R graphics proportionally to the size of the plot window on Stackoverflow, http://stackoverflow.com/questions/31381066/r-function-to-make-plot-symbols-line-widths-and-text-in-ggplot2-lattice-and-b/32412384#32412384 but nobody seemed to be able to come up with a good answer/solution. This made me wonder if there could perhaps be some low-level solution to this? best regards, Tom [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Default location where packages are stored under Windows
With a default installation of R on Windows platforms, packages are stored under Program Files/R/R-3.X.X/library. This often causes permission problems, as this directory is always read only by default, requiring the user to either change permissions for that directory or to change the directory where packages are stored later on option wise through modification of .libPaths in .Rprofile. For most users I imagine this is slightly annoying, having to do this over and over. I was just wondering if the default directory to store packages on Windows platforms could therefore not better be made the personal library folder, Users/Username/Documents/R/win-library/3.XX/, or perhaps even better, Users/All Users/Documents/R/win-library/3.XX/, so that downloaded packages are available for all users ? [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Default location where packages are stored under Windows
Hi Jeroen, Yes I noticed this - but with students etc it often still causes confusion, and I was just wondering if it would not be better to make it the default during installation of a new R version, as opposed to only changing over the first time you try to install a package and R noticing that the default directory is not writable... cheers, Tom From: Jeroen Ooms [jeroeno...@gmail.com] Sent: 05 September 2015 14:45 To: Tom Wenseleers Cc: r-devel@r-project.org Subject: Re: [Rd] Default location where packages are stored under Windows On Sat, Sep 5, 2015 at 2:05 PM, Tom Wenseleers wrote: > I was just wondering if the default directory to store packages on Windows > platforms could therefore not better be made the personal library folder, > Users/Username/Documents/R/win-library/3.XX/ I think this is already the case? The first time you try to install a package as non-admin, you will be prompted with a message that the global library is not writable and if you want to create a user library. Once the user library exists, R will make that the default by putting it on the head of .libPaths() at the start of every R session. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Support for high DPI 4K screens
Hi Brian, Thanks for your message. Just to clarify - I've seen this problem on Windows both under Windows 8.1 and Windows 10, and the RStudio people were also aware of the problem (it's also a known problem on Linux btw, https://support.rstudio.com/hc/communities/public/questions/201913407-RStudioGD-option-to-set-screen-DPI?locale=en-us )... I gathered that part of the problem is the difficulty to scale a graphics window without affecting the relative scaling of the plot elements (text, line widths etc), which is why in RStudio they now rely on the inbuilt dpi scaling of Windows, which merely upscales the low res image by a factor of 2 if you set the zoom factor to 2 (resulting in a blurry plot window). Not using dpi scaling or zooming is also an option, but then one typically has to make one's plot window larger, thereby requiring one to adjust the scaling of all plot elements, e.g. in ggplot2, ie text sizes, plot symbol sizes, line sizes etc due to the fact that all those sizes are ! specified as absolute sizes... Other problem is that without zooming the default text sizes of all standard ggplot2 themes e.g. are much too small. This made me wonder if in some future edition such problems could not be solved by allowing graphics to scale proportionally, maybe with some optional zoom factor or something, or by being able to specify how many ppi one's screen is? Many people I know that use R would also love to be able to maximize their plot window without it affecting the scaling of all the text etc in the graph. Right now one is pretty much tied to exporting as PDF and then viewing that full screen... Or am I overlooking something? I am just asking this question here as I have a feeling that a solution to this problem would probably be most conveniently addressed somewhere at a low level in grDevices or grid... best regards, Tom From: R-devel [r-devel-boun...@r-project.org] on behalf of Brian G. Peterson [br...@braverock.com] Sent: 05 September 2015 15:56 To: r-devel@r-project.org Subject: Re: [Rd] Support for high DPI 4K screens On 09/05/2015 06:46 AM, Tom Wenseleers wrote: > I was recently testing R and RStudio on a high dpi 4K monitor under > Windows and noticed that the plot window cannot be scaled or zoomed > without affecting the relative sizing of all plot elements (line > widths, font sizes, legend spacing etc). RStudio seems to try to > overcome this by enabling dpi scaling for the plot window on high dpi > screens, but this results in really fuzzy text and graphics (e.g. > causing colour fringing when using Cleartype). This made me wonder if > the assumed dpi of the screen could perhaps be set using some global > option, so that all graphics could be made to scale their contents in > a correct way, without affecting the size relative to the size of the > plot window (I think now it is always assumed to be 72 dpi)? I > recently asked a related question re how to scale R graphics > proportionally to the size of the plot window on Stackoverflow, > http://stackoverflow.com/questions/31381066/r-function-to-make-plot-symbols-line-widths-and-text-in-ggplot2-lattice-and-b/32412384#32412384 > but nobody seemed to be able to come up with a good answer/solution. > This made me wonder if there could perhaps be some low-level solution > to this? R-help or RStudio support seem more appropriate for this? 'The correct way' is a very subjective term. I really don't want R or any other application or operating system assuming that I bought a whole bunch of expensive 4k displays for smoother lines. I bought them for pixel count. We routinely use R and RStudio on 4k displays, I'm doing so right now. The problem you are likely having is an old version of Windows, and has little or nothing to do with R or RStudio. Windows 8 and higher have extensive application scaling support. Of course, Macs and Linux have good scaling support also, and you get better R performance on Macs and Linux as well. Even on Windows, we typically run almost all our applications on 4k displays at native resolution, and only change title bar and menu scaling based on distance to the screen. We also use all those pixels. Your use cases, of course, may vary. Which, in part, is why R has so much control over the types of graphic devices you create, and how you choose to control them. Regards, Brian -- Brian G. Peterson http://braverock.com/brian/ Ph: 773-459-4973 IM: bgpbraverock __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
