[R-sig-ME] C test functions for lmer()

[Douglas Bates]

On Sun, Oct 3, 2010 at 10:03 AM, murat k. <skorsky12 at gmail.com> wrote:
> Hi, the caller side must be C based for my needs; Thanks for the lme4a
> suggestion.

> I also saw an nlme package, which was a precursor to lme4 I belive.. Its
> interface seems to use more of basic C types, so it is easier to understand.
> I might actually go with that option, instead of lme4 which is too tightly
> integrated into R at this point.

Well the code in the nlme package is more than 10 years old and we
have learned a lot about the computational methods in the intervening
years.

If you just want to fit a simple model with a random intercept you
would be much better off starting from the equations or the C++
classes instead of trying to decide what the internal C code in either
nlme or lme4 is doing.

> On Sun, Oct 3, 2010 at 5:05 PM, Douglas Bates <bates at stat.wisc.edu> wrote:
>>
>> On Sun, Oct 3, 2010 at 2:05 AM, Koala <skorsky12 at gmail.com> wrote:
>> > Hi everyone, I am trying to use lmer() using only C; Does anyone have
>> > test
>> > functions available that do not require R? My main routine needs to be
>> > C, but I
>> > am having a hard time understanding the data types going back and forth
>> > between
>> > R and lme4 C code. Any help would be appreciated,
>>
>> Well, naturally enough, those structures are the internal
>> representations of R objects - vectors, matrices, functions, etc.  You
>> would need to read the "Writing R Extensions" manual to understand
>> their structure and even then you would need most of the R API to be
>> able to manipulate them.  If you really want to embark on this, and it
>> is definitely not trivial, I would recommend looking at the code in
>> the lme4a package instead, because it is based on C++ classes and the
>> Rcpp package.  I'm not sure that I see the point, though, as R is
>> already open source.  If you want to reimplement for another system
>> you would probably be better off examining the structure of the
>> calculations and reimplementing them instead of trying to adapt the
>> lme4 code.
>
>