alex hayes

Next steps for `augment()`

3

This is a followup to #32, but an attempt to start answering "what should `augment()` look like"? I'm of the belief that `augment()` should be split into three different generics:...

The `anova` class is so overloaded that you never know what you're going to get, and so it's near impossible to extend methods that save information of some sort in...

Don't keep estimates in multiple objects

1

See https://github.com/tidymodels/broom/issues/663 for example, or a number of the bootstrap-style things that I can't remember. All the estimates should live in a single objects, otherwise you end with an interface...

Settle on an interface for ensembles

1

In particular thinking about preprocessing, as the many fits in an ensemble might require different pre-processing.

What should happen? I think you should either get an empty tibble back, or an error. Could see it going either way.

tranform()-like generic for unsupervised methods

1

Moving the discussion here from Slack. We should define a generic for unsupervised transformations. Jenny pointed out that `transform()` would be a bad name since it would have a name...

Add section on how to test models

2

Things that should be included: - How to test a formula / recipe interface - How to test code that compares results to computation from other packages, or software written...

A broad class of hyperparameter tuning methods rely on being able to specify some amount of resources (iterations, time) to spend training a model. An even broader class of hyperparameter...

step_lag should have an order_by argument

1

Currently it requires that the input tibble is appropriately sorted, but we could just pass a column to sort by to `dplyr::lag` in the implementation. Probably can get around to...

Random projection step

1

I'd like a signature along the lines of: ```r step_randomproj(recipe, ..., dimensions, error) ``` where the user can either specify the number of dimensions to project into or an acceptable...