[CI] Update RAPIDS to latest stable

.github/workflows/jvm_tests.yml

@@ -51,14 +51,14 @@ jobs:
       id: extract_branch
       if: |
         (github.ref == 'refs/heads/master' || contains(github.ref, 'refs/heads/release_')) &&
-        (matrix.os == 'windows-latest' || matrix.os == 'macos-11')
+        matrix.os == 'windows-latest'
 
     - name: Publish artifact xgboost4j.dll to S3
       run: |
         cd lib/
         Rename-Item -Path xgboost4j.dll -NewName xgboost4j_${{ github.sha }}.dll
         dir
-        python -m awscli s3 cp xgboost4j_${{ github.sha }}.dll s3://xgboost-nightly-builds/${{ steps.extract_branch.outputs.branch }}/libxgboost4j/ --acl public-read
+        python -m awscli s3 cp xgboost4j_${{ github.sha }}.dll s3://xgboost-nightly-builds/${{ steps.extract_branch.outputs.branch }}/ --acl public-read
       if: |
         (github.ref == 'refs/heads/master' || contains(github.ref, 'refs/heads/release_')) &&
         matrix.os == 'windows-latest'
@@ -66,19 +66,6 @@ jobs:
         AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID_IAM_S3_UPLOADER }}
         AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY_IAM_S3_UPLOADER }}
 
-    - name: Publish artifact libxgboost4j.dylib to S3
-      run: |
-        cd lib/
-        mv -v libxgboost4j.dylib libxgboost4j_${{ github.sha }}.dylib
-        ls
-        python -m awscli s3 cp libxgboost4j_${{ github.sha }}.dylib s3://xgboost-nightly-builds/${{ steps.extract_branch.outputs.branch }}/libxgboost4j/ --acl public-read
-      if: |
-        (github.ref == 'refs/heads/master' || contains(github.ref, 'refs/heads/release_')) &&
-        matrix.os == 'macos-11'
-      env:
-        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID_IAM_S3_UPLOADER }}
-        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY_IAM_S3_UPLOADER }}
-
 
     - name: Test XGBoost4J (Core, Spark, Examples)
       run: |

.github/workflows/r_tests.yml

@@ -25,7 +25,7 @@ jobs:
       with:
         submodules: 'true'
 
-    - uses: r-lib/actions/setup-r@11a22a908006c25fe054c4ef0ac0436b1de3edbe # v2.6.4
+    - uses: r-lib/actions/setup-r@50d1eae9b8da0bb3f8582c59a5b82225fa2fe7f2 # v2.3.1
       with:
         r-version: ${{ matrix.config.r }}
 
@@ -64,7 +64,7 @@ jobs:
       with:
         submodules: 'true'
 
-    - uses: r-lib/actions/setup-r@11a22a908006c25fe054c4ef0ac0436b1de3edbe # v2.6.4
+    - uses: r-lib/actions/setup-r@50d1eae9b8da0bb3f8582c59a5b82225fa2fe7f2 # v2.3.1
       with:
         r-version: ${{ matrix.config.r }}
 

.github/workflows/scorecards.yml

@@ -27,7 +27,7 @@ jobs:
           persist-credentials: false
 
       - name: "Run analysis"
-        uses: ossf/scorecard-action@08b4669551908b1024bb425080c797723083c031 # tag=v2.2.0
+        uses: ossf/scorecard-action@99c53751e09b9529366343771cc321ec74e9bd3d # tag=v2.0.6
         with:
           results_file: results.sarif
           results_format: sarif
@@ -41,7 +41,7 @@ jobs:
       # Upload the results as artifacts (optional). Commenting out will disable uploads of run results in SARIF
       # format to the repository Actions tab.
       - name: "Upload artifact"
-        uses: actions/upload-artifact@0b7f8abb1508181956e8e162db84b466c27e18ce # tag=v3.1.2
+        uses: actions/upload-artifact@6673cd052c4cd6fcf4b4e6e60ea986c889389535 # tag=v3.0.0
         with:
           name: SARIF file
           path: results.sarif
@@ -49,6 +49,6 @@ jobs:
 
       # Upload the results to GitHub's code scanning dashboard.
       - name: "Upload to code-scanning"
-        uses: github/codeql-action/upload-sarif@7b6664fa89524ee6e3c3e9749402d5afd69b3cd8 # tag=v2.14.1
+        uses: github/codeql-action/upload-sarif@5f532563584d71fdef14ee64d17bafb34f751ce5 # tag=v1.0.26
         with:
           sarif_file: results.sarif

.gitignore

@@ -48,7 +48,6 @@ Debug
 *.Rproj
 ./xgboost.mpi
 ./xgboost.mock
-*.bak
 #.Rbuildignore
 R-package.Rproj
 *.cache*

.readthedocs.yaml

@@ -32,3 +32,4 @@ formats:
 python:
   install:
    - requirements: doc/requirements.txt
+  system_packages: true

CITATION

@@ -15,3 +15,4 @@
  address = {New York, NY, USA},
  keywords = {large-scale machine learning},
 }
+

CMakeLists.txt

@@ -1,5 +1,5 @@
 cmake_minimum_required(VERSION 3.18 FATAL_ERROR)
-project(xgboost LANGUAGES CXX C VERSION 2.0.3)
+project(xgboost LANGUAGES CXX C VERSION 2.0.0)
 include(cmake/Utils.cmake)
 list(APPEND CMAKE_MODULE_PATH "${xgboost_SOURCE_DIR}/cmake/modules")
 cmake_policy(SET CMP0022 NEW)
@@ -14,24 +14,8 @@ endif ((${CMAKE_VERSION} VERSION_GREATER 3.13) OR (${CMAKE_VERSION} VERSION_EQUA
 
 message(STATUS "CMake version ${CMAKE_VERSION}")
 
-# Check compiler versions
-# Use recent compilers to ensure that std::filesystem is available
-if(MSVC)
-  if(MSVC_VERSION LESS 1920)
-    message(FATAL_ERROR "Need Visual Studio 2019 or newer to build XGBoost")
-  endif()
-elseif(CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
-  if(CMAKE_CXX_COMPILER_VERSION VERSION_LESS "8.1")
-    message(FATAL_ERROR "Need GCC 8.1 or newer to build XGBoost")
-  endif()
-elseif(CMAKE_CXX_COMPILER_ID STREQUAL "AppleClang")
-  if(CMAKE_CXX_COMPILER_VERSION VERSION_LESS "11.0")
-    message(FATAL_ERROR "Need Xcode 11.0 (AppleClang 11.0) or newer to build XGBoost")
-  endif()
-elseif(CMAKE_CXX_COMPILER_ID STREQUAL "Clang")
-  if(CMAKE_CXX_COMPILER_VERSION VERSION_LESS "9.0")
-    message(FATAL_ERROR "Need Clang 9.0 or newer to build XGBoost")
-  endif()
+if (CMAKE_COMPILER_IS_GNUCC AND CMAKE_CXX_COMPILER_VERSION VERSION_LESS 5.0)
+  message(FATAL_ERROR "GCC version must be at least 5.0!")
 endif()
 
 include(${xgboost_SOURCE_DIR}/cmake/FindPrefetchIntrinsics.cmake)
@@ -66,7 +50,6 @@ option(HIDE_CXX_SYMBOLS "Build shared library and hide all C++ symbols" OFF)
 option(KEEP_BUILD_ARTIFACTS_IN_BINARY_DIR "Output build artifacts in CMake binary dir" OFF)
 ## CUDA
 option(USE_CUDA  "Build with GPU acceleration" OFF)
-option(USE_PER_THREAD_DEFAULT_STREAM "Build with per-thread default stream" ON)
 option(USE_NCCL  "Build with NCCL to enable distributed GPU support." OFF)
 option(BUILD_WITH_SHARED_NCCL "Build with shared NCCL library." OFF)
 set(GPU_COMPUTE_VER "" CACHE STRING
@@ -233,11 +216,6 @@ endif (RABIT_BUILD_MPI)
 add_subdirectory(${xgboost_SOURCE_DIR}/src)
 target_link_libraries(objxgboost PUBLIC dmlc)
 
-# Link -lstdc++fs for GCC 8.x
-if(CMAKE_CXX_COMPILER_ID STREQUAL "GNU" AND CMAKE_CXX_COMPILER_VERSION VERSION_LESS "9.0")
-  target_link_libraries(objxgboost PUBLIC stdc++fs)
-endif()
-
 # Exports some R specific definitions and objects
 if (R_LIB)
   add_subdirectory(${xgboost_SOURCE_DIR}/R-package)
@@ -253,15 +231,6 @@ add_subdirectory(${xgboost_SOURCE_DIR}/plugin)
 
 if (PLUGIN_RMM)
   find_package(rmm REQUIRED)
-
-  # Patch the rmm targets so they reference the static cudart
-  # Remove this patch once RMM stops specifying cudart requirement
-  # (since RMM is a header-only library, it should not specify cudart in its CMake config)
-  get_target_property(rmm_link_libs rmm::rmm INTERFACE_LINK_LIBRARIES)
-  list(REMOVE_ITEM rmm_link_libs CUDA::cudart)
-  list(APPEND rmm_link_libs CUDA::cudart_static)
-  set_target_properties(rmm::rmm PROPERTIES INTERFACE_LINK_LIBRARIES "${rmm_link_libs}")
-  get_target_property(rmm_link_libs rmm::rmm INTERFACE_LINK_LIBRARIES)
 endif (PLUGIN_RMM)
 
 #-- library

R-package/DESCRIPTION

@@ -1,8 +1,8 @@
 Package: xgboost
 Type: Package
 Title: Extreme Gradient Boosting
-Version: 2.0.3.1
-Date: 2023-12-14
+Version: 2.0.0.1
+Date: 2022-10-18
 Authors@R: c(
   person("Tianqi", "Chen", role = c("aut"),
          email = "tianqi.tchen@gmail.com"),

R-package/R/callbacks.R

@@ -70,7 +70,7 @@ cb.print.evaluation <- function(period = 1, showsd = TRUE) {
         i == env$begin_iteration ||
         i == env$end_iteration) {
       stdev <- if (showsd) env$bst_evaluation_err else NULL
-      msg <- .format_eval_string(i, env$bst_evaluation, stdev)
+      msg <- format.eval.string(i, env$bst_evaluation, stdev)
       cat(msg, '\n')
     }
   }
@@ -380,9 +380,7 @@ cb.early.stop <- function(stopping_rounds, maximize = FALSE,
     if ((maximize && score > best_score) ||
         (!maximize && score < best_score)) {
 
-      best_msg <<- .format_eval_string(
-        i, env$bst_evaluation, env$bst_evaluation_err
-      )
+      best_msg <<- format.eval.string(i, env$bst_evaluation, env$bst_evaluation_err)
       best_score <<- score
       best_iteration <<- i
       best_ntreelimit <<- best_iteration * env$num_parallel_tree
@@ -513,7 +511,7 @@ cb.cv.predict <- function(save_models = FALSE) {
     if (save_models) {
       env$basket$models <- lapply(env$bst_folds, function(fd) {
         xgb.attr(fd$bst, 'niter') <- env$end_iteration - 1
-        xgb.Booster.complete(xgb.handleToBooster(handle = fd$bst, raw = NULL), saveraw = TRUE)
+        xgb.Booster.complete(xgb.handleToBooster(fd$bst), saveraw = TRUE)
       })
     }
   }
@@ -661,7 +659,7 @@ cb.gblinear.history <- function(sparse = FALSE) {
     } else { # xgb.cv:
       cf <- vector("list", length(env$bst_folds))
       for (i in seq_along(env$bst_folds)) {
-        dmp <- xgb.dump(xgb.handleToBooster(handle = env$bst_folds[[i]]$bst, raw = NULL))
+        dmp <- xgb.dump(xgb.handleToBooster(env$bst_folds[[i]]$bst))
         cf[[i]] <- as.numeric(grep('(booster|bias|weigh)', dmp, invert = TRUE, value = TRUE))
         if (sparse) cf[[i]] <- as(cf[[i]], "sparseVector")
       }
@@ -756,7 +754,7 @@ xgb.gblinear.history <- function(model, class_index = NULL) {
 #
 
 # Format the evaluation metric string
-.format_eval_string <- function(iter, eval_res, eval_err = NULL) {
+format.eval.string <- function(iter, eval_res, eval_err = NULL) {
   if (length(eval_res) == 0)
     stop('no evaluation results')
   enames <- names(eval_res)

R-package/R/utils.R

@@ -140,7 +140,7 @@ check.custom.eval <- function(env = parent.frame()) {
 
 
 # Update a booster handle for an iteration with dtrain data
-xgb.iter.update <- function(booster_handle, dtrain, iter, obj) {
+xgb.iter.update <- function(booster_handle, dtrain, iter, obj = NULL) {
   if (!identical(class(booster_handle), "xgb.Booster.handle")) {
     stop("booster_handle must be of xgb.Booster.handle class")
   }
@@ -163,7 +163,7 @@ xgb.iter.update <- function(booster_handle, dtrain, iter, obj) {
 # Evaluate one iteration.
 # Returns a named vector of evaluation metrics
 # with the names in a 'datasetname-metricname' format.
-xgb.iter.eval <- function(booster_handle, watchlist, iter, feval) {
+xgb.iter.eval <- function(booster_handle, watchlist, iter, feval = NULL) {
   if (!identical(class(booster_handle), "xgb.Booster.handle"))
     stop("class of booster_handle must be xgb.Booster.handle")
 
@@ -234,7 +234,7 @@ generate.cv.folds <- function(nfold, nrows, stratified, label, params) {
         y <- factor(y)
       }
     }
-    folds <- xgb.createFolds(y = y, k = nfold)
+    folds <- xgb.createFolds(y, nfold)
   } else {
     # make simple non-stratified folds
     kstep <- length(rnd_idx) %/% nfold
@@ -251,7 +251,7 @@ generate.cv.folds <- function(nfold, nrows, stratified, label, params) {
 # Creates CV folds stratified by the values of y.
 # It was borrowed from caret::createFolds and simplified
 # by always returning an unnamed list of fold indices.
-xgb.createFolds <- function(y, k) {
+xgb.createFolds <- function(y, k = 10) {
   if (is.numeric(y)) {
     ## Group the numeric data based on their magnitudes
     ## and sample within those groups.

R-package/R/xgb.Booster.R

@@ -1,6 +1,7 @@
 # Construct an internal xgboost Booster and return a handle to it.
 # internal utility function
-xgb.Booster.handle <- function(params, cachelist, modelfile, handle) {
+xgb.Booster.handle <- function(params = list(), cachelist = list(),
+                               modelfile = NULL, handle = NULL) {
   if (typeof(cachelist) != "list" ||
       !all(vapply(cachelist, inherits, logical(1), what = 'xgb.DMatrix'))) {
     stop("cachelist must be a list of xgb.DMatrix objects")
@@ -11,7 +12,7 @@ xgb.Booster.handle <- function(params, cachelist, modelfile, handle) {
       ## A filename
       handle <- .Call(XGBoosterCreate_R, cachelist)
       modelfile <- path.expand(modelfile)
-      .Call(XGBoosterLoadModel_R, handle, enc2utf8(modelfile[1]))
+      .Call(XGBoosterLoadModel_R, handle, modelfile[1])
       class(handle) <- "xgb.Booster.handle"
       if (length(params) > 0) {
         xgb.parameters(handle) <- params
@@ -43,7 +44,7 @@ xgb.Booster.handle <- function(params, cachelist, modelfile, handle) {
 
 # Convert xgb.Booster.handle to xgb.Booster
 # internal utility function
-xgb.handleToBooster <- function(handle, raw) {
+xgb.handleToBooster <- function(handle, raw = NULL) {
   bst <- list(handle = handle, raw = raw)
   class(bst) <- "xgb.Booster"
   return(bst)
@@ -128,12 +129,7 @@ xgb.Booster.complete <- function(object, saveraw = TRUE) {
     stop("argument type must be xgb.Booster")
 
   if (is.null.handle(object$handle)) {
-    object$handle <- xgb.Booster.handle(
-      params = list(),
-      cachelist = list(),
-      modelfile = object$raw,
-      handle = object$handle
-    )
+    object$handle <- xgb.Booster.handle(modelfile = object$raw, handle = object$handle)
   } else {
     if (is.null(object$raw) && saveraw) {
       object$raw <- xgb.serialize(object$handle)
@@ -479,7 +475,7 @@ predict.xgb.Booster <- function(object, newdata, missing = NA, outputmargin = FA
 #' @export
 predict.xgb.Booster.handle <- function(object, ...) {
 
-  bst <- xgb.handleToBooster(handle = object, raw = NULL)
+  bst <- xgb.handleToBooster(object)
 
   ret <- predict(bst, ...)
   return(ret)

R-package/R/xgb.DMatrix.R

@@ -88,7 +88,7 @@ xgb.DMatrix <- function(data, info = list(), missing = NA, silent = FALSE, nthre
 
 # get dmatrix from data, label
 # internal helper method
-xgb.get.DMatrix <- function(data, label, missing, weight, nthread) {
+xgb.get.DMatrix <- function(data, label = NULL, missing = NA, weight = NULL, nthread = NULL) {
   if (inherits(data, "dgCMatrix") || is.matrix(data)) {
     if (is.null(label)) {
       stop("label must be provided when data is a matrix")

R-package/R/xgb.cv.R

@@ -135,6 +135,9 @@ xgb.cv <- function(params = list(), data, nrounds, nfold, label = NULL, missing
   check.custom.obj()
   check.custom.eval()
 
+  #if (is.null(params[['eval_metric']]) && is.null(feval))
+  #  stop("Either 'eval_metric' or 'feval' must be provided for CV")
+
   # Check the labels
   if ((inherits(data, 'xgb.DMatrix') && is.null(getinfo(data, 'label'))) ||
       (!inherits(data, 'xgb.DMatrix') && is.null(label))) {
@@ -158,6 +161,10 @@ xgb.cv <- function(params = list(), data, nrounds, nfold, label = NULL, missing
     folds <- generate.cv.folds(nfold, nrow(data), stratified, cv_label, params)
   }
 
+  # Potential TODO: sequential CV
+  #if (strategy == 'sequential')
+  #  stop('Sequential CV strategy is not yet implemented')
+
   # verbosity & evaluation printing callback:
   params <- c(params, list(silent = 1))
   print_every_n <- max(as.integer(print_every_n), 1L)
@@ -187,13 +194,7 @@ xgb.cv <- function(params = list(), data, nrounds, nfold, label = NULL, missing
 
   # create the booster-folds
   # train_folds
-  dall <- xgb.get.DMatrix(
-    data = data,
-    label = label,
-    missing = missing,
-    weight = NULL,
-    nthread = params$nthread
-  )
+  dall <- xgb.get.DMatrix(data, label, missing, nthread = params$nthread)
   bst_folds <- lapply(seq_along(folds), function(k) {
     dtest  <- slice(dall, folds[[k]])
     # code originally contributed by @RolandASc on stackoverflow
@@ -201,12 +202,7 @@ xgb.cv <- function(params = list(), data, nrounds, nfold, label = NULL, missing
        dtrain <- slice(dall, unlist(folds[-k]))
     else
        dtrain <- slice(dall, train_folds[[k]])
-    handle <- xgb.Booster.handle(
-      params = params,
-      cachelist = list(dtrain, dtest),
-      modelfile = NULL,
-      handle = NULL
-    )
+    handle <- xgb.Booster.handle(params, list(dtrain, dtest))
     list(dtrain = dtrain, bst = handle, watchlist = list(train = dtrain, test = dtest), index = folds[[k]])
   })
   rm(dall)
@@ -227,18 +223,8 @@ xgb.cv <- function(params = list(), data, nrounds, nfold, label = NULL, missing
     for (f in cb$pre_iter) f()
 
     msg <- lapply(bst_folds, function(fd) {
-      xgb.iter.update(
-        booster_handle = fd$bst,
-        dtrain = fd$dtrain,
-        iter = iteration - 1,
-        obj = obj
-      )
-      xgb.iter.eval(
-        booster_handle = fd$bst,
-        watchlist = fd$watchlist,
-        iter = iteration - 1,
-        feval = feval
-      )
+      xgb.iter.update(fd$bst, fd$dtrain, iteration - 1, obj)
+      xgb.iter.eval(fd$bst, fd$watchlist, iteration - 1, feval)
     })
     msg <- simplify2array(msg)
     bst_evaluation <- rowMeans(msg)

R-package/R/xgb.ggplot.R

@@ -142,7 +142,6 @@ xgb.ggplot.shap.summary <- function(data, shap_contrib = NULL, features = NULL,
 #'
 #' @return A data.table containing the observation ID, the feature name, the
 #'   feature value (normalized if specified), and the SHAP contribution value.
-#' @noRd
 prepare.ggplot.shap.data <- function(data_list, normalize = FALSE) {
   data <- data_list[["data"]]
   shap_contrib <- data_list[["shap_contrib"]]
@@ -171,7 +170,6 @@ prepare.ggplot.shap.data <- function(data_list, normalize = FALSE) {
 #' @param x Numeric vector
 #'
 #' @return Numeric vector with mean 0 and sd 1.
-#' @noRd
 normalize <- function(x) {
   loc <- mean(x, na.rm = TRUE)
   scale <- stats::sd(x, na.rm = TRUE)
@@ -183,7 +181,7 @@ normalize <- function(x) {
 # ... the plots
 # cols number of columns
 # internal utility function
-multiplot <- function(..., cols) {
+multiplot <- function(..., cols = 1) {
   plots <- list(...)
   num_plots <- length(plots)
 

R-package/R/xgb.load.R

@@ -35,12 +35,7 @@ xgb.load <- function(modelfile) {
   if (is.null(modelfile))
     stop("xgb.load: modelfile cannot be NULL")
 
-  handle <- xgb.Booster.handle(
-    params = list(),
-    cachelist = list(),
-    modelfile = modelfile,
-    handle = NULL
-  )
+  handle <- xgb.Booster.handle(modelfile = modelfile)
   # re-use modelfile if it is raw so we do not need to serialize
   if (typeof(modelfile) == "raw") {
     warning(
@@ -50,9 +45,9 @@ xgb.load <- function(modelfile) {
         " `xgb.unserialize` instead. "
       )
     )
-    bst <- xgb.handleToBooster(handle = handle, raw = modelfile)
+    bst <- xgb.handleToBooster(handle, modelfile)
   } else {
-    bst <- xgb.handleToBooster(handle = handle, raw = NULL)
+    bst <- xgb.handleToBooster(handle, NULL)
   }
   bst <- xgb.Booster.complete(bst, saveraw = TRUE)
   return(bst)

R-package/R/xgb.model.dt.tree.R

@@ -86,7 +86,8 @@ xgb.model.dt.tree <- function(feature_names = NULL, model = NULL, text = NULL,
     text <- xgb.dump(model = model, with_stats = TRUE)
   }
 
-  if (length(text) < 2 || !any(grepl('leaf=(\\d+)', text))) {
+  if (length(text) < 2 ||
+      sum(grepl('leaf=(\\d+)', text)) < 1) {
     stop("Non-tree model detected! This function can only be used with tree models.")
   }
 

R-package/R/xgb.plot.deepness.R

@@ -136,7 +136,7 @@ get.leaf.depth <- function(dt_tree) {
     # list of paths to each leaf in a tree
     paths <- lapply(paths_tmp$vpath, names)
     # combine into a resulting path lengths table for a tree
-    data.table(Depth = lengths(paths), ID = To[Leaf == TRUE])
+    data.table(Depth = sapply(paths, length), ID = To[Leaf == TRUE])
   }, by = Tree]
 }
 

R-package/R/xgb.plot.shap.R

@@ -193,7 +193,7 @@ xgb.plot.shap <- function(data, shap_contrib = NULL, features = NULL, top_n = 1,
 #' hence allows us to see which features have a negative / positive contribution
 #' on the model prediction, and whether the contribution is different for larger
 #' or smaller values of the feature. We effectively try to replicate the
-#' \code{summary_plot} function from https://github.com/shap/shap.
+#' \code{summary_plot} function from https://github.com/slundberg/shap.
 #'
 #' @inheritParams xgb.plot.shap
 #'
@@ -202,7 +202,7 @@ xgb.plot.shap <- function(data, shap_contrib = NULL, features = NULL, top_n = 1,
 #'
 #' @examples # See \code{\link{xgb.plot.shap}}.
 #' @seealso \code{\link{xgb.plot.shap}}, \code{\link{xgb.ggplot.shap.summary}},
-#'   \url{https://github.com/shap/shap}
+#'   \url{https://github.com/slundberg/shap}
 xgb.plot.shap.summary <- function(data, shap_contrib = NULL, features = NULL, top_n = 10, model = NULL,
                                   trees = NULL, target_class = NULL, approxcontrib = FALSE, subsample = NULL) {
   # Only ggplot implementation is available.

R-package/R/xgb.save.R

@@ -43,6 +43,6 @@ xgb.save <- function(model, fname) {
   }
   model <- xgb.Booster.complete(model, saveraw = FALSE)
   fname <- path.expand(fname)
-  .Call(XGBoosterSaveModel_R, model$handle, enc2utf8(fname[1]))
+  .Call(XGBoosterSaveModel_R, model$handle, fname[1])
   return(TRUE)
 }

R-package/R/xgb.train.R

@@ -363,13 +363,8 @@ xgb.train <- function(params = list(), data, nrounds, watchlist = list(),
   is_update <- NVL(params[['process_type']], '.') == 'update'
 
   # Construct a booster (either a new one or load from xgb_model)
-  handle <- xgb.Booster.handle(
-    params = params,
-    cachelist = append(watchlist, dtrain),
-    modelfile = xgb_model,
-    handle = NULL
-  )
-  bst <- xgb.handleToBooster(handle = handle, raw = NULL)
+  handle <- xgb.Booster.handle(params, append(watchlist, dtrain), xgb_model)
+  bst <- xgb.handleToBooster(handle)
 
   # extract parameters that can affect the relationship b/w #trees and #iterations
   num_class <- max(as.numeric(NVL(params[['num_class']], 1)), 1)
@@ -395,21 +390,10 @@ xgb.train <- function(params = list(), data, nrounds, watchlist = list(),
 
     for (f in cb$pre_iter) f()
 
-    xgb.iter.update(
-        booster_handle = bst$handle,
-        dtrain = dtrain,
-        iter = iteration - 1,
-        obj = obj
-    )
+    xgb.iter.update(bst$handle, dtrain, iteration - 1, obj)
 
-    if (length(watchlist) > 0) {
-      bst_evaluation <- xgb.iter.eval(  # nolint: object_usage_linter
-        booster_handle = bst$handle,
-        watchlist = watchlist,
-        iter = iteration - 1,
-        feval = feval
-      )
-    }
+    if (length(watchlist) > 0)
+      bst_evaluation <- xgb.iter.eval(bst$handle, watchlist, iteration - 1, feval)  # nolint: object_usage_linter
 
     xgb.attr(bst$handle, 'niter') <- iteration - 1
 

R-package/R/xgboost.R

@@ -10,13 +10,7 @@ xgboost <- function(data = NULL, label = NULL, missing = NA, weight = NULL,
                     save_period = NULL, save_name = "xgboost.model",
                     xgb_model = NULL, callbacks = list(), ...) {
   merged <- check.booster.params(params, ...)
-  dtrain <- xgb.get.DMatrix(
-    data = data,
-    label = label,
-    missing = missing,
-    weight = weight,
-    nthread = merged$nthread
-  )
+  dtrain <- xgb.get.DMatrix(data, label, missing, weight, nthread = merged$nthread)
 
   watchlist <- list(train = dtrain)
 

R-package/configure

@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.71 for xgboost 2.0.3.
+# Generated by GNU Autoconf 2.71 for xgboost 2.0.0.
 #
 #
 # Copyright (C) 1992-1996, 1998-2017, 2020-2021 Free Software Foundation,
@@ -607,8 +607,8 @@ MAKEFLAGS=
 # Identity of this package.
 PACKAGE_NAME='xgboost'
 PACKAGE_TARNAME='xgboost'
-PACKAGE_VERSION='2.0.3'
-PACKAGE_STRING='xgboost 2.0.3'
+PACKAGE_VERSION='2.0.0'
+PACKAGE_STRING='xgboost 2.0.0'
 PACKAGE_BUGREPORT=''
 PACKAGE_URL=''
 
@@ -1225,7 +1225,7 @@ if test "$ac_init_help" = "long"; then
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures xgboost 2.0.3 to adapt to many kinds of systems.
+\`configure' configures xgboost 2.0.0 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1287,7 +1287,7 @@ fi
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
-     short | recursive ) echo "Configuration of xgboost 2.0.3:";;
+     short | recursive ) echo "Configuration of xgboost 2.0.0:";;
    esac
   cat <<\_ACEOF
 
@@ -1367,7 +1367,7 @@ fi
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-xgboost configure 2.0.3
+xgboost configure 2.0.0
 generated by GNU Autoconf 2.71
 
 Copyright (C) 2021 Free Software Foundation, Inc.
@@ -1533,7 +1533,7 @@ cat >config.log <<_ACEOF
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by xgboost $as_me 2.0.3, which was
+It was created by xgboost $as_me 2.0.0, which was
 generated by GNU Autoconf 2.71.  Invocation command line was
 
   $ $0$ac_configure_args_raw
@@ -3412,7 +3412,7 @@ cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by xgboost $as_me 2.0.3, which was
+This file was extended by xgboost $as_me 2.0.0, which was
 generated by GNU Autoconf 2.71.  Invocation command line was
 
   CONFIG_FILES    = $CONFIG_FILES
@@ -3467,7 +3467,7 @@ ac_cs_config_escaped=`printf "%s\n" "$ac_cs_config" | sed "s/^ //; s/'/'\\\\\\\\
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config='$ac_cs_config_escaped'
 ac_cs_version="\\
-xgboost config.status 2.0.3
+xgboost config.status 2.0.0
 configured by $0, generated by GNU Autoconf 2.71,
   with options \\"\$ac_cs_config\\"
 

R-package/configure.ac

@@ -2,7 +2,7 @@
 
 AC_PREREQ(2.69)
 
-AC_INIT([xgboost],[2.0.3],[],[xgboost],[])
+AC_INIT([xgboost],[2.0.0],[],[xgboost],[])
 
 : ${R_HOME=`R RHOME`}
 if test -z "${R_HOME}"; then

R-package/demo/interaction_constraints.R

@@ -44,7 +44,7 @@ treeInteractions <- function(input_tree, input_max_depth) {
 
   # Remove non-interactions (same variable)
   interaction_list <- lapply(interaction_list, unique)  # remove same variables
-  interaction_length <- lengths(interaction_list)
+  interaction_length <- sapply(interaction_list, length)
   interaction_list <- interaction_list[interaction_length > 1]
   interaction_list <- unique(lapply(interaction_list, sort))
   return(interaction_list)

R-package/man/normalize.Rd

@@ -0,0 +1,18 @@
+% Generated by roxygen2: do not edit by hand
+% Please edit documentation in R/xgb.ggplot.R
+\name{normalize}
+\alias{normalize}
+\title{Scale feature value to have mean 0, standard deviation 1}
+\usage{
+normalize(x)
+}
+\arguments{
+\item{x}{Numeric vector}
+}
+\value{
+Numeric vector with mean 0 and sd 1.
+}
+\description{
+This is used to compare multiple features on the same plot.
+Internal utility function
+}

R-package/man/prepare.ggplot.shap.data.Rd

@@ -0,0 +1,27 @@
+% Generated by roxygen2: do not edit by hand
+% Please edit documentation in R/xgb.ggplot.R
+\name{prepare.ggplot.shap.data}
+\alias{prepare.ggplot.shap.data}
+\title{Combine and melt feature values and SHAP contributions for sample
+observations.}
+\usage{
+prepare.ggplot.shap.data(data_list, normalize = FALSE)
+}
+\arguments{
+\item{data_list}{List containing 'data' and 'shap_contrib' returned by
+\code{xgb.shap.data()}.}
+
+\item{normalize}{Whether to standardize feature values to have mean 0 and
+standard deviation 1 (useful for comparing multiple features on the same
+plot). Default \code{FALSE}.}
+}
+\value{
+A data.table containing the observation ID, the feature name, the
+  feature value (normalized if specified), and the SHAP contribution value.
+}
+\description{
+Conforms to data format required for ggplot functions.
+}
+\details{
+Internal utility function.
+}

R-package/man/xgb.plot.shap.summary.Rd

@@ -67,12 +67,12 @@ Each point (observation) is coloured based on its feature value. The plot
 hence allows us to see which features have a negative / positive contribution
 on the model prediction, and whether the contribution is different for larger
 or smaller values of the feature. We effectively try to replicate the
-\code{summary_plot} function from https://github.com/shap/shap.
+\code{summary_plot} function from https://github.com/slundberg/shap.
 }
 \examples{
 # See \code{\link{xgb.plot.shap}}.
 }
 \seealso{
 \code{\link{xgb.plot.shap}}, \code{\link{xgb.ggplot.shap.summary}},
-  \url{https://github.com/shap/shap}
+  \url{https://github.com/slundberg/shap}
 }

R-package/src/Makevars.in

@@ -47,7 +47,6 @@ OBJECTS= \
     $(PKGROOT)/src/data/data.o \
     $(PKGROOT)/src/data/sparse_page_raw_format.o \
     $(PKGROOT)/src/data/ellpack_page.o \
-    $(PKGROOT)/src/data/file_iterator.o \
     $(PKGROOT)/src/data/gradient_index.o \
     $(PKGROOT)/src/data/gradient_index_page_source.o \
     $(PKGROOT)/src/data/gradient_index_format.o \
@@ -69,8 +68,6 @@ OBJECTS= \
     $(PKGROOT)/src/tree/updater_quantile_hist.o \
     $(PKGROOT)/src/tree/updater_refresh.o \
     $(PKGROOT)/src/tree/updater_sync.o \
-    $(PKGROOT)/src/tree/hist/param.o \
-    $(PKGROOT)/src/tree/hist/histogram.o \
     $(PKGROOT)/src/linear/linear_updater.o \
     $(PKGROOT)/src/linear/updater_coordinate.o \
     $(PKGROOT)/src/linear/updater_shotgun.o \
@@ -85,7 +82,6 @@ OBJECTS= \
     $(PKGROOT)/src/common/charconv.o \
     $(PKGROOT)/src/common/column_matrix.o \
     $(PKGROOT)/src/common/common.o \
-    $(PKGROOT)/src/common/error_msg.o \
     $(PKGROOT)/src/common/hist_util.o \
     $(PKGROOT)/src/common/host_device_vector.o \
     $(PKGROOT)/src/common/io.o \

R-package/src/Makevars.win

@@ -47,7 +47,6 @@ OBJECTS= \
     $(PKGROOT)/src/data/data.o \
     $(PKGROOT)/src/data/sparse_page_raw_format.o \
     $(PKGROOT)/src/data/ellpack_page.o \
-    $(PKGROOT)/src/data/file_iterator.o \
     $(PKGROOT)/src/data/gradient_index.o \
     $(PKGROOT)/src/data/gradient_index_page_source.o \
     $(PKGROOT)/src/data/gradient_index_format.o \
@@ -69,8 +68,6 @@ OBJECTS= \
     $(PKGROOT)/src/tree/updater_quantile_hist.o \
     $(PKGROOT)/src/tree/updater_refresh.o \
     $(PKGROOT)/src/tree/updater_sync.o \
-    $(PKGROOT)/src/tree/hist/param.o \
-    $(PKGROOT)/src/tree/hist/histogram.o \
     $(PKGROOT)/src/linear/linear_updater.o \
     $(PKGROOT)/src/linear/updater_coordinate.o \
     $(PKGROOT)/src/linear/updater_shotgun.o \
@@ -85,7 +82,6 @@ OBJECTS= \
     $(PKGROOT)/src/common/charconv.o \
     $(PKGROOT)/src/common/column_matrix.o \
     $(PKGROOT)/src/common/common.o \
-    $(PKGROOT)/src/common/error_msg.o \
     $(PKGROOT)/src/common/hist_util.o \
     $(PKGROOT)/src/common/host_device_vector.o \
     $(PKGROOT)/src/common/io.o \

R-package/src/xgboost_R.cc

@@ -120,25 +120,11 @@ XGB_DLL SEXP XGDMatrixCreateFromMat_R(SEXP mat, SEXP missing, SEXP n_threads) {
   ctx.nthread = asInteger(n_threads);
   std::int32_t threads = ctx.Threads();
 
-  if (is_int) {
   xgboost::common::ParallelFor(nrow, threads, [&](xgboost::omp_ulong i) {
     for (size_t j = 0; j < ncol; ++j) {
-        auto v = iin[i + nrow * j];
-        if (v == NA_INTEGER) {
-          data[i * ncol + j] = std::numeric_limits<float>::quiet_NaN();
-        } else {
-          data[i * ncol + j] = static_cast<float>(v);
-        }
+      data[i * ncol + j] = is_int ? static_cast<float>(iin[i + nrow * j]) : din[i + nrow * j];
     }
   });
-  } else {
-    xgboost::common::ParallelFor(nrow, threads, [&](xgboost::omp_ulong i) {
-      for (size_t j = 0; j < ncol; ++j) {
-        data[i * ncol + j] = din[i + nrow * j];
-      }
-    });
-  }
-
   DMatrixHandle handle;
   CHECK_CALL(XGDMatrixCreateFromMat_omp(BeginPtr(data), nrow, ncol,
                                         asReal(missing), &handle, threads));

R-package/tests/testthat/test_dmatrix.R

@@ -56,42 +56,6 @@ test_that("xgb.DMatrix: basic construction", {
   expect_equal(raw_fd, raw_dgc)
 })
 
-test_that("xgb.DMatrix: NA", {
-  n_samples <- 3
-  x <- cbind(
-    x1 = sample(x = 4, size = n_samples, replace = TRUE),
-    x2 = sample(x = 4, size = n_samples, replace = TRUE)
-  )
-  x[1, "x1"] <- NA
-
-  m <- xgb.DMatrix(x)
-  xgb.DMatrix.save(m, "int.dmatrix")
-
-  x <- matrix(as.numeric(x), nrow = n_samples, ncol = 2)
-  colnames(x) <- c("x1", "x2")
-  m <- xgb.DMatrix(x)
-
-  xgb.DMatrix.save(m, "float.dmatrix")
-
-  iconn <- file("int.dmatrix", "rb")
-  fconn <- file("float.dmatrix", "rb")
-
-  expect_equal(file.size("int.dmatrix"), file.size("float.dmatrix"))
-
-  bytes <- file.size("int.dmatrix")
-  idmatrix <- readBin(iconn, "raw", n = bytes)
-  fdmatrix <- readBin(fconn, "raw", n = bytes)
-
-  expect_equal(length(idmatrix), length(fdmatrix))
-  expect_equal(idmatrix, fdmatrix)
-
-  close(iconn)
-  close(fconn)
-
-  file.remove("int.dmatrix")
-  file.remove("float.dmatrix")
-})
-
 test_that("xgb.DMatrix: saving, loading", {
   # save to a local file
   dtest1 <- xgb.DMatrix(test_data, label = test_label)
@@ -108,7 +72,6 @@ test_that("xgb.DMatrix: saving, loading", {
   tmp <- c("0 1:1 2:1", "1 3:1", "0 1:1")
   tmp_file <- tempfile(fileext = ".libsvm")
   writeLines(tmp, tmp_file)
-  expect_true(file.exists(tmp_file))
   dtest4 <- xgb.DMatrix(paste(tmp_file, "?format=libsvm", sep = ""), silent = TRUE)
   expect_equal(dim(dtest4), c(3, 4))
   expect_equal(getinfo(dtest4, 'label'), c(0, 1, 0))

R-package/tests/testthat/test_helpers.R

@@ -189,7 +189,7 @@ test_that("SHAPs sum to predictions, with or without DART", {
     tol <- 1e-5
 
     expect_equal(rowSums(shap), pred, tol = tol)
-    expect_equal(rowSums(shapi), pred, tol = tol)
+    expect_equal(apply(shapi, 1, sum), pred, tol = tol)
     for (i in seq_len(nrow(d)))
       for (f in list(rowSums, colSums))
         expect_equal(f(shapi[i, , ]), shap[i, ], tol = tol)

R-package/tests/testthat/test_unicode.R

@@ -1,21 +0,0 @@
-context("Test Unicode handling")
-
-data(agaricus.train, package = 'xgboost')
-data(agaricus.test, package = 'xgboost')
-train <- agaricus.train
-test <- agaricus.test
-set.seed(1994)
-
-test_that("Can save and load models with Unicode paths", {
-  nrounds <- 2
-  bst <- xgboost(data = train$data, label = train$label, max_depth = 2,
-                 eta = 1, nthread = 2, nrounds = nrounds, objective = "binary:logistic",
-                 eval_metric = "error")
-  tmpdir <- tempdir()
-  lapply(c("모델.json", "がうる・ぐら.json", "类继承.ubj"), function(x) {
-    path <- file.path(tmpdir, x)
-    xgb.save(bst, path)
-    bst2 <- xgb.load(path)
-    expect_equal(predict(bst, test$data), predict(bst2, test$data))
-  })
-})

R-package/vignettes/discoverYourData.Rmd

@@ -51,24 +51,24 @@ A *categorical* variable has a fixed number of different values. For instance, i
 >
 > Type `?factor` in the console for more information.
 
-To answer the question above we will convert *categorical* variables to `numeric` ones.
+To answer the question above we will convert *categorical* variables to `numeric` one.
 
 ### Conversion from categorical to numeric variables
 
 #### Looking at the raw data
 
-+In this Vignette we will see how to transform a *dense* `data.frame` (*dense* = the majority of the matrix is non-zero) with *categorical* variables to a very *sparse* matrix (*sparse* = lots of zero entries in the matrix) of `numeric` features.
+In this Vignette we will see how to transform a *dense* `data.frame` (*dense* = few zeroes in the matrix) with *categorical* variables to a very *sparse* matrix (*sparse* = lots of zero in the matrix) of `numeric` features.
 
 The method we are going to see is usually called [one-hot encoding](https://en.wikipedia.org/wiki/One-hot).
 
-The first step is to load the `Arthritis` dataset in memory and wrap it with the `data.table` package.
+The first step is to load `Arthritis` dataset in memory and wrap it with `data.table` package.
 
 ```{r, results='hide'}
 data(Arthritis)
 df <- data.table(Arthritis, keep.rownames = FALSE)
 ```
 
-> `data.table` is 100% compliant with **R** `data.frame` but its syntax is more consistent and its performance for large dataset is [best in class](https://stackoverflow.com/questions/21435339/data-table-vs-dplyr-can-one-do-something-well-the-other-cant-or-does-poorly) (`dplyr` from **R** and `Pandas` from **Python** [included](https://github.com/Rdatatable/data.table/wiki/Benchmarks-%3A-Grouping)). Some parts of **XGBoost's** **R** package use `data.table`.
+> `data.table` is 100% compliant with **R** `data.frame` but its syntax is more consistent and its performance for large dataset is [best in class](https://stackoverflow.com/questions/21435339/data-table-vs-dplyr-can-one-do-something-well-the-other-cant-or-does-poorly) (`dplyr` from **R** and `Pandas` from **Python** [included](https://github.com/Rdatatable/data.table/wiki/Benchmarks-%3A-Grouping)). Some parts of **XGBoost** **R** package use `data.table`.
 
 The first thing we want to do is to have a look to the first few lines of the `data.table`:
 
@@ -95,19 +95,19 @@ We will add some new *categorical* features to see if it helps.
 
 ##### Grouping per 10 years
 
-For the first features we create groups of age by rounding the real age.
+For the first feature we create groups of age by rounding the real age.
 
-Note that we transform it to `factor` so the algorithm treats these age groups as independent values.
+Note that we transform it to `factor` so the algorithm treat these age groups as independent values.
 
-Therefore, 20 is not closer to 30 than 60. In other words, the distance between ages is lost in this transformation.
+Therefore, 20 is not closer to 30 than 60. To make it short, the distance between ages is lost in this transformation.
 
 ```{r}
 head(df[, AgeDiscret := as.factor(round(Age / 10, 0))])
 ```
 
-##### Randomly split into two groups
+##### Random split into two groups
 
-The following is an even stronger simplification of the real age with an arbitrary split at 30 years old. I choose this value **based on nothing**. We will see later if simplifying the information based on arbitrary values is a good strategy (you may already have an idea of how well it will work...).
+Following is an even stronger simplification of the real age with an arbitrary split at 30 years old. We choose this value **based on nothing**. We will see later if simplifying the information based on arbitrary values is a good strategy (you may already have an idea of how well it will work...).
 
 ```{r}
 head(df[, AgeCat := as.factor(ifelse(Age > 30, "Old", "Young"))])
@@ -119,7 +119,7 @@ These new features are highly correlated to the `Age` feature because they are s
 
 For many machine learning algorithms, using correlated features is not a good idea. It may sometimes make prediction less accurate, and most of the time make interpretation of the model almost impossible. GLM, for instance, assumes that the features are uncorrelated.
 
-Fortunately, decision tree algorithms (including boosted trees) are very robust to these features. Therefore we don't have to do anything to manage this situation.
+Fortunately, decision tree algorithms (including boosted trees) are very robust to these features. Therefore we have nothing to do to manage this situation.
 
 ##### Cleaning data
 
@@ -144,7 +144,7 @@ We will use the [dummy contrast coding](https://stats.oarc.ucla.edu/r/library/r-
 
 The purpose is to transform each value of each *categorical* feature into a *binary* feature `{0, 1}`.
 
-For example, the column `Treatment` will be replaced by two columns, `TreatmentPlacebo`, and `TreatmentTreated`. Each of them will be *binary*. Therefore, an observation which has the value `Placebo` in column `Treatment` before the transformation will have the value `1` in the new column `TreatmentPlacebo` and the value `0` in the new column `TreatmentTreated` after the transformation. The column `TreatmentPlacebo` will disappear during the contrast encoding, as it would be absorbed into a common constant intercept column.
+For example, the column `Treatment` will be replaced by two columns, `TreatmentPlacebo`, and `TreatmentTreated`. Each of them will be *binary*. Therefore, an observation which has the value `Placebo` in column `Treatment` before the transformation will have after the transformation the value `1` in the new column `TreatmentPlacebo` and the value `0` in the new column `TreatmentTreated`. The column `TreatmentPlacebo` will disappear during the contrast encoding, as it would be absorbed into a common constant intercept column.
 
 Column `Improved` is excluded because it will be our `label` column, the one we want to predict.
 
@@ -176,9 +176,13 @@ bst <- xgboost(data = sparse_matrix, label = output_vector, max_depth = 4,
 
 ```
 
-You can see some `train-logloss: 0.XXXXX` lines followed by a number. It decreases. Each line shows how well the model explains the data. Lower is better.
+You can see some `train-error: 0.XXXXX` lines followed by a number. It decreases. Each line shows how well the model explains your data. Lower is better.
 
-A small value for training error may be a symptom of [overfitting](https://en.wikipedia.org/wiki/Overfitting), meaning the model will not accurately predict unseen values.
+A small value for training error may be a symptom of [overfitting](https://en.wikipedia.org/wiki/Overfitting), meaning the model will not accurately predict the future values.
+
+> Here you can see the numbers decrease until line 7 and then increase.
+>
+> It probably means we are overfitting. To fix that I should reduce the number of rounds to `nrounds = 4`. I will let things like that because I don't really care for the purpose of this example :-)
 
 Feature importance
 ------------------
@@ -195,35 +199,64 @@ importance <- xgb.importance(feature_names = colnames(sparse_matrix), model = bs
 head(importance)
 ```
 
-> The column `Gain` provides the information we are looking for.
+> The column `Gain` provide the information we are looking for.
 >
 > As you can see, features are classified by `Gain`.
 
-`Gain` is the improvement in accuracy brought by a feature to the branches it is on. The idea is that before adding a new split on a feature X to the branch there were some wrongly classified elements; after adding the split on this feature, there are two new branches, and each of these branches is more accurate (one branch saying if your observation is on this branch then it should be classified as `1`, and the other branch saying the exact opposite).
+`Gain` is the improvement in accuracy brought by a feature to the branches it is on. The idea is that before adding a new split on a feature X to the branch there was some wrongly classified elements, after adding the split on this feature, there are two new branches, and each of these branch is more accurate (one branch saying if your observation is on this branch then it should be classified as `1`, and the other branch saying the exact opposite).
 
-`Cover` is related to the second order derivative (or Hessian) of the loss function with respect to a particular variable; thus, a large value indicates a variable has a large potential impact on the loss function and so is important.
+`Cover` measures the relative quantity of observations concerned by a feature.
 
 `Frequency` is a simpler way to measure the `Gain`. It just counts the number of times a feature is used in all generated trees. You should not use it (unless you know why you want to use it).
 
+#### Improvement in the interpretability of feature importance data.table
+
+We can go deeper in the analysis of the model. In the `data.table` above, we have discovered which features counts to predict if the illness will go or not. But we don't yet know the role of these features. For instance, one of the question we may want to answer would be: does receiving a placebo treatment helps to recover from the illness?
+
+One simple solution is to count the co-occurrences of a feature and a class of the classification.
+
+For that purpose we will execute the same function as above but using two more parameters, `data` and `label`.
+
+```{r}
+importanceRaw <- xgb.importance(feature_names = colnames(sparse_matrix), model = bst, data = sparse_matrix, label = output_vector)
+
+# Cleaning for better display
+importanceClean <- importanceRaw[, `:=`(Cover = NULL, Frequency = NULL)]
+
+head(importanceClean)
+```
+
+> In the table above we have removed two not needed columns and select only the first lines.
+
+First thing you notice is the new column `Split`. It is the split applied to the feature on a branch of one of the tree. Each split is present, therefore a feature can appear several times in this table. Here we can see the feature `Age` is used several times with different splits.
+
+How the split is applied to count the co-occurrences? It is always `<`. For instance, in the second line, we measure the number of persons under 61.5 years with the illness gone after the treatment.
+
+The two other new columns are `RealCover` and `RealCover %`. In the first column it measures the number of observations in the dataset where the split is respected and the label marked as `1`. The second column is the percentage of the whole population that `RealCover` represents.
+
+Therefore, according to our findings, getting a placebo doesn't seem to help but being younger than 61 years may help (seems logic).
+
+> You may wonder how to interpret the `< 1.00001` on the first line. Basically, in a sparse `Matrix`, there is no `0`, therefore, looking for one hot-encoded categorical observations validating the rule `< 1.00001` is like just looking for `1` for this feature.
+
 ### Plotting the feature importance
 
+
 All these things are nice, but it would be even better to plot the results.
 
 ```{r, fig.width=8, fig.height=5, fig.align='center'}
 xgb.plot.importance(importance_matrix = importance)
 ```
 
-Running this line of code, you should get a bar chart showing the importance of the 6 features (containing the same data as the output we saw earlier, but displaying it visually for easier consumption).  Note that `xgb.ggplot.importance` is also available for all the ggplot2 fans!
+Feature have automatically been divided in 2 clusters: the interesting features... and the others.
 
 > Depending of the dataset and the learning parameters you may have more than two clusters. Default value is to limit them to `10`, but you can increase this limit. Look at the function documentation for more information.
 
 According to the plot above, the most important features in this dataset to predict if the treatment will work are :
 
-* An individual's age;
-* Having received a placebo or not;
-* Gender;
-* Our generated feature AgeDiscret. We can see that its contribution is very low.
-
+* the Age ;
+* having received a placebo or not ;
+* the sex is third but already included in the not interesting features group ;
+* then we see our generated features (AgeDiscret). We can see that their contribution is very low.
 
 ### Do these results make sense?
 
@@ -237,53 +270,53 @@ c2 <- chisq.test(df$Age, output_vector)
 print(c2)
 ```
 
-The Pearson correlation between Age and illness disappearing is **`r round(c2$statistic, 2 )`**.
+Pearson correlation between Age and illness disappearing is **`r round(c2$statistic, 2 )`**.
 
 ```{r, warning=FALSE, message=FALSE}
 c2 <- chisq.test(df$AgeDiscret, output_vector)
 print(c2)
 ```
 
-Our first simplification of Age gives a Pearson correlation of **`r round(c2$statistic, 2)`**.
+Our first simplification of Age gives a Pearson correlation is **`r round(c2$statistic, 2)`**.
 
 ```{r, warning=FALSE, message=FALSE}
 c2 <- chisq.test(df$AgeCat, output_vector)
 print(c2)
 ```
 
-The perfectly random split we did between young and old at 30 years old has a low correlation of **2.36**. This suggests that, for the particular illness we are studying, the age at which someone is vulnerable to this disease is likely very different from 30.
+The perfectly random split I did between young and old at 30 years old have a low correlation of **`r round(c2$statistic, 2)`**. It's a result we may expect as may be in my mind > 30 years is being old (I am 32 and starting feeling old, this may explain that), but for the illness we are studying, the age to be vulnerable is not the same.
 
-Moral of the story: don't let your *gut* lower the quality of your model.
+Morality: don't let your *gut* lower the quality of your model.
 
-In *data science*, there is the word *science* :-)
+In *data science* expression, there is the word *science* :-)
 
 Conclusion
 ----------
 
 As you can see, in general *destroying information by simplifying it won't improve your model*. **Chi2** just demonstrates that.
 
-But in more complex cases, creating a new feature from an existing one may help the algorithm and improve the model.
+But in more complex cases, creating a new feature based on existing one which makes link with the outcome more obvious may help the algorithm and improve the model.
 
-+The case studied here is not complex enough to show that. Check [Kaggle website](https://www.kaggle.com/) for some challenging datasets.
+The case studied here is not enough complex to show that. Check [Kaggle website](http://www.kaggle.com/) for some challenging datasets. However it's almost always worse when you add some arbitrary rules.
 
-Moreover, you can see that even if we have added some new features which are not very useful/highly correlated with other features, the boosting tree algorithm was still able to choose the best one (which in this case is the Age).
+Moreover, you can notice that even if we have added some not useful new features highly correlated with other features, the boosting tree algorithm have been able to choose the best one, which in this case is the Age.
 
-Linear models may not perform as well.
+Linear model may not be that smart in this scenario.
 
 Special Note: What about Random Forests™?
 -----------------------------------------
 
-As you may know, the [Random Forests](https://en.wikipedia.org/wiki/Random_forest) algorithm is cousin with boosting and both are part of the [ensemble learning](https://en.wikipedia.org/wiki/Ensemble_learning) family.
+As you may know, [Random Forests](https://en.wikipedia.org/wiki/Random_forest) algorithm is cousin with boosting and both are part of the [ensemble learning](https://en.wikipedia.org/wiki/Ensemble_learning) family.
 
-Both train several decision trees for one dataset. The *main* difference is that in Random Forests, trees are independent and in boosting, the `N+1`-st tree focuses its learning on the loss (<=> what has not been well modeled by the tree `N`).
+Both trains several decision trees for one dataset. The *main* difference is that in Random Forests, trees are independent and in boosting, the tree `N+1` focus its learning on the loss (<=> what has not been well modeled by the tree `N`).
 
-This difference can have an impact on a edge case in feature importance analysis: *correlated features*.
+This difference have an impact on a corner case in feature importance analysis: the *correlated features*.
 
 Imagine two features perfectly correlated, feature `A` and feature `B`. For one specific tree, if the algorithm needs one of them, it will choose randomly (true in both boosting and Random Forests).
 
-However, in Random Forests this random choice will be done for each tree, because each tree is independent from the others. Therefore, approximately (and depending on your parameters) 50% of the trees will choose feature `A` and the other 50% will choose feature `B`. So the *importance* of the information contained in `A` and `B` (which is the same, because they are perfectly correlated) is diluted in `A` and `B`. So you won't easily know this information is important to predict what you want to predict! It is even worse when you have 10 correlated features...
+However, in Random Forests this random choice will be done for each tree, because each tree is independent from the others. Therefore, approximatively, depending of your parameters, 50% of the trees will choose feature `A` and the other 50% will choose feature `B`. So the *importance* of the information contained in `A` and `B` (which is the same, because they are perfectly correlated) is diluted in `A` and `B`. So you won't easily know this information is important to predict what you want to predict! It is even worse when you have 10 correlated features...
 
-In boosting, when a specific link between feature and outcome have been learned by the algorithm, it will try to not refocus on it (in theory it is what happens, reality is not always that simple). Therefore, all the importance will be on feature `A` or on feature `B` (but not both). You will know that one feature has an important role in the link between the observations and the label. It is still up to you to search for the correlated features to the one detected as important if you need to know all of them.
+In boosting, when a specific link between feature and outcome have been learned by the algorithm, it will try to not refocus on it (in theory it is what happens, reality is not always that simple). Therefore, all the importance will be on feature `A` or on feature `B` (but not both). You will know that one feature have an important role in the link between the observations and the label. It is still up to you to search for the correlated features to the one detected as important if you need to know all of them.
 
 If you want to try Random Forests algorithm, you can tweak XGBoost parameters!
 

README.md

@@ -48,6 +48,7 @@ Become a sponsor and get a logo here. See details at [Sponsoring the XGBoost Pro
 
 <a href="https://www.nvidia.com/en-us/" target="_blank"><img src="https://raw.githubusercontent.com/xgboost-ai/xgboost-ai.github.io/master/images/sponsors/nvidia.jpg" alt="NVIDIA" width="72" height="72"></a>
 <a href="https://www.intel.com/" target="_blank"><img src="https://images.opencollective.com/intel-corporation/2fa85c1/logo/256.png" width="72" height="72"></a>
+<a href="https://getkoffie.com/?utm_source=opencollective&utm_medium=github&utm_campaign=xgboost" target="_blank"><img src="https://images.opencollective.com/koffielabs/f391ab8/logo/256.png" width="72" height="72"></a>
 
 ### Backers
 [[Become a backer](https://opencollective.com/xgboost#backer)]

cmake/Utils.cmake

@@ -90,8 +90,8 @@ function(format_gencode_flags flags out)
   endif()
   # Set up architecture flags
   if(NOT flags)
-    if (CUDA_VERSION VERSION_GREATER_EQUAL "11.8")
-      set(flags "50;60;70;80;90")
+    if (CUDA_VERSION VERSION_GREATER_EQUAL "11.1")
+      set(flags "50;60;70;80")
     elseif (CUDA_VERSION VERSION_GREATER_EQUAL "11.0")
       set(flags "50;60;70;80")
     elseif(CUDA_VERSION VERSION_GREATER_EQUAL "10.0")
@@ -133,11 +133,6 @@ function(xgboost_set_cuda_flags target)
     $<$<COMPILE_LANGUAGE:CUDA>:-Xcompiler=${OpenMP_CXX_FLAGS}>
     $<$<COMPILE_LANGUAGE:CUDA>:-Xfatbin=-compress-all>)
 
-  if (USE_PER_THREAD_DEFAULT_STREAM)
-    target_compile_options(${target} PRIVATE
-            $<$<COMPILE_LANGUAGE:CUDA>:--default-stream per-thread>)
-  endif (USE_PER_THREAD_DEFAULT_STREAM)
-
   if (CMAKE_VERSION VERSION_GREATER_EQUAL "3.18")
     set_property(TARGET ${target} PROPERTY CUDA_ARCHITECTURES ${CMAKE_CUDA_ARCHITECTURES})
   endif (CMAKE_VERSION VERSION_GREATER_EQUAL "3.18")
@@ -177,8 +172,7 @@ function(xgboost_set_cuda_flags target)
   set_target_properties(${target} PROPERTIES
     CUDA_STANDARD 17
     CUDA_STANDARD_REQUIRED ON
-    CUDA_SEPARABLE_COMPILATION OFF
-    CUDA_RUNTIME_LIBRARY Static)
+    CUDA_SEPARABLE_COMPILATION OFF)
 endfunction(xgboost_set_cuda_flags)
 
 macro(xgboost_link_nccl target)
@@ -280,7 +274,6 @@ macro(xgboost_target_link_libraries target)
 
   if (USE_CUDA)
     xgboost_set_cuda_flags(${target})
-    target_link_libraries(${target} PUBLIC CUDA::cudart_static)
   endif (USE_CUDA)
 
   if (PLUGIN_RMM)

cmake/modules/FindNccl.cmake

@@ -52,11 +52,11 @@ endif (BUILD_WITH_SHARED_NCCL)
 
 find_path(NCCL_INCLUDE_DIR
   NAMES nccl.h
-  HINTS  ${NCCL_ROOT}/include $ENV{NCCL_ROOT}/include)
+  PATHS $ENV{NCCL_ROOT}/include ${NCCL_ROOT}/include)
 
 find_library(NCCL_LIBRARY
   NAMES ${NCCL_LIB_NAME}
-  HINTS ${NCCL_ROOT}/lib $ENV{NCCL_ROOT}/lib/)
+  PATHS $ENV{NCCL_ROOT}/lib/ ${NCCL_ROOT}/lib)
 
 message(STATUS "Using nccl library: ${NCCL_LIBRARY}")
 

demo/README.md

@@ -106,7 +106,7 @@ Please send pull requests if you find ones that are missing here.
 - Prarthana Bhat, 2nd place winner in [DYD Competition](https://datahack.analyticsvidhya.com/contest/date-your-data/). Link to [Solution](https://github.com/analyticsvidhya/DateYourData/blob/master/Prathna_Bhat_Model.R).
 
 ## Talks
-- XGBoost: A Scalable Tree Boosting System ([video] (https://www.youtube.com/watch?v=Vly8xGnNiWs) + [slides](https://speakerdeck.com/datasciencela/tianqi-chen-xgboost-overview-and-latest-news-la-meetup-talk)) by Tianqi Chen at the Los Angeles Data Science meetup
+- [XGBoost: A Scalable Tree Boosting System](http://datascience.la/xgboost-workshop-and-meetup-talk-with-tianqi-chen/) (video+slides) by Tianqi Chen at the Los Angeles Data Science meetup
 
 ## Tutorials
 

demo/c-api/basic/c-api-demo.c

@@ -53,7 +53,15 @@ int main() {
   // configure the training
   // available parameters are described here:
   //   https://xgboost.readthedocs.io/en/latest/parameter.html
-  safe_xgboost(XGBoosterSetParam(booster, "device", use_gpu ? "cuda" : "cpu"));
+  safe_xgboost(XGBoosterSetParam(booster, "tree_method", use_gpu ? "gpu_hist" : "hist"));
+  if (use_gpu) {
+    // set the GPU to use;
+    // this is not necessary, but provided here as an illustration
+    safe_xgboost(XGBoosterSetParam(booster, "gpu_id", "0"));
+  } else {
+    // avoid evaluating objective and metric on a GPU
+    safe_xgboost(XGBoosterSetParam(booster, "gpu_id", "-1"));
+  }
 
   safe_xgboost(XGBoosterSetParam(booster, "objective", "binary:logistic"));
   safe_xgboost(XGBoosterSetParam(booster, "min_child_weight", "1"));

demo/dask/cpu_survival.py

@@ -18,45 +18,43 @@ def main(client):
     # The Veterans' Administration Lung Cancer Trial
     # The Statistical Analysis of Failure Time Data by Kalbfleisch J. and Prentice R (1980)
     CURRENT_DIR = os.path.dirname(__file__)
-    df = dd.read_csv(
-        os.path.join(CURRENT_DIR, os.pardir, "data", "veterans_lung_cancer.csv")
-    )
+    df = dd.read_csv(os.path.join(CURRENT_DIR, os.pardir, 'data', 'veterans_lung_cancer.csv'))
 
     # DaskDMatrix acts like normal DMatrix, works as a proxy for local
     # DMatrix scatter around workers.
     # For AFT survival, you'd need to extract the lower and upper bounds for the label
     # and pass them as arguments to DaskDMatrix.
-    y_lower_bound = df["Survival_label_lower_bound"]
-    y_upper_bound = df["Survival_label_upper_bound"]
-    X = df.drop(["Survival_label_lower_bound", "Survival_label_upper_bound"], axis=1)
-    dtrain = DaskDMatrix(
-        client, X, label_lower_bound=y_lower_bound, label_upper_bound=y_upper_bound
-    )
+    y_lower_bound = df['Survival_label_lower_bound']
+    y_upper_bound = df['Survival_label_upper_bound']
+    X = df.drop(['Survival_label_lower_bound',
+                 'Survival_label_upper_bound'], axis=1)
+    dtrain = DaskDMatrix(client, X, label_lower_bound=y_lower_bound,
+                         label_upper_bound=y_upper_bound)
 
     # Use train method from xgboost.dask instead of xgboost.  This
     # distributed version of train returns a dictionary containing the
     # resulting booster and evaluation history obtained from
     # evaluation metrics.
-    params = {
-        "verbosity": 1,
-        "objective": "survival:aft",
-        "eval_metric": "aft-nloglik",
-        "learning_rate": 0.05,
-        "aft_loss_distribution_scale": 1.20,
-        "aft_loss_distribution": "normal",
-        "max_depth": 6,
-        "lambda": 0.01,
-        "alpha": 0.02,
-    }
-    output = xgb.dask.train(
-        client, params, dtrain, num_boost_round=100, evals=[(dtrain, "train")]
-    )
-    bst = output["booster"]
-    history = output["history"]
+    params = {'verbosity': 1,
+              'objective': 'survival:aft',
+              'eval_metric': 'aft-nloglik',
+              'learning_rate': 0.05,
+              'aft_loss_distribution_scale': 1.20,
+              'aft_loss_distribution': 'normal',
+              'max_depth': 6,
+              'lambda': 0.01,
+              'alpha': 0.02}
+    output = xgb.dask.train(client,
+                            params,
+                            dtrain,
+                            num_boost_round=100,
+                            evals=[(dtrain, 'train')])
+    bst = output['booster']
+    history = output['history']
 
     # you can pass output directly into `predict` too.
     prediction = xgb.dask.predict(client, bst, dtrain)
-    print("Evaluation history: ", history)
+    print('Evaluation history: ', history)
 
     # Uncomment the following line to save the model to the disk
     # bst.save_model('survival_model.json')
@@ -64,7 +62,7 @@ def main(client):
     return prediction
 
 
-if __name__ == "__main__":
+if __name__ == '__main__':
     # or use other clusters for scaling
     with LocalCluster(n_workers=7, threads_per_worker=4) as cluster:
         with Client(cluster) as client:

demo/dask/cpu_training.py

@@ -25,23 +25,21 @@ def main(client):
     # distributed version of train returns a dictionary containing the
     # resulting booster and evaluation history obtained from
     # evaluation metrics.
-    output = xgb.dask.train(
-        client,
-        {"verbosity": 1, "tree_method": "hist"},
+    output = xgb.dask.train(client,
+                            {'verbosity': 1,
+                             'tree_method': 'hist'},
                             dtrain,
-        num_boost_round=4,
-        evals=[(dtrain, "train")],
-    )
-    bst = output["booster"]
-    history = output["history"]
+                            num_boost_round=4, evals=[(dtrain, 'train')])
+    bst = output['booster']
+    history = output['history']
 
     # you can pass output directly into `predict` too.
     prediction = xgb.dask.predict(client, bst, dtrain)
-    print("Evaluation history:", history)
+    print('Evaluation history:', history)
     return prediction
 
 
-if __name__ == "__main__":
+if __name__ == '__main__':
     # or use other clusters for scaling
     with LocalCluster(n_workers=7, threads_per_worker=4) as cluster:
         with Client(cluster) as client:

demo/dask/gpu_training.py

@@ -13,38 +13,33 @@ from xgboost import dask as dxgb
 from xgboost.dask import DaskDMatrix
 
 
-def using_dask_matrix(client: Client, X: da.Array, y: da.Array) -> da.Array:
-    # DaskDMatrix acts like normal DMatrix, works as a proxy for local DMatrix scatter
-    # around workers.
+def using_dask_matrix(client: Client, X, y):
+    # DaskDMatrix acts like normal DMatrix, works as a proxy for local
+    # DMatrix scatter around workers.
     dtrain = DaskDMatrix(client, X, y)
 
-    # Use train method from xgboost.dask instead of xgboost.  This distributed version
-    # of train returns a dictionary containing the resulting booster and evaluation
-    # history obtained from evaluation metrics.
-    output = xgb.dask.train(
-        client,
-        {
-            "verbosity": 2,
-            "tree_method": "hist",
+    # Use train method from xgboost.dask instead of xgboost.  This
+    # distributed version of train returns a dictionary containing the
+    # resulting booster and evaluation history obtained from
+    # evaluation metrics.
+    output = xgb.dask.train(client,
+                            {'verbosity': 2,
                              # Golden line for GPU training
-            "device": "cuda",
-        },
+                             'tree_method': 'gpu_hist'},
                             dtrain,
-        num_boost_round=4,
-        evals=[(dtrain, "train")],
-    )
-    bst = output["booster"]
-    history = output["history"]
+                            num_boost_round=4, evals=[(dtrain, 'train')])
+    bst = output['booster']
+    history = output['history']
 
     # you can pass output directly into `predict` too.
     prediction = xgb.dask.predict(client, bst, dtrain)
-    print("Evaluation history:", history)
+    print('Evaluation history:', history)
     return prediction
 
 
-def using_quantile_device_dmatrix(client: Client, X: da.Array, y: da.Array) -> da.Array:
-    """`DaskQuantileDMatrix` is a data type specialized for `hist` tree methods for
-     reducing memory usage.
+def using_quantile_device_dmatrix(client: Client, X, y):
+    """`DaskQuantileDMatrix` is a data type specialized for `gpu_hist` and `hist` tree
+     methods for reducing memory usage.
 
     .. versionadded:: 1.2.0
 
@@ -57,19 +52,17 @@ def using_quantile_device_dmatrix(client: Client, X: da.Array, y: da.Array) -> d
     # the `ref` argument of `DaskQuantileDMatrix`.
     dtrain = dxgb.DaskQuantileDMatrix(client, X, y)
     output = xgb.dask.train(
-        client,
-        {"verbosity": 2, "tree_method": "hist", "device": "cuda"},
-        dtrain,
-        num_boost_round=4,
+        client, {"verbosity": 2, "tree_method": "gpu_hist"}, dtrain, num_boost_round=4
     )
 
     prediction = xgb.dask.predict(client, output, X)
     return prediction
 
 
-if __name__ == "__main__":
+if __name__ == '__main__':
     # `LocalCUDACluster` is used for assigning GPU to XGBoost processes.  Here
-    # `n_workers` represents the number of GPUs since we use one GPU per worker process.
+    # `n_workers` represents the number of GPUs since we use one GPU per worker
+    # process.
     with LocalCUDACluster(n_workers=2, threads_per_worker=4) as cluster:
         with Client(cluster) as client:
             # generate some random data for demonstration
@@ -78,7 +71,7 @@ if __name__ == "__main__":
             X = da.random.random(size=(m, n), chunks=10000)
             y = da.random.random(size=(m, ), chunks=10000)
 
-            print("Using DaskQuantileDMatrix")
+            print('Using DaskQuantileDMatrix')
             from_ddqdm = using_quantile_device_dmatrix(client, X, y)
-            print("Using DMatrix")
+            print('Using DMatrix')
             from_dmatrix = using_dask_matrix(client, X, y)

demo/dask/sklearn_gpu_training.py

@@ -21,8 +21,7 @@ def main(client):
     y = da.random.random(m, partition_size)
 
     regressor = xgboost.dask.DaskXGBRegressor(verbosity=1)
-    # set the device to CUDA
-    regressor.set_params(tree_method="hist", device="cuda")
+    regressor.set_params(tree_method='gpu_hist')
     # assigning client here is optional
     regressor.client = client
 
@@ -32,13 +31,13 @@ def main(client):
     bst = regressor.get_booster()
     history = regressor.evals_result()
 
-    print("Evaluation history:", history)
+    print('Evaluation history:', history)
     # returned prediction is always a dask array.
     assert isinstance(prediction, da.Array)
     return bst                  # returning the trained model
 
 
-if __name__ == "__main__":
+if __name__ == '__main__':
     # With dask cuda, one can scale up XGBoost to arbitrary GPU clusters.
     # `LocalCUDACluster` used here is only for demonstration purpose.
     with LocalCUDACluster() as cluster:

demo/gpu_acceleration/README.md

@@ -0,0 +1,5 @@
+# GPU Acceleration Demo
+
+`cover_type.py` shows how to train a model on the [forest cover type](https://archive.ics.uci.edu/ml/datasets/covertype) dataset using GPU acceleration. The forest cover type dataset has 581,012 rows and 54 features, making it time consuming to process. We compare the run-time and accuracy of the GPU and CPU histogram algorithms.
+
+`shap.ipynb` demonstrates using GPU acceleration to compute SHAP values for feature importance.

demo/gpu_acceleration/README.rst

@@ -1,8 +0,0 @@
-:orphan:
-
-GPU Acceleration Demo
-=====================
-
-This is a collection of demonstration scripts to showcase the basic usage of GPU. Please
-see :doc:`/gpu/index` for more info. There are other demonstrations for distributed GPU
-training using dask or spark.

demo/gpu_acceleration/cover_type.py

@@ -1,49 +1,41 @@
-"""
-Using xgboost on GPU devices
-============================
-
-Shows how to train a model on the `forest cover type
-<https://archive.ics.uci.edu/ml/datasets/covertype>`_ dataset using GPU
-acceleration. The forest cover type dataset has 581,012 rows and 54 features, making it
-time consuming to process. We compare the run-time and accuracy of the GPU and CPU
-histogram algorithms.
-
-In addition, The demo showcases using GPU with other GPU-related libraries including
-cupy and cuml. These libraries are not strictly required.
-
-"""
 import time
 
-import cupy as cp
-from cuml.model_selection import train_test_split
 from sklearn.datasets import fetch_covtype
+from sklearn.model_selection import train_test_split
 
 import xgboost as xgb
 
 # Fetch dataset using sklearn
-X, y = fetch_covtype(return_X_y=True)
-X = cp.array(X)
-y = cp.array(y)
-y -= y.min()
+cov = fetch_covtype()
+X = cov.data
+y = cov.target
 
 # Create 0.75/0.25 train/test split
-X_train, X_test, y_train, y_test = train_test_split(
-    X, y, test_size=0.25, train_size=0.75, random_state=42
-)
+X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.25, train_size=0.75,
+                                                    random_state=42)
 
 # Specify sufficient boosting iterations to reach a minimum
 num_round = 3000
 
 # Leave most parameters as default
-clf = xgb.XGBClassifier(device="cuda", n_estimators=num_round)
+param = {'objective': 'multi:softmax', # Specify multiclass classification
+         'num_class': 8, # Number of possible output classes
+         'tree_method': 'gpu_hist' # Use GPU accelerated algorithm
+         }
+
+# Convert input data from numpy to XGBoost format
+dtrain = xgb.DMatrix(X_train, label=y_train)
+dtest = xgb.DMatrix(X_test, label=y_test)
+
+gpu_res = {} # Store accuracy result
+tmp = time.time()
 # Train model
-start = time.time()
-clf.fit(X_train, y_train, eval_set=[(X_test, y_test)])
-gpu_res = clf.evals_result()
-print("GPU Training Time: %s seconds" % (str(time.time() - start)))
+xgb.train(param, dtrain, num_round, evals=[(dtest, 'test')], evals_result=gpu_res)
+print("GPU Training Time: %s seconds" % (str(time.time() - tmp)))
 
 # Repeat for CPU algorithm
-clf = xgb.XGBClassifier(device="cpu", n_estimators=num_round)
-start = time.time()
-cpu_res = clf.evals_result()
-print("CPU Training Time: %s seconds" % (str(time.time() - start)))
+tmp = time.time()
+param['tree_method'] = 'hist'
+cpu_res = {}
+xgb.train(param, dtrain, num_round, evals=[(dtest, 'test')], evals_result=cpu_res)
+print("CPU Training Time: %s seconds" % (str(time.time() - tmp)))

demo/gpu_acceleration/tree_shap.py

@@ -1,55 +0,0 @@
-"""
-Use GPU to speedup SHAP value computation
-=========================================
-
-Demonstrates using GPU acceleration to compute SHAP values for feature importance.
-
-"""
-import shap
-from sklearn.datasets import fetch_california_housing
-
-import xgboost as xgb
-
-# Fetch dataset using sklearn
-data = fetch_california_housing()
-print(data.DESCR)
-X = data.data
-y = data.target
-
-num_round = 500
-
-param = {
-    "eta": 0.05,
-    "max_depth": 10,
-    "tree_method": "hist",
-    "device": "cuda",
-}
-
-# GPU accelerated training
-dtrain = xgb.DMatrix(X, label=y, feature_names=data.feature_names)
-model = xgb.train(param, dtrain, num_round)
-
-# Compute shap values using GPU with xgboost
-model.set_param({"device": "cuda"})
-shap_values = model.predict(dtrain, pred_contribs=True)
-
-# Compute shap interaction values using GPU
-shap_interaction_values = model.predict(dtrain, pred_interactions=True)
-
-
-# shap will call the GPU accelerated version as long as the device parameter is set to
-# "cuda"
-explainer = shap.TreeExplainer(model)
-shap_values = explainer.shap_values(X)
-
-# visualize the first prediction's explanation
-shap.force_plot(
-    explainer.expected_value,
-    shap_values[0, :],
-    X[0, :],
-    feature_names=data.feature_names,
-    matplotlib=True,
-)
-
-# Show a summary of feature importance
-shap.summary_plot(shap_values, X, plot_type="bar", feature_names=data.feature_names)

demo/guide-python/callbacks.py

@@ -1,9 +1,9 @@
-"""
+'''
 Demo for using and defining callback functions
 ==============================================
 
     .. versionadded:: 1.3.0
-"""
+'''
 import argparse
 import os
 import tempfile
@@ -17,11 +17,10 @@ import xgboost as xgb
 
 
 class Plotting(xgb.callback.TrainingCallback):
-    """Plot evaluation result during training.  Only for demonstration purpose as it's quite
+    '''Plot evaluation result during training.  Only for demonstration purpose as it's quite
     slow to draw.
 
-    """
-
+    '''
     def __init__(self, rounds):
         self.fig = plt.figure()
         self.ax = self.fig.add_subplot(111)
@@ -32,16 +31,16 @@ class Plotting(xgb.callback.TrainingCallback):
         plt.ion()
 
     def _get_key(self, data, metric):
-        return f"{data}-{metric}"
+        return f'{data}-{metric}'
 
     def after_iteration(self, model, epoch, evals_log):
-        """Update the plot."""
+        '''Update the plot.'''
         if not self.lines:
             for data, metric in evals_log.items():
                 for metric_name, log in metric.items():
                     key = self._get_key(data, metric_name)
                     expanded = log + [0] * (self.rounds - len(log))
-                    (self.lines[key],) = self.ax.plot(self.x, expanded, label=key)
+                    self.lines[key],  = self.ax.plot(self.x, expanded, label=key)
                     self.ax.legend()
         else:
             # https://pythonspot.com/matplotlib-update-plot/
@@ -56,8 +55,8 @@ class Plotting(xgb.callback.TrainingCallback):
 
 
 def custom_callback():
-    """Demo for defining a custom callback function that plots evaluation result during
-    training."""
+    '''Demo for defining a custom callback function that plots evaluation result during
+    training.'''
     X, y = load_breast_cancer(return_X_y=True)
     X_train, X_valid, y_train, y_valid = train_test_split(X, y, random_state=0)
 
@@ -70,16 +69,14 @@ def custom_callback():
     # Pass it to the `callbacks` parameter as a list.
     xgb.train(
         {
-            "objective": "binary:logistic",
-            "eval_metric": ["error", "rmse"],
-            "tree_method": "hist",
-            "device": "cuda",
+            'objective': 'binary:logistic',
+            'eval_metric': ['error', 'rmse'],
+            'tree_method': 'gpu_hist'
         },
         D_train,
-        evals=[(D_train, "Train"), (D_valid, "Valid")],
+        evals=[(D_train, 'Train'), (D_valid, 'Valid')],
         num_boost_round=num_boost_round,
-        callbacks=[plotting],
-    )
+        callbacks=[plotting])
 
 
 def check_point_callback():
@@ -92,10 +89,10 @@ def check_point_callback():
             if i == 0:
                 continue
             if as_pickle:
-                path = os.path.join(tmpdir, "model_" + str(i) + ".pkl")
+                path = os.path.join(tmpdir, 'model_' + str(i) + '.pkl')
             else:
-                path = os.path.join(tmpdir, "model_" + str(i) + ".json")
-            assert os.path.exists(path)
+                path = os.path.join(tmpdir, 'model_' + str(i) + '.json')
+            assert(os.path.exists(path))
 
     X, y = load_breast_cancer(return_X_y=True)
     m = xgb.DMatrix(X, y)
@@ -103,36 +100,31 @@ def check_point_callback():
     with tempfile.TemporaryDirectory() as tmpdir:
         # Use callback class from xgboost.callback
         # Feel free to subclass/customize it to suit your need.
-        check_point = xgb.callback.TrainingCheckPoint(
-            directory=tmpdir, iterations=rounds, name="model"
-        )
-        xgb.train(
-            {"objective": "binary:logistic"},
-            m,
+        check_point = xgb.callback.TrainingCheckPoint(directory=tmpdir,
+                                                      iterations=rounds,
+                                                      name='model')
+        xgb.train({'objective': 'binary:logistic'}, m,
                   num_boost_round=10,
                   verbose_eval=False,
-            callbacks=[check_point],
-        )
+                  callbacks=[check_point])
         check(False)
 
         # This version of checkpoint saves everything including parameters and
         # model.  See: doc/tutorials/saving_model.rst
-        check_point = xgb.callback.TrainingCheckPoint(
-            directory=tmpdir, iterations=rounds, as_pickle=True, name="model"
-        )
-        xgb.train(
-            {"objective": "binary:logistic"},
-            m,
+        check_point = xgb.callback.TrainingCheckPoint(directory=tmpdir,
+                                                      iterations=rounds,
+                                                      as_pickle=True,
+                                                      name='model')
+        xgb.train({'objective': 'binary:logistic'}, m,
                   num_boost_round=10,
                   verbose_eval=False,
-            callbacks=[check_point],
-        )
+                  callbacks=[check_point])
         check(True)
 
 
-if __name__ == "__main__":
+if __name__ == '__main__':
     parser = argparse.ArgumentParser()
-    parser.add_argument("--plot", default=1, type=int)
+    parser.add_argument('--plot', default=1, type=int)
     args = parser.parse_args()
 
     check_point_callback()

demo/guide-python/cat_in_the_dat.py

@@ -63,8 +63,7 @@ def load_cat_in_the_dat() -> tuple[pd.DataFrame, pd.Series]:
 
 
 params = {
-    "tree_method": "hist",
-    "device": "cuda",
+    "tree_method": "gpu_hist",
     "n_estimators": 32,
     "colsample_bylevel": 0.7,
 }

demo/guide-python/categorical.py

@@ -58,13 +58,13 @@ def main() -> None:
     # Specify `enable_categorical` to True, also we use onehot encoding based split
     # here for demonstration. For details see the document of `max_cat_to_onehot`.
     reg = xgb.XGBRegressor(
-        tree_method="hist", enable_categorical=True, max_cat_to_onehot=5, device="cuda"
+        tree_method="gpu_hist", enable_categorical=True, max_cat_to_onehot=5
     )
     reg.fit(X, y, eval_set=[(X, y)])
 
     # Pass in already encoded data
     X_enc, y_enc = make_categorical(100, 10, 4, True)
-    reg_enc = xgb.XGBRegressor(tree_method="hist", device="cuda")
+    reg_enc = xgb.XGBRegressor(tree_method="gpu_hist")
     reg_enc.fit(X_enc, y_enc, eval_set=[(X_enc, y_enc)])
 
     reg_results = np.array(reg.evals_result()["validation_0"]["rmse"])

demo/guide-python/external_memory.py

@@ -22,10 +22,7 @@ import xgboost
 
 
 def make_batches(
-    n_samples_per_batch: int,
-    n_features: int,
-    n_batches: int,
-    tmpdir: str,
+    n_samples_per_batch: int, n_features: int, n_batches: int, tmpdir: str,
 ) -> List[Tuple[str, str]]:
     files: List[Tuple[str, str]] = []
     rng = np.random.RandomState(1994)
@@ -41,7 +38,6 @@ def make_batches(
 
 class Iterator(xgboost.DataIter):
     """A custom iterator for loading files in batches."""
-
     def __init__(self, file_paths: List[Tuple[str, str]]):
         self._file_paths = file_paths
         self._it = 0
@@ -86,9 +82,8 @@ def main(tmpdir: str) -> xgboost.Booster:
     missing = np.NaN
     Xy = xgboost.DMatrix(it, missing=missing, enable_categorical=False)
 
-    # ``approx`` is also supported, but less efficient due to sketching. GPU behaves
-    # differently than CPU tree methods as it uses a hybrid approach. See tutorial in
-    # doc for details.
+    # Other tree methods including ``approx``, and ``gpu_hist`` are supported. GPU
+    # behaves differently than CPU tree methods. See tutorial in doc for details.
     booster = xgboost.train(
         {"tree_method": "hist", "max_depth": 4},
         Xy,

demo/guide-python/learning_to_rank.py

@@ -104,8 +104,7 @@ def ranking_demo(args: argparse.Namespace) -> None:
     qid_test = qid_test[sorted_idx]
 
     ranker = xgb.XGBRanker(
-        tree_method="hist",
-        device="cuda",
+        tree_method="gpu_hist",
         lambdarank_pair_method="topk",
         lambdarank_num_pair_per_sample=13,
         eval_metric=["ndcg@1", "ndcg@8"],
@@ -162,8 +161,7 @@ def click_data_demo(args: argparse.Namespace) -> None:
 
     ranker = xgb.XGBRanker(
         n_estimators=512,
-        tree_method="hist",
-        device="cuda",
+        tree_method="gpu_hist",
         learning_rate=0.01,
         reg_lambda=1.5,
         subsample=0.8,

demo/guide-python/quantile_data_iterator.py

@@ -28,18 +28,17 @@ BATCHES = 32
 
 
 class IterForDMatrixDemo(xgboost.core.DataIter):
-    """A data iterator for XGBoost DMatrix.
+    '''A data iterator for XGBoost DMatrix.
 
     `reset` and `next` are required for any data iterator, other functions here
     are utilites for demonstration's purpose.
 
-    """
-
+    '''
     def __init__(self):
-        """Generate some random data for demostration.
+        '''Generate some random data for demostration.
 
         Actual data can be anything that is currently supported by XGBoost.
-        """
+        '''
         self.rows = ROWS_PER_BATCH
         self.cols = COLS
         rng = cupy.random.RandomState(1994)
@@ -60,26 +59,27 @@ class IterForDMatrixDemo(xgboost.core.DataIter):
         return cupy.concatenate(self._weights)
 
     def data(self):
-        """Utility function for obtaining current batch of data."""
+        '''Utility function for obtaining current batch of data.'''
         return self._data[self.it]
 
     def labels(self):
-        """Utility function for obtaining current batch of label."""
+        '''Utility function for obtaining current batch of label.'''
         return self._labels[self.it]
 
     def weights(self):
         return self._weights[self.it]
 
     def reset(self):
-        """Reset the iterator"""
+        '''Reset the iterator'''
         self.it = 0
 
     def next(self, input_data):
-        """Yield next batch of data."""
+        '''Yield next batch of data.'''
         if self.it == len(self._data):
             # Return 0 when there's no more batch.
             return 0
-        input_data(data=self.data(), label=self.labels(), weight=self.weights())
+        input_data(data=self.data(), label=self.labels(),
+                   weight=self.weights())
         self.it += 1
         return 1
 
@@ -103,19 +103,18 @@ def main():
 
     assert m_with_it.num_col() == m.num_col()
     assert m_with_it.num_row() == m.num_row()
-    # Tree meethod must be `hist`.
+    # Tree meethod must be one of the `hist` or `gpu_hist`. We use `gpu_hist` for GPU
+    # input here.
     reg_with_it = xgboost.train(
-        {"tree_method": "hist", "device": "cuda"}, m_with_it, num_boost_round=rounds
+        {"tree_method": "gpu_hist"}, m_with_it, num_boost_round=rounds
     )
     predict_with_it = reg_with_it.predict(m_with_it)
 
-    reg = xgboost.train(
-        {"tree_method": "hist", "device": "cuda"}, m, num_boost_round=rounds
-    )
+    reg = xgboost.train({"tree_method": "gpu_hist"}, m, num_boost_round=rounds)
     predict = reg.predict(m)
 
     numpy.testing.assert_allclose(predict_with_it, predict, rtol=1e6)
 
 
-if __name__ == "__main__":
+if __name__ == '__main__':
     main()

demo/guide-python/quantile_regression.py

@@ -7,11 +7,6 @@ Quantile Regression
 The script is inspired by this awesome example in sklearn:
 https://scikit-learn.org/stable/auto_examples/ensemble/plot_gradient_boosting_quantile.html
 
-.. note::
-
-    The feature is only supported using the Python package. In addition, quantile
-    crossing can happen due to limitation in the algorithm.
-
 """
 import argparse
 from typing import Dict

demo/guide-python/update_process.py

@@ -24,7 +24,7 @@ def main():
     Xy = xgb.DMatrix(X_train, y_train)
     evals_result: xgb.callback.EvaluationMonitor.EvalsLog = {}
     booster = xgb.train(
-        {"tree_method": "hist", "max_depth": 6, "device": "cuda"},
+        {"tree_method": "gpu_hist", "max_depth": 6},
         Xy,
         num_boost_round=n_rounds,
         evals=[(Xy, "Train")],
@@ -87,7 +87,7 @@ def main():
     np.testing.assert_allclose(
         np.array(prune_result["Original"]["rmse"]),
         np.array(prune_result["Train"]["rmse"]),
-        atol=1e-5,
+        atol=1e-5
     )
 
 

demo/nvflare/.gitignore

@@ -1 +0,0 @@
-!config

demo/nvflare/config/config_fed_client.json

@@ -1,23 +0,0 @@
-{
-  "format_version": 2,
-  "executors": [
-    {
-      "tasks": [
-        "train"
-      ],
-      "executor": {
-        "path": "trainer.XGBoostTrainer",
-        "args": {
-          "server_address": "localhost:9091",
-          "world_size": 2,
-          "server_cert_path": "server-cert.pem",
-          "client_key_path": "client-key.pem",
-          "client_cert_path": "client-cert.pem",
-          "use_gpus": false
-        }
-      }
-    }
-  ],
-  "task_result_filters": [],
-  "task_data_filters": []
-}

demo/nvflare/config/config_fed_server.json

@@ -1,22 +0,0 @@
-{
-  "format_version": 2,
-  "server": {
-    "heart_beat_timeout": 600
-  },
-  "task_data_filters": [],
-  "task_result_filters": [],
-  "workflows": [
-    {
-      "id": "server_workflow",
-      "path": "controller.XGBoostController",
-      "args": {
-        "port": 9091,
-        "world_size": 2,
-        "server_key_path": "server-key.pem",
-        "server_cert_path": "server-cert.pem",
-        "client_cert_path": "client-cert.pem"
-      }
-    }
-  ],
-  "components": []
-}

demo/nvflare/horizontal/README.md

@@ -6,7 +6,7 @@ This directory contains a demo of Horizontal Federated Learning using
 ## Training with CPU only
 
 To run the demo, first build XGBoost with the federated learning plugin enabled (see the
-[README](../../../plugin/federated/README.md)).
+[README](../../plugin/federated/README.md)).
 
 Install NVFlare (note that currently NVFlare only supports Python 3.8):
 ```shell

demo/nvflare/horizontal/custom/trainer.py

@@ -70,7 +70,8 @@ class XGBoostTrainer(Executor):
             param = {'max_depth': 2, 'eta': 1, 'objective': 'binary:logistic'}
             if self._use_gpus:
                 self.log_info(fl_ctx, f'Training with GPU {rank}')
-                param['device'] = f"cuda:{rank}"
+                param['tree_method'] = 'gpu_hist'
+                param['gpu_id'] = rank
 
             # Specify validations set to watch performance
             watchlist = [(dtest, 'eval'), (dtrain, 'train')]

demo/nvflare/horizontal/prepare_data.sh

@@ -16,7 +16,7 @@ split -n l/${world_size} --numeric-suffixes=1 -a 1 ../../data/agaricus.txt.test
 
 nvflare poc -n 2 --prepare
 mkdir -p /tmp/nvflare/poc/admin/transfer/horizontal-xgboost
-cp -fr ../config custom /tmp/nvflare/poc/admin/transfer/horizontal-xgboost
+cp -fr config custom /tmp/nvflare/poc/admin/transfer/horizontal-xgboost
 cp server-*.pem client-cert.pem /tmp/nvflare/poc/server/
 for (( site=1; site<=world_size; site++ )); do
   cp server-cert.pem client-*.pem /tmp/nvflare/poc/site-"$site"/

demo/nvflare/vertical/README.md

@@ -6,7 +6,7 @@ This directory contains a demo of Vertical Federated Learning using
 ## Training with CPU only
 
 To run the demo, first build XGBoost with the federated learning plugin enabled (see the
-[README](../../../plugin/federated/README.md)).
+[README](../../plugin/federated/README.md)).
 
 Install NVFlare (note that currently NVFlare only supports Python 3.8):
 ```shell

demo/nvflare/vertical/custom/trainer.py

@@ -16,7 +16,7 @@ class SupportedTasks(object):
 
 class XGBoostTrainer(Executor):
     def __init__(self, server_address: str, world_size: int, server_cert_path: str,
-                 client_key_path: str, client_cert_path: str, use_gpus: bool):
+                 client_key_path: str, client_cert_path: str):
         """Trainer for federated XGBoost.
 
         Args:
@@ -32,7 +32,6 @@ class XGBoostTrainer(Executor):
         self._server_cert_path = server_cert_path
         self._client_key_path = client_key_path
         self._client_cert_path = client_cert_path
-        self._use_gpus = use_gpus
 
     def execute(self, task_name: str, shareable: Shareable, fl_ctx: FLContext,
                 abort_signal: Signal) -> Shareable:
@@ -82,8 +81,6 @@ class XGBoostTrainer(Executor):
                 'objective': 'binary:logistic',
                 'eval_metric': 'auc',
             }
-            if self._use_gpus:
-                self.log_info(fl_ctx, 'GPUs are not currently supported by vertical federated XGBoost')
 
             # specify validations set to watch performance
             watchlist = [(dtest, "eval"), (dtrain, "train")]

demo/nvflare/vertical/prepare_data.sh

@@ -56,7 +56,7 @@ fi
 
 nvflare poc -n 2 --prepare
 mkdir -p /tmp/nvflare/poc/admin/transfer/vertical-xgboost
-cp -fr ../config custom /tmp/nvflare/poc/admin/transfer/vertical-xgboost
+cp -fr config custom /tmp/nvflare/poc/admin/transfer/vertical-xgboost
 cp server-*.pem client-cert.pem /tmp/nvflare/poc/server/
 for (( site=1; site<=world_size; site++ )); do
   cp server-cert.pem client-*.pem /tmp/nvflare/poc/site-"${site}"/

demo/rmm_plugin/README.md

@@ -0,0 +1,47 @@
+Using XGBoost with RAPIDS Memory Manager (RMM) plugin (EXPERIMENTAL)
+====================================================================
+[RAPIDS Memory Manager (RMM)](https://github.com/rapidsai/rmm) library provides a collection of
+efficient memory allocators for NVIDIA GPUs. It is now possible to use XGBoost with memory
+allocators provided by RMM, by enabling the RMM integration plugin.
+
+The demos in this directory highlights one RMM allocator in particular: **the pool sub-allocator**.
+This allocator addresses the slow speed of `cudaMalloc()` by allocating a large chunk of memory
+upfront. Subsequent allocations will draw from the pool of already allocated memory and thus avoid
+the overhead of calling `cudaMalloc()` directly. See
+[this GTC talk slides](https://on-demand.gputechconf.com/gtc/2015/presentation/S5530-Stephen-Jones.pdf)
+for more details.
+
+Before running the demos, ensure that XGBoost is compiled with the RMM plugin enabled. To do this,
+run CMake with option `-DPLUGIN_RMM=ON` (`-DUSE_CUDA=ON` also required):
+```
+cmake .. -DUSE_CUDA=ON -DUSE_NCCL=ON -DPLUGIN_RMM=ON
+make -j4
+```
+CMake will attempt to locate the RMM library in your build environment. You may choose to build
+RMM from the source, or install it using the Conda package manager. If CMake cannot find RMM, you
+should specify the location of RMM with the CMake prefix:
+```
+# If using Conda:
+cmake .. -DUSE_CUDA=ON -DUSE_NCCL=ON -DPLUGIN_RMM=ON -DCMAKE_PREFIX_PATH=$CONDA_PREFIX
+# If using RMM installed with a custom location
+cmake .. -DUSE_CUDA=ON -DUSE_NCCL=ON -DPLUGIN_RMM=ON -DCMAKE_PREFIX_PATH=/path/to/rmm
+```
+
+# Informing XGBoost about RMM pool
+
+When XGBoost is compiled with RMM, most of the large size allocation will go through RMM
+allocators, but some small allocations in performance critical areas are using a different
+caching allocator so that we can have better control over memory allocation behavior.
+Users can override this behavior and force the use of rmm for all allocations by setting
+the global configuration ``use_rmm``:
+
+``` python
+with xgb.config_context(use_rmm=True):
+    clf = xgb.XGBClassifier(tree_method="gpu_hist")
+```
+
+Depending on the choice of memory pool size or type of allocator, this may have negative
+performance impact.
+
+* [Using RMM with a single GPU](./rmm_singlegpu.py)
+* [Using RMM with a local Dask cluster consisting of multiple GPUs](./rmm_mgpu_with_dask.py)

demo/rmm_plugin/README.rst

@@ -1,51 +0,0 @@
-Using XGBoost with RAPIDS Memory Manager (RMM) plugin (EXPERIMENTAL)
-====================================================================
-
-`RAPIDS Memory Manager (RMM) <https://github.com/rapidsai/rmm>`__ library provides a
-collection of efficient memory allocators for NVIDIA GPUs. It is now possible to use
-XGBoost with memory allocators provided by RMM, by enabling the RMM integration plugin.
-
-The demos in this directory highlights one RMM allocator in particular: **the pool
-sub-allocator**.  This allocator addresses the slow speed of ``cudaMalloc()`` by
-allocating a large chunk of memory upfront. Subsequent allocations will draw from the pool
-of already allocated memory and thus avoid the overhead of calling ``cudaMalloc()``
-directly. See `this GTC talk slides
-<https://on-demand.gputechconf.com/gtc/2015/presentation/S5530-Stephen-Jones.pdf>`_ for
-more details.
-
-Before running the demos, ensure that XGBoost is compiled with the RMM plugin enabled. To do this,
-run CMake with option ``-DPLUGIN_RMM=ON`` (``-DUSE_CUDA=ON`` also required):
-
-.. code-block:: sh
-
-  cmake .. -DUSE_CUDA=ON -DUSE_NCCL=ON -DPLUGIN_RMM=ON
-  make -j$(nproc)
-
-CMake will attempt to locate the RMM library in your build environment. You may choose to build
-RMM from the source, or install it using the Conda package manager. If CMake cannot find RMM, you
-should specify the location of RMM with the CMake prefix:
-
-.. code-block:: sh
-
-  # If using Conda:
-  cmake .. -DUSE_CUDA=ON -DUSE_NCCL=ON -DPLUGIN_RMM=ON -DCMAKE_PREFIX_PATH=$CONDA_PREFIX
-  # If using RMM installed with a custom location
-  cmake .. -DUSE_CUDA=ON -DUSE_NCCL=ON -DPLUGIN_RMM=ON -DCMAKE_PREFIX_PATH=/path/to/rmm
-
-********************************
-Informing XGBoost about RMM pool
-********************************
-
-When XGBoost is compiled with RMM, most of the large size allocation will go through RMM
-allocators, but some small allocations in performance critical areas are using a different
-caching allocator so that we can have better control over memory allocation behavior.
-Users can override this behavior and force the use of rmm for all allocations by setting
-the global configuration ``use_rmm``:
-
-.. code-block:: python
-
-  with xgb.config_context(use_rmm=True):
-    clf = xgb.XGBClassifier(tree_method="hist", device="cuda")
-
-Depending on the choice of memory pool size or type of allocator, this may have negative
-performance impact.

demo/rmm_plugin/rmm_mgpu_with_dask.py

@@ -1,7 +1,3 @@
-"""
-Using rmm with Dask
-===================
-"""
 import dask
 from dask.distributed import Client
 from dask_cuda import LocalCUDACluster
@@ -15,33 +11,25 @@ def main(client):
     # xgb.set_config(use_rmm=True)
 
     X, y = make_classification(n_samples=10000, n_informative=5, n_classes=3)
-    # In pratice one should prefer loading the data with dask collections instead of
-    # using `from_array`.
+    # In pratice one should prefer loading the data with dask collections instead of using
+    # `from_array`.
     X = dask.array.from_array(X)
     y = dask.array.from_array(y)
     dtrain = xgb.dask.DaskDMatrix(client, X, label=y)
 
-    params = {
-        "max_depth": 8,
-        "eta": 0.01,
-        "objective": "multi:softprob",
-        "num_class": 3,
-        "tree_method": "hist",
-        "eval_metric": "merror",
-        "device": "cuda",
-    }
-    output = xgb.dask.train(
-        client, params, dtrain, num_boost_round=100, evals=[(dtrain, "train")]
-    )
-    bst = output["booster"]
-    history = output["history"]
-    for i, e in enumerate(history["train"]["merror"]):
-        print(f"[{i}] train-merror: {e}")
+    params = {'max_depth': 8, 'eta': 0.01, 'objective': 'multi:softprob', 'num_class': 3,
+              'tree_method': 'gpu_hist', 'eval_metric': 'merror'}
+    output = xgb.dask.train(client, params, dtrain, num_boost_round=100,
+                            evals=[(dtrain, 'train')])
+    bst = output['booster']
+    history = output['history']
+    for i, e in enumerate(history['train']['merror']):
+        print(f'[{i}] train-merror: {e}')
 
 
-if __name__ == "__main__":
-    # To use RMM pool allocator with a GPU Dask cluster, just add rmm_pool_size option
-    # to LocalCUDACluster constructor.
-    with LocalCUDACluster(rmm_pool_size="2GB") as cluster:
+if __name__ == '__main__':
+    # To use RMM pool allocator with a GPU Dask cluster, just add rmm_pool_size option to
+    # LocalCUDACluster constructor.
+    with LocalCUDACluster(rmm_pool_size='2GB') as cluster:
         with Client(cluster) as client:
             main(client)

demo/rmm_plugin/rmm_singlegpu.py

@@ -1,7 +1,3 @@
-"""
-Using rmm on a single node device
-=================================
-"""
 import rmm
 from sklearn.datasets import make_classification
 
@@ -20,8 +16,7 @@ params = {
     "eta": 0.01,
     "objective": "multi:softprob",
     "num_class": 3,
-    "tree_method": "hist",
-    "device": "cuda",
+    "tree_method": "gpu_hist",
 }
 # XGBoost will automatically use the RMM pool allocator
 bst = xgb.train(params, dtrain, num_boost_round=100, evals=[(dtrain, "train")])

dev/change_scala_version.py

@@ -1,79 +0,0 @@
-import argparse
-import pathlib
-import re
-import shutil
-
-
-def main(args):
-    if args.scala_version == "2.12":
-        scala_ver = "2.12"
-        scala_patchver = "2.12.18"
-    elif args.scala_version == "2.13":
-        scala_ver = "2.13"
-        scala_patchver = "2.13.11"
-    else:
-        raise ValueError(f"Unsupported Scala version: {args.scala_version}")
-
-    # Clean artifacts
-    if args.purge_artifacts:
-        for target in pathlib.Path("jvm-packages/").glob("**/target"):
-            if target.is_dir():
-                print(f"Removing {target}...")
-                shutil.rmtree(target)
-
-    # Update pom.xml
-    for pom in pathlib.Path("jvm-packages/").glob("**/pom.xml"):
-        print(f"Updating {pom}...")
-        with open(pom, "r", encoding="utf-8") as f:
-            lines = f.readlines()
-        with open(pom, "w", encoding="utf-8") as f:
-            replaced_scalaver = False
-            replaced_scala_binver = False
-            for line in lines:
-                for artifact in [
-                    "xgboost-jvm",
-                    "xgboost4j",
-                    "xgboost4j-gpu",
-                    "xgboost4j-spark",
-                    "xgboost4j-spark-gpu",
-                    "xgboost4j-flink",
-                    "xgboost4j-example",
-                ]:
-                    line = re.sub(
-                        f"<artifactId>{artifact}_[0-9\\.]*",
-                        f"<artifactId>{artifact}_{scala_ver}",
-                        line,
-                    )
-                # Only replace the first occurrence of scala.version
-                if not replaced_scalaver:
-                    line, nsubs = re.subn(
-                        r"<scala.version>[0-9\.]*",
-                        f"<scala.version>{scala_patchver}",
-                        line,
-                    )
-                    if nsubs > 0:
-                        replaced_scalaver = True
-                # Only replace the first occurrence of scala.binary.version
-                if not replaced_scala_binver:
-                    line, nsubs = re.subn(
-                        r"<scala.binary.version>[0-9\.]*",
-                        f"<scala.binary.version>{scala_ver}",
-                        line,
-                    )
-                    if nsubs > 0:
-                        replaced_scala_binver = True
-                f.write(line)
-
-
-if __name__ == "__main__":
-    parser = argparse.ArgumentParser()
-    parser.add_argument("--purge-artifacts", action="store_true")
-    parser.add_argument(
-        "--scala-version",
-        type=str,
-        required=True,
-        help="Version of Scala to use in the JVM packages",
-        choices=["2.12", "2.13"],
-    )
-    parsed_args = parser.parse_args()
-    main(parsed_args)

dev/prepare_jvm_release.py

@@ -2,6 +2,7 @@ import argparse
 import errno
 import glob
 import os
+import platform
 import re
 import shutil
 import subprocess
@@ -20,14 +21,12 @@ def normpath(path):
     else:
         return normalized
 
-
 def cp(source, target):
     source = normpath(source)
     target = normpath(target)
     print("cp {0} {1}".format(source, target))
     shutil.copy(source, target)
 
-
 def maybe_makedirs(path):
     path = normpath(path)
     print("mkdir -p " + path)
@@ -37,7 +36,6 @@ def maybe_makedirs(path):
         if e.errno != errno.EEXIST:
             raise
 
-
 @contextmanager
 def cd(path):
     path = normpath(path)
@@ -49,22 +47,18 @@ def cd(path):
     finally:
         os.chdir(cwd)
 
-
 def run(command, **kwargs):
     print(command)
     subprocess.check_call(command, shell=True, **kwargs)
 
-
 def get_current_git_tag():
     out = subprocess.check_output(["git", "tag", "--points-at", "HEAD"])
     return out.decode().split("\n")[0]
 
-
 def get_current_commit_hash():
     out = subprocess.check_output(["git", "rev-parse", "HEAD"])
     return out.decode().split("\n")[0]
 
-
 def get_current_git_branch():
     out = subprocess.check_output(["git", "log", "-n", "1", "--pretty=%d", "HEAD"])
     m = re.search(r"release_[0-9\.]+", out.decode())
@@ -72,49 +66,38 @@ def get_current_git_branch():
         raise ValueError("Expected branch name of form release_xxx")
     return m.group(0)
 
-
 def retrieve(url, filename=None):
     print(f"{url} -> {filename}")
     return urlretrieve(url, filename)
 
-
 def main():
     parser = argparse.ArgumentParser()
-    parser.add_argument(
-        "--release-version",
-        type=str,
-        required=True,
-        help="Version of the release being prepared",
-    )
+    parser.add_argument("--release-version", type=str, required=True,
+                        help="Version of the release being prepared")
     args = parser.parse_args()
+
+    if sys.platform != "darwin" or platform.machine() != "x86_64":
+        raise NotImplementedError("Please run this script using an Intel Mac")
+
     version = args.release_version
     expected_git_tag = "v" + version
     current_git_tag = get_current_git_tag()
     if current_git_tag != expected_git_tag:
         if not current_git_tag:
-            raise ValueError(
-                f"Expected git tag {expected_git_tag} but current HEAD has no tag. "
-                f"Run: git checkout {expected_git_tag}"
-            )
-        raise ValueError(
-            f"Expected git tag {expected_git_tag} but current HEAD is at tag "
-            f"{current_git_tag}. Run: git checkout {expected_git_tag}"
-        )
+            raise ValueError(f"Expected git tag {expected_git_tag} but current HEAD has no tag. "
+                             f"Run: git checkout {expected_git_tag}")
+        raise ValueError(f"Expected git tag {expected_git_tag} but current HEAD is at tag "
+                         f"{current_git_tag}. Run: git checkout {expected_git_tag}")
 
     commit_hash = get_current_commit_hash()
     git_branch = get_current_git_branch()
-    print(
-        f"Using commit {commit_hash} of branch {git_branch}, git tag {current_git_tag}"
-    )
+    print(f"Using commit {commit_hash} of branch {git_branch}, git tag {current_git_tag}")
 
     with cd("jvm-packages/"):
         print("====copying pure-Python tracker====")
         for use_cuda in [True, False]:
             xgboost4j = "xgboost4j-gpu" if use_cuda else "xgboost4j"
-            cp(
-                "../python-package/xgboost/tracker.py",
-                f"{xgboost4j}/src/main/resources",
-            )
+            cp("../python-package/xgboost/tracker.py", f"{xgboost4j}/src/main/resources")
 
         print("====copying resources for testing====")
         with cd("../demo/CLI/regression"):
@@ -132,12 +115,7 @@ def main():
                 cp(file, f"{xgboost4j_spark}/src/test/resources")
 
         print("====Creating directories to hold native binaries====")
-        for os_ident, arch in [
-            ("linux", "x86_64"),
-            ("windows", "x86_64"),
-            ("macos", "x86_64"),
-            ("macos", "aarch64"),
-        ]:
+        for os_ident, arch in [("linux", "x86_64"), ("windows", "x86_64"), ("macos", "x86_64")]:
             output_dir = f"xgboost4j/src/main/resources/lib/{os_ident}/{arch}"
             maybe_makedirs(output_dir)
         for os_ident, arch in [("linux", "x86_64")]:
@@ -145,98 +123,52 @@ def main():
             maybe_makedirs(output_dir)
 
         print("====Downloading native binaries from CI====")
-        nightly_bucket_prefix = (
-            "https://s3-us-west-2.amazonaws.com/xgboost-nightly-builds"
-        )
-        maven_repo_prefix = (
-            "https://s3-us-west-2.amazonaws.com/xgboost-maven-repo/release/ml/dmlc"
-        )
+        nightly_bucket_prefix = "https://s3-us-west-2.amazonaws.com/xgboost-nightly-builds"
+        maven_repo_prefix = "https://s3-us-west-2.amazonaws.com/xgboost-maven-repo/release/ml/dmlc"
 
-        retrieve(
-            url=f"{nightly_bucket_prefix}/{git_branch}/libxgboost4j/xgboost4j_{commit_hash}.dll",
-            filename="xgboost4j/src/main/resources/lib/windows/x86_64/xgboost4j.dll",
-        )
-        retrieve(
-            url=f"{nightly_bucket_prefix}/{git_branch}/libxgboost4j/libxgboost4j_{commit_hash}.dylib",
-            filename="xgboost4j/src/main/resources/lib/macos/x86_64/libxgboost4j.dylib",
-        )
-        retrieve(
-            url=f"{nightly_bucket_prefix}/{git_branch}/libxgboost4j/libxgboost4j_m1_{commit_hash}.dylib",
-            filename="xgboost4j/src/main/resources/lib/macos/aarch64/libxgboost4j.dylib",
-        )
+        retrieve(url=f"{nightly_bucket_prefix}/{git_branch}/xgboost4j_{commit_hash}.dll",
+                 filename="xgboost4j/src/main/resources/lib/windows/x86_64/xgboost4j.dll")
 
         with tempfile.TemporaryDirectory() as tempdir:
             # libxgboost4j.so for Linux x86_64, CPU only
             zip_path = os.path.join(tempdir, "xgboost4j_2.12.jar")
             extract_dir = os.path.join(tempdir, "xgboost4j")
-            retrieve(
-                url=f"{maven_repo_prefix}/xgboost4j_2.12/{version}/"
+            retrieve(url=f"{maven_repo_prefix}/xgboost4j_2.12/{version}/"
                          f"xgboost4j_2.12-{version}.jar",
-                filename=zip_path,
-            )
+                     filename=zip_path)
             os.mkdir(extract_dir)
             with zipfile.ZipFile(zip_path, "r") as t:
                 t.extractall(extract_dir)
-            cp(
-                os.path.join(extract_dir, "lib", "linux", "x86_64", "libxgboost4j.so"),
-                "xgboost4j/src/main/resources/lib/linux/x86_64/libxgboost4j.so",
-            )
+            cp(os.path.join(extract_dir, "lib", "linux", "x86_64", "libxgboost4j.so"),
+               "xgboost4j/src/main/resources/lib/linux/x86_64/libxgboost4j.so")
 
             # libxgboost4j.so for Linux x86_64, GPU support
             zip_path = os.path.join(tempdir, "xgboost4j-gpu_2.12.jar")
             extract_dir = os.path.join(tempdir, "xgboost4j-gpu")
-            retrieve(
-                url=f"{maven_repo_prefix}/xgboost4j-gpu_2.12/{version}/"
+            retrieve(url=f"{maven_repo_prefix}/xgboost4j-gpu_2.12/{version}/"
                          f"xgboost4j-gpu_2.12-{version}.jar",
-                filename=zip_path,
-            )
+                     filename=zip_path)
             os.mkdir(extract_dir)
             with zipfile.ZipFile(zip_path, "r") as t:
                 t.extractall(extract_dir)
-            cp(
-                os.path.join(extract_dir, "lib", "linux", "x86_64", "libxgboost4j.so"),
-                "xgboost4j-gpu/src/main/resources/lib/linux/x86_64/libxgboost4j.so",
-            )
+            cp(os.path.join(extract_dir, "lib", "linux", "x86_64", "libxgboost4j.so"),
+               "xgboost4j-gpu/src/main/resources/lib/linux/x86_64/libxgboost4j.so")
+
 
     print("====Next Steps====")
     print("1. Gain upload right to Maven Central repo.")
     print("1-1. Sign up for a JIRA account at Sonatype: ")
-    print(
-        "1-2. File a JIRA ticket: "
+    print("1-2. File a JIRA ticket: "
           "https://issues.sonatype.org/secure/CreateIssue.jspa?issuetype=21&pid=10134. Example: "
-        "https://issues.sonatype.org/browse/OSSRH-67724"
-    )
-    print(
-        "2. Store the Sonatype credentials in .m2/settings.xml. See insturctions in "
-        "https://central.sonatype.org/publish/publish-maven/"
-    )
-    print(
-        "3. Now on a Linux machine, run the following to build Scala 2.12 artifacts. "
-        "Make sure to use an Internet connection with fast upload speed:"
-    )
-    print(
-        "   # Skip native build, since we have all needed native binaries from CI\n"
-        "   export MAVEN_SKIP_NATIVE_BUILD=1\n"
-        "   GPG_TTY=$(tty) mvn deploy -Prelease -DskipTests"
-    )
-    print(
-        "4. Log into https://oss.sonatype.org/. On the left menu panel, click Staging "
-        "Repositories. Visit the URL https://oss.sonatype.org/content/repositories/mldmlc-xxxx "
+          "https://issues.sonatype.org/browse/OSSRH-67724")
+    print("2. Store the Sonatype credentials in .m2/settings.xml. See insturctions in "
+          "https://central.sonatype.org/publish/publish-maven/")
+    print("3. Now on a Mac machine, run:")
+    print("   GPG_TTY=$(tty) mvn deploy -Prelease -DskipTests")
+    print("4. Log into https://oss.sonatype.org/. On the left menu panel, click Staging "
+          "Repositories. Visit the URL https://oss.sonatype.org/content/repositories/mldmlc-1085 "
           "to inspect the staged JAR files. Finally, press Release button to publish the "
-        "artifacts to the Maven Central repository. The top-level metapackage should be "
-        "named xgboost-jvm_2.12."
-    )
-    print(
-        "5. Remove the Scala 2.12 artifacts and build Scala 2.13 artifacts:\n"
-        "   export MAVEN_SKIP_NATIVE_BUILD=1\n"
-        "   python dev/change_scala_version.py --scala-version 2.13 --purge-artifacts\n"
-        "   GPG_TTY=$(tty) mvn deploy -Prelease-cpu-only,scala-2.13 -DskipTests"
-    )
-    print(
-        "6. Go to https://oss.sonatype.org/ to release the Scala 2.13 artifacts. "
-        "The top-level metapackage should be named xgboost-jvm_2.13."
-    )
-
+          "artifacts to the Maven Central repository.")
 
 if __name__ == "__main__":
     main()

doc/.gitignore

@@ -6,5 +6,3 @@ doxygen
 parser.py
 *.pyc
 web-data
-# generated by doxygen
-tmp

doc/R-package/discoverYourData.md

@@ -1,76 +1,70 @@
-# Understand your dataset with XGBoost
 
-## Introduction
+Understand your dataset with XGBoost
+====================================
 
-The purpose of this vignette is to show you how to use **XGBoost** to
-discover and understand your own dataset better.
+Introduction
+------------
 
-This vignette is not about predicting anything (see [XGBoost
-presentation](https://github.com/dmlc/xgboost/blob/master/R-package/vignettes/xgboostPresentation.Rmd)).
-We will explain how to use **XGBoost** to highlight the *link* between
-the *features* of your data and the *outcome*.
+The purpose of this Vignette is to show you how to use **XGBoost** to discover and understand your own dataset better.
+
+This Vignette is not about predicting anything (see [XGBoost presentation](https://github.com/dmlc/xgboost/blob/master/R-package/vignettes/xgboostPresentation.Rmd)). We will explain how to use **XGBoost** to highlight the *link* between the *features* of your data and the *outcome*.
 
 Package loading:
 
+
+```r
 require(xgboost)
 require(Matrix)
 require(data.table)
-    if (!require('vcd')) {
-      install.packages('vcd')
-    }
+if (!require('vcd')) install.packages('vcd')
+```
 
 > **VCD** package is used for one of its embedded dataset only.
 
-## Preparation of the dataset
+Preparation of the dataset
+--------------------------
+
+### Numeric VS categorical variables
 
-### Numeric v.s. categorical variables
 
 **XGBoost** manages only `numeric` vectors.
 
 What to do when you have *categorical* data?
 
-A *categorical* variable has a fixed number of different values. For
-instance, if a variable called *Colour* can have only one of these three
-values, *red*, *blue* or *green*, then *Colour* is a *categorical*
-variable.
+A *categorical* variable has a fixed number of different values. For instance, if a variable called *Colour* can have only one of these three values, *red*, *blue* or *green*, then *Colour* is a *categorical* variable.
 
 > In **R**, a *categorical* variable is called `factor`.
 >
 > Type `?factor` in the console for more information.
 
-To answer the question above we will convert *categorical* variables to
-`numeric` ones.
+To answer the question above we will convert *categorical* variables to `numeric` one.
 
 ### Conversion from categorical to numeric variables
 
 #### Looking at the raw data
 
-+In this Vignette we will see how to transform a *dense* `data.frame`
-(*dense* = the majority of the matrix is non-zero) with *categorical*
-variables to a very *sparse* matrix (*sparse* = lots of zero entries in
-the matrix) of `numeric` features.
+In this Vignette we will see how to transform a *dense* `data.frame` (*dense* = few zeroes in the matrix) with *categorical* variables to a very *sparse* matrix (*sparse* = lots of zero in the matrix) of `numeric` features.
 
-The method we are going to see is usually called [one-hot
-encoding](https://en.wikipedia.org/wiki/One-hot).
+The method we are going to see is usually called [one-hot encoding](http://en.wikipedia.org/wiki/One-hot).
 
-The first step is to load the `Arthritis` dataset in memory and wrap it
-with the `data.table` package.
+The first step is to load `Arthritis` dataset in memory and wrap it with `data.table` package.
 
+
+```r
 data(Arthritis)
 df <- data.table(Arthritis, keep.rownames = FALSE)
+```
 
-> `data.table` is 100% compliant with **R** `data.frame` but its syntax
-> is more consistent and its performance for large dataset is [best in
-> class](https://stackoverflow.com/questions/21435339/data-table-vs-dplyr-can-one-do-something-well-the-other-cant-or-does-poorly)
-> (`dplyr` from **R** and `Pandas` from **Python**
-> [included](https://github.com/Rdatatable/data.table/wiki/Benchmarks-%3A-Grouping)).
-> Some parts of **XGBoost’s** **R** package use `data.table`.
+> `data.table` is 100% compliant with **R** `data.frame` but its syntax is more consistent and its performance for large dataset is [best in class](http://stackoverflow.com/questions/21435339/data-table-vs-dplyr-can-one-do-something-well-the-other-cant-or-does-poorly) (`dplyr` from **R** and `Pandas` from **Python** [included](https://github.com/Rdatatable/data.table/wiki/Benchmarks-%3A-Grouping)). Some parts of **XGBoost** **R** package use `data.table`.
 
-The first thing we want to do is to have a look to the first few lines
-of the `data.table`:
+The first thing we want to do is to have a look to the first lines of the `data.table`:
 
+
+```r
 head(df)
+```
 
+```
 ##    ID Treatment  Sex Age Improved
 ## 1: 57   Treated Male  27     Some
 ## 2: 46   Treated Male  29     None
@@ -78,11 +72,16 @@ of the `data.table`:
 ## 4: 17   Treated Male  32   Marked
 ## 5: 36   Treated Male  46   Marked
 ## 6: 23   Treated Male  58   Marked
+```
 
 Now we will check the format of each column.
 
-    str(df)
 
+```r
+str(df)
+```
+
+```
 ## Classes 'data.table' and 'data.frame':	84 obs. of  5 variables:
 ##  $ ID       : int  57 46 77 17 36 23 75 39 33 55 ...
 ##  $ Treatment: Factor w/ 2 levels "Placebo","Treated": 2 2 2 2 2 2 2 2 2 2 ...
@@ -90,14 +89,14 @@ Now we will check the format of each column.
 ##  $ Age      : int  27 29 30 32 46 58 59 59 63 63 ...
 ##  $ Improved : Ord.factor w/ 3 levels "None"<"Some"<..: 2 1 1 3 3 3 1 3 1 1 ...
 ##  - attr(*, ".internal.selfref")=<externalptr>
+```
 
 2 columns have `factor` type, one has `ordinal` type.
 
 > `ordinal` variable :
 >
-> -   can take a limited number of values (like `factor`) ;
-> -   these values are ordered (unlike `factor`). Here these ordered
->     values are: `Marked > Some > None`
+> * can take a limited number of values (like `factor`) ;
+> * these values are ordered (unlike `factor`). Here these ordered values are: `Marked > Some > None`
 
 #### Creation of new features based on old ones
 
@@ -105,16 +104,18 @@ We will add some new *categorical* features to see if it helps.
 
 ##### Grouping per 10 years
 
-For the first features we create groups of age by rounding the real age.
+For the first feature we create groups of age by rounding the real age.
 
-Note that we transform it to `factor` so the algorithm treats these age
-groups as independent values.
+Note that we transform it to `factor` so the algorithm treat these age groups as independent values.
 
-Therefore, 20 is not closer to 30 than 60. In other words, the distance
-between ages is lost in this transformation.
+Therefore, 20 is not closer to 30 than 60. To make it short, the distance between ages is lost in this transformation.
 
+
+```r
 head(df[,AgeDiscret := as.factor(round(Age/10,0))])
+```
 
+```
 ##    ID Treatment  Sex Age Improved AgeDiscret
 ## 1: 57   Treated Male  27     Some          3
 ## 2: 46   Treated Male  29     None          3
@@ -122,17 +123,18 @@ between ages is lost in this transformation.
 ## 4: 17   Treated Male  32   Marked          3
 ## 5: 36   Treated Male  46   Marked          5
 ## 6: 23   Treated Male  58   Marked          6
+```
 
-##### Randomly split into two groups
+##### Random split in two groups
 
-The following is an even stronger simplification of the real age with an
-arbitrary split at 30 years old. I choose this value **based on
-nothing**. We will see later if simplifying the information based on
-arbitrary values is a good strategy (you may already have an idea of how
-well it will work…).
+Following is an even stronger simplification of the real age with an arbitrary split at 30 years old. I choose this value **based on nothing**. We will see later if simplifying the information based on arbitrary values is a good strategy (you may already have an idea of how well it will work...).
 
+
+```r
 head(df[,AgeCat:= as.factor(ifelse(Age > 30, "Old", "Young"))])
+```
 
+```
 ##    ID Treatment  Sex Age Improved AgeDiscret AgeCat
 ## 1: 57   Treated Male  27     Some          3  Young
 ## 2: 46   Treated Male  29     None          3  Young
@@ -140,336 +142,330 @@ well it will work…).
 ## 4: 17   Treated Male  32   Marked          3    Old
 ## 5: 36   Treated Male  46   Marked          5    Old
 ## 6: 23   Treated Male  58   Marked          6    Old
+```
 
 ##### Risks in adding correlated features
 
-These new features are highly correlated to the `Age` feature because
-they are simple transformations of this feature.
+These new features are highly correlated to the `Age` feature because they are simple transformations of this feature.
 
-For many machine learning algorithms, using correlated features is not a
-good idea. It may sometimes make prediction less accurate, and most of
-the time make interpretation of the model almost impossible. GLM, for
-instance, assumes that the features are uncorrelated.
+For many machine learning algorithms, using correlated features is not a good idea. It may sometimes make prediction less accurate, and most of the time make interpretation of the model almost impossible. GLM, for instance, assumes that the features are uncorrelated.
 
-Fortunately, decision tree algorithms (including boosted trees) are very
-robust to these features. Therefore we don’t have to do anything to
-manage this situation.
+Fortunately, decision tree algorithms (including boosted trees) are very robust to these features. Therefore we have nothing to do to manage this situation.
 
 ##### Cleaning data
 
-We remove ID as there is nothing to learn from this feature (it would
-just add some noise).
+We remove ID as there is nothing to learn from this feature (it would just add some noise).
 
+
+```r
 df[,ID:=NULL]
+```
 
 We will list the different values for the column `Treatment`:
 
+
+```r
 levels(df[,Treatment])
+```
 
+```
 ## [1] "Placebo" "Treated"
+```
 
-#### Encoding categorical features
+
+#### One-hot encoding
 
 Next step, we will transform the categorical data to dummy variables.
-Several encoding methods exist, e.g., [one-hot
-encoding](https://en.wikipedia.org/wiki/One-hot) is a common approach.
-We will use the [dummy contrast
-coding](https://stats.oarc.ucla.edu/r/library/r-library-contrast-coding-systems-for-categorical-variables/)
-which is popular because it produces “full rank” encoding (also see
-[this blog post by Max
-Kuhn](http://appliedpredictivemodeling.com/blog/2013/10/23/the-basics-of-encoding-categorical-data-for-predictive-models)).
+This is the [one-hot encoding](http://en.wikipedia.org/wiki/One-hot) step.
 
-The purpose is to transform each value of each *categorical* feature
-into a *binary* feature `{0, 1}`.
+The purpose is to transform each value of each *categorical* feature in a *binary* feature `{0, 1}`.
 
-For example, the column `Treatment` will be replaced by two columns,
-`TreatmentPlacebo`, and `TreatmentTreated`. Each of them will be
-*binary*. Therefore, an observation which has the value `Placebo` in
-column `Treatment` before the transformation will have the value `1` in
-the new column `TreatmentPlacebo` and the value `0` in the new column
-`TreatmentTreated` after the transformation. The column
-`TreatmentPlacebo` will disappear during the contrast encoding, as it
-would be absorbed into a common constant intercept column.
+For example, the column `Treatment` will be replaced by two columns, `Placebo`, and `Treated`. Each of them will be *binary*. Therefore, an observation which has the value `Placebo` in column `Treatment` before the transformation will have after the transformation the value `1` in the new column `Placebo` and the value `0` in the new column `Treated`. The column `Treatment` will disappear during the one-hot encoding.
 
-Column `Improved` is excluded because it will be our `label` column, the
-one we want to predict.
+Column `Improved` is excluded because it will be our `label` column, the one we want to predict.
 
-    sparse_matrix <- sparse.model.matrix(Improved ~ ., data = df)[, -1]
+
+```r
+sparse_matrix <- sparse.model.matrix(Improved~.-1, data = df)
 head(sparse_matrix)
+```
 
-    ## 6 x 9 sparse Matrix of class "dgCMatrix"
-    ##   TreatmentTreated SexMale Age AgeDiscret3 AgeDiscret4 AgeDiscret5 AgeDiscret6
-    ## 1                1       1  27           1           .           .           .
-    ## 2                1       1  29           1           .           .           .
-    ## 3                1       1  30           1           .           .           .
-    ## 4                1       1  32           1           .           .           .
-    ## 5                1       1  46           .           .           1           .
-    ## 6                1       1  58           .           .           .           1
-    ##   AgeDiscret7 AgeCatYoung
-    ## 1           .           1
-    ## 2           .           1
-    ## 3           .           1
-    ## 4           .           .
-    ## 5           .           .
-    ## 6           .           .
+```
+## 6 x 10 sparse Matrix of class "dgCMatrix"
+##                       
+## 1 . 1 1 27 1 . . . . 1
+## 2 . 1 1 29 1 . . . . 1
+## 3 . 1 1 30 1 . . . . 1
+## 4 . 1 1 32 1 . . . . .
+## 5 . 1 1 46 . . 1 . . .
+## 6 . 1 1 58 . . . 1 . .
+```
 
-> Formula `Improved ~ .` used above means transform all *categorical*
-> features but column `Improved` to binary values. The `-1` column
-> selection removes the intercept column which is full of `1` (this
-> column is generated by the conversion). For more information, you can
-> type `?sparse.model.matrix` in the console.
+> Formulae `Improved~.-1` used above means transform all *categorical* features but column `Improved` to binary values. The `-1` is here to remove the first column which is full of `1` (this column is generated by the conversion). For more information, you can type `?sparse.model.matrix` in the console.
 
 Create the output `numeric` vector (not as a sparse `Matrix`):
 
-    output_vector <- df[, Improved] == "Marked"
+
+```r
+output_vector = df[,Improved] == "Marked"
+```
 
 1. set `Y` vector to `0`;
 2. set `Y` to `1` for rows where `Improved == Marked` is `TRUE` ;
 3. return `Y` vector.
 
-## Build the model
+Build the model
+---------------
 
-The code below is very usual. For more information, you can look at the
-documentation of `xgboost` function (or at the vignette [XGBoost
-presentation](https://github.com/dmlc/xgboost/blob/master/R-package/vignettes/xgboostPresentation.Rmd)).
+The code below is very usual. For more information, you can look at the documentation of `xgboost` function (or at the vignette [XGBoost presentation](https://github.com/dmlc/xgboost/blob/master/R-package/vignettes/xgboostPresentation.Rmd)).
 
-    bst <- xgboost(data = sparse_matrix, label = output_vector, max_depth = 4,
+
+```r
+bst <- xgboost(data = sparse_matrix, label = output_vector, max.depth = 4,
                eta = 1, nthread = 2, nrounds = 10,objective = "binary:logistic")
+```
 
-    ## [1]  train-logloss:0.485466 
-    ## [2]  train-logloss:0.438534 
-    ## [3]  train-logloss:0.412250 
-    ## [4]  train-logloss:0.395828 
-    ## [5]  train-logloss:0.384264 
-    ## [6]  train-logloss:0.374028 
-    ## [7]  train-logloss:0.365005 
-    ## [8]  train-logloss:0.351233 
-    ## [9]  train-logloss:0.341678 
-    ## [10] train-logloss:0.334465
+```
+## [0]	train-error:0.202381
+## [1]	train-error:0.166667
+## [2]	train-error:0.166667
+## [3]	train-error:0.166667
+## [4]	train-error:0.154762
+## [5]	train-error:0.154762
+## [6]	train-error:0.154762
+## [7]	train-error:0.166667
+## [8]	train-error:0.166667
+## [9]	train-error:0.166667
+```
 
-You can see some `train-logloss: 0.XXXXX` lines followed by a number. It
-decreases. Each line shows how well the model explains the data. Lower
-is better.
+You can see some `train-error: 0.XXXXX` lines followed by a number. It decreases. Each line shows how well the model explains your data. Lower is better.
 
-A small value for training error may be a symptom of
-[overfitting](https://en.wikipedia.org/wiki/Overfitting), meaning the
-model will not accurately predict unseen values.
+A model which fits too well may [overfit](http://en.wikipedia.org/wiki/Overfitting) (meaning it copy/paste too much the past, and won't be that good to predict the future).
 
-## Feature importance
+> Here you can see the numbers decrease until line 7 and then increase.
+>
+> It probably means we are overfitting. To fix that I should reduce the number of rounds to `nrounds = 4`. I will let things like that because I don't really care for the purpose of this example :-)
+
+Feature importance
+------------------
 
 ## Measure feature importance
 
+
 ### Build the feature importance data.table
 
-Remember, each binary column corresponds to a single value of one of
-*categorical* features.
+In the code below, `sparse_matrix@Dimnames[[2]]` represents the column names of the sparse matrix. These names are the original values of the features (remember, each binary column == one value of one *categorical* feature).
 
-    importance <- xgb.importance(feature_names = colnames(sparse_matrix), model = bst)
+
+```r
+importance <- xgb.importance(feature_names = sparse_matrix@Dimnames[[2]], model = bst)
 head(importance)
+```
 
+```
 ##             Feature        Gain      Cover  Frequency
-    ## 1:              Age 0.622031769 0.67251696 0.67241379
-    ## 2: TreatmentTreated 0.285750540 0.11916651 0.10344828
-    ## 3:          SexMale 0.048744022 0.04522028 0.08620690
-    ## 4:      AgeDiscret6 0.016604639 0.04784639 0.05172414
-    ## 5:      AgeDiscret3 0.016373781 0.08028951 0.05172414
-    ## 6:      AgeDiscret4 0.009270557 0.02858801 0.01724138
+## 1:              Age 0.622031651 0.67251706 0.67241379
+## 2: TreatmentPlacebo 0.285750607 0.11916656 0.10344828
+## 3:          SexMale 0.048744054 0.04522027 0.08620690
+## 4:      AgeDiscret6 0.016604647 0.04784637 0.05172414
+## 5:      AgeDiscret3 0.016373791 0.08028939 0.05172414
+## 6:      AgeDiscret4 0.009270558 0.02858801 0.01724138
+```
 
-> The column `Gain` provides the information we are looking for.
+> The column `Gain` provide the information we are looking for.
 >
 > As you can see, features are classified by `Gain`.
 
-`Gain` is the improvement in accuracy brought by a feature to the
-branches it is on. The idea is that before adding a new split on a
-feature X to the branch there were some wrongly classified elements;
-after adding the split on this feature, there are two new branches, and
-each of these branches is more accurate (one branch saying if your
-observation is on this branch then it should be classified as `1`, and
-the other branch saying the exact opposite).
+`Gain` is the improvement in accuracy brought by a feature to the branches it is on. The idea is that before adding a new split on a feature X to the branch there was some wrongly classified elements, after adding the split on this feature, there are two new branches, and each of these branch is more accurate (one branch saying if your observation is on this branch then it should be classified as `1`, and the other branch saying the exact opposite).
 
-`Cover` is related to the second order derivative (or Hessian) of the
-loss function with respect to a particular variable; thus, a large value
-indicates a variable has a large potential impact on the loss function
-and so is important.
+`Cover` measures the relative quantity of observations concerned by a feature.
 
-`Frequency` is a simpler way to measure the `Gain`. It just counts the
-number of times a feature is used in all generated trees. You should not
-use it (unless you know why you want to use it).
+`Frequency` is a simpler way to measure the `Gain`. It just counts the number of times a feature is used in all generated trees. You should not use it (unless you know why you want to use it).
+
+#### Improvement in the interpretability of feature importance data.table
+
+We can go deeper in the analysis of the model. In the `data.table` above, we have discovered which features counts to predict if the illness will go or not. But we don't yet know the role of these features. For instance, one of the question we may want to answer would be: does receiving a placebo treatment helps to recover from the illness?
+
+One simple solution is to count the co-occurrences of a feature and a class of the classification.
+
+For that purpose we will execute the same function as above but using two more parameters, `data` and `label`.
+
+
+```r
+importanceRaw <- xgb.importance(feature_names = sparse_matrix@Dimnames[[2]], model = bst, data = sparse_matrix, label = output_vector)
+
+# Cleaning for better display
+importanceClean <- importanceRaw[,`:=`(Cover=NULL, Frequency=NULL)]
+
+head(importanceClean)
+```
+
+```
+##             Feature        Split       Gain RealCover RealCover %
+## 1: TreatmentPlacebo -1.00136e-05 0.28575061         7   0.2500000
+## 2:              Age         61.5 0.16374034        12   0.4285714
+## 3:              Age           39 0.08705750         8   0.2857143
+## 4:              Age         57.5 0.06947553        11   0.3928571
+## 5:          SexMale -1.00136e-05 0.04874405         4   0.1428571
+## 6:              Age         53.5 0.04620627        10   0.3571429
+```
+
+> In the table above we have removed two not needed columns and select only the first lines.
+
+First thing you notice is the new column `Split`. It is the split applied to the feature on a branch of one of the tree. Each split is present, therefore a feature can appear several times in this table. Here we can see the feature `Age` is used several times with different splits.
+
+How the split is applied to count the co-occurrences? It is always `<`. For instance, in the second line, we measure the number of persons under 61.5 years with the illness gone after the treatment.
+
+The two other new columns are `RealCover` and `RealCover %`. In the first column it measures the number of observations in the dataset where the split is respected and the label marked as `1`. The second column is the percentage of the whole population that `RealCover` represents.
+
+Therefore, according to our findings, getting a placebo doesn't seem to help but being younger than 61 years may help (seems logic).
+
+> You may wonder how to interpret the `< 1.00001` on the first line. Basically, in a sparse `Matrix`, there is no `0`, therefore, looking for one hot-encoded categorical observations validating the rule `< 1.00001` is like just looking for `1` for this feature.
 
 ### Plotting the feature importance
 
-All these things are nice, but it would be even better to plot the
-results.
 
-    xgb.plot.importance(importance_matrix = importance)
+All these things are nice, but it would be even better to plot the results.
 
-<img src="discoverYourData_files/figure-markdown_strict/unnamed-chunk-12-1.png" style="display: block; margin: auto;" />
 
-Running this line of code, you should get a bar chart showing the
-importance of the 6 features (containing the same data as the output we
-saw earlier, but displaying it visually for easier consumption). Note
-that `xgb.ggplot.importance` is also available for all the ggplot2 fans!
+```r
+xgb.plot.importance(importance_matrix = importanceRaw)
+```
 
-> Depending of the dataset and the learning parameters you may have more
-> than two clusters. Default value is to limit them to `10`, but you can
-> increase this limit. Look at the function documentation for more
-> information.
+```
+## Error in xgb.plot.importance(importance_matrix = importanceRaw): Importance matrix is not correct (column names issue)
+```
 
-According to the plot above, the most important features in this dataset
-to predict if the treatment will work are :
+Feature have automatically been divided in 2 clusters: the interesting features... and the others.
 
--   An individual’s age;
--   Having received a placebo or not;
--   Gender;
--   Our generated feature AgeDiscret. We can see that its contribution
-    is very low.
+> Depending of the dataset and the learning parameters you may have more than two clusters. Default value is to limit them to `10`, but you can increase this limit. Look at the function documentation for more information.
+
+According to the plot above, the most important features in this dataset to predict if the treatment will work are :
+
+* the Age ;
+* having received a placebo or not ;
+* the sex is third but already included in the not interesting features group ;
+* then we see our generated features (AgeDiscret). We can see that their contribution is very low.
 
 ### Do these results make sense?
 
-Let’s check some **Chi2** between each of these features and the label.
+
+Let's check some **Chi2** between each of these features and the label.
 
 Higher **Chi2** means better correlation.
 
+
+```r
 c2 <- chisq.test(df$Age, output_vector)
 print(c2)
+```
 
+```
 ## 
 ## 	Pearson's Chi-squared test
 ## 
 ## data:  df$Age and output_vector
 ## X-squared = 35.475, df = 35, p-value = 0.4458
+```
 
-The Pearson correlation between Age and illness disappearing is
-**35.47**.
+Pearson correlation between Age and illness disappearing is **35.48**.
 
+
+```r
 c2 <- chisq.test(df$AgeDiscret, output_vector)
 print(c2)
+```
 
+```
 ## 
 ## 	Pearson's Chi-squared test
 ## 
 ## data:  df$AgeDiscret and output_vector
 ## X-squared = 8.2554, df = 5, p-value = 0.1427
+```
 
-Our first simplification of Age gives a Pearson correlation of **8.26**.
+Our first simplification of Age gives a Pearson correlation is **8.26**.
 
+
+```r
 c2 <- chisq.test(df$AgeCat, output_vector)
 print(c2)
+```
 
+```
 ## 
 ## 	Pearson's Chi-squared test with Yates' continuity correction
 ## 
 ## data:  df$AgeCat and output_vector
 ## X-squared = 2.3571, df = 1, p-value = 0.1247
+```
 
-The perfectly random split we did between young and old at 30 years old
-has a low correlation of **2.36**. This suggests that, for the
-particular illness we are studying, the age at which someone is
-vulnerable to this disease is likely very different from 30.
+The perfectly random split I did between young and old at 30 years old have a low correlation of **2.36**. It's a result we may expect as may be in my mind > 30 years is being old (I am 32 and starting feeling old, this may explain that), but for the illness we are studying, the age to be vulnerable is not the same.
 
-Moral of the story: don’t let your *gut* lower the quality of your
-model.
+Morality: don't let your *gut* lower the quality of your model.
 
-In *data science*, there is the word *science* :-)
+In *data science* expression, there is the word *science* :-)
 
-## Conclusion
+Conclusion
+----------
 
-As you can see, in general *destroying information by simplifying it
-won’t improve your model*. **Chi2** just demonstrates that.
+As you can see, in general *destroying information by simplifying it won't improve your model*. **Chi2** just demonstrates that.
 
-But in more complex cases, creating a new feature from an existing one
-may help the algorithm and improve the model.
+But in more complex cases, creating a new feature based on existing one which makes link with the outcome more obvious may help the algorithm and improve the model.
 
-+The case studied here is not complex enough to show that. Check [Kaggle
-website](https://www.kaggle.com/) for some challenging datasets.
+The case studied here is not enough complex to show that. Check [Kaggle website](http://www.kaggle.com/) for some challenging datasets. However it's almost always worse when you add some arbitrary rules.
 
-Moreover, you can see that even if we have added some new features which
-are not very useful/highly correlated with other features, the boosting
-tree algorithm was still able to choose the best one (which in this case
-is the Age).
+Moreover, you can notice that even if we have added some not useful new features highly correlated with other features, the boosting tree algorithm have been able to choose the best one, which in this case is the Age.
 
-Linear models may not perform as well.
+Linear models may not be that smart in this scenario.
 
-## Special Note: What about Random Forests™?
+Special Note: What about Random Forests™?
+-----------------------------------------
 
-As you may know, the [Random
-Forests](https://en.wikipedia.org/wiki/Random_forest) algorithm is
-cousin with boosting and both are part of the [ensemble
-learning](https://en.wikipedia.org/wiki/Ensemble_learning) family.
+As you may know, [Random Forests](http://en.wikipedia.org/wiki/Random_forest) algorithm is cousin with boosting and both are part of the [ensemble learning](http://en.wikipedia.org/wiki/Ensemble_learning) family.
 
-Both train several decision trees for one dataset. The *main* difference
-is that in Random Forests, trees are independent and in boosting, the
-`N+1`-st tree focuses its learning on the loss (&lt;=&gt; what has not
-been well modeled by the tree `N`).
+Both train several decision trees for one dataset. The *main* difference is that in Random Forests, trees are independent and in boosting, the tree `N+1` focus its learning on the loss (<=> what has not been well modeled by the tree `N`).
 
-This difference can have an impact on a edge case in feature importance
-analysis: *correlated features*.
+This difference have an impact on a corner case in feature importance analysis: the *correlated features*.
 
-Imagine two features perfectly correlated, feature `A` and feature `B`.
-For one specific tree, if the algorithm needs one of them, it will
-choose randomly (true in both boosting and Random Forests).
+Imagine two features perfectly correlated, feature `A` and feature `B`. For one specific tree, if the algorithm needs one of them, it will choose randomly (true in both boosting and Random Forests).
 
-However, in Random Forests this random choice will be done for each
-tree, because each tree is independent from the others. Therefore,
-approximately (and depending on your parameters) 50% of the trees will
-choose feature `A` and the other 50% will choose feature `B`. So the
-*importance* of the information contained in `A` and `B` (which is the
-same, because they are perfectly correlated) is diluted in `A` and `B`.
-So you won’t easily know this information is important to predict what
-you want to predict! It is even worse when you have 10 correlated
-features…
+However, in Random Forests this random choice will be done for each tree, because each tree is independent from the others. Therefore, approximatively, depending of your parameters, 50% of the trees will choose feature `A` and the other 50% will choose feature `B`. So the *importance* of the information contained in `A` and `B` (which is the same, because they are perfectly correlated) is diluted in `A` and `B`. So you won't easily know this information is important to predict what you want to predict! It is even worse when you have 10 correlated features...
 
-In boosting, when a specific link between feature and outcome have been
-learned by the algorithm, it will try to not refocus on it (in theory it
-is what happens, reality is not always that simple). Therefore, all the
-importance will be on feature `A` or on feature `B` (but not both). You
-will know that one feature has an important role in the link between the
-observations and the label. It is still up to you to search for the
-correlated features to the one detected as important if you need to know
-all of them.
+In boosting, when a specific link between feature and outcome have been learned by the algorithm, it will try to not refocus on it (in theory it is what happens, reality is not always that simple). Therefore, all the importance will be on feature `A` or on feature `B` (but not both). You will know that one feature have an important role in the link between the observations and the label. It is still up to you to search for the correlated features to the one detected as important if you need to know all of them.
 
-If you want to try Random Forests algorithm, you can tweak XGBoost
-parameters!
+If you want to try Random Forests algorithm, you can tweak XGBoost parameters!
 
-For instance, to compute a model with 1000 trees, with a 0.5 factor on
-sampling rows and columns:
+**Warning**: this is still an experimental parameter.
 
+For instance, to compute a model with 1000 trees, with a 0.5 factor on sampling rows and columns:
+
+
+```r
 data(agaricus.train, package='xgboost')
 data(agaricus.test, package='xgboost')
 train <- agaricus.train
 test <- agaricus.test
 
 #Random Forest - 1000 trees
-    bst <- xgboost(
-        data = train$data
-        , label = train$label
-        , max_depth = 4
-        , num_parallel_tree = 1000
-        , subsample = 0.5
-        , colsample_bytree = 0.5
-        , nrounds = 1
-        , objective = "binary:logistic"
-    )
+bst <- xgboost(data = train$data, label = train$label, max.depth = 4, num_parallel_tree = 1000, subsample = 0.5, colsample_bytree =0.5, nrounds = 1, objective = "binary:logistic")
+```
 
-    ## [1]  train-logloss:0.456201
+```
+## [0]	train-error:0.002150
+```
 
+```r
 #Boosting - 3 rounds
-    bst <- xgboost(
-        data = train$data
-        , label = train$label
-        , max_depth = 4
-        , nrounds = 3
-        , objective = "binary:logistic"
-    )
+bst <- xgboost(data = train$data, label = train$label, max.depth = 4, nrounds = 3, objective = "binary:logistic")
+```
 
-    ## [1]  train-logloss:0.444882 
-    ## [2]  train-logloss:0.302428 
-    ## [3]  train-logloss:0.212847
+```
+## [0]	train-error:0.006142
+## [1]	train-error:0.006756
+## [2]	train-error:0.001228
+```
 
 > Note that the parameter `round` is set to `1`.
 
-> [**Random
-> Forests**](https://www.stat.berkeley.edu/~breiman/RandomForests/cc_papers.htm)
-> is a trademark of Leo Breiman and Adele Cutler and is licensed
-> exclusively to Salford Systems for the commercial release of the
-> software.
+> [**Random Forests**](https://www.stat.berkeley.edu/~breiman/RandomForests/cc_papers.htm) is a trademark of Leo Breiman and Adele Cutler and is licensed exclusively to Salford Systems for the commercial release of the software.

doc/build.rst

@@ -119,7 +119,7 @@ An up-to-date version of the CUDA toolkit is required.
 
 .. note:: Checking your compiler version
 
-  CUDA is really picky about supported compilers, a table for the compatible compilers for the latest CUDA version on Linux can be seen `here <https://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html>`_.
+  CUDA is really picky about supported compilers, a table for the compatible compilers for the latests CUDA version on Linux can be seen `here <https://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html>`_.
 
   Some distros package a compatible ``gcc`` version with CUDA. If you run into compiler errors with ``nvcc``, try specifying the correct compiler with ``-DCMAKE_CXX_COMPILER=/path/to/correct/g++ -DCMAKE_C_COMPILER=/path/to/correct/gcc``. On Arch Linux, for example, both binaries can be found under ``/opt/cuda/bin/``.
 

doc/conf.py

@@ -19,6 +19,7 @@ import sys
 import tarfile
 import urllib.request
 import warnings
+from subprocess import call
 from urllib.error import HTTPError
 
 from sh.contrib import git
@@ -147,20 +148,12 @@ extensions = [
 
 sphinx_gallery_conf = {
     # path to your example scripts
-    "examples_dirs": [
-        "../demo/guide-python",
-        "../demo/dask",
-        "../demo/aft_survival",
-        "../demo/gpu_acceleration",
-        "../demo/rmm_plugin"
-    ],
+    "examples_dirs": ["../demo/guide-python", "../demo/dask", "../demo/aft_survival"],
     # path to where to save gallery generated output
     "gallery_dirs": [
         "python/examples",
         "python/dask-examples",
         "python/survival-examples",
-        "python/gpu-examples",
-        "python/rmm-examples",
     ],
     "matplotlib_animations": True,
 }

doc/contrib/ci.rst

@@ -32,7 +32,7 @@ GitHub Actions is also used to build Python wheels targeting MacOS Intel and App
 ``python_wheels`` pipeline sets up environment variables prefixed ``CIBW_*`` to indicate the target
 OS and processor. The pipeline then invokes the script ``build_python_wheels.sh``, which in turns
 calls ``cibuildwheel`` to build the wheel. The ``cibuildwheel`` is a library that sets up a
-suitable Python environment for each OS and processor target. Since we don't have Apple Silicon
+suitable Python environment for each OS and processor target. Since we don't have Apple Silion
 machine in GitHub Actions, cross-compilation is needed; ``cibuildwheel`` takes care of the complex
 task of cross-compiling a Python wheel. (Note that ``cibuildwheel`` will call
 ``pip wheel``. Since XGBoost has a native library component, we created a customized build
@@ -131,7 +131,7 @@ set up a credential pair in order to provision resources on AWS. See
 Worker Image Pipeline
 =====================
 Building images for worker machines used to be a chore: you'd provision an EC2 machine, SSH into it, and
-manually install the necessary packages. This process is not only laborious but also error-prone. You may
+manually install the necessary packages. This process is not only laborous but also error-prone. You may
 forget to install a package or change a system configuration.
 
 No more. Now we have an automated pipeline for building images for worker machines.

doc/contrib/coding_guide.rst

@@ -100,7 +100,7 @@ two automatic checks to enforce coding style conventions. To expedite the code r
 
 Linter
 ======
-We use `pylint <https://github.com/PyCQA/pylint>`_ and `cpplint <https://github.com/cpplint/cpplint>`_ to enforce style convention and find potential errors. Linting is especially useful for Python, as we can catch many errors that would have otherwise occurred at run-time.
+We use `pylint <https://github.com/PyCQA/pylint>`_ and `cpplint <https://github.com/cpplint/cpplint>`_ to enforce style convention and find potential errors. Linting is especially useful for Python, as we can catch many errors that would have otherwise occured at run-time.
 
 To run this check locally, run the following command from the top level source tree:
 

doc/contrib/donate.rst

@@ -29,7 +29,7 @@ The Project Management Committee (PMC) of the XGBoost project appointed `Open So
 
 All expenses incurred for hosting CI will be submitted to the fiscal host with receipts. Only the expenses in the following categories will be approved for reimbursement:
 
-* Cloud expenses for the cloud test farm (https://buildkite.com/xgboost)
+* Cloud exprenses for the cloud test farm (https://buildkite.com/xgboost)
 * Cost of domain https://xgboost-ci.net
 * Monthly cost of using BuildKite
 * Hosting cost of the User Forum (https://discuss.xgboost.ai)

doc/contrib/unit_tests.rst

@@ -169,7 +169,7 @@ supply a specified SANITIZER_PATH.
 
 How to use sanitizers with CUDA support
 =======================================
-Running XGBoost on CUDA with address sanitizer (asan) will raise memory error.
+Runing XGBoost on CUDA with address sanitizer (asan) will raise memory error.
 To use asan with CUDA correctly, you need to configure asan via ASAN_OPTIONS
 environment variable:
 

doc/faq.rst

@@ -63,7 +63,7 @@ XGBoost supports missing values by default.
 In tree algorithms, branch directions for missing values are learned during training.
 Note that the gblinear booster treats missing values as zeros.
 
-When the ``missing`` parameter is specified, values in the input predictor that is equal to
+When the ``missing`` parameter is specifed, values in the input predictor that is equal to
 ``missing`` will be treated as missing and removed.  By default it's set to ``NaN``.
 
 **************************************

doc/gpu/index.rst

@@ -14,46 +14,53 @@ Most of the algorithms in XGBoost including training, prediction and evaluation
 
 Usage
 =====
+Specify the ``tree_method`` parameter as ``gpu_hist``. For details around the ``tree_method`` parameter, see :doc:`tree method </treemethod>`.
+
+Supported parameters
+--------------------
+
+GPU accelerated prediction is enabled by default for the above mentioned ``tree_method`` parameters but can be switched to CPU prediction by setting ``predictor`` to ``cpu_predictor``. This could be useful if you want to conserve GPU memory. Likewise when using CPU algorithms, GPU accelerated prediction can be enabled by setting ``predictor`` to ``gpu_predictor``.
+
+The device ordinal (which GPU to use if you have many of them) can be selected using the
+``gpu_id`` parameter, which defaults to 0 (the first device reported by CUDA runtime).
 
-To enable GPU acceleration, specify the ``device`` parameter as ``cuda``. In addition, the device ordinal (which GPU to use if you have multiple devices in the same node) can be specified using the ``cuda:<ordinal>`` syntax, where ``<ordinal>`` is an integer that represents the device ordinal. XGBoost defaults to 0 (the first device reported by CUDA runtime).
 
 The GPU algorithms currently work with CLI, Python, R, and JVM packages. See :doc:`/install` for details.
 
 .. code-block:: python
   :caption: Python example
 
-  params = dict()
-  params["device"] = "cuda"
-  params["tree_method"] = "hist"
-  Xy = xgboost.QuantileDMatrix(X, y)
-  xgboost.train(params, Xy)
+  param['gpu_id'] = 0
+  param['tree_method'] = 'gpu_hist'
 
 .. code-block:: python
-  :caption: With the Scikit-Learn interface
+  :caption: With Scikit-Learn interface
+
+  XGBRegressor(tree_method='gpu_hist', gpu_id=0)
 
-  XGBRegressor(tree_method="hist", device="cuda")
 
 GPU-Accelerated SHAP values
 =============================
-XGBoost makes use of `GPUTreeShap <https://github.com/rapidsai/gputreeshap>`_ as a backend for computing shap values when the GPU is used.
+XGBoost makes use of `GPUTreeShap <https://github.com/rapidsai/gputreeshap>`_ as a backend for computing shap values when the GPU predictor is selected.
 
 .. code-block:: python
 
-  booster.set_param({"device": "cuda:0"})
-  shap_values = booster.predict(dtrain, pred_contribs=True)
+  model.set_param({"gpu_id": "0", "tree_method": "gpu_hist"})
+  shap_values = model.predict(dtrain, pred_contribs=True)
   shap_interaction_values = model.predict(dtrain, pred_interactions=True)
 
-See :ref:`sphx_glr_python_gpu-examples_tree_shap.py` for a worked example.
+See examples `here
+<https://github.com/dmlc/xgboost/tree/master/demo/gpu_acceleration>`__.
 
 Multi-node Multi-GPU Training
 =============================
 
-XGBoost supports fully distributed GPU training using `Dask <https://dask.org/>`_, ``Spark`` and ``PySpark``. For getting started with Dask see our tutorial :doc:`/tutorials/dask` and worked examples :doc:`/python/dask-examples/index`, also Python documentation :ref:`dask_api` for complete reference. For usage with ``Spark`` using Scala see :doc:`/jvm/xgboost4j_spark_gpu_tutorial`. Lastly for distributed GPU training with ``PySpark``, see :doc:`/tutorials/spark_estimator`.
+XGBoost supports fully distributed GPU training using `Dask <https://dask.org/>`_, ``Spark`` and ``PySpark``. For getting started with Dask see our tutorial :doc:`/tutorials/dask` and worked examples `here <https://github.com/dmlc/xgboost/tree/master/demo/dask>`__, also Python documentation :ref:`dask_api` for complete reference. For usage with ``Spark`` using Scala see :doc:`/jvm/xgboost4j_spark_gpu_tutorial`. Lastly for distributed GPU training with ``PySpark``, see :doc:`/tutorials/spark_estimator`.
 
 
 Memory usage
 ============
-The following are some guidelines on the device memory usage of the ``hist`` tree method on GPU.
+The following are some guidelines on the device memory usage of the `gpu_hist` tree method.
 
 Memory inside xgboost training is generally allocated for two reasons - storing the dataset and working memory.
 
@@ -66,13 +73,12 @@ If you are getting out-of-memory errors on a big dataset, try the or :py:class:`
 
 CPU-GPU Interoperability
 ========================
-
-The model can be used on any device regardless of the one used to train it. For instance, a model trained using GPU can still work on a CPU-only machine and vice versa. For more information about model serialization, see :doc:`/tutorials/saving_model`.
+XGBoost models trained on GPUs can be used on CPU-only systems to generate predictions. For information about how to save and load an XGBoost model, see :doc:`/tutorials/saving_model`.
 
 
 Developer notes
 ===============
-The application may be profiled with annotations by specifying ``USE_NTVX`` to cmake. Regions covered by the 'Monitor' class in CUDA code will automatically appear in the nsight profiler when `verbosity` is set to 3.
+The application may be profiled with annotations by specifying USE_NTVX to cmake. Regions covered by the 'Monitor' class in CUDA code will automatically appear in the nsight profiler when `verbosity` is set to 3.
 
 **********
 References

doc/install.rst

@@ -3,10 +3,10 @@ Installation Guide
 ##################
 
 XGBoost provides binary packages for some language bindings.  The binary packages support
-the GPU algorithm (``device=cuda:0``) on machines with NVIDIA GPUs. Please note that
-**training with multiple GPUs is only supported for Linux platform**. See
-:doc:`gpu/index`.  Also we have both stable releases and nightly builds, see below for how
-to install them.  For building from source, visit :doc:`this page </build>`.
+the GPU algorithm (``gpu_hist``) on machines with NVIDIA GPUs. Please note that **training
+with multiple GPUs is only supported for Linux platform**. See :doc:`gpu/index`.  Also we
+have both stable releases and nightly builds, see below for how to install them.  For
+building from source, visit :doc:`this page </build>`.
 
 .. contents:: Contents
 
@@ -189,7 +189,7 @@ This will check out the latest stable version from the Maven Central.
 
 For the latest release version number, please check `release page <https://github.com/dmlc/xgboost/releases>`_.
 
-To enable the GPU algorithm (``device='cuda'``), use artifacts ``xgboost4j-gpu_2.12`` and ``xgboost4j-spark-gpu_2.12`` instead (note the ``gpu`` suffix).
+To enable the GPU algorithm (``tree_method='gpu_hist'``), use artifacts ``xgboost4j-gpu_2.12`` and ``xgboost4j-spark-gpu_2.12`` instead (note the ``gpu`` suffix).
 
 
 .. note:: Windows not supported in the JVM package
@@ -325,4 +325,4 @@ The SNAPSHOT JARs are hosted by the XGBoost project. Every commit in the ``maste
 
 You can browse the file listing of the Maven repository at https://s3-us-west-2.amazonaws.com/xgboost-maven-repo/list.html.
 
-To enable the GPU algorithm (``device='cuda'``), use artifacts ``xgboost4j-gpu_2.12`` and ``xgboost4j-spark-gpu_2.12`` instead (note the ``gpu`` suffix).
+To enable the GPU algorithm (``tree_method='gpu_hist'``), use artifacts ``xgboost4j-gpu_2.12`` and ``xgboost4j-spark-gpu_2.12`` instead (note the ``gpu`` suffix).

doc/jvm/java_intro.rst

@@ -129,7 +129,7 @@ With parameters and data, you are able to train a booster model.
 
     booster.saveModel("model.bin");
 
-* Generating model dump with feature map
+* Generaing model dump with feature map
 
   .. code-block:: java
 

doc/jvm/xgboost4j_spark_gpu_tutorial.rst

@@ -121,7 +121,7 @@ To train a XGBoost model for classification, we need to claim a XGBoostClassifie
       "objective" -> "multi:softprob",
       "num_class" -> 3,
       "num_round" -> 100,
-      "device" -> "cuda",
+      "tree_method" -> "gpu_hist",
       "num_workers" -> 1)
 
   val featuresNames = schema.fieldNames.filter(name => name != labelName)
@@ -130,14 +130,15 @@ To train a XGBoost model for classification, we need to claim a XGBoostClassifie
       .setFeaturesCol(featuresNames)
       .setLabelCol(labelName)
 
-The ``device`` parameter is for informing XGBoost that CUDA devices should be used instead of CPU. Unlike the single-node mode, GPUs are managed by spark instead of by XGBoost. Therefore, explicitly specified device ordinal like ``cuda:1`` is not support.
-
-The available parameters for training a XGBoost model can be found in :doc:`here </parameter>`. Similar to the XGBoost4J-Spark package, in addition to the default set of parameters, XGBoost4J-Spark-GPU also supports the camel-case variant of these parameters to be consistent with Spark's MLlib naming convention.
+The available parameters for training a XGBoost model can be found in :doc:`here </parameter>`.
+Similar to the XGBoost4J-Spark package, in addition to the default set of parameters,
+XGBoost4J-Spark-GPU also supports the camel-case variant of these parameters to be
+consistent with Spark's MLlib naming convention.
 
 Specifically, each parameter in :doc:`this page </parameter>` has its equivalent form in
-XGBoost4J-Spark-GPU with camel case. For example, to set ``max_depth`` for each tree, you
-can pass parameter just like what we did in the above code snippet (as ``max_depth``
-wrapped in a Map), or you can do it through setters in XGBoostClassifer:
+XGBoost4J-Spark-GPU with camel case. For example, to set ``max_depth`` for each tree, you can pass
+parameter just like what we did in the above code snippet (as ``max_depth`` wrapped in a Map), or
+you can do it through setters in XGBoostClassifer:
 
 .. code-block:: scala
 

doc/parameter.rst

@@ -34,20 +34,6 @@ General Parameters
 
   - Which booster to use. Can be ``gbtree``, ``gblinear`` or ``dart``; ``gbtree`` and ``dart`` use tree based models while ``gblinear`` uses linear functions.
 
-* ``device`` [default= ``cpu``]
-
-  .. versionadded:: 2.0.0
-
-  - Device for XGBoost to run. User can set it to one of the following values:
-
-    + ``cpu``: Use CPU.
-    + ``cuda``: Use a GPU (CUDA device).
-    + ``cuda:<ordinal>``: ``<ordinal>`` is an integer that specifies the ordinal of the GPU (which GPU do you want to use if you have more than one devices).
-    + ``gpu``: Default GPU device selection from the list of available and supported devices. Only ``cuda`` devices are supported currently.
-    + ``gpu:<ordinal>``: Default GPU device selection from the list of available and supported devices. Only ``cuda`` devices are supported currently.
-
-    For more information about GPU acceleration, see :doc:`/gpu/index`. In distributed environments, ordinal selection is handled by distributed frameworks instead of XGBoost. As a result, using ``cuda:<ordinal>`` will result in an error. Use ``cuda`` instead.
-
 * ``verbosity`` [default=1]
 
   - Verbosity of printing messages.  Valid values are 0 (silent), 1 (warning), 2 (info), 3
@@ -58,7 +44,7 @@ General Parameters
 * ``validate_parameters`` [default to ``false``, except for Python, R and CLI interface]
 
   - When set to True, XGBoost will perform validation of input parameters to check whether
-    a parameter is used or not. A warning is emitted when there's unknown parameter.
+    a parameter is used or not.
 
 * ``nthread`` [default to maximum number of threads available if not set]
 
@@ -69,6 +55,10 @@ General Parameters
 
   - Flag to disable default metric. Set to 1 or ``true`` to disable.
 
+* ``num_feature`` [set automatically by XGBoost, no need to be set by user]
+
+  - Feature dimension used in boosting, set to maximum dimension of the feature
+
 Parameters for Tree Booster
 ===========================
 * ``eta`` [default=0.3, alias: ``learning_rate``]
@@ -109,7 +99,7 @@ Parameters for Tree Booster
   - ``gradient_based``: the selection probability for each training instance is proportional to the
     *regularized absolute value* of gradients (more specifically, :math:`\sqrt{g^2+\lambda h^2}`).
     ``subsample`` may be set to as low as 0.1 without loss of model accuracy. Note that this
-    sampling method is only supported when ``tree_method`` is set to ``hist`` and the device is ``cuda``; other tree
+    sampling method is only supported when ``tree_method`` is set to ``gpu_hist``; other tree
     methods only support ``uniform`` sampling.
 
 * ``colsample_bytree``, ``colsample_bylevel``, ``colsample_bynode`` [default=1]
@@ -141,15 +131,26 @@ Parameters for Tree Booster
 * ``tree_method`` string [default= ``auto``]
 
   - The tree construction algorithm used in XGBoost. See description in the `reference paper <http://arxiv.org/abs/1603.02754>`_ and :doc:`treemethod`.
+  - XGBoost supports  ``approx``, ``hist`` and ``gpu_hist`` for distributed training.  Experimental support for external memory is available for ``approx`` and ``gpu_hist``.
 
-  - Choices: ``auto``, ``exact``, ``approx``, ``hist``, this is a combination of commonly
-    used updaters.  For other updaters like ``refresh``, set the parameter ``updater``
-    directly.
+  - Choices: ``auto``, ``exact``, ``approx``, ``hist``, ``gpu_hist``, this is a
+    combination of commonly used updaters.  For other updaters like ``refresh``, set the
+    parameter ``updater`` directly.
 
-    - ``auto``: Same as the ``hist`` tree method.
+    - ``auto``: Use heuristic to choose the fastest method.
+
+      - For small dataset, exact greedy (``exact``) will be used.
+      - For larger dataset, approximate algorithm (``approx``) will be chosen.  It's
+        recommended to try ``hist`` and ``gpu_hist`` for higher performance with large
+        dataset.
+        (``gpu_hist``)has support for ``external memory``.
+
+      - Because old behavior is always use exact greedy in single machine, user will get a
+        message when approximate algorithm is chosen to notify this choice.
     - ``exact``: Exact greedy algorithm.  Enumerates all split candidates.
     - ``approx``: Approximate greedy algorithm using quantile sketch and gradient histogram.
     - ``hist``: Faster histogram optimized approximate greedy algorithm.
+    - ``gpu_hist``: GPU implementation of ``hist`` algorithm.
 
 * ``scale_pos_weight`` [default=1]
 
@@ -162,8 +163,7 @@ Parameters for Tree Booster
     - ``grow_colmaker``: non-distributed column-based construction of trees.
     - ``grow_histmaker``: distributed tree construction with row-based data splitting based on global proposal of histogram counting.
     - ``grow_quantile_histmaker``: Grow tree using quantized histogram.
-    - ``grow_gpu_hist``:  Enabled when ``tree_method`` is set to ``hist`` along with ``device=cuda``.
-    - ``grow_gpu_approx``: Enabled when ``tree_method`` is set to ``approx`` along with ``device=cuda``.
+    - ``grow_gpu_hist``: Grow tree with GPU.
     - ``sync``: synchronizes trees in all distributed nodes.
     - ``refresh``: refreshes tree's statistics and/or leaf values based on the current data. Note that no random subsampling of data rows is performed.
     - ``prune``: prunes the splits where loss < min_split_loss (or gamma) and nodes that have depth greater than ``max_depth``.
@@ -183,7 +183,7 @@ Parameters for Tree Booster
 * ``grow_policy`` [default= ``depthwise``]
 
   - Controls a way new nodes are added to the tree.
-  - Currently supported only if ``tree_method`` is set to ``hist`` or ``approx``.
+  - Currently supported only if ``tree_method`` is set to ``hist``, ``approx`` or ``gpu_hist``.
   - Choices: ``depthwise``, ``lossguide``
 
     - ``depthwise``: split at nodes closest to the root.
@@ -195,7 +195,7 @@ Parameters for Tree Booster
 
 * ``max_bin``, [default=256]
 
-  - Only used if ``tree_method`` is set to ``hist`` or ``approx``.
+  - Only used if ``tree_method`` is set to ``hist``, ``approx`` or ``gpu_hist``.
   - Maximum number of discrete bins to bucket continuous features.
   - Increasing this number improves the optimality of splits at the cost of higher computation time.
 
@@ -226,15 +226,6 @@ Parameters for Tree Booster
     - ``one_output_per_tree``: One model for each target.
     - ``multi_output_tree``:  Use multi-target trees.
 
-* ``max_cached_hist_node``, [default = 65536]
-
-  Maximum number of cached nodes for CPU histogram.
-
-  .. versionadded:: 2.0.0
-
-  - For most of the cases this parameter should not be set except for growing deep trees
-    on CPU.
-
 .. _cat-param:
 
 Parameters for Categorical Feature
@@ -329,7 +320,7 @@ Parameters for Linear Booster (``booster=gblinear``)
   - Choice of algorithm to fit linear model
 
     - ``shotgun``: Parallel coordinate descent algorithm based on shotgun algorithm. Uses 'hogwild' parallelism and therefore produces a nondeterministic solution on each run.
-    - ``coord_descent``: Ordinary coordinate descent algorithm. Also multithreaded but still produces a deterministic solution. When the ``device`` parameter is set to ``cuda`` or ``gpu``, a GPU variant would be used.
+    - ``coord_descent``: Ordinary coordinate descent algorithm. Also multithreaded but still produces a deterministic solution.
 
 * ``feature_selector`` [default= ``cyclic``]
 
@@ -354,7 +345,7 @@ Specify the learning task and the corresponding learning objective. The objectiv
 
   - ``reg:squarederror``: regression with squared loss.
   - ``reg:squaredlogerror``: regression with squared log loss :math:`\frac{1}{2}[log(pred + 1) - log(label + 1)]^2`.  All input labels are required to be greater than -1.  Also, see metric ``rmsle`` for possible issue  with this objective.
-  - ``reg:logistic``: logistic regression, output probability
+  - ``reg:logistic``: logistic regression.
   - ``reg:pseudohubererror``: regression with Pseudo Huber loss, a twice differentiable alternative to absolute loss.
   - ``reg:absoluteerror``: Regression with L1 error. When tree model is used, leaf value is refreshed after tree construction. If used in distributed training, the leaf value is calculated as the mean value from all workers, which is not guaranteed to be optimal.
 

doc/prediction.rst

@@ -35,14 +35,14 @@ After 1.4 release, we added a new parameter called ``strict_shape``, one can set
   has equivalent output shape of ``multi:softprob`` due to dropped transformation.  If
   strict shape is set to False then output can have 1 or 2 dim depending on used model.
 
-- When using ``pred_contribs`` with ``strict_shape`` set to ``True``:
+- When using ``preds_contribs`` with ``strict_shape`` set to ``True``:
 
   Output is a 3-dim array, with ``(rows, groups, columns + 1)`` as shape.  Whether
   ``approx_contribs`` is used does not change the output shape. If the strict shape
   parameter is not set, it can be a 2 or 3 dimension array depending on whether
   multi-class model is being used.
 
-- When using ``pred_interactions`` with ``strict_shape`` set to ``True``:
+- When using ``preds_interactions`` with ``strict_shape`` set to ``True``:
 
   Output is a 4-dim array, with ``(rows, groups, columns + 1, columns + 1)`` as shape.
   Like the predict contribution case, whether ``approx_contribs`` is used does not change
@@ -54,7 +54,7 @@ After 1.4 release, we added a new parameter called ``strict_shape``, one can set
   Output is a 4-dim array with ``(n_samples, n_iterations, n_classes, n_trees_in_forest)``
   as shape.  ``n_trees_in_forest`` is specified by the ``numb_parallel_tree`` during
   training.  When strict shape is set to False, output is a 2-dim array with last 3 dims
-  concatenated into 1.  Also the last dimension is dropped if it equals to 1. When using
+  concatenated into 1.  Also the last dimension is dropped if it eqauls to 1. When using
   ``apply`` method in scikit learn interface, this is set to False by default.
 
 
@@ -68,7 +68,7 @@ n_classes, n_trees_in_forest)``, while R with ``strict_shape=TRUE`` outputs
 Other than these prediction types, there's also a parameter called ``iteration_range``,
 which is similar to model slicing.  But instead of actually splitting up the model into
 multiple stacks, it simply returns the prediction formed by the trees within range.
-Number of trees created in each iteration equals to :math:`trees_i = num\_class \times
+Number of trees created in each iteration eqauls to :math:`trees_i = num\_class \times
 num\_parallel\_tree`.  So if you are training a boosted random forest with size of 4, on
 the 3-class classification dataset, and want to use the first 2 iterations of trees for
 prediction, you need to provide ``iteration_range=(0, 2)``.  Then the first :math:`2

doc/python/.gitignore

@@ -1,5 +1,3 @@
 examples
 dask-examples
 survival-examples
-gpu-examples
-rmm-examples

doc/python/index.rst

@@ -17,5 +17,3 @@ Contents
   examples/index
   dask-examples/index
   survival-examples/index
-  gpu-examples/index
-  rmm-examples/index

doc/python/model.rst

@@ -37,7 +37,3 @@ The sliced model is a copy of selected trees, that means the model itself is imm
 during slicing.  This feature is the basis of `save_best` option in early stopping
 callback. See :ref:`sphx_glr_python_examples_individual_trees.py` for a worked example on
 how to combine prediction with sliced trees.
-
-.. note::
-
-   The returned model slice doesn't contain attributes like :py:class:`~xgboost.Booster.best_iteration` and :py:class:`~xgboost.Booster.best_score`.

doc/python/python_api.rst

@@ -23,16 +23,12 @@ Core Data Structure
     :show-inheritance:
 
 .. autoclass:: xgboost.QuantileDMatrix
-    :members:
     :show-inheritance:
 
 .. autoclass:: xgboost.Booster
     :members:
     :show-inheritance:
 
-.. autoclass:: xgboost.DataIter
-    :members:
-    :show-inheritance:
 
 Learning API
 ------------

doc/python/python_intro.rst

@@ -310,8 +310,8 @@ for more info.
 
 .. code-block:: python
 
-  # Use "hist" for training the model.
-  reg = xgb.XGBRegressor(tree_method="hist", device="cuda")
+  # Use "gpu_hist" for training the model.
+  reg = xgb.XGBRegressor(tree_method="gpu_hist")
   # Fit the model using predictor X and response y.
   reg.fit(X, y)
   # Save model into JSON format.

doc/python/sklearn_estimator.rst

@@ -20,7 +20,7 @@ sklearn estimator interface is still working in progress.
 
 You can find some some quick start examples at
 :ref:`sphx_glr_python_examples_sklearn_examples.py`. The main advantage of using sklearn
-interface is that it works with most of the utilities provided by sklearn like
+interface is that it works with most of the utilites provided by sklearn like
 :py:func:`sklearn.model_selection.cross_validate`. Also, many other libraries recognize
 the sklearn estimator interface thanks to its popularity.
 

doc/treemethod.rst

@@ -3,14 +3,14 @@ Tree Methods
 ############
 
 For training boosted tree models, there are 2 parameters used for choosing algorithms,
-namely ``updater`` and ``tree_method``.  XGBoost has 3 builtin tree methods, namely
-``exact``, ``approx`` and ``hist``.  Along with these tree methods, there are also some
-free standing updaters including ``refresh``, ``prune`` and ``sync``.  The parameter
-``updater`` is more primitive than ``tree_method`` as the latter is just a
-pre-configuration of the former.  The difference is mostly due to historical reasons that
-each updater requires some specific configurations and might has missing features.  As we
-are moving forward, the gap between them is becoming more and more irrelevant.  We will
-collectively document them under tree methods.
+namely ``updater`` and ``tree_method``.  XGBoost has 4 builtin tree methods, namely
+``exact``, ``approx``, ``hist`` and ``gpu_hist``.  Along with these tree methods, there
+are also some free standing updaters including ``refresh``,
+``prune`` and ``sync``.  The parameter ``updater`` is more primitive than ``tree_method``
+as the latter is just a pre-configuration of the former.  The difference is mostly due to
+historical reasons that each updater requires some specific configurations and might has
+missing features.  As we are moving forward, the gap between them is becoming more and
+more irrelevant.  We will collectively document them under tree methods.
 
 **************
 Exact Solution
@@ -19,23 +19,23 @@ Exact Solution
 Exact means XGBoost considers all candidates from data for tree splitting, but underlying
 the objective is still interpreted as a Taylor expansion.
 
-1. ``exact``: The vanilla gradient boosting tree algorithm described in `reference paper
-   <http://arxiv.org/abs/1603.02754>`_.  During split-finding, it iterates over all
-   entries of input data.  It's more accurate (among other greedy methods) but
-   computationally slower in compared to other tree methods.  Further more, its feature
-   set is limited. Features like distributed training and external memory that require
-   approximated quantiles are not supported. This tree method can be used with the
-   parameter ``tree_method`` set to ``exact``.
+1. ``exact``: Vanilla gradient boosting tree algorithm described in `reference paper
+   <http://arxiv.org/abs/1603.02754>`_.  During each split finding procedure, it iterates
+   over all entries of input data.  It's more accurate (among other greedy methods) but
+   slow in computation performance.  Also it doesn't support distributed training as
+   XGBoost employs row spliting data distribution while ``exact`` tree method works on a
+   sorted column format.  This tree method can be used with parameter ``tree_method`` set
+   to ``exact``.
 
 
 **********************
 Approximated Solutions
 **********************
 
-As ``exact`` tree method is slow in computation performance and difficult to scale, we
-often employ approximated training algorithms.  These algorithms build a gradient
-histogram for each node and iterate through the histogram instead of real dataset.  Here
-we introduce the implementations in XGBoost.
+As ``exact`` tree method is slow in performance and not scalable, we often employ
+approximated training algorithms.  These algorithms build a gradient histogram for each
+node and iterate through the histogram instead of real dataset.  Here we introduce the
+implementations in XGBoost below.
 
 1. ``approx`` tree method: An approximation tree method described in `reference paper
    <http://arxiv.org/abs/1603.02754>`_.  It runs sketching before building each tree
@@ -48,18 +48,22 @@ we introduce the implementations in XGBoost.
    this global sketch.  This is the fastest algorithm as it runs sketching only once.  The
    algorithm can be accessed by setting ``tree_method`` to ``hist``.
 
+3. ``gpu_hist`` tree method: The ``gpu_hist`` tree method is a GPU implementation of
+   ``hist``, with additional support for gradient based sampling.  The algorithm can be
+   accessed by setting ``tree_method`` to ``gpu_hist``.
+
 ************
 Implications
 ************
 
-Some objectives like ``reg:squarederror`` have constant hessian.  In this case, the
-``hist`` should be preferred as weighted sketching doesn't make sense with constant
+Some objectives like ``reg:squarederror`` have constant hessian.  In this case, ``hist``
+or ``gpu_hist`` should be preferred as weighted sketching doesn't make sense with constant
 weights.  When using non-constant hessian objectives, sometimes ``approx`` yields better
-accuracy, but with slower computation performance.  Most of the time using ``hist`` with
-higher ``max_bin`` can achieve similar or even superior accuracy while maintaining good
-performance.  However, as xgboost is largely driven by community effort, the actual
-implementations have some differences than pure math description.  Result might be
-slightly different than expectation, which we are currently trying to overcome.
+accuracy, but with slower computation performance.  Most of the time using ``(gpu)_hist``
+with higher ``max_bin`` can achieve similar or even superior accuracy while maintaining
+good performance.  However, as xgboost is largely driven by community effort, the actual
+implementations have some differences than pure math description.  Result might have
+slight differences than expectation, which we are currently trying to overcome.
 
 **************
 Other Updaters
@@ -68,7 +72,7 @@ Other Updaters
 1. ``Prune``: It prunes the existing trees.  ``prune`` is usually used as part of other
    tree methods.  To use pruner independently, one needs to set the process type to update
    by: ``{"process_type": "update", "updater": "prune"}``.  With this set of parameters,
-   during training, XGBoost will prune the existing trees according to 2 parameters
+   during trianing, XGBOost will prune the existing trees according to 2 parameters
    ``min_split_loss (gamma)`` and ``max_depth``.
 
 2. ``Refresh``: Refresh the statistic of built trees on a new training dataset.  Like the
@@ -102,8 +106,8 @@ solely for the interest of documentation.
    histogram creation step and uses sketching values directly during split evaluation.  It
    was never tested and contained some unknown bugs, we decided to remove it and focus our
    resources on more promising algorithms instead.  For accuracy, most of the time
-   ``approx`` and ``hist`` are enough with some parameters tuning, so removing them don't
-   have any real practical impact.
+   ``approx``, ``hist`` and ``gpu_hist`` are enough with some parameters tuning, so
+   removing them don't have any real practical impact.
 
 3. ``grow_local_histmaker`` updater: An approximation tree method described in `reference
    paper <http://arxiv.org/abs/1603.02754>`_.  This updater was rarely used in practice so
@@ -123,23 +127,23 @@ Feature Matrix
 Following table summarizes some differences in supported features between 4 tree methods,
 `T` means supported while `F` means unsupported.
 
-+------------------+-----------+---------------------+------------------------+---------------------+------------------------+
-|                  | Exact     | Approx              | Approx (GPU)           | Hist                | Hist (GPU)             |
-+==================+===========+=====================+========================+=====================+========================+
-| grow_policy      | Depthwise | depthwise/lossguide | depthwise/lossguide    | depthwise/lossguide | depthwise/lossguide    |
-+------------------+-----------+---------------------+------------------------+---------------------+------------------------+
-| max_leaves       | F         | T                   | T                      | T                   | T                      |
-+------------------+-----------+---------------------+------------------------+---------------------+------------------------+
-| sampling method  | uniform   | uniform             | gradient_based/uniform | uniform             | gradient_based/uniform |
-+------------------+-----------+---------------------+------------------------+---------------------+------------------------+
-| categorical data | F         | T                   | T                      | T                   | T                      |
-+------------------+-----------+---------------------+------------------------+---------------------+------------------------+
-| External memory  | F         | T                   | P                      | T                   | P                      |
-+------------------+-----------+---------------------+------------------------+---------------------+------------------------+
-| Distributed      | F         | T                   | T                      | T                   | T                      |
-+------------------+-----------+---------------------+------------------------+---------------------+------------------------+
++------------------+-----------+---------------------+---------------------+------------------------+
+|                  | Exact     | Approx              | Hist                | GPU Hist               |
++==================+===========+=====================+=====================+========================+
+| grow_policy      | Depthwise | depthwise/lossguide | depthwise/lossguide | depthwise/lossguide    |
++------------------+-----------+---------------------+---------------------+------------------------+
+| max_leaves       | F         | T                   | T                   | T                      |
++------------------+-----------+---------------------+---------------------+------------------------+
+| sampling method  | uniform   | uniform             | uniform             | gradient_based/uniform |
++------------------+-----------+---------------------+---------------------+------------------------+
+| categorical data | F         | T                   | T                   | T                      |
++------------------+-----------+---------------------+---------------------+------------------------+
+| External memory  | F         | T                   | T                   | P                      |
++------------------+-----------+---------------------+---------------------+------------------------+
+| Distributed      | F         | T                   | T                   | T                      |
++------------------+-----------+---------------------+---------------------+------------------------+
 
-Features/parameters that are not mentioned here are universally supported for all 3 tree
+Features/parameters that are not mentioned here are universally supported for all 4 tree
 methods (for instance, column sampling and constraints).  The `P` in external memory means
-special handling.  Please note that both categorical data and external memory are
+partially supported.  Please note that both categorical data and external memory are
 experimental.

doc/tutorials/c_api_tutorial.rst

@@ -55,7 +55,7 @@ To ensure that CMake can locate the XGBoost library, supply ``-DCMAKE_PREFIX_PAT
 
 .. code-block:: bash
 
-  # Navigate to the build directory for your application
+  # Nagivate to the build directory for your application
   cd build
   # Activate the Conda environment where we previously installed XGBoost
   conda activate [env_name]
@@ -65,7 +65,7 @@ To ensure that CMake can locate the XGBoost library, supply ``-DCMAKE_PREFIX_PAT
   make
 
 ************************
-Useful Tips To Remember
+Usefull Tips To Remember
 ************************
 
 Below are some useful tips while using C API:
@@ -151,7 +151,7 @@ c. Assertion technique: It works both in C/ C++. If expression evaluates to 0 (f
    Example if we our training data is in ``dense matrix`` format then your prediction dataset should also be a ``dense matrix`` or if training in ``libsvm`` format then dataset for prediction should also be in ``libsvm`` format.
 
 
-4. Always use strings for setting values to the parameters in booster handle object. The parameter value can be of any data type (e.g. int, char, float, double, etc), but they should always be encoded as strings.
+4. Always use strings for setting values to the parameters in booster handle object. The paramter value can be of any data type (e.g. int, char, float, double, etc), but they should always be encoded as strings.
 
 .. code-block:: c
 
@@ -168,7 +168,7 @@ Sample examples along with Code snippet to use C API functions
 .. code-block:: c
 
   DMatrixHandle data; // handle to DMatrix
-  // Load the data from file & store it in data variable of DMatrixHandle datatype
+  // Load the dat from file & store it in data variable of DMatrixHandle datatype
   safe_xgboost(XGDMatrixCreateFromFile("/path/to/file/filename", silent, &data));
 
 
@@ -278,7 +278,7 @@ Sample examples along with Code snippet to use C API functions
     uint64_t const* out_shape;
     /* Dimension of output prediction */
     uint64_t out_dim;
-    /* Pointer to a thread local contiguous array, assigned in prediction function. */
+    /* Pointer to a thread local contigious array, assigned in prediction function. */
     float const* out_result = NULL;
     safe_xgboost(
         XGBoosterPredictFromDMatrix(booster, dmatrix, config, &out_shape, &out_dim, &out_result));

doc/tutorials/categorical.rst

@@ -4,17 +4,16 @@ Categorical Data
 
 .. note::
 
-   As of XGBoost 1.6, the feature is experimental and has limited features. Only the
-   Python package is fully supported.
+   As of XGBoost 1.6, the feature is experimental and has limited features
 
-Starting from version 1.5, the XGBoost Python package has experimental support for
-categorical data available for public testing. For numerical data, the split condition is
-defined as :math:`value < threshold`, while for categorical data the split is defined
-depending on whether partitioning or onehot encoding is used. For partition-based splits,
-the splits are specified as :math:`value \in categories`, where ``categories`` is the set
-of categories in one feature.  If onehot encoding is used instead, then the split is
-defined as :math:`value == category`. More advanced categorical split strategy is planned
-for future releases and this tutorial details how to inform XGBoost about the data type.
+Starting from version 1.5, XGBoost has experimental support for categorical data available
+for public testing. For numerical data, the split condition is defined as :math:`value <
+threshold`, while for categorical data the split is defined depending on whether
+partitioning or onehot encoding is used. For partition-based splits, the splits are
+specified as :math:`value \in categories`, where ``categories`` is the set of categories
+in one feature.  If onehot encoding is used instead, then the split is defined as
+:math:`value == category`. More advanced categorical split strategy is planned for future
+releases and this tutorial details how to inform XGBoost about the data type.
 
 ************************************
 Training with scikit-learn Interface
@@ -36,8 +35,8 @@ parameter ``enable_categorical``:
 
 .. code:: python
 
-  # Supported tree methods are `approx` and `hist`.
-  clf = xgb.XGBClassifier(tree_method="hist", enable_categorical=True, device="cuda")
+  # Supported tree methods are `gpu_hist`, `approx`, and `hist`.
+  clf = xgb.XGBClassifier(tree_method="gpu_hist", enable_categorical=True)
   # X is the dataframe we created in previous snippet
   clf.fit(X, y)
   # Must use JSON/UBJSON for serialization, otherwise the information is lost.

doc/tutorials/custom_metric_obj.rst

@@ -38,7 +38,7 @@ Although XGBoost has native support for said functions, using it for demonstrati
 provides us the opportunity of comparing the result from our own implementation and the
 one from XGBoost internal for learning purposes.  After finishing this tutorial, we should
 be able to provide our own functions for rapid experiments.  And at the end, we will
-provide some notes on non-identity link function along with examples of using custom metric
+provide some notes on non-identy link function along with examples of using custom metric
 and objective with the `scikit-learn` interface.
 
 If we compute the gradient of said objective function:
@@ -165,7 +165,7 @@ Reverse Link Function
 When using builtin objective, the raw prediction is transformed according to the objective
 function.  When a custom objective is provided XGBoost doesn't know its link function so the
 user is responsible for making the transformation for both objective and custom evaluation
-metric.  For objective with identity link like ``squared error`` this is trivial, but for
+metric.  For objective with identiy link like ``squared error`` this is trivial, but for
 other link functions like log link or inverse link the difference is significant.
 
 For the Python package, the behaviour of prediction can be controlled by the
@@ -173,7 +173,7 @@ For the Python package, the behaviour of prediction can be controlled by the
 parameter without a custom objective, the metric function will receive transformed
 prediction since the objective is defined by XGBoost. However, when the custom objective is
 also provided along with that metric, then both the objective and custom metric will
-receive raw prediction.  The following example provides a comparison between two different
+recieve raw prediction.  The following example provides a comparison between two different
 behavior with a multi-class classification model. Firstly we define 2 different Python
 metric functions implementing the same underlying metric for comparison,
 `merror_with_transform` is used when custom objective is also used, otherwise the simpler

doc/tutorials/dask.rst

@@ -56,6 +56,7 @@ on a dask cluster:
         dtrain = xgb.dask.DaskDMatrix(client, X, y)
         # or
         # dtrain = xgb.dask.DaskQuantileDMatrix(client, X, y)
+        # `DaskQuantileDMatrix` is available for the `hist` and `gpu_hist` tree method.
 
         output = xgb.dask.train(
             client,
@@ -148,7 +149,7 @@ Also for inplace prediction:
 .. code-block:: python
 
   # where X is a dask DataFrame or dask Array backed by cupy or cuDF.
-  booster.set_param({"device": "cuda"})
+  booster.set_param({"gpu_id": "0"})
   prediction = xgb.dask.inplace_predict(client, booster, X)
 
 When input is ``da.Array`` object, output is always ``da.Array``.  However, if the input
@@ -224,12 +225,6 @@ collection.
                 main(client)
 
 
-****************
-GPU acceleration
-****************
-
-For most of the use cases with GPUs, the `Dask-CUDA <https://docs.rapids.ai/api/dask-cuda/stable/quickstart.html>`__ project should be used to create the cluster, which automatically configures the correct device ordinal for worker processes. As a result, users should NOT specify the ordinal (good: ``device=cuda``, bad: ``device=cuda:1``). See :ref:`sphx_glr_python_dask-examples_gpu_training.py` and :ref:`sphx_glr_python_dask-examples_sklearn_gpu_training.py` for worked examples.
-
 ***************************
 Working with other clusters
 ***************************
@@ -256,7 +251,7 @@ In the example below, a ``KubeCluster`` is used for `deploying Dask on Kubernete
       m = 1000
       n = 10
       kWorkers = 2                # assuming you have 2 GPU nodes on that cluster.
-      # You need to work out the worker-spec yourself.  See document in dask_kubernetes for
+      # You need to work out the worker-spec youself.  See document in dask_kubernetes for
       # its usage.  Here we just want to show that XGBoost works on various clusters.
       cluster = KubeCluster.from_yaml('worker-spec.yaml', deploy_mode='remote')
       cluster.scale(kWorkers)     # scale to use all GPUs
@@ -267,7 +262,7 @@ In the example below, a ``KubeCluster`` is used for `deploying Dask on Kubernete
 
           regressor = xgb.dask.DaskXGBRegressor(n_estimators=10, missing=0.0)
           regressor.client = client
-          regressor.set_params(tree_method='hist', device="cuda")
+          regressor.set_params(tree_method='gpu_hist')
           regressor.fit(X, y, eval_set=[(X, y)])
 
 
@@ -648,7 +643,7 @@ environment than training the model using a single node due to aforementioned cr
 Memory Usage
 ************
 
-Here are some practices on reducing memory usage with dask and xgboost.
+Here are some pratices on reducing memory usage with dask and xgboost.
 
 - In a distributed work flow, data is best loaded by dask collections directly instead of
   loaded by client process.  When loading with client process is unavoidable, use

doc/tutorials/external_memory.rst

@@ -7,7 +7,7 @@ dataset needs to be loaded into memory. This can be costly and sometimes
 infeasible. Staring from 1.5, users can define a custom iterator to load data in chunks
 for running XGBoost algorithms. External memory can be used for both training and
 prediction, but training is the primary use case and it will be our focus in this
-tutorial. For prediction and evaluation, users can iterate through the data themselves
+tutorial. For prediction and evaluation, users can iterate through the data themseleves
 while training requires the full dataset to be loaded into the memory.
 
 During training, there are two different modes for external memory support available in
@@ -81,7 +81,7 @@ constructor.
   it = Iterator(["file_0.svm", "file_1.svm", "file_2.svm"])
   Xy = xgboost.DMatrix(it)
 
-  # The ``approx`` also work, but with low performance. GPU implementation is different from CPU.
+  # Other tree methods including ``hist`` and ``gpu_hist`` also work, but has some caveats
   # as noted in following sections.
   booster = xgboost.train({"tree_method": "hist"}, Xy)
 
@@ -118,15 +118,15 @@ to reduce the overhead of file reading.
 GPU Version (GPU Hist tree method)
 **********************************
 
-External memory is supported by GPU algorithms (i.e. when ``device`` is set to
-``cuda``). However, the algorithm used for GPU is different from the one used for
+External memory is supported by GPU algorithms (i.e. when ``tree_method`` is set to
+``gpu_hist``). However, the algorithm used for GPU is different from the one used for
 CPU. When training on a CPU, the tree method iterates through all batches from external
 memory for each step of the tree construction algorithm. On the other hand, the GPU
 algorithm uses a hybrid approach. It iterates through the data during the beginning of
-each iteration and concatenates all batches into one in GPU memory for performance
-reasons. To reduce overall memory usage, users can utilize subsampling. The GPU hist tree
-method supports `gradient-based sampling`, enabling users to set a low sampling rate
-without compromising accuracy.
+each iteration and concatenates all batches into one in GPU memory. To reduce overall
+memory usage, users can utilize subsampling. The GPU hist tree method supports
+`gradient-based sampling`, enabling users to set a low sampling rate without compromising
+accuracy.
 
 .. code-block:: python
 
@@ -142,7 +142,7 @@ see `this paper <https://arxiv.org/abs/2005.09148>`_.
 .. warning::
 
    When GPU is running out of memory during iteration on external memory, user might
-   receive a segfault instead of an OOM exception.
+   recieve a segfault instead of an OOM exception.
 
 .. _ext_remarks:
 
@@ -150,7 +150,7 @@ see `this paper <https://arxiv.org/abs/2005.09148>`_.
 Remarks
 *******
 
-When using external memory with XGBoost, data is divided into smaller chunks so that only
+When using external memory with XBGoost, data is divided into smaller chunks so that only
 a fraction of it needs to be stored in memory at any given time. It's important to note
 that this method only applies to the predictor data (``X``), while other data, like labels
 and internal runtime structures are concatenated. This means that memory reduction is most
@@ -211,7 +211,7 @@ construction of `QuantileDmatrix` with data chunks. On the other hand, if it's p
 doesn't fetch data during training. On the other hand, the external memory `DMatrix`
 fetches data batches from external memory on-demand.  Use the `QuantileDMatrix` (with
 iterator if necessary) when you can fit most of your data in memory. The training would be
-an order of magnitude faster than using external memory.
+an order of magnitute faster than using external memory.
 
 ****************
 Text File Inputs

doc/tutorials/feature_interaction_constraint.rst

@@ -233,7 +233,7 @@ This has lead to some interesting implications of feature interaction constraint
 ``[[0, 1], [0, 1, 2], [1, 2]]`` as another example.  Assuming we have only 3 available
 features in our training datasets for presentation purpose, careful readers might have
 found out that the above constraint is the same as simply ``[[0, 1, 2]]``.  Since no matter which
-feature is chosen for split in the root node, all its descendants are allowed to include every
+feature is chosen for split in the root node, all its descendants are allowd to include every
 feature as legitimate split candidates without violating interaction constraints.
 
 For one last example, we use ``[[0, 1], [1, 3, 4]]`` and choose feature ``0`` as split for

doc/tutorials/learning_to_rank.rst

@@ -11,12 +11,12 @@ Learning to Rank
 ********
 Overview
 ********
-Often in the context of information retrieval, learning-to-rank aims to train a model that arranges a set of query results into an ordered list `[1] <#references>`__. For supervised learning-to-rank, the predictors are sample documents encoded as feature matrix, and the labels are relevance degree for each sample. Relevance degree can be multi-level (graded) or binary (relevant or not). The training samples are often grouped by their query index with each query group containing multiple query results.
+Often in the context of information retrieval, learning-to-rank aims to train a model that arranges a set of query results into an ordered list `[1] <#references>`__. For surprivised learning-to-rank, the predictors are sample documents encoded as feature matrix, and the labels are relevance degree for each sample. Relevance degree can be multi-level (graded) or binary (relevant or not). The training samples are often grouped by their query index with each query group containing multiple query results.
 
 XGBoost implements learning to rank through a set of objective functions and performance metrics. The default objective is ``rank:ndcg`` based on the ``LambdaMART`` `[2] <#references>`__ algorithm, which in turn is an adaptation of the ``LambdaRank`` `[3] <#references>`__ framework to gradient boosting trees. For a history and a summary of the algorithm, see `[5] <#references>`__. The implementation in XGBoost features deterministic GPU computation, distributed training, position debiasing and two different pair construction strategies.
 
 ************************************
-Training with the Pairwise Objective
+Training with the Pariwise Objective
 ************************************
 ``LambdaMART`` is a pairwise ranking model, meaning that it compares the relevance degree for every pair of samples in a query group and calculate a proxy gradient for each pair. The default objective ``rank:ndcg`` is using the surrogate gradient derived from the ``ndcg`` metric. To train a XGBoost model, we need an additional sorted array called ``qid`` for specifying the query group of input samples. An example input would look like this:
 
@@ -59,7 +59,7 @@ Notice that the samples are sorted based on their query index in a non-decreasin
   X = X[sorted_idx, :]
   y = y[sorted_idx]
 
-The simplest way to train a ranking model is by using the scikit-learn estimator interface. Continuing the previous snippet, we can train a simple ranking model without tuning:
+The simpliest way to train a ranking model is by using the scikit-learn estimator interface. Continuing the previous snippet, we can train a simple ranking model without tuning:
 
 .. code-block:: python
 
@@ -70,7 +70,7 @@ Please note that, as of writing, there's no learning-to-rank interface in scikit
 
 .. code-block:: python
 
-  df = pd.DataFrame(X, columns=[str(i) for i in range(X.shape[1])])
+  df = pd.DataFrame(X, columns=[str(i) for i in range(X.shape[1]))
   df["qid"] = qid
   ranker.fit(df, y)  # No need to pass qid as a separate argument