Add nlmixr_formula() (testable work in progress)

[billdenney]

Fix #6.

What it does is it implements a formula interface that allows nlmixr2 models to be estimated when all that is required is an algebraic formula. It takes inspiration from lme4::nlmer() for the way to define the formula to use.

The current state of the PR does not have testing, and documentation needs expansion. There are some design decisions that I think are worth vetting, too.

The main design decisions that are questionable to me are:

• Is there a better/simpler formula interface to use that incorporates fixed and random effects? What about automated modeling of parameters?
• How should random effects be defined? Should they be required to be different than fixed effects or should the system automatically generate the different names for the user?
• Can there be more than one type of random effect? In other words must it be just ID or are other columns also acceptable?
• There's no way to specify the starting random effect variability; it simply starts at 1. Should an interface be added for that?
• Is the way that it handles factors when generating multiple fixed effects good? Is there a better way to generate them?
• Should it handle more types of automatic parameterization than just factors? (That can be a downstream option.)

[mattfidler]

One minor comment, please adopt the style used in the rest of the package. I follow more or less the bionconductor style guide:

https://contributions.bioconductor.org/r-code.html

[mattfidler]

Mostly I really want a consistent feel from the user and developer perspective. If we follow a consistent style guide then this would be easier to achieve

[mattfidler]

Can there be more than one type of random effect? In other words must it be just ID or are other columns also acceptable?

Eventually possible right now not possible

[mattfidler]

Is the way that it handles factors when generating multiple fixed effects good? Is there a better way to generate them?

This perhaps should be generalized to the rest of nlmixr?

[billdenney]

I'm happy to modify the style. My default style is snake_case, and I needed this pretty quickly for something else. I also thought that there may be significant modifications after considerations for the ways that it works, so I'm guessing there will be some pretty big rework before it's done.

I don't see a simple way to generalize the factor handling to the rest of nlmixr2, but I'd be interested to think about it more and hear thoughts of how it could be done. The way that the nlmixr2 ini() works right now, I don't readily see a way to make it work with factors. I could imagine a few different ways that it could be augmented, but at that point, I worry that the UI would start to get cumbersome. Balancing the feature with the UI needs should be discussed in depth.

A few ideas of how I considered it were:

• Assignment with a vertical bar in the ini block could assign the same initial estimate to all factor levels (e.g. a <- fixed(1, 2, 3) | STUDYID). That would parallel what is done for random effects with fixed effects pretty simply. But, you would now have to watch for a somewhat subtle difference between <- and ~ which already trips me up sometimes when writing the models.
• Only support it with post-processing of a model (but that doesn't feel good since I think you should have all of the flexibility in the main model syntax).

[billdenney]

FYI, this PR update only changes things around the edges (documentation issues, mainly). I'll go through the coding style after the underlying functionality has been reviewed.

[billdenney]

Another thought for generating parameters for a model with a fixed effect per factor level. Should we go all the way down the path of generating orthogonal contrasts for estimation and then back-transforming them? That seems like it would be mathematically the best (in most scenarios), but it gets a lot more cumbersome.

Or, maybe that is already sufficiently covered by nlmixr2extra::preconditionFit().

[mattfidler]

Well, all factors are mu referenced so perhaps simply adding them to the linear model for covariates would be fine. If that is the case , the initial estimate would be mostly irrelevant. This speaks to adding my referenced covariates to focei like nonmem....

[billdenney]

I don't understand "all factors are mu referenced".