NEWS.md

inlabru (development version)

Feature updates

inlabru 2.10.1

Feature updates

Bug fixes and dependency simplification

inlabru 2.10.0

Feature updates

Bug fixes

inlabru 2.9.0

Feature updates

Note: From version 2.9.0, use bru_log() to access the global log, and bru_log(fit) to access a stored estimation log.

Up to version 2.8.0, bru_log() was a deprecated alias for bru_log_message(). When running on 2.8.0 or earlier, use bru_log_get() to access the global log, and cat(fit$bru_iinla$log, sep = "\n") to print a stored estimation object log.

Bug fixes and speed improvements

Deprecation of old functions

inlabru 2.8.0

Feature updates

The bru_used() methods are used to guess the needed component names, applied to the right-hand side of the formula arguments. The allow_latent argument to like() has been deprecated in favour of include_latent (by default auto-detected for use of _latent and _eval).

The internal information storage is handled by the new bru_used() methods, that can also be used directly by the user and supplied via the used argument to like()/generate()/predict(). Add fm_int() integration methods, replacing the old ipmaker() and ipoints() methods. Supports both sf and sp sampler objects. Add fm_pixels() methods for gridded points. The old pixels() method now calls fm_pixels(..., format = "sp") eval_spatial support for sf objects (for point-in-polygon data lookups) Allow precomputed spatial covariates in the data for point process observations Add edge|int|ext.linewidth arguments to gg.inla.mesh #188 Rename the predict() and generate() data arguments to newdata, for better compatibility with other predict() methods. The old argument name will still be accepted, but give a warning. Code that does not name the data argument is not affected. * Note: Coordinate names for Spatial* objects have been inconsistently available in the predictor expression evaluation. However, due to how internal conversions might inadvertently change these names, they can not be relied on, and they are no longer being made available to the predictor expression. As a side effect, this change also speeds up some bru() runs by around a factor 2, since it avoids converting the Spatial* to a regular data.frame in time-sensitive core evaluation code.

If you need access to the raw coordinate values, use explicit calls to sp::coordinates(.data.) (e.g. for custom spatial covariate evaluation.). When possible, use the built-in covariate evaluation method, eval_spatial(), either implicitly with comp(covariate, ...) or explicitly, comp(eval_spatial(covariate, where = .data.), ...), that handles crs information correctly. Also consider transitioning from sp to sf data storage, using geometry instead of raw coordinates.

Bug and dependency updates

inlabru 2.7.0

Feature overview

Feature details

Bug fixes

inlabru 2.6.0

Features

Bug fixes

inlabru 2.5.3

Features

Bug fixes

inlabru 2.5.2

inlabru 2.5.1

inlabru 2.5.0

Features

Bug fixes

inlabru 2.4.0

Features

Bugfixes

Miscellaneous

inlabru 2.3.1

inlabru 2.3.0

Breaking changes since version 2.1.13

New features since version 2.1.13

inlabru 2.2.8

For components with group and replicate features, these also need to be provided to the _eval function, with ..._eval(..., group = ..., replicate = ...)

This feature is built on top of the _latent suffix feature, that gives direct access to the latent state variables of a component, so in order to use _eval in the model predictor itself, you must use like(..., allow_latent = TRUE) in the model definition.

inlabru 2.2.7

inlabru 2.2.6

inlabru 2.2.5

inlabru 2.2.4

inlabru 2.2.2

inlabru 2.2.1

inlabru 2.2.0

inlabru 2.1.15

inlabru 2.1.13

inlabru 2.1.12

inlabru 2.1.11

inlabru 2.1.10

inlabru 2.1.9

inlabru 2.1.8

inlabru 2.1.7

inlabru 2.1.4

inlabru 2.1.3



inlabru-org/inlabru documentation built on May 5, 2024, 4:31 p.m.