parameter organisation

[mhinsch]

Sadly we won't be able to maintain the 1:1 correspondence between parameter types and simulation functions/modules. marriage! for example uses mostly idiosyncratic parameters, but, unfortunately, also minPregnancyAge, ageOfAdulthood and numClasses, all of which are used in other parts of the model as well (work, birth and unspecified).

I find it annoying to have a unique combination of different parameter objects for each simulation function (although I admit that it at least makes dependencies explicit), but it's equally annoying to have to go through a hierarchy of parameter objects in client code (e.g. pars.work.ageOfAdulthood, which at the same time implies of course that even in marriage! marriage parameters have to be accessed explicitly, e.g. pars.marriage.basicMaleMarriageProb).

For now I'll just hand over several parameter objects to marriage!, but it would be nice if we could find a better solution. Following two sketches of possible solutions that I haven't made my mind up about yet.

• Duplicate parameters across modules. E.g. MarriagePars has minPregnancyAge as well. In some cases this even makes sense (e.g. for minPregnancyAge and ageOfAdulthood, but not for numClasses). My feeling is that this would be more annoying than helpful. It might work if we find a way to mark the duplication as such somehow (which would also imply that values get synchronised somehow).
• Fuse parameter objects ad hoc. Using generated functions it would for example be possible to create a named tuple from any number of struct objects.

Edit: I should mention that this would provide a solution, but that's more 2.0 stuff, I think.

[AtiyahElsheikh]

I don't like the first solution either. The second solution seems to be more reasonable.

Still I can imagine combining both worlds, i.e. keeping the 1:1 association, i.e. every parameter belongs to only one group, but to make it clear through the API that different groups of parameters are being employed:

doMarraige(*,marPars,birthPars,...)

this seems to work with the second proposed solution:

doMarraige(*,marPars,birthPars,...) = doMarraige(*,fuse(marPars,birthPars,..),...)

[mhinsch]

I don't like the first solution either. The second solution seems to be more reasonable.

Still I can imagine combining both worlds, i.e. keeping the 1:1 association, i.e. every parameter belongs to only one group, but to make it clear through the API that different groups of parameters are being employed:

doMarraige(*,marPars,birthPars,...)

this seems to work with the second proposed solution:

doMarraige(*,marPars,birthPars,...) = doMarraige(*,fuse(marPars,birthPars,..),...)

I think the main tension lies between a) wanting to make clear which function uses which parameters and b) not wanting to have to care about the specifics of parameter organisation within a function. From the point of view of for example someone implementing marriage! I don't want to know where the parameter minPregnancyAge is coming from, it's a parameter of marriage! and that's it.

[mhinsch]

We have a so so solution, so closing for now.