Hi,
Thanks to all who took the time to reply, in particular Simon Jackman & Gene
Hahn (who's replies gave me the confidence to trust my alternative code for
"sum-to-zero" parameterisation) and Martyn Plummer (who prompted me to
compare my results with the data augmented 'NA' approach to making
predictions). In general, I would also recommend this approach for making
predictions - I use a different, but equivalent approach, due to how my
program, BugsXLA, automatically generates code.
I now believe, rather embarrassingly, that my original predictions
(equivalent to the "NA" approach) are fine. My initial doubts essentially
arose due to my incorrect assumption that the mean for a specific factor
level in the study should be estimated less precisely than the population
mean. Whilst this is true for a fixed effects model, I had not thought hard
enough to realise it is not necessarily true for a random effects model. A
small excuse is that I was originally thinking about these means as
predictions, which clouded my view a little.
However, I am now wiser about a couple of things as a result of this
mistake. I believe I now understand the difference between the thetas for
the two types of parameterisation (see below for my interpretation), and if
I do ever wish to code up a sum-to-zero constraint, I believe my "60% faster
method" is perfectly OK.
It is easier to show the differences between the "free floating" and
"sum-to-zero" parameterisation with a simple Normal model (eg Dyes
data-set). Parameterised as in the manual, the constant theta is estimated
with mean (sd) of 1529 (23). A sum-to-zero parameterisation and it has mean
(sd) of 1528 (9). Comparing to a classical analysis, the original st.dev.
is comparable to the st.err. obtained from a random effects analysis, while
the "sum-to-zero" st.dev. is comparable to the st.err. obtained from a fixed
effects analysis. Hence, I assume that in the former case theta is
interpreted as the population mean of the distribution of batches, whilst in
the latter it is just the mean of the six batches in the study.
Apologies to all for raising an issue that turned out to be non-existent
(although just being able to "talk" this issue through with knowledgable
WinBUGS folk has been extremely valuable to me, allowing me to progress my
work with some confidence). Once again, if you believe I am still incorrect
in my understanding of how this all works, please contact me directly.
Many thanks
> Phil Woodward
>
>
>
-------------------------------------------------------------------
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
|