Closed jdutch27 closed 9 years ago
It seems like it may be worthwhile to make HydeNetwork
a generic function with methods HydeNetwork.formula
and HydeNetwork.list
. That way the same call with the two different inputs could have vastly different behaviors.
This opens the question now of whether the Hyde objects should have nodeModel
attributes. If the model is already built, it seems wasteful to have to refit the model when we generate that JAGS code, especially if we're getting into large data sets.
The question that comes after that is: at what point in the HydeNetwork.formula
flow do we generate the models and attach them to the object? I wouldn't want to do that in HydeNetwork.formula
, because the user may make changes with setNode
. But now that I write it out, it might be reasonable to fit the model in setNode
.
My checklist to make this happen correctly Bold indicates completion
HydeNetwork
as a genericHydeNetwork.formula
as a methodHydeNetwork
will be renamed model
lm
, glm
, multinom
, and xtabs
) write a method to extract the following attributes
HydeNetwork.formula
dag
object in HydeNetwork.list
nodeData
and nodeModel
to HydeNetwork.formula
. Default to NULL
for each node.setNode
: fitModel=FALSE
. When TRUE
, it will fit the model during the setNode
run, fill in the nodeParams
. Default of FALSE
delays all of the fitting until the JAGS model is written. (perhaps set this as a global option? options(Hyde_fitModel=FALSE)
writeJagsFormula
to first look in nodeData
and then data
when using fromData()
.Changes are implemented. Now to test and fix the bugs.
It would read the regression equations from the model objects and make the network using the predictors in the model equations.
We would still need to input the prior distributions for the predictor variables.