Is this normal for models to run this long or could they be stuck?
May I take a look at your setup?
Sure. What do you need?
I want to look at the RF settings.
1 Like
You're using "criterion": "absolute_error".
The issues with absolute_error on a z-scored (trimmed, clipped) target:
-
It's structurally slow, and no preprocessing fixes that. Mean Absolute Error split-finding requires median tracking per candidate split instead of the running-sum arithmetic that squared error uses. That makes it 10–100x slower per fit and the cost is identical whether the target is raw returns or a tame, capped z-score. Trimming and clipping change the values, not the algorithm.
-
Its benefit has already been consumed upstream. MAE's only advantage is robustness to extreme target values. A tree trained with
absolute_errorpredicts leaf medians, and medians don't respond to outlier magnitude, whereas a tree trained withsquared_errorpredicts leaf means, which do. But z-scoring plus trimming plus a 3.5σ cap removes or bounds those tails before the model ever sees them. On a target confined to roughly [−3.5, +3.5], node means and node medians are nearly identical, soabsolute_errorandsquared_errorchoose nearly the same splits and produce nearly the same predictions. -
The result is paying twice for one benefit. Target normalization and the MAE criterion are two solutions to the same problem; heavy-tailed targets. Stacking them means you've spent information (trimmed observations, clipped magnitudes) and compute (the expensive criterion) to buy robustness once.
-
The cost compounds through everything downstream. Every extra fit — cross-validation folds, hyperparameter searches — multiplies the per-fit penalty.
Why squared_error is the better choice here:
It runs at full speed on exactly the same preprocessed target, produces statistically indistinguishable results. The robustness job belongs to the normalization pipeline, which is already doing it; the criterion's job is just to find splits fast.
When your target is z-scored, trimmed, and outlier-capped, absolute_error adds hours of runtime and nothing else. Use squared_error and let the normalization handle robustness.
The above is based on Claude.ai's analysis, but Gemini thought it was brilliant.
I ran a small test comparing the Random Forest criterion using the default squared_error versus absoulte_error. The test used the S&P 500 universe with 10 years of data, Core: Quality's 12 features, and Z-score normalization with default trim/cap. The base algorithm was "random forest I".
The difference in run time was dramatic. With the default squared_error criterion, the model completed in about 3 seconds. With absoulte_error, the same model took just under 36 minutes to finish.
I think absolute_error was the default setting.
I canceled the remaining. How can I change the remaining to squared_error without scrapping all the work $$$ already done?
Thanks
Tony
Thanks
The P123 RF defaults are all criterion: squared error.
I think you're going to have to restart with updated RF settings. The good news is they should run much faster.
Yes, you're absolutely 
right. The RF grid has both absolute_error and squared_error variants.
1 Like
Should I discontinue using the grid in the future or edit the params to remove absolute_error?
Thanks
Tony
There are two RF grid variants; absolute_error and squared_error.
Pick which you want to use.
Before spending more time on the grid search implementation, I'd suggest making a simple benchmark that runs the same training twice. Once with squared_error and once with absolute_error.
1 Like
If you're still open to benchmarking, also experiment with reducing max_depth.