R 3.6.0 is coming

A new version of R will be released on 2019-04-26. One significant change is the support of HCL colour definitios and palettes. Some defaults for colour palettes are changing (for the better) but small differences may visible in how plots look compared to earlier R versions. There is a post with a summary at the R blog, and a paper arXiv:1903.0649 describing why better palettes for data plotting can be defined.

Another significant change is that serialization format 3 becomes the default. As this format can be read only by R (>= 3.5.0) when sharing files created with save() or saveRDS(), and when sharing saved workspaces one needs to make sure the recipient is using a recent version of R or override this new default to create the files to be shared using the older serialization format 2.

All the packages I maintain should work correctly under R (= 3.6.0), but if you discover a problem, please, raise an issue at bitbucket within the repository of the affected package.

Benchmarking function sun_angles() [updated]

As far as I know there are in CRAN four R packages implementing the computations for the position of the sun and times of sunrise and sunset: ‘photobiology’, ‘fishmethods’, ‘solartime’ and ‘suncalc’.

The functions sun_angles() and day_night() from package ‘photobiology’ use Meeus equations as used by NOAA Solar Calculator https://www.esrl.noaa.gov/gmd/grad/solcalc/ which could be more precise than those in NOAA’s Excel worksheet which implement a simplified version of the Meeus equations especially for far into the past or far into the future calculations. The approximations based on Meuus equations are very good for years between 1800 and 2100 and results should still be sufficiently accurate for the range from -1000 to 3000 as long as the computation of Julian dates is correct. The Excel implementation is only valid for dates between 1901 and 2099 because of how Julian dates are computed in Excel.

Function astrocalc4r() from package ‘fishmethods’ also implements Meeus equations (the authors work at NOAA). Function computeSunPosition() from package ‘solartime’ uses unspecified equations and function getSunlightPosition() is an R interface to the ‘suncalc.js’ library, part of the ‘SunCalc.net’ project <http://suncalc.net>.

Function computeSunPosition() from package ‘solartime’ uses unspecified equations and function getSunlightPosition() is an R interface to the ‘suncalc.js’ library, part of the ‘SunCalc.net’ project <http://suncalc.net>.

UPDATED on 2019-04-24

I have noticed significant differences in the values returned by equivalent functions from different packages. Up to now the tests on the functions of my own package ‘photobiology’ have revealed only very small mismatches to the NOAA Solar Calculator. These small errors, noticeable for dates far from the present, were due to the use of base R’s julian() function, which is not designed to be precise enough for astronomical calculations. The code now in the repository at Bitbucket has been revised to use Meuus’ algorithm for the calculation of Julian days removing this source of  small discrepancies.

In contrast, while testing ‘photobiology’ against other packages, I seem to have found a bug in function astrocalc4r() from R package ‘fishmethods’.

A minimal example follows:

By only changing the hour passed as argument different times for sunrise, sunset and daylength are returned even though the day is the same. The differences are larger at high than at low latitudes. The maximum difference for the example above is 1/4 h for daylength. Comparison against the NOAA Solar Calculator shows even larger differences.

(The bug has been reported to the maintainer of package ‘fishmethods’.)

Continue reading

Yoctopuce modules: Introduction

Yoctopuce USB interface modules provide a very elegant solution to many different sensing and control problems, including measuring radiation. I have been interested in using them to acquire data directly from within R so as to be able to use the ‘r4photobiology’ suite of packages for real-time or near real time analysis and plotting of the acquired data.

The elegantly coded libraries supplied by Yoctopuce are available with interfaces in multiple computer programming and scripting languages. I have been trying different approaches to calling functions from these libraries in R scripts, but given the large number of functions needed to support the great variety of modules, writing an ad hoc interface for R was out of question. I first tried calling the command line version of the library functions from within R, but at least in Windows 10, the delay was too much and not consistent. Next I tried using the web server in the YoctoHub to send commands as http requests. This worked but it is a rather awkward approach, and not portable to accessing the modules directly through USB.

Two days ago, after reading about the ‘reticulate’ package I decided to test an approach similar to that I have used in package ‘rOmniDriver’ to access, with help from the ‘rJava’ package, Ocean Optics spectrometers through OmniDriver, a library written in Java. In the present case using ‘reticulate’ to access the Python version of the YoctoPuce library. It works extremely well, and the RStudio IDE provides in the editor even auto-completion and bubble help for functions and other objects defined in the Python library!

I have decided to describe here a few use cases for data acquisition or light source control using YoctoPuce models and R scripts. Most examples will be simple but useful, as they are real use cases rather than toy examples.

The YoctoPuce modules, hubs and the corresponding free libraries and the documentation are available at https://www.yoctopuce.com/. The ‘reticulate’ package is available through CRAN, and nicely formatted documentation can be found at https://rstudio.github.io/reticulate/. The first CRAN release of ‘reticulate’ appeared less than a year ago.

.


Package ‘patchwork’

Operators defined in package ‘patchwork’ can be used to combine multiple plots created with package ‘ggplot2’ or extensions to it, such as my own ‘ggpmisc’ and ‘ggspectra’. (The site ggplot2 extensions showcases at the moment more than 40 extensions to ‘ggplot2’.)

Package ‘patchwork’ has been developed by Thomas Lin Pedersen, and being relatively new, it is not yet in CRAN. It can be installed from the public Git repository at Github.

# install.packages("devtools")
devtools::install_github("thomasp85/patchwork")

The ‘ggplot2’ package provides a strong API for sequentially building up a plot, but does not concern itself with composition of multiple plots. ‘patchwork’ is a package that expands the API to allow for arbitrarily complex composition of plots by providing mathmatical operators for combining multiple plots. Other packages that address this need (but with a different approach) are ‘gridExtra’ and ‘cowplot’.

From the package’s DESCRIPTION.

Package ‘ggspectra’ provides function multiplot() for this purpose, but this function is minimalistic, with its most important handicap in its inability to independently align the plotting areas and axis labels of the composed plots.

An example using the operators / and & from ‘patchwork’ follows.

library(ggspectra)
library(patchwork)
p <- autoplot(sun.spct) / 
  autoplot(polyester.spct, range = c(280, 800)) / 
  autoplot(sun.spct * polyester.spct)
png("three-plots.png", height = 800, width = 600)
print(p) & theme_bw()
dev.off()