Fitting kinetic models to chemical degradation data (also on github) https://erac.jrwb.de/mkin/atom?h=v1.0.3 2021-02-04T10:41:06Z 2021-02-04T10:41:06Z Johannes Ranke jranke@uni-bremen.de 2021-02-04T10:24:22Z urn:sha1:ac183c732317cf6ede26a2ee127604a407f0a6b3 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. 2021-02-03T17:18:19Z Johannes Ranke jranke@uni-bremen.de 2021-02-03T15:41:31Z urn:sha1:f0ef23a7598e5d19648ae4edc2b74e0fba27a41c - 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 2020-12-19T11:24:43Z Johannes Ranke jranke@uni-bremen.de 2020-12-19T11:24:43Z urn:sha1:e2aa453b1d5535ceb2d0d7b042d2c3b68c6298d1 2020-12-11T14:39:43Z Johannes Ranke jranke@uni-bremen.de 2020-12-11T14:39:43Z urn:sha1:c6a1733974334b4e97a27170c60e481dc9e9f35d 2020-11-19T14:41:24Z Johannes Ranke jranke@uni-bremen.de 2020-11-19T14:41:24Z urn:sha1:db9ae6a0c9cecb92048fde6f06af1da183c09b5f By depending on parallel instead of importing it, functions to set up and stop a cluster are always available when mkin is loaded. The use of multicore processing in mmkin on Windows is now documented in the help file, which brings mkin closer to a version 1.0 #9. 2020-11-09T16:24:53Z Johannes Ranke jranke@uni-bremen.de 2020-11-09T16:24:53Z urn:sha1:aa74f5a30853fb0a15c99c283e072f08ee819149 With a plot method. The class mixed.mmkin is currently only a virtual class created to unify the plotting method. 2020-11-09T13:23:16Z Johannes Ranke jranke@uni-bremen.de 2020-11-09T13:23:16Z urn:sha1:6464d3999338d34c081f360694dbc0bc0abf68cb 2020-11-08T01:12:55Z Johannes Ranke jranke@uni-bremen.de 2020-11-08T01:12:55Z urn:sha1:279a1d83d7cbe39a953467762629eb1abb9addf4 Also make the endpoints function work for saem objects. 2020-11-07T11:54:58Z Johannes Ranke jranke@uni-bremen.de 2020-11-07T11:54:58Z urn:sha1:2e37905a7bf0d72751ee7326ef05a268989e49b2 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. 2020-10-27T14:36:46Z Johannes Ranke jranke@uni-bremen.de 2020-10-27T14:34:14Z urn:sha1:a5874ab7fce4616e80be69366ff0685332f47bf1 Improve and update docs