I’ll give an example. The task that I personally work with are biological models, where you have gaussian process for a regulator molecule and measurements for some target molecules. Now there are multiple ways the derivative of target molecule concentration could depend on the regulator including for example:
target' = k1 * (1 / exp(-w * regulator - b)) - k2*target and
target' = w * regulator - target except for
target, all the inputs are Stan parameters to be determined. Those two “link functions” differ in both number of parameters and priors required for the shared parameter
w. But there is a lot of code around this including numerical integration, the GP stuff etc. that is exactly the same, so I would like to have a compile-time parameter to choose between those two types of models.
Currently the alternatives are
a) put everything in functions (possibly with lots of parameters) and have two different main model files that only call those functions and differ in which “link” they use. Since I cannot pass functions as parameters, this would still result in a lot of duplicated code.
b) include parameters for both links in the model and pass the desired link type as int data variable, then
if on this data variable in the
transformed parameters blocks, the parameters for the unused links still exist in the model, but are not involved in any statements. The parameters still consume memory though.
My intention is to have a code that basically folows b), but makes it explicit that at runtime the
if conditions are always evaluated the same and gets rid of the unnecessary variables. Alternatively I can imagine that you are allowed to use some kind of
if in the
parameters block if the condition is based only on data, but that seems hacky and I am not sure it would be easy to implement.
Also you can easily imagine that Stan caches the compiled model separately for for different compile-time parameter values, so recompilation would not be that frequent. This would probably require all compile-time parameters to be declared and have a type, but I believe strong typing is a good idea anyway.
True if we changed the way current
#include syntax works, but I think Krzysztof agrees with me that having backwards compatibility on this is easy (e.g. introduce new syntax and make