- increased granularity of options for types of autoML applied in the autoMLer specifications - such as to distinguish between classification options for boolean, ordinal, and onehot encoded labels - even though for random forest they all use the same models - this was partly motivated by a vague impression that autosklearn treats two class and multiclass classification differently
4.95
- the last rollout included an update to the accuracy metric used for regression in feature importance - after running some more tests came to conclusion that was in error - so this update reverts to default regression accuracy metric of mean_squared_log_error - move fast and fix things as is our motto - sorry to be a flake
4.94
- found and fixed bug in printouts for model training functions rolled out in 4.94 - incorporated modular aspects of model inference to feature importance shuffle permutation support function - so feature importance now has potential to support alternate autoML architectures like ML infill - revised the default feature importance regression accuracy metric from mean_squared_log_error to mean_squared_error - (I think is more generalizable since allows negative values)
4.93
- rewrite of a few support functions associated with ML infill - improving code and comment clarity - and for purposes of enabling better modularity - such as to facilitate plug and play of additional architecture / ensemble options - also replaced a parameter key in ML_cmnd for clarity - replaced {'MLinfill_type':'default'} with {'autoML_type':'randomforest'} - where MLinfill_type as previously used was only a placeholder - so this update won't impact backward compatibility - more to come
4.92
- extended transformation function parameter support for adjinfill to include base categoric options - including bnry, bnr2, text, onht, ordl, ord3, 1010 - similar to updates from 4.88 and 4.89 - don't worry, I have a plan
4.91
- found an opportunity to eliminate some redundancy in data stored in postprocess_dict - associated with the normalization_dict entries - this redundancy was a relic of some earlier methods for accessing entries in postmunge - which have since been replaced with a more straightforward approach - this update has potential to materially reduce the memory footprint of postprocess_dict in some cases - also found a few support functions that had a parameter not used by functions - associated with the labelsencoding_dict report - so removed that entry as a parameter to those functions - in interest of reducing complexity