Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I can test on R-devel locally for preparing releases
|
|
|
|
|
|
The default is pdDiag again, as we often have a small number of datasets
in degradation kinetics.
|
|
|
|
|
|
|
|
As can be seen in the miniscule change seen on R-devel in the reference
plot updated with this commit
|
|
Also make the endpoints function work for saem objects.
|
|
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.
|
|
Also, use logit transformation for g and for solitary formation
fractions, addressing #10.
|
|
|
|
Improve and update docs
|
|
|
|
|
|
- Reduce significant digits for the objective function output in
mkinfit(..., quiet = FALSE) as R and R-devel gave different output on my
system
- Add makefile target 'devtest' for testing with R-devel, in order
to fix problems showing up with R-devel on Travis
|
|
|
|
following the arguments of Xavier Robin https://github.com/r-lib/vdiffr/issues/86#issuecomment-636447231
|
|
Vignette FOCUS_L failed as I had introduced a bug in the handling of
warnings.
Current vdiffr only runs visual tests if R < 4.1.0, skipping r-devel for now,
see https://github.com/r-lib/vdiffr/commit/630a29d013361fd63fea242f531e2db6aef37919
|
|
|
|
This revealed a bug in the data returned in mkinfit$data in the case
of the d_3 algorithm, which also affected the residual plot - the
data from the direct fitting was not returned even if this was
the better method.
|
|
|
|
Also, use more intelligent starting values for the variance of the
random effects for saemix. While this does not appear to speed up
the convergence, it shows where this variance is greatly reduced
by using mixed-effects models as opposed to the separate independent
fits.
|
|
|
|
|
|
|
|
This is about twice as fast as deSolve compiled in the case of FOCUS D
|
|
|
|
https://github.com/r-lib/vdiffr/issues/86
|
|
|
|
also for deSolve and eigenvalue based solutions. This noticeably increases
performance for these methods, see test.log and benchmark vignette.
|
|
This revealed that transforming rates is necessary for fitting
the analytical solution of the SFO-SFO model to the FOCUS D dataset.
Benchmarks show that fitting coupled models with deSolve got a bit
slower through the latest changes
|
|
This increases performance up to a factor of five!
|
|
|
|
Still in preparation for analytical solutions of coupled models
|
|
Preparing for symbolic solutions for more than one compound
|
|
|
|
|
|
This was done to address the test failure on
r-devel-linux-x86_64-debian-gcc on CRAN
|
|
|
|
|