James Lamb

Thanks for using LightGBM. Is it absolutely necessary to "refit" (modify the values of the leaf nodes without changing the total number of trees)? Or would it bee acceptable to...

Also...I see that you double-posted this here and on Stack Overflow ([link](https://stackoverflow.com/questions/78536594/how-to-refit-a-lightgbm-classifier)). Please do not do that. Maintainers here also monitor the `[lightgbm]` tag on Stack Overflow. I could have...

> *It would be best if we can use the same exact "refit", if not I can use the update function?* What is preventing you from using `Booster.refit()`? You showed...

There will be at least one thing I know needs to change... `np.array(..., copy=False)` calls being changed to `np.asarray(...)`. Reference: https://github.com/dmlc/treelite/pull/562/files#r1603610473

@andrey-khropov just noting for your planning purposes... the target release date for `numpy` 2.x is June 16th: https://github.com/numpy/numpy/issues/24300#issuecomment-2125643448

Adding some links. I think that instead of doing this for projects in `rapids_cpm_spdlog()`, we can soon just remove that manual exporting from projects' `get_spdlog.cmake`. Assuming https://github.com/rapidsai/build-planning/issues/56 is completed (see...

I think this would could be closed if the following are merged: * [x] https://github.com/rapidsai/rapids-cmake/pull/689 * [x] https://github.com/rapidsai/rmm/pull/1678 * [x] https://github.com/rapidsai/cudf/pull/16806

I think this can be closed! The now-extraneous `rapids_export()` calls were removed in the PRs linked in https://github.com/rapidsai/rapids-cmake/issues/387#issuecomment-2361281304. There are not any remaining across RAPIDS: https://github.com/search?q=org%3Arapidsai+%22NAMESPACE+spdlog%3A%3A%22+AND+NOT+is%3Aarchived&type=code

Thanks for using LightGBM. The `tree_learner` setting only affects *training*, not *prediction*. You can pass `num_threads` through parameters for prediction. That tells LightGBM to parallelize prediction **over rows in the...

> *I found that no matter whether you choose C_API_DTYPE_FLOAT32 or C_API_DTYPE_FLOAT64, the internal processing is based on double* Can you share some links or other evidence that makes you...