StochasticVariationalInference¶
Apply Bayesian inference given data and a wired-in statistical model, using Stochastic Variational Inference (SVI).
SVI fits a distribution function of a pre-specified type (e.g., Gaussian or a non-parametric form) to the posterior using a choice of stochastic gradient descent method, and subject to a criterion like the KL divergence (which can be either analytic or empirical). These amount to the main options of the node, see below for more details. SVI can be very fast compared to MCMC, but the choice of posterior approximation will introduce a bias into the results, unless it is well matched to the actual posterior (which has rarely a "simple" mathematical form, except in special model types), although some flexible approximations like BNAF can mitigate this. Therefore, Bayesian analysis frequently starts with an MCMC approach and may progress to SVI once the form of the posterior is well understood, except when working with specialized models that are designed or known to be a good fit (e.g., Kalman filters, Gaussian processes, etc) or when inference is otherwise prohibitively costly. Use cases are deployed settings with tight compute/memory budgets (on-device machine learning, cloud services), large-scale inference, and certain Bayesian time-series models. Due to its high performance, SVI is also practical for doing inference over deep neural network weights and predictions, when a deep network is embedded in the model (see the Bayes Net node for this). Like the other Inference nodes, SVI "updates" a prior distribution (as formalized by a statistical model) given observed data, yielding a (joint) posterior distribution over the latent (unobserved) variables in the model. The posterior can be accessed for further analysis via the samples outputs port. Unlike MCMC, the node does not generate much in terms of diagnostics, although the loss history can be retrieved via the history port. Once a posterior has been inferred, the node can also be used for predictve inference of dependent variables when new data is passed in, and these predictions are available over the data output port, so the node can be used as a drop-in replacement for other machine-learning nodes in NeuroPype; the inference result can also be saved and loaded back in via the model port. The statistical model is the portion of the graph that is wired into the "graph" input port and runs under the control of the node; see the "Graph [signature]" documentation (tooltip) for more detail on how statistical models can be built using nodes such as Random Draw or With Stacked Variables. Unlike the MCMC node, SVI does not currently support discrete latent variables (e.g., mixture models), but discrete dependent variables pose no problem. Like all inference nodes, the node generates an output distribution in the form of a collection of samples whose distribution matches that of the posterior; these can be scatter-plotted, summarized via moment or quantile statistics, or propagated through downstream computations. The node does not currently generate analytic posterior (predictive) probability density functions, but the variational parameters (e.g., location and scales in case of a Gaussian approximation) can be retrieved via the params port and used for this purpose. The main configuration option is the type of posterior approximation, which can be Gaussian (in which case the posterior correlations setting applies) or the flexible BNAF type, but analytic mean-field, Laplace, and MAP approxmation can also be chosen. Among the tuning options to improve convergence or debug issues are the type of cost function ("variational objective") to optimize and the type of optimizer to use for it (which can also be wired in as a node). One can also configure the number of "particles" (a type of batch size, but not the same as the mini-batch size in deep learning, the latter of which in bayesian models is rather configured via the subsample option when using a With Stacked Variables (Plate) node. The optimizers are generally interchangeable, but a skilled choice can help with models that do not converge, converge slowly, or result in NaN's or infinities. Another potential remedy is overriding the init strategy with more conservative settings. However, if this seems incurable after a handful of optimizers have been tried, the root cause is very likely a mis-specified or ill-conditioned model, or possibly bad data. For general model troubleshooting tips, see also the documentation of the MCMC node. If you get an error related to jax "tracers" or "concretization", it may be that your model has a parameter that is used for some type of control flow or structural choice (e.g., the replication count in a plate nodes), and you may have to provide this as part of the frozen model arguments instead (under miscellaneous). Like other GPU-compatible ML nodes in NeuroPype, the wired-in input data is slightly reorganized for more efficient compute, and among others, the instance axis of your data will appear as a separate stream with a feature axis (indexing the instance-axis fields such as the TargetValue) and a (blank) dummy instance axis indexing the instances. This can be further configured via options in the "Input" category. More Info... Version 0.9.0
Ports/Properties¶
data¶
The data to process.
- verbose name: Data
- default value: None
- port type: DataPort
- value type: AnyNumeric (can be None)
- data direction: INOUT
samples¶
Generated posterior samples in the desired format.
- verbose name: Samples
- default value: None
- port type: DataPort
- value type: Packet (can be None)
- data direction: OUT
history¶
History trace of inference process.
- verbose name: History
- default value: None
- port type: DataPort
- value type: Packet (can be None)
- data direction: OUT
graph¶
The graphical model to use.
- verbose name: Graph
- default value: None
- port type: GraphPort
- value type: Graph
graph__signature¶
Argument names accepted by the wired-in graphical model (statistical model). This is a listing of the names of input arguments of your statistical model, which is typically a single argument conventionally named "data" (although you can choose your own name) followed by a catch-all tilde symbol, as in (data,~). This data argument then receives the same data given to the inference node (via its data input), in most cases after minimal restructuring for efficient processing (as per the input options).
In addition to or instead of this argument, the model may accept keyword arguments (generally listed after a + separator), which may match the name of a stream (such as 'eeg') in the input data packet (in which case a single-stream packet will be assigned to that argument), or the name of an axis field (e.g., 'TargetValue') of an axis that was promoted to a stream (see the corresponding option under Input, which defaults to promoting the instance axis). In such a case, the variable receives that stream's Block, but reduced to only the axis field in question. An example signature that does this is (data, +, TargetValue, ~) and a signature that binds only a stream named 'eeg' to a keyword argument instead of receiving the data as a whole is (+, eeg, TargetValue, ~). The model may also accept an argument conventionally named 'is_training' either as a second positional argument or as a keyword argument, which will receive False if the model is used in a prediction capacity, and True otherwise.
Your model is generally a graph that begins with one or more Placeholders nodes whose slotname must match a name listed here, and which are followed by a series of nodes that collectively specify your graphical model. The final node of your network must be wired into the "graph" input of the inference node (note that in graphical UIs, the edge that goes into the "graph" input will be drawn in dotted style to indicate that this is not normal forward data flow, but that the graph runs under the control of the inference node). However, the return value of your model has no special meaning since the inference node is generally only concerned with named random variables occurring in the model (i.e., the varnames in Random Draw nodes).
A simple strategy for building a graphical model is to work backwards from the data that you wish to explain or model, and the core tool at your disposal is the Random Draw node, which specifies that the data you want to model (wired in to the obs input port) is the result of a random draw from some (specifiable) distribution (see Distributions package). Models become hierarchical by using distribution parameters that are themselves the output of a random draw. Other useful nodes are the With Stacked Variables node and the associated At Subscripts node. A wide range of other nodes may be used (e.g., math operations, formatting) to complicate the dependency structure among variables in the model.
- verbose name: Graph [Signature]
- default value: (data,~)
- port type: Port
- value type: object (can be None)
approx¶
Approximating variational distribution family.
- verbose name: Approx
- default value: None
- port type: DataPort
- value type: BaseNode (can be None)
- data direction: IN
optstep¶
Optional optimizer step node. This is one of the Step nodes (nodes ending in Step). Note that not all step nodes implement end-to-end optimizers but implement special gradient processing steps (such as clipping); if in doubt, review the documentation of the respective step nodes. Composite steps can be defined using either the ChainedStep or CustomStep nodes (the latter for a fully custom step graph).
- verbose name: Optstep
- default value: None
- port type: DataPort
- value type: BaseNode (can be None)
- data direction: IN
params¶
The estimated parameters of the model.
- verbose name: Params
- default value: None
- port type: DataPort
- value type: dict (can be None)
- data direction: OUT
posterior_approx¶
Type of approximating distribution family to use for the posterior. The Gaussian approximation is a diagonal, full-rank, or low-rank approximation as per the posterior correlations setting. The mean-field approximation is a very fast method using analytic KL divergence calculations that is mathematically equivalent to the diagonal Gaussian approximation, save for these implementation differences. The Laplace approximation is a rough approximation that inspects only the cuvature at the mode of the posterior to deduce the overall covariance (this only holds for nearly Gaussian posteriors, and the error will be larger than with the other Gaussian approximations, which account for probability mass away from the mode). This can also be given as in Laplace(1e-3) to specify a regularization parameter for additional robustness in high-dimensional settings. The MAP approximation only estimates the location of the posterior maximum (aka mode) without any Bayesian uncertainty estimates ("error bars"). The BNAF (block neural auto-regressive flow) approximation is the most flexible in this listing, and can fit non-Gaussian, skewed, and even multimodal distributions (within limits). The first parameter is the number of flows to use, and the remaining are the hidden units per layer, for an arbitrary number of layers (see also the BNAF Approximation node). The 'provided' option allows you to wire in a custom approximation family (any of the Approx nodes) using the approx port; these may offer more control over the parameters, and additional approximations beyond those listed here may be available.
- verbose name: Posterior Approximation
- default value: Gaussian
- port type: ComboPort
- value type: str (can be None)
objective¶
Type of variational objective function to optimize. Basic ELBO ("evidence lower bound") is the simplest SVI cost function and amounts to a stochastic approximation of the KL divergence; this will work with the widest range of models. The Rao-Blackwellized formulation has lower variance but is more complex and has somewhat more limited applicability (e.g., it does not currently support networks including the Bayes Net node). The Mean-Field (Analytic) objective uses analytic (as opposed to stochastic) formulas for the KL divergence, and is consequently very efficient, but is mainly meant for use when paired with the Mean-Field (Analytic) posterior approximation. The auto setting uses Mean-Field (Analytic) if the posterior approximation is set to that, otherwise Basic ELBO if the model contains a Bayes Net node, and otherwise Rao-Blackwellized. In case of inference issues it can be useful to override this and start with either Basic ELBO as a simple starting point, and only go to Rao-Blackwellized once any issues have been resolved.
- verbose name: Variational Objective
- default value: auto
- port type: ComboPort
- value type: str (can be None)
initial_stddev¶
Initial standard deviation of posterior approximation. This should be set a small value (e.g., 0.05 or 0.1), and only applies to the normal approximations (Gaussian and Mean-Field).
- verbose name: Initial Stddev
- default value: 0.1
- port type: FloatPort
- value type: float (can be None)
optimizer¶
Optimizer to use for fitting the variational approximation to the posterior distribution (as per the chosen objective function). Adam or similar algorithms are generally great choices. The default learning rate for all optimizers is set relatively high here, therefore if the optimization diverges, you may need to lower the learning rate (first parameter, e.g. by 10x). Note that while one can remedy some issues with tweaks on the optimizer side, the problem may well lie in the model (e.g., not reparameterized, badly configured distributions, model not matching the data, non-identifiable parameters, Funnel geometries, etc), the variational approximation (e.g., too flexible), or in the data (e.g., a common problem is failing to standardize the explanatory variables to reasonable scales); for these reasons it can be a good idea to first test the model with an MCMC approach, and going through tips on addressing Bayesian model mis-specification.
If Adam diverges, one can also try one of AdaBelief, AMSGrad, Fromage or Yogi. For models with a high level of gradient variance, one might also try to pass in the beta1 parameter to Adam-like optimizers (see their documentation, usually second parameter) and set it to 0.95 instead of 0.9, although this should only rarely be necessary. However, particularly when using some of the more advanced approximating familities like BNAF, or models that are extremely complex or nonlinear (like deep bayesian neural networks), it may be necessary to experiment somewhat with different optimizers. For example, if you are running out of memory with very large models, you may test AdaFactor and SM3, and if you are using extremely large batch sizes (numbers of particles in the 100s or more, for example for models that combine variational inference with deep learning), you could try out Lamb or Lars. For information on the available optimizers, see the individual Step nodes in NeuroPype's deep learning category. Optimizers can be configured with parameters here, by appending them in parentheses after the name and separated by commas, in the order of appearance in the respective step node. For example, 'Adam(0.001, 0.9, 0.999)' specifies the Adam optimizer with a learning rate of 0.001, beta1 of 0.9, and beta2 of 0.999.
To achieve the highest possible accuracy in the final solution, the learning rate may be decayed over time following a schedule to improve robustness, convergence and final-solution accuracy. To specify such a learning rate schedule one needs use a custom optimizer. This is done by choosing the "provided" optimizer setting and then wiring one of the Step nodes corresponding to an optimizer (e.g., AdamStep) into the "optstep" port (using the step node's "this" output port). Finally one wires one of the Schedule nodes (e.g., "Linear Warmup Exponential Decay Schedule" (WarmupExponentialDecaySchedule)) into the into the step node's learning rate schedule port. This also allows one to override parameters of the optimizer in oner pipeline graph rather than in textual form. When doing so, note that not all Step node are end-to-end optimizers - if in doubt, go by the optimizers in this listing or read the optimizer's documentation text (the icon will also have the text "opt step" in it). It is also possible to use a more custom optimizer using either the ChainedStep node or the CustomStep node, which gives one even finer-grained control (see documentation of these two nodes for more details on their use).
- verbose name: Optimizer
- default value: Adam(0.01)
- port type: ComboPort
- value type: str (can be None)
num_particles¶
The number of samples (aka particles) to use in each stochastic update. This is a type of batch size in stochastic gradient descent, and larger values reduce the variance of the gradient estimate and can mitigate any divergence issues, but also increase the computational cost (although on the GPU, low values may be essentially free). Note that a separate type of batch size is related to data subsampling, and this is can be enabled by using a With Stacked Variables node in the model and setting subsampling to the desired batch size. For deep learning inside the model, it can be a good idea to experiment with the number of particles (e.g., going up to 10), while for more conventional models, 1 particle is often sufficient.
- verbose name: Number Of Particles
- default value: 1
- port type: IntPort
- value type: int (can be None)
max_iter¶
Maximum number of iterations to run. 1000 is a good value, but when performing inference in deployed settings, lower values could be explored on a case-by-case basis depending on the demands of the data and model, but their fidelity should be validated.
- verbose name: Max Iterations
- default value: 1000
- port type: IntPort
- value type: int (can be None)
use_gradient_clipping¶
Whether to use an update rule that clips large gradients. This can improve robustness of the estimator.
- verbose name: Use Gradient Clipping
- default value: True
- port type: BoolPort
- value type: bool (can be None)
use_stable_update¶
Whether to use an update rule that backtracks from invalid values. This can fix some spurious divergence and may be a good choice in production settings, while during research it can mask issues that are best addressed using other means.
- verbose name: Backtrack From Invalid Values
- default value: False
- port type: BoolPort
- value type: bool (can be None)
frozen_args¶
Optional dictionary of model arguments that are "frozen" in that the model will be recompiled if they change. These can be used for certain arguments that cannot be handled dynamically.
- verbose name: Frozen Model Args
- default value: {}
- port type: DictPort
- value type: dict (can be None)
auto_prefix¶
Name prefix for used for variational parameters (parameters governing the variational approximations such as location and scales of Gaussians). If using custom approximation nodes, this is not necessarily respected.
- verbose name: Auto Prefix
- default value: vari_
- port type: StringPort
- value type: str (can be None)
set_breakpoint¶
Set a breakpoint on this node. If this is enabled, your debugger (if one is attached) will trigger a breakpoint.
- verbose name: Set Breakpoint (Debug Only)
- default value: False
- port type: BoolPort
- value type: bool (can be None)
metadata¶
User-definable meta-data associated with the node. Usually reserved for technical purposes.
- verbose name: Metadata
- default value: {}
- port type: DictPort
- value type: dict (can be None)
posterior_correlations¶
Assumed covariance structure among posterior variables. This setting determines the fidelity of the variational approximation (if Gaussian is selected) and affects the tractability and efficiency of posterior inference: 'uncorrelated' assumes that all posterior variables are uncorrelated (i.e., diagonal posterior covariance); 'lowrank(N)' assumes that correlations are dominated and explained well by the largest N factors (plus a diagonal term), and 'all-to-all' does not restrict the covariance structure in any way but can have tractability/performance issues on high-dimensional data.
- verbose name: Posterior Correlations
- default value: uncorrelated
- port type: ComboPort
- value type: str (can be None)
init_strategy¶
Override the initialization strategy for distribution parameters, optionally for individual (sets of) variables. Some choices accept a parameter that can also be omitted (the default is shown in the drop-down examples). Uniform(r) initializes each parameter to a uniform range within -r to +r in the "unconstrained" domain, which is very frequently a good default, although at times the system may have to make multiple attempts to find a feasible starting point. At times, models can require a more conservative choice, for example median(n) initializes to the median of n samples drawn from the prior distribution, mean uses the expected value, sample draws a random sample, feasible initializes to a fixed trivially feasible point (e.g., 0), and value(x) initializes to a given fixed value x. This can also be specified on a per-variable basis (but typically not necessary for well-specified models), using a dictionary syntax where the variable name (or a wildcard pattern) is used as the key and the value is the initialization form. See also drop-down options for concrete examples.
- verbose name: Init Strategy
- default value: uniform
- port type: ComboPort
- value type: str (can be None)
promote_axis¶
If given, promote axes of the specified type to their own stream using the Promote Axis to Stream node. This adds a new stream to the data packet that holds the data of the selected axis; It has a feature axis that indexes the fields of the axis (e.g., 'TargetValue', 'times', etc) and a (blank) dummy copy of the axis as the second dimension, and the axis "payload" (i.e. numeric content) is then accessible in the stream's two-dimensional data array like any other data modality. This representation is generally used in contexts that employ high-performance (multicore or GPU-accelerated) computation, including the Deep Model, Convex Model, and Inference nodes. This can be disabled by leaving the option blank (but note that doing so can incur heavy performance overhead each time the axis content changes from one use of the node to another, e.g., in a cross-validation). You can also disable this you wish to manually use the Promote Axis to Stream or other formatting node beforehand. The new stream is by convention named the same as the axis (i.e., 'instance'), unless there are multiple different streams with matching axes that are not equal to each other, in which case one stream per source stream is created and is named 'streamname-axisname'. The original axis will be cleared to all-defaults for the purpose of running the model graph, but will be restored afterwards from the stream (if modified during inference) or the original axis.
- verbose name: Promote Axis To Stream
- default value: instance
- port type: ComboPort
- value type: str (can be None)
pass_metadata¶
Graph accesses marker-stream or props metadata. If this is selected, then marker streams and stream (chunk) properties will be preserved when the input data enters the model graph. If this is deselected (the default), both any marker streams and all but a few essential chunk properties will be removed for the purposes of inference (which avoids unnecessary recompilation of the model graph, but the model will not have access to these details) and are restored afterwards.
- verbose name: Pass Marker/props Metadata
- default value: False
- port type: BoolPort
- value type: bool (can be None)
data_format¶
The type of statistics to output in the main data output packet (for prediction use cases). This can either be a comma-separated list of summary statistics, in which case the data output will contain a statistic axis along which the respective statistics are itemized, or it can be set to distribution, in which case the output will have a distribution axis along which the desired number of posterior samples are enumerated. The former is useful for a simple estimate-with-error-bars type of representation, which can then be used for plotting etc. If a single location statistic is used (e.g., mean or median), then the output will be largely compatible with the output of a conventional machine learning node (which tend to output a posterior mode or maximum-likelihood estimate depending on the type of model), and the inference node can be used as a drop-in replacement for such nodes. When error statistics are included (e.g., stddev, mad, or ci90), only a few successor nodes will correctly interpret or preserve this output, for example some of the plotting nodes that can display error bars; other numeric nodes will either ignore these statistics (e.g., MeasureLoss) or will act on all statistics using the same operation, which is typically not correct. Instead, if further downstream computations are to be performed with the output of the inference node, it is recommended to use the distribution output, since posterior samples will propagate through most mathematical operations correctly, i.e., the result will be a distribution over the result of the successor operation(s).
- verbose name: Data Output Statistics
- default value: distribution
- port type: ComboPort
- value type: str (can be None)
num_pred_samples¶
Number of samples to use when computing various kinds of post-hoc statistics. This affects alll downstream statistics, including the fidelity of the posterior approximation available via the samples output, as well as any predictions available through the data output. Note that when using low-dimensional predictions in a machine-learning context, quite low values such as 32-128 may be sufficient for the desired accuracy and will reduce the compute and memory requirements in prediction workflows.
- verbose name: Num Stats Samples
- default value: 256
- port type: IntPort
- value type: int (can be None)
data_vars¶
Optionally a listing of variables for which to generate predictions. By default this will be all variables that are not included in the posterior distribution (what is returned by the dist and samples outputs), which in practice amounts to all observable variables in the model. In general, the node will name the streams in the packet based on the variable (e.g., 'y') and if the respective Random Draw node was configured via a like= input to output a Packet, then this stream name will be concatenated to the variable name (e.g., 'y_eeg'). To take control of the output stream names, one may also specify this as a dictionary, where the keys are the variable names whose data to emit and the values are the desired output stream names (e.g., {'y': 'eeg']).
- verbose name: Data Output Variables
- default value: None
- port type: Port
- value type: object (can be None)
exclude_from_posterior¶
Optionally a listing of latent variable names or patterns to exclude from the posterior. It is recommended to use patterns that end in a * to also cover cases where additional related variables, such
- verbose name: Exclude From Posterior
- default value: None
- port type: ListPort
- value type: list (can be None)
vectorized_prediction¶
The way in which samples are handled during prediction from new data and generation of predictive statistics. Note that both modes are compiled and will run efficiently, but the vectorized mode can be considerably faster with small (low-dimensional / few samples) models. For high-dimensional models, the memory requirements of the vectorized mode can be very large and the mode is not necessarily faster, so the serial mode is recommended in such cases.
- verbose name: Vectorized Prediction
- default value: serial
- port type: EnumPort
- value type: str (can be None)
canonicalize_output_axes¶
Whether to canonicalize the data output axes of the node to match the expected output axes of other machine-learning nodes. This only applies to the data output (predictions) and only if the model outputs data with an instance axis. This is mainly useful if you use the Inference node in an ML workflow (MeasureLoss, Crossvalidation, Parameter Optimization) and ensures that the output has a feature axis that properly encodes what the outputs represent. If the observable variables in your model have highly custom axes (other than one instance and optionally a feature axis), you may need to do some extra reformatting between the Inference node and any downstream ML workflow node.
- verbose name: Canonicalize Output Axes
- default value: True
- port type: BoolPort
- value type: bool (can be None)
seed¶
Seed for any pseudo-random choices during training. This can be either a splittable seed as generated by Create Random Seed or a plain integer seed. If left unspecified, this will resolve to either the current 0-based "task number" if used in a context where such a thing is defined (for example cross-validation or a parallel for loop), or 12345 as a generic default.
- verbose name: Random Seed
- default value: None
- port type: Port
- value type: AnyNumeric (can be None)
update_on¶
Update the model on the specified data. This setting controls how the node behaves when it is repeatedly invoked with data and can usually be left at its default. For use cases in which the node is invoked only a single time in a pipeline, all settings are equivalent. Scenarios where a difference arises include 1) real-time (streaming, aka "online") processing, where initially a non-streaming ("offline") dataset is passed in or a previously trained model is loaded in), and subsequently streaming data is passed through the node, 2) machine-learning style offline analysis, where the node is first given an offline dataset to train on, and then subsequently given a (still offline) test dataset to evaluate the trained model on, or 3) when the model is adapted over the course of multiple successive invocations with potentially different datasets. The settings are then as follows: "initial offline" will adapt the model only on the first non-streaming data that it receives (note that whether data is considered streaming or not is a matter of whether its is_streaming flag is set, rather than whether it comes in in actual real time). The "successive offline" mode will keep updating the model on any data marked non-streaming (this will use the model's prior state if none is wired in, or the wired-in state, which therefore must come from a previous invocation of the model). The "offline and streaming" mode will train on any data, regardless of whether it is offline or streaming (e.g., for adaptive real-time training). Note that not all inference nodes will support the offline and streaming mode -- specifically, MCMC Inference does not. The parameter can also be changed at runtime, to switch from one mode to another.
- verbose name: Update On
- default value: initial offline
- port type: EnumPort
- value type: str (can be None)
dont_reset_model¶
Do not reset the model when the preceding graph is changed. Normally, when certain parameters of preceding nodes are being changed, the model will be reset. If this is enabled, the model will persist, but there is a chance that the model is incompatible when input data format to this node has changed.
- verbose name: Do Not Reset Model
- default value: False
- port type: BoolPort
- value type: bool (can be None)
verbosity¶
Verbosity level. Higher numbers will produce more extensive printed output.
- verbose name: Verbosity Level
- default value: 1
- port type: EnumPort
- value type: str (can be None)
axis_pairing¶
Axis pairing override to apply within the context of the model. This will cause all nodes in the model graph that have an axis_pairing option set to 'default' to use this setting instead. It is recommended to leave this to 'matched'; if set to positional, several options in model nodes need to be carefully chosen in correspondence with the axis position in the data, including the number of event-space dimensions in AtSubscript nodes, and the dimension index (relative to the event-space dimension) for any With Stacked Variables nodes. One also needs to be careful with whether distributions have a multivariate event space (e.g., Multivariate Normal) or not (most other distributions).
- verbose name: Axis Pairing In Model
- default value: matched
- port type: EnumPort
- value type: str (can be None)
vectorized_inference¶
Whether to vectorize computation across particles. This will be more efficient, but also uses more memory during inference.
- verbose name: Vectorized Inference
- default value: vectorized
- port type: EnumPort
- value type: str (can be None)
differentiation_mode¶
The differentiation mode to use. Forward is supported by all constructs that may occur in a model. Reverse can be more efficient depending on the ratio of data points to parameters, but is not supported for example when Fold Loops are used in the model (e.g., for time-series models), and will throw an error in such cases.
- verbose name: Differentiation Mode
- default value: reverse
- port type: EnumPort
- value type: str (can be None)