[R] Current state of support for BUGS access for Linux users?
Paul Johnson
pauljohn32 at gmail.com
Wed Jan 18 07:39:16 CET 2006
Before I forget, found the working recipe for "rbugs". My mistake
before was not
realzing that the n.iter value is total iterations, including burnin,
and so by setting
n.iter=1000 and n.burnin=1000, I was leaving 0 iterations for the updates.
### Paul Johnson 2006-01-18. This does work!
### Works in Fedora Core 4 Linux with wine-0.9.5 and WinBUGS-1.4.1
### (that's patched Winbugs 1.4). The first part is from Andrew Gelman's
### web site http://www.stat.columbia.edu/~gelman/bugsR/, but is basically
### same as rbugs example code.
schools <- read.table ("schools.dat", header=T)
J <- nrow(schools)
y <- schools$estimate
sigma.y <- schools$sd
data <- list ("J", "y", "sigma.y")
inits <- function() {list (theta=rnorm(J,0,100),
mu.theta=rnorm(1,0,100), sigma.theta=runif(1,0,100))}
parameters <- c("theta", "mu.theta", "sigma.theta")
library(rbugs)
# Note that n.iter-n.burnin = N of observations collected in CODA
schools.sim <- rbugs ( data,
inits,
parameters,
"schools.bug",
n.chains = 1,
n.iter = 30000,
n.burnin = 1000,
n.thin = 1,
workingDir="/home/pauljohn/.wine/fake_windows/temp",
bugs="/usr/local/share/WinBUGS14/WinBUGS14.exe",
bugsWorkingDir="z:/home/pauljohn/.wine/fake_windows/temp",
useWine=TRUE,
wine="/usr/bin/wine",
debug=F)
myResults <- getBugsOutput(workingDir =
"/home/pauljohn/.wine/fake_windows/temp", n.chains=1)
# Creates an ordinary data frame:
str(myResults)
library(coda)
# Another way to retrieve text file data. using coda library
c1 <- read.coda("coda1.txt",
"/home/pauljohn/.wine/fake_windows/temp/codaIndex.txt")
# That creates a much more complicated mcmc data structure, however.
# But the output is pretty nice! And there are diagnostic functions
summary(c1)
heidel.diag(c1)
geweke.diag(c1)
### need more chains to run gelman.diag
###Note R2WinBUGS has a "read.bugs" command very similar. I suspect it
### work like a simple wrapper around the read.coda function
c2 <- read.bugs("/home/pauljohn/.wine/fake_windows/temp/coda1.txt")
heidel.diag(c2)
geweke.diag(c2)
pj
On 1/17/06, Paul Johnson <pauljohn32 at gmail.com> wrote:
> Thanks! Let me ask this question again. Clearly, if you experts
> can't make R talk to WinBUGS, then I can't either. So, If "bugs()"
> doesn't work, What is the next best thing?
>
> With wine, I can run OpenBUGS and WinBUGS, but I cannot send jobs from
> R to a BUGS program (still trying, some people say they have seen
> rbugs work in Linux).
>
> I want to follow along with the instructions In Prof Gelman's site for
> R2WinBUGS. OR the examples in the rbugs package. I just noticed that
> rbugs works by writing the data, model, inits, and so forth into text
> files, along with a script that drives WinBUGS. Although there is
> something wrong with the script file that causes a fatal WinBUGS
> crash, I have just manually started the GUI and pointed and clicked my
> way to a working set of BUGS estimates (see details on script flaw
> and trap below).
>
> That makes me feel a bit confident that I will be able to create
> working BUGS sims and get results. I need to learn how to bring into
> R from CODA output. In the WinBUGS output, I find a codaIndex.txt
> file that looks promising.
>
>
> Now, about efforts to run WinBUGS from within R. In case other people
> are trying this, here is what I learned.
>
> 1. bugs() from R2WinBUGS to WinBUGS14 under wine-0.9.5 is not able to
> start WinBUGS14.exe
>
> I've just tried the newest example from
> http://www.stat.columbia.edu/~gelman/bugsR/ with WinBUGS14 under wine.
>
> WinBUGS never shows on the screen before the error appears:
>
> > library(R2WinBUGS)
> > schools <- read.table ("schools.dat", header=T)
> > J <- nrow(schools)
> > y <- schools$estimate
> > sigma.y <- schools$sd
> > data <- list ("J", "y", "sigma.y")
> > inits <- function() {list (theta=rnorm(J,0,100), mu.theta=rnorm(1,0,100), sigma.theta=runif(1,0,100))}
> > parameters <- c("theta", "mu.theta", "sigma.theta")
> > schools.sim <- bugs (data,
> + inits,
> + parameters,
> + "schools.bug",
> + bugs.directory = "/usr/local/share/WinBUGS14/",
> + n.chains=3,
> + n.iter=1000,
> + useWINE= T,
> + WINE = "/usr/bin/wine"
> + )
> Loading required package: tools
> Error in pmatch(x, table, duplicates.ok) :
> argument is not of mode character
>
> Humphf!
>
> I tried running this under debug, but can't understand the output. I
> get through about 8 steps, when bugs.script() seems to cause the
> error:
> Browse[1]> n
> debug: bugs.script(parameters.to.save, n.chains, n.iter, n.burnin, n.thin,
> bugs.directory, new.model.file, debug = debug, is.inits = !is.null(inits),
> bin = bin, DIC = DIC, useWINE = useWINE)
> Browse[1]> n
> Error in pmatch(x, table, duplicates.ok) :
> argument is not of mode character
>
>
> 2. With the "rbugs" package and WinBUGS14, I get a lot further. From
> fumbling around in this code, I can tell that rbugs writes text files
> in the working directory and then tells WinBUGS to start and access
> those files. This code causes the WinBUGS GUI to pop up and it goes
> pretty far. Using the exact same code as in the R2WinBUGS example
> above, observe:
>
>
> library(rbugs)
> schools.sim <- rbugs ( data,
> inits,
> parameters,
> "schools.bug",
> n.burnin = 1000, n.chains=1, n.iter=1000,
> workingDir="/home/pauljohn/.wine/fake_windows/temp",
> bugs="/usr/local/share/WinBUGS14/WinBUGS14.exe",
> bugsWorkingDir="z:/home/pauljohn/.wine/fake_windows/temp",
> useWine=TRUE,
> wine="/usr/bin/wine",
> debug=F)
>
> As I said, the WinBUGS14 window opens, the log file says
>
> display(log)
> check(z:/home/pauljohn/.wine/fake_windows/temp/model.txt)
> model is syntactically correct
> data(z:/home/pauljohn/.wine/fake_windows/temp/data.txt)
> data loaded
> compile(1)
> model compiled
> inits(1,z:/home/pauljohn/.wine/fake_windows/temp/init1.txt)
> model is initialized
> gen.inits()
> command #Bugs:gen.inits cannot be executed (is greyed out)
> beg(1001)
> thin.updater(1)
> set(theta)
> set(mu.theta)
> set(sigma.theta)
> set(deviance)
> update(1000)
> dic.set()
> update(0)
> stats(*)
> no monitor set
> dic.stats()
>
>
> However, after all that up pops a window called "TRAP" (pasted next).
> I believe this is going wrong becuase the fourth-to-last line is
> update(0). If I manually change that to update(30000), then the
> script does not crash. So there's something wrong in rbugs in taking
> "n.iter" into the script. I'll try to follow that up.
>
> Here's the TRAP window output. I believe it is much ado about
> nothing--update(0) is causing it.
>
> undefined real result
>
> MonitorsSummary.StdMonitor.Mean [000002FBH]
> .mean REAL 2.121995790965272E-314
> .monitor MonitorsSummary.StdMonitor [0113F3F0H]
> DeviancePlugin.EstimatedMeans [000003FBH]
> .cursor GraphStochastic.List [01145FE0H]
> .i INTEGER 0
> .j INTEGER 2143872776
> .list GraphStochastic.List [01145FE0H]
> .node GraphStochastic.Node [01044600H]
> .size INTEGER 1
> .value REAL 2.121995790965272E-314
> DevianceInterface.DICAll [0000058EH]
> .dBar REAL 3.486226116065809E+307
> .dBarTotal REAL 3.486184325428448E+307
> .dHat REAL 1.856490554558022E-303
> .dHatTotal REAL 8.948601956767742E-317
> .dicTotal REAL 1.342105535202697E-102
> .f TextMappers.Formatter Fields
> .i INTEGER 2143868088
> .monitors POINTER [01145ED0H]
> .num INTEGER 1
> .pDTotal REAL 4.244199150914158E-313
> .res INTEGER 0
> DevianceCmds.DIC [0000012DH]
> .asc INTEGER 104775
> .dsc INTEGER 28575
> .f TextMappers.Formatter Fields
> .height INTEGER 16821552
> .lines INTEGER 553779732
> .res INTEGER 0
> .t TextModels.Model [01145E50H]
> .title ARRAY 256 OF CHAR "DIC"
> .width INTEGER 114300
> StdInterpreter.CallProc [0000047AH]
> .a BOOLEAN FALSE
> .b BOOLEAN FALSE
> .c BOOLEAN FALSE
> .i Meta.Item Fields
> .imported ARRAY 256 OF CHAR "" ...
> .importing ARRAY 256 OF CHAR "" ...
> .mn Meta.Name "DevianceCmds"
> .mod StdInterpreter.Ident "DevianceCmds"
> .object ARRAY 256 OF CHAR "" ...
> .ok BOOLEAN TRUE
> .parType INTEGER 3
> .pn Meta.Name "DIC"
> .proc StdInterpreter.Ident "DIC" ...
> .res INTEGER 0
> .v StdInterpreter.ProcVal Fields
> .vi StdInterpreter.ProcIVal Fields
> .vii StdInterpreter.ProcIIVal Fields
> .vr StdInterpreter.ProcRVal Fields
> .vri StdInterpreter.ProcRIVal Fields
> .vrii StdInterpreter.ProcRIIVal Fields
> .vrr StdInterpreter.ProcRRVal Fields
> .vrri StdInterpreter.ProcRRIVal Fields
> .vrrii StdInterpreter.ProcRRIIVal Fields
> .vrs StdInterpreter.ProcRSVal Fields
> .vrsi StdInterpreter.ProcRSIVal Fields
> .vrsii StdInterpreter.ProcRSIIVal Fields
> .vs StdInterpreter.ProcSVal Fields
> .vsi StdInterpreter.ProcSIVal Fields
> .vsii StdInterpreter.ProcSIIVal Fields
> .vsr StdInterpreter.ProcSRVal Fields
> .vsri StdInterpreter.ProcSRIVal Fields
> .vsrii StdInterpreter.ProcSRIIVal Fields
> .vss StdInterpreter.ProcSSVal Fields
> .vssi StdInterpreter.ProcSSIVal Fields
> .vssii StdInterpreter.ProcSSIIVal Fields
> StdInterpreter.Command [0000131CH]
> .left StdInterpreter.Ident "DevianceCmds"
> .ptype INTEGER 3
> .right StdInterpreter.Ident "DIC" ...
> StdInterpreter.CallHook.Call [00001441H]
> .ch CHAR 0X
> .e ARRAY 64 OF CHAR "" ...
> .errorMsg ARRAY 1 OF CHAR ""
> .f ARRAY 64 OF CHAR "" ...
> .g ARRAY 64 OF CHAR "" ...
> .hook StdInterpreter.CallHook [01060050H]
> .i INTEGER 24
> .i0 INTEGER 0
> .i1 INTEGER 0
> .id StdInterpreter.Ident "DIC" ...
> .par0 Dialog.String "" ...
> .par1 Views.Title "" ...
> .proc ARRAY 240 OF CHAR "DevianceCmds.DIC('DIC')" ...
> .res INTEGER 0
> .s0 Dialog.String "DIC"
> .s1 Dialog.String "" ...
> .type INTEGER 3
> .x INTEGER 0
> Dialog.Call [00002FC8H]
> .errorMsg ARRAY 1 OF CHAR ""
> .proc ARRAY 240 OF CHAR "DevianceCmds.DIC('DIC')" ...
> .res INTEGER 0
> BugsScript.Call [00000130H]
> .bugsCommands ARRAY 240 OF CHAR "DevianceCmds.DIC('DIC')" ...
> .i INTEGER 23
> .item Meta.Item Fields
> .j INTEGER 23
> .ok BOOLEAN FALSE
> .par Dialog.Par Fields
> .pos INTEGER -1
> .res INTEGER 0
> .s ARRAY 240 OF CHAR "DevianceCmds.DIC('DIC')" ...
> .scriptCommand ARRAY 240 OF CHAR "#Bugs:dic.stats" ...
> .start INTEGER 18
> .v BugsScript.RECORD Fields
> BugsScript.Action.Do [0000062FH]
> .a BugsScript.Action [011D2120H]
> .argNum INTEGER 0
> .bugsCommands ARRAY 240 OF CHAR "DevianceCmds.DIC('DIC')" ...
> .p ARRAY 3, 120 OF CHAR Elements
> .s BugsScanners.Scanner Fields
> .scriptCommand ARRAY 240 OF CHAR "#Bugs:dic.stats" ...
> .vectorName BOOLEAN FALSE
> Services.Exec [00000136H]
> .a Services.Action [011D2120H]
> .t POINTER [21C90170H]
> Services.IterateOverActions [000002F4H]
> .p Services.Action [011D2120H]
> .t POINTER NIL
> .time LONGINT 3498
> Services.StdHook.Step [0000034DH]
> .h Services.StdHook [0101E380H]
> HostWindows.Idle [00004A86H]
> .focus BOOLEAN FALSE
> .tick Controllers.TickMsg Fields
> .w HostWindows.Window NIL
> HostMenus.TimerTick [00003422H]
> .lParam INTEGER 0
> .ops Controllers.PollOpsMsg Fields
> .wParam INTEGER 1
> .wnd INTEGER 65574
> Kernel.Try [00003A61H]
> .a INTEGER 65574
> .b INTEGER 1
> .c INTEGER 0
> .h PROCEDURE HostMenus.TimerTick
> HostMenus.ApplWinHandler [00003841H]
> .Proc PROCEDURE NIL
> .hit BOOLEAN Undefined70
> .lParam INTEGER 0
> .message INTEGER 275
> .res INTEGER 1180843108
> .s ARRAY 256 OF SHORTCHAR 2X ...
> .w INTEGER 538416909
> .wParam INTEGER 1
> .wnd INTEGER 65574
> <system> (pc=465EDB29H, fp=7FC8FB00H)
> <system> (pc=465EE418H, fp=7FC8FB3CH)
> <system> (pc=465F1DF0H, fp=7FC8FB80H)
> <system> (pc=465BD031H, fp=7FC8FBB0H)
> HostMenus.Loop [00003BDEH]
> .done BOOLEAN FALSE
> .f SET {0..5}
> .n INTEGER 0
> .res INTEGER 0
> .w HostWindows.Window NIL
> Kernel.Start [00002B8CH]
> .code PROCEDURE HostMenus.Loop
>
>
> 3. Accessing OpenBUGS with wine from "rbugs" gets as far as opening
> the OpenBUGS GUI, but nothing ever appears in the log file and there
> are no computations going on (according to system monitors, anyway),
> but everything in OpenBUGS just seems stuck.
>
>
> pj
>
>
> On 1/17/06, Uwe Ligges <ligges at statistik.uni-dortmund.de> wrote:
> > Paul Johnson wrote:
> > > Thanks, Uwe
> > >
> > > that clears up why I can't make R2WinBUGs work with OpenBUGS and WinBUGS1.5 :)
> > > Both work pretty good with Wine in a GUI. I noticed that when I tried
> > > "rbugs", it does succeed in starting WinBUGS GUI, but then nothing
> > > happens. I'll get WinBUGS1.4 and see what happens.
> > >
> > > In the meanwhile, I'm going to t ry to see what BRugs is good for. In
> > > Linux, when I try to install BRugs, the install fails with an error
> > > saying that, at the current time, BRugs works only in Windows.
> >
> >
> > Yes, I have added that particular line in order not to confuse users,
> > and I thought I told you in my last message that it works only under
> > Windows.
> >
> >
> > > * Installing *source* package 'BRugs' ...
> > > Package 'BRugs' currently only works under Windows.\nIt is supposed to
> > > work under Linux in future releases.
> > >
> > > I'd like to stop that check and see what happens!
> >
> > OK, just remove the configure file.
> >
> >
> > > The way I read the
> > > sourcecode from OpenBUGS and BRugs, I need to replace the windows dll
> > > install and instead put in an so file (as in OpenBUGS).
> >
> > Yes, it is already shipped, and the infrastructure in the package is
> > ready (hopefully), but the brugs.so file does not work as expected.
> >
> >
> > > If anybody has done this, please let me know of your experience.
> >
> > Yes, several tried, among them Andrew Thomas and Uwe Ligges, and then I
> > invited Andrew Thomas to Dortmund and we tried together (I have to admit
> > that I was clueless all the time and in fact Andrew tried).
> > Andrew's conclusion was that there is some compiler problem on Linux
> > with the BlackBox framework (Component Pascal compiler from Oberon
> > microsystems) in which WinBUGS/OpenBUGS is written in ...
> >
> > If you get it to work, please let us know!
> >
> > Uwe
> >
>
> --
> Paul E. Johnson
> Professor, Political Science
> 1541 Lilac Lane, Room 504
> University of Kansas
>
--
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas
More information about the R-help
mailing list