A new version 0.8.3 of
Rcpp
is now
CRAN and in
Debian.
It comes about three weeks after the
0.8.2
release. And even though we
promised to
concentrate on documentation, it contains a raft of new features:
- The addition of what we dub Rcpp sugar: some syntactic sugar
based on clever use of expression templates
that lets us write C++ expression as neatly and compactly as vectorised R expressions
(while getting C++ speed!!). More on that below.
- New classes Date and Datetime with internal representations just like
R's Date and POSIXct classes, plus vector versions DateVector and
DatetimeVector which behave just like STL vectors. With that, the new API
is now feature-complete compared to the older 'classic' API.
- Rcpp Modules (our 'not unlike Boost::Python' feature introduced in
version 0.8.1)
can now expose public data members
- A new API class InternalFunction which can expose C++ functions
even without R modules.
The main thing here is
Rcpp sugar for which we also have a new
(seventh !!) vignette
Rcpp-sugar.
As a quick example, consider this simple C++ function that takes two vectors
from R and creates a new one conditional on the relative values:
export "C" SEXP foo( SEXP xs, SEXP ys)
Rcpp::NumericVector x(xs), y(ys);
int n = x.size();
Rcpp::NumericVector res( n );
double xd = 0.0, yd = 0.0 ;
for( int i=0; i<n; i++)
xd = x[i];
yd = y[i];
if( xd < yd )
res[i] = xd * xd ;
else
res[i] = -( yd * yd);
return res ;
Now, if you use R, you really want to writes this more compactly. And now you
can, thanks to
Rcpp sugar:
extern "C" SEXP foo( SEXP xs, SEXP ys)
Rcpp::NumericVector x(xs), y(xs);
return ifelse( x < y, x*x, -(y*y));
Same great taste, but much less filling! More details are in the
Rcpp-sugar vignette.
Doug Bates is already a fan of this and is employing it in the
lme4a development
version of the well-known
lme4 package.
The full NEWS entry for this release follows below:
0.8.3 2010-06-27
o This release adds Rcpp sugar which brings (a subset of) the R syntax
into C++. This supports :
- binary operators : <,>,<=,>=,==,!= between R vectors
- arithmetic operators: +,-,*,/ between compatible R vectors
- several functions that are similar to the R function of the same name:
abs, all, any, ceiling, diff, exp, ifelse, is_na, lapply, pmin, pmax,
pow, sapply, seq_along, seq_len, sign
Simple examples :
// two numeric vector of the same size
NumericVector x ;
NumericVector y ;
NumericVector res = ifelse( x < y, x*x, -(y*y) ) ;
// sapply'ing a C++ function
double square( double x ) return x*x ;
NumericVector res = sapply( x, square ) ;
Rcpp sugar uses the technique of expression templates, pioneered by the
Blitz++ library and used in many libraries (Boost::uBlas, Armadillo).
Expression templates allow lazy evaluation of expressions, which
coupled with inlining generates very efficient code, very closely
approaching the performance of hand written loop code, and often
much more efficient than the equivalent (vectorized) R code.
Rcpp sugar is curently limited to vectors, future releases will
include support for matrices with sugar functions such as outer, etc ...
Rcpp sugar is documented in the Rcpp-sugar vignette, which contains
implementation details.
o New helper function so that "Rcpp?something" brings up Rcpp help
o Rcpp Modules can now expose public data members
o New classes Date, Datetime, DateVector and DatetimeVector with proper
'new' API integration such as as(), wrap(), iterators, ...
o The so-called classic API headers have been moved to a subdirectory
classic/ This should not affect client-code as only Rcpp.h was ever
included.
o RcppDate now has a constructor from SEXP as well
o RcppDateVector and RcppDatetimeVector get constructors from int
and both const / non-const operator(int i) functions
o New API class Rcpp::InternalFunction that can expose C++ functions
to R without modules. The function is exposed as an S4 object of
class C++Function
As always, even fuller details are in
Rcpp Changelog page and the
Rcpp page which also
leads to the downloads, the
browseable
doxygen docs and zip files of doxygen output for the standard formats.
A
local directory has
source and documentation too.
Questions, comments etc should go to the
rcpp-devel mailing list
off the
R-Forge page
I hate keeping track of money. Bank accounts, credit cards,
investing it's such a hassle. Hell, sometimes I even hate the fact
that money exists and needs to be dealt with in the first place. But I
admit that it's an easier system than bartering for everything.
In college I pretty much ignored most things financial. I rarely had
more money than I needed, and put little financial planning into
deciding what I could and could not spend money on besides, "I'm going
to make X dollars this summer," and, "think twice." But now that I
have a steady paycheck, it seems like a good idea to know where all my
money goes, so I can make better decisions about how I'm spending (and
saving) it.
But I've kept procrastinating starting to do so, because GUI programs
like Gnucash and
HomeBank seem like such a hassle. Their first
screen is dauntingly complex, and if you don't know much about
accounting it's scary and difficult to be asked to set up a big set of
accounts when first starting to use the program, without having any
prior experience with what you personally would find useful to keep
track of. Entering data through menus and dialogs is tedious and slow.
hledger (or
ledger, which came first) had
been appearing on my radar recently, not least because
Iron Blogger uses it). hledger
changed my opinion of accounting software. In about 15 minutes, using
only the sample transactions from
the manual, I was able to enter all my
assets and liabilities bank accounts, credit card, student loans,
money I've borrowed from people and never paid back though I said I
would, etc. And then, I could run 'hledger balance' and it would tell me
what sorts of things I had spent money on in the past few days, as far
back as I could bother looking up actual transactions for, rather than
entering a single transaction with a balance forward. Duuude, awesome!
I'm a geek. I like statistics and data about my life, as long as it's
not a huge pain to collect the data in the first place. More data means
more on which to base decisions, decisions which will then be freer from
the bias of what I find memorable enough to remember having done.
Here's what I like best about ledger:
Like 
Starting with GDB version 7, first appearing in Ubuntu with Karmic (Ubuntu 9.10), ASLR is 
Many people run Debian testing or unstable or some mix thereof. This works pretty well for a development system or a general desktop system if you know a bit about what you're doing (note: nonetheless officially not recommended). Sometimes you throw packages from 
... this version, or something not too far away from it, might actually stand a chance of getting into testing.
I've just uploaded grub2 1.98+20100702-1. The most significant set of changes in this release is that it switches 
At 
Now that disk space is cheap, it makes more and more sense to rip
music and store it in FLAC format. I used to use abcde to encode
directly to Ogg Vorbis, but a while back I decided to re-rip. The
disks in the server at home now have lots of hours of music in a nice
lossless format ready for easy playback on various machines on the
network.
However, that's not all I need. I also want to be able to create
Ogg Vorbis files for my own music player with limited space. And Jo's
Ipod won't play either .ogg or .flac (yay for closed devices!)... At
least I now have readily-available original quality music already on
hard disk, so I don't need to go and find CDs again. But I really
don't want to have to work through my directories of music by hand,
re-encoding individually.
My solution: write a filesystem that will read in the .flac files
and convert to .ogg or .mp3 on the fly. Now I can simply read the
files I want off the server (via sftp/rsync/whatever) and it will
create them for me!
So, fuse-music is my first attempt to do this. It's a simple perl
program that works using the perl FUSE bindings to generate a
pseudo-filesystem where a tree of .flac files will appear as a tree of
.ogg or .mp3 files instead. It's not wonderfully fast (as encoding
takes time), but it works. The only major difficulty I have at this
point is calculating the sizes of the output files: if I want rsync to
work reliably then the reported sizes need to be static and
correct. But it's not possible (AFAICS) to predict the size of an MP3
or Ogg Vorbis file without actually doing the encoding and
measuring the output size. So (ick!) that's what the code currently
does when necessary. It caches the output size in a perl hash DB so
the work is only needed once per file; ideally I'd like to not to have
to do this at all!
If this sounds interesting at all, feel free to have a look at and
play with the
code: 
Sometimes Wikipedia shows it even has a somewhat humorous side. My finding it funny may be a product of late night learning sessions and semi-random clicking-sprees, but still, worthy of a chuckle for those with the right (wrong?) inclinations.
If you do, then please read 
This blog post is a kind of followup of a previous blog post about 
Ooops:
You will probably think that I work for Verbatim. This is not true but I must admit that first-price CD-RW/CD-R seems to be very low quality and don't hold data in time. This is probably related to the chemical compounds of the CD. The failing Memorex CD-RW will end up in a trash and I will continue to use my 5 years old Verbatim CD-RW.
Dear reader, in order to find a way not to dump this failing CD-RW, do you know a way to make it to work?
What you should now about the failing CD-RW:
