The Google Open Source Programs Office sponsored me to create the new int64 package that has been released to CRAN a few days ago. The package has been mentionned in an article in the open source blog from Google.

The package defines classes int64 and uint64 that represent signed and unsigned 64 bit integer vectors. The package also allows conversion of several types (integer, numeric, character, logical) to 64 bit integer vectors, arithmetic operations as well as other standard group generic functions, and reading 64 bit integer vectors as a data.frame column using int64 or uint64 as the colClasses argument.

The package has a vignette that details its features, several examples are given in the usual help files. Once again, I've used RUnit for quality insurance about the package code

int64 has been developped so that 64 bit integer vectors are represented using only R data structures, i.e data is not represented as external pointers to some C++ object. Instead, each 64 bit integer is represented as a couple of regular 32 bit integers, each of them carrying half the bits of the underlying 64 bit integer. This was a choice by design so that 64 bit integer vectors can be serialized and used as data frame columns.

The package contains C++ headers that third party packages can used (via LinkingTo: int64) to use the C++ internals. This allows creation and manipulation of the objects in C++. The internals will be documented in another vignette for package developpers who wish to use the internals. For the moment, the main entry point is the C++ template class LongVector.

I'm particularly proud that Google trusted me to sponsor the development of int64. The next versions of packages Rcpp and RProtoBuf take advantage of the facilities of int64, e.g. Rcpp gains wrapping of C++ containers of 64 bit integers as R objects of classes int64 and uint64 and RProtoBuf improves handling of 64 bit integers in protobuf messages. More on this later

I played around with reverse dependencies of Rcpp. At the moment, 44 packages depend on Rcpp and the number goes up to 53 when counting recusive reverse dependencies.

I've used graphviz for the representation of the directed graph

Here is the code I've used to generate the dot file:

Pierre Jacob and Robin Ryder (from Paris-Dauphine, CREST, and Statisfaction) have just arXived (and submitted to the Annals of Applied Probability) a neat result on the Wang-Landau algorithm. (This algorithm, which modifies the target in a sort of reweighted partioned sampling to achieve faster convergence, has always been perplexing to me.)  They show that some variations of the Wang-Landau algorithm meet the flat histogram criterion in finite time, and, just as importantly that other variations do not reach this criterion. The proof uses elegant Markov chain arguments and I hope the paper makes it through, as there are very few theoretical results on this algorithm. (Pierre also wrote recently a paper with Luke Bornn, Arnaud Doucet, and Pierre Del Moral, on An Adaptive Interacting Wang-Landau Algorithm for Automatic Density Exploration last week, with an associated R package. Not yet on CRAN.)

Sooner on later, every useR will manage to exhaust R’s built-in capabilities and land on CRAN looking for his dreamed needle in a haystack of 3k+ contributed packages. Probably most of you already know stuff like Task Views or rseek which make finding something relevant a bit easier than digging the full list or googling, however all methods will eventually lead to a CRAN package page like this:

Sample CRAN package page

Ok, but what’s the problem? We have basic info here, sources, manuals, builds, dependencies… Well, let’s compare this to some modern application repositories like Android Market, Mozilla Add-ons or AppStore; we’ll immediately notice lack of any form of user feedback, neither as ratings nor reviews. And such stuff may be quite handy — imagine you have for instance found three packages doing certain thing; surely one of them will be fastest, one least bloated, one most functional and one will best integrate with the rest of your code, but you probably won’t be able to deduce this easily from manuals.  Or you’ve found a package from 2003 and you don’t really want to check whether it is an abandoned code dependent on a bunch of obsolete quirks or just a solid code that just didn’t require any modifications. Or you have been using foozifier for years not knowing that bartools’ functionWithConfusingName does the same 50 times faster using 1/1000 of RAM. Or you just thought you can’t baz in R, yet the only problem was that the bazzing package author thought it was called wizzing.

Moreover, this is also useful for package authors — comment is much easier and more reusable way of leaving feedback than e-mail, so you can count on more reports and thus catch more bugs and gather more good feature ideas.

What’s worse with this story is that this is more-less already here; it is called Crantastic and works pretty well, not counting the fact that it would certainly benefit from some more traffic — so, go there and check if you are registered user of all packages you’ve installed and start contributing; it really comes back!

The raster package defines classes and methods for spatial raster data access and manipulation. The new rasterVis package complements raster providing a set of methods for enhanced visualization and interaction. It is now at CRAN.

Several examples can be found at the webpage of the project.

The version 0.24 of solaR is at CRAN and R-Forge. Some days before the 0.23 version was uploaded, but I had to make a quick fix to readMAPA: the url of http://www.mapa.es/siar has been changed to http://www.marm.es/siar. Moreover, this function has been renamed to readSIAR, although it is still available as readMAPA. Consequently the mode modeRad‘mapa’= is now deprecated and renamed to modeRad‘siar’=.

Besides, the arguments prom, mapa, bd and bdI of calcG0, calcGef, prodGCPV and prodPVPS have been unified in the new dataRad argument. Those arguments are now deprecated although still available.

The previous solaR 0.23 fixed a bug in fInclin when horizBright=FALSE, and:

• Four sun-geometry methods are now available.
• ThzS, AlS and AzS are not set to NA outside sunrise-sunset period.
• fInclin and calcGef gain a new argument, HCPV, for High Concentrated Photovoltaics.
• A bug in fSolI and fTheta when lat=0 has been corrected.

Last, the vignette has been reformated and now uses the memoir class of LaTeX. It is available here.

Cameron and I are pleased to announce version 0.6.0 of the tikzDevice
package which should be available shortly at your local CRAN mirror!
The tikzDevice makes it possible to export R graphics as LaTeX code
that can be included in other documents or compiled into stand alone
figures. The full power of LaTeX is available for typesetting text and
mathematical expressions inside figures produced using the tikzDevice.

Over 80 commits have occurred since the release of 0.5.3 which have
added exciting new features to the device. The most important addition
is 0.6.0 is that the XeLaTeX compiler is officially supported.
Compared to the PdfTeX engine, XeTeX has native support for Unicode
which we hope will make the package more useful for producing graphics
that contain text in languages outside the ASCII symbol table. 0.6.0
also provides support for including raster imagry in graphics and
polypath drawing which catches the `tikz()` graphics device up with
recent developments in the R graphics engine.

There have also been some significant changes under the hood. Our
package has migrated to using Roxygen for function documentation—a
move that was greatly facilitated by the Rd2roxygen package written by
Yihui Xie and Hadley Wickham. Our homebrewed testsuite has also been
re-written on top of Hadley’s excellent test_that package.  Many
thanks to the R community for writing great tools to support package
development!

The full changelog is appended to this email. For a detailed diff of
changes since 0.5.3, see:
https://github.com/Sharpie/RTikZDevice/compare/0.5.3…master

With 80 commits, it is likely we introduced some exciting new bugs.
Bug reports are welcomed at the GitHub issue tracker:

https://github.com/Sharpie/RTikZDevice/issues

The tikzDevice also has a mailing list provided by R-Forge:

tikzdevice-bugs @at@ lists.r-forge.r-project.org

Which is also accessible via Google Groups:

https://groups.google.com/forum/#!forum/tikzdevice

A rough roadmap for future package development can be found at:

https://github.com/Sharpie/RTikZDevice/wiki/Roadmap

Commentary and discussion is welcomed in the mailing list, patches
containing bugfixes or features are welcomed on the issue tracker.

-Charlie

—

### Version: 0.6.1
Released: 4-14-2011
—
#### Bug Fixes
- Fixed a bug where `tikz` was not applying background color to the plot
canvas.
- Fixed a Vignette bug caused by an incorrect merge that was breaking the CRAN
build.

—
### Version: 0.6.0
—
#### New Features
- Unicode Support!!!! XeLaTeX may now be used calculate metrics and widths for
Unicode characters. PdfLaTeX remains the default LaTeX compiler, but this may
be changed by setting the global option `tikzDefaultEngine` to `xetex`.

- New global option `tikzXelatexPackages` which contains packages necessary to
use unicode characters with xelatex.  Specifically, the fontspec and the
xunicode packages as well as the xetex option to the preview package.

- New global option `tikzUnicodeMetricPackages` which contains the packages
necessary to calculate metrics for multibyte unicode characters with xelatex.

- New function anyMultibyteUTF8Characters() which will check if the given
string contains any multibyte unicode characters.  Exposed in the package
namespace since it is general and may be useful in other applications.

- The TikZ device now fully supports the `Raster` graphics primitive that was
added in R 2.11.0 and no longer throws “not implemented” warnings when this
functionality is used. This is accompilshed by writing raster images to PNG
files, `Rplots_ras#.png`, which are then included in the main TeX file
`Rplots.tex`.

- The TikZ device now fully supports the `polypath` graphics primitive that was
added in R 2.12.0 and no longer throws “not implemented” warnings when this
functionality is used.

#### Bug Fixes

- Fixed a bug where the `lwd` parameter used to control line widths was
declared by tikzDevice to be of type `int` when it is actually a `double`.
This was causing line widths to be ignored or miscalculated. Many thanks to
Baptiste Auguie for reporting this issue.

#### Depreciation Notices

- Versions of R < 2.11.0 are no longer supported due to lack of required
functions for handling Unicode strings.

#### Behind the Scenes

- New Makefile for executing common development tasks.

- Package documentation now handled by `roxygen`.  Many thanks to Hadley
Wickham and Yihui Xie for the `Rd2roxygen` package which facilitated this
switch.

- Package test suite completely overhauled and now based on Hadley Wickham’s
`test_that` unit testing framework.

Getting more into mixed models, I’ve been playing around with both nlme::lme and lme4::lmer. http://tolstoy.newcastle.edu.au/R/e2/help/06/10/3345.html was quite a good post at explaining the differences, which from what I gather is largely performance based when using crossed or partially crossed models.

In the models I am tinkering with at the moment I am noticing differences in the standard deviations for the coefficients, which is alarming, but I’ll continue to dig around.