Age | Commit message (Collapse) | Author | Files | Lines |
|
I am postponing my attempts to get the nlmixr interface to CRAN, given
some problems with nlmixr using R-devel under Windows, see
https://github.com/nlmixrdevelopment/nlmixr/issues/596
and
https://github.com/r-hub/rhub/issues/512,
which is fixed by the removal of nlmixr from the testsuite.
For the tests to be more platform independent, the biphasic mixed
effects models test dataset was defined in a way that fitting
should be more robust (less ill-defined).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Respect digits argument when printing correlations in summaries
|
|
|
|
This means that we still get the \r in the test logs so so the
postprocessing with sed works unmodified
|
|
|
|
|
|
Adapt to the corrected data and unify control parameters for saemix and
nlmixr with saem. Update docs
|
|
|
|
The EFSA URL failed on winbuilder because some cookie sets a different
domain, so I am now using \href{} with the full link as link text instead
of \url{}
|
|
|
|
After the merge, run make test and accept the new snapshot for the mixed
model fit for an nlme object
|
|
|
|
Also adapt summary.nlmixr.mmkin to correctly handle the way
formation fractions are translated to nlmixr
|
|
|
|
|
|
In residual plots, use xlab and xlim if appropriate
|
|
- fit_with_errors for saem()
- test_log_parms for mean_degparms() and saem()
|
|
|
|
|
|
Also bump version to 1.0.3.
|
|
Run make testcheck to regenerate logs with merge conflicts
|
|
mkinfit: Keep model names stored in mkinmod objects, avoiding their loss in gmkin
|
|
Also after the upgrade from buster to bullseye of my local system, some
test results for saemix have changed.
|
|
Platform dependence also revealed after upgrade to bullseye
|
|
The errors in the example code were in the \dontrun sections, so they
were not caught by CRAN checks. In addition, the static help files
generated with pkgdown were cached, so I noticed the errors only
after completely regenerating the documentation for version 1.0.0.
|
|
- Improve authorship and copyright information
- Prepare pkgdown config
- Remove dependence on saemix as we need the development version which
is not ready for CRAN
- Temporarily remove saemix interface to check code coverage of the rest
|
|
Address release critical check and test issues
|
|
|
|
But skip the test as it takes too long to always run
|
|
I threw out mclapply as it did not play well with the linear algebra
routines used in the saemix code. Most of the change is actually
indentation in the code creating the model function. But there
is an important fix in mkinpredict which I had broken.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The default is pdDiag again, as we often have a small number of datasets
in degradation kinetics.
|
|
|
|
Depends on inline >= 0.16.2 (including the bug fixes from
eddelbuettel/inline#18), which provides 'moveDLL' to store the DLL for a
compiled function in a safe place in case the argument 'dll_dir' is
specified in the call to 'mkinmod'.
Huge thanks to Dirk @eddelbuettel for his review and support
for the work on the inline package.
|
|
With automatic reloading in mkinfit and mkinpredict in case the
DLL is not loaded and the original DLL path has been cleaned up.
Depends on jranke/inline@974bdea04fcedfafaab231e6f359c88270b56cb9
See inline#13
|
|
|
|
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.
|