parsnip set_args() in R: Update Model Arguments

The parsnip set_args() function in R updates the arguments of a model specification after you create it. You pass a spec and one or more named arguments, and parsnip returns an updated spec with those values changed or added.

⚡ Quick Answer
rand_forest() |> set_args(mtry = 3)               # set one main argument
rand_forest() |> set_args(mtry = 3, trees = 500)  # set several at once
linear_reg() |> set_args(penalty = tune())        # mark an argument for tuning
boost_tree() |> set_args(learn_rate = 0.01)       # update a hyperparameter
rand_forest(trees = 200) |> set_args(trees = 500) # overwrite an existing value
spec |> set_args(importance = "impurity")         # add an engine-specific arg
spec |> set_args(min_n = tune("min_node"))        # named tuning placeholder

Need explanation? Read on for examples and pitfalls.

📊 Is set_args() the right tool?
STARTupdate main model argumentsset_args(spec, trees = 1000)choose the fitting backendset_engine(spec, "ranger")set regression or classificationset_mode(spec, "classification")see the resolved engine calltranslate(spec)list tunable argumentstunable(spec)train the finished specfit(spec, y ~ ., data = train)

What set_args() does

set_args() changes the arguments of a model specification that already exists. A model function such as rand_forest() builds a spec. set_args() lets you revise that spec later, setting hyperparameters like trees or mtry without rebuilding it from scratch.

The function returns an updated specification, so it slots into a pipe. Nothing is fitted when you call it. set_args() only records the new argument values, and the actual computation waits until you call fit().

An argument you pass is matched against the model's main arguments first. A name like trees or penalty updates a main argument. Any name parsnip does not recognise becomes an engine-specific argument instead, forwarded to the underlying fitting function.

Key Insight
set_args() is the verb for hyperparameters, not for the backend. The model function says what model, set_engine() says which package computes it, and set_args() tunes the numbers. Keeping argument updates in one named verb makes a model specification easy to build programmatically.

set_args() syntax and arguments

set_args() takes a spec followed by named arguments. The signature is short, and every name after the spec is a value you want to set or change.

Run live
Run live, no install needed. Every R block on this page runs in your browser. Click Run, edit the code, re-run instantly. No setup.
RThe set_args argument skeleton
set_args( object, # a parsnip model specification ... # one or more named arguments to set )

  

The object argument is the spec you built with a model function like rand_forest() or boost_tree(). The ... slot holds the arguments you want to update, each supplied by name.

Values in ... can be literals or tuning placeholders. A literal such as trees = 500 fixes the value. A placeholder such as penalty = tune() marks the argument for later tuning, which the tune package resolves during tune_grid(). You must supply at least one named argument, or set_args() raises an error.

Update model arguments: four examples

Each example builds a spec and prints it. Building a spec needs only parsnip, so the code runs even before any engine package is installed.

Example 1: Set a single argument

Pass one named argument to update one value. Here set_args() adds mtry to a random forest spec.

RSet one model argument with set_args
library(tidymodels) rf_spec <- rand_forest() |> set_mode("regression") |> set_args(mtry = 3) rf_spec #> Random Forest Model Specification (regression) #> #> Main Arguments: #> mtry = 3 #> #> Computational engine: ranger

  

The printed spec lists mtry under main arguments. The value is recorded but not used until fit() runs.

Example 2: Set several arguments and overwrite a value

One set_args() call can change many arguments at once. It also overwrites values that were set in the model function.

RUpdate several arguments at once
rf_spec2 <- rand_forest(trees = 200) |> set_mode("regression") |> set_args(trees = 500, min_n = 10) rf_spec2 #> Random Forest Model Specification (regression) #> #> Main Arguments: #> trees = 500 #> min_n = 10 #> #> Computational engine: ranger

  

The spec started with trees = 200, but set_args() replaced it with 500 and added min_n. The latest value always wins.

Example 3: Mark arguments for tuning

Use tune() inside set_args() to defer a value. This is the standard way to flag hyperparameters before a grid search.

RFlag arguments for tuning
tune_spec <- boost_tree() |> set_mode("classification") |> set_args(trees = tune(), learn_rate = tune()) tune_spec #> Boosted Tree Model Specification (classification) #> #> Main Arguments: #> trees = tune() #> learn_rate = tune() #> #> Computational engine: xgboost

  

The placeholders tell tune_grid() which arguments to search. Until tuning runs, the spec carries tune() markers instead of numbers.

Example 4: Add an engine-specific argument

An unrecognised name becomes an engine argument. Here importance is not a main random forest argument, so parsnip forwards it to the ranger engine.

RAdd an engine-specific argument
rf_imp <- rand_forest(trees = 500) |> set_mode("regression") |> set_engine("ranger") |> set_args(importance = "impurity") rf_imp #> Random Forest Model Specification (regression) #> #> Main Arguments: #> trees = 500 #> #> Engine-Specific Arguments: #> importance = impurity #> #> Computational engine: ranger

  

The print output separates the two groups. trees is a main argument every random forest engine shares, while importance belongs to ranger alone.

Tip
Call tunable() to see which arguments you can tune. tunable(spec) returns a tibble of every argument the model and engine expose for tuning. Use it before writing set_args(... = tune()) so you mark only valid arguments.

set_args() vs passing arguments directly

set_args() is one of three ways to set model arguments. The right choice depends on when you know the values.

Approach When to use Example
Model function arguments You know the values when you create the spec rand_forest(mtry = 3)
set_args() You revise a spec that already exists `spec \ > set_args(mtry = 3)`
update() You revise a spec inside a workflow or tuning step update(spec, mtry = 5)

The decision rule is direct. Put values in the model function when you build the spec in one shot. Reach for set_args() when a spec is passed around, built in stages, or generated by a loop. Use update() when the spec is wrapped in a workflow and you need to revise it in place.

Note
set_engine() also accepts arguments. Engine-specific options can be passed through set_engine("ranger", importance = "impurity") or through set_args(). Both land in the same Engine-Specific Arguments slot, so pick whichever reads more clearly in your pipeline.

Common pitfalls

Two mistakes account for most set_args() trouble. Both are quick to spot once you know the pattern.

The first is calling set_args() with no arguments. The function requires at least one named value and errors otherwise.

Rset_args needs at least one named argument
# This errors: no arguments supplied rand_forest() |> set_args() #> Error in set_args(): Please pass at least one named argument.

  

The second is a misspelled argument name. parsnip does not reject unknown names. It quietly treats them as engine-specific arguments, which can cause a confusing failure later at fit() time.

RA typo becomes an engine-specific argument
# 'tree' is a typo for 'trees', so it is treated as engine-specific rand_forest() |> set_mode("regression") |> set_args(tree = 500) #> Random Forest Model Specification (regression) #> #> Engine-Specific Arguments: #> tree = 500 #> #> Computational engine: ranger

  
Warning
set_args() does not modify the spec in place. It returns a new spec, so you must assign the result. Writing set_args(spec, trees = 500) without spec <- ... discards the update and leaves the original unchanged.

Try it yourself

Try it: Build a boost_tree() spec, set the mode to classification, then use set_args() to set trees = 1000 and mark learn_rate for tuning. Save the spec to ex_spec.

RYour turn: configure a boosted tree spec
# Try it: build a boost_tree spec with set_args ex_spec <- # your code here ex_spec #> Expected: trees = 1000 and learn_rate = tune()

  
Click to reveal solution
RSolution
ex_spec <- boost_tree() |> set_mode("classification") |> set_args(trees = 1000, learn_rate = tune()) ex_spec #> Boosted Tree Model Specification (classification) #> #> Main Arguments: #> trees = 1000 #> learn_rate = tune() #> #> Computational engine: xgboost

  

Explanation: set_args() updates two main arguments in a single call. The literal 1000 fixes trees, while tune() flags learn_rate for a later grid search.

set_args() works alongside the other parsnip specification verbs. These functions cover the neighbouring steps of building and fitting a model.

  • set_engine() declares which package computes the model.
  • set_mode() declares regression or classification for dual-mode models.
  • update() revises a spec, often inside a workflow.
  • tune() is the placeholder that marks an argument for tuning.
  • translate() shows the exact engine call a spec will generate.
  • fit() trains the spec once its arguments are set.

FAQ

What does set_args() do in R?

set_args() updates the arguments of a parsnip model specification after it has been created. You pass the spec and one or more named arguments, and it returns an updated spec with those values set or changed. The arguments can be main model arguments like trees or engine-specific options. No model is fitted when you call it. The values are only recorded, and computation happens later when you call fit().

What is the difference between set_args() and set_engine()?

They configure different parts of a spec. set_args() sets the model's arguments, the hyperparameters that control how the model behaves. set_engine() chooses the computational backend, the package that actually fits the model. A random forest can run on ranger or randomForest through set_engine(), while its trees and mtry values come from set_args() or the model function. Both verbs return an updated spec for the pipe.

Can I use set_args() to set tuning parameters?

Yes. Pass tune() as the value, for example set_args(penalty = tune()). This marks the argument as a tuning parameter rather than a fixed number. The tune package then resolves it during tune_grid() or tune_bayes(). You can also pass a named placeholder like tune("my_penalty") when several arguments need distinct labels in the tuning grid. Until tuning runs, the spec carries the tune() marker instead of a value.

Should I use set_args() or pass arguments to the model function?

Pass arguments directly to the model function when you know the values as you build the spec, since rand_forest(mtry = 3) is shorter. Use set_args() when the spec already exists and you need to revise it, which is common when specs are built in stages or generated programmatically. Both produce the same result. set_args() simply lets you defer or change the values after creation.

Does set_args() change the spec in place?

No. set_args() returns a new, updated specification and leaves the original untouched. You must assign the result, as in spec <- set_args(spec, trees = 500), or chain it in a pipe. Forgetting to capture the return value is a common mistake that silently discards your changes. R objects are not modified in place, so the returned spec is the only one that carries the update.

For the full argument reference, see the parsnip set_args() documentation.