Re: [Bugs-r-devel] Recent changes

[Uwe L. <li...@st...>]

Gregor Gorjanc wrote:
> Hi Rodney.
> 
> Sorry for late response.
> 
> Rodney Sparapani wrote:
>> Gorjanc Gregor wrote:
>>>> DarWINE 0.9.43 and 0.9.44 have some problems as well.
>>>>
>>> Any meaningful error message?
>>>
>> Not really.  And, it's very surprising.  OpenBUGS had a pretty
>> good track record with DarWINE.  v. 2.2.0 started working
>> with DarWINE 0.9.12 and worked for every version that I tried after
>> that.  WinBUGS was far more tempermental.  v. 1.4.3
>> is the first that I have ever been able to run with DarWINE.
> 
> Can not help here. But it is good to have some feedback on which 
> versions are happy with each other.
> 
>>>> Now, how do I install the latest trunk to do the same test?
>>>> I've downloaded it, but there does not appear to be a .tgz file.
>>>>
>>> Just build it. I guess mac side should not be much different from
>>>
>>> R CMD build R2WinBUGS
>>>
>> Ah, didn't think of that.  I'll give it a try.  But, it would
>> probably be easier to just include the .tgz in the repository.
> 
> Tarball is available from CRAN for published packages. If we would 
> provide tarball in the repository for each commit, the the size of SVN 
> databse would probably blow up. I think that R CMD build is not that 
> hard to do.
> 
>> In any case, I was looking around in R2WinBUGS and I noticed that
>> fitbugs is not included.  Is there any reason for this?  I'd like to see
>> a version of fitbugs that returns the object and also allows WINE to be
>> used.  The version of fitbugs that I found doesn't appear to have either
>> of these.  But, maybe there is a later version somewhere?  Here's the
>> one I've been looking at http://www.stat.columbia.edu/~kerman/td/fitbugs.R
>> Of course, I'm willing to work on this.  But, I didn't want to
>> re-invent the wheel.
> 
> fitbugs() was written by Jouni Kerman and Uwe has implemented part of it 
> as write.model(). Maybe he can comment on why only writing a model from 
> an R function was implemented.

Easy: fitbugs() makes very though assumptions that the user is very 
careful with environments and data. It is extremely dangerous to use 
fitbugs() within other functions, because scoping issues will arise 
almost certainly.
If you have variable (=node) names such as N, T, a and x in your BUGS 
model and in your R environmants (which is quite probable), then you 
will have conflicts. If you do want to circumvent this, just use the 
meta function BRugsFit(), which does it all in a clean way!

So the way is to call
a) write.model() and after that
b) BRugsFit()

and you have finished

What we could do is: let BRugsFit() decide if model.file is a function 
and call write.model() automatically to write into a temporary model 
file in that case.

Uwe



>> Lastly, one thing that I forgot to mention.  When I ran the
>> BUGS-L example, a new WinBUGS window opens, performs the
>> analysis, creates some graphics, and then closes, before you
>> have a chance to actually look at the graphics.  The posterior/summary
>> is returned, but I'm wondering why the window closes.  Is this supposed
>> to happen?  Or is this a problem only on Mac?
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Bugs-r-devel mailing list
> Bug...@li...
> https://lists.sourceforge.net/lists/listinfo/bugs-r-devel