This note is a comment on some of the timings shared in the dplyr-0.8.0 pre-release announcement.
The original published timings were as follows:
With performance metrics: measurements are marketing. So let’s dig in the above a bit.
Our group has done a lot of work with non-standard calling conventions in
Our tools work hard to eliminate non-standard calling (as is the purpose of
wrapr::let()), or at least make it cleaner and more controllable (as is done in the wrapr dot pipe). And even so, we still get surprised by some of the side-effects and mal-consequences of the over-use of non-standard calling conventions in
Please read on for a recent example.
This note is just a quick follow-up to our last note on correcting the bias in estimated standard deviations for binomial experiments.
This note is about attempting to remove the bias brought in by using sample standard deviation estimates to estimate an unknown true standard deviation of a population. We establish there is a bias, concentrate on why it is not important to remove it for reasonable sized samples, and (despite that) give a very complete bias management solution.
In August of 2003 Thomas Lumley added
R 1.8.1. This gave
R users an explicit Lisp-style quasiquotation capability.
bquote() and quasiquotation are actually quite powerful. Professor Thomas Lumley should get, and should continue to receive, a lot of credit and thanks for introducing the concept into
bquote() is already powerful enough to build a version of
dplyr 0.5.0 with quasiquotation semantics quite close (from a user perspective) to what is now claimed in
Let’s take a look at that.
This type of cooperation and user choice is what keeps the
R community vital. Please encourage it. (Heck, please insist on it!)
Let’s take this as an excuse to take a quick look at what happens when we try a task in both systems.
Our interference from then environment issue was a bit subtle. But there are variations that can be a bit more insidious.
Please consider the following.
"One of the most useful properties of expressions is that called by Quine referential transparency. In essence this means that if we wish to find the value of an expression which contains a sub-expression, the only thing we need to know about the sub-expression is its value."
Christopher Strachey, "Fundamental Concepts in Programming Languages", Higher-Order and Symbolic Computation, 13, 1149, 2000, Kluwer Academic Publishers (lecture notes written by Christopher Strachey for the International Summer School in Computer Programming at Copenhagen in August, 1967).
Please read on for discussion of a subtle bug shared by a few popular non-standard evaluation interfaces.