fastml

Breaking changes

• **time_varying_cox has been withdrawn.** It required start-stop interval input, which the evaluation path does not accept, so the model could be fitted but never scored. It no longer appears in availableMethods("survival"), and a request for it by name now stops with an error naming the reason and pointing to cox_ph and stratified_cox. Advertising a learner that cannot produce a result is worse than not offering it. Code that named it previously received a fitted model with no metrics.
• **Requesting resampling or tuning for xgboost_aft is now an error rather than a warning.** parsnip exposes no censored regression mode for xgboost, so the family cannot be fitted through a workflow. Previously the request warned and then fitted natively with resampling silently disabled, which returned a fastml object carrying no fold-level results for a user who had explicitly asked for them. The request is now refused. This is the same contract every other natively fitted survival family already followed.
• **Values in tune_params are now candidate values, not the endpoints of a range.** A vector of length two was previously read as an interval and interpolated across grid_levels, while a vector of length three or more was read as an explicit set. Nothing but the length distinguished them, so a single call could contain mixture = c(0, 0.5, 1) meaning three values and min_n = c(20, 50) meaning an interval, which is not what the code appears to say. Every value supplied through tune_params is now searched as written, whatever the number of values, and the parameter's range is widened where a requested value falls outside a package default. The package's own default ranges are unchanged and are still interpolated, so results obtained without a tune_params argument are unaffected.
• **bootstrap_ci now defaults to FALSE.** The interval it produces resamples the held-out predictions of a single fitted model, so it describes uncertainty from the evaluation sample conditional on that fit and excludes training, tuning and model-selection variability. Read as ordinary uncertainty about model performance, which is how a reader of a .lower/.upper column will read it, it overstates precision. Computing it also dominated run time, accounting for about 85% of the elapsed time of a Cox fit to the rotterdam data, which falls from roughly 19 seconds to roughly 2.9 seconds with it disabled, and summary() did not display the result unless show_ci = TRUE was passed, so the cost was paid on every fit for output that was not shown. Set bootstrap_ci = TRUE to restore the previous behaviour. With it off, .lower and .upper are NA and .n_boot is zero, so nothing in the performance table reads as an interval that was not computed. When intervals are displayed, summary() now prints the estimand above the table so the qualification travels with the numbers.
• **Regression results now report rsq_trad alongside rsq.** yardstick::rsq() is squared Pearson correlation and is invariant to location and scale, so it cannot see a prediction that is biased or mis-dispersed. rsq_trad() is one minus the residual sum of squares over the total sum of squares, which is the quantity most readers assume when they see an R-squared in a results table. The two agree when predictions are unbiased and correctly scaled and diverge when they are not, so the gap between them is a calibration diagnostic. Code that reads the regression metrics table by column position will need updating.

New features

• **The tuning grid that was actually searched is recorded and printed.** The fitted object gains a tuning_grid component listing, per algorithm and engine, each tuned parameter, the values that were searched on the parameter's natural scale, and whether the parameter came from the user or from the package defaults. summary() prints it under the new type = "grid", which is included in the default type = "all". Reporting only the selected configuration cannot reveal a grid that differs from the one requested, because a selected value looks identical whether the user named it or the package interpolated it, which is how the scale defect below survived. ?fastml documents the scale and the range semantics of tune_params explicitly rather than leaving them to be inferred.
• **stratified_cox strata are now named through a strata_cols argument.** Strata were previously identified by a naming convention, any column whose name began with strata. A convention that determines model structure but appears nowhere in the function signature is not discoverable, and a user who named a column stratum_site got an unstratified fit with no indication. fastml(..., strata_cols = "site") is now the documented interface; the strata prefix is still recognised, so existing code is unaffected. Naming a column that is not present in the data is an error, and requesting stratified_cox with no strata at all is an error rather than a silent skip.

Bug fixes

• **Tuning values supplied through tune_params are no longer reinterpreted as logarithms.** dials stores quantitative parameters on their transformed scale, which for penalty, learn_rate, loss_reduction, cost, cost_complexity and rbf_sigma is base-10 logarithmic. User-supplied values were passed to dials::range_set() on the natural scale without being mapped, so learn_rate = c(0.05, 0.1) was fitted as 10^0.05 = 1.122 to 10^0.1 = 1.259, and penalty = c(0.01, 0.1) as 1.023 to 1.259. Nothing in the output reported the substitution. For boosting the consequence is severe, since a learning rate above one overshoots at every step: on an NHANES blood-pressure regression the fitted LightGBM predictions had 1.43 times the standard deviation of the outcome and spanned 36 to 294 mmHg, giving an RMSE of 23.1 against 17.3 for predicting the mean. The reported rsq of 0.19 did not reveal this, because yardstick::rsq() is squared Pearson correlation and is invariant to location and scale; the traditional R-squared was -0.79. Values supplied by the user are now mapped through the parameter's own transform, and a value outside a transformed parameter's domain is refused with an error naming the parameter. Values are now mapped through the parameter's own transform before they reach dials, and a negative value for a positive-domain parameter is refused with an error naming the parameter. A requested zero, which is meaningful for loss_reduction but has no logarithm, maps to the parameter's lower bound and the resulting value is visible in the recorded grid. The same route is taken by the fixed defaults from get_default_params(), which are also written on the natural scale and were also being exponentiated. A user who supplied any tune_params for LightGBM without naming learn_rate was given a learning rate of 10^0.1 = 1.2589 in place of the intended default of 0.1. Only the default *tuning ranges* from get_default_tune_params() are written on the scale dials stores, and those are left alone, so results obtained without a tune_params argument are unaffected. Regression tests are in tests/testthat/test-tuning-grid-scale.R.