-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature consideration: Autodetect model transformations to set typical values? #8
Comments
I implemented this in nlmixr2/babelmixr2#48 Perhaps we should consider it it should move upstream to |
Isn't this in the get split mu ref module? And if it uses the same code, it can only be promoted to |
mu referencing is calculated in |
I'm not sure if we're talking about the same thing. What I'm talking about is something that I wrote for the PKNCA link: What it does it it allows a model with mod %>%
ini_transform(vc=2) And it will look at the transformation table and the mu reference table to see that what the user meant was: mod %>%
ini(lvc = log(2)) Is that what you've already done? (If so please let me know how to do it, and I will drop the part I added to the PKNCA link.) |
No it isn't the same thing that we are talking about. However, since it uses |
Let me think about this a bit. If we don't promote to |
Well, it uses the |
This is a longer-term request. It does not need to happen before the PKNCA connection is made.
Something that would help the PKNCA connection would be the ability to automatically detect typical value translations and parameter names. This also seems like it could be useful for users to get the automatic back-translation. As an example, it would be useful to do something like the following:
lka
and the parameter within the model is defined aska <- exp(lka)
(eta and additional covariates may be added, too).ini(model, ka=2)
gets automatically translated toini(model, lka=log(2))
.The code for this could be pretty similar to what is already in
addEta()
.My first thought for implementation is that it would be best/easiest within the
ini()
function itself, but if the mu-referencing is only known tonlmixr2est
and not known torxode2
, that makes it a bit more complicated. If implemented inrxode2
, then I think that the mu-referencing code would need to move fromnlmixr2est
torxode2
(but I don't really know).My second thought is to put it here and give it a unique name like
updateIni()
. That is cleaner in that translation of parameter names would never happen without it being intentional. (In other words, translation fromka
tolka
would not happen withinini()
.) But, it makes the user need to know another function for a similar purpose.My third thought is: Don't make this too complicated, Bill.
Thoughts?
The text was updated successfully, but these errors were encountered: