When using generateGridDesign with a "numeric" parameter that has integer typed lower and upper bounds, and with a resolution that leads to integer valued grid points, the resulting df column is of type integer instead of numeric:
> dfRowToList(design, ps, 1)
Error in dfRowsToList(df = df, par.set = par.set, enforce.col.types = enforce.col.types, :
REAL() can only be applied to a 'numeric', not a 'integer'
Which ultimately leads to mlr-org/mlr#2493: doing grid search with integer parameter bounds and a fitting grid resolution fails.
One could say that the user should not give integer typed bounds to makeNumericParam, but R makes otherwise basically no distinction between the integer and floating point type, so ParamHelpers should not unexpectedly fail here.
Either generateGridDesign should make sure a numeric parameter's column is not integer typed, or dfRow[s]ToList should be able to handle integer columns for numeric parameters. (Probably both.)
When using
generateGridDesign
with a "numeric" parameter that has integer typed lower and upper bounds, and with a resolution that leads to integer valued grid points, the resulting df column is of type integer instead of numeric:This confuses
dfRow[s]ToList
:Which ultimately leads to mlr-org/mlr#2493: doing grid search with integer parameter bounds and a fitting grid resolution fails. One could say that the user should not give integer typed bounds to
makeNumericParam
, but R makes otherwise basically no distinction between the integer and floating point type, so ParamHelpers should not unexpectedly fail here. EithergenerateGridDesign
should make sure a numeric parameter's column is not integer typed, ordfRow[s]ToList
should be able to handle integer columns for numeric parameters. (Probably both.)