Prediction approach

[nutterb]

The node_attr object needs a new column for predict_fn. when a node model is set, if a valid predict method is available, the predict.object_type could be given as a default.

The user can define his or her own prediction function. We will need a set_node_predict_fn. This is how we can define deterministic nodes without a model.

Return the object in a list. First element is data for non-dynamic nodes.

Additional elements at each time point of the dynamic nodes(?).

Provide a tidy method to bring all the elements together into a two dimensional tidy data frame.

[jarrod-dalton]

I think this accurately reflects our conversation. Although, my inclination is to require user-defined functions for each node in the network by default, with specialized utility functions/wrappers (model_to_node methods) that create these node functions based on provided model objects.

My interpretation of what you wrote is then that a) the user specifies the network structure, including maxt and other parameters; b) the predict_fn slot is by default empty for all nodes, and therefore the user needs to fill these functions somehow. The syntax might be something like:

set_node(net, myGLMObject) #runs modelToNode.glm method or something like that set_node(net, myFunction) #runs a custom function defined by the user

In each of those two situations, there needs to be a fixed naming convention for the inputs to either the predict.glm() method or the user-defined myFunction(). It could be something like

g <- dbn(map[t] | age*sex*map[1:3])  #shorthand for map[t-1]*map[t-2]*map[t-3]? just a thought...

predictMAP <- function(age, sex, map.lag1, map.lag2, map.lag3){
  #all inputted parameters need to be vectors of the same length
  # we may consider the feasibility of making lagged covariates a matrix, 
  # such that lag-3 MAP might be inputted as an nsim*3 matrix

  #whatever computations the user wants to make

  return(predictedMAPComputedInThisFunction)
}

You can see that I'm a little worried about syntax with longer lags involved in the model...