search

lme4 / lme4pureR

A pure R implementation of the numerical steps in lmer and glmer
35 stars 4 forks source link

Which functions to export? #7

Open dmbates opened 11 years ago

dmbates commented 11 years ago

@stevencarlislewalker I notice that you have exported functions like Zsection. It wasn't my intention that those utilities would get exported. I wrote them a short functions so that it would be follow the logic in the creation of the representation.

The thing that I would like to avoid with lme4pureR is having it morph into a large, essentially unintelligible code base like lme4.

stevencarlislewalker commented 11 years ago

I thought you might object to that move 8)

I personally found the exercise of documenting and commenting on these auxiliary functions, and using them interactively (which is aided by exporting), to be educational, which is a primary goal of lme4pureR. I agree that we don't want the complexity to grow to anywhere near that of lme4, but I don't think we are there yet. Since these functions exist anyways, I don't see the problem with exporting them.

I guess one issue could be that the help index has more entries and looks more intimidating. But we could use @rdname to put all the Lambdat/Zt functions in one help file. I do think this would be a good idea. Then there would only be three help files: (1) pls.Rd, (2) pirls.Rd, and (3) mkRanefRepresentation.Rd.

I really liked the parallelism you set up between creating the diagonal blocks of the relative covariance factor and the sections of the random effects design matrix. Both of these are created from a (1) grouping factor for each term and a (2) dense design matrix for each term. I personally think that exposing this underlying simplicity (by exporting these functions) would have value.

I guess my argument just comes down to the fact that I found it enlightening to work with those functions interactively.

stevencarlislewalker commented 11 years ago

Whoops...I mean four help files, including plsform.Rd

dmbates commented 11 years ago

I'm okay with having the functions documented in a single .Rd file. I just didn't want to end up with a whole raft of functions that could cause confusion about what were the primary functions and what were the secondary ones,

Now that you mention the parallel approaches of creating a horizontal slice of Zt and creating a diagonal block of Lambdat I wonder if those should be collapsed into a single function.