New function name for juice()

[juliasilge]

We have a set of "verbs" to use with recipes:

• First you specify a dataset and variables.
• Next you add preprocessing steps.
• Then you prep the recipe to estimate the quantities for each step from the training data.
• Finally, you can apply this prepped recipe to new data with bake.

Feedback from users indicates that there is confusion around prep(), bake(), but especially juice(). The juice() function goes back to the prepped recipe and gets out the original training set with all steps applied. It is useful because the prepped recipe does have this information in it already.

In almost all cases these two are the same, where rec_prep is a prepped recipe:

juice(rec_rep)
bake(rec_prep, new_data = training_data)

Let's consider creating a new function that does the same thing juice() does, but with a new name. The juice() function will stay around but probably eventually be labeled "superseded".

[Bijaelo]

From a user perspective, I'd say that prep (or prepare) is a more logical name for fitting of the recipe. From a modelling perspective one could also use fit or using the known standard in predict. The logic for the first two are rather vague (likely bake and prep were also an author preference to keep with the theme of recipes)., while the logic for using predict is simply to stay within the known ecosystem that is already built in R's S3 class. Most users of R are familiar with predict, and thus it will be known to most users that newdata should be supplied for reevaluation on new data, while the original data will be processed if newdata was not supplied.
Meanwhile using bake and prep feels like a more pythonic implementation, where the more classical OOP doesn't incentivize package authors to implement standardized methods in the same way as the existing S3 infrastructure does. This might be a reason for the confusion for more classical R programmers.

Additionally one could be confused why prep is even needed. Recipes seems to be fully extendable in the sense that

data(iris)
library(recipes)
rec <- recipe(iris) %>%
  step_normalize(starts_with('Sepal')) %>%
  prep()

rec %>% step_normalize(starts_with('Petal')) %>%
  print()

gives a partially trained recipe. This edge-case makes the need for the current use of prep seem redundant. Two options for alleviating this comes to my mind.

1. Use an option for automatic evaluation of step at runtime (eg. recipe.lazy), to decide whether to evaluate a step immediately or until prep is called. Letting this be TRUE by default would make it simpler for high-level users to adopt the package.
2. Make recipes truly lazy, making prep and juice somewhat redundant. If the individual steps and elements of the recipe were stored in a local environment instead of how they are currently stored, these could be altered by the function itself.

[EmilHvitfeldt]

My two cents

I like recipe and step_s as nouns in this framework. It is very clear what they are trying to convey. The bake and prep verbs are cute, but prep always seemed wrong in my ears. This is mostly because of how prep is being used.

Conceptually, in my mind, a recipe is more or less a loose description of tasks to be performed (pour flour, whisk in milk and eggs, pour in the pan with butter, flip, serve), then prep is the action of figuring out the specific quantities according to what your domain in (here we used the data to see that we need 1 cup, 1 cup, 2 eggs, medium heat). Using this framing than bake follows naturally as you are baking using the final recipe.

I don't see this task as prepping, but more along the line of calibrating, finalizing or refining. In this framing, then we can keep bake as it is.

Then you would

• specify a recipe()
• finalize() the specific quantities (I know that finalize() is going to be too close to finalize_recipe() 😢 )
• bake() using our recipe or our ingredients (data)

This phrasing makes it more clear to me that the same recipe can be refined to give different results when used in different domains.

As for juice(). I think the most minimal change with the highest payoff would be as_tibble(). It doesn't follow the baking theme, but It clearly demonstrates that we are trying to get a tibble as an output. Another way would be a multi-word function based off what prep is being changed to. Honestly, I think steering clear of the cooking references is the right thing to do in this situation. I have a hard time finding an appropriate verb that would suffice.

As for as.data.frame(), this is similar to as_tibble() in a lot of ways. The main difference in my mind is that as_tibble() is used less then as.data.frame(). So the change would affect fewer packages.

I don't like the idea of being so invasive. This would mean that a prepped recipe could be passed to a modeling function via the data argument (which doesn't make a lot of sense since you are not passing data) and then it would be turned into data if the function starts by calling as.data.frame()

modeling_fun <- function(formula, data, weights, ...) {
  data <- as.data.frame(data)

...

It would have a lot of unintended (and hard to test for) interactions. I think package authors should opt-in to having recipes as an input format, it would be too much if we shoehorn it in.

[topepo]

I've thought a little more about @Bijaelo's suggestion and, while I still don't know that it is the solution, it does appeal to me more. I think that is it a bad idea to mix metaphors/paradigms and that's my main opposition to using it.

I think that we'll kick this around some more and then come up with a short list of candidate names (I have three so far) and then get feedback.

In the mean time, please propose/debate away...

[laderast]

I have been struggling with the difference between juice() and bake() for a while. To me, the verbs don't really map to training and test sets. I think having one verb name that maps to the two sets, such as bake_training() and bake_test() (as was suggested previously) might make the mapping more explicit and easier to understand.

[rlbarter]

For what it's worth, in my head I always think of to juice() as to "extract" (or even "pull") the processed data. I think this is biased by my idea of juicing as extracting the juice from a fruit, and I recognize that this doesn't quite make sense because the processed data hasn't actually been created yet in the object I'm juicing (but it's still a helpful way to think about it).

@Bijaelo's suggestion of having an option to generate the processed data internally when baking the recipe, so that the processed data can then be extracted using $ (or however else) seems fairly intuitive to me too. I think when I first started using recipes, this was the behaviour that I expected - I tried to extract the processed data from the recipe object before realizing that I had to juice it to get the processed data out.

[exuberantleigh]

Two suggestions: first idea, have bake() do both. When new_data = NULL, it uses the current juice() method. Although, that could lead to some inadvertent user error with someone forgetting to supply their test data, which would not be fun for them.

Second suggestion and the one I like better - More in line with @rlbarter's thinking, maybe juice() becomes pull_training()? "pull" is in line with the pull_* functions in workflow where you are extracting something from an object. "training" seems like it would be clear/intuitive and matches the argument in prep(). It doesn't play with the metaphor, but ya can't win 'em all.

Unless I'm misunderstanding the previous comments, you CAN get the processed training data out of the prepped recipe with $template, it just doesn't have the features that juice() has to select columns or convert the output type.

[jaredlander]

As for names, I just spent a day with Andreas and sklearn uses fit and transform in place of prep() and juice()/bake(). So I am not a huge fan of that because to my mind, fitting is something you do with a model. And yes, computing the transformations is sort of the same idea as fitting a model, but it didn't work for me. Likewise, predict() seems too much like it belongs to a model.

Maybe the food metaphors are a bit too abstract and something that is more representative of what they do?

But beyond that, having separate functions depending on training vs testing data is confusing too. If we are transforming the data who cares which data it is? If it were just one function, then we wouldn't have to worry about "skipping" steps carried out on the response.

And importantly, I'm not thrilled that in order to use juice(), which is needed in order to run "skipped" steps, we need to retain the data in the prep()-ed object. So now the data is stored in the original data.frame, in the prep()-ed object and in the juice()-ed object. Three copies the data can take up a lot of memory.

[juliasilge]

Chime in here with your opinion on some of the options we are currently considering!

[juliasilge]

The new option is now implemented in #561. As it says in NEWS:

To reduce confusion between bake() and juice(), the latter is superseded in favor of using bake(object, new_data = NULL). The new_data argument now has no default, so a NULL value must be explicitly used in order to emulate the results of juice(). juice() will remain in the package (and used internally) but most communication and training will use bake(object, new_data = NULL).

These two are now exactly the same:

juice(rec_rep)
bake(rec_prep, new_data = NULL)

[github-actions]

This issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with reprex) and link to this issue. https://reprex.tidyverse.org