[Call for help] Bringing the R package up-to-date.

[trivialfis]

We are maintaining the R package with the best effort, but due to resource limitations, the R package feature has been lagging behind compared to the Python package. Here is a list of things that can be improved. Contributions are appreciated!

• Categorical data support. We need the R package to recognize the factor type and pass related information into xgboost.
• Multi-output models. Even though it's still working in progress, establishing an interface would be nice. ([R] Support multi-class custom objective. #9526)
• Design an interface that's more native to R, for instance, using formulas like what the GLM does. The tidy verse can be a good design reference.
• Distributed training, perhaps integration with RSpark.
• QuantileDMatrix support can help R users to reduce memory usage.
• External memory with DataIter.
• quantile regression with multiple quantiles.
• Use CMake instead of autotools when possible, this way we can make it easier to support GPU with R.
• inplace prediction.

[trivialfis]

As a side note, at the moment I'm the maintainer of the CRAN package. If there are contributors who want to share this I'm more than happy to assist and change the maintainership. I have some familiarity with R for statistical computing, but it's not my daily drive and it's unlikely that I will gain a deep understanding of the community in near future.

[jameslamb]

👋🏻 I'd be happy to help out more with the R package, if you're open to it. I'll try some more small PRs to get familiar with XGBoost generally and the R package specifically before addressing the specific features you've listed.

[trivialfis]

@jameslamb Thank you for working on the R package! Feel free to ping me if there's anything I can help.

[dfsnow]

@trivialfis I'm interested in tackling the first issue: adding categorical support to the existing R implementation. I should be able to get it done within the next month or two. Are you open to me creating a draft PR in a fork and pinging you + @jameslamb when it's ready?

[trivialfis]

Thank you for volunteering! Feel free to ping me.

[mayer79]

Great initiative, thanks a lot @trivialfis :

1. If @david-cortes has a little bit of spare time, he would be our man here. I can also help, but need a little bit of time to get used to the code base.
2. I'd love to see multi-target support in R! Same for the multi-quantile loss.
3. Do we already have SHAP values for the multi-target (and multi-quantile) situation (not only in R, but in XGBoost in general)?

[david-cortes]

Sure I could help if needed.

But I think a first step would be to decide on what the final result should look like, how far are the changes meant to be, and whether we're going to hold off the R release until all changes are complete (e.g. by keeping a separate branch) or introduce them gradually alongside with releases; or maybe even release under a different name like xgboost2.

Right now, xgboost works very differently from base R's stats::glm, and from most other R packages for statistical modeling, whether tree-based (e.g. ranger, randomForest, gbm3, etc.) or linear-based (e.g. VGAM, glmnet, glmx, ncvreg, grpreg, etc.); both when fitting models and when making predictions. Using xgboost in R without any wrapper is quite inconvenient and requires a lot more code than other packages.

Changing the interface to be more idiomatic would be nicer for users, and I think this major version jump is the best chance to introduce big changes as there probably won't be any next major release any time soon, if ever.

However, there's a lot of packages that depend on xgboost in some way (currently 133 listed in CRAN alone), plus lots of scripts in the wild, and for a package as widely used, any breaking change would lead to a large amount of frustrated users, plus would involve notifying the maintainers of those CRAN/bioconductor packages and perhaps subimitting PRs to them.

So I'd say let's first clarify on what's acceptable to change and what isn't.

For example, off the top of my mind, I can think of the following un-idiomatic behaviors that could be improved:

• Accepting formulas as possible inputs. This could be changed for example by changing xgboost to a generic method and having a specialization for formula, and another x/y interface that would accept inputs like xgb.DMatrix/matrix/dgCMatrix. Here however we'd need to decide on a lot of nuances such as how to treat categoricals, whether to use base R's interpretation of formulas or some other parser with different options, etc.
• Accepting data.frame as inputs. Ideally, here it should automatically detect which variables are to be considered as categorical (either factor, or factor+character like base R). Perhaps it should also keep a list of their levels to recode variables at prediction time, and a list of the column names for feature importances, plots, and such.
• Allowing other arguments to be able to refer to column names from a data.frame, such as monotonicity constraints.
• Accepting other sources of data like arrow. Perhaps this could be left only for xgb.DMatrix if that makes it easier.
• Accepting an argument to specify categorical columns in non-data.frame inputs. Here we'd need to clarify whether that would be supposed to error-out on data.frame or not, for example.
• Accepting factors as response variable for classification objectives, and keeping a list of their levels for predictions. Ideally also making the default objective switch to logistic/multinomial when passed a factor.
• Using those factor levels as output/names from the prediction function and plot function.
• Perhaps also accepting a column name from a data frame as response variable and/or as weights, either as string or using non-standard evaluation.
• Changing the names of the arguments to functions and their positions in the call to better match with base R and other packages (e.g. "weights" instead of "weight").
• Moving more options to top-level arguments, like objective and nthreads.
• Using 1-based indexing for things that refer to enumerations, such as tree/node numbers.
• Changing the structure of the predict function - e.g. a type argument, enforced output shape as suggested here, keeping metadata like row names, etc.
• Potentially having the option for predict to re-order columns to match names and recode factors to the levels seen during training. This is quite unusual among packages though.
• Having a fit control function for generating parameters with auto-completion capabilities. Not sure how feasible this is though, as I think there isn't a single place with a list of parameters.
• Improve efficiency of the prediction by using the same mechanisms for passing data as the python interface does.
• Allow passing survival objects for survival objectives.

Some of these would involve large breakage in reverse dependencies, while others wouldn't, but I think the biggest gains here are precisely the ones that would cause breakage.

[hcho3]

there's a lot of packages that depend on xgboost in some way (currently 133 listed in CRAN alone), plus lots of scripts in the wild, and for a package as widely used, any breaking change would lead to a large amount of frustrated users, plus would involve notifying the maintainers of those CRAN/bioconductor packages and perhaps subimitting PRs to them.

I am personally in favor of creating {xgboost2} to avoid this very issue. Already, XGBoost 2.0 breaks multiple reverse dependencies and hence it's not yet available on CRAN.

[mayer79]

@hcho3: I wanted to propose {xgboost2} as well, but did not dare :-)

[trivialfis]

I'm happy with xgboost2. Should it be a different package or can live side by side with the existing one?