Move non-optional "controls" to doHB

[jeffkeller87]

The controls argument to doHB should only contain controls and settings for which there is a reasonable default value. Currently, there are two "controls" that must be passed via the controls argument to doHB with no default value (gVarNamesNormal and gVarNamesFixed). These should be made arguments of doHB so that they are easier for users to find and specify.

[chasec]

I get the point above, though I do think there's value in keeping all of
the parameters that need to be passed into the model in one place. This
allows you recall everything that is a parameter to the model in one place.
For both of the parameters above, could we assume something like "fixed_1,
fixed_2, fixed_n" and "vary_1, vary_2, vary_n" or something equivalent?

On Tue, Mar 15, 2016 at 10:25 PM, Jeff Keller notifications@github.com
wrote:

The controls argument to doHB should only contain controls and settings
for which there is a reasonable default value. Currently, there are two
"controls" that must be passed via the controls argument to doHB with no
default value (gVarNamesNormal and gVarNamesFixed). These should be made
arguments of doHB so that they are easier for users to find and specify.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#75

[jeffkeller87]

The trouble is that we use these arguments to determine each "n".

[chasec]

Right, I actually knew that. I do think we could consider forcing those
arguments to be passed via the controls argument as opposed to directly
within the doHB function. For some reason, it seems "cleaner" to me. In
reality - if a user doesn't specify the names of the parameters they are
estimating, they are probably in line for a gentle reminder / warning
regardless.

I guess the equivalent of this from CBCHB is how they define each column
based off the data file you pass in and then assign "level 1" etc for
unnamed levels...we don't really have that option available to us, do we?

On Tue, Mar 15, 2016 at 10:35 PM, Jeff Keller notifications@github.com
wrote:

The trouble is that we use these arguments to determine each "n".

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#75 (comment)

[jeffkeller87]

Not without constraining the format of inputs, which is something we've decided we won't be doing.

Users do currently get a warning if these two arguments are not supplied. I'm approaching this from a usability POV, where more commonly used arguments are more "visible". The doHB help file probably illustrates my concern best. You need to scroll through about half of the help file (which is quite long) before you come across the descriptions for these two non-optional arguments.

In optim, the first two arguments are the function and parameter names/starting values, as these are the most frequently adjusted arguments. The control list is one of the last and contains all of the smaller "tweaker" arguments that have reasonable default values. To me, this is cleaner, but it's not a high priority, certainly not for the poster version, so agreeing to disagree is fine.