Dear Bugsies,
Last month I posted an arcane question about the apparently cyclical
construction of non-trivial interval censorship of priors in BUGS. My
original post and the subsequent replies follow. Finn
-------------------------------------------------------------------
My original post to the group was:
Is anybody else concerned by the cyclic construction of this graph?
Should we assume that bugs still works when the models are not DAGs or
Chain graphs? Does the compiler check for cyclic structures? Enquiring
minds want to know.
model{
for (i in 1:N) {
a[i] ~ dweib(gammaa, lambdaa)I(leftem[i], aupper[i])
aupper[i] <- min(rightem[i], c[i]) ## ADD THIS LINE
blower[i] <- max(a[i], leftcar[i])
c[i] ~ dweib(gammab, lambdab)I(blower[i], rightcar[i])
}
-------------------------------------------------------------------
David Spiegelhalter wrote:
I think this is a very good point.
model{
for (i in 1:N) {
a[i] ~ dweib(gammaa, lambdaa)I(leftem[i], aupper[i])
aupper[i] <- min(rightem[i], c[i]) ## ADD THIS LINE
blower[i] <- max(a[i], leftcar[i])
c[i] ~ dweib(gammab, lambdab)I(blower[i], rightcar[i])
}
Unless (gammaa, lambdaa) are entirely independent in the graph from
(gammab, lambdab), I don't think this will give the correct update. This
is mentioned in the manual where the I() construct is discussed.
-------------------------------------------------------------------
I replied:
David, I was actually concerned about the cycle:
a[i] -> blower[i] -> c[i] -> aupper[i] -> a[i]
I am not familiar with MCMC on cyclic graphs. I thought bugs would
check for cyclic structures and prohibit them. Am I wrong here?
-------------------------------------------------------------------
To which David replied:
Whether to treat constraints as a 'parent' has always been a
problem, as we want to allow things like
a[1]~dnorm(0,1)I(,a[2])
a[2]~dnorm(0,1)I(a[1],)
which is formally a cycle but one we allow, provided we are not learning
common parameters of the normal distribution. Unfortunately BUGS has
not got a warning to say when this is inappropriate - I think we are
going to have to try and build one in and have more than a warning in
the manual.
-------------------------------------------------------------------
To which I replied:
There is something I am not getting here. What makes
a[1]~dnorm(0,1)I(,a[2])
a[2]~dnorm(0,1)I(a[1],)
any more acceptable than sharing 'non-interval' parameters
a[1]~dnorm(mu,tau)I(,a[2])
a[2]~dnorm(mu,tau)I(a[1],)
mu~dnorm(0,.0001)
tau~dgamma(.001,.001)
I have to wonder at the validity of the distinction between interval and
non-interval parameters. Surely there is no distinction to be made in
the case of the uniform distribution.
-------------------------------------------------------------------
To which David replied:
In the first case you are not learning any parameters - in the second it
is not clear one will have the correct likelihood term for mu and tau.
-------------------------------------------------------------------
Andrew Thomas responded to my post:
and good points. Somewhere the presedence relation BUGS uses to deal
with this sort of situation is described. The relation
must be put in explicitly in the symetric for so that the likelihood is
calculated correctly.
-------------------------------------------------------------------
Andrew Millard responded to my post:
According to the classic BUGS manual this is the correct way to specify
I() constructs (p.19) and such constructs are undirected links (p.53).
So the graph is not cyclic, but a chain graph, with c[] and a[] in a
block. Although the BUGS manual also warns "when using anything other
than a DAG it is the user's responsibility to ensure they are defining a
correct joint distribution" (p.54), I haven't found any problem when
representing prior knowledge of ordering with the I() construct.
-------------------------------------------------------------------
To which I replied:
I would agree if there was an undirected link between c[] and a[],
a[i] ~ dweib(gammaa, lambdaa)I(leftem[i], c[i])
c[i] ~ dweib(gammab, lambdab)I(a[i], rightcar[i])
but doesn't adding the line
aupper[i] <- min(rightem[i], c[i])
blower[i] <- max(a[i], leftcar[i])
to
c[i] ~ dweib(gammab, lambdab)I(blower[i], rightcar[i])
a[i] ~ dweib(gammaa, lambdaa)I(leftem[i], aupper[i])
make this a directed cycle? Can one add directed deterministic links
and maintain the undirectedness of the link? In this case, isn't c[] is
both the parent and the offspring of a[]?
-------------------------------------------------------------------
To which Andrew replied:
I looked at some lecture notes last night: the definition of a Bayesian
Belief Network (=Bayesian Graphical Model = Bayesian Belief Diagram) is
only over the random quantities, and the edges of the graph are defined
between random quantities. My notes don't have anything on computation
over the graph, but it seems likely that this is all that BUGS needs.
In that case the deterministic nodes in BUGS don't count when checking
that the graph is a chain graph. References from that lecture, which I
will check in the library if I have time, are:
Jensen, FInn V 1996 An introduction to Bayesian networks Cowell, RG,
Dawid, AP, Lauritzen SL & Speigelhalter DJ 1999 Probabilistic
networks and expert systems
Jensen's website is at www.cs.auc.dk/~fvj, but a quick look did not
reveal anything useful.
-------------------------------------------------------------------
Conclusion:
I don't think that we got it all solved. Interval censorship in this
particular case can be collapsed down to a single block in a chain
graph, but by allowing directed links to define censorship intervals, we
allow graphs that can form cycles. Andrew's citation of the manual's
warning is probably the best tool right now, but given that most of the
members of this list probably don't follow or aren't interested in this
problem, I would be more comfortable if the compiler was more
restrictive about potentially cyclic graphs. -Finn
PS As with just about every other problem, I always go back to the ONES
trick, which in this case allows us to interval censor without creating
cycles.
-------------------------------------------------------------------
This list is for discussion of modelling issues and the BUGS software.
For help with crashes and error messages, first mail [log in to unmask]
To mail the BUGS list, mail to [log in to unmask]
Before mailing, please check the archive at www.jiscmail.ac.uk/lists/bugs.html
Please do not mail attachments to the list.
To leave the BUGS list, send LEAVE BUGS to [log in to unmask]
If this fails, mail [log in to unmask], NOT the whole list
|