recipes step_log() in R: Log-Transform Skewed Predictors

The recipes step_log() function in R applies a log transformation to numeric predictors, compressing right-skewed columns so a model sees a more symmetric spread. You add it to a recipe(), finalize it with prep(), and apply it with bake().

step_log(rec, all_numeric_predictors())              # natural log of all predictors
step_log(rec, disp, hp)                              # log named columns
step_log(rec, all_numeric_predictors(), base = 10)   # log base 10
step_log(rec, all_numeric_predictors(), base = 2)    # log base 2
step_log(rec, units, offset = 1)                     # add 1 first, handles zeros
step_log(rec, amt, signed = TRUE)                    # signed log, handles negatives
prep(rec) |> bake(new_data = NULL)                   # apply the transform

What step_log() does in R

step_log() replaces each selected column with its logarithm. During bake() it applies log(x, base) to every value, optionally adding an offset first. The default base is the natural constant e, so a plain step_log() call produces natural logs. The outcome variable is left alone when you select columns with all_numeric_predictors().

Logging is the standard fix for a right-skewed predictor, where most values cluster low and a long tail stretches high. The transformation pulls that tail in, turning multiplicative spacing into additive spacing. Counts, prices, incomes, and population sizes are common candidates. Models that assume roughly symmetric inputs, such as linear regression, often fit better once a heavy tail is logged.

step_log() syntax and arguments

step_log() attaches a logarithm operation to a recipe. You pass the recipe first, then the columns to transform, chosen with tidyselect helpers or bare names.

The arguments you will actually touch:

Log-transforming predictors: worked examples

Build the recipe, prep it, then bake. A recipe is a plan until prep() finalizes it. The first example takes the natural log of every numeric predictor in mtcars.

The outcome mpg keeps its original scale because all_numeric_predictors() excludes it. To log specific columns in a different base, name them and set base. Base 10 maps each order of magnitude to one unit, which many readers find easier to interpret.

The offset argument adds a constant before the log, the standard trick for columns that contain zeros. The log of zero is undefined, so step_log(offset = 1) behaves like the log1p() function and keeps every row finite.

For columns that also hold negative values, set signed = TRUE. The signed log takes sign(x) * log(abs(x)) and maps any value between -1 and 1 to 0, so the result stays finite across the whole real line.

step_log() vs step_BoxCox() vs step_YeoJohnson()

Pick the step that matches your data and your goal. All three reduce skew, but they differ in how much they estimate and what input values they tolerate.

Use step_log() when you already know a log makes sense and you want a transformation that is fast, fixed, and easy to explain. Reach for step_BoxCox() or step_YeoJohnson() when you would rather let the data choose the exponent, and step_YeoJohnson() specifically when the column has zeros or negatives. The estimated steps are more flexible but harder to communicate, since the fitted power is rarely a round number.

Common pitfalls with step_log()

Most step_log() bugs trace back to invalid inputs or the wrong column set. Because the transformation is static, recipes will not warn you before producing a broken column.

1. Zeros and negatives. log(0) is -Inf and log(-1) is NaN. A predictor with either value needs offset to shift it positive or signed = TRUE to use the signed variant.
2. Transforming the outcome by accident. all_numeric() includes the response variable. Use all_numeric_predictors() so the model still trains and predicts on the untransformed target.
3. New data with unexpected values. Training data may be all positive while a later batch contains a zero. step_log() will not error; it will quietly emit -Inf and corrupt the prediction. Validate new data or build the offset in from the start.

Try it yourself

Related recipes steps

step_log() is one of several recipes transformation steps. These pair naturally with it in a tidymodels workflow:

• step_BoxCox() estimates the best power transform for positive data.
• step_YeoJohnson() estimates a power transform that allows zeros and negatives.
• step_sqrt() applies a fixed square-root transform.
• step_normalize() centers and scales to mean 0 and SD 1.
• recipe() creates the preprocessing object every step attaches to.

FAQ

What does step_log() do in the recipes package?

step_log() adds a log transformation to a recipe. When you bake() the prepped recipe, every value in the selected columns is replaced by log(x, base), optionally after adding an offset. The default base is e, the natural log. It is most often used to compress right-skewed numeric predictors so models that assume symmetric inputs fit more reliably. Because it is a static transform, it estimates nothing from the data and runs identically on training and new rows.

How do I take a log transform of zeros with step_log()?

The log of zero is -Inf, so a column with zeros needs the offset argument. Setting step_log(units, offset = 1) adds 1 to every value before the log, exactly like the log1p() function, which keeps zero rows finite at log(1) = 0. If the column also has negative values, use signed = TRUE instead, which applies sign(x) * log(abs(x)) and maps values between -1 and 1 to 0.

Should I use step_log() or step_BoxCox()?

Use step_log() when you already know a log is appropriate and want a fixed, transparent transformation that is easy to explain to others. Use step_BoxCox() when you would rather let the data choose the exponent automatically. Box-Cox estimates a power that best symmetrizes each column, which can fit better but produces a non-round exponent that is harder to communicate. Box-Cox also requires strictly positive data, while step_log() can handle zeros and negatives through offset and signed.

Does step_log() transform the outcome variable?

Not if you select columns with all_numeric_predictors(), which excludes the response. If you use all_numeric() instead, the outcome is included and gets logged too, which is rarely what you want. To log the response on purpose, name it explicitly and remember that predictions then come back on the log scale and must be exponentiated to return to the original units.