Global Parameters

[jrdnmdhl]

As currently implemented, parameters are evaluated separately by comparator. This presents a problem for #293. At best, this means such computations will take multiple times longer. At worst, it means each comparator will get different results for the same model (if the estimation is non-deterministic).

Perhaps we need to separate global and comparator-specific parameters?

[MattWiener]

I think we already have the tools to do this. tabular_input.R uses one method, which is to load things into and pass around an environment. That's what's being done for create_df_from_tabular (currently in my version line 111 - 117) and sourcing in functions (lines 119-134). Objects and functions get incorporated into an environment that is then passed to create_parameters_from_tabular and incorporated into the environment used for all evaluations (including parameters), so you can just refer to those objects when you want them. The data frames used as the first argument to look_up, for example, are loaded this way.

look_up is deterministic, of course, so there would need to be something extra for stochastic computations. For bootstrapping, for example, you could load in the base data set as a global parameter, and then define a function that takes in the base set and a seed. Setting the seed would allow the same set to be selected for each strategy. In fact, maybe we would want a general wrapper function that could be applied to other functions that would take in a seed and other arguments, set the seed, and pass the rest of the arguments through to the "base" function. Something like (untested):

function(seed, fn, ...){
  set_seed(seed)
  do.call(fn, list(...))
}

That's just one idea. There may be better ways to use it, but the environment that's already being passed around seems like it is part of the solution.

[jrdnmdhl]

The idea here is to come up with a solution that also works for #293, which is intended to replace some of the mechanics that you are describing by allowing anything to be a parameter. I think your points can be read as a challenge to whether #293 is actually necessary.

I think it makes sense to come at the problem from both angles:

• Try to make the existing workarounds sufficiently good that we don't need arbitrary objects in parameters
• Try to develop a seamless solution to arbitrary objects in parameters, including how to handle parameters that are global