You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some of the default values in parameter sets can currently not be expressed because they contain expressions. E.g. a parameter seed might be an integer() but the default is sample.int(100). It is currently not possible to specify the default.
Currently people address this differently when implementing learners. A common solution to the above problem is then to say that the parameter has no default, which is not correct. We came to the agreement that we want to specify this using something like a Cmplx_Default token that is also visible in the rd_info output that is shown e.g. in the learner's help page. This then communicates to the user that one has to look in the help page of the upstream function to learn about the parameter's default behaviour.
The text was updated successfully, but these errors were encountered:
The information encoded here would be redundand, since the absence of a "required" tag already indicates that some kind of default behaviour happens. The difference between "no default (user has to enter something himfself)" and "no default that we want to specify here" is made by having the NO_DEF token with the "repuired" tag present or absent, respectively. If we want to have different tokens for these cases, we could consider dropping the "required" tag.
Ah sorry, I might have misremembered some details.
So we decided to only change the rd_info.ParamSet function to print this more explicitly? (should have written this down immediately)
Some of the default values in parameter sets can currently not be expressed because they contain expressions. E.g. a parameter
seed
might be aninteger()
but the default issample.int(100)
. It is currently not possible to specify the default.Currently people address this differently when implementing learners. A common solution to the above problem is then to say that the parameter has no default, which is not correct. We came to the agreement that we want to specify this using something like a
Cmplx_Default
token that is also visible in therd_info
output that is shown e.g. in the learner's help page. This then communicates to the user that one has to look in the help page of the upstream function to learn about the parameter's default behaviour.The text was updated successfully, but these errors were encountered: