Saturated Model Log-Likelihood for Multinomial Outcomes

When the response variable Y takes one of R > 1 values, the function 'glsm()' computes the maximum likelihood estimates (MLEs) of the parameters under four models: null, complete, saturated, and logistic. It also calculates the log-likelihood values for each model. This method assumes independent, non-identically distributed variables. For grouped data with a multinomial outcome, where observations are divided into J populations, the function 'glsm()' provides estimation for any number K of explanatory variables.

Log-Gaussian Cox Process Models with Approximations

Supports modelling case data to facilitate. The package provides automated computational grid generation over an area of interest with methods to map covariates between geographies, model fitting including spatially aggregated case counts, and predictions and visualisation. Monte Carlo maximum likelihood is the main fitting method with a low-rank approximation for Gaussian processes described by Solin and Särkkä (2020) and a stochastic partial differential equation approximation. Bayesian methods are also provided for some methods. Log-Gaussian Cox Processes are described by Diggle et al. (2013) .

Compare Models with Cross-Validated Log-Likelihood

An implementation of the cross-validated difference in means (CVDM) test by Desmarais and Harden (2014) (see also Harden and Desmarais, 2011 ) and the cross-validated median fit (CVMF) test by Desmarais and Harden (2012) . These tests use leave-one-out cross-validated log-likelihoods to assist in selecting among model estimations. You can also utilize data from Golder (2010) and Joshi & Mason (2008) that are included to facilitate examples from real-world analysis.

Robust, Logged and Reproducible Iteration at Organizational Scale

Turns one-off iterative R procedures (such as for loops, lapply() or pmap() from 'purrr') into production-grade workflows by wrapping them with orthogonal, composable execution layers. Two layers are always active: structured logging with real traceback and per-case timing; and reproducibility capture, which records the R version, loaded package versions, execution environment, the exact iteration mask, and a stat-based fingerprint of every input file referenced in the mask (with a diff_inputs() helper to detect silent drift between runs). Parallel execution (built on the 'future' framework, Bengtsson (2021) ), non-blocking background jobs, and opt-in progress reporting (via 'progressr') are implemented as optional, composable layers. Further layers (error replay, content-hash input fingerprinting, content-based case identifiers) are planned and will remain composable with the default layers.

Send Log Messages to Remote 'syslog' Server

Send 'syslog' protocol messages to a remote 'syslog' server specified by host name and TCP network port.

Processing of 'CARWatch' Sampling Logs and Saliva Data

Import and reconstruct saliva-sampling studies recorded by the 'CARWatch' application. Registration metadata and raw barcode events are converted into auditable study days and scheduled sample positions using a two-pass issue-review workflow. Functions assess sampling-time compliance, merge laboratory saliva measurements, calculate response features, and create quality-control visualizations. The application is described by Richer et al. (2023) .

Produces Markdown Log File with a Built-in Function Call

Produces clean and neat Markdown log file and also provide an argument to include the function call inside the Markdown log.

Analyze Download Logs from the CRAN RStudio Mirror

Analyze download logs from the CRAN RStudio mirror (< http://cran.rstudio.com/>). This CRAN mirror is the default one used in RStudio. The available data is the result of parsed and anonymised raw log data from that CRAN mirror.

Dynamic Logging for R Inspired by Configuration Driven Development

A comprehensive and dynamic configuration driven logging package for R. While there are several excellent logging solutions already in the R ecosystem, I always feel constrained in some way by each of them. Every project is designed differently to solve it's domain specific problem, and ultimately the utility of a logging solution is its ability to adapt to this design. This is the raison d'être for 'dyn.log': to provide a modular design, template mechanics and a configuration-based integration model, so that the logger can integrate deeply into your design, even though it knows nothing about it.

Parsing Semi-Structured Log Files into Tabular Format

Convert semi-structured log files (such as 'Apache' access.log files) into a tabular format (data.frame) using a standard template system.