diff options
author | Johannes Ranke <jranke@uni-bremen.de> | 2020-11-07 12:54:58 +0100 |
---|---|---|
committer | Johannes Ranke <jranke@uni-bremen.de> | 2020-11-07 12:54:58 +0100 |
commit | 2e37905a7bf0d72751ee7326ef05a268989e49b2 (patch) | |
tree | cd65d87f8ff258304b26f3aa64e5a8c7216400d6 /man/mkinpredict.Rd | |
parent | cda47972e2b6a9610e3118dcd2270d7a1c76de3d (diff) |
Create saem generic for fitting saemix models
The reasons for this decision were
- Creating an saemix generic in the saemix package caused problems with
roxygen, because functions like saemix.plot.xy were documented in
their help files as S3 methods, although explicitly exported with
@export
- Creating an saemix generic in this package is possible, but would
make it necessary to load samix with exclude = "saemix" in order to
avoid overwriting the generic when loading saemix.
- The return object of such an saemix generic in this package cannot
be an S3 class with class attribute c("saemix.mmkin", "SaemixObject")
similar to nlme.mmkin, as saemix returns an S4 class.
- Extending the S4 class SaemixObject using simple inheritance to
a class SaemixMmkinObject with additional slots did not work
as expected. When the initialize method was left untouched, it
prevented creation of an SaemixMmkinObject even if it was based
on an initialised SaemixObject, as the initialize method seems
to always be called by new(). This could potentially be circumvented
by a coerce method. If an alternative initialize method was
used, an SaemixMmkinObject could be created. However, the methods
written for SaemixObjects only worked in some instances, either
because they checked for the class, and not for class inheritance
(like compare.saemix), or because the initialize method was called
for some reason. Therefore, the idea of creating a derived S4 class
was abandoned.
- A side effect of this decision is that the introduction of the saem
generic opens the possibility to use the same generic also for other
backends like nlmixr with the SAEM algorithm.
Diffstat (limited to 'man/mkinpredict.Rd')
-rw-r--r-- | man/mkinpredict.Rd | 22 |
1 files changed, 5 insertions, 17 deletions
diff --git a/man/mkinpredict.Rd b/man/mkinpredict.Rd index f2799bf4..3a2939e1 100644 --- a/man/mkinpredict.Rd +++ b/man/mkinpredict.Rd @@ -6,19 +6,7 @@ \alias{mkinpredict.mkinfit} \title{Produce predictions from a kinetic model using specific parameters} \usage{ -mkinpredict( - x, - odeparms, - odeini, - outtimes = seq(0, 120, by = 0.1), - solution_type = "deSolve", - use_compiled = "auto", - method.ode = "lsoda", - atol = 1e-08, - rtol = 1e-10, - map_output = TRUE, - ... -) +mkinpredict(x, odeparms, odeini, outtimes, ...) \method{mkinpredict}{mkinmod}( x, @@ -30,8 +18,8 @@ mkinpredict( method.ode = "lsoda", atol = 1e-08, rtol = 1e-10, - na_stop = TRUE, map_output = TRUE, + na_stop = TRUE, ... ) @@ -65,6 +53,9 @@ observed variables, for example in the case of the SFORB model.} \item{outtimes}{A numeric vector specifying the time points for which model predictions should be generated.} +\item{\dots}{Further arguments passed to the ode solver in case such a +solver is used.} + \item{solution_type}{The method that should be used for producing the predictions. This should generally be "analytical" if there is only one observed variable, and usually "deSolve" in the case of several observed @@ -89,9 +80,6 @@ the observed variables (default) or for all state variables (if set to FALSE). Setting this to FALSE has no effect for analytical solutions, as these always return mapped output.} -\item{\dots}{Further arguments passed to the ode solver in case such a -solver is used.} - \item{na_stop}{Should it be an error if deSolve::ode returns NaN values} } \value{ |