[ADMB Users] ABMD & DLLs

[Laurie Kell]

Hi

I´ll download the ADMB source code and try and track the bug It might be 
something simple such as an errant print statement. I agree that a 
worked example of an ADMB/R package with a discussion of benefits would 
be useful eg.
The benefits of using ADMB rather than R non-linear solvers (e.g. 
optim/minpack.lm), the benefits of using R for graphics, data-bases, and 
linking with other tools. Then a discussion of object orientated 
programming in R, i.e. S4 classes and FLR.

I think a candidate for this example could be Pella-T example.

Laurie


Arni Magnusson wrote:
> I had experimented with DLL compilation, but never enough to notice 
> this bug. By the way, the assignment call does work if it's the first 
> thing in the session,
>
>   x <- rep(0,100)
>   f <- 0
>   dyn.load("simpleDLL.dll")
>   res <- .C("simpleDLL", as.integer(length(x)), as.double(x),
>             as.double(f), "")
>
> but then a plain subsequent run will crash:
>
>   .C("simpleDLL", as.integer(length(x)), as.double(x), as.double(f), "")
>
> It is therefore conceivable that an R package would work fine, since 
> package functions would always make an assignment call, and never make 
> a plain call without assigning the result to an object name.
>
> R does not have this problem with non-ADMB DLLs I have tried, so it 
> appears that all ADMB DLLs are at least half broken. I still believe 
> this can be fixed by a skilled C++ programmer, with hints from Dave 
> Fournier. Until then, Johnoel will probably tag this bug report with a 
> number.
>
> Laurie, as an encouragement to improve ADMB in this area, can you 
> describe the benefits of using DLLs as opposed to plain executables? I 
> have only experimented with this a bit, and tried out the R package 
> 'glmmADMB' which uses plain executables. I'm guessing DLLs are a 
> tidier connection than passing text files to and from executables, but 
> the latter approach can achieve the same goal by adding a couple of 
> lines to the R function to take care of temporary files, right? The 
> time penalty should be negligible; I just tried writing and reading a 
> 5 column x 1000 row dataset in R,
>
>   write.table(quakes, "quakes.txt", row.names=FALSE)
>   quakes2 <- read.table("quakes.txt", header=TRUE)
>
> and it takes 0.06 sec on Windows and 0.02 sec on Linux 64, even when 
> using the inefficient read.table and write.table functions. File 
> handling on the ADMB side should be very fast as well.
>
> The benefit of using plain executables is of course that the same 
> model can be used either as stand-alone or called by other software 
> via text files. If the medium-term goal is to fix the ADMB DLLs, then 
> a long-term goal could be to make it possible to compile both DLLs and 
> executables without modifying the TPL code.
>
> Thanks for exploring this, and for improving the MSVC compilation 
> scripts.
>
> Arni
>
>
>
> On Sun, 21 Feb 2010, Laurie Kell wrote:
>
>> I have managed to compile windows MSVC9 DLLs, both on the command 
>> line and using the IDE with debugging info. I will update the 
>> adlink.bat for MSVC9
>>
>> However, using the simple example to create the DLL there is a 
>> problem when calling the DLL from R for versions compiled in MSVC9 
>> and GCC (windows and linux).
>>
>> The MSVC9 dll crashes at line
>>
>> mp.computations(argc,argv);
>>
>> While under GCC (both windows and linux) although the DLL runs i.e.
>> .C("simpleDLL", ...)
>>
>> it crashes R if  you try to save the results i.e.
>> res<-.C("simpleDLL", ...)
>>
>> I think this points to a memory allocation or a calling convention 
>> problem in the ADMB code. I´ve had a quick look at the code on 
>> http://code.google.com/p/admb-project
>>
>> But think it might be easier if somebody who is more familar with the 
>> source than me could have a look at this problem.
>>
>> Laurie
>>