HuberLoss¶
Calculate the robust Huber loss between predictions and regression target values.
This is a canonical robust substitute for the squared loss in regression problems. The Huber loss has the same shape as the squared loss within the given error threshold (delta), but continues at a fixed (linear) slope beyond that threshold. As a result, it does not over-penalize large deviations, and becomes robust to outliers. The labels should have the same shape as the predictions or otherwise at least need to be of a broadcastable shape. Like all Loss nodes (except MeasureLoss), this node returns the per-example loss, which needs to be manually summed or averaged to get a total dataset/batch loss. For a twice-differentiable alternative, see also the LogCoshLoss node. If target values are omitted, they default to 0. One may also specify a grouping structure where it is assumed that outliers may occur in clusters of observations, rather than in an i.i.d. manner; this is either an array of 0-based group ids (for non-overlapping groups), or a list of arrays of array indices (for overlapping groups), or an integer that represents the size of successive groups, which must evenly divide the number of observations (for uniformly-sized groups). More Info... Version 1.1.0
Ports/Properties¶
preds¶
Predictions.
targs¶
Target values.
output¶
Output.
delta¶
Transition point between squared and linear (robust) regime, in data units. It is crucial to set this parameter correctly to obtain the desired robust behavior. The effect of setting this value is that your loss will behave like a standard least-squares loss for any prediction errors that are smaller than this value, and like a least absolute loss for any errors that are larger. Therefore, you should think of it as the threshold, in original data units, that separates outliers from inliers. A too-small value will result in reduced statistical efficiency (like the median vs mean) while a too-large value will be no more robust than the squared loss. In some applications one can also drive this value based on a robust estimate of the standard deviation of the data (or a multiple thereof) to get an adaptive robust threshold. For binary classification problems, a convenient (very rough) heuristic is to set this to the standard deviation of the labels (0.5) times the classic 1.35 factor for the normal distribution, i.e., 0.675.
grouping¶
Optional grouping structure of the observations. This can be an integer, in which case it is assumed that successive observations are uniformly grouped in blocks of this size. It can also be an array of group ids, where each observation is assigned to a group (allowing for non-uniform groups), or a list of arrays of indices, where each array contains the indices of the observations in a group (allowing for overlapping groups). Some restrictions apply when using this inside a node like ConvexModel, such as a fixed number of groups in the overlapping case.
set_breakpoint¶
Set a breakpoint on this node. If this is enabled, your debugger (if one is attached) will trigger a breakpoint.
metadata¶
User-definable meta-data associated with the node. Usually reserved for technical purposes.
axis_pairing¶
How to pair axes of the preds and targs operands. In 'positional' mode, axes are paired by their position according to a right alignment, that is, the last axis of the first operand is paired with the last axis of the second operand, and so on, while any missing axes behave as if they were unnamed axes of length 1 (this is the same way plain n-dimensional arrays pair in Python/numpy). In 'matched' mode, axes are paired by their type and optionally label, where the axis order of the first operand is preserved in the output, optionally with additional axes that only occur in the second operand prepended on the left. The other operand then has its axes reordered to match. All axis classes are treated as distinct, except for the plain axis, which is treated as a wildcard axis that can pair with any other axis. The 'default' value resolves to a value that may be overridden in special contexts (e.g., an ambient Inference node) and otherwise resolves to the setting of the configuration variable default_axis_pairing, which is set to 'positional' in 2024.x. See also the 'label_handling' property for how labels are treated in this mode. Note that axis pairing can be subtle, and it is recommended to not blindly trust that the default behavior is always what the user intended.
label_pairing¶
How to treat axis labels when pairing axes in 'matched' mode. In 'always' mode, labels are always considered significant, and axes with different labels are always considered distinct, which means that, if the two operands each have an axis of same type but with different labels, each operand will have a singleton axis inserted to pair with the respective axis in the other operand. In 'ignore' mode, labels are entirely ignored when pairing axes; this means that, if multiple axes of the same type occur in one or more operands, the last space axis in the first operand is paired with the last space axis in the second operand, etc. as in positional mode. In 'auto' mode, labels are only considered significant if they are necessary for distinguishing two or more axes of the same type in any of the operands, or if they occur on a plain axis.
lists_as_arrays¶
Whether to treat lists as numeric arrays, as opposed to a recursive data structure. This is equivalent to converting any list operand(s) to arrays before passing them to the node. Broadly, enabling this allows for more efficient processing of large lists of either numbers, or lists of many smaller arrays, with some limitations and caveats, as follows. If one operand was a list and the other an array, an array will be returned, and if all were lists, a list will be returned (if the operand lists themselves contained arrays, the result is still a "pure" list of potentially nested lists of numbers). A limitation is that input lists may contain ONLY numbers or arrays of the same shape (e..g., no lists of blocks or packets, dictionaries, or irregular array shapes in this mode). In contrast, when the option is disabled, then if one operand is a list and the other is not a list (e.g., a number, array, block, packet, etc), then each element of the list is separately undergoing the operation while the other operand is held fixed. This has the consequence that a) the result will generally be a list if at least one operand is a list and b) the result will be mathematically different when one is a list and the other is an array, because the array will be separately combined with each list element. Note the default for this option was enabled by default in NeuroPype 2023. The option can also be set globally or in a context using the WithOptions node, for example for pipeline-wide backwards compatibility.