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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 ______________________________________________ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html