`R`

is a powerful and efficient programming language for statistics, modeling, and data mining. Here I want to provide a quick note on the question *"How do I get the name of a function in R?"*.

Consider the scenario where you write a function `myFun`

in the form of ` <- function(f) { … }`

that accepts another function `f`

as parameter and computes something. Maybe your computation takes a lot of time, so you want to output some logging information which contains the name of the function `f`

as well, so the reader can see what is going on. Or maybe you want to generate a report with the results from several functions, so you want the "function names" to be the section titles of the report. Getting the name of a function (or any object) in `R`

is actually quite tricky. Here I discuss a working approach.

Today, we published the first version of a new `R`

package at github.com/thomasWeise/dataTransformeR for normalizing and transforming numerical data.

When we fit models to data, we often do not want to use the raw data as-is. Instead, we usually want to fit models to normalized or log-scaled versions of the data. If all data elements are in `[0,1]`

, this makes it easier to pick initial parameter values for models. If there are exponential relationships present in data sets, we may want to get rid of them by log-scaling the data. This means that, after the models have been fitted, we need to transform the model back by applying the inverse of the data transformation to the model.

This package uses our functionComposeR package to construct and apply such bijective transformations. The core of this package are the `Transformation`

and `TransformedData`

S4 classes and the routines to construct instances of them.

Today, we published the first version of a new `R`

package at github.com/thomasWeise/functionComposeR for composing and canonicalizing functions. When we combine functions in `R`

in the form of `g(f(x))`

, we have the problem that the result is rarely human readable. This results from two problems. The first problem is that variables inside the function are evaluated in the environment of the function and even if they are constants, they will remain as variables. Thus, when printing a function `f(x)`

, I may sometimes something like a `k*x`

inside, but may not know the value of `k`

, even though it may be perfectly known in the function's environment and a constant. The second problem is that this also applies to nested functions, so there may be something like `f=function(x) x+g(x)`

where `g`

is a well-defined function, but printing `f`

will not reveal the nature of `g`

. Both of these issues also make evaluating the functions slower, as we could resolve the variables to constants and inline the nested functions' bodies, but instead evaluate them as variables and function calls, respectively. With our new package, we try to solve all of these issues at once. We provide a tool for combining functions and one for canonicalizing functions, i.e., for resolving all resolve-able components of a function.

`Path`

API instead of the old `File`

API. Here I discuss how a directory for temporary files further be scoped in time with Java's `try-with-resources`

.
]]>