figure out way to propagate initial values for lifted nodes from LHS link about nimble HOT 10 CLOSED

I think there are separate aspects of this issue for R execution and compilation. For R execution (used during initialization), we could arrange for the active binding for mu to automatically set log_mu. We'd have to keep track of all links for all scalar elements in a variable, but we could do that. If we also want compiled run code like model[["mu"]] <- 5 to automatically initialize log_mu, that would be a separate project. One way would be to generate a set of "nodeFunctions" for the task that aren't ever found from the model graph but can be used as nodeFunctionVector in compiled code. Do we want both?

from nimble.

I would unequivocally suggest that if we implement that on the R side
(initializing "mu" automatically initializes "log_mu"), then we should
support the same behaviour in C++.

Daniel

On Mon, May 4, 2015 at 3:54 PM, perrydv [email protected] wrote:

I think there are separate aspects of this issue for R execution and
compilation. For R execution (used during initialization), we could arrange
for the active binding for mu to automatically set log_mu. We'd have to
keep track of all links for all scalar elements in a variable, but we could
do that. If we also want compiled run code like model[["mu"]] <- 5 to
automatically initialize log_mu, that would be a separate project. One way
would be to generate a set of "nodeFunctions" for the task that aren't ever
found from the model graph but can be used as nodeFunctionVector in
compiled code. Do we want both?

—
Reply to this email directly or view it on GitHub
#16 (comment).

from nimble.

I agree, but I made the distinction since the issue label referred only to initial values, not to general value assignment. But I think it really is the latter.
Perry

On May 4, 2015, at 4:00 PM, Daniel Turek [email protected] wrote:

I would unequivocally suggest that if we implement that on the R side
(initializing "mu" automatically initializes "log_mu"), then we should
support the same behaviour in C++.

Daniel

On Mon, May 4, 2015 at 3:54 PM, perrydv [email protected] wrote:

I think there are separate aspects of this issue for R execution and
compilation. For R execution (used during initialization), we could arrange
for the active binding for mu to automatically set log_mu. We'd have to
keep track of all links for all scalar elements in a variable, but we could
do that. If we also want compiled run code like model[["mu"]] <- 5 to
automatically initialize log_mu, that would be a separate project. One way
would be to generate a set of "nodeFunctions" for the task that aren't ever
found from the model graph but can be used as nodeFunctionVector in
compiled code. Do we want both?

—
Reply to this email directly or view it on GitHub
#16 (comment).

—
Reply to this email directly or view it on GitHub #16 (comment).

from nimble.

We talked about how getting this to work from R (for either compiled or uncompiled model objects) will be easier than for compilation. We thought we should go ahead with the easier step so it is available for setting initial values. I'm wondering if it would be better for me to implement that as a separate member function (setValues?) rather than building it into the active binding. That would keep the inconsistency clearer since setValues would fail to compile rather than compiling and providing different behavior.

from nimble.

I'm not quite following ... if a user says:

log(x) ~ dnorm(0,1)

in BUGS and then says "model$x <- 1" or model$setInits(x = 1), do/would
both of these assignments happen by way of setValues rather than the active
binding?

Making the inconsistency clearer sounds good to me.

chris

On Thu, May 14, 2015 at 12:40 PM, perrydv [email protected] wrote:

We talked about how getting this to work from R (for either compiled or
uncompiled model objects) will be easier than for compilation. We thought
we should go ahead with the easier step so it is available for setting
initial values. I'm wondering if it would be better for me to implement
that as a separate member function (setValues?) rather than building it
into the active binding. That would keep the inconsistency clearer since
setValues would fail to compile rather than compiling and providing
different behavior.

—
Reply to this email directly or view it on GitHub
#16 (comment).

from nimble.

No, the suggestion is that model$x <- 1 would set only x, while model$setValues(x = 1) would do some work and also set log_x.

If we make model$x <- 1 automatically set log_x during R execution but not compiled execution, that’s the inconsistency I’m suggesting we avoid.

I think setValues is a more general name than setInits, but I’m open to suggestion on that.

On May 14, 2015, at 1:09 PM, Christopher Paciorek [email protected] wrote:

I'm not quite following ... if a user says:

log(x) ~ dnorm(0,1)

in BUGS and then says "model$x <- 1" or model$setInits(x = 1), do/would
both of these assignments happen by way of setValues rather than the active
binding?

Making the inconsistency clearer sounds good to me.

chris

On Thu, May 14, 2015 at 12:40 PM, perrydv [email protected] wrote:

We talked about how getting this to work from R (for either compiled or
uncompiled model objects) will be easier than for compilation. We thought
we should go ahead with the easier step so it is available for setting
initial values. I'm wondering if it would be better for me to implement
that as a separate member function (setValues?) rather than building it
into the active binding. That would keep the inconsistency clearer since
setValues would fail to compile rather than compiling and providing
different behavior.

—
Reply to this email directly or view it on GitHub
#16 (comment).

—
Reply to this email directly or view it on GitHub #16 (comment).

from nimble.

setInits() exists now and is currently only for variables/nodes in a model
and is separate functionality corresponding to what is often done with the
'inits' argument to nimbleModel(). So I think we're talking about different
but related things.

It's occurring to me that if we don't do it via "<-", then we might just do
this completely via the inits argument and via setInits(). And print a
warning to the user when a model contains a LHS link that assigning via
"<-" is dangerous as it doesn't get the lifted node.

The 3 of us might want to chat about this in person tmrw.

On Thu, May 14, 2015 at 1:11 PM, perrydv [email protected] wrote:

No, the suggestion is that model$x <- 1 would set only x, while
model$setValues(x = 1) would do some work and also set log_x.

If we make model$x <- 1 automatically set log_x during R execution but not
compiled execution, that’s the inconsistency I’m suggesting we avoid.

I think setValues is a more general name than setInits, but I’m open to
suggestion on that.

On May 14, 2015, at 1:09 PM, Christopher Paciorek <
[email protected]> wrote:

I'm not quite following ... if a user says:

log(x) ~ dnorm(0,1)

in BUGS and then says "model$x <- 1" or model$setInits(x = 1), do/would
both of these assignments happen by way of setValues rather than the
active
binding?

Making the inconsistency clearer sounds good to me.

chris

On Thu, May 14, 2015 at 12:40 PM, perrydv [email protected]
wrote:

We talked about how getting this to work from R (for either compiled or
uncompiled model objects) will be easier than for compilation. We
thought
we should go ahead with the easier step so it is available for setting
initial values. I'm wondering if it would be better for me to implement
that as a separate member function (setValues?) rather than building it
into the active binding. That would keep the inconsistency clearer
since
setValues would fail to compile rather than compiling and providing
different behavior.

—
Reply to this email directly or view it on GitHub
<#16 (comment)
.

—
Reply to this email directly or view it on GitHub <
https://github.com/nimble-dev/nimble/issues/16#issuecomment-102152971>.

—
Reply to this email directly or view it on GitHub
#16 (comment).

from nimble.

We didn't get a chance to talk about this today.

My point is that I think this need arises beyond just "initializing a model", so I was thinking of a "setValues". If "setInits" (which sounds like it refers to initialization only) uses setValues, that would make sense.

Does that fit with your thinking?

from nimble.

A few summary points from an in-person discussion

• this would be hard to handle in generality.
• one possibility is to just have setInits() do the assignment to the parent node
• we could have setValues() or setValuesWithLink() to work on the R side for assigning into models but this requires users to know about the existence of this special assignment and then when working programmatically with models, they'd need to have something that works when one doesn't know in advance which nodes of a model have LHS link
• in either case, this would be hard to handle in the DSL

JAGS does not allow LHS links for stochastic declarations. For deterministic declarations, the BUGS examples show initialization of the variables on the RHS and not directly of the variable on the LHS.

For the moment, we're going to leave this issue unresolved.

from nimble.

moved to wiki

from nimble.